Re: 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. 7) is probably best handled by extending switch conversion pass to discover switches written as sequences of ifs and then convert two way switches into bitmask operation. This was requested by kernel folks for a while. Honza > > Thanks, > > David
Re: 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 Yep. We might however also teach unroller to fully unroll the loop if we improve constant_after_peeling. This is probably good idea too, since we do have different kinds of loop carried vars that not always simplify. > > 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. > > 7) is probably best handled by extending switch conversion pass to discover > switches > written as sequences of ifs and then convert two way switches into bitmask > operation. > This was requested by kernel folks for a while. I filled this in as enhancement PR46935. Honza
Re: Target support needed for LTO
On 13/12/2010 17:02, Frederic Riss wrote: > 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... Hello Frederic, This symptom usually means that the assembler is padding the section containing the compressed data when it generates the IR-containing .o file. There is no record within the compressed data stream of how long it is supposed to be(*), so LTO assumes that the /entire/ contents of the section represents compressed data and feeds it to the decompressor. If there are a few trailing bytes of zeroes, they get fed to the decompressor as well and it gets confused and complains. On ELF and COFF we deal with this by setting the section alignment to 1 byte, so that no padding is added and the size of the section exactly matches the amount of data written to it. This can be done in the TARGET_ASM_NAMED_SECTION hook by detecting if the section name begins with LTO_SECTION_NAME_PREFIX and if so, forcing the alignment to 1 byte; see for example i386_pe_asm_named_section() in gcc/config/i386/winnt.c. > Is there anything except defining TARGET_BUILTIN_DECL that targets > need to do to have LTO working? TARGET_BUILTIN_DECL isn't relevant to LTO, actually. You may or may not need to define TARGET_MANGLE_ASSEMBLER_NAME, depending on whether your port does anything unusual with symbol processing; the default hook works fine for most targets where it's just a matter of whether or not to prepend an underscore. > Maybe our linker is somehow mangling > the IR sections. Is there some way to debug those issues? Well, check the theory I suggested above first of all; it's more likely that the assembler is generating the sections with alignment padding. cheers, DaveK -- (*) - Yes, this is a design weakness we should try and resolve.
Re: Target support needed for LTO
Hi Dave, On 14 December 2010 15:48, Dave Korn wrote: > This symptom usually means that the assembler is padding the section > containing the compressed data when it generates the IR-containing .o file. > There is no record within the compressed data stream of how long it is > supposed to be(*), so LTO assumes that the /entire/ contents of the section > represents compressed data and feeds it to the decompressor. If there are a > few trailing bytes of zeroes, they get fed to the decompressor as well and it > gets confused and complains. Although this wasn't exactly the issue, it pointed me in the right direction and I found a bug in my assembler that mangled some end of sections... Thanks a lot! Fred
Buffer overflow in emutls code
I know that almost no one uses emutls, but I was fiddling with
it recently, and found a buffer overflow; the emutls_destroy()
function moves past the end of an array. Patch attached.
The correctness of the fix may not be immediately obvious, but
a careful study of emutls_alloc() will show that there is some
off-by-one tomfoolery, coded in on purpose (personally, I think
its poor/bad coding style). The corresponding tomfoolery
wasn't done in the matching free code, leading to this bug.
---
gcc/emutls.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: gcc-4.4/gcc/emutls.c
===
--- gcc-4.4.orig/gcc/emutls.c 2010-12-13 16:53:48.0 -0600
+++ gcc-4.4/gcc/emutls.c2010-12-13 17:12:27.0 -0600
@@ -76,7 +76,11 @@ emutls_destroy (void *ptr)
pointer size = arr->size;
pointer i;
- for (i = 0; i < size; ++i)
+ /* arr->size is the total size of area that 'arr' is pointing to.
+ * The size of 'arr->data' is one less than that.
+ * Properly, its (&arr->data[0]-arr)/sizeof(void *) = 1 less.
+ */
+ for (i = 0; i < size-1; ++i)
{
if (arr->data[i])
free (arr->data[i][-1]);
PATCH: Support mixing .init_array.* and .ctors.* input sections
On Mon, Dec 13, 2010 at 04:49:32PM -0800, H.J. Lu wrote:
> 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.
>
>
Here is the updated patch to set SHT_INIT_ARRAY/SHT_FINI_ARRAY section
types for .init_array/.fini_array output sections when they contain
.ctors/.dtors input sections. I have followup gcc/glibc patches to
remove .ctors/.dtors output sections. OK to install?
Thanks.
H.J.
---
bfd/
2010-12-14 H.J. Lu
* elf.c (_bfd_elf_new_section_hook): Special handling for
.init_array/.fini_array output sections.
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/bfd/elf.c b/bfd/elf.c
index 0e7cd9a..de0ab61 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -2304,12 +2304,19 @@ _bfd_elf_new_section_hook (bfd *abfd, asection *sec)
anyway. We will set ELF section type and flags for all linker
created sections. If user specifies BFD section flags, we will
set ELF section type and flags based on BFD section flags in
- elf_fake_sections. */
- if ((!sec->flags && abfd->direction != read_direction)
+ elf_fake_sections. Special handling for .init_array/.fini_array
+ output sections since they may contain .ctors/.dtors input
+ sections. We don't want _bfd_elf_init_private_section_data to
+ copy ELF section type from .ctors/.dtors input sections. */
+ if (abfd->direction != read_direction
|| (sec->flags & SEC_LINKER_CREATED) != 0)
{
ssect = (*bed->get_sec_type_attr) (abfd, sec);
- if (ssect != NULL)
+ if (ssect != NULL
+ && (!sec->flags
+ || (sec->flags & SEC_LINKER_CREATED) != 0
+ || ssect->type == SHT_INIT_ARRAY
+ || ssect->type == SHT_FINI_ARRAY))
{
elf_section_type (sec) = ssect->type;
elf_section_flags (sec) = ssect->attr;
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.
gcc-4.4-20101214 is now available
Snapshot gcc-4.4-20101214 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20101214/ 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 167819 You'll find: gcc-4.4-20101214.tar.bz2 Complete GCC (includes all of below) MD5=b0143e1521d279067bb6221e970753a5 SHA1=8ae41642806b5174aa669652e67fd75a7b740734 gcc-core-4.4-20101214.tar.bz2C front end and core compiler MD5=c4acf59f03a99b91f54a2286a9359f1b SHA1=4fd9a1b885d93d561da6d048b0a98530ae0ee768 gcc-ada-4.4-20101214.tar.bz2 Ada front end and runtime MD5=41db6b95304b0a2204442c1aea76617d SHA1=539674d12ba55791e1ad23aa180e342a03177611 gcc-fortran-4.4-20101214.tar.bz2 Fortran front end and runtime MD5=092097e7be2e6e3971c5d6835623ed71 SHA1=b77236e2e2425419038a9aaedfc2866fa5ce79e2 gcc-g++-4.4-20101214.tar.bz2 C++ front end and runtime MD5=d2093131def52974f9d69b5bc3f91a6e SHA1=6575b707c76bc8b5c0db01523f5f79f01eddd3bb gcc-java-4.4-20101214.tar.bz2Java front end and runtime MD5=1896a77977670c2ada22154422eee743 SHA1=9da98a822a770284080d1970f31cf637a9865f6d gcc-objc-4.4-20101214.tar.bz2Objective-C front end and runtime MD5=f6f2dd827b65c1d5daded17b1ab81067 SHA1=e1361480b84d92025fbc1441d8cd4a83e61d2df3 gcc-testsuite-4.4-20101214.tar.bz2 The GCC testsuite MD5=73fa7735fdf6a25aa835d2e298158f27 SHA1=c3d0a64f9fe8091ddea62a134adf1849a09819e2 Diffs from 4.4-20101207 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: C/C++ extensions for array notations
On Mon, Dec 13, 2010 at 6:08 PM, 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? > > 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. Looks similar to what I hacked into the C frontend to support middle-end arrays (well, hacked, as I used builtins). Richard.
gcc 4.5.1 Success compilation on RH ES 5.5
1) config.guess i686-pc-linux-gnu 2) gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/lib/../libexec/gcc/i686-pc-linux-gnu/4.5.1/lto-wrapper Target: i686-pc-linux-gnu Configured with: ./configure --with-gmp=/usr/local --with-mpc=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.5.1 (GCC) 3) cat /etc/issue Red Hat Enterprise Linux Server release 5.5 (Tikanga) Kernel \r on an \m 4) uname -a Linux soca.banksoyuz.ru 2.6.18-194.el5PAE #1 SMP Tue Mar 16 22:00:21 EDT 2010 i686 i686 i386 GNU/Linux 5) rpm -q glibc glibc-2.5-49 Sincerly Yours, Peter Dyachenko Chief Administrator IT Department JSC Bank "SOYUZ" Tel.: +7 (495) 729-55-55 (доб. 4-3018) Mobile.: +7 (916) 860-14-87 Fax: +7 (495) 729-55-08
Re: PATCH: Support mixing .init_array.* and .ctors.* input sections
On Tue, Dec 14, 2010 at 09:55:42AM -0800, H.J. Lu wrote:
> bfd/
>
> 2010-12-14 H.J. Lu
>
> * elf.c (_bfd_elf_new_section_hook): Special handling for
> .init_array/.fini_array output sections.
>
> 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.
OK. Except
> +static long int
unsigned long
> +get_init_priority (const char *name)
> +{
> + char *end;
> + long int init_priority;
unsigned long
> +
> + /* GCC uses the following section names for the init_priority
> + attribute with numerical values 101 and 65535 inclusive:
> +
> + 1: .init_array./.fini_array.: Where is the
> + decimal numerical value of the init_priority attribute.
> + 2: .ctors./.ctors.: Where is 65535 minus the
> + decimal numerical value of the init_priority attribute.
> + */
I would like to see this comment expanded. Specify what the
init_priority values mean, ie. a lower value means a higher priority.
Also specify the order of execution in .init_array and .fini_array.
>From memory .init_array is forward, .fini_array reverse, and just to
make things interesting .ctors/.dtors goes the other way, .ctors
reverse and .dtors forward.
> + if (strncmp (name, ".init_array.", 12) == 0
> + || strncmp (name, ".fini_array.", 12) == 0)
> +{
> + init_priority = strtoul (name + 12, &end, 10);
> + return *end ? 0 : init_priority;
> +}
> + else if (strncmp (name, ".ctors.", 7) == 0
> +|| strncmp (name, ".dtors.", 7) == 0)
> +{
> + init_priority = strtoul (name + 7, &end, 10);
> + return *end ? 0 : 65535 - init_priority;
> +}
> +
> + return 0;
> +}
> +
> /* Compare sections ASEC and BSEC according to SORT. */
>
> static int
> compare_section (sort_type sort, asection *asec, asection *bsec)
> {
>int ret;
> + long int ainit_priority, binit_priority;
unsigned long
> @@ -247,19 +274,16 @@ CTOR=".ctors${CONSTRUCTING-0} :
> linker won't look for a file to match a
> wildcard. The wildcard also means that it
> doesn't matter which directory crtbegin.o
> - is in. */
> + is in.
>
> -KEEP (*crtbegin.o(.ctors))
> -KEEP (*crtbegin?.o(.ctors))
> -
> -/* We don't want to include the .ctor section from
> + We don't want to include the .ctor section from
> the crtend.o file until after the sorted ctors.
> The .ctor section from the crtend file contains the
> end of ctors marker and it must be last */
>
> -KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o $OTHER_EXCLUDE_FILES) .ctors))
> -KEEP (*(SORT(.ctors.*)))
> -KEEP (*(.ctors))
> +KEEP (*crtbegin.o(.ctors))
> +KEEP (*crtbegin?.o(.ctors))
> +${CTORS}
> ${CONSTRUCTING+${CTOR_END}}
>}"
> DTOR=".dtors${CONSTRUCTING-0} :
> @@ -267,9 +291,7 @@ DTOR=".dtors${CONSTRUCTING-0} :
> ${CONSTRUCTING+${DTOR_START}}
> KEEP (*crtbegin.o(.dtors))
> KEEP (*crtbegin?.o(.dtors))
> -KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o $OTHER_EXCLUDE_FILES) .dtors))
> -KEEP (*(SORT(.dtors.*)))
> -KEEP (*(.dtors))
> +${DTORS}
> ${CONSTRUCTING+${DTOR_END}}
>}"
No need to make any changes to .ctors or .dtors. If .init_array
and .fini_array match input .ctors or .dtors sections, then any later
match will simply be ignored.
--
Alan Modra
Australia Development Lab, IBM
