Re: PR43839 almost fixed
On 22/04/2010 03:25, Jack Howarth wrote:
> @@ -267,7 +268,7 @@
># to just make the linker find libgcc using -L options.
># Similar logic applies to libgcj.
>if { [istarget "*-*-darwin*"] } {
> -lappend cxxflags -shared-libgcc -lgcj -liconv
> +lappend cxxflags "-shared-libgcc -lgcj $libiconv"
>}
> Can anyone explain why the above syntax ends up adding wrappering
> curly brackets around the evaluated $libiconv.
Because that's what lappend does: it takes a list of *multiple* arguments,
and appends them as list elements to a variable. By adding those gratuitous
quotes, you've turned the lappend command from multiple args into a single arg
with embedded spaces; you're thinking of shell scripting, but this is TCL.
http://www.google.com/search?q=tcl+lappend
brings up various man pages.
cheers,
DaveK
Re: g++ 4.5.0, end-user disappointment and interrogations
On 22/04/2010 03:30, tbp wrote: > What's the deal with constexpr (or what can i reasonably expect)? You can *reasonably* expect the documented behaviour from the compiler. Or you can *un*reasonably ignore the documentation, make ill-informed guesses about what the compiler ought to do, and complain when they turn out not to be correct. On 22/04/2010 07:29, tbp wrote: > Ah, so it was nothing but smokes & mirrors. No, you are merely ignorant of the facts. As it clearly says on the changes page: http://gcc.gnu.org/gcc-4.5/changes.html > Improved experimental support for the upcoming C++0x ISO C++ standard, > including support for raw strings, lambda expressions and explicit type > conversion operators. (notice no mention of constexpr there) and if you follow the link to the C++0x implementation status page: http://gcc.gnu.org/gcc-4.5/cxx0x_status.html > Language Feature ProposalAvailable in GCC 4.5? > Generalized constant expressions N2235 No so any disappointment is caused solely by your own baseless assumptions and failure to properly read and comprehend what was in front of your eyes. > Thanks for the clarification. Please, don't trouble yourself with adding insincere thanks to an insult; it's not worth the effort for you or anyone else so you may as well save yourself the time. cheers, DaveK
Re: GCC 4.5.0 Released
22.4.2010 1:35, Andreas Schwab kirjoitti: Paolo Bonzini writes: I'm not sure if "nm -g" would work under Linux, since $ nm -g /usr/lib64/libsqlite3.so nm: /usr/lib64/libsqlite3.so: no symbols $ objdump -T /usr/lib64/libsqlite3.so|head -5 The equivalent of "objdump -T" is "nm -D". Whatever the 'objdump -T' now tries to do during the 'gcc/configure', that it does with the wrong 'objdump', that for the $target, not that for the $host ! Maybe there was some usual one-eyeness in implementation, in a native GCC $host == $target, and it never was thought that someone could make a cross GCC ? This "feature" appeared when someone tried to build gcc-4.5.0 for 'arm-elf' on a x86_64 machine, seemingly the objdump made for arm-elf target and x86_64-linux-gnu host doesn't grok 64-bit ELF binaries... Meanwhile on a 32-bit i686-linux-gnu host there is no problem : [r...@dell gcc]# /usr/local/arm-elf/bin/objdump -T xgcc xgcc: file format elf32-little DYNAMIC SYMBOL TABLE: DF *UND* 0042 GLIBC_2.0 wait4 DF *UND* 0059 GLIBC_2.0 ferror DF *UND* 0167 GLIBC_2.0 strchr DF *UND* 01b2 GLIBC_2.1 fdopen 08076300 gDO .bss 0004 GLIBC_2.0 __ctype_tolower DF *UND* 0035 GLIBC_2.1 mempcpy
Re: GCC 4.5.0 Released
On 22/04/2010 09:16, Kai Ruottu wrote: > Whatever the 'objdump -T' now tries to do during the > 'gcc/configure', that it does with the wrong 'objdump', > that for the $target, not that for the $host ! > > Maybe there was some usual one-eyeness in implementation, > in a native GCC $host == $target, and it never was thought > that someone could make a cross GCC ? Yes, it's not an entirely uncommon mistake. (The fact that most target versions of objdump speak such a wide range of object formats may have helped it to be overlooked.) > This "feature" It's a bug, feel free to call it a bug! > appeared when someone tried to build > gcc-4.5.0 for 'arm-elf' on a x86_64 machine, seemingly > the objdump made for arm-elf target and x86_64-linux-gnu > host doesn't grok 64-bit ELF binaries... Right you are. So file a PR please, so that it doesn't get forgotten? cheers, DaveK
Re: GCC 4.5.0 Released
Jack Howarth writes:
> Index: configure.ac
> ===
> --- configure.ac(revision 158487)
> +++ configure.ac(working copy)
> @@ -4456,15 +4456,27 @@
> pluginlibs=
> if test x"$enable_plugin" = x"yes"; then
>
> + if test -z "$gcc_cv_objdump"; then
> +case "${host}" in
> + *-*-darwin*)
> +export_sym_check="$gcc_cv_nm -g"
> + ;;
> + *)
> +export_sym_check="$gcc_cv_nm -D"
> + ;;
> +esac
This is wrong at least on Solaris and IRIX, which don't have nm -D
either. Please restrict use of nm -D to platforms where it is known to
work.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC 4.5.0 Released
On Thu, Apr 22, 2010 at 10:38 AM, Rainer Orth
wrote:
> Jack Howarth writes:
>
>> Index: configure.ac
>> ===
>> --- configure.ac (revision 158487)
>> +++ configure.ac (working copy)
>> @@ -4456,15 +4456,27 @@
>> pluginlibs=
>> if test x"$enable_plugin" = x"yes"; then
>>
>> + if test -z "$gcc_cv_objdump"; then
>> + case "${host}" in
>> + *-*-darwin*)
>> + export_sym_check="$gcc_cv_nm -g"
>> + ;;
>> + *)
>> + export_sym_check="$gcc_cv_nm -D"
>> + ;;
>> + esac
>
> This is wrong at least on Solaris and IRIX, which don't have nm -D
> either. Please restrict use of nm -D to platforms where it is known to
> work.
And objdump does work on Solaris / IRIX?
Ciao!
Steven
Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)
On Thu, 2010-04-15 at 13:57 +0200, Basile Starynkevitch wrote: > (BTW I call lowlevel any language which does not manage memory > automatically; I am quite fond of Ocaml even if I don't use it much today. > So in my eyes C++, Ada95 & Fortran2005 are still low-level; this is only a > matter of taste & terminology). You didn't look very hard in the Ada Reference Manual :). Garbage collection support for Ada implementations is optional but defined in Ada since the first standard in 1983. All Ada standards (83/95/05) do have a "garbage collection" entry in their index wich lists the various parts of the standard interacting with absence or presence of automatic memory management, for example see "pragma Controlled". GNAT/GCC does not provide garbage collection but GNAT/dotnet and GNAT/Java do provide it so you can run Ada software these days without having to do manual memory management. Sincerely, Laurent
Re: GCC 4.5.0 Released
On Thu, 22 Apr 2010, Rainer Orth wrote: This is wrong at least on Solaris and IRIX, which don't have nm -D either. Please restrict use of nm -D to platforms where it is known to work. Uh? From what I can find, solaris 7 already had nm -D, and so do all later versions. http://docs.sun.com/app/docs/doc/805-3172/6j31br5j5 Do you mean its output is different enough that it is unusable here? Or that it is not installed by default? (SUNWbtool is already listed as a requirement in install/specific.html) -- Marc Glisse
Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)
On Wed, 2010-04-21 at 14:03 -0400, Robert Dewar wrote: > I do realize that some people are running gcc on very old > machines, that particularly happens say in developing > countries or with students or hobbyists using old cast > off machines. For those developping free software the compile farm has some nice iron: http://gcc.gnu.org/wiki/CompileFarm > And for those compile time is a problem, > but for out Ada users, many of whom have absolutely giant > programs of millions of lines, compile time speed has not > been an issue (we would know if it was, people would > tell us, they tell us of ANY problems they have). > > The one exception is that native compilation on VMS > is slow, but that's a consequence of the VMS file > system, where opening lots of small files is slow. > We are planning to encourage people using VMS to > switch to using PC-based cross-compilation. In my (limited) experience for daily development link times on the Windows platform for big Ada applications are an issue too, not compile times. Laurent
RE: branch probabilities on multiway branches
Thanks Edmar! I will try and work your patch into our GCC 4.4.1 port and get some results. Cheers, Rahul
Re: Code assistance with GCC
On Wed, Apr 21, 2010 at 06:23:44PM -0700, Chris Lattner wrote: > On Apr 21, 2010, at 1:51 PM, Manuel López-Ibáñez wrote: > http://cx4a.org/software/gccsense/ > >>> > >>> This approach seems highly, uh, "inspired" from the exact same > >>> functionality in Clang. Any reason not to contribute to that > >>> effort? > >> > >> Surely trying to persuade people to contribute to some other project > >> rather than gcc is off-topic here. Even if not, it's pretty hostile. > > > > Would such a feature be accepted in GCC? Otherwise, this seems like a > > misunderstanding. Chris was not suggesting to contribute to Clang > > instead of GCC but instead to contribute to the Clang completion > > library rather than create your own 1-person project. Or at least this > > is how I understood it. > > I actually meant to respond to him personally, I apologize for cc'ing the > list. > > I did this because the other responses made it seem that it wasn't > something that would be accepted back into GCC proper. Maintaining an Can you point at any response that said it would not be accepted back into GCC proper? There were no such comments AFAIK. All that has been said is that it is not possible to implement it AS A PLUGIN, at least not currently and would probably require way too many hook points unless it wants to do only code completion after . and -> (and not e.g. after :: and many other tokens). For C++ tentative parsing is probably the biggest problem that needs solving. Jakub
logos digitizing Madams/Sirs
Dear Madams/Sirs, 1.The lowest price for embroidery digitizing services.More discount available,please reply stand...@embpunching.com. US$2.50/1000 stitches () For details,you can visit http://www.embpunching.com PLEASE CONTACT US TO GET PRICE BROCHURE,OR AMOUNT DISCOUNT BROCHURE. 2.Sales for Embroidery Desings: Lowest price,Variety of designs Pls link to websiste:http://www.embsupply.net 3.Vector logos for screen printing for screen printing: One color: US$5.00 Two colors: US$10.00 Three colors: US$15.00 Exceed three colors:US$25.00 If you have any question,Pls do not hestitate to contact us at: stand...@embpunching.com Best regards Helen Embroidery Punching US tell: 989-785-0256 2010-04-22
Re: GCC 4.5.0 Released
On Thu, Apr 22, 2010 at 10:38:18AM +0200, Rainer Orth wrote:
> Jack Howarth writes:
>
> > Index: configure.ac
> > ===
> > --- configure.ac(revision 158487)
> > +++ configure.ac(working copy)
> > @@ -4456,15 +4456,27 @@
> > pluginlibs=
> > if test x"$enable_plugin" = x"yes"; then
> >
> > + if test -z "$gcc_cv_objdump"; then
> > +case "${host}" in
> > + *-*-darwin*)
> > +export_sym_check="$gcc_cv_nm -g"
> > + ;;
> > + *)
> > +export_sym_check="$gcc_cv_nm -D"
> > + ;;
> > +esac
>
> This is wrong at least on Solaris and IRIX, which don't have nm -D
> either. Please restrict use of nm -D to platforms where it is known to
> work.
>
> Rainer
>
Rainer,
Have you built gcc trunk with --enable-plugin on either
Solaris or Irix? What is the expectation of which compiler is
to be used to build the test code...
echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
I find on Irix 6.5 that the system compiler lacks -rdynamic so
that part of the test would fail unless a gcc compiler is
used. On Solaris 9, I have an ancient vendor supplied gcc 3.2.3
which doesn't seem to support -rdynamic either. It is unclear
to me how many additional utilities are expected to be installed
for FSF gcc to build on hosts like Irix or Solaris these days.
Jack
ps My inclination is to proceed with the current patch and
adjust it for Solaris and Irix later after the base tool
set is agreed upon for those hosts. That is, will users be
able to bootstrap FSF gcc using the system compiler and
--enable-plugin or will they have to install a previous
FSF gcc first.
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
unnecessary --enable-plugin tests
Looking at the results of the tests executed
by plugin.exp on x86_64 Fedora 10, I don't see
any evidence that -rdynamic is ever used. Can't
we reduce the tests performed as follow since
only -shared appears to be actually used? Removing
these tests would eliminate all of the problems
with not having 'nm -D' or objdump on different hosts.
Jack
ps I understand we are removing the test for
exported symbols but isn't that understood to
be satisfied when -shared is used?
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 158645)
+++ gcc/configure.ac(working copy)
@@ -4425,24 +4425,6 @@
pluginlibs=
if test x"$enable_plugin" = x"yes"; then
- AC_MSG_CHECKING([for exported symbols])
- echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
- ${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest > /dev/null 2>&1
- if $gcc_cv_objdump -T conftest | grep foobar > /dev/null; then
-: # No need to use a flag
- else
-AC_MSG_CHECKING([for -rdynamic])
-${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest > /dev/null
2>&1
-if $gcc_cv_objdump -T conftest | grep foobar > /dev/null; then
- plugin_rdynamic=yes
- pluginlibs="-rdynamic"
-else
- plugin_rdynamic=no
- enable_plugin=no
-fi
-AC_MSG_RESULT([$plugin_rdynamic])
- fi
-
# Check -ldl
saved_LIBS="$LIBS"
AC_SEARCH_LIBS([dlopen], [dl])
@@ -4453,7 +4435,14 @@
# Check that we can build shared objects with -fPIC -shared
saved_LDFLAGS="$LDFLAGS"
- LDFLAGS="$LDFLAGS -fPIC -shared"
+ case "${host}" in
+*-*-darwin*)
+ LDFLAGS="$LDFLAGS -fPIC -shared -undefined dynamic_lookup"
+;;
+*)
+ LDFLAGS="$LDFLAGS -fPIC -shared"
+;;
+ esac
AC_MSG_CHECKING([for -fPIC -shared])
AC_TRY_LINK(
[extern int X;],[return X == 0;],
@@ -4470,7 +4459,7 @@
if test x"$default_plugin" != x"yes"; then
AC_MSG_ERROR([
Building GCC with plugin support requires a host that supports
--fPIC, -shared, -ldl and -rdynamic.])
+-fPIC, -shared and -ldl.])
fi
fi
fi
Re: unnecessary --enable-plugin tests
Jack Howarth writes: >Looking at the results of the tests executed > by plugin.exp on x86_64 Fedora 10, I don't see > any evidence that -rdynamic is ever used. On GNU/Linux, in order to use plugins, it's necessary to use -rdynamic when linking cc1. Otherwise plugins will not be able to access many functions and variables in cc1. Darwin has a somewhat different model; I don't know if anything similar is required there. Ian
GCC 4.4.4 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 4.4.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.4-RC-20100422 and shortly its mirrors. It has been generated from SVN revision 158640. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. The branch is now frozen and all checkins until after the final release of GCC 4.4.4 require explicit RM approval. If all goes well, I'd like to release 4.4.4 next week.
Re: unnecessary --enable-plugin tests
On Thu, Apr 22, 2010 at 07:38:04AM -0700, Ian Lance Taylor wrote: > Jack Howarth writes: > > >Looking at the results of the tests executed > > by plugin.exp on x86_64 Fedora 10, I don't see > > any evidence that -rdynamic is ever used. > > On GNU/Linux, in order to use plugins, it's necessary to use -rdynamic > when linking cc1. Otherwise plugins will not be able to access many > functions and variables in cc1. > > Darwin has a somewhat different model; I don't know if anything > similar is required there. > > Ian Ian, Since the proposed patch on darwin (using 'nm -g') reports to configure that -rdynamic is unnecessary on darwin and the resulting gcc build generates code via dragon-egg, I believe we can infer that this isn't an issue on darwin. So I guess my current patch should be best... http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01345.html Of course, it should be adjusted later for Solaris and Irix once they sort out which set of devtools and utilities will be the baseline requirement of compiling plugin support (since the system compilers may not provide -rdynamic and objdump may not be present). Jack
Re: unnecessary --enable-plugin tests
On Thu, Apr 22, 2010 at 5:08 PM, Jack Howarth wrote: > On Thu, Apr 22, 2010 at 07:38:04AM -0700, Ian Lance Taylor wrote: >> Jack Howarth writes: >> >> > Looking at the results of the tests executed >> > by plugin.exp on x86_64 Fedora 10, I don't see >> > any evidence that -rdynamic is ever used. >> >> On GNU/Linux, in order to use plugins, it's necessary to use -rdynamic >> when linking cc1. Otherwise plugins will not be able to access many >> functions and variables in cc1. >> >> Darwin has a somewhat different model; I don't know if anything >> similar is required there. >> >> Ian > > Ian, > Since the proposed patch on darwin (using 'nm -g') reports > to configure that -rdynamic is unnecessary on darwin and the > resulting gcc build generates code via dragon-egg, I believe > we can infer that this isn't an issue on darwin. So I guess > my current patch should be best... > > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01345.html > > Of course, it should be adjusted later for Solaris and > Irix once they sort out which set of devtools and utilities > will be the baseline requirement of compiling plugin support > (since the system compilers may not provide -rdynamic and > objdump may not be present). If plugins work on Solaris and Irix currently then we shouldn't regress for them. Richard. > Jack > > >
Re: unnecessary --enable-plugin tests
On Thu, Apr 22, 2010 at 05:12:19PM +0200, Richard Guenther wrote:
> On Thu, Apr 22, 2010 at 5:08 PM, Jack Howarth
> wrote:
> > On Thu, Apr 22, 2010 at 07:38:04AM -0700, Ian Lance Taylor wrote:
> >> Jack Howarth writes:
> >>
> >> > Looking at the results of the tests executed
> >> > by plugin.exp on x86_64 Fedora 10, I don't see
> >> > any evidence that -rdynamic is ever used.
> >>
> >> On GNU/Linux, in order to use plugins, it's necessary to use -rdynamic
> >> when linking cc1. Otherwise plugins will not be able to access many
> >> functions and variables in cc1.
> >>
> >> Darwin has a somewhat different model; I don't know if anything
> >> similar is required there.
> >>
> >> Ian
> >
> > Ian,
> > Since the proposed patch on darwin (using 'nm -g') reports
> > to configure that -rdynamic is unnecessary on darwin and the
> > resulting gcc build generates code via dragon-egg, I believe
> > we can infer that this isn't an issue on darwin. So I guess
> > my current patch should be best...
> >
> > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01345.html
> >
> > Of course, it should be adjusted later for Solaris and
> > Irix once they sort out which set of devtools and utilities
> > will be the baseline requirement of compiling plugin support
> > (since the system compilers may not provide -rdynamic and
> > objdump may not be present).
>
> If plugins work on Solaris and Irix currently then we shouldn't
> regress for them.
Richard,
Okay, I've posted a fifth revision of this patch that reverts
to using "$gcc_cv_objdump -T" on non-darwin hosts as before. I
also verified objdump from binutils 2.20.1 on powerpc-apple-darwin9
that darwin doesn't require -rdynamic to export symbols...
echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
gcc conftest.c -o conftest
objdump -T conftest | grep foobar
0f69 g 0f SECT 01 .text _foobar
Jack
>
> Richard.
>
> > Jack
> >
> >
> >
Re: vectorization, scheduling and aliasing
Hi Richard,
2010/4/14, Richard Guenther :
> On Wed, Apr 14, 2010 at 8:48 AM, roy rosen wrote:
> > Hi All,
> >
> > I have implemented some vectorization features in my gcc port.
> >
> > In the generated code for this function I can see a scheduling problem:
> >
> > int xxx(int* __restrict__ a, int* __restrict__ b)
> > {
> >int __restrict__ i;
> >for (i = 0; i < 8; i++)
> >{
> >a[i] = b[i];
> >}
> >return 0;
> > }
> >
> > from asmcons:
> >
> > (insn 17 14 18 3 a.c:15 (set (reg:V4HI 105)
> >(mem:V4HI (reg/v/f:SI 100 [ b ]) [2 S8 A64])) 115 {*movv4hi_load}
> > (nil))
> >
> > (insn 18 17 19 3 a.c:15 (set (mem:V4HI (reg/v/f:SI 99 [ a ]) [2 S8 A64])
> >(reg:V4HI 105)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI
> > 105)
> >(nil)))
> >
> > (insn 19 18 20 3 a.c:15 (set (reg:V4HI 106)
> >(mem:V4HI (plus:SI (reg/v/f:SI 100 [ b ])
> >(const_int 8 [0x8])) [2 S8 A64])) 115 {*movv4hi_load}
> > (expr_list:REG_DEAD (reg/v/f:SI 100 [ b ])
> >(nil)))
> >
> > (insn 20 19 58 3 a.c:15 (set (mem:V4HI (plus:SI (reg/v/f:SI 99 [ a ])
> >(const_int 8 [0x8])) [2 S8 A64])
> >(reg:V4HI 106)) 116 {*movv4hi_store} (expr_list:REG_DEAD (reg:V4HI
> > 106)
> >(expr_list:REG_DEAD (reg/v/f:SI 99 [ a ])
> >(nil
> >
> > from sched1 - dependecies list:
> > --- Region Dependences --- b 3 bb 0
> > ;; insn codebb dep prio cost reservation
> > ;; -- --- ---
> > ;; 17 115 3 0 4 1 (2_slots+lsu) : 58 20 18
> > ;; 18 116 3 1 3 1 (2_slots+lsu) : 58 19
> > ;; 19 115 3 1 2 1 (2_slots+lsu) : 58 20
> > ;; 20 116 3 2 1 1 (2_slots+lsu) : 58
> > ;; 58 101 3 4 1 1 (3_slots+pcu) :
> >
> > As you can see, insn 19 is dependant on 18.
> > I think that this should not happen since the arrays has __restrict__.
> > It might have something to do with aliasing.
> >
> > Are you aware of any kind of problems regarding aliasing and vectors?
> > Can you think of anything else that might be wrong in my code that
> > leads gcc to think that there is a dependency between insn 18 and 19?
>
> It completely depends on the GCC version you are using. The
> MEM_EXPRs suggest that it is maybe 4.4 or 4.5 based? Because
> they are not existant. Try recent trunk which should work fine.
>
> Richard.
>
> > Thanks, Roy.
> >
>
I have taken 4.5.0 and I still get the same problem.
Do you have any ideas? Shouldn't the restrict tell the compiler that
there is no dependency between these insns?
Thanks, Roy.
Re: Code assistance with GCC
On Apr 22, 2010, at 4:29 AM, Jakub Jelinek wrote: >> >> I did this because the other responses made it seem that it wasn't >> something that would be accepted back into GCC proper. Maintaining an > > Can you point at any response that said it would not be accepted back into > GCC proper? There were no such comments AFAIK. All that has been said > is that it is not possible to implement it AS A PLUGIN, Nope, you are correct. Again, the cc was a mistake and I apologize for it. > at least not currently > and would probably require way too many hook points unless it wants to do > only code completion after . and -> (and not e.g. after :: and many other > tokens). For C++ tentative parsing is probably the biggest problem that > needs solving. I predict it won't be accepted into GCC mainline either, but we'll see. :) -Chris
Re: g++ 4.5.0, end-user disappointment and interrogations
On Thu, Apr 22, 2010 at 12:44 AM, Dave Korn wrote: > On 22/04/2010 03:30, tbp wrote: > >> What's the deal with constexpr (or what can i reasonably expect)? > > You can *reasonably* expect the documented behaviour from the compiler. Or > you can *un*reasonably ignore the documentation, make ill-informed guesses > about what the compiler ought to do, and complain when they turn out not to be > correct. > > On 22/04/2010 07:29, tbp wrote: > >> Ah, so it was nothing but smokes & mirrors. > > No, you are merely ignorant of the facts. As it clearly says on the changes > page: > > http://gcc.gnu.org/gcc-4.5/changes.html >> Improved experimental support for the upcoming C++0x ISO C++ standard, >> including support for raw strings, lambda expressions and explicit type >> conversion operators. > > (notice no mention of constexpr there) and if you follow the link to the C++0x > implementation status page: > > http://gcc.gnu.org/gcc-4.5/cxx0x_status.html >> Language Feature Proposal Available in GCC 4.5? >> Generalized constant expressions N2235 No > > so any disappointment is caused solely by your own baseless assumptions and > failure to properly read and comprehend what was in front of your eyes. > >> Thanks for the clarification. > > Please, don't trouble yourself with adding insincere thanks to an insult; > it's not worth the effort for you or anyone else so you may as well save > yourself the time. Hi, Is there really a need for an angry reply like this? Is it better to just give some advises instead? David > > cheers, > DaveK >
Re: g++ 4.5.0, end-user disappointment and interrogations
On 22 April 2010 18:50, Xinliang David Li wrote: > > Hi, Is there really a need for an angry reply like this? Is it better > to just give some advises instead? > I just want to express that I agree with David's sentiment and the above behaviour is not representative of GCC's community, not mater whether the original post did or didn't insult. If you think that he was insulting or trolling, just do not reply, delete the message and put that time and energy on checking some unconfirmed PR in bugzilla. You will live longer and make gcc better ;-) Cheers, Manuel.
Re: GCC 4.5.0 Released
Marc Glisse writes: > On Thu, 22 Apr 2010, Rainer Orth wrote: > >> This is wrong at least on Solaris and IRIX, which don't have nm -D >> either. Please restrict use of nm -D to platforms where it is known to >> work. > > Uh? From what I can find, solaris 7 already had nm -D, and so do all later > versions. > http://docs.sun.com/app/docs/doc/805-3172/6j31br5j5 > > Do you mean its output is different enough that it is unusable here? Or > that it is not installed by default? (SUNWbtool is already listed as a > requirement in install/specific.html) Sorry, this is partially my fault: I've just invoked nm -D without a filename and didn't see -D listed in the usage message. I'll file a CR for that. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC 4.5.0 Released
Steven Bosscher writes: >> This is wrong at least on Solaris and IRIX, which don't have nm -D >> either. Please restrict use of nm -D to platforms where it is known to >> work. > > And objdump does work on Solaris / IRIX? Sure: all plugin tests pass on both platforms, and objdump is used by the testsuite for some (all?) visibility tests. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Linux Plumbers Conference 2010 Call for Tracks
Hi, I wanted to point people to the Linux Plumbers Conference Call for Ideas. The conference is in its 3rd year, and it will take place in Boston, in November. I think it would be a good opportunity to bring the various communities together. Here is the official text, if you have any ideas for topics please submit them. Also if you have questions, please ask me offline. thanks elena Linux Plumbers Conference 2010 Call for Tracks This year, Linux Plumbers Conference will take place in Cambridge, MA on November 3-5, 2010. Unlike more traditional conferences, the Plumbers conference is not structured around presentations of completed work, or problems and solutions confined to a single subsystem or layer of the Linux ecosystem. Rather the Plumbers Conference encourages BOFs type meetings and brainstorming sessions where technical experts from different areas and leaders in the Linux and Open Source world can get together and discuss how to make progress towards the solution of interdisciplinary multifaceted problems spanning multiple components of the Linux system. In some sense, the Plumbers Conference is really more of a workshop. The program committee for the Linux Plumbers Conference is looking for proposals for the "tracks" that will be run during the Plumbers Conference. To do that, we are looking for "problem statements": things that could be improved in Linux that cross multiple interfaces or other project boundaries (if you can solve it yourself inside a single project, please, don't let us stop you --- get hacking!). We are looking for problems that require collaboration and face-to-face communication across multiple teams and open source projects. These problems could apply to anywhere Linux is used: Linux on the Desktop, Linux on Mobile devices, Linux on servers, etc. For example, if in order to get better performance, we need to get better information about low-level devices from the kernel, and that needs to be utilized by file system utilities, and the user needs to be able to involved by exposing options at the UI level in control panels and distribution installers --- the Plumbers conference might be a great place to get everyone in the same room for half a day to solve this particular problem. Along with your problem statements or track ideas, please list the projects which and/or key individuals who ideally should be present, and who might be a good person or persons to run such a conference track. If you have any thoughts or contributions, you can either * discuss them on this Linux Weekly News page: http://lwn.net/Articles/lpc2010-cfi/ * add the proposed topic to the Topics wiki page: http://wiki.linuxplumbersconf.org/2010:topics * send e-mail to: lpc-plann...@linuxplumbersconf.org Many thanks for helping to make Linux an even better platform! The 2010 LPC Committee Note: The event will be co-located with the Linux Kernel Summit which will be held earlier that week. Please feel free to forward this announcements to any communities or mailing lists where you think it would be appropriate.
Re: Some benchmark comparison of gcc4.5 and dragonegg (was dragonegg in FSF gcc?)
Robert Dewar wrote: Vladimir Makarov wrote: Although it is not right argument to what you mean. But example about vectorization would be right. ICC vectorizes many more loops than gcc does. Vectorized loops is much bigger in size than their non-vectorized variants. So faster code does not mean smaller code in general. There are a lot of optimization which makes code bigger and faster: like function versioning (based on argument values), aggressive inlining, modulo scheduling, vectorization, loop unrolling, loop versioning, loop tiling etc. So even if the both compiler do the same optimizations and if one compiler is more successful in such optimizations, the generated code will be bigger and faster. Sure, we can all find such examples, but if you take a large program, (say hundreds of thousands of lines), you will find that the speed vs size relation holds pretty well. Definitely not for Intel compiler and not for modern x86_64 processors (although it is most probably true for some other processors like ARM). ICC really generates much bigger code than GCC even we take subtarget versioning away. The closest analog on x86_64 for gcc -O3 would be -O3 -xT for icc. -xT means generating code only one subtarget which is Core2. I tried to compile the biggest one file program I have (about 500K lines). ICC crashed on it because there is not enough memory (8GB) in comparison with gcc which is doing fine with 2GB memory. So I had to check SPEC2006. In average the code increase on all SPEC2006 for ICC was 34%. But because you mentioned programs with hundreds of thousands of lines, I am also giving numbers for some programs from SPEC2006. lines Intel code size increase gromacs400K23% tonto 125K29% wrf115K44% gobmk 197K-2% Already long ago I got impression that ICC is good mostly for FP programs (for integer benchmarks gcc frequently generates a better code) but if icc stays its course, gcc will be always a better system compiler.
Re: GCC 4.5.0 Released
Jack Howarth writes: >Have you built gcc trunk with --enable-plugin on either > Solaris or Irix? What is the expectation of which compiler is No need: plugins just work on both platforms, both with the vendor tools and gld (on Solaris, gld is currently broken for IRIX). > I find on Irix 6.5 that the system compiler lacks -rdynamic so > that part of the test would fail unless a gcc compiler is Doesn't matter: even if you bootstrap with the vendor compiler (works on Solaris, still on my agenda for IRIX), stages 2 and 3 are built with gcc. With the native linkers, -rdynamic isn't needed and gcc/configure.ac handles this just fine. In my case, I had to introduce -rdynamic support into gcc so plugins work with gld: PATCH: Handle -rdynamic on Solaris 2 with GNU ld http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01458.html > used. On Solaris 9, I have an ancient vendor supplied gcc 3.2.3 > which doesn't seem to support -rdynamic either. It is unclear > to me how many additional utilities are expected to be installed > for FSF gcc to build on hosts like Irix or Solaris these days. That's certainly an important goal: currently, we have several hidden dependencies like that that influence what features the GCC just build has. This should be made more transparent. > ps My inclination is to proceed with the current patch and > adjust it for Solaris and Irix later after the base tool > set is agreed upon for those hosts. That is, will users be > able to bootstrap FSF gcc using the system compiler and > --enable-plugin or will they have to install a previous > FSF gcc first. As I said, the bootstrap compiler isn't relevant here. But *please* avoid introducing new failure modes for other platforms in your effort to improve Darwin support. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC 4.5.0 Released
On Thu, Apr 22, 2010 at 08:44:32PM +0200, Rainer Orth wrote: > Jack Howarth writes: > > >Have you built gcc trunk with --enable-plugin on either > > Solaris or Irix? What is the expectation of which compiler is > > No need: plugins just work on both platforms, both with the vendor tools > and gld (on Solaris, gld is currently broken for IRIX). > > > I find on Irix 6.5 that the system compiler lacks -rdynamic so > > that part of the test would fail unless a gcc compiler is > > Doesn't matter: even if you bootstrap with the vendor compiler (works on > Solaris, still on my agenda for IRIX), stages 2 and 3 are built with > gcc. With the native linkers, -rdynamic isn't needed and > gcc/configure.ac handles this just fine. In my case, I had to introduce > -rdynamic support into gcc so plugins work with gld: > > PATCH: Handle -rdynamic on Solaris 2 with GNU ld > http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01458.html > > > used. On Solaris 9, I have an ancient vendor supplied gcc 3.2.3 > > which doesn't seem to support -rdynamic either. It is unclear > > to me how many additional utilities are expected to be installed > > for FSF gcc to build on hosts like Irix or Solaris these days. > > That's certainly an important goal: currently, we have several hidden > dependencies like that that influence what features the GCC just build > has. This should be made more transparent. > > > ps My inclination is to proceed with the current patch and > > adjust it for Solaris and Irix later after the base tool > > set is agreed upon for those hosts. That is, will users be > > able to bootstrap FSF gcc using the system compiler and > > --enable-plugin or will they have to install a previous > > FSF gcc first. > > As I said, the bootstrap compiler isn't relevant here. But *please* > avoid introducing new failure modes for other platforms in your effort > to improve Darwin support. > Rainer, My last proposed version... http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01394.html will behave identically to current gcc trunk on all hosts but darwin. Jack > Thanks. > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University
gcc-4.5-20100422 is now available
Snapshot gcc-4.5-20100422 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100422/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 158656 You'll find: gcc-4.5-20100422.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100422.tar.bz2 C front end and core compiler gcc-ada-4.5-20100422.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100422.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100422.tar.bz2 C++ front end and runtime gcc-java-4.5-20100422.tar.bz2 Java front end and runtime gcc-objc-4.5-20100422.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100422.tar.bz2The GCC testsuite Diffs from 4.5-20100415 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: Code assistance with GCC
On Wed, Apr 21, 2010 at 12:49, Andrew Haley wrote: > On 04/21/2010 06:35 PM, Chris Lattner wrote: >> This approach seems highly, uh, "inspired" from the exact same >> functionality in Clang. Any reason not to contribute to that >> effort? > > Surely trying to persuade people to contribute to some other project > rather than gcc is off-topic here. Even if not, it's pretty hostile. Chris Lattner of Apple Chief architect of the LLVM project and Clang. Andrew Haley of Red Hat Maintainer of the GCC's Java frontend. Michael Witten Preparer of Popcorn. :-D
Re: g++ 4.5.0, end-user disappointment and interrogations
On 22/04/2010 17:50, Xinliang David Li wrote: > > Hi, Is there really a need for an angry reply like this? Is it better > to just give some advises instead? Ok, here is a non-angry reply to the angry post by tbp: http://en.wiktionary.org/wiki/smoke_and_mirrors > Noun > > smoke and mirrors > >1. (idiomatic) A deceptive, fraudulent, or unconvincing explanation or > description. Dear tbp, please don't accuse people of being deceptive or fraudulent, it is not a nice thing to do. cheers, DaveK
Re: Code assistance with GCC
Chris Lattner writes: >>> I did this because the other responses made it seem that it wasn't >>> something that would be accepted back into GCC proper. Maintaining an >> >> Can you point at any response that said it would not be accepted back into >> GCC proper? There were no such comments AFAIK. All that has been said >> is that it is not possible to implement it AS A PLUGIN, > > Nope, you are correct. Again, the cc was a mistake and I apologize for it. But people aren't objecting to the CC, they're objecting to the message you were (apparently) trying to send to the original poster. If anything, the CC was _good_, because it allowed some measure of debate. -Miles -- Fast, small, soon; pick any 2.
Re: g++ 4.5.0, end-user disappointment and interrogations
On Fri, Apr 23, 2010 at 5:48 AM, Dave Korn wrote: > Dear tbp, please don't accuse people of being deceptive or fraudulent, it is > not a nice thing to do. Indeed. That wasn't the intent. Seeing libstdc++ being combed over for constexpr, i've conveniently fooled myself into believing my hopes were realised. That i am ignorant, hermetic to facts and terminally clueless is, i fear, congruent to my current condition of end-user. PS: If not for the risk of further aggravation, i'd contend that i have nowhere accused people; but that's best forgotten.
Re: g++ 4.5.0, end-user disappointment and interrogations
On 23/04/2010 05:47, tbp wrote: > On Fri, Apr 23, 2010 at 5:48 AM, Dave Korn wrote: >> Dear tbp, please don't accuse people of being deceptive or fraudulent, it is >> not a nice thing to do. > Indeed. That wasn't the intent. I apologise, I thought it was your intent but I believe you when you say it was not meant that way. cheers, DaveK
