Re: Some bugs in the GCC 4.3 release notes
On Tue, 10 Jun 2008, James Brown wrote: > The link the the GCC 4.3 release notes to the TR1 implementation > status page is dead. No more, fixed with the patch below. (This was one of the side effects of a documentation rewrite on the libstdc++ side.) > Also, the parallel mode page is somewhat unclear as to exactly _how_ > to substitute the parallel algorithms "on a piecemeal basis." Let me add the libstdc++ list where the experts are. Usually, user support questions should go to [EMAIL PROTECTED], not the general lists which is about the development _of_ GCC as opposed to _with_ GCC, but this may be something to hilight better in our documentation. Gerald -- Gerald (Jerry) Pfeifer [EMAIL PROTECTED] http://www.pfeifer.com/gerald/
Re: Mirror
Hi Alex, On Tue, 10 Jun 2008, Alex Korolev wrote: > I noticed I miss few important things in the first email regarding > mirror. > > Mirror name: gcc.releasenotes.org > Mirror url: http://gcc.releasenotes.org > Location: USA, TX > Supporter: [EMAIL PROTECTED] I looked into this, and it seems this mirror "only" carries our releases? http://gcc.gnu.org/mirrors.html is ment to list those sites that mirror gcc.gnu.org directly, including our weekly snapshots and RCs. For sites that carry releases, we refer to the main GNU mirror list. Gerald -- Gerald (Jerry) Pfeifer [EMAIL PROTECTED] http://www.pfeifer.com/gerald/
ftp://gcc.gnu.org/pub/gcc/snapshots cleanups
I realized that our full FTP tree at ftp://gcc.gnu.org/pub/gcc/ consumes 27GB overall. There is ample diskspace on gcc.gnu.org itself, but for (new) mirrors this is quite a bit, for example, so I went ahead and reduced this to 18G by removing some older snapshots (from 2007 and RCs for previous releases). Gerald
Re: Help requested on C++ template syntax (for Emacs development).
Hi, Ian!
On Tue, Jun 10, 2008 at 12:05:20PM -0700, Ian Lance Taylor wrote:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Alan Mackenzie <[EMAIL PROTECTED]> writes:
> >> I'm thinking of things like
> >> foo (a < b, c > d);
[ ]
> Oh, wait, I forgot about constructors. This is valid C++ code:
> template class a;
> class foo
> {
> foo (a < b, c > d);
> };
> extern void quux (int, int);
> void bar()
> {
> quux (e < b, c > d);
> }
> Inside the class foo, you've got a template, inside the function bar,
> you've got a function call.
> I think you're going to have a hard time with this.
Er, yes. ;-) Thank you very much for all the help. It's going to take
some while to sink in. C++ is a difficult language. Hopefully, in a few
months time, Emacs will be doing better than it currently is.
> Ian
--
Alan Mackenzie (Nuremberg, Germany).
PATH_MAX missing cross building gmon-sol2.c
I am crossing from i686-cygwin to sparc-solaris (my Sun cc won't compile gcc due to macros with empty parameters like in c-common.c): /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c: In function '_mcleanup': /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: error: 'PATH_MAX' undeclared (first use in this function) /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: error: (Each undeclared identifier is reported only once /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: error: for each function it appears in.) /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: warning: unused variable 'buf' make[3]: *** [/cygdrive/d/obj/cross-gcc/sparc-solaris/libgcc/gmon.o] Error 1 make[3]: Leaving directory `/cygdrive/d/obj/cross-gcc/gcc' make[2]: *** [gcc-extra-parts] Error 2 Could be my /usr/local/sparc-solaris/include is old. just add #define PATH_MAX 1024 D:\src\gcc-4.3.1\gcc\config\sparc>diff -u gmon-sol2.c.orig gmon-sol2.c --- gmon-sol2.c.orig2008-06-15 07:55:53.296875000 -0700 +++ gmon-sol2.c 2008-06-15 07:55:57.671875000 -0700 @@ -37,6 +37,8 @@ #include /* for creat() */ #include "coretypes.h" #include "tm.h" + +#define PATH_MAX 1024 #if 0 #include "sparc/gmon.h" I deliberately didn't put #ifndef in so that if it is defined, and this mismatches, will error. Thanks, - Jay
configuring in-tree gmp/mpfr with "none"?
When gcc configures the in-tree gmp/mpfr, why
does it use --host=none-${host_vendor}-${host_os}
--target=none-${host_vendor}-${host_os}
instead of --host=${host_alias} --target=${target_alias}
This "breaks" config.cache if used across directories, because the platforms
change.
I'm trying like:
mkdir /obj
cd /obj
/src/gcc/configure -cache-file=`pwd`/config.cache
# must delete the initial one as well, else another problem
rem config.cache
make
With the 4.3.1 release.
Thanks,
- Jay
Re: PATH_MAX missing cross building gmon-sol2.c
> I am crossing from i686-cygwin to sparc-solaris (my Sun cc won't compile > gcc due to macros with empty parameters like in c-common.c): > > /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c: In function '_mcleanup': > /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: error: 'PATH_MAX' > undeclared (first use in this function) > /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: error: (Each undeclared > identifier is reported only once > /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: error: for each function > it appears in.) /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: warning: > unused variable 'buf' make[3]: *** > [/cygdrive/d/obj/cross-gcc/sparc-solaris/libgcc/gmon.o] Error 1 make[3]: > Leaving directory `/cygdrive/d/obj/cross-gcc/gcc' > make[2]: *** [gcc-extra-parts] Error 2 > > Could be my /usr/local/sparc-solaris/include is old. Or a configuration problem, see PR target/28097. -- Eric Botcazou
Re: 4.4 deprecation proposals
"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > i[34567]86-*-coff* DJGPP is ix86-coff - how would this deprecation affect djgpp?
Re: 4.4 deprecation proposals
On Sun, 15 Jun 2008, DJ Delorie wrote: > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > > i[34567]86-*-coff* > > DJGPP is ix86-coff - how would this deprecation affect djgpp? I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think having generic CPU-*-OBJFMT triplets that really refer to a particular OS is a good idea. It's only certain generic triplets I'm proposing to deprecate. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Thread safety annotations and analysis in GCC
> "Le-Chun" == Le-Chun Wu <[EMAIL PROTECTED]> writes: Le-Chun> Here is the design doc for the proposed annotations: Le-Chun> http://docs.google.com/Doc?id=ddqtfwhb_0c49t6zgr I am curious to know how this compares to the kind of lock checking implemented in sparse, and in particular whether sparse annotations could easily be translated to this style. Tom
Re: 4.4 deprecation proposals
> I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think > having generic CPU-*-OBJFMT triplets that really refer to a > particular OS is a good idea. It's only certain generic triplets > I'm proposing to deprecate. DJGPP is ix86-pc-msdosdjgpp, yes. However, it's based on the ix86-coff code (djgpp is coff-based) but not 100% binary compatible (mostly due to the dos stub, but also due to preprocessor defines, libraries, etc). Likewise, Cygwin and MinGW are based on the ix86-coff code but with PE stubs and support for DLLs and such.
Re: 4.4 deprecation proposals
DJ Delorie <[EMAIL PROTECTED]> writes: >> I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think >> having generic CPU-*-OBJFMT triplets that really refer to a >> particular OS is a good idea. It's only certain generic triplets >> I'm proposing to deprecate. > > DJGPP is ix86-pc-msdosdjgpp, yes. However, it's based on the > ix86-coff code (djgpp is coff-based) but not 100% binary compatible > (mostly due to the dos stub, but also due to preprocessor defines, > libraries, etc). > > Likewise, Cygwin and MinGW are based on the ix86-coff code but with PE > stubs and support for DLLs and such. My understanding is that Joseph is just talking about removing the entries in config.gcc. He is not talking about removing the support in the code, except perhaps for cases where there is no longer any entry in config.gcc which requires that support. Ian
Re: 4.4 deprecation proposals
On Sun, 15 Jun 2008, Ian Lance Taylor wrote: > My understanding is that Joseph is just talking about removing the > entries in config.gcc. He is not talking about removing the support > in the code, except perhaps for cases where there is no longer any > entry in config.gcc which requires that support. Correct (libgcc/config.host, target patterns in testcases etc. are also covered). Files in config/ are only removed when no configuration uses them. If a file is removed while still being used by another target, that's a mistake and the file should be restored; if a file (formerly used by some targets) remains while no target uses it, that's also a mistake and it should be removed. -- Joseph S. Myers [EMAIL PROTECTED]
GCC-ICI V1.0 & GCC-ICI-PLUGINS V1.0 release (for the MILEPOST GCC)
Dear all, Just wanted to mention that we released the new version of GCC ICI and GCC ICI Plugins that are used in the MILEPOST GCC (machine learning based research compiler). I will be at the GCC Summit next week presenting this work and will be happy to discuss our current and future research & developments, however you can already get some hints from our Summit paper: http://gcc-ici.sourceforge.net/papers/fmtp2008.pdf We hope to release MILEPOST GCC (including Machine Learning routines from IBM Haifa) in summer'08 as a GCC branch. Some more info is available here: http://unidapt.org/software.html#milepostgcc Yours, Grigori Fursin Grigori Fursin, PhD Research Scientist, UNIDAPT Group, INRIA, France http://unidapt.org - tackling the complexity of future computing systems using machine learning
Re: RFC: Extend x86-64 psABI for 256bit AVX register
On Wed, Jun 11, 2008 at 07:49:12AM -0700, H.J. Lu wrote: > > I guess we all agree on passing variadic arguments on stack (that is > > only those belonging on ...) and rest in registers. It seems easiest in > > regard to future register set extensions too. Only negative thing is > > that calls to variadic functions will become bit longer, but I guess it > > is not big deal. (the fact that register passing conventions are shorter > > and variadic functions tends to be called many times was also original > > motivation to support register passing on pretty much everything for > > varargs in psABI) > > > > There is no precedent for passing named parameters in registers but > unnamed parameters on the stack. On IA32 for the __m128 types, we > pass ALL __m128 parameters on the stack for varargs functions, not > just the unnamed ones. I think we should do the same for x86-64. Why should the 32-bit ABI influence x86-64 ABI decisions? There are clear advantages of passing __m128 named arguments in registers (shorter/faster code both on the caller and callee side) and there are advantages of passing __m128 unnamed arguments on the stack (for va_arg to work, they need to be on the stack, and if they are passed in registers, the callee would need to push them to the stack). Jakub
Re: C++ warnings vs. errors
2008/6/13 Mark Mitchell: > Jonathan Wakely wrote: >> >> Hi Volker, thanks for picking these issues up. I told Manuel I'd >> review the rest of the remaining pedwarns, but haven't had time to do >> it either. > > Just to chime in here: Volker, I agree with your comments. I think we all do :-) > Jonathan, Manuel, if you would please make the time to finish this project, > that would be very much appreciated. We don't want this to be a case where > we improved the infrastructure of the compiler -- but made the user > experience worse. Absolutely agreed. I'm working on it. Sorry for the delay, until Volker's mail I didn't realise most of the pedwarns hadn't changed to permerrors already. Jon
Re: 4.4 deprecation proposals
On Sat, 2008-06-14 at 18:53 +, Joseph S. Myers wrote: > m68k-*-aout* > m68k-*-coff* These would be fine with me; there has been no interest in these targets in binutils-land for some time. Ben
Re: RFC: Extend x86-64 psABI for 256bit AVX register
> On Wed, Jun 11, 2008 at 07:49:12AM -0700, H.J. Lu wrote: > > > I guess we all agree on passing variadic arguments on stack (that is > > > only those belonging on ...) and rest in registers. It seems easiest in > > > regard to future register set extensions too. Only negative thing is > > > that calls to variadic functions will become bit longer, but I guess it > > > is not big deal. (the fact that register passing conventions are shorter > > > and variadic functions tends to be called many times was also original > > > motivation to support register passing on pretty much everything for > > > varargs in psABI) > > > > > > > There is no precedent for passing named parameters in registers but > > unnamed parameters on the stack. On IA32 for the __m128 types, we > > pass ALL __m128 parameters on the stack for varargs functions, not > > just the unnamed ones. I think we should do the same for x86-64. > > Why should the 32-bit ABI influence x86-64 ABI decisions? > There are clear advantages of passing __m128 named arguments in registers > (shorter/faster code both on the caller and callee side) and there > are advantages of passing __m128 unnamed arguments on the stack > (for va_arg to work, they need to be on the stack, and if they > are passed in registers, the callee would need to push them > to the stack). For record I would also preffer passing all named AVX arguments in registers. x86-64 ABI was designed for performance not for backward compatibility, so it should be consistent with original idea and I think that ABIs are divergent anough so this won't cause too much of extra confussion. But I am happy with both solutions. Honza > > Jakub
Re: newlib & libgcov
> Hello,
> In our GCC porting, we use newlib instead of libc. Today I tried to use
> profiling feedback based optimization with option -fprofile-arcs. But
> the executable doesn't produce .gcda file. I examined the disassembled
> binary file and found the following functions are basically just dummy
> ones: __gcov_init, __gcov_flush, __gcov_merge_add. I checked libgcov.c
> that contains these functions and found following code.
>
>
> #if defined(inhibit_libc)
I am not much expert in this area, but the inhibit_libc check here is
mainly to disable gcov functions for freestanding targets that don't
support normal IO. If you use newlib instead of glibc, you still do
have libc, so why inhibit_libc is defined at first place?
Honza
> /* If libc and its header files are not available, provide dummy
> functions. */
>
> #ifdef L_gcov
> void __gcov_init (struct gcov_info *p __attribute__ ((unused))) {}
> void __gcov_flush (void) {}
> #endif
>
> #ifdef L_gcov_merge_add
> void __gcov_merge_add (gcov_type *counters __attribute__ ((unused)),
> unsigned n_counters __attribute__ ((unused))) {}
> #endif
>
> #ifdef L_gcov_merge_single
> void __gcov_merge_single (gcov_type *counters __attribute__ ((unused)),
> unsigned n_counters __attribute__ ((unused)))
> {}
> #endif
>
> #ifdef L_gcov_merge_delta
> void __gcov_merge_delta (gcov_type *counters __attribute__ ((unused)),
>unsigned n_counters __attribute__ ((unused)))
> {}
> #endif
>
>
> Both -Dinhibit_libc and -DL_gcov are used as shown in our building log
> file. I guess -Dinhibit_libc is added because we used newlibc instead
> of glibc. I tried to grep these functions in newlibc and didn't find
> them. My question is how to enable gcov with newlibc. Do I need to
> write my own versions of them? Any suggestion is greatly appreciated.
>
> Cheers,
> Bingfeng Mei
>
> Broadcom UK
Re: C++ warnings vs. errors
Jonathan -- Thanks for pushing this forward! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 On Jun 15, 2008, at 7:06 PM, "Jonathan Wakely" <[EMAIL PROTECTED]> wrote: 2008/6/13 Mark Mitchell: Jonathan Wakely wrote: Hi Volker, thanks for picking these issues up. I told Manuel I'd review the rest of the remaining pedwarns, but haven't had time to do it either. Just to chime in here: Volker, I agree with your comments. I think we all do :-) Jonathan, Manuel, if you would please make the time to finish this project, that would be very much appreciated. We don't want this to be a case where we improved the infrastructure of the compiler -- but made the user experience worse. Absolutely agreed. I'm working on it. Sorry for the delay, until Volker's mail I didn't realise most of the pedwarns hadn't changed to permerrors already. Jon
