-print-* command-line switches misbehave or are misdocumented
Some of the -print-* command-line switches either don't work as advertised or their documentation should be made more clear. All of the examples below are with the following version of GCC: gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I also tested with this version, with the same results. gcc (GCC) 3.4.2 (mingw-special) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Please tell whether I should submit a bug report for some or all of the below. 1. -print-multi-directory: Documentation is confusing and unclear. The manual says: `-print-multi-directory' Print the directory name corresponding to the multilib selected by any other switches present in the command line. This directory is supposed to exist in `GCC_EXEC_PREFIX'. But without having ``multilib'' explained anywhere else in the manual, let alone having a cross-reference here to such a description, there's no way to understand what this switch does. 2. -print-multi-lib: Same issue as with the previous switch. 3. -print-prog-name: Works only for some programs; manual text misleading. The manual says: `-print-prog-name=PROGRAM' Like `-print-file-name', but searches for a program such as `cpp'. It fails to say what programs will this work with. The example it gives, `cpp' doesn't work: e...@fencepost:~$ gcc -print-prog-name=cpp cpp Similarly, it doesn't work with `gcc' itself, which seems a pity, as it doesn't allow to write scripts that discover where GCC lives. It works with cc1: e...@fencepost:~$ gcc -print-prog-name=cc1 /usr/lib/gcc/x86_64-linux-gnu/4.0.3/cc1 However, the manual should at least give a hint about which values of PROGRAM will work here, and the example with `cpp' should be removed. Thanks.
gtyp-input.list should contain absolute paths.
Hello all,
gengtype how has a plugin mode (when invoked with -p as the first
program argument after gengtype).
It would be much easier for plugins if gtyp-input.list contained only
absolute paths. In my case, (AMD64/Debian/Sid), it contains only two
relative filepaths: auto-host.h & options.h
If gtyp-input.list contained only absolute path, plugins wanting
gengtype could use that very list. Otherwise, they have to hack it to
replace relative file paths (relative to the build directory) by
absolute ones.
I tried to replace in gcc/Makefile.in near line 3437
s-gtyp-input: Makefile
@: $(call write_entries_to_file,$(GTFILES),tmp-gi.list)
$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list
$(STAMP) s-gtyp-input
with
s-gtyp-input: Makefile
@: $(call write_entries_to_file,$(realpath $(GTFILES)),tmp-gi.list)
$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list
$(STAMP) s-gtyp-input
but it does not work. However, I am unfamiliar with GNU make user
functions and cannot understand how write_entries_to_file work.
Does anyone have a suggestion, or preferably a tiny patch?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
VTA compile time memory usage comparison
On Mon, Jun 08, 2009 at 01:35:34PM -0400, Diego Novillo wrote: > On Sun, Jun 7, 2009 at 16:04, Alexandre Oliva wrote: > > > So the question is, what should I measure? Memory use for any specific > > set of testcases, summarized over a bootstrap with memory use tracking > > enabled, something else? Likewise for compile time? What else? > > Some quick measurements I'd be interested in: > > - Size of the IL over some standard code bodies > (http://gcc.gnu.org/wiki/PerformanceTesting). > - Memory consumption in cc1/cc1plus at -Ox -g over that set of apps. Here are data comparing tr...@148582 (last merge point to VTA branch) with v...@149180 (current VTA branch head), using maxmem2.sh and maxmem-pipe2.py. Both compilers were built with --enable-checking=release, all numbers are on x86_64-linux from cc1 resp. cc1plus (*.i resp. *.ii) with -g -quiet and the options listed in the header line. The only major compile time memory consumption problem is in VARIOUS/, particularly pr28071.i where var-tracking goes through roof, I hope Alex will look into it, worst case we could just silently turn off flag_var_tracking_assignments in var-tracking.c for functions which have too many basic blocks and too many VALUEs to track. I'm now running compilations with -ftime-report, once that finishes will post statistics for compile time as well, then size of IL. -O0-m64 -O0-m32 -O1-m64 -O1-m32 -O2-m64 -O2-m32 -O3-m64 -O3-m32 -Os-m64 -Os-m32 GCC tr...@148582 avg103772 102936 105455 104689 106334 105539 108212 107044 105339 104666 GCC v...@149180 avg 103773 102937 106076 105426 106963 106324 108964 107892 105864 105203 v...@149180/tr...@148582100.00% 100.00% 100.59% 100.70% 100.59% 100.74% 100.69% 100.79% 100.50% 100.51% GCC tr...@148582 max528254 460362 587570 542154 598130 533138 625174 544654 591410 26 GCC v...@149180 max 528254 460362 579338 540282 598014 547914 627214 561434 578970 553646 v...@149180/tr...@148582100.00% 100.00% 98.60% 99.65% 99.98% 102.77% 100.33% 103.08% 97.90% 99.66% FF3D tr...@148582 avg 160478 160379 169280 170735 174005 175407 179056 179874 164380 165596 FF3D v...@149180 avg 160463 160384 171352 173741 176746 178873 182519 183965 165770 167263 v...@149180/tr...@14858299.99% 100.00% 101.22% 101.76% 101.58% 101.98% 101.93% 102.27% 100.85% 101.01% FF3D tr...@148582 max 494298 493310 497114 492538 509234 508778 529734 540582 476798 493110 FF3D v...@149180 max 494298 493338 515690 517554 531498 530806 542822 552638 514798 534822 v...@149180/tr...@148582100.00% 100.01% 103.74% 105.08% 104.37% 104.33% 102.47% 102.23% 107.97% 108.46% MICO tr...@148582 avg 270379 240593 276524 248775 278922 251851 282331 254687 273297 246126 MICO v...@149180 avg 270328 240570 278185 251241 280705 254305 284368 257374 274451 247978 v...@149180/tr...@14858299.98% 99.99% 100.60% 100.99% 100.64% 100.97% 100.72% 101.06% 100.42% 100.75% MICO tr...@148582 max 497802 494486 537502 522602 528098 519598 557086 544478 528158 527110 MICO v...@149180 max 497838 494506 538998 524282 533038 522418 566886 550298 545302 553194 v...@149180/tr...@148582100.01% 100.00% 100.28% 100.32% 100.94% 100.54% 101.76% 101.07% 103.25% 104.95% SPEC2K tr...@148582 avg 101353 101091 102610 102519 103434 103358 105819 105165 102910 102884 SPEC2K v...@149180 avg101349 101092 103087 103067 103936 103914 106482 105914 103360 103395 v...@149180/tr...@148582100.00% 100.00% 100.46% 100.53% 100.49% 100.54% 100.63% 100.71% 100.44% 100.50% SPEC2K tr...@148582 max 172526 172678 188594 188810 192194 193514 204014 202330 186690 189914 SPEC2K v...@149180 max172526 172674 189394 192394 195182 197266 205002 206714 187870 192654 v...@149180/tr...@148582100.00% 100.00% 100.42% 101.90% 101.55% 101.94% 100.48% 102.17% 100.63% 101.44% tramp3dtr...@148582 avg 686766 685898 893478 889398 919662 942746 996782 995498 891466 893930 tramp3d...@149180 avg 687558 686494 1030534 1024634 1023046 1020642 1045182 1053774 891838 897942 v...@149180/tr...@148582100.12% 100.09% 115.34% 115.21% 111.24% 108.26% 104.86% 105.85% 100.04% 100.45% tramp3dtr...@148582 max 686766 685898 893478 889398 919662 942746 996782 995498 891466 893930 tramp3d...@149180 max 687558 686494 1030534 1024634 1023046 1020642 1045182 1053774 891838 897942 v...@149180/tr...@148582100.12% 100.09% 115.34% 115.21% 111.24% 108.26% 104.86% 105.85% 100.04% 100.45% DLV tr...@148582 avg239153 237855 260962 261421 263187 263827 270711 268845 247990 248256 DLV v...@149180 avg 239135 237804 264511 265722 26 269264 275713 275005 250084 250658 v...@149180/tr...@14858299.99% 99.98% 101.36% 101.65% 101.74% 102.06% 101.85
Re: GCC build failure, h...@149166 on native
On Thu, Jul 2, 2009 at 5:23 PM, Paolo Bonzini wrote: > Well, if the failure is in libgcc, that means that we get a mail on every > commit. In this case my patch went in on Sunday afternoon, and the problems > were fixed only on Thursday for multiple reasons (multiple patches, need for > approval, need to rely on Peter Bergner to test patches, possibility to work > with him only when both of us were awake, etc.). > > This was pretty bad, but it was also unlucky that the failure was only on > the exact arch that the tester builds for. Failures on powerpc are > extremely annoying, failures on SPARC will go (almost) unnoticed. What is wrong about failures being annoying? Paolo, you could have reverted your original patch and worked with the PowerPC developers to test a revised patch. David
Re: GCC build failure, h...@149166 on native
What is wrong about failures being annoying? Paolo, you could have reverted your original patch and worked with the PowerPC developers to test a revised patch. If I had been asked, I would have. Paolo
Re: gtyp-input.list should contain absolute paths.
Hello Basile, * Basile STARYNKEVITCH wrote on Fri, Jul 03, 2009 at 12:10:17PM CEST: > It would be much easier for plugins if gtyp-input.list contained > only absolute paths. In my case, (AMD64/Debian/Sid), it contains > only two relative filepaths: auto-host.h & options.h Over here it contains only relative paths. I build GCC using a relative srcdir: ../gcc/configure as opposed to /path/to/gcc/configure > If gtyp-input.list contained only absolute path, plugins wanting > gengtype could use that very list. Otherwise, they have to hack it > to replace relative file paths (relative to the build directory) by > absolute ones. I cannot judge whether using absolute paths in this file is a problem or not. The s-gtyp-input rule definitely has problems when the absolute paths to the files contain whitespace. (I have no idea whether building GCC works, or would be nice to work, when source or build directory names contains whitespace, at least when relative $srcdir is used.) > I tried to replace in gcc/Makefile.in near line 3437 > s-gtyp-input: Makefile >@: $(call write_entries_to_file,$(GTFILES),tmp-gi.list) >$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list >$(STAMP) s-gtyp-input > with > s-gtyp-input: Makefile >@: $(call write_entries_to_file,$(realpath $(GTFILES)),tmp-gi.list) >$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list >$(STAMP) s-gtyp-input > but it does not work. Please note that "it does not work" is never a good description of any failure. You can always do better than that, and be more precise, by showing the command that failed and any error messages. > However, I am unfamiliar with GNU make user > functions and cannot understand how write_entries_to_file work. Write out names in pieces that don't overflow command line length limits. The easiest way to debug such makefile constructs is to use make SHELL='/bin/sh -x' or similar. One issue with your change is that it drops the [ada] and other language tags that $(GTFILES) contains. Hope that helps. Cheers, Ralf
Re: Endianess attribute
On Thu, Jul 02, 2009 at 06:54:52PM -0400, Ken Raeburn wrote: > On Jul 2, 2009, at 16:44, Michael Meissner wrote: >> Anyway I had some time during the summit, and I decided to see how >> hard it >> would be to add explicit big/little endian support to the powerpc >> port. It >> only took a few hours to add the support for __little and __big >> qualifier >> keywords, and in fact more time to get the byte swap instructions >> nailed down > > That sounds great! > >> (there are restrictions that named >> address space variables can only be global/static or referenced >> through a >> pointer). > > That sounds like a potential problem, depending on the use cases. No > structure field members with explicit byte order? That could be > annoying for dealing with network protocols or file formats with > explicit byte ordering. The technical report that named address spaces is based on does not allow you to mix address spaces within a structure (pointers to different address spaces can be mixed, just not the data themselves). For example, stack variables are always in the generic address space. I do tend to think it would be better to have little/big be more offical than a target specific thing. However, most of the places you need to modify for named address spaces are the places you need to modify for mixed endian. > On the other hand, if we're talking about address spaces... I would > guess you could apply it to a structure? That would be good for > memory-mapped devices accepting only one byte order that may not be that > of the main CPU. For that use case, it would be unfortunate to have to > tag every integer field. > > I don't think Paul indicated what his use case was... -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
Re: gtyp-input.list should contain absolute paths.
Ralf Wildenhues wrote:
Hello Basile,
* Basile STARYNKEVITCH wrote on Fri, Jul 03, 2009 at 12:10:17PM CEST:
It would be much easier for plugins if gtyp-input.list contained
only absolute paths. In my case, (AMD64/Debian/Sid), it contains
only two relative filepaths: auto-host.h & options.h
Over here it contains only relative paths. I build GCC using a relative
srcdir:
../gcc/configure
as opposed to
/path/to/gcc/configure
If gtyp-input.list contained only absolute path, plugins wanting
gengtype could use that very list. Otherwise, they have to hack it
to replace relative file paths (relative to the build directory) by
absolute ones.
I cannot judge whether using absolute paths in this file is a problem or
not.
It should not be a problem, since this file is only used by gengtype, as
a list of files to process (and AFAIK, gengtype only fopen-s them). It
also contains language specific tags like [c] or [ada].
Because of that, I would imagine that GCC could not be built with
relative directories (for source or build tree) starting with a bracket,
but that is not a common situation, and I believe we should not bother.
One issue with your change is that it drops the [ada] and other language
tags that $(GTFILES) contains.
This is indeed the issue.
The patch below solves the issue, but the generated gtype-input.list
contains too much empty blank lines. Any suggestions on how to solve this?
#
Index: gcc/Makefile.in
===
--- gcc/Makefile.in(revision 149204)
+++ gcc/Makefile.in(working copy)
@@ -3409,6 +3409,10 @@
$(srcdir)/tree-ssa-alias.h \
@all_gtfiles@
+
+## compute the realpath of above GTFILES - keeping language tags as before
+REALGTFILES = $(foreach f, $(GTFILES), $(if $(patsubst [%],,$f),
$(realpath $f), $f))
+
# Compute the list of GT header files from the corresponding C sources,
# possibly nested within config or language subdirectories. Match
gengtype's
# behavior in this respect: gt-LANG-file.h for "file" anywhere within a
LANG
@@ -3432,7 +3436,7 @@
gtyp-input.list: s-gtyp-input ; @true
s-gtyp-input: Makefile
-@: $(call write_entries_to_file,$(GTFILES),tmp-gi.list)
+@: $(call write_entries_to_file,$(REALGTFILES),tmp-gi.list)
$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list
$(STAMP) s-gtyp-input
###
Comments are welcome. I know it is not good enough to be proposed as a
true patch (because of the white lines).
I also believe the plugin mode of gengtype could be unsufficient when
the plugins has complex GTY-ed types, in particular unions. Apparently
in that case, the file gtype-desc.h should also be generated, but that
also triggers different issues (mostly PCH related. The more I think
about it, the more I believe that precompiled headers and plugins are
not compatible).
Regards.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: GCC build failure, h...@149166 on native
On Fri, 2009-07-03 at 07:43 +0200, Paolo Bonzini wrote: > On 07/03/2009 07:31 AM, Eric Botcazou wrote: > >> This was pretty bad, but it was also unlucky that the failure was only > >> on the exact arch that the tester builds for. Failures on powerpc are > >> extremely annoying, failures on SPARC will go (almost) unnoticed. > > > > Not clear what you mean about SPARC. The recent multiple SPARC breakages > > had > > been reported for weeks in PRs and the problematic patch clearly identified. > > Yeah, but it's nothing compared to the nagging for powerpc-darwin. > Maintainers and other frequent testers of SPARC notice it, and that's > it. While everyone is going to notice the failures from Geoff's > regression tester, like Arnaud did. Right now the bootstrap+check loops I run on the compile farm cover the following *-linux platforms with c,ada unless otherwise specified: gcc13 x86_64trunk 3h30 gcc15 x86_644.4 6h30 (-j 2) gcc40 powerpc64 trunk 6h00 gcc50 armv5tel trunk 112h00 (c,c++,fortran) gcc51 mips64el trunk 21h00 tri ABI gcc53 powerpc trunk 8h00 gcc54 sparc trunk 25h00 gcc60 ia64 trunk 8h30 gcc61 hppa trunk 22h00 gcc62 sparc64 trunk 28h00 Currently my script loops silently in case of bootstrap failure. I can make the script send a mail to gcc-regression@ when bootstrap state change (work then fail, and fail then work) if there's consensus it's useful (I don't know if people follow gcc-regression@). Sincerely, Laurent
Re: GCC build failure, h...@149166 on native
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 03/07/2009 15:58, Laurent GUERBY a écrit : [...] > Right now the bootstrap+check loops I run on the compile farm cover the > following *-linux platforms with c,ada unless otherwise specified: > > gcc13 x86_64trunk 3h30 > gcc15 x86_644.4 6h30 (-j 2) > gcc40 powerpc64 trunk 6h00 > gcc50 armv5tel trunk 112h00 (c,c++,fortran) > gcc51 mips64el trunk 21h00 tri ABI > gcc53 powerpc trunk 8h00 > gcc54 sparc trunk 25h00 > gcc60 ia64 trunk 8h30 > gcc61 hppa trunk 22h00 > gcc62 sparc64 trunk 28h00 > > Currently my script loops silently in case of bootstrap failure. I can > make the script send a mail to gcc-regression@ when bootstrap state > change (work then fail, and fail then work) if there's consensus it's > useful (I don't know if people follow gcc-regression@). It would certainly be useful to me at least as I check gcc-regression before fetching new bits from the gcc repository. Thanks. - -- Dodji Seketeli Red Hat, Inc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpOI9cACgkQPejI7lrem2GVxQCgvQKX5RsDVfIcLhurKJSrk9Eh dkMAnj2iRT1APLvnopyYaQMdF858wIhG =M6Wz -END PGP SIGNATURE-
g-socket.adb error
Hi, Apparently no one has hit this case. RTEMS does not have two error codes that g-socket.adb maps back. From s-oscons.ads: ESHUTDOWN : constant := -1; -- Cannot send once shutdown ESOCKTNOSUPPORT : constant := -1; -- Socket type not supported This results in a compilation error in g-socket.adb in the switch since they both have the same value: g-socket.adb:1775:15: duplication of choice value at line 1773 Any thoughts? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Is there any pointers you might have What are the pros and cons I should be looking out for Any info much appreciated Thank you very much John
Hi, Is there any pointers you might havewhat are the pros and cons i should be looking out for any info much appreciatedthank you very muchjohn? What Gotchas should I be aware of? Any help appreciated. Thank you so much. Regards, Joan
