Re: GFDL/GPL issues

[Miles Bader]

Robert Dewar  writes:
> I am actually a bit dubious about automatic extraction of documentation
> from code. The kind of thing you can get this way is in any case easily
> obtained by browsing the code.

Presumably it saves the effort of browsing the code, which is not a
small thing... (If I'm learning about an interface, I want a concise
introduction to the functions in it, and the work of finding the
appropriate functions in the appropriate location in the appropriate
file can be pretty annoying).

Moreover, it such extraction can to improve the source code for browsing
too:  if a function's header-comment were actually included in the
documentation (suitably massaged), that's all the more incentive to
write really good and clear function header-comments...

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

some integer undefined behaviors in gcc

[John Regehr]

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.

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

Thanks,

John Regehr





<../../gcc/alias.c, (1896:25)> : Op: +, Reason : Signed Addition Overflow, 
BINARY OPERATION: left (int32): -2147483647 right (int32): -4 
<../../gcc/alias.c, (322:44)> : Op: *, Reason : Signed Multiplication Overflow, 
BINARY OPERATION: left (int32): 39996 right (int32): 8 
<../../gcc/builtins.c, (7681:57)> : Op: -, Reason : Signed Subtraction 
Overflow, UNARY OPERATION: right (int32): -2147483648 
<../../gcc/builtins.c, (7699:57)> : Op: -, Reason : Signed Subtraction 
Overflow, UNARY OPERATION: right (int32): -2147483648 
<../../gcc/builtins.c, (7709:25)> : Op: -, Reason : Signed Subtraction 
Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/builtins.c, (7717:25)> : Op: -, Reason : Signed Subtraction 
Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/combine.c, (10620:62)> : Op: -, Reason : Signed Subtraction 
Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/combine.c, (10655:62)> : Op: -, Reason : Signed Subtraction 
Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/combine.c, (11350:54)> : Op: -, Reason : Signed Subtraction 
Overflow, BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/combine.c, (7047:63)> : Op: -, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/combine.c, (7205:54)> : Op: +, Reason : Signed Addition Overflow, 
BINARY OPERATION: left (int32): 2147483647 right (int32): 1 
<../../gcc/combine.c, (7838:22)> : Op: <<, Reason : Unsigned Left Shift Error: 
Right operand is negative or is greater than or equal to the width of the 
promoted left operand, BINARY OPERATION: left (uint32): 4294967295 right 
(uint32): 4294967291 
<../../gcc/config/i386/i386.c, (10253:10)> : Reason : The current index is 
greater than array size!
<../../gcc/config/i386/i386.c, (16316:17)> : Op: -, Reason : Signed Subtraction 
Overflow, BINARY OPERATION: left (int32): 0 right (int32): -2147483648 
<../../gcc/config/i386/i386.c, (16362:18)> : Op: -, Reason : Signed Subtraction 
Overflow, BINARY OPERATION: left (int32): 0 right (int32): -2147483648 
<../../gcc/config/i386/i386.c, (16473:11)> : Op: -, Reason : Signed Subtraction 
Overflow, UNARY OPERATION: right (int32): -2147483648 
<../../gcc/dbxout.c, (674:14)> : Op: -, Reason : Signed Subtraction Overflow, 
UNARY OPERATION: right (int32): -2147483648 
<../../gcc/double-int.c, (115:13)> : Op: -, Reason : Signed Subtraction 
Overflow, UNARY OPERATION: right (int32): -2147483648 
<../../gcc/double-int.c, (158:21)> : Op: *, Reason : Signed Multiplication 
Overflow, BINARY OPERATION: left (int32): 65535 right (int32): 65535 
<../../gcc/dse.c, (1636:28)> : Op: +, Reason : Signed Addition Overflow, BINARY 
OPERATION: left (int32): 2147483647 right (int32): 1 
<../../gcc/dwarf2out.c, (4753:46)> : Op: -, Reason : Signed Subtraction 
Overflow, UNARY OPERATION: right (int32): -2147483648 
<../../gcc/emit-rtl.c, (261:44)> : Op: *, Reason : Signed Multiplication 
Overflow, BINARY OPERATION: left (int32): 134217728 right (int32): 5 
<../../gcc/emit-rtl.c, (262:40)> : Op: *, Reason : Signed Multiplication 
Overflow, BINARY OPERATION: left (int32): 786432 right (int32): 250 
<../../gcc/expmed.c, (1092:13)> : Op: -, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/expmed.c, (2928:15)> : Op: -=, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/expmed.c, (3107:8)> : Op: -, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/expmed.c, (3707:52)> : Op: -, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/expmed.c, (3813:23)> : Op: -, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/expmed.c, (4151:12)> : Op: -, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/expmed.c, (949:38)> : Op: -, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/expmed.c, (954:42)> : Op: -, Reason : Signed Subtraction Overflow, 
BINARY OPERATION: left (int32): -2147483648 right (int32): 1 
<../../gcc/fold-const.c, (7127:33)> : Op: -, Reason : Signed Subtraction 
Overflow, UNARY OPERATION: right (int32): -2147483648 

gcc-4.4-20100803 is now available

[gccadmin]

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.

Re: GFDL/GPL issues

[Steven Bosscher]

On Tue, Aug 3, 2010 at 8:48 PM, Robert Dewar  wrote:
> Joe Buck 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".
>
> Does *anyone* print documentation "out as a book", this seems to me
> to be a completely obsolete concept. We used to print GNAT manuals
> for our customers, and ship them out in fancy boxes, and they looked
> nice, but were in reality useless, since they got so quickly outdated.
>
> We still format everything so that it can be printed out as books, but
> I doubt anyone does it, we certainly don't.

So perhaps the solution is to only make the manual available as
separate, linked HTML pages from now on?

The HTML pages would exist under different licenses. There is nothing
against pointing from GFDL-licensed web pages to GPL-ed web pages,
right? So we could have a GFDL "wrapper" manual, and parts of the
manual generated from GPL code as separate pages. There are
interesting problems (generating the index, for example, and a small
maintenance problem for the links between parts of the manual under
different license), but it would work around the license problems.

Feels like reductio ad absurdum, but that's really sort-of the point...

Ciao!
Steven

Re: GFDL/GPL issues

[Joseph S. Myers]

On Tue, 3 Aug 2010, Joe Buck wrote:

> On Mon, Aug 02, 2010 at 05:51:13PM -0700, Paul Koning wrote:
> > gcc and gccint docs are actually pretty reasonable.  (Certainly gccint is 
> > vastly better than some of its siblings, like gdbint.)  But very little of 
> > it is generated and very little of what comes to mind as possible subject 
> > matter is suitable for being generated.
> 
> RMS explicitly blessed generated cross-references and the like under the
> GPL.
> 
> 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".

The following is my personal opinion.

We want to move forward with the transition of target macros to hooks, we 
want to be able to convert each macro's documentation to hook 
documentation in target.def, we want to be able to move existing 
documentation for target hooks there, we want this to be possible for 
people maintaining their own non-FSF versions of GCC, we want to be able 
to do similar things with other sorts of documentation based solely on the 
technical judgement of relevant maintainers while keeping it properly 
integrated with related documentation, and we do not want this to need 
approval from RMS or the FSF for each patch.  Though it would probably be 
better for people doing hook conversion patches to include doc conversion 
and send them all to RMS rather than not including doc conversion and not 
pointing out to RMS every time such a patch runs into a legal issue.

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.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GFDL/GPL issues

[Robert Dewar]

Joe Buck 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".


Does *anyone* print documentation "out as a book", this seems to me
to be a completely obsolete concept. We used to print GNAT manuals
for our customers, and ship them out in fancy boxes, and they looked
nice, but were in reality useless, since they got so quickly outdated.

We still format everything so that it can be printed out as books, but
I doubt anyone does it, we certainly don't.

Re: GFDL/GPL issues

[Robert Dewar]

It's interesting to note that in the case of GNAT, we have no
licensing constraints on the documentation that would restrict
automatic generation, but we just don't do it.

The GNAT documentation is pretty complete, and certainly
gets a lot of attention and constant improvement, since
we regard it as being as important as the code.

In the case of interfaces to library routines, what we do
is to have fully commented Ada package specs that act as
both the documentation of the implementation interface and
as the user documentation (for an example, look at g-spipat.ads).
I can't see any value in duplicating this information elsewhere.

Re: GFDL/GPL issues

[Robert Dewar]

Diego Novillo wrote:


We are already having trouble keeping our documentation up-to-date.
Some of it is in such a poor shape as to be laughable.  Yes, it's
mostly our fault, but if we were able to generate documentation by
simply extracting it from the code.  Tools exist for this, and
properly maintained, they are very useful.


I am actually a bit dubious about automatic extraction of documentation
from code. The kind of thing you can get this way is in any case easily
obtained by browsing the code. All too often this kind of automatic
generation is just a way of satisfying the need for quantity of
documentation without enough attention to quality.

There are certainly exceptions to this, some of which have been
mentioned in this thread, but as a general mechanism, it is dangerous
in my opinion.

Ultimately the proper path to excellent documentation is to have
programmers who are as interested in generating documentation as
they are in writing code. If you don't have that, you will never
get really good documentation.

RE: Restrict qualifier still not working?

[Bingfeng Mei]

> -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? 
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 MEM_REF.
(print_call_name): Likewise.
* tree.c (recompute_tree_invariant_for_addr_expr): Handle MEM_REF.
(build_simple_mem_ref_loc): New function.
(mem_ref_offset): Likewise.
* tree.h (build_simple_mem_ref_loc): Declare.
(build_simple_mem_ref): Define.
(mem_ref_offset): Declare.
* fold-const.c: Include tree-flow.h.
(operand_equal_p): Handle MEM_REF.
(build_fold_addr_expr_with_type_loc): Likewise.
(fold_comparison): Likewise.
(fold_unary_loc): Fold
VIEW_CONVERT_EXPR > to MEM_REF .
(fold_binary_loc): Fold MEM[&MEM[p, CST1], CST2] to MEM[p, CST1 + CST2],
fold MEM[&a.b, CST2] to MEM[&a, offsetof (a, b) + CST2].
* tree-ssa-alias.c (ptr_deref_may_alias_decl_p): Handle MEM_REF.
(ptr_deref_may_alias_ref_p_1): Likewise.
(ao_ref_base_alias_set): Properly differentiate base object for
offset and TBAA.
(ao_ref_init_from_ptr_and_size): Use MEM_REF.
(indirect_ref_may_alias_decl_p): Handle MEM_REFs properly.
(indirect_refs_may_alias_p): Likewise.
(refs_may_alias_p_1): Likewise.  Remove pointer SSA name def
chasing code.
(ref_maybe_used_by_call_p_1): Handle MEM_REF.
(call_may_clobber_ref_p_1): Likewise.
* dwarf2out.c (loc_list_from_tree): Handle MEM_REF.
> 
> Thanks,
> Richard.

Re: Restrict qualifier still not working?

[Richard Guenther]

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

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).

Thanks,
Richard.

Re: GFDL/GPL issues

[Joe Buck]

On Mon, Aug 02, 2010 at 05:51:13PM -0700, Paul Koning wrote:
> gcc and gccint docs are actually pretty reasonable.  (Certainly gccint is 
> vastly better than some of its siblings, like gdbint.)  But very little of it 
> is generated and very little of what comes to mind as possible subject matter 
> is suitable for being generated.

RMS explicitly blessed generated cross-references and the like under the
GPL.

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".

RE: Restrict qualifier still not working?

[Bingfeng Mei]

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)
movl4(%rdx,%rax), %r9d
imull   4(%rsi,%rax), %r9d
movl%r9d, 4(%rdi,%rax)
movl8(%rdx,%rax), %r8d
imull   8(%rsi,%rax), %r8d
movl%r8d, 8(%rdi,%rax)
movl12(%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?

Thanks,
Bingfeng

> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 03 August 2010 10:33
> To: Bingfeng Mei
> Cc: Alexander Monakov; gcc@gcc.gnu.org
> Subject: Re: Restrict qualifier still not working?
> 
> On Tue, Aug 3, 2010 at 10:50 AM, Bingfeng Mei  wrote:
> >> -Original Message-
> >> From: Alexander Monakov [mailto:amona...@ispras.ru]
> >> Sent: 02 August 2010 17:48
> >> To: Bingfeng Mei
> >> Cc: gcc@gcc.gnu.org; Richard Guenther
> >> Subject: Re: Restrict qualifier still not working?
> >>
> >>
> >>
> >> On Mon, 2 Aug 2010, Bingfeng Mei wrote:
> >>
> >> > Hi,
> >> > I ran a small test to see how the trunk/4.5 works
> >> > with the rewritten restrict qualified pointer code. But it doesn't
> >> > seem to work on both x86-64 and our port.
> >> >
> >> > tst.c:
> >> > void foo (int * restrict a, int * restrict b,
> >> >           int * restrict c, int * restrict d)
> >> > {
> >> >   *c = *a + 1;
> >> >   *d = *b + 1;
> >> > }
> >> [snip]
> >> > foo:
> >> > .LFB0:
> >> >     .cfi_startproc
> >> >     movl    (%rdi), %eax
> >> >     addl    $1, %eax
> >> >     movl    %eax, (%rdx)
> >> >     movl    (%rsi), %eax
> >> >     addl    $1, %eax
> >> >     movl    %eax, (%rcx)
> >> >     ret
> >> >
> >> > In the finally generated code, the second load should have
> >> > been moved before the first store if restrict qualifiers
> >> > are handled correctly.
> >> >
> >> > Am I missing something here? Thanks.
> >>
> >> The second load is moved for me with -fschedule-insns, -frename-
> >> registers or
> >> -fselective-scheduling2 (all of which are disabled by default on
> x86-64
> >> -O2).
> >> Without those flags, second scheduler alone cannot lift the load due
> to
> >> dependency on %eax.
> >>
> >> Hope that helps.
> >
> > Thanks, I can reproduce it with trunk compiler but not 4.5.0.
> > Do you know how alias set are represented and used now. It used to
> > be each alias set is assigned a unique number and there won't
> > be a dependence edge drawn between different alias set. It seems not
> > to be the case anymore. [2 *a_1(D)+0 S4 A32] The second field
> > must play a role in disambiguate the memory access.
> 
> Yes, restrict support is now implemented as part of points-to
> analysis and information is stored alongside SSA names (the a_1(D)).
> On the 4.5 branch we do not preserve them in all cases.
> 
> See the fixes for PR42617 which should apply to the branch
> (but also watch for some patches fixing fallout in that area).
> 
> Richard.
> 
> > BTW, why these two intermediate variables are both assigned to eax
> > without these non-default options? This example has no register
> pressure.
> > It looks like an issue with IRA.
> >
> >
> > Cheers,
> > Bingfeng
> >
> >
> >

constraints and predicates

[roy rosen]

Hi All,

If I don't use a constraint, is it possible that during ira I get a
register which is not acceptable by the predicate?
In my port I have the following to support HW loops:

(define_predicate "lc_operand"
(match_operand 0 "register_operand")
{
unsigned int regno;
if (GET_CODE (op) == SUBREG)
op = SUBREG_REG (op);
regno = REGNO (op);
return (regno >= FIRST_PSEUDO_REGISTER ||
REGNO_REG_CLASS(regno) == LC_REGS);
}
)

(define_expand "doloop_end"
  [(use (match_operand 0 "" "")); loop pseudo
   (use (match_operand 1 "" "")); iterations; zero if unknown
   (use (match_operand 2 "" "")); max iterations
   (use (match_operand 3 "" "")); loop level
   (use (match_operand 4 "" ""))]   ; label
  ""
  {
if (INTVAL (operands[3]) > 4
)
FAIL;
emit_jump_insn (gen_doloop_end_internal (operands[4], operands[0]));
DONE;
  }
)

(define_insn "doloop_end_internal"
  [(set (pc)
(if_then_else (ne (match_operand:SI 1 "lc_operand" "")
  (const_int 0))
  (label_ref (match_operand 0 "" ""))
  (pc)))
   (set (match_dup 1) (plus:SI (match_dup 1) (const_int -1)))]
  ""
  "doloop_end%b1 %!"
)

I see that during ira operand 1 in doloop_end_internal is getting
"best GENERAL_REGS" and eventually ends up as a register of a class
other than LC_REGS.
I thought that if I have predicate lc_operand then I don't need a
constraint since all other register classes would be rejected in all
stages for this operand.
What might be the problem here?

Thanks, Roy.

Re: Restrict qualifier still not working?

[Richard Guenther]

On Tue, Aug 3, 2010 at 11:38 AM, Alexander Monakov  wrote:
>
>
> On Tue, 3 Aug 2010, Bingfeng Mei wrote:
>
>> Thanks, I can reproduce it with trunk compiler but not 4.5.0.
>> Do you know how alias set are represented and used now.
>
> I'm not aware of any changes regarding alias sets.
>
>> It used to
>> be each alias set is assigned a unique number and there won't
>> be a dependence edge drawn between different alias set.
>
> Are you implying that restricted pointers would get different alias sets
> numbers before but don't anymore?  I don't think that this might have changed
> but I may be mistaken (hopefully Richard can clarify this).

Yes, this changed.  In GCC 4.4 and before restrict was implemented
together with type-based alias analysis.  Starting from 4.5 it was
moved to pointer analysis which is more appropriate.

Richard.

>> It seems not
>> to be the case anymore. [2 *a_1(D)+0 S4 A32] The second field
>> must play a role in disambiguate the memory access.
>
> Yes, this is MEM_EXPR which is used to invoke tree alias oracle from RTL.  See
> mem_refs_may_alias_p and its invocations in {true,anti,write}_dependence.  It
> should be much more precise than alias set numbers (but they are still used
> nevertheless).
>
>> BTW, why these two intermediate variables are both assigned to eax
>> without these non-default options? This example has no register pressure.
>> It looks like an issue with IRA.
>
> Well, RA is quite complicated even without considering issues like this.
> Thanks to Vladimir's pressure-sensitive scheduling patches, pre-RA scheduling
> should solve this.
>
> Alexander
>

RE: Restrict qualifier still not working?

[Alexander Monakov]

On Tue, 3 Aug 2010, Bingfeng Mei wrote:

> Thanks, I can reproduce it with trunk compiler but not 4.5.0. 
> Do you know how alias set are represented and used now.

I'm not aware of any changes regarding alias sets.

> It used to 
> be each alias set is assigned a unique number and there won't 
> be a dependence edge drawn between different alias set.

Are you implying that restricted pointers would get different alias sets
numbers before but don't anymore?  I don't think that this might have changed
but I may be mistaken (hopefully Richard can clarify this).

> It seems not
> to be the case anymore. [2 *a_1(D)+0 S4 A32] The second field 
> must play a role in disambiguate the memory access. 

Yes, this is MEM_EXPR which is used to invoke tree alias oracle from RTL.  See
mem_refs_may_alias_p and its invocations in {true,anti,write}_dependence.  It
should be much more precise than alias set numbers (but they are still used
nevertheless).

> BTW, why these two intermediate variables are both assigned to eax
> without these non-default options? This example has no register pressure.
> It looks like an issue with IRA. 

Well, RA is quite complicated even without considering issues like this.
Thanks to Vladimir's pressure-sensitive scheduling patches, pre-RA scheduling
should solve this.

Alexander

Re: Restrict qualifier still not working?

[Richard Guenther]

On Tue, Aug 3, 2010 at 10:50 AM, Bingfeng Mei  wrote:
>> -Original Message-
>> From: Alexander Monakov [mailto:amona...@ispras.ru]
>> Sent: 02 August 2010 17:48
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org; Richard Guenther
>> Subject: Re: Restrict qualifier still not working?
>>
>>
>>
>> On Mon, 2 Aug 2010, Bingfeng Mei wrote:
>>
>> > Hi,
>> > I ran a small test to see how the trunk/4.5 works
>> > with the rewritten restrict qualified pointer code. But it doesn't
>> > seem to work on both x86-64 and our port.
>> >
>> > tst.c:
>> > void foo (int * restrict a, int * restrict b,
>> >           int * restrict c, int * restrict d)
>> > {
>> >   *c = *a + 1;
>> >   *d = *b + 1;
>> > }
>> [snip]
>> > foo:
>> > .LFB0:
>> >     .cfi_startproc
>> >     movl    (%rdi), %eax
>> >     addl    $1, %eax
>> >     movl    %eax, (%rdx)
>> >     movl    (%rsi), %eax
>> >     addl    $1, %eax
>> >     movl    %eax, (%rcx)
>> >     ret
>> >
>> > In the finally generated code, the second load should have
>> > been moved before the first store if restrict qualifiers
>> > are handled correctly.
>> >
>> > Am I missing something here? Thanks.
>>
>> The second load is moved for me with -fschedule-insns, -frename-
>> registers or
>> -fselective-scheduling2 (all of which are disabled by default on x86-64
>> -O2).
>> Without those flags, second scheduler alone cannot lift the load due to
>> dependency on %eax.
>>
>> Hope that helps.
>
> Thanks, I can reproduce it with trunk compiler but not 4.5.0.
> Do you know how alias set are represented and used now. It used to
> be each alias set is assigned a unique number and there won't
> be a dependence edge drawn between different alias set. It seems not
> to be the case anymore. [2 *a_1(D)+0 S4 A32] The second field
> must play a role in disambiguate the memory access.

Yes, restrict support is now implemented as part of points-to
analysis and information is stored alongside SSA names (the a_1(D)).
On the 4.5 branch we do not preserve them in all cases.

See the fixes for PR42617 which should apply to the branch
(but also watch for some patches fixing fallout in that area).

Richard.

> BTW, why these two intermediate variables are both assigned to eax
> without these non-default options? This example has no register pressure.
> It looks like an issue with IRA.
>
>
> Cheers,
> Bingfeng
>
>
>

Re: GFDL/GPL issues

[Paolo Bonzini]

On 08/03/2010 01:35 AM, Richard Kenner wrote:

That is true, but very often the documentation is needed in two
places: in the code and in the manual. Especially for things like
machine constraints, flags and options.


Yes, but the audiences are different between users who read the manual and
developers who read the code.  For the best quality, the two descriptions
may well be quite different, in emphasis, tone and other areas.  If the
emphasis is on finding text that's acceptable for BOTH purposes, you create
documentation that's not ideal for EITHER.


The amount of comments copied tout-court from gccint to the target files 
(especially with respect to target macro definitions) seems to 
contradict this.


Paolo

RE: Restrict qualifier still not working?

[Bingfeng Mei]

> -Original Message-
> From: Alexander Monakov [mailto:amona...@ispras.ru]
> Sent: 02 August 2010 17:48
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; Richard Guenther
> Subject: Re: Restrict qualifier still not working?
> 
> 
> 
> On Mon, 2 Aug 2010, Bingfeng Mei wrote:
> 
> > Hi,
> > I ran a small test to see how the trunk/4.5 works
> > with the rewritten restrict qualified pointer code. But it doesn't
> > seem to work on both x86-64 and our port.
> >
> > tst.c:
> > void foo (int * restrict a, int * restrict b,
> >   int * restrict c, int * restrict d)
> > {
> >   *c = *a + 1;
> >   *d = *b + 1;
> > }
> [snip]
> > foo:
> > .LFB0:
> > .cfi_startproc
> > movl(%rdi), %eax
> > addl$1, %eax
> > movl%eax, (%rdx)
> > movl(%rsi), %eax
> > addl$1, %eax
> > movl%eax, (%rcx)
> > ret
> >
> > In the finally generated code, the second load should have
> > been moved before the first store if restrict qualifiers
> > are handled correctly.
> >
> > Am I missing something here? Thanks.
> 
> The second load is moved for me with -fschedule-insns, -frename-
> registers or
> -fselective-scheduling2 (all of which are disabled by default on x86-64
> -O2).
> Without those flags, second scheduler alone cannot lift the load due to
> dependency on %eax.
> 
> Hope that helps.

Thanks, I can reproduce it with trunk compiler but not 4.5.0. 
Do you know how alias set are represented and used now. It used to 
be each alias set is assigned a unique number and there won't 
be a dependence edge drawn between different alias set. It seems not
to be the case anymore. [2 *a_1(D)+0 S4 A32] The second field 
must play a role in disambiguate the memory access. 

BTW, why these two intermediate variables are both assigned to eax
without these non-default options? This example has no register pressure.
It looks like an issue with IRA. 


Cheers,
Bingfeng