Re: SSE (Pentium 3) - Is this correct?
> Even if you fix that, gcc will only vectorize if you pass the
> -ftree-vectorize option. And it will only vectorize code in loops.
Supporting straight-line code vectorization is in the works, but at first
we'll look for such opportunities only in loops (i.e. exploit
vector-parallelism within an iteration rather than only across iterations).
So we'll be able to vectorize unrolled loops and such, but not the code
example in question, if it's not enclosed in any loop.
> And it unfortunately doesn't do a good job of using movups, so it will
> mess around with checking the alignment.
Yes, the way we handle unaligned stores is to peel the loop to make that
access aligned. We do use the movups for the load though. This is just a
random restriction that can easily be fixed - I have an old patch for
misaligned stores sitting around - I'll just go ahead and send it.
> And there isn't a good way
> to specify alignment.
>
> I do see use of the vector instructions for this example
>
>
> float *vector_add4f(float * __restrict va, float * __restrict vb)
> {
> int i;
>
> for (i = 0; i < 4; ++i)
> va[i] += vb[i];
> return va;
> }
>
> if I compile with -O2 -ftree-vectorize. Frankly the generated code is
> really awful, and I wouldn't be surprised if it runs more slowly than
> the non-vectorized code.
If the va access is unaligned the vectorized code will definitely be slower
than the original code, because the vector code will not be executed - just
the peel-loop before the vector-loop (that tries to align the store) and
the peel-loop after he vector-loop (for the remaining iterations). So we
will just have executed extra ifs/branches and the code size will have
increased. Probably even if the store is aligned it will not be much of a
win for such a small trip count. I have a small patch that lets you specify
the minimum number of vector iterations under which you don't want to allow
vectorization. I'll go ahead and send that too.
> This is evidently an area where the compiler
> could use more work.
>
True, and indeed there are people who are currently looking into adding a
cost model to the vectorizer. The patch I mentioned above would be a first
(trivial) step towards that.
dorit
> Ian
C++ overflow testcases failing on mainline
Dear all, It seems I managed to mess up the patch applied to revision 120558. The problem is that somehow all testcases have been added three times. I cannot imagine how such thing happenned. Anyway, I will fix it today as soon as I put my hands in my laptop. Is it better to revert and re-apply the original patch or just fix the testcases? I would guess that the former is the better since the original patch bootstrapped and regression tested without problems. Sorry for the inconvenience. Manuel.
Re: C++ overflow testcases failing on mainline
It seems I managed to mess up the patch applied to revision 120558. The problem is that somehow all testcases have been added three times. I cannot imagine how such thing happenned. You probably used "patch" which, instead of warning if a patch creates a file that is already there, happily puts the content of the file again at the beginning of it. Paolo
Test: Immobilien Hamburg
This is only a test on Immobilien Hamburg. So please ignore. http://www.hamburgimmobilie.de ___ Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos. Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02
Jan Hubicka and Uros Bizjak appointed i386 maintainers
I am pleased to announce that the GCC Steering Committee has appointed Jan Hubicka and Uros Bizjak as co-maintainers of the i386 port. Please join me in congratulating Jan and Uros on their new role. Jan and Uros, please update your listings in the MAINTAINERS file. Happy hacking! David
Re: [bug-gnulib] Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Richard Kenner wrote: > (3) How many programs are known to rely on wrap semantics? For each: > (a) How hard was it to determine there was a problem with that > assumption? A piece of data for GNU clisp and cln: - For clisp, it was easy to find out and fix all problems, because the package has a good testsuite coverage. It was just a matter of building the package with CFLAGS=-ftrapv, doing "make check", and debugging the abort() calls. 2 or 3 hours of work. Just 2 problems were found: - A loop: for (x=1; x != 0; x = x+x) ... This is the same idiom as Paul's example. - A bitmask computation that assumed two's complement arithmetic: if (n > 0) *p &= (unsigned int) ((1 << (32 - n)) - 1); - For cln, I fixed the easily spottable problems, but I completely ignore how many other problems remain - because the package has only a small testsuite, and gcc last week emitted no warnings when it exploits the C99 semantics of signed integer overflow. Bruno
Build problem with gcc 4.3.0 20070108 (experimental)
/tools/gcc/obj-i686-pc-linux-gnu/./prev-gcc/xgcc -B/tools/gcc/obj-i686-pc-linux-gnu/./prev-gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/tree-vectorizer.c -o tree-vectorizer.o cc1: warnings being treated as errors ../../gcc/gcc/tree-vectorizer.c:2267: warning: initialization from incompatible pointer type make[3]: *** [tree-vectorizer.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcjh.pod gcj-dbtool.pod grmiregistry.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gfdl.pod jv-scan.pod cpp.pod gjnih.pod gij.pod gpl.pod gfortran.pod gcc.pod make[3]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu' make: *** [bootstrap] Error 2 = _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/ _/_/_/_/ _/_/_/_/ - _/ _/ _/_/ _/_/ _/ _/ _/ _/_/ _/_/_/_/ _/_/ _/_/_/ _/ _/_/ _/_/_/_/ - _/_/ _/ _/_/ _/ _/ _/_/ _/ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/_/_/_/ - "It's not what you know that hurts you, It's what you know that ain't so." Will Rogers __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Build problem with gcc 4.3.0 20070108 (experimental)
On 1/8/07, George R Goffe <[EMAIL PROTECTED]> wrote: /tools/gcc/obj-i686-pc-linux-gnu/./prev-gcc/xgcc -B/tools/gcc/obj-i686-pc-linux-gnu/./prev-gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/tree-vectorizer.c -o tree-vectorizer.o cc1: warnings being treated as errors ../../gcc/gcc/tree-vectorizer.c:2267: warning: initialization from incompatible pointer type make[3]: *** [tree-vectorizer.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcjh.pod gcj-dbtool.pod grmiregistry.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gfdl.pod jv-scan.pod cpp.pod gjnih.pod gij.pod gpl.pod gfortran.pod gcc.pod make[3]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu' make: *** [bootstrap] Error 2 That's honza's patch - but bootstrap doesn't abort for me at that point. Richard.
Re: Fwd: Re: gcc 4.1.1 for mcore
Hello Nick, Thanks for your support. this is the error message I'm getting: " ... make[4]: Leaving directory `/proj/tec/alpeca_lite/users/alexgr/gcc/objdir1/gcc' /proj/tec/alpeca_lite/users/alexgr/gcc/objdir1/./gcc/xgcc -B/proj/tec/alpeca_lite/users/alexgr/gcc/objdir1/./gcc/ -B/usr/local/mcore-elf/bin/ -B/usr/local/mcore-elf/lib/ -isystem /usr/local/mcore-elf/include -isystem /usr/local/mcore-elf/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -DDONT_HAVE_STDIO -DDONT_HAVE_SETJMP -Dinhibit_libc -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -O3 -DNO_FLOATLIB_FIXUNSDFSI -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include -DL_floatdisf -c ../../gcc-4.1.1/gcc/libgcc2.c -o libgcc/./_floatdisf.o /tmp/ccvk5vjH.s: Assembler messages: /tmp/ccvk5vjH.s:38: Error: operand must be absolute in range 1..32, not 53 make[3]: *** [libgcc/./_floatdisf.o] Error 1 make[3]: Leaving directory `/proj/tec/alpeca_lite/users/alexgr/gcc/objdir1/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/proj/tec/alpeca_lite/users/alexgr/gcc/objdir1/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/proj/tec/alpeca_lite/users/alexgr/gcc/objdir1' make: *** [all] Error 2 attached are the library file compiled with -S option with the bmaski r4,53 wrong instruction form. and my configuration file. I run on a Linux machine with AMD CPU (x86_64). It runs 3.1.3-6.10 RedHat KDE release 2.4.21-32.EL Thanks again Alex. --- Nick Clifton <[EMAIL PROTECTED]> wrote: > Hi Alex, > > > I have some troubles with the MCORE GCC target, > (see > > below). Do have any idea what it can be and how to > > solve the problem? > > Yes - First unless you are constrained to only use > the 4.1.1 sources > please try using the current mainline gcc > development sources. It is > possible, but unlikely, that the bug has already > been fixed. > > Assuming that the problem persists, please could you > put together a > small test case to demonstrate it, including details > of how you > configured the toolchain and what sort of host > machine you are using. > If you could send this to me, but, *important*, CC > the email to the gcc > mailing list as well, then I can investigate and try > to fix the problem. > > >>> The compiler generates illigal form of bmaski > >>> instruction with operand out of range. > > Interesting. I have looked at the code locations > where this instruction > is generated and it appears to be correct. I will > be intrigued to see > how this bug is produced. > > Cheers >Nick > > > libgcc2.s Description: 846145001-libgcc2.s config.status Description: 881791177-config.status
Re: Fwd: Re: gcc 4.1.1 for mcore
Alexander Grobman wrote: /tmp/ccvk5vjH.s:38: Error: operand must be absolute in range 1..32, not 53 Some of the embedded target ports won't work if compiled on 64-bit hosts. mcore-elf seems to be one of them. This problem sometimes shows up as a gcc error and sometimes shows up as a binutils error, and sometimes both. Recompile as a 32-bit application (-m32), or build on a 32-bit linux host. Or file a bug report so this can be fixed. The important bit of info here isn't that the host processor is x86_64, but rather that you are running the 64-bit x86_64-linux OS on it. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Build problem with gcc 4.3.0 20070108 (experimental)
> >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu/gcc'
> >make[2]: *** [all-stage2-gcc] Error 2
> >make[2]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu'
> >make[1]: *** [stage2-bubble] Error 2
> >make[1]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu'
> >make: *** [bootstrap] Error 2
>
> That's honza's patch - but bootstrap doesn't abort for me at that point.
Hi,
I've comited the obvious fix. Sorry for that. I wonder why the
bootstrap doesn't fail on all targets?
Honza
Index: ChangeLog
===
*** ChangeLog (revision 120588)
--- ChangeLog (working copy)
***
*** 1,3
--- 1,7
+ 2007-01-08 Jan Hubicka <[EMAIL PROTECTED]>
+
+ * tree-vectorizer.c (gate_increase_alignment): Fix return type.
+
2007-01-08 Richard Guenther <[EMAIL PROTECTED]>
* tree-ssa-ccp.c (maybe_fold_offset_to_array_ref): Use type
Index: tree-vectorizer.c
===
*** tree-vectorizer.c (revision 120588)
--- tree-vectorizer.c (working copy)
*** increase_alignment (void)
*** 2255,2261
return 0;
}
! static int
gate_increase_alignment (void)
{
return flag_section_anchors && flag_tree_vectorize;
--- 2255,2261
return 0;
}
! static bool
gate_increase_alignment (void)
{
return flag_section_anchors && flag_tree_vectorize;
Re: Build problem with gcc 4.3.0 20070108 (experimental)
> > > >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu/gcc' > > >make[2]: *** [all-stage2-gcc] Error 2 > > >make[2]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu' > > >make[1]: *** [stage2-bubble] Error 2 > > >make[1]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu' > > >make: *** [bootstrap] Error 2 > > > > That's honza's patch - but bootstrap doesn't abort for me at that point. > > Hi, > I've comited the obvious fix. Sorry for that. I wonder why the > bootstrap doesn't fail on all targets? This only fixes on of the problems, the other one is function_and_variable_visibility needs to return unsigned int and 0. This fixes an ICE building libgcc for spu-elf on powerpc-linux-gnu. Thanks, Andrew Pinski
Re: Build problem with gcc 4.3.0 20070108 (experimental)
> >
> > > >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu/gcc'
> > > >make[2]: *** [all-stage2-gcc] Error 2
> > > >make[2]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu'
> > > >make[1]: *** [stage2-bubble] Error 2
> > > >make[1]: Leaving directory `/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu'
> > > >make: *** [bootstrap] Error 2
> > >
> > > That's honza's patch - but bootstrap doesn't abort for me at that point.
> >
> > Hi,
> > I've comited the obvious fix. Sorry for that. I wonder why the
> > bootstrap doesn't fail on all targets?
>
> This only fixes on of the problems, the other one is
> function_and_variable_visibility needs to return unsigned int and 0.
> This fixes an ICE building libgcc for spu-elf on powerpc-linux-gnu.
Hi,
I've commit the obvious fix too and I doubly apologize for the problems.
I've doublechecked that the patch tested ineed was the same as comitted
and it is the case. I don't see how it can possibly pass -Werror
bootstrap, will investigate it tomorrow.
Hope that all bootstraps are fine now!
Index: ChangeLog
===
--- ChangeLog (revision 120589)
+++ ChangeLog (working copy)
@@ -1,6 +1,7 @@
2007-01-08 Jan Hubicka <[EMAIL PROTECTED]>
* tree-vectorizer.c (gate_increase_alignment): Fix return type.
+ * ipa.c (function_and_variable_visibility): Fix return type.
2007-01-08 Richard Guenther <[EMAIL PROTECTED]>
Index: ipa.c
===
--- ipa.c (revision 120580)
+++ ipa.c (working copy)
@@ -220,7 +220,7 @@ cgraph_remove_unreachable_nodes (bool be
in language point of view but we want to overwrite this default
via visibilities for the backend point of view. */
-static void
+static unsigned int
function_and_variable_visibility (void)
{
struct cgraph_node *node;
@@ -272,6 +272,7 @@ function_and_variable_visibility (void)
fprintf (dump_file, "\n\n");
}
cgraph_function_flags_ready = true;
+ return 0;
}
struct tree_opt_pass pass_ipa_function_and_variable_visibility =
Re: Jan Hubicka and Uros Bizjak appointed i386 maintainers
> I am pleased to announce that the GCC Steering Committee has > appointed Jan Hubicka and Uros Bizjak as co-maintainers of the i386 port. > > Please join me in congratulating Jan and Uros on their new role. > Jan and Uros, please update your listings in the MAINTAINERS file. Thank you! I will try to start reviewing the i386 patches backlog shortly and I've updated the MAINTAINERS file by the attached patch. Honza Index: ChangeLog === --- ChangeLog (revision 120590) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2007-01-08 Jan Hubicka <[EMAIL PROTECTED]> + + * MAINTAINERS: Add myself as i386 maintainer. + 2007-01-08 Kai Tietz <[EMAIL PROTECTED]> * configure.in: Add support for an x86_64-mingw* target. Index: MAINTAINERS === --- MAINTAINERS (revision 120590) +++ MAINTAINERS (working copy) @@ -53,6 +53,7 @@ h8 port Kazu Hirata [EMAIL PROTECTED] hppa port Jeff Law[EMAIL PROTECTED] hppa port Dave Anglin [EMAIL PROTECTED] i386 port Richard Henderson [EMAIL PROTECTED] +i386 port Jan Hubicka [EMAIL PROTECTED] ia64 port Jim Wilson [EMAIL PROTECTED] iq2000 portNick Clifton[EMAIL PROTECTED] m32c port DJ Delorie [EMAIL PROTECTED]
gcc-4.1-20070108 is now available
Snapshot gcc-4.1-20070108 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070108/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 120594 You'll find: gcc-4.1-20070108.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070108.tar.bz2 C front end and core compiler gcc-ada-4.1-20070108.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070108.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070108.tar.bz2 C++ front end and runtime gcc-java-4.1-20070108.tar.bz2 Java front end and runtime gcc-objc-4.1-20070108.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070108.tar.bz2The GCC testsuite Diffs from 4.1-20061229 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: Build problem with gcc 4.3.0 20070108 (experimental)
--- Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > >
> > > > >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu/gcc'
> > > > >make[2]: *** [all-stage2-gcc] Error 2
> > > > >make[2]: Leaving directory
> > > > >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu'
> > > > >make[1]: *** [stage2-bubble] Error 2
> > > > >make[1]: Leaving directory
> > > > >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu'
> > > > >make: *** [bootstrap] Error 2
> > > >
> > > > That's honza's patch - but bootstrap doesn't abort for me at that point.
> > >
> > > Hi,
> > > I've comited the obvious fix. Sorry for that. I wonder why the
> > > bootstrap doesn't fail on all targets?
> >
> > This only fixes on of the problems, the other one is
> > function_and_variable_visibility needs to return unsigned int and 0.
> > This fixes an ICE building libgcc for spu-elf on powerpc-linux-gnu.
>
> Hi,
> I've commit the obvious fix too and I doubly apologize for the problems.
> I've doublechecked that the patch tested ineed was the same as comitted
> and it is the case. I don't see how it can possibly pass -Werror
> bootstrap, will investigate it tomorrow.
>
> Hope that all bootstraps are fine now!
>
> Index: ChangeLog
> ===
> --- ChangeLog (revision 120589)
> +++ ChangeLog (working copy)
> @@ -1,6 +1,7 @@
> 2007-01-08 Jan Hubicka <[EMAIL PROTECTED]>
>
> * tree-vectorizer.c (gate_increase_alignment): Fix return type.
> + * ipa.c (function_and_variable_visibility): Fix return type.
>
> 2007-01-08 Richard Guenther <[EMAIL PROTECTED]>
>
> Index: ipa.c
> ===
> --- ipa.c (revision 120580)
> +++ ipa.c (working copy)
> @@ -220,7 +220,7 @@ cgraph_remove_unreachable_nodes (bool be
> in language point of view but we want to overwrite this default
> via visibilities for the backend point of view. */
>
> -static void
> +static unsigned int
> function_and_variable_visibility (void)
> {
>struct cgraph_node *node;
> @@ -272,6 +272,7 @@ function_and_variable_visibility (void)
>fprintf (dump_file, "\n\n");
> }
>cgraph_function_flags_ready = true;
> + return 0;
> }
>
> struct tree_opt_pass pass_ipa_function_and_variable_visibility =
>
Jan,
I'm testing the build now. FC 6 (x86_64) on pentium 4 based HP XW 4300.
Regards,
George...
=
_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/ _/_/_/_/ _/_/_/_/ -
_/ _/ _/_/ _/_/ _/ _/
_/ _/_/ _/_/_/_/ _/_/ _/_/_/ _/ _/_/ _/_/_/_/ -
_/_/ _/ _/_/ _/ _/ _/_/ _/
_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/_/_/_/ -
"It's not what you know that hurts you, It's what you know that ain't so." Will
Rogers
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RFC: Speeding up libstdc++.so with --dynamic-list-data
I am enclosing a patch to implement a new linker swicth,
--dynamic-list-data. It is -Bsymbolic for function symbols only.
I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64
and Linux/ia64. There are only a few regressions. The function calls
within the new resulting DSOs will bind locally. It speeds up
the enclosed C++ testcase by
1. 23% on ia64.
2. 6% on ia32.
3. 3% on x86-64.
Should we consider such optimization?
H.J.
bfd/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* elf-bfd.h (bfd_elf_link_mark_dynamic_symbol): Add an
argument, Elf_Internal_Sym *.
* elflink.c (bfd_elf_link_mark_dynamic_symbol): Mark a data
symbol dynamic if info->dynamic_data is TRUE.
(bfd_elf_record_link_assignment): Updated call to
bfd_elf_record_link_assignment.
(_bfd_elf_merge_symbol): Likewise. Always call
bfd_elf_link_mark_dynamic_symbol.
include/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* bfdlink.h (bfd_link_info): Rename dynamic to dynamic_list.
Add dynamic and dynamic_data.
ld/
2007-01-05 H.J. Lu <[EMAIL PROTECTED]>
PR ld/3831
* ldlang.c (lang_process): Change link_info.dynamic to
link_info.dynamic_list.
(lang_append_dynamic_list): Likewise.
* ldmain.c (main): Likewise. Initialize link_info.dynamic and
link_info.dynamic_data to FALSE.
* lexsup.c (option_values): Add OPTION_DYNAMIC_LIST_DATA.
(ld_options): --dynamic-list-data.
(parse_args): Change link_info.dynamic to
link_info.dynamic_list. Set link_info.dynamic_data to TRUE for
--dynamic-list-data. Set link_info.dynamic to TRUE for
--dynamuc-list*.
--- binutils/bfd/elf-bfd.h.data 2007-01-08 10:05:49.0 -0800
+++ binutils/bfd/elf-bfd.h 2007-01-08 10:05:49.0 -0800
@@ -1858,7 +1858,8 @@ extern int bfd_elf_link_record_local_dyn
(struct bfd_link_info *, bfd *, long);
extern void bfd_elf_link_mark_dynamic_symbol
- (struct bfd_link_info *, struct elf_link_hash_entry *);
+ (struct bfd_link_info *, struct elf_link_hash_entry *,
+ Elf_Internal_Sym *);
extern bfd_boolean _bfd_elf_close_and_cleanup
(bfd *);
--- binutils/bfd/elflink.c.data 2007-01-08 10:05:49.0 -0800
+++ binutils/bfd/elflink.c 2007-01-08 17:42:35.0 -0800
@@ -454,14 +454,22 @@ bfd_elf_link_record_dynamic_symbol (stru
void
bfd_elf_link_mark_dynamic_symbol (struct bfd_link_info *info,
- struct elf_link_hash_entry *h)
+ struct elf_link_hash_entry *h,
+ Elf_Internal_Sym *sym)
{
- struct bfd_elf_dynamic_list *d = info->dynamic;
+ struct bfd_elf_dynamic_list *d = info->dynamic_list;
- if (d == NULL || info->relocatable)
+ /* It may be called more than once on the same H. */
+ if(h->dynamic || info->relocatable)
return;
- if ((*d->match) (&d->head, NULL, h->root.root.string))
+ if ((info->dynamic_data
+ && (h->type == STT_OBJECT
+ || (sym != NULL
+ && ELF_ST_TYPE (sym->st_info) == STT_OBJECT)))
+ || (d != NULL
+ && h->root.type == bfd_link_hash_new
+ && (*d->match) (&d->head, NULL, h->root.root.string)))
h->dynamic = 1;
}
@@ -499,7 +507,7 @@ bfd_elf_record_link_assignment (bfd *out
if (h->root.type == bfd_link_hash_new)
{
- bfd_elf_link_mark_dynamic_symbol (info, h);
+ bfd_elf_link_mark_dynamic_symbol (info, h, NULL);
h->non_elf = 0;
}
@@ -906,13 +914,17 @@ _bfd_elf_merge_symbol (bfd *abfd,
|| h->root.type == bfd_link_hash_warning)
h = (struct elf_link_hash_entry *) h->root.u.i.link;
+ /* We have to check it for every instance since the first few may be
+ refereences and not all compilers emit symbol type for undefined
+ symbols. */
+ bfd_elf_link_mark_dynamic_symbol (info, h, sym);
+
/* If we just created the symbol, mark it as being an ELF symbol.
Other than that, there is nothing to do--there is no merge issue
with a newly defined symbol--so we just return. */
if (h->root.type == bfd_link_hash_new)
{
- bfd_elf_link_mark_dynamic_symbol (info, h);
h->non_elf = 0;
return TRUE;
}
--- binutils/include/bfdlink.h.data 2006-10-30 15:25:51.0 -0800
+++ binutils/include/bfdlink.h 2007-01-08 10:05:49.0 -0800
@@ -340,6 +340,13 @@ struct bfd_link_info
caching ELF symbol buffer. */
unsigned int reduce_memory_overheads: 1;
+ /* TRUE if all data symbols should be dynamic. */
+ unsigned int dynamic_data: 1;
+
+ /* TRUE if some symbols have to be dynamic, controlled by
+ --dynamic-list command line options. */
+ unsigned int dynamic: 1;
+
/* What to do with unresolved symbols in an object file.
When producing executables the default is GENERATE_ERROR.
When producing shared libraries the default is IGNORE. T
Re: Build problem with gcc 4.3.0 20070108 (experimental)
Howdy,
The build succeeded.
Thanks for the help.
George...
--- Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > >
> > > > >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu/gcc'
> > > > >make[2]: *** [all-stage2-gcc] Error 2
> > > > >make[2]: Leaving directory
> > > > >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu'
> > > > >make[1]: *** [stage2-bubble] Error 2
> > > > >make[1]: Leaving directory
> > > > >`/rb.exphome/tools/gcc/obj-i686-pc-linux-gnu'
> > > > >make: *** [bootstrap] Error 2
> > > >
> > > > That's honza's patch - but bootstrap doesn't abort for me at that point.
> > >
> > > Hi,
> > > I've comited the obvious fix. Sorry for that. I wonder why the
> > > bootstrap doesn't fail on all targets?
> >
> > This only fixes on of the problems, the other one is
> > function_and_variable_visibility needs to return unsigned int and 0.
> > This fixes an ICE building libgcc for spu-elf on powerpc-linux-gnu.
>
> Hi,
> I've commit the obvious fix too and I doubly apologize for the problems.
> I've doublechecked that the patch tested ineed was the same as comitted
> and it is the case. I don't see how it can possibly pass -Werror
> bootstrap, will investigate it tomorrow.
>
> Hope that all bootstraps are fine now!
>
> Index: ChangeLog
> ===
> --- ChangeLog (revision 120589)
> +++ ChangeLog (working copy)
> @@ -1,6 +1,7 @@
> 2007-01-08 Jan Hubicka <[EMAIL PROTECTED]>
>
> * tree-vectorizer.c (gate_increase_alignment): Fix return type.
> + * ipa.c (function_and_variable_visibility): Fix return type.
>
> 2007-01-08 Richard Guenther <[EMAIL PROTECTED]>
>
> Index: ipa.c
> ===
> --- ipa.c (revision 120580)
> +++ ipa.c (working copy)
> @@ -220,7 +220,7 @@ cgraph_remove_unreachable_nodes (bool be
> in language point of view but we want to overwrite this default
> via visibilities for the backend point of view. */
>
> -static void
> +static unsigned int
> function_and_variable_visibility (void)
> {
>struct cgraph_node *node;
> @@ -272,6 +272,7 @@ function_and_variable_visibility (void)
>fprintf (dump_file, "\n\n");
> }
>cgraph_function_flags_ready = true;
> + return 0;
> }
>
> struct tree_opt_pass pass_ipa_function_and_variable_visibility =
>
=
_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/ _/_/_/_/ _/_/_/_/ -
_/ _/ _/_/ _/_/ _/ _/
_/ _/_/ _/_/_/_/ _/_/ _/_/_/ _/ _/_/ _/_/_/_/ -
_/_/ _/ _/_/ _/ _/ _/_/ _/
_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/_/_/_/ -
"It's not what you know that hurts you, It's what you know that ain't so." Will
Rogers
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote: > I am enclosing a patch to implement a new linker swicth, > --dynamic-list-data. It is -Bsymbolic for function symbols only. > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > and Linux/ia64. There are only a few regressions. The function calls > within the new resulting DSOs will bind locally. It speeds up > the enclosed C++ testcase by > > 1. 23% on ia64. > 2. 6% on ia32. > 3. 3% on x86-64. > > Should we consider such optimization? The real question is, does this work with operator new? In that if I a C++ developer provides a seperate operator new (and delete), does libstdc++ use that one as required by the C++ standard? Thanks, Andrew Pinski
Re: RFC: Speeding up libstdc++.so with --dynamic-list-data
On Mon, Jan 08, 2007 at 08:09:59PM -0800, Andrew Pinski wrote: > On Mon, 2007-01-08 at 18:25 -0800, H. J. Lu wrote: > > I am enclosing a patch to implement a new linker swicth, > > --dynamic-list-data. It is -Bsymbolic for function symbols only. > > I tried it with C, C++, Java and Fortran on Linux/ia32, Linux/x86-64 > > and Linux/ia64. There are only a few regressions. The function calls > > within the new resulting DSOs will bind locally. It speeds up > > the enclosed C++ testcase by > > > > 1. 23% on ia64. > > 2. 6% on ia32. > > 3. 3% on x86-64. > > > > Should we consider such optimization? > > The real question is, does this work with operator new? > > In that if I a C++ developer provides a seperate operator new (and > delete), does libstdc++ use that one as required by the C++ standard? These are the regressions I was talking about. I can support them with a new linker switch. So far, we have --dynamic-list-cpp-typeinfo Use C++ typeinfo dynamic list --dynamic-list FILE Read dynamic list My current proposal adds --dynamic-list-data Add data symbols to dynamic list I can add a new one --dynamic-list-cpp-new Add C++ new/delete to dynamic list Then we can build libstdc++ with --dynamic-list-data --dynamic-list-cpp-new H.J.
