Re: Fwd: gcc cross compiler problem

[Paul Brook]

> I am running into a problem when I am trying to compile GCC to run on
> a i686-pc-linux-gnu (host) but to build source code for target,
> x86_64-pc-linux-gnu. I have build binutils first with the following
> configure parameters:

> --enable-plugin  --with-cpu=generic --host=x86_64-pc-linux-gnu

This should be --target=

In future this king of question is more suited to the gcc-help mailing list.

Paul

Database for GCC

[Tom Browder]

A naive thought, perhaps:

Would there be any advantage to using a key-value embedded database
program for the voluminous maps needed for gcc optimization, etc.?

If so, consider .

I have used its predecessor, qdbm, for years and it was very fast.  TC
is faster still.

I notice many threads here about memory requirements and speed
reductions--perhaps there is some way TC could help with those
problems.

-Tom

Re: IRA for GCC 4.4

[Vladimir Makarov]

Kenneth Zadeck wrote:

Vladimir Makarov wrote:

Peter Bergner wrote:

On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
 
Thanks, Peter.  That was clever and email is very enlightening.  I 
have analogous idea for more compact conflict matrix 
representation.  IRA builds allocno live ranges first (they are 
ranges of program points where the allocno lives).  I can use this 
information for fast searching potential conflicts to sort the 
allocnos.  Probably the matrix will be even more compact because 
live ranges contain more detail info than basic blocks where the 
local allocnos live.  For example, the ranges even can show that 
allocnos local in the same block will never conflicts.  It means 
that matrix even for fppp can be compressed.



You say you use your analogous idea now?  Can you point me to the code?
I thought I heard you (maybe someone else?) that your conflict 
information
was much bigger than old mainline.  If this is true and you are 
compacting

the bit matrix like I am, why is it so big?


  
I am currently working on bit matrix compression.  It is not 
implemented yet.  I hope it will be ready in a week.


vlad, this seems like the wrong way to go.   i understand that you 
feel that it is a sign of weakness to use someone else's fully 
debugged and functional code rather than writing it from scratch, but 
every one else feels that (a) you could better spend your time working 
on the other issues that will be relevant to getting this thing in and 
(b) none of the other reviewers looks forward to just seeing a lot of 
the same code only different.
Ken, I am far from feeling this way.  I think you persistence to use 
Peter's code is probably from bad knowledge of IRA specifics.  I'll try 
to explain reasons why I am not just using Peter's code:


o number of allocnos in IRA is changed (new allocnos can be added after 
live range splitting, some allocnos can be removed and other allocnos 
can inherent their conflicts during transformation of regional IR into 
plain IR).


o Adding conflicts is done not on just one step.  After building 
conflicts for allocnos, in some time there is a step where conflicts 
from low level region allocnos results in adding conflicts on 
corresponding upper level region allocnos.


o I have info about program points where allocno lives and it can be 
used for building more compressed bit matrix than Peter's one because 
he  uses only bb where local allocnos live.  Using this info permits to 
define in some cases that even two global allocnos or two allocnos local 
in the same BB will never conflict.


o I see a bigger picture how intermediate data used to build compressed 
bit vectors help me to solve -O0 IRA slowness problem (using just the 
reload without any allocation is not a solution).


o IRA uses a bit different approach to traverse all conflicting allocnos 
than Peter's code for adjacency lists.  Instead of bit vector matrix, 
IRA uses bit vectors attached to allocnos.  If the bit vector is smaller 
than adjacency list (some criteria for smallness is used), the adjacency 
list is not formed and the bit vector is used to visit conflicting 
allocnos.  It permits save memory.  On the other hand, it means no 
triangular bit matrix.  And this code was written long before Peter's one.


Taking all this into account, I see much more work and modifications to 
integrate Peter's code into IRA than just compressing bit vectors in 
existing IRA infrastructure.


I hope that this email will help to understand why I am not just using 
Peter's code which I do really like.  It is just code for a different 
allocator.

Re: Database for GCC

[J.C. Pizarro]

On Tue, 29 Apr 2008 08:16:14 -0500, "Tom Browder" <[EMAIL PROTECTED]> wrote:
> A naive thought, perhaps:
>
> Would there be any advantage to using a key-value embedded database
> program for the voluminous maps needed for gcc optimization, etc.?
>
> If so, consider .
>
> I have used its predecessor, qdbm, for years and it was very fast.  TC
> is faster still.
>
> I notice many threads here about memory requirements and speed
> reductions--perhaps there is some way TC could help with those
> problems.
>
> -Tom

It's interesting but this database manager TC as the SQLite are
 non-concurrent or non-parallel libraries versus their perspective
 another libraries DB4 and MySQL that can be concurrent or
 parallel.

But it's not a general problem. You can use them using filelocks
 but the access to this database manager is non-concurrent.

The applicability of TC for GCC can be enormeus:
* for storing compiled objects with many attributes of information.
* for storing profiles of the runs.
* for storing logs of the compilations of experimental GCC.
* for browsing this locked database for track the internal details of GCC.
* etc.

   J.C.Pizarro

Re: [RFC] Modeling the behavior of function calls

[Joe Buck]

On Mon, Apr 28, 2008 at 03:04:56PM -0400, Diego Novillo wrote:
> [ Apologies if this comes out twice.  I posted this message last week,
>but I think it was rejected because of a .pdf attachment. ]
> 
> We have been bouncing ideas for a new mechanism to describe the behavior
> of function calls so that optimizers can be more aggressive at call
> sites.  Currently, GCC supports the notion of pure/impure,
> const/non-const, but that is not enough for various cases.
> 
> The main application for this would be stable library code like libc,
> that the compiler generally doesn't get to process.
...
> The main idea is to add a variety of attributes to describe contracts
> for function calls.  When the optimizers read in the function
> declaration, they can take advantage of the attributes and adjust the
> clobbering effects of call sites.

Such a facility can have other uses, particularly for static analysis,
by allowing simple preconditions and postconditions to be specified.
For example:

* a returned pointer is guaranteed to be non-null.
* a supplied pointer is always dereferenced.
* a supplied pointer must be dereferenceable on input, and that pointer
  is no longer dereferenceable after return, e.g. free().

Of course, there's a tradeoff between implementation complexity and
features, as always.  While these facilities might help the optimizer,
the compiler could also issue warnings if it detects that a precondition
must be violated (and this can also be used to check the correctness
of any user-supplied annotations).

Re: IRA for GCC 4.4

[Mark Mitchell]

Kenneth Zadeck wrote:

Thanks, Peter.  That was clever and email is very enlightening.  I 
have analogous idea for more compact conflict matrix 
representation.


I am currently working on bit matrix compression.  It is not 
implemented yet.  I hope it will be ready in a week.



vlad, this seems like the wrong way to go.


Vladimir, if you feel that Peter's code cannot be used directly in IRA, 
would you please explain why not?  It does seem like it would be easier 
for everyone if we could leverage what has already been done.


Thanks,

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

Re: [RFC] Modeling the behavior of function calls

[Diego Novillo]

On 4/29/08 1:31 PM, Joe Buck wrote:


Such a facility can have other uses, particularly for static analysis,
by allowing simple preconditions and postconditions to be specified.
For example:

* a returned pointer is guaranteed to be non-null.
* a supplied pointer is always dereferenced.
* a supplied pointer must be dereferenceable on input, and that pointer
  is no longer dereferenceable after return, e.g. free().


Indeed.


Of course, there's a tradeoff between implementation complexity and
features, as always.  While these facilities might help the optimizer,
the compiler could also issue warnings if it detects that a precondition
must be violated (and this can also be used to check the correctness
of any user-supplied annotations).


Yes, one of the ideas we discussed is for the compiler to do semantic 
checks when compiling the marked-up code to make sure the attributes are 
not lying.  Since not all the attributes can be strictly checked, we'll 
probably end up emitting a mixture of errors and warnings.  The latter 
will probably take us into false positive problems which we'll have to 
address as we find them.


These attributes cannot be checked while compiling client code, of 
course.  At most we can check that the code being compiled is not 
calling any function marked with contradictory attributes.



Diego.

Re: [RFC] Modeling the behavior of function calls

[Andrew Pinski]

On Tue, Apr 29, 2008 at 10:59 AM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 4/29/08 1:31 PM, Joe Buck wrote:
>
>
> > Such a facility can have other uses, particularly for static analysis,
> > by allowing simple preconditions and postconditions to be specified.
> > For example:
> >
> > * a returned pointer is guaranteed to be non-null.
> > * a supplied pointer is always dereferenced.
> > * a supplied pointer must be dereferenceable on input, and that pointer
> >  is no longer dereferenceable after return, e.g. free().
> >
>
>  Indeed.

We already have the second one, called nonnull

 The first one is recorded as PR 20318.

Thanks,
Andrew Pinski

Re: Security vulernarability or security feature? VU#162289

[Ian Lance Taylor]

"Robert C. Seacord" <[EMAIL PROTECTED]> writes:

> The original impetus for this came from a check in a sprint() function 
> from Plan 9.  Because of the API, there was no way to test if the len 
> was out of bounds, but the developers wanted to make sure they weren't
> wrapping the stack on some architectures that have their stacks in
> high memory.

The code in question is here:

http://groups.google.com/group/comp.os.plan9/msg/d5c0a5836622f0c9

That code can be rewritten in standard conformant C.  For example:

  len = min(1 << 30, - (uintptr_t) buf - 1);

I will update you with the status of the new gcc warnings about this
code when the work is complete in all active branches.

Ian

Re: IRA for GCC 4.4

[Steven Bosscher]

On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>  Vladimir, if you feel that Peter's code cannot be used directly in IRA,
> would you please explain why not?

I think he already has explained, see
http://gcc.gnu.org/ml/gcc/2008-04/msg00730.html

Having looked at IRA a bit, I think I have to agree with Vlad that
Peter's code is not easily adapted to IRA.  Peter's code works for a
single, immutable conflict graph for the whole function.  IRA works
with inter-region and intra-region conflicts (as far as I understand,
documentation in ira-conflict.c would be welcome), so the sorting
trick that Peter uses, doesn't translate one-to-one to Vlad's
allocator.

Having said that, I think the "square" approach with
mirror_conflicts() that IRA currently has, is a big step backward from
what we have now.  IRA should at least have a representation for
conflicts that does not duplicate information unnecessary.  The bits
that seem to be bad in this respect are build_conflict_bit_table() and
mirror_conflicts().  It's not clear to me how these are used, but it
looks like you can end up building a square conflict graph for the
whole function, like GCC did before Peter's work.  This could be a
huge memory and speed regression if it isn't addressed.

Another note: IRA uses VARRAYs, and I was under the impression we are
trying to move away from those.  Vlad, please use VECs instead.

Gr.
Steven

Re: IRA for GCC 4.4

[J.C. Pizarro]

On Tue, 29 Apr 2008 20:25:56 +0200, "Steven Bosscher"
<[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> >  Vladimir, if you feel that Peter's code cannot be used directly in IRA,
> > would you please explain why not?
>
> I think he already has explained, see
> http://gcc.gnu.org/ml/gcc/2008-04/msg00730.html
>
> Having looked at IRA a bit, I think I have to agree with Vlad that
> Peter's code is not easily adapted to IRA.  Peter's code works for a
> single, immutable conflict graph for the whole function.  IRA works
> with inter-region and intra-region conflicts (as far as I understand,
> documentation in ira-conflict.c would be welcome), so the sorting
> trick that Peter uses, doesn't translate one-to-one to Vlad's
> allocator.
>
> Having said that, I think the "square" approach with
> mirror_conflicts() that IRA currently has, is a big step backward from
> what we have now.  IRA should at least have a representation for
> conflicts that does not duplicate information unnecessary.  The bits
> that seem to be bad in this respect are build_conflict_bit_table() and
> mirror_conflicts().  It's not clear to me how these are used, but it
> looks like you can end up building a square conflict graph for the
> whole function, like GCC did before Peter's work.  This could be a
> huge memory and speed regression if it isn't addressed.
>
> Another note: IRA uses VARRAYs, and I was under the impression we are
> trying to move away from those.  Vlad, please use VECs instead.
>
> Gr.
> Steven

Use my idea of flexible chained upper triangulars & rectangulars as
 indicated briefly in

http://gcc.gnu.org/ml/gcc/2008-04/msg00707.html
http://gcc.gnu.org/ml/gcc/2008-04/msg00681.html

You can update easily these structures through subroutines that
 traverse the chains and update their chained local structures when
 is needed, and is similar to the Observer pattern (when the subjects
 are modified then it update the views of the observers too).

   J.C.Pizarro

Re: libstdc++ svn head broken

[Benjamin Kosnik]

> Doing a build of gcc from revision 134693 with

The build issue should be fixed post 134776.

-benjamin

Re: IRA for GCC 4.4

[Vladimir Makarov]

Mark Mitchell wrote:

Kenneth Zadeck wrote:

Thanks, Peter.  That was clever and email is very enlightening.  I 
have analogous idea for more compact conflict matrix representation.


I am currently working on bit matrix compression.  It is not 
implemented yet.  I hope it will be ready in a week.



vlad, this seems like the wrong way to go.


Vladimir, if you feel that Peter's code cannot be used directly in 
IRA, would you please explain why not?  It does seem like it would be 
easier for everyone if we could leverage what has already been done.


Sorry, Mark.  I believe I already explained in my previous email why the 
code is hard to incorporate into IRA.  It is just more easy to add one 
missed feature into IRA conflict infrastructure.


I am not going to ignore all Peter's code.  After some investigation, I 
decided to use sparsets implemented by Peter and Janis.  It is already 
implemented and easy to use and there is no harm in using this, only 
potential improvement in compiler speed (although most probably this 
improvement will be insignificantly).

Re: IRA for GCC 4.4

[Vladimir Makarov]

Steven Bosscher wrote:

On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
  

 Vladimir, if you feel that Peter's code cannot be used directly in IRA,
would you please explain why not?



I think he already has explained, see
http://gcc.gnu.org/ml/gcc/2008-04/msg00730.html

Having looked at IRA a bit, I think I have to agree with Vlad that
Peter's code is not easily adapted to IRA.  Peter's code works for a
single, immutable conflict graph for the whole function.  IRA works
with inter-region and intra-region conflicts (as far as I understand,
documentation in ira-conflict.c would be welcome), so the sorting
trick that Peter uses, doesn't translate one-to-one to Vlad's
allocator.

  
Thanks, Steven.  It is really harder to incorporate.  Also, using live 
ranges potentially results in more compact bit vectors.  I forgot to say 
that conflict bit vectors and adjacency lists (vector of pointers to 
conflict allocnos) in IRA contains only allocno of the same cover 
classes.  I can use the fact and compress conflict vectors even more.

Having said that, I think the "square" approach with
mirror_conflicts() that IRA currently has, is a big step backward from
what we have now.  IRA should at least have a representation for
conflicts that does not duplicate information unnecessary.  The bits
that seem to be bad in this respect are build_conflict_bit_table() and
mirror_conflicts().  It's not clear to me how these are used, but it
looks like you can end up building a square conflict graph for the
whole function, like GCC did before Peter's work.  This could be a
huge memory and speed regression if it isn't addressed.

  
It will be addressed (I am working on this).  There will be no mirror 
conflicts anymore.  But I don't use and I am not going to use triangular 
matrix.  It means more memory from one point of view.  On other had, It 
permits me to use conflict bit vector for implementation of adjacency 
lists (and not allocate vector of pointers to conflict allocnos saving 
memory) if the conflict bit vector is smaller than vectors of the pointers.

Another note: IRA uses VARRAYs, and I was under the impression we are
trying to move away from those.  Vlad, please use VECs instead.
  
Steven, thanks for pointing this.  I'll remove VARRAYs.  It is probably 
code which was written long ago.  I tried to use VECs in more fresh code.

Re: IRA for GCC 4.4

[Vladimir Makarov]

J.C. Pizarro wrote:

On Tue, 29 Apr 2008 20:25:56 +0200, "Steven Bosscher"
<[EMAIL PROTECTED]> wrote:
  

On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:


 Vladimir, if you feel that Peter's code cannot be used directly in IRA,
would you please explain why not?
  

I think he already has explained, see
http://gcc.gnu.org/ml/gcc/2008-04/msg00730.html

Having looked at IRA a bit, I think I have to agree with Vlad that
Peter's code is not easily adapted to IRA.  Peter's code works for a
single, immutable conflict graph for the whole function.  IRA works
with inter-region and intra-region conflicts (as far as I understand,
documentation in ira-conflict.c would be welcome), so the sorting
trick that Peter uses, doesn't translate one-to-one to Vlad's
allocator.

Having said that, I think the "square" approach with
mirror_conflicts() that IRA currently has, is a big step backward from
what we have now.  IRA should at least have a representation for
conflicts that does not duplicate information unnecessary.  The bits
that seem to be bad in this respect are build_conflict_bit_table() and
mirror_conflicts().  It's not clear to me how these are used, but it
looks like you can end up building a square conflict graph for the
whole function, like GCC did before Peter's work.  This could be a
huge memory and speed regression if it isn't addressed.

Another note: IRA uses VARRAYs, and I was under the impression we are
trying to move away from those.  Vlad, please use VECs instead.

Gr.
Steven



Use my idea of flexible chained upper triangulars & rectangulars as
 indicated briefly in

http://gcc.gnu.org/ml/gcc/2008-04/msg00707.html
http://gcc.gnu.org/ml/gcc/2008-04/msg00681.html

You can update easily these structures through subroutines that
 traverse the chains and update their chained local structures when
 is needed, and is similar to the Observer pattern (when the subjects
 are modified then it update the views of the observers too).

  
Your approach was interesting but it needs some partition of allocnos.  
This partition is present in Peter's code (local allocnos in each BB and 
global allocnos).  Partition is not easy to do when  live ranges  are 
used to find potential conflicts.  Also such partition is less accurate 
and will result bigger matrices than using live ranges to find potential 
conflict for each allocno pair.


The part of what you are proposing (partitioning allocnos) is close to 
many implementation of register allocators, e.g. Chow in his 
implementation of priority coloring built conflicts only for global 
allocnos to save memory.

Weird result for modulus operation

[Ang Way Chuang]

Hi all,
Firstly, I want to thank gcc developers for the wonderful compiler 
suite.

	I ran into a problem. I am not whether this is regression or not. I 
compiled the following code using gcc-4.2.3 ubuntu 8.04 x86-64 and 
gcc-4.1.2 fedora 8  i686


struct abc {
int a;
int b;
};

void postfix(void)
{
struct abc abc;
abc.b = 16;
abc.a = 17;
abc.a = abc.a++ % abc.b;
printf("postfix a %d\n", abc.a);
}


The output that I get when postfix function is called is:
postfix a 18

I expected the result to be something like this:
postfix a 1

	However when I compile the code using gcc-3.4 on fedora 8 i686. The 
result is :


postfix a 1

	which is the result I expected. So, is the result given by gcc version 
4 compliant with the C standard or a bug? If it is compliant with the C 
standard, can somebody care to explain it to me why it behaves in such a 
way?


Thank you in advance.

Regards,
Ang Way Chuang

Re: Weird result for modulus operation

[Andrew Pinski]

On Tue, Apr 29, 2008 at 8:50 PM, Ang Way Chuang <[EMAIL PROTECTED]> wrote:

> abc.a = abc.a++ % abc.b;

You are assigning to abc.a twice without a sequence point inbetween so
this code is undefined as the order of evaluation of expressions
without a sequence point is unspecified.

Thanks,
Andrew Pinski

Re: Weird result for modulus operation

[Ang Way Chuang]

Andrew Pinski wrote:

On Tue, Apr 29, 2008 at 8:50 PM, Ang Way Chuang <[EMAIL PROTECTED]> wrote:


abc.a = abc.a++ % abc.b;


You are assigning to abc.a twice without a sequence point inbetween so
this code is undefined as the order of evaluation of expressions
without a sequence point is unspecified.

Thanks for the speedy reply. But why this code:

int a = 17, b = 16;
a = a++ % 16;

results in a = 2 then? I think I need to know what is sequence point. 
I'll google that.


Thanks,
Andrew Pinski

Re: Weird result for modulus operation

[Andrew Pinski]

On Tue, Apr 29, 2008 at 9:08 PM, Ang Way Chuang <[EMAIL PROTECTED]> wrote:
>  Thanks for the speedy reply. But why this code:
>
> int a = 17, b = 16;
> a = a++ % 16;
>
>  results in a = 2 then? I think I need to know what is sequence point. I'll
> google that.

As I mentioned, the code is undefined so it could be any value.

Thanks,
Andrew Pinski

Re: Weird result for modulus operation

[Ang Way Chuang]

Andrew Pinski wrote:

On Tue, Apr 29, 2008 at 9:08 PM, Ang Way Chuang <[EMAIL PROTECTED]> wrote:

 Thanks for the speedy reply. But why this code:

int a = 17, b = 16;
a = a++ % 16;

 results in a = 2 then? I think I need to know what is sequence point. I'll
google that.


As I mentioned, the code is undefined so it could be any value.


Is there any flag in gcc that can provide warning to code that relies on 
undefined behaviours?




Thanks,
Andrew Pinski

Re: Weird result for modulus operation

[Ang Way Chuang]

Ang Way Chuang wrote:

Andrew Pinski wrote:

On Tue, Apr 29, 2008 at 9:08 PM, Ang Way Chuang <[EMAIL PROTECTED]> wrote:

 Thanks for the speedy reply. But why this code:

int a = 17, b = 16;
a = a++ % 16;

 results in a = 2 then? I think I need to know what is sequence 
point. I'll

google that.


As I mentioned, the code is undefined so it could be any value.


Is there any flag in gcc that can provide warning to code that relies on 
undefined behaviours?


Found it. -Wsequence-point which is enabled by -Wall. But gcc didn't 
fart out any warning with -Wall or -Wsequence-point flag :(






Thanks,
Andrew Pinski

Re: Weird result for modulus operation

[Paolo Bonzini]

Ang Way Chuang wrote:

Ang Way Chuang wrote:

Andrew Pinski wrote:

On Tue, Apr 29, 2008 at 9:08 PM, Ang Way Chuang <[EMAIL PROTECTED]> wrote:

 Thanks for the speedy reply. But why this code:

int a = 17, b = 16;
a = a++ % 16;

 results in a = 2 then? I think I need to know what is sequence 
point. I'll

google that.


As I mentioned, the code is undefined so it could be any value.


Is there any flag in gcc that can provide warning to code that relies 
on undefined behaviours?


Found it. -Wsequence-point which is enabled by -Wall. But gcc didn't 
fart out any warning with -Wall or -Wsequence-point flag :(


You found a bug, it does point out the problem with the second example here.

Paolo