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

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:1

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

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 attribut

What are INIT_ARRAY_SECTION_ASM_OP/FINI_ARRAY_SECTION_ASM_OP used for?

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: PATCH: 2 stage BFD linker for LTO plugin

> 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_st

Re: PATCH: 2 stage BFD linker for LTO plugin

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 > think

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

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

Re: Is init_priority file scope or global scope?

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

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

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_ar

Re: Is init_priority file scope or global scope?

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

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

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 cod

Re: performance comparison post

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

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

Re: C/C++ extensions for array notations

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/i

Re: C/C++ extensions for array notations

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/comm

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

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 mistru

performance comparison post

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, Davi

C/C++ extensions for array notations

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 opinion

Target support needed for LTO

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/fr

Re: 4.5.2 20101213 (prerelease) ??

e 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

Re: 4.5.2 20101213 (prerelease) ??

RBY 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 rele

RE: A question about using restrict

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: Bingfe

4.5.2 20101213 (prerelease) ??

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

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

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