RE: A question about using restrict

[Bingfeng Mei]

Hi, Revital,
Sorry for late reply. I think you can write following code
according to C99 standard to make sure src1/src2 don't alias
with dst. However, current GCC support for restrict is still
quite weak. The restrict info tends to be lost in all optimizations,
especially ivopts. You won't get the intended result. I have some
internal patch for 4.5 to track the source of a pointer.
It is not a very efficient implementation but works for us so far.
I can send to you if you are interested.

void
foo(unsigned char  *** dst,
unsigned char * __restrict__ src1,
unsigned char  * __restrict__ src2, int row)
{
int x;
unsigned char  * __restrict__ dst2 = dst[0][row];

for( x = 0; x < 100; x+=1)
  {
dst2[x] = (src1[x] * src2[x]);
  }
}

Cheers,
Bingfeng

> -Original Message-
> From: Revital1 Eres [mailto:e...@il.ibm.com]
> Sent: 13 December 2010 07:59
> To: gcc@gcc.gnu.org
> Cc: Bingfeng Mei
> Subject: A question about using restrict
> 
> 
> Hello,
> 
> I have the loop below and I want to pass to gcc that src1 and src2
> never
> alias with dst; so I used the restrict keyword as below; however I
> still
> see that there are dependence edges between dst and src1 and src2 in
> the DDG created by SMS and I wonder how can I resolve this.
> (I used GCC -v167637 and compiled for powerpc)
> 
> Thanks,
> Revital
> 
> Original version:
> 
> void foo(unsigned char  ***dst,
> unsigned char *src1,
> unsigned char  *src2, int row)
> {
> int x;
> 
> for( x = 0; x < 100; x+=1)
>   {
> dst[0][row][x] = ( src1[x] * src2[x]);
>   }
> }
> 
> version 1 with restrict:
> 
> void foo(unsigned char  ***__restrict__ dst,
> unsigned char *__restrict__ src1,
> unsigned char  *__restrict__ src2, int row)
> {
> int x;
> 
> for( x = 0; x < 100; x+=1)
>   {
> dst[0][row][x] = ( src1[x] * src2[x]);
>   }
> }
> 
> version 2 with restrict:
> 
> void
> foo(unsigned char  *** __restrict__ dst,
> unsigned char * __restrict__ src1,
> unsigned char  * __restrict__ src2, int row)
> {
> int x;
> unsigned char  **__restrict__ dst1 = dst[0];
> unsigned char  * __restrict__ dst2 = dst1[row];
> 
> for( x = 0; x < 100; x+=1)
>   {
> dst2[x] = (src1[x] * src2[x]);
>   }
> }
> 
> 

RE: A question about using restrict

[Revital1 Eres]

Hello Bingfeng,

Thanks for your reply! I would be very interested to try your patch.

Revital




From:   "Bingfeng Mei" 
To: Revital1 Eres/Haifa/i...@ibmil, "gcc@gcc.gnu.org"

Date:   13/12/2010 12:20 PM
Subject:RE: A question about using restrict



Hi, Revital,
Sorry for late reply. I think you can write following code
according to C99 standard to make sure src1/src2 don't alias
with dst. However, current GCC support for restrict is still
quite weak. The restrict info tends to be lost in all optimizations,
especially ivopts. You won't get the intended result. I have some
internal patch for 4.5 to track the source of a pointer.
It is not a very efficient implementation but works for us so far.
I can send to you if you are interested.

void
foo(unsigned char  *** dst,
unsigned char * __restrict__ src1,
unsigned char  * __restrict__ src2, int row)
{
int x;
unsigned char  * __restrict__ dst2 = dst[0][row];

for( x = 0; x < 100; x+=1)
  {
dst2[x] = (src1[x] * src2[x]);
  }
}

Cheers,
Bingfeng

> -Original Message-
> From: Revital1 Eres [mailto:e...@il.ibm.com]
> Sent: 13 December 2010 07:59
> To: gcc@gcc.gnu.org
> Cc: Bingfeng Mei
> Subject: A question about using restrict
>
>
> Hello,
>
> I have the loop below and I want to pass to gcc that src1 and src2
> never
> alias with dst; so I used the restrict keyword as below; however I
> still
> see that there are dependence edges between dst and src1 and src2 in
> the DDG created by SMS and I wonder how can I resolve this.
> (I used GCC -v167637 and compiled for powerpc)
>
> Thanks,
> Revital
>
> Original version:
>
> void foo(unsigned char  ***dst,
> unsigned char *src1,
> unsigned char  *src2, int row)
> {
> int x;
>
> for( x = 0; x < 100; x+=1)
>   {
> dst[0][row][x] = ( src1[x] * src2[x]);
>   }
> }
>
> version 1 with restrict:
>
> void foo(unsigned char  ***__restrict__ dst,
> unsigned char *__restrict__ src1,
> unsigned char  *__restrict__ src2, int row)
> {
> int x;
>
> for( x = 0; x < 100; x+=1)
>   {
> dst[0][row][x] = ( src1[x] * src2[x]);
>   }
> }
>
> version 2 with restrict:
>
> void
> foo(unsigned char  *** __restrict__ dst,
> unsigned char * __restrict__ src1,
> unsigned char  * __restrict__ src2, int row)
> {
> int x;
> unsigned char  **__restrict__ dst1 = dst[0];
> unsigned char  * __restrict__ dst2 = dst1[row];
>
> for( x = 0; x < 100; x+=1)
>   {
> dst2[x] = (src1[x] * src2[x]);
>   }
> }
>
>

4.5.2 20101213 (prerelease) ??

[Dennis Clarke]

Dear GCC folks :

I have been closely watching the testsuite results as they come in and I
have yet to see anyone do anything with the 4.5.2 RC for Solaris. Other
than me of course. I have seen some work by Laurent GUERBY on 4.5.2 RC
20101213 ( on Linux ) which is NOT what I see at
ftp://gcc.gnu.org/pub/gcc/snapshots/LATEST-4.5/

So how does an outside community style hard working guy like me get the
absolute latest ? Subversion only ? I'm just trying to do tests before the
actual release and thus far I am seeing wonderful results :

  http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01062.html

  http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01063.html

If there is some other snapshot or RC that I should be testing please let
me know. Thank you dear GCC folks.

-- 
Dennis Clarke
dcla...@opensolaris.ca  <- Email related to the open source Solaris
dcla...@blastwave.org   <- Email related to open source for Solaris

RE: A question about using restrict

[Bingfeng Mei]

Please find the attached patch. The second patch is from our target.c. 
You may put the functions at where you want to insert so that alias.c
can access them.

Cheers,
Bingfeng



> -Original Message-
> From: Revital1 Eres [mailto:e...@il.ibm.com]
> Sent: 13 December 2010 10:37
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: RE: A question about using restrict
> 
> Hello Bingfeng,
> 
> Thanks for your reply! I would be very interested to try your patch.
> 
> Revital
> 
> 
> 
> 
> From: "Bingfeng Mei" 
> To:   Revital1 Eres/Haifa/i...@ibmil, "gcc@gcc.gnu.org"
> 
> Date: 13/12/2010 12:20 PM
> Subject:  RE: A question about using restrict
> 
> 
> 
> Hi, Revital,
> Sorry for late reply. I think you can write following code
> according to C99 standard to make sure src1/src2 don't alias
> with dst. However, current GCC support for restrict is still
> quite weak. The restrict info tends to be lost in all optimizations,
> especially ivopts. You won't get the intended result. I have some
> internal patch for 4.5 to track the source of a pointer.
> It is not a very efficient implementation but works for us so far.
> I can send to you if you are interested.
> 
> void
> foo(unsigned char  *** dst,
> unsigned char * __restrict__ src1,
> unsigned char  * __restrict__ src2, int row)
> {
> int x;
> unsigned char  * __restrict__ dst2 = dst[0][row];
> 
> for( x = 0; x < 100; x+=1)
>   {
> dst2[x] = (src1[x] * src2[x]);
>   }
> }
> 
> Cheers,
> Bingfeng
> 
> > -Original Message-
> > From: Revital1 Eres [mailto:e...@il.ibm.com]
> > Sent: 13 December 2010 07:59
> > To: gcc@gcc.gnu.org
> > Cc: Bingfeng Mei
> > Subject: A question about using restrict
> >
> >
> > Hello,
> >
> > I have the loop below and I want to pass to gcc that src1 and src2
> > never
> > alias with dst; so I used the restrict keyword as below; however I
> > still
> > see that there are dependence edges between dst and src1 and src2 in
> > the DDG created by SMS and I wonder how can I resolve this.
> > (I used GCC -v167637 and compiled for powerpc)
> >
> > Thanks,
> > Revital
> >
> > Original version:
> >
> > void foo(unsigned char  ***dst,
> > unsigned char *src1,
> > unsigned char  *src2, int row)
> > {
> > int x;
> >
> > for( x = 0; x < 100; x+=1)
> >   {
> > dst[0][row][x] = ( src1[x] * src2[x]);
> >   }
> > }
> >
> > version 1 with restrict:
> >
> > void foo(unsigned char  ***__restrict__ dst,
> > unsigned char *__restrict__ src1,
> > unsigned char  *__restrict__ src2, int row)
> > {
> > int x;
> >
> > for( x = 0; x < 100; x+=1)
> >   {
> > dst[0][row][x] = ( src1[x] * src2[x]);
> >   }
> > }
> >
> > version 2 with restrict:
> >
> > void
> > foo(unsigned char  *** __restrict__ dst,
> > unsigned char * __restrict__ src1,
> > unsigned char  * __restrict__ src2, int row)
> > {
> > int x;
> > unsigned char  **__restrict__ dst1 = dst[0];
> > unsigned char  * __restrict__ dst2 = dst1[row];
> >
> > for( x = 0; x < 100; x+=1)
> >   {
> > dst2[x] = (src1[x] * src2[x]);
> >   }
> > }
> >
> >
> 
> 
> 
> 



alias_c_patch
Description: alias_c_patch


new_functions_patch
Description: new_functions_patch

Re: 4.5.2 20101213 (prerelease) ??

[Jonathan Wakely]

On 13 December 2010 15:31, Dennis Clarke  wrote:
> Dear GCC folks :
>
> I have been closely watching the testsuite results as they come in and I
> have yet to see anyone do anything with the 4.5.2 RC for Solaris. Other
> than me of course. I have seen some work by Laurent GUERBY on 4.5.2 RC
> 20101213 ( on Linux ) which is NOT what I see at
> ftp://gcc.gnu.org/pub/gcc/snapshots/LATEST-4.5/
>
> So how does an outside community style hard working guy like me get the
> absolute latest ? Subversion only ? I'm just trying to do tests before the
> actual release and thus far I am seeing wonderful results :
>
>  http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01062.html
>
>  http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01063.html
>
> If there is some other snapshot or RC that I should be testing please let
> me know. Thank you dear GCC folks.

You get the latest gcc-4_5-branch (as always) from Subversion, but as
the branch is frozen you shouldn't need to.  The only change I see
since the RC (rev 167585) is the daily bump to update the date in the
version string:
http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/?sortby=rev&sortdir=down#dirlist


> --
> Dennis Clarke
> dcla...@opensolaris.ca  <- Email related to the open source Solaris
> dcla...@blastwave.org   <- Email related to open source for Solaris
>
>
>
>
>
>

Re: 4.5.2 20101213 (prerelease) ??

[Dennis Clarke]

> On 13 December 2010 15:31, Dennis Clarke  wrote:
>> Dear GCC folks :
>>
>> I have been closely watching the testsuite results as they come in and I
>> have yet to see anyone do anything with the 4.5.2 RC for Solaris. Other
>> than me of course. I have seen some work by Laurent GUERBY on 4.5.2 RC
>> 20101213 ( on Linux ) which is NOT what I see at
>> ftp://gcc.gnu.org/pub/gcc/snapshots/LATEST-4.5/
>>
>> So how does an outside community style hard working guy like me get the
>> absolute latest ? Subversion only ? I'm just trying to do tests before
>> the
>> actual release and thus far I am seeing wonderful results :
>>
>>  http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01062.html
>>
>>  http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01063.html
>>
>> If there is some other snapshot or RC that I should be testing please
>> let
>> me know. Thank you dear GCC folks.
>
> You get the latest gcc-4_5-branch (as always) from Subversion, but as
> the branch is frozen you shouldn't need to.  The only change I see
> since the RC (rev 167585) is the daily bump to update the date in the
> version string:
> http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/?sortby=rev&sortdir=down#dirlist
>
>

In that case we are all on the same page and just waiting for the official
code drop :-)

excellent.


-- 
Dennis Clarke
dcla...@opensolaris.ca  <- Email related to the open source Solaris
dcla...@blastwave.org   <- Email related to open source for Solaris

Target support needed for LTO

[Frederic Riss]

Hi,

I tried to enable LTO on my port, but failed to do so. On a stupid
example, I get:

$ k1-gcc -flto toto.o print.o
lto1: internal compiler error: compressed stream: data error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /work1/friss/tools/open64/osprey/targia32_k1/devimage/bin/k1-gcc
returned 1 exit status
collect2: lto-wrapper returned 1 exit status

I debugged a bit and found out that the deflate finds that the
compressed data is invalid. I tried to compile with included zlib,
system zlib, Fedora libelf or self-built libelf, the results are the
same...

Is there anything except defining TARGET_BUILTIN_DECL that targets
need to do to have LTO working? Maybe our linker is somehow mangling
the IR sections. Is there some way to debug those issues?

Thanks,
Fred

C/C++ extensions for array notations

[Sebastian Pop]

Hi,

I would like to ask the opinion of C/C++ maintainers about the extension
that the Intel compiler proposes for array notations:
http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011/compiler_c/index.htm#optaps/common/optaps_par_cean_prog.htm

Are there strong opinions against this extension?

Thanks,
Sebastian

PS: The openMP accelerator subcommittee is discussing about adopting
this notation as well to specify slices of data to be sent to an accelerator.

performance comparison post

[Xinliang David Li]

Any comment on the following?

http://blog.regehr.org/archives/320

1) is due to lack of non-linear induction variable support
5) is the same problem mentioned in pr35363

I have not looked at the details of others -- there are probably
related missed-optimization bugs already filed.

Thanks,

David

Request for clarification on how a contribution to gcc can be made

[Thomas Klein]

Hello

To me it looks like that what is described in the online document 
  is either not correct or is being 
misinterpreted at least by me.
It's not clear to me at which point the FSF is trusting an individual 
(or organization or company) and why it is mistrusting an individual per 
default.

Is there a way to suggest a code changes.
What kind of paper work is required for small code changes and what for 
huge code changes.
If a potential change is reviewed and accepted by a maintainer, who has 
to commit the change and when are they made.
(In assumption the person who is asking for a change usually did not 
have svn write permission.)

A clarification at GCC side would reduce frustration for people like me.

Regards
  Thomas

Re: C/C++ extensions for array notations

[Joseph S. Myers]

On Mon, 13 Dec 2010, Sebastian Pop wrote:

> Hi,
> 
> I would like to ask the opinion of C/C++ maintainers about the extension
> that the Intel compiler proposes for array notations:
> http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011/compiler_c/index.htm#optaps/common/optaps_par_cean_prog.htm
> 
> Are there strong opinions against this extension?

I don't see any specification there at the language standard level of how 
this interacts with the type system, with sizeof (and C1X alignof and GNU 
typeof), with array-to-pointer decay, what the type compatibility rules 
are, what is a constraint violation and what is runtime undefined 
(regarding integer constant expression or non-i-c-e values being out of 
range or disagreeing within an expression, for example).  Likewise 
regarding type conversions (implicit and otherwise).  And regarding 
sequence point rules (use the terminology in C1X and C++0X in providing 
such a specification, please).

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

Re: C/C++ extensions for array notations

[Joe Buck]

On Mon, Dec 13, 2010 at 09:08:39AM -0800, Sebastian Pop wrote:
> Hi,
> 
> I would like to ask the opinion of C/C++ maintainers about the extension
> that the Intel compiler proposes for array notations:
> http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011/compiler_c/index.htm#optaps/common/optaps_par_cean_prog.htm
> 
> Are there strong opinions against this extension?

It's an interesting concept, looks especially useful for parallel
programming.  It looks like a very complex set of features; I don't
know whether Intel has a document elsewhere that specifies the details.
Because of the high complexity, it could be quite a maintainance burden,
especially if there isn't a rigorous spec.

Interaction with other C++ language features doesn't seem to be described.
I can't think of a standard C++ program that would change meaning with
this extension.  But it's not stated whether there can be a reference to
an array section, what the ABI looks like when an array section is
passed as a C++ function argument, whether there are any issues when the
base type of the array we're taking a section of has constructors and
destructors, etc.

If someone is interested in producing an experimental gcc extension,
great.  But there would be a lot of questions to be answered before
it would be appropriate to accept as a supported feature of GCC.

Re: Request for clarification on how a contribution to gcc can be made

[Tobias Burnus]

On 12/13/2010 07:27 PM, Thomas Klein wrote:

It's not clear to me at which point the FSF is trusting an individual
(or organization or company) and why it is mistrusting an individual per
default.


My understanding is that the FSF wants to own the code completely,* 
which allows it to re-license the code, e.g. to use comments of GPL code 
for generated sections in FDL-licensed documents (or some application 
like that). In order to do so, the FSF needs a copyright transfer 
agreement of either an individual or of a entity/company for all its 
employees. If the patch is small and trivial enough to be not 
copyrightable, it can be included without copyright agreement. I think 
typically patches below 10 lines are regarded as obvious.




Is there a way to suggest a code changes.


Fill a bugreport - in doubt (no licence agreement but nontrivial patch) 
do NOT attach a patch. (If you do, you / copyright law might make it 
more complicated to create a patch, which might be included.)



What kind of paper work is required for small code changes and what for
huge code changes.


Trivial _and_ small patch: None. Otherwise, the normal licence agreement.


If a potential change is reviewed and accepted by a maintainer, who has
to commit the change and when are they made.


Well, usually the reviewer does the commit after approval. (It helps to 
state that one does not have commit rights - otherwise, it is assumed 
that one has it.) If there has not been a review - or no committal after 
approval: Simply ping the patch. Usually, patch review is relatively 
quick - but sometimes one needs several pings.



Regarding the copyright assignment procedures: I also found it a bit 
complicated and inconvenient, but I can understand the FSF. In any case: 
The GCC follows this procedure and, thus, one currently needs to adhere 
to it. If one only needs a signature of oneself (no employer such as the 
university or research institution), the procedure can be relatively 
quickly: One sends in (by email) a small form, FSF sends then a form via 
mail ("snail mail") to you, which you sign and send back. Then you get 
the counter-signed form as PDF. In my case, the procedure took about 10 
days, which is relatively quick. In unlucky cases (slow FSF, slow mail, 
lost forms, form wandering upwards the hierarchy at your employer) it 
can take months.


Tobias

* While the FSF wants to own the code completely, you keep also the 
rights on your code (except for allowing the FSF to also own the code) - 
which means you can still integrate it in, e.g., closed source software 
under whatever licence. In special cases, the FSF also accepts not to 
own the code - but those are special cases, which need to be explicitly 
discussed with the FSF.

Re: performance comparison post

[Sebastian Pop]

On Mon, Dec 13, 2010 at 11:14, Xinliang David Li  wrote:
> Any comment on the following?
>
> http://blog.regehr.org/archives/320
>
> 1) is due to lack of non-linear induction variable support
> 5) is the same problem mentioned in pr35363
>

Example 2) is now http://gcc.gnu.org/PR46928

Sebastian

Re: Request for clarification on how a contribution to gcc can be made

[Robert Dewar]

On 12/13/2010 12:57 PM, Tobias Burnus wrote:

On 12/13/2010 07:27 PM, Thomas Klein wrote:

It's not clear to me at which point the FSF is trusting an individual
(or organization or company) and why it is mistrusting an individual per
default.


My understanding is that the FSF wants to own the code completely,*
which allows it to re-license the code, e.g. to use comments of GPL code
for generated sections in FDL-licensed documents (or some application
like that). In order to do so, the FSF needs a copyright transfer
agreement of either an individual or of a entity/company for all its
employees. If the patch is small and trivial enough to be not
copyrightable, it can be included without copyright agreement. I think
typically patches below 10 lines are regarded as obvious.


this is not a 100% correct summary of the FSF assignment document. I 
suggest reading this document to find out exactly what the conditions 
are. They by no means result in the FSF "owning the code completely".



* While the FSF wants to own the code completely, you keep also the
rights on your code (except for allowing the FSF to also own the code) -
which means you can still integrate it in, e.g., closed source software
under whatever licence. In special cases, the FSF also accepts not to
own the code - but those are special cases, which need to be explicitly
discussed with the FSF.

Re: Is init_priority file scope or global scope?

[Ian Lance Taylor]

"H.J. Lu"  writes:

> Using .init_array section on Linux/x86 raised a question on
> init_priority.  GCC manual says
>
> `init_priority (PRIORITY)'
>  In Standard C++, objects defined at namespace scope are guaranteed
>  to be initialized in an order in strict accordance with that of
>  their definitions _in a given translation unit_.  No guarantee is
>  made for initializations across translation units.  However, GNU
>  C++ allows users to control the order of initialization of objects
>  defined at namespace scope with the `init_priority' attribute by
>  specifying a relative PRIORITY, a constant integral expression
>  currently bounded between 101 and 65535 inclusive.  Lower numbers
>  indicate a higher priority.
>
>  In the following example, `A' would normally be created before
>  `B', but the `init_priority' attribute has reversed that order:
>
>   Some_Class  A  __attribute__ ((init_priority (2000)));
>   Some_Class  B  __attribute__ ((init_priority (543)));
>
>  Note that the particular values of PRIORITY do not matter; only
>  their relative ordering.
>
> Is init_priority file scope or global scope? I consider init_priority is
> file scope.  Is that a correct assumption?

No.  That would be useless.  init_priority has global scope.  That is
what it was designed for.

The documentation could be more clear, but it is clearly saying "C++
specifies the order in a translation unit, init_priority specifies the
order across translation units."

Ian

RFC: Support mixing .init_array.* and .ctors.* input sections

[H.J. Lu]

Hi,

Using .init_array section in GCC:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

raised a question on init_priority attribute.  We need to provide binary
compatibilty for existing binaries with init_priority attribute.  This
linker patch puts input .ctors.* sections in the output .init_array
section and puts input .dtors.* sections in the output .fini_array
section if target supports .init_array sections. It adds
SORT_BY_INIT_PRIORITY to sort sections by numerical value of the GCC
init_priority attribute encoded in the section name.  Any comments?

Thanks.



H.J.
---
config/

2010-12-13  H.J. Lu  

* initfini-array.m4: New.

ld/

2010-12-13  H.J. Lu  

* Makefile.am (GENSCRIPTS): Padd @enable_initfini_ar...@.

* NEWS: Mention SORT_BY_INIT_PRIORITY.

* configure.in:  Add ACX_INITFINI_ARRAY.

* genscripts.sh (ENABLE_INITFINI_ARRAY): New.

* ld.h (sort_type): Add by_init_priority.

* ld.texinfo: Document SORT_BY_INIT_PRIORITY.

* ldgram.y (SORT_BY_INIT_PRIORITY): New.
(wildcard_spec): Handle SORT_BY_INIT_PRIORITY.

* ldlang.c (get_init_priority): New.
(compare_section): Use get_init_priority for by_init_priority.

* ldlex.l (SORT_BY_INIT_PRIORITY): New.

* scripttempl/elf.sc: Support ENABLE_INITFINI_ARRAY.

* Makefile.in: Regenerated.
* aclocal.m4: Regenerated.
* config.in: Likewise.
* configure: Likewise.

ld/testsuite/

2010-12-13  H.J. Lu  

* ld-elf/elf.exp (array_tests): Add init-mixed.
(array_tests_static): Likewise.
Also delete tmpdir/init-mixed.

* ld-elf/init-mixed.c: New.
* ld-elf/init-mixed.out: Likewise.

diff --git a/config/initfini-array.m4 b/config/initfini-array.m4
new file mode 100644
index 000..c09f144
--- /dev/null
+++ b/config/initfini-array.m4
@@ -0,0 +1,42 @@
+dnl Copyright (C) 2010 Free Software Foundation, Inc.
+dnl
+dnl GCC is free software; you can redistribute it and/or modify
+dnl it under the terms of the GNU General Public License as published by
+dnl the Free Software Foundation; either version 3, or (at your option)
+dnl any later version.
+dnl
+dnl GCC is distributed in the hope that it will be useful,
+dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+dnl GNU General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU General Public License
+dnl along with GCC; see the file COPYING3.  If not see
+dnl .
+
+AC_DEFUN([ACX_INITFINI_ARRAY],
+[AC_REQUIRE([AC_CANONICAL_BUILD])
+AC_REQUIRE([AC_CANONICAL_TARGET])
+AC_ARG_ENABLE(initfini-array,
+   [  --enable-initfini-array  use .init_array/.fini_array sections],
+   [], [
+AC_CACHE_CHECK(for .preinit_array/.init_array/.fini_array support,
+gcc_cv_initfini_array, [dnl
+  if test "x${build}" = "x${target}" ; then
+AC_RUN_IFELSE([AC_LANG_SOURCE([
+static int x = -1;
+int main (void) { return x; }
+int foo (void) { x = 0; }
+int (*fp) (void) __attribute__ ((section (".init_array"))) = foo;])],
+[gcc_cv_initfini_array=yes], [gcc_cv_initfini_array=no],
+[gcc_cv_initfini_array=no])
+   else
+ gcc_cv_initfini_array=no
+   fi])
+  enable_initfini_array=$gcc_cv_initfini_array
+])
+AC_SUBST(enable_initfini_array)])
+if test $enable_initfini_array = yes; then
+  AC_DEFINE(HAVE_INITFINI_ARRAY, 1,
+[Define .init_array/.fini_array sections are available and working.])
+fi])
diff --git a/ld/Makefile.am b/ld/Makefile.am
index d9e1bcc..9f016df 100644
--- a/ld/Makefile.am
+++ b/ld/Makefile.am
@@ -611,7 +611,7 @@ stringify.sed: ${srcdir}/emultempl/$(STRINGIFY)
 
 # These all start with e so 'make clean' can find them.
 
-GENSCRIPTS = LIB_PATH='${LIB_PATH}' $(SHELL) $(srcdir)/genscripts.sh 
"${srcdir}" "${libdir}" "${prefix}" "${exec_prefix}" @host@ @target@ 
@target_alias@ "@EMULATION_LIBPATH@" "@NATIVE_LIB_DIRS@" @use_sysroot@
+GENSCRIPTS = LIB_PATH='${LIB_PATH}' $(SHELL) $(srcdir)/genscripts.sh 
"${srcdir}" "${libdir}" "${prefix}" "${exec_prefix}" @host@ @target@ 
@target_alias@ "@EMULATION_LIBPATH@" "@NATIVE_LIB_DIRS@" @use_sysroot@ 
@enable_initfini_array@
 GEN_DEPENDS = $(srcdir)/genscripts.sh stringify.sed
 ELF_DEPS = $(srcdir)/emultempl/elf32.em $(srcdir)/emultempl/elf-generic.em
 ELF_GEN_DEPS = $(srcdir)/emultempl/generic.em 
$(srcdir)/emultempl/elf-generic.em $(srcdir)/emultempl/genelf.em
diff --git a/ld/Makefile.in b/ld/Makefile.in
index 01511bc..c807947 100644
--- a/ld/Makefile.in
+++ b/ld/Makefile.in
@@ -54,6 +54,7 @@ am__aclocal_m4_deps = $(top_srcdir)/../bfd/acinclude.m4 \
$(top_srcdir)/../bfd/warning.m4 $(top_srcdir)/../config/acx.m4 \
$(top_srcdir)/../config/depstand.m4 \
$(top_srcdir)/../config/gettext-sister.m4 \
+   $(top_srcdir)/../config/initfini-array.m4 \
$(top_srcdir)/../config/largefile.m4 \
 

Re: Is init_priority file scope or global scope?

[Ian Lance Taylor]

Dave Korn  writes:

>   Well, at least on PE-COFF, the numeric string is (65536-priority).  It is
> zero padded to five digits, so that the linker's alphabetical sort effectively
> becomes a numeric sort, and the reason for the inverting the numeric order of
> priorities is because .ctors gets read backwards at startup.

Same on ELF (except that on ARM EABI it uses .init_array and does not
subtract from 65535; see arm_elf_asm_cdtor).

Ian

Re: Request for clarification on how a contribution to gcc can be made

[Ian Lance Taylor]

Thomas Klein  writes:

> To me it looks like that what is described in the online document
>   is either not correct or is
> being misinterpreted at least by me.
> It's not clear to me at which point the FSF is trusting an individual
> (or organization or company) and why it is mistrusting an individual
> per default.
> Is there a way to suggest a code changes.
> What kind of paper work is required for small code changes and what
> for huge code changes.
> If a potential change is reviewed and accepted by a maintainer, who
> has to commit the change and when are they made.
> (In assumption the person who is asking for a change usually did not
> have svn write permission.)
> A clarification at GCC side would reduce frustration for people like me.

Can you suggest specific items that need to be clarified?  I'm not sure
how to move from your comments to changes in the documentation.

E.g., you say:

> It's not clear to me at which point the FSF is trusting an individual
> (or organization or company) and why it is mistrusting an individual
> per default.

When I look at http://gcc.gnu.org/contribute.html , it seems fairly
clear that there are "Legal Prerequisites" which must be satisfied for
the FSF to trust an individual.  It seems clear that the requirements
come from the FSF, not from the GCC project, and the web page links to
the FSF site for an explanation.

So, while we certainly want to improve the documentation, I think some
more specific suggestions will help us do so.  Thanks.

Ian

Re: PATCH: 2 stage BFD linker for LTO plugin

[Ian Lance Taylor]

Alan Modra  writes:

> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Personally, I think 2 stage linking is one way to fix this issue.
>
> Ian has stated that he thinks this is a really bad idea.  I haven't
> approved the patch because I value Ian's opinion, and can see why he
> thinks it is the wrong way to go.  On the other hand, BFD is full of
> bad ideas..  I'm not strongly opposed to your patch myself.

Here is an alternative proposal, with a patch for gold.

We add a new plugin vector: LDPT_REGISTER_RESCAN_ARCHIVE_HOOK.  Like
LDPT_REGISTER_CLAIM_FILE_HOOK, this gives the plugin the address of a
function which can register a plugin function: rescan_archive.

typedef
enum ld_plugin_status
(*ld_plugin_rescan_archive_handler) (
  const struct ld_plugin_input_file *file, int *rescan);

If the plugin registers this hook, the linker will call the hook for
each archive that it sees.  If the hook sets the *rescan variable to a
non-zero value, then the linker will rescan the archive after calling
the all_symbols_read hook.  The archive will be rescanned using the same
position dependent options as when it was originally scanned.  In
particular, if the archive occurred within --start-group/--end-group,
the entire group will be rescanned.

The point of this patch is that the known problems with the LTO plugin
are when the plugin introduces a previously unknown symbol which must be
satisfied from some archive.  The new symbol is introduced when the
all_symbols_hook read hook calls add_input_file to add a new object file
to the link, and the new object file refers to the new symbol.  Since
the symbol was not previously seen, if the definition should come from
an archive, the archive will not have been searched.  Hence the test
case in GCC PR 42690 comment #32.

Fortunately, we know that gcc is not going to introduce arbitrary new
symbol references.  The current system hacks around the problem by using
a special -pass-through option which directs the plugin to add specific
archives to the link, namely -lc and -lgcc.  That works for most cases,
but not when gcc introduces a symbol which comes from -lm.  Still,
despite the -lm issue, we do not have to concern ourselves with
arbitrary archives, because gcc is not going to act arbitrarily.

Also we know that the problem can only occur with archives, not with
shared objects.

The rescan_archive proposal fixes the problems and obviates the need to
use -pass-through.  It avoids the unnecessary cost of a complete relink.

I've appended a patch for gold which implements this proposal.  I've
also appended a patch for lto-plugin.  This patched lto-plugin does not
use -pass-through when rescan_archive is available.  It rescans libc.a,
libgcc.a, and libm.a.  It handles the PR 42690 comment #32 test case
correctly.

Any thoughts on this approach?

Ian


Index: include/plugin-api.h
===
RCS file: /cvs/src/src/include/plugin-api.h,v
retrieving revision 1.12
diff -p -u -r1.12 plugin-api.h
--- include/plugin-api.h	14 Oct 2010 01:31:28 -	1.12
+++ include/plugin-api.h	13 Dec 2010 20:53:16 -
@@ -163,6 +163,13 @@ typedef
 enum ld_plugin_status
 (*ld_plugin_all_symbols_read_handler) (void);
 
+/* The plugin library's "rescan archive" handler.  */
+
+typedef
+enum ld_plugin_status
+(*ld_plugin_rescan_archive_handler) (
+  const struct ld_plugin_input_file *file, int *rescan);
+
 /* The plugin library's cleanup handler.  */
 
 typedef
@@ -182,6 +189,13 @@ enum ld_plugin_status
 (*ld_plugin_register_all_symbols_read) (
   ld_plugin_all_symbols_read_handler handler);
 
+/* The linker's interface for registering the "rescan archive" handler.  */
+
+typedef
+enum ld_plugin_status
+(*ld_plugin_register_rescan_archive) (
+  ld_plugin_rescan_archive_handler handler);
+
 /* The linker's interface for registering the cleanup handler.  */
 
 typedef
@@ -269,7 +283,8 @@ enum ld_plugin_tag
   LDPT_ADD_INPUT_LIBRARY,
   LDPT_OUTPUT_NAME,
   LDPT_SET_EXTRA_LIBRARY_PATH,
-  LDPT_GNU_LD_VERSION
+  LDPT_GNU_LD_VERSION,
+  LDPT_REGISTER_RESCAN_ARCHIVE_HOOK
 };
 
 /* The plugin transfer vector.  */
@@ -283,6 +298,7 @@ struct ld_plugin_tv
 const char *tv_string;
 ld_plugin_register_claim_file tv_register_claim_file;
 ld_plugin_register_all_symbols_read tv_register_all_symbols_read;
+ld_plugin_register_rescan_archive tv_register_rescan_archive;
 ld_plugin_register_cleanup tv_register_cleanup;
 ld_plugin_add_symbols tv_add_symbols;
 ld_plugin_get_symbols tv_get_symbols;
Index: plugin.cc
===
RCS file: /cvs/src/src/gold/plugin.cc,v
retrieving revision 1.41
diff -p -u -r1.41 plugin.cc
--- plugin.cc	5 Nov 2010 21:14:12 -	1.41
+++ plugin.cc	13 Dec 2010 20:52:15 -
@@ -60,6 +60,9 @@ static enum ld_plugin_status
 register_all_symbols_read(ld_plugin_all_symbols_read_handler handler);
 
 static enum ld_plugin_status
+register_rescan_archiv

Re: PATCH: 2 stage BFD linker for LTO plugin

[Cary Coutant]

> Here is an alternative proposal, with a patch for gold.
>
> We add a new plugin vector: LDPT_REGISTER_RESCAN_ARCHIVE_HOOK.  Like
> LDPT_REGISTER_CLAIM_FILE_HOOK, this gives the plugin the address of a
> function which can register a plugin function: rescan_archive.
>
> typedef
> enum ld_plugin_status
> (*ld_plugin_rescan_archive_handler) (
>  const struct ld_plugin_input_file *file, int *rescan);
>
> If the plugin registers this hook, the linker will call the hook for
> each archive that it sees.  If the hook sets the *rescan variable to a
> non-zero value, then the linker will rescan the archive after calling
> the all_symbols_read hook.  The archive will be rescanned using the same
> position dependent options as when it was originally scanned.  In
> particular, if the archive occurred within --start-group/--end-group,
> the entire group will be rescanned.
>
> The point of this patch is that the known problems with the LTO plugin
> are when the plugin introduces a previously unknown symbol which must be
> satisfied from some archive.  The new symbol is introduced when the
> all_symbols_hook read hook calls add_input_file to add a new object file
> to the link, and the new object file refers to the new symbol.  Since
> the symbol was not previously seen, if the definition should come from
> an archive, the archive will not have been searched.  Hence the test
> case in GCC PR 42690 comment #32.
>
> Fortunately, we know that gcc is not going to introduce arbitrary new
> symbol references.  The current system hacks around the problem by using
> a special -pass-through option which directs the plugin to add specific
> archives to the link, namely -lc and -lgcc.  That works for most cases,
> but not when gcc introduces a symbol which comes from -lm.  Still,
> despite the -lm issue, we do not have to concern ourselves with
> arbitrary archives, because gcc is not going to act arbitrarily.
>
> Also we know that the problem can only occur with archives, not with
> shared objects.
>
> The rescan_archive proposal fixes the problems and obviates the need to
> use -pass-through.  It avoids the unnecessary cost of a complete relink.
>
> I've appended a patch for gold which implements this proposal.  I've
> also appended a patch for lto-plugin.  This patched lto-plugin does not
> use -pass-through when rescan_archive is available.  It rescans libc.a,
> libgcc.a, and libm.a.  It handles the PR 42690 comment #32 test case
> correctly.
>
> Any thoughts on this approach?

Looks good to me. I'd still prefer something based on a list of symbol
names that the backend might introduce calls to, but I'll concede that
this is far more practical.

I think Dave mentioned in the other thread that libgcov, libssp, and
libmudflap might also need to be rescanned:

>>> My suspicion is that the LTO plugin can only introduce a small bounded
>>> set of new symbol references, namely those which we assume can be
>>> satisified from -lc or -lgcc.  Is that true?
>>
>> Exactly.
>
> Potentially also gcov, ssp, mudflap?

Should we mark the pass-through option in lto-plugin as obsolescent?

-cary

What are INIT_ARRAY_SECTION_ASM_OP/FINI_ARRAY_SECTION_ASM_OP used for?

[H.J. Lu]

Hi,

I checked GC sources.  From what I can see,  we only check if
INIT_ARRAY_SECTION_ASM_OP
and FINI_ARRAY_SECTION_ASM_OP are defined. Their values aren't used.
Am I correct?

-- 
H.J.

Re: RFC: Support mixing .init_array.* and .ctors.* input sections

[H.J. Lu]

On Mon, Dec 13, 2010 at 11:39:28AM -0800, H.J. Lu wrote:
> Hi,
> 
> Using .init_array section in GCC:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
> 
> raised a question on init_priority attribute.  We need to provide binary
> compatibilty for existing binaries with init_priority attribute.  This
> linker patch puts input .ctors.* sections in the output .init_array
> section and puts input .dtors.* sections in the output .fini_array
> section if target supports .init_array sections. It adds
> SORT_BY_INIT_PRIORITY to sort sections by numerical value of the GCC
> init_priority attribute encoded in the section name.  Any comments?
> 
> Thanks.
> 
> 
> 
> H.J.
> ---
> config/
> 
> 2010-12-13  H.J. Lu  
> 
>   * initfini-array.m4: New.
> 
> ld/
> 
> 2010-12-13  H.J. Lu  
> 
>   * Makefile.am (GENSCRIPTS): Padd @enable_initfini_ar...@.
> 
>   * NEWS: Mention SORT_BY_INIT_PRIORITY.
> 
>   * configure.in:  Add ACX_INITFINI_ARRAY.
> 
>   * genscripts.sh (ENABLE_INITFINI_ARRAY): New.
> 
>   * ld.h (sort_type): Add by_init_priority.
> 
>   * ld.texinfo: Document SORT_BY_INIT_PRIORITY.
> 
>   * ldgram.y (SORT_BY_INIT_PRIORITY): New.
>   (wildcard_spec): Handle SORT_BY_INIT_PRIORITY.
> 
>   * ldlang.c (get_init_priority): New.
>   (compare_section): Use get_init_priority for by_init_priority.
> 
>   * ldlex.l (SORT_BY_INIT_PRIORITY): New.
> 
>   * scripttempl/elf.sc: Support ENABLE_INITFINI_ARRAY.
> 
>   * Makefile.in: Regenerated.
>   * aclocal.m4: Regenerated.
>   * config.in: Likewise.
>   * configure: Likewise.
> 
> ld/testsuite/
> 
> 2010-12-13  H.J. Lu  
> 
>   * ld-elf/elf.exp (array_tests): Add init-mixed.
>   (array_tests_static): Likewise.
>   Also delete tmpdir/init-mixed.
> 
>   * ld-elf/init-mixed.c: New.
>   * ld-elf/init-mixed.out: Likewise.
> 

Updated patch to remove config/initfini-array.m4.


H.J.
---
ld/

2010-12-13  H.J. Lu  

* Makefile.am (GENSCRIPTS): Add @enable_initfini_ar...@.

* NEWS: Mention SORT_BY_INIT_PRIORITY.

* configure.in: Add AC_CANONICAL_BUILD.
Add --enable-initfini-array.

* genscripts.sh (ENABLE_INITFINI_ARRAY): New.

* ld.h (sort_type): Add by_init_priority.

* ld.texinfo: Document SORT_BY_INIT_PRIORITY.

* ldgram.y (SORT_BY_INIT_PRIORITY): New.
(wildcard_spec): Handle SORT_BY_INIT_PRIORITY.

* ldlang.c (get_init_priority): New.
(compare_section): Use get_init_priority for by_init_priority.

* ldlex.l (SORT_BY_INIT_PRIORITY): New.

* scripttempl/elf.sc: Support ENABLE_INITFINI_ARRAY.

* Makefile.in: Regenerated.
* aclocal.m4: Regenerated.
* config.in: Likewise.
* configure: Likewise.

ld/testsuite/

2010-12-13  H.J. Lu  

* ld-elf/elf.exp (array_tests): Add init-mixed.
(array_tests_static): Likewise.
Also delete tmpdir/init-mixed.

* ld-elf/init-mixed.c: New.
* ld-elf/init-mixed.out: Likewise.

diff --git a/ld/Makefile.am b/ld/Makefile.am
index d9e1bcc..9f016df 100644
--- a/ld/Makefile.am
+++ b/ld/Makefile.am
@@ -611,7 +611,7 @@ stringify.sed: ${srcdir}/emultempl/$(STRINGIFY)
 
 # These all start with e so 'make clean' can find them.
 
-GENSCRIPTS = LIB_PATH='${LIB_PATH}' $(SHELL) $(srcdir)/genscripts.sh 
"${srcdir}" "${libdir}" "${prefix}" "${exec_prefix}" @host@ @target@ 
@target_alias@ "@EMULATION_LIBPATH@" "@NATIVE_LIB_DIRS@" @use_sysroot@
+GENSCRIPTS = LIB_PATH='${LIB_PATH}' $(SHELL) $(srcdir)/genscripts.sh 
"${srcdir}" "${libdir}" "${prefix}" "${exec_prefix}" @host@ @target@ 
@target_alias@ "@EMULATION_LIBPATH@" "@NATIVE_LIB_DIRS@" @use_sysroot@ 
@enable_initfini_array@
 GEN_DEPENDS = $(srcdir)/genscripts.sh stringify.sed
 ELF_DEPS = $(srcdir)/emultempl/elf32.em $(srcdir)/emultempl/elf-generic.em
 ELF_GEN_DEPS = $(srcdir)/emultempl/generic.em 
$(srcdir)/emultempl/elf-generic.em $(srcdir)/emultempl/genelf.em
diff --git a/ld/Makefile.in b/ld/Makefile.in
index 01511bc..3cb6234 100644
--- a/ld/Makefile.in
+++ b/ld/Makefile.in
@@ -299,6 +299,7 @@ datarootdir = @datarootdir@
 do_compare = @do_compare@
 docdir = @docdir@
 dvidir = @dvidir@
+enable_initfini_array = @enable_initfini_array@
 exec_prefix = @exec_prefix@
 host = @host@
 host_alias = @host_alias@
@@ -797,7 +798,7 @@ EMULATION_FILES = emultempl/pe.em emultempl/armcoff.em
 POTFILES = $(CFILES) $(HFILES) $(EMULATION_FILES)
 
 # These all start with e so 'make clean' can find them.
-GENSCRIPTS = LIB_PATH='${LIB_PATH}' $(SHELL) $(srcdir)/genscripts.sh 
"${srcdir}" "${libdir}" "${prefix}" "${exec_prefix}" @host@ @target@ 
@target_alias@ "@EMULATION_LIBPATH@" "@NATIVE_LIB_DIRS@" @use_sysroot@
+GENSCRIPTS = LIB_PATH='${LIB_PATH}' $(SHELL) $(srcdir)/genscripts.sh 
"${srcdir}" "${libdir}" "${prefix}" "${exec_prefix}" @host@ @target@ 
@target_alias@ "@EMULATION_LIBPATH@" "@NATIVE_LIB_DIRS@" @use_sysroot@ 
@enable_initfini_array@
 GEN_DEPENDS = $(srcdir)/gensc

gcc-4.5.2-RC-20101208 warning in fold-const.c

[Dennis Clarke]

I'm doing a bootstrap with on Debian squeeze with
--enable-stage1-checking=all and --enable-checking=all and in stage 2 I
see this sort of thing about an "unsafe" issue :

../../gcc-4.5.2-RC-20101208/gcc/fold-const.c: In function
'fold_checksum_tree':
../../gcc-4.5.2-RC-20101208/gcc/fold-const.c:14267:3: warning: new
qualifiers in middle of multi-level non-const cast are unsafe

This is probably filed as a bug somewhere but I couldn't find it.

-- 
Dennis