Re: GFDL/GPL issues

[Benjamin Kosnik]

> So one way to move forward is to effectively have two manuals, one
> containing traditional user-written text (GFDL), the other containing
> generated text (GPL).  If you print it out as a book, the generated
> part would just appear as an appendix to the manual, it's "mere
> aggregation".

This is not acceptable to me. 

You have just described the status quo,
what we are already doing. It is very difficult to link api
references to manual references in two separate documents. What I want
to do is full integration, and not be forced into these aggregations.

And I am being denied. 

I am very disheartened by this conversation. I'm actually incredulous,
exactly as expressed by Diego, that this is even an issue. These ivory
tower replies about awesome docs written by programmer-scribe-monks
for simple C interfaces that none of the email authors is in fact
writing are incredibly annoying to me, as somebody who is actually
doing this work. Let's at least give weight to the people in the gcc
community who are doing this work, ok? Or else I will stop doing it.

This should be a minor detail, not a month long thread. All we are
asking is for the permission to render GPL code as GFDL in addion to
GPL. No freedoms are being lost here dudes.

-benjamin

Re: GFDL/GPL issues

[Benjamin Kosnik]

> The FSF's responsibility for legal matters under the Mission
> Statement comes with a duty to the developers not to get in the way
> of the "Patches will be considered equally based on their technical
> merits." principle from the Mission Statement.  The FSF is failing in
> its duty to what was traditionally considered one of its flagship
> projects.  If this has not been brought up with the full board of
> directors of the FSF, it is time that it was so brought up.  Richard
> may have the right point in
>  regarding problems
> with FSF leadership.  I support the FSF's various campaigns for
> freedom and against closed devices and systems, but I get the
> impression that they have been losing sight of the needs of their
> traditional flagship projects lately.

I agree. SC, please escalate.

-benjamin

Re: Restrict qualifier still not working?

[Richard Guenther]

On Tue, Aug 3, 2010 at 6:38 PM, Bingfeng Mei  wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: 03 August 2010 17:22
>> To: Bingfeng Mei
>> Cc: Alexander Monakov; gcc@gcc.gnu.org
>> Subject: Re: Restrict qualifier still not working?
>>
>> On Tue, Aug 3, 2010 at 6:11 PM, Bingfeng Mei  wrote:
>> > Richard,
>> > I applied the patch. The simple example in my previous mail is
>> > compiled as expected. However, for a bit more complex example,
>> > restrict qualifier still doesn't work as expected. This happens
>> > even on trunk compiler so it is not due to some missing patches on
>> 4.5.
>> >
>> > void foo (int * restrict a, int * restrict b, int * restrict c)
>> > {
>> >   int i;
>> >   for(i = 0; i < 100; i+=4)
>> >     {
>> >       a[i] = b[i] * c[i];
>> >       a[i+1] = b[i+1] * c[i+1];
>> >       a[i+2] = b[i+2] * c[i+2];
>> >       a[i+3] = b[i+3] * c[i+3];
>> >     }
>> > }
>> >
>> > ~/work/install-x86/bin/gcc tst3.c -O2 -S -std=c99 -da -fschedule-
>> insns -frename-register
>> >
>> > .L2:
>> >        movl    (%rdx,%rax), %r10d
>> >        imull   (%rsi,%rax), %r10d
>> >        movl    %r10d, (%rdi,%rax)
>> >        movl    4(%rdx,%rax), %r9d
>> >        imull   4(%rsi,%rax), %r9d
>> >        movl    %r9d, 4(%rdi,%rax)
>> >        movl    8(%rdx,%rax), %r8d
>> >        imull   8(%rsi,%rax), %r8d
>> >        movl    %r8d, 8(%rdi,%rax)
>> >        movl    12(%rdx,%rax), %ecx
>> >        imull   12(%rsi,%rax), %ecx
>> >        movl    %ecx, 12(%rdi,%rax)
>> >        addq    $16, %rax
>> >        cmpq    $400, %rax
>> >        jne     .L2
>> >        rep
>> >
>> > This used to compile efficiently on our 4.4 port. Any comments?
>>
>> It's due to TMR_ORIGINAL being used for MEM_EXPRs during
>> expansion (and TMRs not being handled by the alias oracles
>> well).  I can look at this if you file a bugreport, so I remember.
>>
>> A patch as simple as
>>
>> Index: expr.c
>> ===
>> --- expr.c      (revision 162841)
>> +++ expr.c      (working copy)
>> @@ -8665,7 +8665,7 @@ expand_expr_real_1 (tree exp, rtx target
>>         set_mem_addr_space (temp, as);
>>         base = get_base_address (TMR_ORIGINAL (exp));
>>         if (base
>> -           && INDIRECT_REF_P (base)
>> +           && (INDIRECT_REF_P (base) || TREE_CODE (base) == MEM_REF)
>>             && TMR_BASE (exp)
>>             && TREE_CODE (TMR_BASE (exp)) == SSA_NAME
>>             && POINTER_TYPE_P (TREE_TYPE (TMR_BASE (exp
>>
> Thanks, this patch works with trunk x86.
>
>> might help.  On the 4.5 branch you need to backport the various
>> changes to retain points-to info during IVOPTs (or use -fno-tree-
>> ivopts).
>
> Is this gigantic patch you referring to?

No, more like

2010-07-23  Richard Guenther  

PR tree-optimization/45037
* tree-ssa-loop-ivopts.c (copy_ref_info): Handle NULL base.

2010-07-05  Richard Guenther  

* tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Copy alias info.

2010-07-05  Richard Guenther  

* tree.c (reference_alias_ptr_type): New function.
* tree.h (reference_alias_ptr_type): Declare.
* tree-ssa-loop-ivopts.c (copy_ref_info): Restructure to
allow non-TARGET_MEM_REF new refs.
(rewrite_use_address): Pass old alias pointer type to create_mem_ref.
* tree-ssa-address.c (create_mem_ref_raw): Get alias pointer type.
Build a MEM_REF instead of a TARGET_MEM_REF if possible.
(create_mem_ref): Get alias pointer type.  Adjust calls to
create_mem_ref_raw.
(maybe_fold_tmr): Likewise.
* tree-flow.h (create_mem_ref): Adjust prototype.

2010-07-04  Richard Guenther  

PR tree-optimization/44479
* tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Avoid
extra SSA name copy statements which preserves points-to
information.
* tree-vect-data-refs.c (vect_create_addr_base_for_vector_ref):
Copy points-to information for all pointers.  Properly handle
MEM_REFs.
(vect_create_data_ref_ptr): Likewise.  Avoid extra SSA name
copy statements.
* Makefile.in (tree-ssa-loop-ivopts.o): Add tree-ssa-propagate.h
dependency.

2010-07-02  Richard Guenther  

* tree-ssa-structalias.c (pt_solution_set_var): New function.
* tree-ssa-alias.h (pt_solution_set_var): Declare.
* tree-ssa-loop-ivopts.c (copy_ref_info): Also copy or create
points-to information.

well - all the pieces that apply.  The above went in after the
gigantic patch you refered to which makes most pieces need
adjustments for the branch.

RIchard.


> 2010-07-01  Richard Guenther  
>
>        PR middle-end/42834
>        PR middle-end/44468
>        * doc/gimple.texi (is_gimple_mem_ref_addr): Document.
>        * doc/generic.texi (References to storage): Document MEM_REF.
>        * tree-pretty-print.c (dump_generic_node): Handle M

RE: SH optimized software floating point routines

[Naveen H. S]

Hi,

>> I've tested sh-softfp-20100718-2131 + sh-softfp-predicate-fix
>> on -m1, -m2, -m3, -m3 -ml, -m2a on sh-elf, sh4-linux and
>> sh64-linux  

The SH toolchain was built with the following patches and regression
is completed.
1. sh-softfp-20100718-2131
2. sh-softfp-predicate-fix
3. Patch by Kaz Kojima-san at following link
http://gcc.gnu.org/ml/gcc/2010-07/msg00352.html

However, there were some regressions compared to fresh toolchain.
The following list summarizes the regressions for each target.

m1, m2, m2a-nofpu 
gcc.dg/pr28796-2.c
gcc.dg/torture/type-generic-1.c

m2e, m3e, -m2a-single-only
gcc.c-torture/execute/ieee/fp-cmp-4l.c
gcc.c-torture/execute/ieee/fp-cmp-8l.c  
gcc.dg/builtins-43.c
gcc.dg/pr28796-2.c
gcc.dg/torture/type-generic-1.c

m3, m4-nofpu, m4-single-only, m4a-nofpu, m4a-single-only
gcc.c-torture/execute/2605-1.c (-O0)
gcc.c-torture/execute/20060420-1.c (-Os) 
gcc.c-torture/execute/loop-ivopts-1.c
gcc.c-torture/execute/pr39228.c(-O0) 
gcc.dg/pr28796-2.c
gcc.dg/torture/type-generic-1.c
gcc.dg/pr41963.c
c-c++-common/torture/complex-sign-mixed-mul.c
gcc.target/sh/sh4a-fprun.c

>> Now all test results look clean

Please let me know whether these regressions are known and okay?
OR
Am I missing something in the patch which solves them?

Thanks & Regards,
Naveen

Re: SH optimized software floating point routines

[Kaz Kojima]

"Naveen H. S"  wrote:
> The SH toolchain was built with the following patches and regression
> is completed.
> 1. sh-softfp-20100718-2131
> 2. sh-softfp-predicate-fix
> 3. Patch by Kaz Kojima-san at following link
> http://gcc.gnu.org/ml/gcc/2010-07/msg00352.html

Thanks for testing.

> However, there were some regressions compared to fresh toolchain.
> The following list summarizes the regressions for each target.
[snip]
>>> Now all test results look clean
> 
> Please let me know whether these regressions are known and okay?

"clean" might be a bad choice of words.  I meant that results
are expected i.e. regressions I saw are NaN issues we discussed
in the list.

Although your list of arches and regressions is different from
mine, some regressions you've caught

> gcc.c-torture/execute/2605-1.c (-O0)
> gcc.c-torture/execute/20060420-1.c (-Os) 
> gcc.c-torture/execute/loop-ivopts-1.c
> gcc.c-torture/execute/pr39228.c(-O0)
> gcc.dg/pr41963.c
> c-c++-common/torture/complex-sign-mixed-mul.c
> gcc.target/sh/sh4a-fprun.c

don't look like NaN issues and we should know what is going on
in these cases.

Regards,
kaz

Shouldn't alias_sets_conflict_p be replaced with rtx_refs_may_alias_p?

[Bingfeng Mei]

Hi,
alias_sets_conflict_p are still used in various places to determine
whether two memory accesses are aliased. It is based on unique set
number, which seems not correct with recent changes on alias
oracle. For example, in ddg.c cross-iteration memory dependence
is drawn by calling insn_alias_sets_conflict_p, which in turns calls
alias_sets_conflict_p and gets the wrong answer. Using 
rtx_refs_may_alias_p allow the ddg to be built correctly and our
modulo scheduler to succeed. 

Shouldn't alias_sets_conflict_p be replaced with rtx_refs_may_alias_p
everywhere? What's catch? 


Cheers,
Bingfeng 

Re: Shouldn't alias_sets_conflict_p be replaced with rtx_refs_may_alias_p?

[Richard Guenther]

On Wed, Aug 4, 2010 at 2:02 PM, Bingfeng Mei  wrote:
> Hi,
> alias_sets_conflict_p are still used in various places to determine
> whether two memory accesses are aliased. It is based on unique set
> number, which seems not correct with recent changes on alias
> oracle. For example, in ddg.c cross-iteration memory dependence
> is drawn by calling insn_alias_sets_conflict_p, which in turns calls
> alias_sets_conflict_p and gets the wrong answer. Using
> rtx_refs_may_alias_p allow the ddg to be built correctly and our
> modulo scheduler to succeed.
>
> Shouldn't alias_sets_conflict_p be replaced with rtx_refs_may_alias_p
> everywhere? What's catch?

Extra compile-time and lack of testing I suppose.

Richard.

>
> Cheers,
> Bingfeng
>
>

Thread model: simple and C

[Marcos Dione]

first of all: I'm not subscribed to gcc's ML, so please cc: in any answers.

I'm cross-compiling an application to a platform whose SDK brings a gcc 
which reports 'Thread model: single'. even so, the platform implements a 
rudimentary thread support (a subset of posix), which leads me to think 
that it should be possible to use it in C programs.

why? because the only reference to Thread model I could find in gcc's 
doc is in libstdc++'s manual[1] and no other useful reference about simple 
thread model.

in particular, my main concern is not about our own program but a library 
we use, namely, Boehm's GC, which I see is included in gcc's code. I already 
asked Boehm itself (via the GC's ML[2]) but he's not sure what are the 
implications.

so, in short: does a simple Thread model have any impact on C-only 
programs that could use threads? in particular, how it does impact 
Boehm's GC usage in a C-only program? if the impact is negative, would 
you say that the original gcc is compiled with the wrong flags, given that 
there is a bit of pthreads implementation in the platform?

--
[1] http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html

[2] 
http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3680
-- 
Lic. Marcos Dione
Engineer Expert - Hop Project
http://hop.inria.fr/
INRIA Sophia Antipolis - Méditerranée
Phone: +33 (0)4 92 38 79 67

Re: GFDL/GPL issues

[Diego Novillo]

On 10-08-04 03:22 , Benjamin Kosnik wrote:



The FSF's responsibility for legal matters under the Mission
Statement comes with a duty to the developers not to get in the way
of the "Patches will be considered equally based on their technical
merits." principle from the Mission Statement.  The FSF is failing in
its duty to what was traditionally considered one of its flagship
projects.  If this has not been brought up with the full board of
directors of the FSF, it is time that it was so brought up.  Richard
may have the right point in
  regarding problems
with FSF leadership.  I support the FSF's various campaigns for
freedom and against closed devices and systems, but I get the
impression that they have been losing sight of the needs of their
traditional flagship projects lately.


I agree. SC, please escalate.


Agreed.  This is surreal and counterproductive.


Diego.

ira-assert keeps turning up

[Paulo J. Matos]

Hi,

I am looking at gcc-4.4.4, and porting a backend into this version.
However, what didn't break in previous 4.2 / 4.3, now keeps breaking
in both CB and priority algorithms.
Line 1792 of ira.c keeps breaking. For context here's the function:
1783 static void
1784 setup_preferred_alternate_classes_for_new_pseudos (int start)
1785 {
1786   int i, old_regno;
1787   int max_regno = max_reg_num ();
1788
1789   for (i = start; i < max_regno; i++)
1790 {
1791   old_regno = ORIGINAL_REGNO (regno_reg_rtx[i]);
1792   ira_assert (i != old_regno);
1793   setup_reg_classes (i, reg_preferred_class (old_regno),
1794  reg_alternate_class (old_regno));
1795   if (internal_flag_ira_verbose > 2 && ira_dump_file != NULL)
1796 fprintf (ira_dump_file,
1797  "New r%d: setting preferred %s, alternative
%s\n",
1798  i, reg_class_names[reg_preferred_class
(old_regno)],
1799  reg_class_names[reg_alternate_class
(old_regno)]);
1800 }
1801 }

Now, with CB trying several IRA_COVER_CLASSES config changes the place
where it breaks but it always breaks on my tests and always on this
line. priority breaks also on this line no matter what. Now, since it
is always this line that's breaking stuff I am wondering if there's
anything special about it that I didn't understand yet.

Any tips on what might be happening for this assert to break the
register allocator?

Cheers,
-- 
PMatos

Re: Shouldn't alias_sets_conflict_p be replaced with rtx_refs_may_alias_p?

[Steven Bosscher]

On Wed, Aug 4, 2010 at 2:02 PM, Bingfeng Mei  wrote:
> Hi,
> alias_sets_conflict_p are still used in various places to determine
> whether two memory accesses are aliased. It is based on unique set
> number, which seems not correct with recent changes on alias
> oracle. For example, in ddg.c cross-iteration memory dependence
> is drawn by calling insn_alias_sets_conflict_p, which in turns calls
> alias_sets_conflict_p and gets the wrong answer.

Just to clarify: When you say "wrong", do you mean "incorrect" or "too
conservative"?

Ciao!
Steven

Re: Shouldn't alias_sets_conflict_p be replaced with rtx_refs_may_alias_p?

[Richard Guenther]

On Wed, Aug 4, 2010 at 5:26 PM, Steven Bosscher  wrote:
> On Wed, Aug 4, 2010 at 2:02 PM, Bingfeng Mei  wrote:
>> Hi,
>> alias_sets_conflict_p are still used in various places to determine
>> whether two memory accesses are aliased. It is based on unique set
>> number, which seems not correct with recent changes on alias
>> oracle. For example, in ddg.c cross-iteration memory dependence
>> is drawn by calling insn_alias_sets_conflict_p, which in turns calls
>> alias_sets_conflict_p and gets the wrong answer.
>
> Just to clarify: When you say "wrong", do you mean "incorrect" or "too
> conservative"?

Mostly the latter, though also the former if not doing classical
transformations only (hoisting loads over stores or sinking stores
over loads).

Richard.

> Ciao!
> Steven
>

RE: Shouldn't alias_sets_conflict_p be replaced with rtx_refs_may_alias_p?

[Bingfeng Mei]

For example, alias_sets_conflict_p will say the a[i]
is aliased with b[i]. It is both conservative and wrong. 

void foo(int * restrict a, int * restrict b, int n)
{
  int i;
  for(i = 0; i < n; i++)
  {
a[i] = b[i] * 100;
  }
}

Bingfeng
> -Original Message-
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: 04 August 2010 16:26
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; Richard Guenther
> Subject: Re: Shouldn't alias_sets_conflict_p be replaced with
> rtx_refs_may_alias_p?
> 
> On Wed, Aug 4, 2010 at 2:02 PM, Bingfeng Mei  wrote:
> > Hi,
> > alias_sets_conflict_p are still used in various places to determine
> > whether two memory accesses are aliased. It is based on unique set
> > number, which seems not correct with recent changes on alias
> > oracle. For example, in ddg.c cross-iteration memory dependence
> > is drawn by calling insn_alias_sets_conflict_p, which in turns calls
> > alias_sets_conflict_p and gets the wrong answer.
> 
> Just to clarify: When you say "wrong", do you mean "incorrect" or "too
> conservative"?
> 
> Ciao!
> Steven

Parma Polyhedra Library 0.11

[Roberto Bagnara]

The core development team is very pleased to announce the availability
of PPL 0.11, a new release of the Parma Polyhedra Library.

This release has many new features, some of which developed in strict
coordination with the people behind GCC/Graphite.  The main novelties
are:

- a class PIP_Problem that provides a Parametric Integer Programming
  problem solver;

- "deterministic" timeout computation facilities;

- support for termination analysis via the automatic synthesis of
  linear ranking functions;

- support for approximating computations involving (bounded)
  machine integers.

This release includes several other enhancements, speed improvements
and some bug fixes.  The precise list of user-visible changes is
available at
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11/NEWS .
For more information, please come and visit the PPL web site at

   http://www.cs.unipr.it/ppl/

On behalf of all the past and present developers listed at
http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,

Roberto BagnaraPatricia M. HillEnea Zaffanella

  Applied Formal Methods Laboratory
  Department of Mathematics
  University of Parma, Italy

--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: GFDL/GPL issues

[Joe Buck]

On Wed, Aug 04, 2010 at 12:21:05AM -0700, Benjamin Kosnik wrote:
> 
> > So one way to move forward is to effectively have two manuals, one
> > containing traditional user-written text (GFDL), the other containing
> > generated text (GPL).  If you print it out as a book, the generated
> > part would just appear as an appendix to the manual, it's "mere
> > aggregation".
> 
> This is not acceptable to me. 
> 
> You have just described the status quo,
> what we are already doing. It is very difficult to link api
> references to manual references in two separate documents. What I want
> to do is full integration, and not be forced into these aggregations.
> 
> And I am being denied. 

You are being denied by RMS.  He controls the copyright, the SC has no
legal say, and he's stubborn as hell.

Re: Parma Polyhedra Library 0.11

[Justin P. Mattock]

On 08/04/2010 08:43 AM, Roberto Bagnara wrote:

The core development team is very pleased to announce the availability
of PPL 0.11, a new release of the Parma Polyhedra Library.

This release has many new features, some of which developed in strict
coordination with the people behind GCC/Graphite. The main novelties
are:

- a class PIP_Problem that provides a Parametric Integer Programming
problem solver;

- "deterministic" timeout computation facilities;

- support for termination analysis via the automatic synthesis of
linear ranking functions;

- support for approximating computations involving (bounded)
machine integers.

This release includes several other enhancements, speed improvements
and some bug fixes. The precise list of user-visible changes is
available at
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11/NEWS .
For more information, please come and visit the PPL web site at

http://www.cs.unipr.it/ppl/

On behalf of all the past and present developers listed at
http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,

Roberto Bagnara Patricia M. Hill Enea Zaffanella

Applied Formal Methods Laboratory
Department of Mathematics
University of Parma, Italy



cool.. just downloaded it.. just curious if I need to install ppl and 
cloog on the system then build gcc? right now with the latest snapshot 
of gcc, mpfr gmp are in the source tree and build fine but as soon as I 
add cloog ppl and mpc I crapp out at ppl telling me it cant find gmp


keep in mind this is my first attempt to build gcc with all these 
packages in the source tree of gcc rather than building them separately.


Justin P. Mattock

Re: gcc-4.4-20100803 is now available

[Mihai Donțu]

On Wednesday 04 August 2010 01:53:56 gccad...@gcc.gnu.org wrote:
> Snapshot gcc-4.4-20100803 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100803/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
> 
> This snapshot has been generated from the GCC 4.4 SVN branch
> with the following options:
> svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 162848
> 
> You'll find:
> 
> gcc-4.4-20100803.tar.bz2  Complete GCC (includes all of below)
> 
> gcc-core-4.4-20100803.tar.bz2 C front end and core compiler
> 
> gcc-ada-4.4-20100803.tar.bz2  Ada front end and runtime
> 
> gcc-fortran-4.4-20100803.tar.bz2  Fortran front end and runtime
> 
> gcc-g++-4.4-20100803.tar.bz2  C++ front end and runtime
> 
> gcc-java-4.4-20100803.tar.bz2 Java front end and runtime
> 
> gcc-objc-4.4-20100803.tar.bz2 Objective-C front end and runtime
> 
> gcc-testsuite-4.4-20100803.tar.bz2The GCC testsuite
> 
> Diffs from 4.4-20100727 are available in the diffs/ subdirectory.
> 
> When a particular snapshot is ready for public consumption the LATEST-4.4
> 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.

Is there a page somewhere which details the list of changes made to gcc for 
every release? I don't seem to be able to find it anywhere on gcc.gnu.org. I'm 
not referring to things like http://gcc.gnu.org/gcc-4.5/changes.html but 
something more like:
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.34.2

Thanks,

-- 
Mihai Donțu

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   > > So one way to move forward is to effectively have two manuals,
   > > one containing traditional user-written text (GFDL), the other
   > > containing generated text (GPL).  If you print it out as a
   > > book, the generated part would just appear as an appendix to
   > > the manual, it's "mere aggregation".
   > 
   > This is not acceptable to me. 
   > 
   > You have just described the status quo, what we are already
   > doing. It is very difficult to link api references to manual
   > references in two separate documents. What I want to do is full
   > integration, and not be forced into these aggregations.
   > 
   > And I am being denied.

   You are being denied by RMS.  He controls the copyright, the SC has
   no legal say, and he's stubborn as hell.

When presented with weak arguments, then yes he will be stubborn but
rightly so.  

I don't see what the problem is with two manuals, from a users
perspective I actually prefer that and doing cross referencing between
manuals in texinfo is easy.

Re: GFDL/GPL issues

[Paolo Bonzini]

On 08/04/2010 07:34 PM, Alfred M. Szmidt wrote:

>  >  So one way to move forward is to effectively have two manuals,
>  >  one containing traditional user-written text (GFDL), the other
>  >  containing generated text (GPL).  If you print it out as a
>  >  book, the generated part would just appear as an appendix to
>  >  the manual, it's "mere aggregation".
>
>  This is not acceptable to me.
>
>  You have just described the status quo, what we are already
>  doing. It is very difficult to link api references to manual
>  references in two separate documents. What I want to do is full
>  integration, and not be forced into these aggregations.
>
>  And I am being denied.

You are being denied by RMS.  He controls the copyright, the SC has
no legal say, and he's stubborn as hell.

When presented with weak arguments, then yes he will be stubborn but
rightly so.

I don't see what the problem is with two manuals, from a users
perspective I actually prefer that and doing cross referencing between
manuals in texinfo is easy.


You probably haven't read this thread fully, or you wouldn't imply that 
GCC should have an "options manual" separate from the user's manual.


By the way, it's not an insult to qualify RMS's attitude as "stubborn". 
 And even if it was, he doesn't need a public defender.


Paolo

Re: Thread model: simple and C

[Jonathan Wakely]

On 4 August 2010 13:56, Marcos Dione wrote:
>
>    I'm cross-compiling an application to a platform whose SDK brings a gcc
> which reports 'Thread model: single'. even so, the platform implements a
> rudimentary thread support (a subset of posix), which leads me to think
> that it should be possible to use it in C programs.
>
>    why? because the only reference to Thread model I could find in gcc's
> doc is in libstdc++'s manual[1] and no other useful reference about simple
> thread model.

Do you man single, not simple?
See the docs for --enable-threads at
http://gcc.gnu.org/install/configure.html

>    so, in short: does a simple Thread model have any impact on C-only
> programs that could use threads? in particular, how it does impact
> Boehm's GC usage in a C-only program? if the impact is negative, would

IIUC GCC's thread model doesn't affect how you use threads in your own
program, only how GCC's libraries (e.g. the C++ and ObjC runtimes) use
threads.

> you say that the original gcc is compiled with the wrong flags, given that
> there is a bit of pthreads implementation in the platform?

If the configure command for GCC doesn't show --enable-threads=no or
--disable-threads then it probably means that configure tried to find
the functions needed for --enable-threads=posix and failed, so the
rudimentary support is not enough.

Re: GFDL/GPL issues

[Joe Buck]

On Wed, Aug 04, 2010 at 10:34:51AM -0700, Alfred M. Szmidt wrote:
>You are being denied by RMS.  He controls the copyright, the SC has
>no legal say, and he's stubborn as hell.
> 
> When presented with weak arguments, then yes he will be stubborn but
> rightly so.  
> 
> I don't see what the problem is with two manuals, from a users
> perspective I actually prefer that and doing cross referencing between
> manuals in texinfo is easy.

OK, let's say Don Knuth decides he wants to spend his retirement
contributing to GNU.  RMS is effectively saying that "literate
programming" is banned from the GNU project and Knuth can just go away if
he doesn't like it (and yes, requiring GFDL for documentation and GPL for
code is equivalent to banning literate programming).  This is an
anti-software-freedom argument, an attempt by one man to impose his
personal taste.

For a class library, documentation generators are really the only
reasonable way to provide a maintainable manual.  You need to make
sure that every inheritance relationship is described correctly, and
you need to make sure that, as interfaces change, they are described
consistently and accurately.  The best way to achieve that is to
auto-generate the information.  Sure, as a *user* it works equally
well for you if the maintainers have worked three times as hard to
do by hand what could be done by computer, but there's a high cost.

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   You probably haven't read this thread fully, or you wouldn't imply
   that GCC should have an "options manual" separate from the user's
   manual.

I have read the thread in full, and I do not see the problem with
keeping that info in a seperate manual; GCC has so many options for
various architectures and systems that I think it makes technical
sense to have a "Invoking GCC" manual.

Re: GFDL/GPL issues

[Paolo Bonzini]

On 08/04/2010 08:48 PM, Alfred M. Szmidt wrote:

You probably haven't read this thread fully, or you wouldn't imply
that GCC should have an "options manual" separate from the user's
manual.

I have read the thread in full, and I do not see the problem with
keeping that info in a seperate manual; GCC has so many options for
various architectures and systems that I think it makes technical
sense to have a "Invoking GCC" manual.


The limitation would also apply to target-independent options.

Paolo

Re: Parma Polyhedra Library 0.11

[Jack Howarth]

On Wed, Aug 04, 2010 at 05:43:33PM +0200, Roberto Bagnara wrote:
> The core development team is very pleased to announce the availability
> of PPL 0.11, a new release of the Parma Polyhedra Library.
>
> This release has many new features, some of which developed in strict
> coordination with the people behind GCC/Graphite.  The main novelties
> are:
>
> - a class PIP_Problem that provides a Parametric Integer Programming
>   problem solver;
>
> - "deterministic" timeout computation facilities;
>
> - support for termination analysis via the automatic synthesis of
>   linear ranking functions;
>
> - support for approximating computations involving (bounded)
>   machine integers.

Roberto,
   I noticed that this release bumps the actual soversion numbers so
that we have libppl.9.dylib, libpwl.5.dylib and libppl_c.4.dylib rather 
than libppl.7.dylib, libpwl.4.dylib and libppl_c.2.dylib from the
0.10.x releases. So I assume we now need legacy ppl packages for
the older cloog library builds and will have to bump the soversion
on any newer cloog that builds against ppl 0.11, right?
   Jack
>
> This release includes several other enhancements, speed improvements
> and some bug fixes.  The precise list of user-visible changes is
> available at
> http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11/NEWS .
> For more information, please come and visit the PPL web site at
>
>http://www.cs.unipr.it/ppl/
>
> On behalf of all the past and present developers listed at
> http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,
>
> Roberto BagnaraPatricia M. HillEnea Zaffanella
>
>   Applied Formal Methods Laboratory
>   Department of Mathematics
>   University of Parma, Italy
>
> -- 
> Prof. Roberto Bagnara
> Applied Formal Methods Laboratory
> Department of Mathematics, University of Parma, Italy
> http://www.cs.unipr.it/~bagnara/
> mailto:bagn...@cs.unipr.it
>

Re: GFDL/GPL issues

[Jonathan Wakely]

On 4 August 2010 19:48, Alfred M. Szmidt wrote:
>
> I have read the thread in full, and I do not see the problem with
> keeping that info in a seperate manual; GCC has so many options for
> various architectures and systems that I think it makes technical
> sense to have a "Invoking GCC" manual.

And what about libstdc++ API docs, which are currently quite difficult
to cross-reference with the libstdc++ manual, and cannot be included
in it?  The API docs come from C++ sources and the manual from docbook
sources, so texinfo has nothing to do with it.

Re: GFDL/GPL issues

[Brian Makin]

I'd hate to see generated documented discounted so quickly.  
Especially if the alternative is no documentation.

I'd note the QT docs as a great example of embedded 
comments and auto generated documentation done very well.



  

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   > I have read the thread in full, and I do not see the problem with
   > keeping that info in a seperate manual; GCC has so many options
   > for various architectures and systems that I think it makes
   > technical sense to have a "Invoking GCC" manual.

   And what about libstdc++ API docs, which are currently quite
   difficult to cross-reference with the libstdc++ manual, and cannot
   be included in it?  The API docs come from C++ sources and the
   manual from docbook sources, so texinfo has nothing to do with it.

For a API reference listing document, it would make more sense to
license the work under the GPL, is that possible?  

There is no rule in the GNU project that all types of documentation
must be licensed under the GFDL.  Sometimes it makes sense, good
examples are the gccint, gcc and the emacs manual, and sometimes it
might not like for API reference listings.

Re: GFDL/GPL issues

[Alfred M. Szmidt]

   >You are being denied by RMS.  He controls the copyright, the SC has
   >no legal say, and he's stubborn as hell.
   > 
   > When presented with weak arguments, then yes he will be stubborn
   > but rightly so.
   > 
   > I don't see what the problem is with two manuals, from a users
   > perspective I actually prefer that and doing cross referencing
   > between manuals in texinfo is easy.

   OK, let's say Don Knuth decides he wants to spend his retirement
   contributing to GNU.  RMS is effectively saying that "literate
   programming" is banned from the GNU project and Knuth can just go
   away if he doesn't like it (and yes, requiring GFDL for
   documentation and GPL for code is equivalent to banning literate
   programming).  This is an anti-software-freedom argument, an
   attempt by one man to impose his personal taste.

The GFDL isn't required for all types of documentation, sometimes it
makes sense to use the GFDL for a manual (for example, the emacs
manual) sometimes it might not.  For literate programs, the comments
are as much part of the program as the code, it would make little
sense to require the GFDL for the documentation part of that program.
Infact, the literate programs that are part of the GNU project are
simply licensed under the GPL.  So Knuth is most free to join.  :-)

For some manuals, like the libstdc++ manual as someone mentioned,
maybe relicensing it under the GPL makes the most sense, since it is
mostly a API reference listing.  For other manuals, that contain
little auto-generated text, like the GCC manual, or the GCC Internals
manual, the GFDL makes more sense.

Painting all documentation under a single brush is a huge mistake,
sometimes the GFDL makes sense, sometimes it doesn't.  And one should
look at each specific case separately and make a decision based on
that.

Re: GFDL/GPL issues

[Diego Novillo]

On 10-08-04 16:03 , Alfred M. Szmidt wrote:


There is no rule in the GNU project that all types of documentation
must be licensed under the GFDL.  Sometimes it makes sense, good
examples are the gccint


I don't think we want gccint to be under the GFDL.  This is the main 
part of the documentation that I would like to have mostly generated out 
of the code.



Diego.

Re: some integer undefined behaviors in gcc

[Eric Botcazou]

> I ran gcc 162830 on x86 under a tool that checks for integer undefined
> behaviors.  The attached error messages show up when running "make
> check" and when recompiling gcc.
>
> Each line in the attachment is an error message giving the problematic
> operator, its srcloc, the types of its operands, and examples of
> offending values.

Thanks for doing this.  I've attached a patch that should fix rtlanal.c.

> Let me know if more detail is needed or if it would be better for me to
> file all 71 bug reports.

I think the messages are clear enough.  You should probably wait a few days to 
let people comment and/or fix, and then file PRs.  1 per file seems to be the 
right granularity.


* rtlanal.c (nonzero_bits1): Use unsigned HOST_WIDE_INT in all mask
computations.  Fix formatting issues.


-- 
Eric Botcazou
Index: rtlanal.c
===
--- rtlanal.c	(revision 162622)
+++ rtlanal.c	(working copy)
@@ -3803,12 +3803,14 @@ nonzero_bits1 (const_rtx x, enum machine
 case CONST_INT:
 #ifdef SHORT_IMMEDIATES_SIGN_EXTEND
   /* If X is negative in MODE, sign-extend the value.  */
-  if (INTVAL (x) > 0 && mode_width < BITS_PER_WORD
-	  && 0 != (INTVAL (x) & ((HOST_WIDE_INT) 1 << (mode_width - 1
-	return (INTVAL (x) | ((HOST_WIDE_INT) (-1) << mode_width));
+  if (INTVAL (x) > 0
+	  && mode_width < BITS_PER_WORD
+	  && (UINTVAL (x) & ((unsigned HOST_WIDE_INT) 1 << (mode_width - 1)))
+	 != 0)
+	return UINTVAL (x) | ((unsigned HOST_WIDE_INT) (-1) << mode_width);
 #endif
 
-  return INTVAL (x);
+  return UINTVAL (x);
 
 case MEM:
 #ifdef LOAD_EXTEND_OP
@@ -3885,7 +3887,7 @@ nonzero_bits1 (const_rtx x, enum machine
 	{
 	  inner_nz &= GET_MODE_MASK (GET_MODE (XEXP (x, 0)));
 	  if (inner_nz
-	  & (((HOST_WIDE_INT) 1
+	  & (((unsigned HOST_WIDE_INT) 1
 		  << (GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0))) - 1
 	inner_nz |= (GET_MODE_MASK (mode)
 			 & ~GET_MODE_MASK (GET_MODE (XEXP (x, 0;
@@ -3904,9 +3906,9 @@ nonzero_bits1 (const_rtx x, enum machine
 case XOR:   case IOR:
 case UMIN:  case UMAX:  case SMIN:  case SMAX:
   {
-	unsigned HOST_WIDE_INT nonzero0 =
-	  cached_nonzero_bits (XEXP (x, 0), mode,
-			   known_x, known_mode, known_ret);
+	unsigned HOST_WIDE_INT nonzero0
+	   = cached_nonzero_bits (XEXP (x, 0), mode,
+  known_x, known_mode, known_ret);
 
 	/* Don't call nonzero_bits for the second time if it cannot change
 	   anything.  */
@@ -3926,21 +3928,21 @@ nonzero_bits1 (const_rtx x, enum machine
 	 computing the width (position of the highest-order nonzero bit)
 	 and the number of low-order zero bits for each value.  */
   {
-	unsigned HOST_WIDE_INT nz0 =
-	  cached_nonzero_bits (XEXP (x, 0), mode,
-			   known_x, known_mode, known_ret);
-	unsigned HOST_WIDE_INT nz1 =
-	  cached_nonzero_bits (XEXP (x, 1), mode,
-			   known_x, known_mode, known_ret);
+	unsigned HOST_WIDE_INT nz0
+	  = cached_nonzero_bits (XEXP (x, 0), mode,
+ known_x, known_mode, known_ret);
+	unsigned HOST_WIDE_INT nz1
+	  = cached_nonzero_bits (XEXP (x, 1), mode,
+ known_x, known_mode, known_ret);
 	int sign_index = GET_MODE_BITSIZE (GET_MODE (x)) - 1;
 	int width0 = floor_log2 (nz0) + 1;
 	int width1 = floor_log2 (nz1) + 1;
 	int low0 = floor_log2 (nz0 & -nz0);
 	int low1 = floor_log2 (nz1 & -nz1);
-	HOST_WIDE_INT op0_maybe_minusp
-	  = (nz0 & ((HOST_WIDE_INT) 1 << sign_index));
-	HOST_WIDE_INT op1_maybe_minusp
-	  = (nz1 & ((HOST_WIDE_INT) 1 << sign_index));
+	unsigned HOST_WIDE_INT op0_maybe_minusp
+	  = nz0 & ((unsigned HOST_WIDE_INT) 1 << sign_index);
+	unsigned HOST_WIDE_INT op1_maybe_minusp
+	  = nz1 & ((unsigned HOST_WIDE_INT) 1 << sign_index);
 	unsigned int result_width = mode_width;
 	int result_low = 0;
 
@@ -3960,7 +3962,7 @@ nonzero_bits1 (const_rtx x, enum machine
 	  case DIV:
 	if (width1 == 0)
 	  break;
-	if (! op0_maybe_minusp && ! op1_maybe_minusp)
+	if (!op0_maybe_minusp && !op1_maybe_minusp)
 	  result_width = width0;
 	break;
 	  case UDIV:
@@ -3971,7 +3973,7 @@ nonzero_bits1 (const_rtx x, enum machine
 	  case MOD:
 	if (width1 == 0)
 	  break;
-	if (! op0_maybe_minusp && ! op1_maybe_minusp)
+	if (!op0_maybe_minusp && !op1_maybe_minusp)
 	  result_width = MIN (width0, width1);
 	result_low = MIN (low0, low1);
 	break;
@@ -3986,10 +3988,10 @@ nonzero_bits1 (const_rtx x, enum machine
 	  }
 
 	if (result_width < mode_width)
-	  nonzero &= ((HOST_WIDE_INT) 1 << result_width) - 1;
+	  nonzero &= ((unsigned HOST_WIDE_INT) 1 << result_width) - 1;
 
 	if (result_low > 0)
-	  nonzero &= ~(((HOST_WIDE_INT) 1 << result_low) - 1);
+	  nonzero &= ~(((unsigned HOST_WIDE_INT) 1 << result_low) - 1);
 
 #ifdef POINTERS_EXTEND_UNSIGNED
 	/* If pointers extend unsigned and this is an addition or subtraction
@@ -4010,7 +4012,7 @@ nonzero_bits1 (const_rtx x, enum machine
 case ZERO_EXTRACT:
   if (CONST_INT_P (XE

Re: GFDL/GPL issues

[Richard Guenther]

On Wed, Aug 4, 2010 at 10:03 PM, Alfred M. Szmidt  wrote:
>   > I have read the thread in full, and I do not see the problem with
>   > keeping that info in a seperate manual; GCC has so many options
>   > for various architectures and systems that I think it makes
>   > technical sense to have a "Invoking GCC" manual.
>
>   And what about libstdc++ API docs, which are currently quite
>   difficult to cross-reference with the libstdc++ manual, and cannot
>   be included in it?  The API docs come from C++ sources and the
>   manual from docbook sources, so texinfo has nothing to do with it.
>
> For a API reference listing document, it would make more sense to
> license the work under the GPL, is that possible?
>
> There is no rule in the GNU project that all types of documentation
> must be licensed under the GFDL.  Sometimes it makes sense, good
> examples are the gccint, gcc and the emacs manual, and sometimes it
> might not like for API reference listings.

I can't see how the GFDL "makes sense" for anything.

Richard.

Re: some integer undefined behaviors in gcc

[John Regehr]

I think the messages are clear enough.  You should probably wait a few days to
let people comment and/or fix, and then file PRs.  1 per file seems to be the
right granularity.


Thanks Eric, that's what I'll do.

John

Re: GFDL/GPL issues

[Paolo Bonzini]

On 08/04/2010 10:52 PM, Richard Guenther wrote:

On Wed, Aug 4, 2010 at 10:03 PM, Alfred M. Szmidt  wrote:

   >  I have read the thread in full, and I do not see the problem with
   >  keeping that info in a seperate manual; GCC has so many options
   >  for various architectures and systems that I think it makes
   >  technical sense to have a "Invoking GCC" manual.

   And what about libstdc++ API docs, which are currently quite
   difficult to cross-reference with the libstdc++ manual, and cannot
   be included in it?  The API docs come from C++ sources and the
   manual from docbook sources, so texinfo has nothing to do with it.

For a API reference listing document, it would make more sense to
license the work under the GPL, is that possible?

There is no rule in the GNU project that all types of documentation
must be licensed under the GFDL.  Sometimes it makes sense, good
examples are the gccint, gcc and the emacs manual, and sometimes it
might not like for API reference listings.


I can't see how the GFDL "makes sense" for anything.


Actually, I do see the point in the Front/Back cover texts.  A manual is 
not a program, and those are not the same thing as the BSD advertising 
clause.  Invariant Sections are debatable but we all know why they exist.


However, until there is a possibility to relicense anything GPL->GFDL I 
cannot disagree.  In fact, since the GFDL is more restrictive, it is the 
same thing as the Affero GPL.


Paolo

Re: GFDL/GPL issues

[Joe Buck]

On Wed, Aug 04, 2010 at 02:12:18PM -0700, Paolo Bonzini wrote:
> However, until there is a possibility to relicense anything GPL->GFDL I 
> cannot disagree.  In fact, since the GFDL is more restrictive, it is the 
> same thing as the Affero GPL.

No, because there is explicit language in the Affero GPL and GPL3 to
prevent license incompatibility.

Re: GFDL/GPL issues

[Jonathan Wakely]

On 4 August 2010 21:03, Alfred M. Szmidt  wrote:
>   > I have read the thread in full, and I do not see the problem with
>   > keeping that info in a seperate manual; GCC has so many options
>   > for various architectures and systems that I think it makes
>   > technical sense to have a "Invoking GCC" manual.
>
>   And what about libstdc++ API docs, which are currently quite
>   difficult to cross-reference with the libstdc++ manual, and cannot
>   be included in it?  The API docs come from C++ sources and the
>   manual from docbook sources, so texinfo has nothing to do with it.
>
> For a API reference listing document, it would make more sense to
> license the work under the GPL, is that possible?

Possible? It's required, because it's generated from C++ sources
covered by the GPL. What makes you think making the API reference GPL
would help?  The manual is GFDL. So they can't be combined.  That's a
problem.

The documentation I write for the libstdc++ manual and the
documentation I  write for libstdc++ API reference cannot be combined,
or merged, or derived from each other.

Take it from someone who actually does write the stuff: it's annoying.

Re: GFDL/GPL issues

[Paolo Bonzini]

On 08/04/2010 11:52 PM, Joe Buck wrote:

On Wed, Aug 04, 2010 at 02:12:18PM -0700, Paolo Bonzini wrote:

However, until there is a possibility to relicense anything GPL->GFDL I
cannot disagree.  In fact, since the GFDL is more restrictive, it is the
same thing as the Affero GPL.


No, because there is explicit language in the Affero GPL and GPL3 to
prevent license incompatibility.


I know, I'm saying that it's not something unheard of to make the GPL 
compatible with a more restrictive license if there are good reasons to 
do so.


Paolo

Re: Parma Polyhedra Library 0.11

[Dennis Clarke]

>> Roberto Bagnara Patricia M. Hill Enea Zaffanella
>>
>> Applied Formal Methods Laboratory
>> Department of Mathematics
>> University of Parma, Italy
>>
>
> cool.. just downloaded it.. just curious if I need to install ppl and
> cloog on the system then build gcc? right now with the latest snapshot
> of gcc, mpfr gmp are in the source tree and build fine but as soon as I
> add cloog ppl and mpc I crapp out at ppl telling me it cant find gmp
>
> keep in mind this is my first attempt to build gcc with all these
> packages in the source tree of gcc rather than building them separately.
>

On a number of occasions I have tried to build ppl and Cloog and watched
the process fail repeatedly.  I have yet to see it complete with any
degree of success.  Perhaps this is due to some strange issue with gmp and
mpfr header versions and a false error message about libgmp versions is
generally seen early in the build process.

If this fault in the ppl/cloog code has been fixed then I'll be quite glad
to see it. If not then I shall continue to work with GCC without either
ppl or cloog as their absence seems to not matter a bit.  This is entirely
based on my experiences within the Solaris world where we still have
issues with the GNU Binutils ld linker also.

-- 
Dennis

Re: Thread model: simple and C

[Marcos_David . Dione]

On Wed, August 4, 2010 8:45 pm, Jonathan Wakely wrote:
> On 4 August 2010 13:56, Marcos Dione wrote:
>>so, in short: does a simple Thread model have any impact on C-only
>> programs that could use threads? in particular, how it does impact
>> Boehm's GC usage in a C-only program? if the impact is negative, would
>
> IIUC GCC's thread model doesn't affect how you use threads in your own
> program, only how GCC's libraries (e.g. the C++ and ObjC runtimes) use
> threads.

so it is wrong that some projects (in particular, Boehm's GC) test
thread availability by looking at the output of 'gcc -v' because that
would be assuming that it will use the same libraries compiled along
with that gcc? in particular, this platform uses its own libc
implementation... also, you don't mention libc at all. is it different
with it? and last one: can anyone explain *how* it affects stdlibc++
and others?

-- 
Lic. Marcos Dione
Engineer Expert - Hop Project
http://hop.inria.fr/
INRIA Sophia Antipolis - Méditerranée
Phone: +33 (0)4 92 38 79 67

Re: Parma Polyhedra Library 0.11

[Justin P. Mattock]

On 08/04/2010 08:09 PM, Dennis Clarke wrote:



Roberto Bagnara Patricia M. Hill Enea Zaffanella

Applied Formal Methods Laboratory
Department of Mathematics
University of Parma, Italy



cool.. just downloaded it.. just curious if I need to install ppl and
cloog on the system then build gcc? right now with the latest snapshot
of gcc, mpfr gmp are in the source tree and build fine but as soon as I
add cloog ppl and mpc I crapp out at ppl telling me it cant find gmp

keep in mind this is my first attempt to build gcc with all these
packages in the source tree of gcc rather than building them separately.



On a number of occasions I have tried to build ppl and Cloog and watched
the process fail repeatedly.  I have yet to see it complete with any
degree of success.  Perhaps this is due to some strange issue with gmp and
mpfr header versions and a false error message about libgmp versions is
generally seen early in the build process.

If this fault in the ppl/cloog code has been fixed then I'll be quite glad
to see it. If not then I shall continue to work with GCC without either
ppl or cloog as their absence seems to not matter a bit.  This is entirely
based on my experiences within the Solaris world where we still have
issues with the GNU Binutils ld linker also.



yeah I ended up fussing around with previous versions but had no luck.
after looking through the gcc documentation(don't have the location off 
hand due to my frenzy for searching for results), but what I noticed is 
gmp, mpfr, and mpc can be put in the source tree.(only thing it had said 
with cloog and ppl was to use the --with-cloog/ppl switches).


After doing this my build went through and finished. Although seems gcc 
gets out of whack building a clfs system with two different versions of 
ppl/cloog(hosts system/new system etc..)
figured once im able to boot the fresh system I'll probably rebuild with 
ppl/cloog added in.


Justin P. Mattock

Re: Parma Polyhedra Library 0.11

[Roberto Bagnara]

On 08/04/10 20:58, Jack Howarth wrote:

On Wed, Aug 04, 2010 at 05:43:33PM +0200, Roberto Bagnara wrote:

The core development team is very pleased to announce the availability
of PPL 0.11, a new release of the Parma Polyhedra Library.

This release has many new features, some of which developed in strict
coordination with the people behind GCC/Graphite.  The main novelties
are:

- a class PIP_Problem that provides a Parametric Integer Programming
   problem solver;

- "deterministic" timeout computation facilities;

- support for termination analysis via the automatic synthesis of
   linear ranking functions;

- support for approximating computations involving (bounded)
   machine integers.


Roberto,
I noticed that this release bumps the actual soversion numbers so
that we have libppl.9.dylib, libpwl.5.dylib and libppl_c.4.dylib rather
than libppl.7.dylib, libpwl.4.dylib and libppl_c.2.dylib from the
0.10.x releases.


Hi Jack,

yes, the soversion numbers have been updated as needed
(this should not come as a surprise though).


So I assume we now need legacy ppl packages for
the older cloog library builds and will have to bump the soversion
on any newer cloog that builds against ppl 0.11, right?


I am not familiar enough with cloog to answer that.
What I can do is to recommend the use of PPL 0.11 instead
of PPL 0.10.* for the reasons explained in the NEWS file.
Cheers,

   Roberto

--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: Parma Polyhedra Library 0.11

[Roberto Bagnara]

On 08/05/10 05:09, Dennis Clarke wrote:

On a number of occasions I have tried to build ppl and Cloog and watched
the process fail repeatedly.  I have yet to see it complete with any
degree of success.  Perhaps this is due to some strange issue with gmp and
mpfr header versions and a false error message about libgmp versions is
generally seen early in the build process.

If this fault in the ppl/cloog code has been fixed then I'll be quite glad
to see it.


Hi Dennis,

I am not sure I understand the problems you are talking about
(a release candidate has been announced back in april and no
one reported this problem).
However, PPL 0.11 has new, simpler options to indicate the GMP
installation to use.  These are:

  --with-gmp-prefix[=DIR]  search for libgmp, libgmpxx in DIR/include and 
DIR/lib
  --with-gmp-build=DIRuse a non-installed build of GMP in DIR

If you run into problem, please file a bug at

https://www.cs.unipr.it/mantis/

Cheers,

   Roberto

--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it