Re: %fs and %gs segments on x86/x86-64
FYI similarly, fs: is special on NT/x86 & gs: is special on NT/amd64. In both cases they point to "mostly private builtin" thread locals and from there "publically extensible" thread locals -- TlsGetValue & __declspec(thread) are accessed, & x86 exception handling frame chain, which is just another builtin thread local. (fs: retains the same meaning for NT/x86-on-ia64-or-amd64 as on native NT/x86.) - Jay On Jul 3, 2015, at 1:29 AM, Richard Biener wrote: > On Thu, Jul 2, 2015 at 5:57 PM, Armin Rigo wrote: >> Hi all, >> >> I implemented support for %fs and %gs segment prefixes on the x86 and >> x86-64 platforms, in what turns out to be a small patch. >> >> For those not familiar with it, at least on x86-64, %fs and %gs are >> two special registers that a user program can ask be added to any >> address machine ...
out of date docs? (alpha/64bit vs. 32bit vs. cross)
http://gcc.gnu.org/install/specific.html#alpha-dec-osf "Note that since the Alpha is a 64-bit architecture, cross-compilers from 32-bit machines will not generate code as efficient as that generated when the compiler is running on a 64-bit machine because many optimizations that depend on being able to represent a word on the target in an integral value on the host cannot be performed. Building cross-compilers on the Alpha for 32-bit machines has only been tested in a few cases and may not work properly. " This is false lately, eh? Can it be amended to note what versions it was possibly true for and what versions it is definitely false for? In particular, I /assume/ it is false for any version that uses gmp. Thanks, - Jay
bootstrap4 vs. compare?
In 4.3.2, it seems to me that bootstrap4 does not skip compare, so fails
when it is precisely needed. I did a bootstrap4, compare failed, but manual
make compare3 succeeded.
I guess a workaround is:
/src/configure -disable-bootstrap
make
make install
rm -rf *
/src/configure
make
make install
It seems, based on subsequent make install (not using the
above workaround) that bootstrap4 did skip, or not proceed to, fixincludes.
So I manually:
make all-fixinc
but I get:
/usr/WorkShop/usr/bin/ncc -w -g -o fixincl fixincl.o fixtests.o fixfixes.o serv
er.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a
ld: FATAL 12: Expecting o32 objects: ../libiberty/libiberty.a(safe-ctype.o) is n
32.
Problem is almost obvious, using bootstrap compiler vs. stage1 compiler.
So I edited out the last line of stage3-bubble -- the one that says "make
compare".
That is progressing.
It might help to say:
Makefile.in:
# Bubble a bug fix through all the stages up to stage 3. They are
# remade, but not reconfigured. The next stage (if any) will not be
# reconfigured as well.
.PHONY: stage3-bubble
stage3-bubble:: stage2-bubble
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
if test -f stage3-lean || test -f stage2-lean ; then \
echo Skipping rebuild of stage3 ; \
else \
$(MAKE) stage3-start; \
if $(LEAN); then \
rm -rf stage1-* ; \
$(STAMP) stage1-lean ; \
fi; \
$(MAKE) $(RECURSE_FLAGS_TO_PASS) all-stage3; \
fi
+ifneq ($(.DEFAULT_GOAL),bootstrap4)
$(MAKE) $(RECURSE_FLAGS_TO_PASS) compare
+endif
though that is probably inadequate.
It's not the default goal that matters, but if bootstrap4 is a goal at all.
Or if compare3 is a goal.
- Jay
sparc64 .register when build != host?
We have a system where, when bootstrapping, gcc is used to output assembly on the host, and the assembly files are copied to another system, where they are assembled and linked. Whether we use GNU as and ld or native/vendor is flexible, depending on what works and what I care to build. e.g. AIX is going to require all native/vendor, Irix will require GNU as and vendor ld (until/unless I debug assertion failure in GNU ld). Solaris can probably go either way on as/ld, but currently I'm using Sun for both. I ran into a problem on sparc64-solaris where the .register psuedo op was missing. That's basically the entire problem -- .register is completely absent and the assembler gives lots of errors saying exactly that. No big mystery, no runtime errors, etc. I fixed by hand patching auto-host.h. Next run I'll set gcc_cv_as_sparc_register_op=yes. I think I can phrase this in a more mainstream way. What if build != host, without in-tree binutils/gas? You can't probe the assembler behavior, eh? Maybe gas is ok without .register? ok, if I'm going to use Sun native as? Are there actually old GNU as that target sparc64, but allow omitting .register? I have not looked at the history. More generally, all the business of probing the assembler.. Changing the assembler out from under gcc requires reconfigure/rebuild? Sometimes. In this instance, it looks like it could easily be made a runtime switch. Granted, still not turnkey -- still have to decide a default, and then leave the user to possibly fix it. Unless there is a cheap way to probe at runtime, though that's kind of exactly one of the points -- configure isn't cheap, nor even validation of it. Maybe a "first run" or "configure on host" phase would be nice. I know, it smacks of "setup" instead of just "copy". Any case where gcc needs to know the assembler's behavior..would be fixed by integrating gcc and gas... I guess this is just the general problem of non-native builds, configure done at build-time, but often wants to probe the host environment, not the build environment, and you just muddle along somehow for build != host? Having to set the cv variables isn't deemed so bad? - Jay
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: configuring in-tree gmp/mpfr with "none"?
[again as plain text]
Ah, I didn't realize any C or C++ code could be configured for other than a
specific processor but I guess that makes sense -- it is Makefile, config.h,
and such that are being modified, not the .o files, and they might be the same
across many configurations, like if the compiler command lines and #defines can
be the same, like if there is no need to know the size of a pointer or the
endianness, etc.. I guess more code should work this way if possible. Thanks
Andrew.
(Obviously a lot of source code is independent of pointer size, endianness, but
I haven't seen such configure processor=none use.).
- Jay
> Date: Tue, 17 Jun 2008 13:39:42 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: configuring in-tree gmp/mpfr with "none"?
> CC: gcc@gcc.gnu.org
>
> On Sun, Jun 15, 2008 at 12:49 PM, Jay wrote:
>>
>> 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.
>
> The reason why it is configured with none is so that it can be
> transfered to more computers than your own.
>
> -- Pinski
gcj/sparc64?
This is an incomplete bug report. unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: -bash-3.00$ gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /home/jay/src/gcc/configure Thread model: posix gcc version 4.3.1 (GCC) ~/src/gcc/configure sparc64-sun-solaris2.10 -disable-multilib -disable-bootstrap \ -disable-nls sparc64-sun-solaris2.10 CFLAGS=-m64 MAKEINFO=echo && make \ MAKEINFO=echo CFLAGS=-m64 libtool: compile: /home/jay/obj/gcc.1/gcc/gcj -B/home/jay/obj/gcc.1/sparc64-sun -solaris2.10/libjava/ -B/home/jay/obj/gcc.1/gcc/ -Usun -fclasspath= -fbootclassp ath=/home/jay/src/gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fb ootstrap-classes -g -O2 -c -fsource-filename=/home/jay/obj/gcc.1/sparc64-sun-sol aris2.10/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML _401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/ swing/text/html/parser/HTML_401F.list -fPIC -o gnu/javax/swing/text/html/parser /.libs/HTML_401F.o gcj: Internal error: Segmentation Fault (program jc1) Please submit a full bug report. See for instructions. make[3]: *** [gnu/javax/swing/text/html/parser/HTML_401F.lo] Error 1 make[3]: Leaving directory `/home/jay/obj/gcc.1/sparc64-sun-solaris2.10/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jay/obj/gcc.1/sparc64-sun-solaris2.10/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/jay/obj/gcc.1' make: *** [all] Error 2 -bash-3.00$ uname -a SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 The build gcc -v itself was built with the output of "half Canadian" cross from Cygwin. ie: target==host (==sparc-sun-solaris2.10), but target!=build (i686-pc-cygwin). That should be all I need, but is having some problems, so I figured I'd just it to build native. (I also had to rename away the output of fixincl, as they used the undefined macro _PARAMS.) I'll try again with just -enable-languages=c,c++,fortran,objc. Perhaps I should suck it up, ignore the "biarch-ness" and: ~/src/gcc/configure \ -host=sparc64-sun-solaris2.10 \ -target=sparc64-sun-solaris2.10 \ -enable-languages=c,c++,fortran,objc \ -disable-nls \ -disable-multilib \ MAKEINFO=echo && make MAKEINFO=echo but that fails: checking whether byte ordering is bigendian... unknown configure: error: unknown endianness presetting ac_cv_c_bigendian=no (or yes) will help make[1]: *** [configure-libiberty] Error 1 make[1]: Leaving directory `/home/jay/obj/gcc.1' make: *** [all] Error 2 I shouldn't need this MAKEINFO=echo, but I do for some reason. btw, it'd be cool if one could easily add languages later, remove -disable-multilib later, etc. ie: "reconfigure slightly differently/larger && make" and have it be super duper smart about what to rebuild And -disable-libiconv would be nice. - Jay
fixincludes takes wrong files? (possible sysroot/build-sysroot confusion?)
starting from build i686-pc-cygwin build native build host i686-pc-cygwin target sparc-sun-solaris2.10 -with-sysroot and then host sparc-sun-solaris2.10 target sparc-sun-solaris2.10 installing with destdir = /usr/local/sparc-sun-solaris2.10/install fixincludes took d:\cygwin\usr\include\math.h instead of: D:\cygwin\usr\local\sparc-sun-solaris2.10\sys-root\usr\include\math.h and produced: D:\cygwin\usr\local\sparc-sun-solaris2.10\install\usr\local\lib\gcc\sparc-sun-solaris2.10\4.3.1\include-fixed\math.h which didn't work, of course (for a simple reason -- _PARAMS via _ansi.h vs. __P locally) Perhaps the third toolset should be built -with-sysroot=/ -with-build-sysroot=/usr/local/sparc-sun-solaris2.10/sys-root? Anyway, I renamed the include-fixed away and am rebuilding native. I'll have to dig around and plan to start over "from scratch" anyway and see. I realize these incorrect headers, or what all they are a sign of, *might* have "infected" the tools. The -sysroot stuff is still confusing me some. The other day I found it useful to symlink /usr/local//sys-root to / in order to "fake something out". The -build-sysroot doc says it is only useful with -sysroot, but it seems to me that may be false. I wish sysroot could be validated early, in configure, and user new to cross/etc. builds given a little more hand holding, oh well. - Jay
--sysroot=yes
es at the correct files. Not that fixincludes hasn't already run as part of the cross build. Workaround could be, like: -with-build-sysroot=/usr/local/sparc-sun-solaris2.10/sys-root or -with-sysroot=/ -with-build-sysroot=/usr/local/sparc-sun-solaris2.10/sys-root I should never imho have to say -with-syroot=/. However the documentation on -with-build-sysroot says it only makes a difference if -with-sysroot is also used. I can figure it out though.. This seems like an age old minor but recurring software problem: When do you turn "special" values, such as "yes", into "real" values, such as /usr/local/sparc-sun-solaris2.10/sys-root? The earlier you do it, the less code has to know about the defaults, but the less code can act differently by differentiating the default vs. an explicit choice. More/less code knowing about "special" and default values is both good/bad and bad/good. Sometimes as well you want to ferry along special values through ignorant code. Like, in this example, gcc itself could translate "yes", perhaps. Of course, then, the special value should reliably be in a different namespace, and "yes" strictly speaking is not but reasonably speaking is, but throw in too many "reasonably speaking" and things can get messy fast.. In this particular case, there is probably not much value to delaying the substitution. I am tempted to go further: cross and cross-to-native builds should validate "this stuff" early in configure, check that: -with-sysroot or -with-build-sysroot or -with-headers is specified or this is a merged tree with newlib or glibc (or djgpp runtime?) In fact, one of them should be defaulted, unless it is a merged tree. Or -inihibit-libc, if that is viable. Or skip building target libraries. And if defaulted, check that the default path exists. - Jay
RE: gcj/sparc64?
Sorry Tom, I find opening bugs often tedious..sign up an account, fill in a bunch of fields.. I'll try to get more details "later" (if it repros consistently, callstack in a debugger) - Jay > To: Jayk > CC: gcc > Subject: Re: gcj/sparc64? > From: Tom > Date: Thu, 24 Jul 2008 08:49:13 -0600 > >>>>>> Jay writes: > > Jay> This is an incomplete bug report. > Jay> unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: > Jay> -bash-3.00$ gcc -v > Jay> Using built-in specs. > Jay> Target: sparc-sun-solaris2.10 > > [...] > Jay> /.libs/HTML_401F.o > Jay> gcj: Internal error: Segmentation Fault (program jc1) > Jay> Please submit a full bug report. > > Knowing this particular file, maybe gcj just ran out of memory. > Anyway, please file in bugzilla. If you can include a jc1 stack > trace, that would be helpful.
RE: --sysroot=yes
cc_tooldir)/sys-include'
AC_ARG_WITH(sysroot,
[ --with-sysroot[=DIR] Search for usr/lib, usr/include, et al, within DIR.],
[
- case ${with_sysroot} in
- yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_noncanonical}/sys-root' ;;
- *) TARGET_SYSTEM_ROOT=$with_sysroot ;;
- esac
-
- TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'
-
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
-
- if test "x$prefix" = xNONE; then
- test_prefix=/usr/local
- else
- test_prefix=$prefix
- fi
- if test "x$exec_prefix" = xNONE; then
- test_exec_prefix=$test_prefix
- else
- test_exec_prefix=$exec_prefix
- fi
- case ${TARGET_SYSTEM_ROOT} in
- "${test_prefix}"|"${test_prefix}/"*|\
- "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
- '${prefix}'|'${prefix}/'*|\
- '${exec_prefix}'|'${exec_prefix}/'*)
- t="$TARGET_SYSTEM_ROOT_DEFINE -DTARGET_SYSTEM_ROOT_RELOCATABLE"
- TARGET_SYSTEM_ROOT_DEFINE="$t"
- ;;
- esac
-], [
- TARGET_SYSTEM_ROOT=
- TARGET_SYSTEM_ROOT_DEFINE=
- CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
+ if test x"$with_sysroot" != x ; then
+if test x"$with_sysroot" != xno ; then
+ if test x"$with_sysroot" = xyes ; then
+with_sysroot='${exec_prefix}/${target_noncanonical}/sys-root'
+ fi
+
TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'
+
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
+
+ if test "x$prefix" = xNONE; then
+test_prefix=/usr/local
+ else
+test_prefix=$prefix
+ fi
+ if test "x$exec_prefix" = xNONE; then
+test_exec_prefix=$test_prefix
+ else
+test_exec_prefix=$exec_prefix
+ fi
+ case ${TARGET_SYSTEM_ROOT} in
+"${test_prefix}"|"${test_prefix}/"*|\
+"${test_exec_prefix}"|"${test_exec_prefix}/"*|\
+'${prefix}'|'${prefix}/'*|\
+'${exec_prefix}'|'${exec_prefix}/'*)
+ TARGET_SYSTEM_ROOT_DEFINE="$TARGET_SYSTEM_ROOT_DEFINE
-DTARGET_SYSTEM_ROOT_RELOCATABLE"
+ ;;
+ esac
+fi
+ fi
])
+
+
+#
+# build-sysroot is a copy/paste subset of sysroot
+# It is useful when crossing to native.
+# The resulting compiler is not sensitive to -with-build-sysroot.
+# Fixincludes on the build machine is. (the case I am fixing)
+# The bootstrap compiler is. (not tested)
+#
+# e.g.:
+# configure -disable-bootstrap -build=i686-pc-cygwin -host=i686-pc-cygwin
-target=sparc-sun-solaris2.10 -with-sysroot && make && make install
+# configure -disable-bootstrap -build=i686-pc-cygwin
-host=sparc-sun-solaris2.10 -target=sparc-sun-solaris2.10 -with-build-sysroot
&& make && make install DESTDIR=/usr/local/sparc-sun-solaris2.10/install
+#
+# It passes the same paths during "build", but not any defines that affect
"host".
+# That is, the same thing, but TARGET_SYSTEM_ROOT_DEFINE is not affected.
+#
+AC_ARG_WITH(build-sysroot,
+ [ --with-build-sysroot=sysroot
+ use sysroot as the system root during the build],
+[
+ if test x"$with_build_sysroot" != x ; then
+if test x"$with_build_sysroot" != xno ; then
+ if test x"$with_build_sysroot" = xyes ; then
+with_build_sysroot='${exec_prefix}/${target_noncanonical}/sys-root'
+ fi
+ TARGET_SYSTEM_ROOT=$with_build_sysroot ;;
+
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
+fi
+ fi
+])
+
AC_SUBST(TARGET_SYSTEM_ROOT)
AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
AC_SUBST(CROSS_SYSTEM_HEADER_DIR)
+
# Build with intermodule optimisations
AC_ARG_ENABLE(intermodule,
[ --enable-intermodulebuild the compiler in one step],
Thoughts?
- Jay
> From: [EMAIL PROTECTED]
> To: gcc@gcc.gnu.org
> Subject: --sysroot=yes
> Date: Fri, 25 Jul 2008 05:43:21 +
>
>
I think this one is an actual bug, somewhat "predictable" (easy to realize what
the problem is roughly),
easy for the appropriate folks to fix, easy for affected folks to workaround.
It goes *like* (this is a paraphrase!):
get a "working" system -- cygwin gcc 3.x in my case, but the problem is
probably very portable, as long as you don't have an integrated newlib/glibc
providing the "sysroot" (e.g. Solaris, djgpp, *bsd?)
merged source tree gcc 4.3.1 (release)/binutils 2.18 (release)/gmp/mpfr
get a sparc-sun-solaris2.10 sysroot, at
/usr/local/sp
RE: --sysroot=yes
Joseph, Right, I read that in the docs and I understand. As well, this is probably unusual enough, that no default is needed? Do you agree, at least, that fixincludes has a bug here? For now I am working around by using -with-build-sysroot=/usr/local//sys-root. which is redundant but ok for compiling and linking, since the build=>target toolset in use was already configured with -with-sysroot. I expect it will fix fixincludes though. After all, fixincludes worked when building the buld=>target tools. The diff had at least one error, an extraneous ";;". I *really* think there's a bug here. But I agree the diff I sent is not necessarily the fix. 1) -with-build-sysroot should complain clearly and early if not given a parameter That is, if the parameter is "yes". (Autoconf should probably have a way to indicate a parameter is required, if it doesn't already.) 2) More importantly, fixincludes doesn't get the right headers in this scenario (Canadian cross? "crossing to native"? I think Canadian cross is not "there are three platforms", but that build != host, and there /might/ be three platforms. I think three platforms implies Canadian cross, but two can also? I understand the general picture, of build/host/target, just not what to call things "for short".) There is already a build=>target toolset that knows where to get files. Maybe fixincludes should be part of that? Well, actually, it is, but that isn't sufficient. It is the Makefile that is driving it that is "confused". A possible fix would be to "configure" fixinc.sh with defaults?? No, that seems wrong. At least to include it in fixinc.sh directly. However an easy way to ferry this aspect of the build=>target configuration to the Canadian cross might be good. Some small file that gets "installed". I think -enable-bootstrap + -with-build-sysroot might also fix this, but I'd rather manually build/save/install the build=>target compiler. And I'm not sure, -enable-bootstrap for Canadian cross builds build=>target and build=>host compilers? (in my case target==host). You rather want gcc -print-sysroot I think. That should be a good fix. - Jay > Date: Fri, 25 Jul 2008 10:52:33 + > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: gcc@gcc.gnu.org > Subject: RE: --sysroot=yes > > On Fri, 25 Jul 2008, Jay wrote: > >> It allows -with-build-sysroot to default like -with-sysroot. > > The purpose of --with-build-sysroot is if you have installed your sysroot > in a different location from the configured --prefix. For example, you > have configured with --prefix=/opt/somewhere, the final location the > toolchain will be configured for, but have installed the sysroot under > /scratch/somewhere, a staging location used in the build, and will be > installing with "make install prefix=/scratch/somewhere". > > There should be no need for or use of --with-build-sysroot except in > configurations like this. > > -- > Joseph S. Myers > [EMAIL PROTECTED]
patch for long lines in makefile
Whenever I open gcc/Makefile in my usual editor, Visual C++ 5.0,
which is often, I get a warning about lines being
wrapped at 2048. I can't edit the file, without fixing this.
It is annoying.
This fixes it.
There are two parts and you can take either or both.
Either newline for each language, or newline for every few files, or both.
If there are any quotes, the second part gives up, since they could be quoting
spaces and lead to breaks at incorrect points.
I only tested this on Cygwin, but could test on a few others if required.
I know it's not a huge issue, but it would be nice to fix.
It sadly took quite a while to get to work. I tried with just one temp file,
and failed.
The diff is against the 4.3.1 release.
--- /src/gcc.orig/gcc/configure 2008-05-21 01:54:15.0 -0700
+++ /src/gcc/gcc/configure 2008-07-28 01:55:52.692206100 -0700
@@ -17026,13 +17026,31 @@
all_languages="$all_languages $language"
all_compilers="$all_compilers $compilers"
all_outputs="$all_outputs $outputs"
- all_gtfiles="$all_gtfiles [$subdir] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+ all_gtfiles="$all_gtfiles"' \\\
+ '"[$subdir] $gtfiles"
done
# Pick up gtfiles for c
gtfiles=
. ${srcdir}/c-config-lang.in
-all_gtfiles="$all_gtfiles [c] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+all_gtfiles="$all_gtfiles"' \\\
+ '"[c] $gtfiles"
+
+#
+# Wrap every few elements in all_gtfiles, to keep line lengths
+# somewhat down, unless it has any quotes, which confuse things.
+#
+cat < conftest.gt1
+$all_gtfiles
+EOF
+if grep [\"\'] conftest.gt1; then :; else
+ # Six slashes will immediately become three slashes. Later, via
sed/AC_SUBST, first two will become one, third escapes the newline.
+ # The seventh slash is for the newline the first time.
+ sed 's/\([^ \\][^ \\]* \)\{5\}/\0\\\n /g' conftest.gt1> conftest.gt2
+ all_gtfiles=`cat conftest.gt2`
+fi
check_languages=
for language in $all_selected_languages
--- /src/gcc.orig/gcc/configure.ac 2008-05-21 01:54:15.0 -0700
+++ /src/gcc/gcc/configure.ac 2008-07-28 01:55:43.270331100 -0700
@@ -3639,13 +3639,33 @@
all_languages="$all_languages $language"
all_compilers="$all_compilers $compilers"
all_outputs="$all_outputs $outputs"
- all_gtfiles="$all_gtfiles [[$subdir]] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+ all_gtfiles="$all_gtfiles"' \\\
+ '"[[$subdir]] $gtfiles"
done
# Pick up gtfiles for c
gtfiles=
. ${srcdir}/c-config-lang.in
-all_gtfiles="$all_gtfiles [[c]] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+all_gtfiles="$all_gtfiles"' \\\
+ '"[[c]] $gtfiles"
+
+#
+# Wrap every few elements in all_gtfiles, to keep line lengths
+# somewhat down, unless it has any quotes, which confuse things.
+#
+cat < conftest.gt1
+$all_gtfiles
+EOF
+changequote(,)dnl
+if grep [\"\'] conftest.gt1; then :; else
+ # Six slashes will immediately become three slashes. Later, via
sed/AC_SUBST, first two will become one, third escapes the newline.
+ # The seventh slash is for the newline the first time.
+ sed 's/\([^ \\][^ \\]* \)\{5\}/\0\\\n /g' conftest.gt1> conftest.gt2
+ all_gtfiles=`cat conftest.gt2`
+fi
+changequote([,])dnl
check_languages=
for language in $all_selected_languages
Thanks,
- Jay
--- /src/gcc.orig/gcc/configure 2008-05-21 01:54:15.0 -0700
+++ /src/gcc/gcc/configure 2008-07-28 01:55:52.692206100 -0700
@@ -17026,13 +17026,31 @@
all_languages="$all_languages $language"
all_compilers="$all_compilers $compilers"
all_outputs="$all_outputs $outputs"
- all_gtfiles="$all_gtfiles [$subdir] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+ all_gtfiles="$all_gtfiles"' \\\
+ '"[$subdir] $gtfiles"
done
# Pick up gtfiles for c
gtfiles=
. ${srcdir}/c-config-lang.in
-all_gtfiles="$all_gtfiles [c] $gtfiles"
+# Three slashes: Later, via sed/AC_SUBST, first two will become one, third
escapes the newline.
+all_gtfiles="$all_gtfiles"' \\\
+ '"[c] $gtfiles"
+
+#
+# Wrap every few elements in all_gtfiles, to keep line lengths
+# somewhat down, unless it has any quotes, which confuse things.
+#
+cat < conftest.gt1
+$all_gtfiles
+EOF
+if grep [\"\'] conftest.gt1; then :; else
+ # Six slashes wi
RE: configuring in-tree gmp/mpfr with "none"?
Andrew, Can you explain more why?
Why I'm asking again now:
I have found another "problem" because of this (besides the
reduced ability to share config.cache files).
This exacerbates what looks like a minor bug in gmp's configure.
Sometimes, depending on build/host/target, gmp's configure
sets M4=m4-not-needed.
Setting the processor to "none" is a good way to get it down the "not needed"
path.
Though there might be other ways there, granted.
And then gmp/configure runs flex.
And then sometimes?always flex tries to run getenv("M4") || "m4".
Flex fails, sometimes creating lex.yy.c, sometimes not.
I haven't tracked down this "sometimes".
When I run build under Python, no lex.yy.c, outside of Python, ok.
I still have to dig in further to find out why.
When lex.yy.c is not created, configure fails. It is looking for what file is
the output.
gmp/configure probably should not be setting M4, at least not when it runs flex.
But gcc using processor=none doesn't help.
I'll follow up with gmp folks.
Thanks,
- Jay
> Date: Wed, 18 Jun 2008 06:53:35 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: configuring in-tree gmp/mpfr with "none"?
> CC: gcc@gcc.gnu.org
>
> On Wed, Jun 18, 2008 at 12:40 AM, Jay wrote:
>> Ah, I didn't realize any C or C++ code could be configured for other than a
>> specific processor but I guess that makes sense -- it is Makefile, config.h,
>> and such that are being modified, not the .o files, and they might be the
>> same across many configurations, like if the compiler command lines and
>> #defines can be the same, like if there is no need to know the size of a
>> pointer or the endianness, etc.. I guess more code should work this way if
>> possible. Thanks Andrew.
>
> Well gmp/mpfr are special in that they try to do the same thing as
> -mcpu=native with their configure script and they have some assembly
> files.
>
> Thanks,
> Andrew Pinski
insn-attrtab.c long time to compile..
4.2.3 insn-attrtab.c takes "a long time" to compile on djgpp (build=host=target=i586-pc-msdosdjgpp, bootstrapping from 4.2.3) with the default -g -O2. I let it go, walked away for a few days, laptop power was pulled in the meantime (moved to another laptop), so it ran till the battery ran out. Presumably at least 30 minutes. Perhaps this can at least be split up into insn-attrtab-1.c insn-attrtab-2.c insn-attrtab-3.c insn-attrtab-4.c with a quarter of the functions in each file? It seems either switch takes a long time. Omitting both compiles in just a few seconds. I'll see about collecting accurate times for all four combinations, testing with 4.3.1, see if breaking it up into multiple files helps, etc. (could be just one particular function causes it, even if isolated in one source file). #pragma optimize would probably good and easy, but looks like that's not available in these versions. Thanks, - Jay
RE: configuring in-tree gmp/mpfr with "none"?
> Because at some point, no released version worked on intel macs.
Long since passed and can be removed?
Or only do it on those machines??
Granted, the Python-wrapping-build I'm doing ought to work as well on Intel
Macs as anywhere else.
Here is what ends up happening:
#include
#include
int main()
{
signal(SIGPIPE, SIG_IGN); << Python does like this
putenv("M4=foo");<< gmp/configure does like this
system("flex 1.l");<< gmp/configure does like this
return 0;
}
Without ignoring sigpipe, flex dies in filter_tee_header reading the output of
a failed exec.
Ignoring the signal under a Python wrapper however, it continues on
and deletes the output, causing gmp/configure to fail because it is looking
for the output.
gmp/configure is where the blame really lies, but if gcc configured gmp
"normally",
this wouldn't occur. Or, is cpu=none not so abnormal? Just that I hadn't seen
it?
(Everything new and normal is initially new and abnormal, of course.)
- Jay
> Date: Thu, 31 Jul 2008 15:53:43 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]; gcc@gcc.gnu.org
> Subject: Re: configuring in-tree gmp/mpfr with "none"?
>
> Jay wrote:
>> Andrew, Can you explain more why?
>
> Because at some point, no released version worked on intel macs.
>
>> And then gmp/configure runs flex.
>> And then sometimes?always flex tries to run getenv("M4") || "m4".
>
> Yes, Flex uses m4.
>
>> gmp/configure probably should not be setting M4
>
> Yes, I think that setting M4=m4-not-needed should be done only for
> debugging purposes. Otherwise, GMP should always look for m4 in its
> configure script, and set it to a valid value in the makefile.
>
> Paolo
RE: --sysroot=yes
With a little more cross building experience...I'm still convinced there is a
problem here.
Canadian cross doesn't do the right thing in fixincludes.
There are remnants of a fix in the 4.3.1 configure.ac here:
# When building gcc with a cross-compiler, we need to adjust things so
# that the generator programs are still built with the native compiler.
# Also, we cannot run fixincludes or fix-header.
# These are the normal (build=host) settings:
CC_FOR_BUILD='$(CC)'AC_SUBST(CC_FOR_BUILD)
BUILD_CFLAGS='$(ALL_CFLAGS)'AC_SUBST(BUILD_CFLAGS)
STMP_FIXINC=stmp-fixinc AC_SUBST(STMP_FIXINC)
# Possibly disable fixproto, on a per-target basis.
case ${use_fixproto} in
no)
STMP_FIXPROTO=
;;
yes)
STMP_FIXPROTO=stmp-fixproto
;;
esac
AC_SUBST(STMP_FIXPROTO)
# And these apply if build != host, or we are generating coverage data
if test x$build != x$host || test "x$coverage_flags" != x
then
BUILD_CFLAGS='$(INTERNAL_CFLAGS) $(T_CFLAGS) $(CFLAGS_FOR_BUILD)'
if test "x$TARGET_SYSTEM_ROOT" = x; then
if test "x$STMP_FIXPROTO" != x; then
STMP_FIXPROTO=stmp-install-fixproto
fi
fi
fi
but it doesn't work. The above code is basically the same in trunk.
fix-includes still runs and uses the build headers instead of the target
headers.
-with-build-sysroot doesn't workaround because:
if test x$host != x$target
then
CROSS="-DCROSS_DIRECTORY_STRUCTURE"
ALL=all.cross
SYSTEM_HEADER_DIR=$build_system_header_dir
case "$host","$target" in
# Darwin crosses can use the host system's libraries and headers,
# because of the fat library support. Of course, it must be the
# same version of Darwin on both sides. Allow the user to
# just say --target=foo-darwin without a version number to mean
# "the version on this system".
*-*-darwin*,*-*-darwin*)
hostos=`echo $host | sed 's/.*-darwin/darwin/'`
targetos=`echo $target | sed 's/.*-darwin/darwin/'`
if test $hostos = $targetos -o $targetos = darwin ; then
CROSS=
SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)'
with_headers=yes
fi
;;
i?86-*-*,x86_64-*-* \
| powerpc*-*-*,powerpc64*-*-*)
CROSS="$CROSS -DNATIVE_CROSS" ;;
esac
elif test "x$TARGET_SYSTEM_ROOT" != x; then
SYSTEM_HEADER_DIR=$build_system_header_dir
fi
goes down the native path. Also same in trunk.
Oh, maybe I should do that thing where you make up a platform?
(I saw this in "Do-it-yourself Linux" similar to Linux-from-Scratch").
-host sparc-foo-solaris2.10 -target sparc-sun-solaris2.10
instead of:
-host sparc-sun-solaris2.10 -target sparc-sun-solaris2.10
?
That feels wrong..
Hm, am I supposed to run mkheaders after install? <<<
Ah, I guess so.
But still the above appears in need of repair.
And if user gives -with-build-sysroot, then fixincludes can be run
on the build machine in a Canadian cross.
I opened a bug, but it doesn't have all this info (yet).
- Jay
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: gcc@gcc.gnu.org
> Subject: RE: --sysroot=yes
> Date: Sat, 26 Jul 2008 08:12:14 +
>
>
> Joseph, Right, I read that in the docs and I understand.
> As well, this is probably unusual enough, that no default is needed?
>
> Do you agree, at least, that fixincludes has a bug here?
>
> For now I am working around by using -with-build-sysroot=/usr/local//sys-root.
> which is redundant but ok for compiling and linking, since the build=>target
> toolset in use
> was already configured with -with-sysroot. I expect it will fix fixincludes
> though.
> After all, fixincludes worked when building the buld=>target tools.
>
> The diff had at least one error, an extraneous ";;".
>
> I *really* think there's a bug here.
> But I agree the diff I sent is not necessarily the fix.
>
> 1) -with-build-sysroot should complain clearly and early if not given a
> parameter
> That is, if the parameter is "yes".
> (Autoconf should probably have a way to indicate a parameter is required, if
> it doesn't already.)
>
> 2) More importantly, fixincludes doesn't get the right headers in this
> scenario (Canadian cross?
> "crossing to native"? I think Canadian cross is not "there are three
> platforms", but that build != host,
> and there /might/ be three platforms. I think three platforms implies
> Canadian cross, but two can also?
> I understand the general picture, of build/host/target, just not wha
Re: Problem reading corefiles on ARM
> From: mark@ > To: drow@; gcc@ > CC: sposelenov@; gdb@ > I suppose it optimizes away the instructions to save the return > address, because abort() is marked with __attribute__(noreturn). But Ouch. Other compilers put a breakpoint after a call to any noreturn function. Really, the compiler, not the debugger. I had an incorrect annotation once. :) - Jay
RE: gcj/sparc64?
Thanks.
While I have an easy repro, it's less easy to repro with any "onion peeling" or
logging.
For a while I was avoiding the problem via -enable-languages=c,c++.
This command is what fails (but not always)
/obj/gcc.1/i686-pc-cygwin/sparc64-sun-solaris2.10/gcc/jc1.exe /src/gcc/libjava/
classpath/lib/gnu/javax/swing/text/html/parser/HTML_401F.class -fuse-divide-subr
outine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -quiet -dumpbas
e HTML_401F.class -mcpu=v9 -auxbase-strip gnu/javax/swing/text/html/parser/HTML_
401F.o -g -O2 -Wno-deprecated -version -fencoding=UTF-8 -fbootstrap-classes -fso
urce-filename=/obj/gcc.1/i686-pc-cygwin/sparc64-sun-solaris2.10/sparc64-sun-sola
ris2.10/libjava/classpath/lib/classes -fbootclasspath=./:/src/gcc/libjava/classp
ath/lib/ -faux-classpath /d/DOCUME~1/jay/LOCALS~1/Temp/cciZj3jk.zip -MD_ -MT gnu
/javax/swing/text/html/parser/HTML_401F.lo -MF gnu/javax/swing/text/html/parser/
HTML_401F.deps -o /d/DOCUME~1/jay/LOCALS~1/Temp/ccqOtWtu.s
output is:
GNU Java (GCC) version 4.3.1 (sparc64-sun-solaris2.10)
compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Class path starts here:
/d/DOCUME~1/jay/LOCALS~1/Temp/cciZj3jk.zip/ (zip)
./ (system)
/src/gcc/libjava/classpath/lib/ (system)
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java: In c
lass 'gnu.javax.swing.text.html.parser.HTML_401F':
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java: In m
ethod 'gnu.javax.swing.text.html.parser.HTML_401F.defineElements()':
/src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java:0: in
ternal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
and then here it is under a debugger:
Program received signal SIGSEGV, Segmentation fault.
0x008fc34a in htab_mod (hash=7818600, htab=0x27b75c8)
at /src/gcc/libiberty/hashtab.c:270
270 return htab_mod_1 (hash, p->prime, p->inv, p->shift);
(gdb) bt
#0 0x008fc34a in htab_mod (hash=7818600, htab=0x27b75c8)
at /src/gcc/libiberty/hashtab.c:270
#1 0x008fc752 in htab_find_slot_with_hash (htab=0x27b75c8, element=0x330a0,
hash=7818600, insert=INSERT) at /src/gcc/libiberty/hashtab.c:624
#2 0x008fc8fc in htab_find_slot (htab=0x27b75c8, element=0x330a0,
insert=INSERT) at /src/gcc/libiberty/hashtab.c:678
#3 0x006ce782 in get_def_blocks_for (var=0x3ba6b40)
at /src/gcc/gcc/tree-into-ssa.c:466
#4 0x006d2d78 in mark_use_interesting (var=0x3ba6b40, stmt=0x7c0ec6a0,
bb=0x79a11300, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2375
#5 0x006d2bb8 in prepare_block_for_update (bb=0x79a11300,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2448
#6 0x006d2cec in prepare_block_for_update (bb=0x79a11280,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#7 0x006d2cec in prepare_block_for_update (bb=0x79a111c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#8 0x006d2cec in prepare_block_for_update (bb=0x79a110c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#9 0x006d2cec in prepare_block_for_update (bb=0x79a11040,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#10 0x006d2cec in prepare_block_for_update (bb=0x79a10f80,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#11 0x006d2cec in prepare_block_for_update (bb=0x79a10e80,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#12 0x006d2cec in prepare_block_for_update (bb=0x79a10e00,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#13 0x006d2cec in prepare_block_for_update (bb=0x79a10d40,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#14 0x006d2cec in prepare_block_for_update (bb=0x79a10c40,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#15 0x006d2cec in prepare_block_for_update (bb=0x79a10bc0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#16 0x006d2cec in prepare_block_for_update (bb=0x79a10b00,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#17 0x006d2cec in prepare_block_for_update (bb=0x79a10a00,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#18 0x006d2cec in prepare_block_for_update (bb=0x79a10980,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#19 0x006d2cec in prepare_block_for_update (bb=0x79a108c0,
insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464
#20 0x006d2cec in prepare_block_for_update (bb=0x79a107c0,
...
... pages and pages ...
...
#9950 0x006d2cec in prepare_block_for_update (bb=0x7c82e7c0,
insert_phi_p=1 '\001') at /src
RE: gcj/sparc64?
> From: brian@ >> > This stack exhaustion is PR36218 which was supposedly fixed on > mainline. Two problems: the fix needs to be extended to Cygwin as well > as MinGW, and you're not building mainline. > >> I wish Windows code was PIC > > zero to do with the topic of this thread. I agree it's a tangent. It seems the PIC compilation succeeds. The whole thing where things get compiled twice, PIC and non-PIC, bugs me. It's a "great" way to slow down builds. I guess configure -only-pic might be nice. I understand the results, if only linked into an executabe, might be slower. Picking a base address that might not conflict with other code/data doesn't eliminate the problem, just reduces it, and a cost of random burning of address space. (I don't know the algorithm, "random" isn't the right word). If the code/data were really PIC, it could be tightly packed. Thanks. I'm trying it out with an 8meg stack like was applied to mingwin. I believe Solaris hosts need a fix here too. And djgpp. And perhaps others. AIX? Irix? HP-UX? *BSD? Or most systems default to 8 or 32meg? Not worth changing the gcc code to reduce or eliminate the recursion? - Jay
RE: gcj/sparc64?
This seems t have worked, applied against 4.3.1, based on what I saw was the MinGW fix. $ diff -u /src/gcc.orig/config/mh-cygwin /src/gcc/config/mh-cygwin --- /src/gcc.orig/config/mh-cygwin 2002-12-16 18:58:05.0 -0800 +++ /src/gcc/config/mh-cygwin 2008-08-10 06:09:39.71875 -0700 @@ -4,3 +4,5 @@ all-gdb: maybe-all-libtermcap install-gdb: maybe-all-libtermcap + +LDFLAGS = -Wl,--stack,8388608 I'll retest the break and a fix for Solaris /significantly later/. >> From: brian@ >>> >> This stack exhaustion is PR36218 which was supposedly fixed on >> mainline. Two problems: the fix needs to be extended to Cygwin as well >> as MinGW, and you're not building mainline. >> zero to do with the topic of this thread. > Not worth changing the gcc code to reduce or eliminate the recursion? Thanks, - Jay
obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
\
char *page, *end;\
\
size = static_size;
if (size == 0) \
{ \
size = getpagesize();\
static_size = size;
} \
mask = ~(size -1); \
\
page = (char *) (((size_t) addr) & mask); \
end = (char *) size_t) (addr + (TARGET_64BIT ? 48 : 40))) & mask) +
size); \
\
/* 7 == PROT_READ | PROT_WRITE | PROT_EXEC */\
(void) mprotect (page, end - page, 7); \
size_t is a good type to use here, right?
Best to stick to unsigned imho.
And sizeof(void*) == sizeof(size_t), more often than sizeof(void*) ==
sizeof(long), eh?
- Jay
mingwin getpagesize int vs. size_t
gcc 4.3.1, with minor patches build=host=i686-pc-cygwin target=i686-pc-mingw32 sys-root setup how I believe is appropriatev (well, er, um..maybe not, due to later problems, but I don't think that's the problem here; there indeed varying declarations of getpagesize) => /obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/./gcc/xgcc -B/obj/gcc.1/i686-pc-cygwin /i686-pc-mingw32/./gcc/ -L/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-ming w32/winsup/mingw -L/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mingw32/win sup/w32api/lib -isystem /src/gcc/winsup/mingw/include -isystem /src/gcc/winsup/w 32api/include -B/usr/local/i686-pc-mingw32/bin/ -B/usr/local/i686-pc-mingw32/lib / -isystem /usr/local/i686-pc-mingw32/include -isystem /usr/local/i686-pc-mingw3 2/sys-include -L/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/./ld -O2 -g -g -O2 -I/ src/gcc/gcc/../winsup/w32api/include -O2 -g -g -DIN_GCC -DCROSS_DIRECTORY_STRU CTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold- style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__G CC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/src/gcc/libgcc -I/src/gcc/libgcc/ . -I/src/gcc/libgcc/../gcc -I/src/gcc/libgcc/../include -DHAVE_CC_TLS -o _tramp oline.o -MT _trampoline.o -MD -MP -MF _trampoline.dep -DL_trampoline -c /src/gcc /libgcc/../gcc/libgcc2.c \ /src/gcc/libgcc/../gcc/libgcc2.c:2052: error: conflicting types for 'getpagesize ' /usr/local/i686-pc-mingw32/sys-root/mingw/include/sys/unistd.h:75: error: previo us declaration of 'getpagesize' was here /src/gcc/libgcc/../gcc/libgcc2.c:2066: warning: no previous prototype for 'mprot ect' make[2]: *** [_trampoline.o] Error 1 make[2]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mi ngw32/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32' make: *** [all] Error 2 The two protoypes are int getpagesize(void) size_t getpagesize(void) I can't prove to myself the function is even used, so I'll try #if 0 it. I do understand the point. Nested functions generate code on the stack. The stack might not be executable. Make the page with the trampoline executable via mprotect/VirtualProtect. I just don't see where __enable_execute_stack comes from for this target, other than a no-op. - Jay
"random" "Link tests are not allowed after GCC_NO_EXECUTABLES"
gcc 4.3.1 with small patches... (merged tree with binutils 2.18/gmp/mpfr, also slightly patched) build=i686-pc-cygwin host=i686-pc-cygwin target=i686-pc-mingw32 configure: /obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mingw32/libstdc++-v 3/../libgomp/omp.h not found checking for parallel mode support... no checking for extra compiler flags for building... checking for thread model used by GCC... win32 checking for atomic builtins... no checking for g++ that supports -ffunction-sections -fdata-sections... yes checking for sys/types.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for ld version... 21800 checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32' make: *** [all] Error 2 I hit this "Link tests are not allowed after GCC_NO_EXECUTABLES." for target=djgpp too, though in that case, I know I skipped their wrapper scripts which "preconfigure" some stuff via environment variables. I'll come back to this much later (days/weeks/months). I searched the web here some. It seems in general either: a merged gcc/newlib or gcc/glibc tree works well anything else, not to much, but sometimes e.g. I have built cygwin and solaris targets, with no libc source or maybe it depends on having a complete sysroot? Something seems to be off in general though for cross builds. ? This seems to be a FAQ with no answer. ? Like, there are too many link tests in configure? I'll try to just make install w/o completing make, so I get the compiler at least. I just need mingwin cc1 to make progress building cygwin1.dll with gcc 4.3.1. Could be my mingwin sys-root is bad. I have something kind of complicated in order to get this far, and I had to copy the cygwin winsup into the gcc tree, at least for w32api. Anyway, this is just a random report, like "cross building is a little too difficult". Perhaps the way to go is bootstrap with CC='gcc -mno-cygwin -V 3.4.4' since that has a full mingwin environment. - Jay
RE: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
Yeah that's probably ok. Volatile is enough to force the ordering? I still like just not caching mask. Is "volatile*" legal or just pseudo? Some platforms cache neither. Are some platforms getpagesize slow and others fast? Or it's just "random evolution"? If it's just "random", and nobody knows getpagesize to be slow, I'd say just never cache either. - Jay > > [snip snip snip] > > Or even better store size after the store to mask. > That is: > int tmp = getpagesize(); > *(volatile*)&mask = ~((long)tmp - 1); > *(volatile*)&size = tmp; > > Thanks, > Andrew Pinski
configure CFLAGS="-V 1.2.3" vs. -o
configure CFLAGS='-V 3.4.4' doesn't work because: configure:3291: i686-pc-cygwin-gcc -o conftest.exe -V 3.4.4 -mno-cygwin -g co nftest.c >&5 i686-pc-cygwin-gcc: '-V' must come at the start of the command line configure:3294: $? = 1 configure:3312: error: cannot compute suffix of executables: cannot compile and link Maybe an autoconf bug. Unless gcc could loosen up its command line parsing. I'll try CC instead of CFLAGS. - Jay
RE: obvious race condition in darwin/netbsd __enable_execute_stack due to caching pagesize/mask
> "(volatile*) So this is using implied int then? Isn't that really considered to be avoided these days? Or perfectly ok in C? I know it is "legal", but I assume to be avoided as a matter of taste and C++ compat. Or you can really omit the type I think not. Might be a nice extension though. "Someone" please fix. I don't have write access. Seems agreed best fix is to not cache mask. Not cashing size seems goodness too but should probably first read getpagesize on the affected systems (including older versions), make sure it is just returning a constant, not making a syscall. I'm also not sure about "left casting". int i = 123; (*(char*)&i) = 0; Legal? Tangential and now moot I realize. I understand the point, it is a common construct, but I've long wondered if the standard allows it. I understand that: int i = 123; volatile char* p = (volatile char*) &i; *p = 0; is legal -- with a type, and not "left". btw, I think the cache is also badness in that writable globals should be minimized. In the interest of minimizing dirty pages, "dirtiable" pages, etc. (ie: if you have 4k + 4 bytes of writable globals, saving 4 bytes probably saves 4k.) It's also smaller code to not cache, of course. Thanks, - Jay > From: dave@ > [snip snip snip...]
RE: "random" "Link tests are not allowed after GCC_NO_EXECUTABLES" -- resolved and some suggestions..
l Unices" and *BSD. As well, if user specified -with-sysroot and/or -with-build-sysroot, help them less -- skip all this approx. But still some sanity checking like for mingwin I think. Or maybe sanity check them all -- check for limits.h and/or stdio.h. You know, like how cc/cpp are checked for, check for those files up front, unless detected that you are going to build them (again, the glibc/newlib case, I think). See here, I'm at least an intermediate user, maybe an advanced user, slowly working through these issues by searching the web, reading the docs, reading the code, and I'm "donating my experience" (aka complaining but trying to be helpful. :) ), so maybe the next guy can have it a little easier (albeit less educational? :) ) Actually, the above doesn't say enough. In particular, setting up a mingw sysroot, on a Windows system, can go easily like: install mingw, such as to c:\mingw mkdir c:\cygwin\usr\local\i686-pc-mingw32\sys-root\mingw \\live.sysinternals.com\tools\junction c:\cygwin\usr\local\i686-pc-mingw32\sys-root\mingw\include c:\mingw\include \\live.sysinternals.com\tools\junction c:\cygwin\usr\local\i686-pc-mingw32\sys-root\mingw\lib c:\mingw\lib I suppose to be more useful I should reform this into sh and path configure.ac. The reason I haven't done it that way is for my own ease of maintenence -- easier to maintain patches on the side than get them upstream probably. If folks are actually interested, I can do that. As long as bugs like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37036 exist (or explained to me why it isn't a bug), I kinda think people are not interested. - Jay
old but current libiberty/strsignal vs. cygwin
strsignal problems on target=Cygwin have been kicking around for years.
This is a libiberty issue.
Maybe offtopic for gcc.
Or maybe the right place.
?
(and gcc vs. gcc-patches, similar, opening a bug seems too
heavyweight when an analysis/fix is (mostly) in hand..)
native cygwin (build=host=target=cygwin, or at least target=cygwin)
gcc 4.3.2 (recently released)
+ binutils 2.18
+ cygwin-snapshot-20080822-1
This is winsup and newlib.
+ gmp 4.2.3, mpfr, 2.3.1
once nice unified tree
some or all slightly patched -- to fix build problems
The error is:
# /src/gcc/libiberty/strsignal.c:408: error: conflicting types for 'strsignal'
# const char *
# strsignal (int signo)
#
# /src/gcc/newlib/libc/include/string.h:79: error: previous declaration of
'strsignal' was here
# char *_EXFUN(strsignal, (int __signo));
#
# make[1]: Leaving directory
`/obj/gcc.1/i686-pc-cygwin/i686-pc-cygwin/i686-pc-cygwin/libiberty'
It's a bit involved.
libiberty endeavors to avoid probing for strsignal, and provide its own,
for a cygwin target, in order for cygwin's strsignal to be libiberty's
strsignal.
That's what the comments say, and I believe they match the code (shown below).
That is, the probe would succeed, thereby not contributing the very
implementation needed.
However back in 2004, cygwin got its own strsignal:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/strsig.cc?cvsroot=src
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/Makefile.in.diff?r1=1.153&r2=1.154&cvsroot=src
Current libiberty though:
http://gcc.gnu.org/svn/gcc/trunk/libiberty/configure.ac
if test -z "${setobjs}"; then
case "${host}" in
*-*-cygwin*)
# The Cygwin library actually uses a couple of files from
# libiberty when it is built. If we are building a native
# Cygwin, and we run the tests, we will appear to have these
# files. However, when we go on to build winsup, we will wind up
# with a library which does not have the files, since they should
# have come from libiberty.
# We handle this by removing the functions the winsup library
# provides from our shell variables, so that they appear to be
# missing.
# DJ - only if we're *building* cygwin, not just building *with* cygwin
if test -n "${with_target_subdir}"
then
funcs="`echo $funcs | sed -e 's/random//'`"
AC_LIBOBJ([random])
vars="`echo $vars | sed -e 's/sys_siglist//'`"
checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`"
fi
;;
This appears outdated.
Try changing it to:
checkfuncs="`echo $checkfuncs | sed -e 's/psignal//'`"
That does not fix the problem however.
Though I presume it is reasonable.
That does doesn't run, I think, because of of setjobs (though my sh/test
isn't strong enough to be certain...ugh):
if test -n "${with_target_subdir}"; then
# We are being configured as a target library. AC_REPLACE_FUNCS
# may not work correctly, because the compiler may not be able to
# link executables. Note that we may still be being configured
# native.
# If we are being configured for newlib, we know which functions
# newlib provide and which ones we will be expected to provide.
if test "x${with_newlib}" = "xyes"; then
...
setobjs=yes
fi
Instead see here, same file:
case "${host}" in
*-*-cygwin* | *-*-mingw*)
AC_DEFINE(HAVE_SYS_ERRLIST)
AC_DEFINE(HAVE_SYS_NERR)
;;
esac
and change it to:
case "${host}" in
*-*-mingw*)
AC_DEFINE(HAVE_SYS_ERRLIST)
AC_DEFINE(HAVE_SYS_NERR)
;;
*-*-cygwin*)
AC_DEFINE(HAVE_SYS_ERRLIST)
AC_DEFINE(HAVE_SYS_NERR)
#
# Cygwin used to use libiberty's strsignal, but
# got its own in 2004.
#
AC_DEFINE(HAVE_STRSIGNAL)
;;
esac
I'm still testing this but it does seem to be two smoking guns.
The first one shot a blank but I doubt I'll find a third. :)
Nobody builds gcc + cygwin in an integrated tree?
I wish I could integrate more into The One Tree.
I so dislike everything being separate..
Can someone vet and apply these changes? Thanks.
In the meantime, I wrap up my build with something that applies
various patches and workarounds (attached).
Similarly, this is kind of yucky but I guess ok:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: warning: au
to-importing has been activated without --enable-auto-import specified on the co
mmand line.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.Info: resolving _sys_nerr by linking to __imp__sys_nerr
(auto-import)
Info: resolving _sys_errlist by linking to __imp__sys_errlist (auto-import)
This is probably libiberty/strerror.c.
Must it
optimizing build of multiple configurations?
reducing identical builds? Let's say I cd /configure -build i686-pc-cygwin -host i686-pc-cygwin -target i686-pc-cygwin make make install cd /configure -build i686-pc-cygwin -host i686-pc-cygwin -target sparc-sun-solaris2.10 make make install cd /configure -build i686-pc-cygwin -host i686-pc-cygwin -target sparc64-sun-solaris2.10 make make install cd /configure -build i686-pc-cygwin -host sparc-sun-solaris2.10 -target sparc-sun-solaris2.10 make make install DESTDIR=... cd /configure -build i686-pc-cygwin -host sparc64-sun-solaris2.10 -target sparc64-sun-solaris2.10 make make install DESTDIR=... This does the same thing many times, in the interest of doing a few different things. It builds gmp, mpfr, libiberty many times. Libiberty is built multiple times even with just one configure. Has anyone done work to reduce the waste here? In particular, to automate and optimize building multiple configurations? I started something but it's not very far along, and the stuff I turned up with libiberty's configure points out a danger -- compiling for a platform is different depending on if the platform is build vs. host vs. target. host=i686-pc-cygwin libiberty does not necessarily equal target=i686-pc-cygwin libiberty, etc. Still in the above example, one can be conservative about that and still reduce a lot. As long as build, host, target are really independent. Maybe just something very general like ccache? I haven't tried that yet. I think I will now. Thanks, - Jay
some random build breaks
c.4/i686-pc-cygwin/newlib/targ-include -isystem /src/gcc/newlib/libc/include -B /usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/lo cal/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -L/obj /gcc.4/./ld -DHAVE_CONFIG_H -I. -I/src/gcc/libjava -I./include -I./gcj -I/src/gc c/libjava -Iinclude -I/src/gcc/libjava/include -I/src/gcc/libjava/classpath/incl ude -Iclasspath/include -I/src/gcc/libjava/classpath/native/fdlibm -I/src/gcc/li bjava/../boehm-gc/include -I../boehm-gc/include -I/src/gcc/libjava/.././libjava/ ../gcc -I/src/gcc/libjava/../zlib -I/src/gcc/libjava/../libffi/include -I../libf fi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enu m -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/usr/local\" -DTOOLEXECLIBDIR=\"/usr/local/lib/gcc/i686 -pc-cygwin/4.3.2\" -DJAVA_HOME=\"/usr/local\" -DBOOT_CLASS_PATH=\"/usr/local/sha re/java/libgcj-4.3.2.jar\" -DJAVA_EXT_DIRS=\"/usr/local/share/java/ext\" -DGCJ_E NDORSED_DIRS=\"/usr/local/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/us r/local/lib/gcj-4.3.2-9\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DE FAULT_DATABASE=\"/usr/local/lib/gcj-4.3.2-9/classmap.db\" -DLIBGCJ_DEFAULT_DATAB ASE_PATH_TAIL=\"gcj-4.3.2-9/classmap.db\" -O2 -g -g -O2 -MT java/net/natVMInetAd dress.lo -MD -MP -MF java/net/.deps/natVMInetAddress.Tpo -c java/net/natVMInetAd dress.cc -DDLL_EXPORT -DPIC -o java/net/.libs/natVMInetAddress.o java/net/natVMInetAddress.cc:42: error: declaration of C function 'int gethostna me(char*, int)' conflicts with /src/gcc/newlib/libc/include/sys/unistd.h:227: error: previous declaration 'int gethostname(char*, size_t)' here make[3]: *** [java/net/natVMInetAddress.lo] Error 1 make[3]: Leaving directory `/obj/gcc.4/i686-pc-cygwin/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/obj/gcc.4/i686-pc-cygwin/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/obj/gcc.4' make: *** [all] Error 2 [EMAIL PROTECTED] /obj/gcc.4 $ more /obj/gcc.4/config.log $ /src/gcc/configure -disable-nls STAGE_CC_WRAPPER=ccache -prefix=/usr/local - exec-prefix=/usr/local -libdir=/usr/local/lib -libexecdir=/usr/local/lib -mandir =/usr/local/share/man -infodir=/usr/local/share/info -enable-languages=c,c++,for tran,java,objc,obj-c++ -disable-nls -without-included-gettext -enable-version-sp ecific-runtime-libs -without-x -enable-libgcj -disable-java-awt -with-system-zli b -enable-interpreter -disable-libgcj-debug -enable-threads=posix -enable-java-g c=boehm -disable-win32-registry -enable-sjlj-exceptions -enable-hash-synchroniza tion -enable-libstdcxx-debug Probably the right fix here is some configury to look for the declaration of gethostname and if it is found, be sure to #include where it is found, and not declare it one's self? - Jay
RE: [Cygwin] some random build breaks
if using POSIX threads that have the mutexattr functions.]) # Assume we do not have getuid and friends. AC_DEFINE(NO_GETUID, 1, [Define if getuid() and friends are missing.]) PLATFORMNET=NoNet else AC_CHECK_FUNCS([strerror_r select fstat open fsync sleep opendir \ localtime_r getpwuid_r getcwd \ ... So it doesn't try to figure things out, just seems to assume the wrong thing. This is not even building a cross compiler. I specified no build/host/target, just building native cygwin. Maybe native cygwin is unusual, in that newlib is usually embedded and therefore cross? I guess. And embedded folks don't use Java?? At least not gcc's Java? This is gcc 4.3.2, but gccsvn looks about the same -- at least libjava/configure.ac does. Configure line was: $ /src/gcc/configure -disable-nls STAGE_CC_WRAPPER=ccache -prefix=/usr/local - exec-prefix=/usr/local -libdir=/usr/local/lib -libexecdir=/usr/local/lib -mandir =/usr/local/share/man -infodir=/usr/local/share/info -enable-languages=c,c++,for tran,java,objc,obj-c++ -disable-nls -without-included-gettext -enable-version-sp ecific-runtime-libs -without-x -enable-libgcj -disable-java-awt -with-system-zli b -enable-interpreter -disable-libgcj-debug -enable-threads=posix -enable-java-g c=boehm -disable-win32-registry -enable-sjlj-exceptions -enable-hash-synchroniza tion -enable-libstdcxx-debug Thanks and sorry for the attitude, - Jay > Date: Sun, 14 Sep 2008 16:28:55 -0500 > From: aaron@ > To: jay@ > CC: gcc@ > Subject: Re: [Cygwin] some random build breaks > > Jay wrote: > >> Creating library file: ./shlib/libgcc_s.a.tmp >> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: >> warning: ca >> nnot find entry symbol [EMAIL PROTECTED]; defaulting to 10001000 >> _absvsi2_s.o: In function `__absvsi2': >> /src/gccsvn/libgcc/../gcc/libgcc2.c:237: undefined reference to `_abort' > ... >> collect2: ld returned 1 exit status >> make[1]: *** [libgcc_s.dll] Error 1 > > Can you please try the attached patch to see if it fixes things, and let > me know the result? Thanks in advance. > > >> java/net/natVMInetAddress.cc:42: error: declaration of C function 'int >> gethostna >> me(char*, int)' conflicts with >> /src/gcc/newlib/libc/include/sys/unistd.h:227: error: previous declaration >> 'int >> gethostname(char*, size_t)' here > ... >> Probably the right fix here is some configury to look for the declaration of >> gethostname >> and if it is found, be sure to #include where it is found, and not declare >> it one's self? > > Yes. This is a problem with libjava's autoconfigury. > HAVE_GETHOSTNAME_DECL should be defined, but for some reason isn't. If > you examine the configury files in libjava/ such as config.log, > configure, and configure.ac, you probably will find some clues regarding > whats happening here.
are folks interested in native bootstrapping on SGI with a slightly odd native compiler?
n't have to handle different whitespace around the "=". I didn't dig into this. The compiler thinks obstack[_alloc] returns char* and I didn't check if that is always the case or is configured between char* and void*. If configury, probably fix that. If always char*, the compiler seems right here, and I suspect this is fixedin 4.4 anyway, for C++ compat. - Functions in gcc's combine.c seem to give the compiler a headache. It gives what I deemed nonsense errors, like "lang_hook not a member of lang_hook". Since the functions appear to "only" be doing optimization, I neutered them by just having them return 0 or their input, whatever appeared correct for merely doing no optimization. It may also be reasonable to break up some of the large functions into smaller functions, but that is a bit lame I realize. This last one is the one for which I most don't know how to form an acceptable general patch. It would probably be to come up with some #ifdefs that partition this compiler only and no others. Or maybe something completely manual like BOOT_CFLAGS=-DGCC_NO_COMBINE. So long story, sorry, -- are folks interested in - bootstrapping from this compiler? - more important, open to the patches, vaguely described, to make it so? other than the combine.c one yet to be well formulated, I think they are pretty ok patches, that don't screw up the code for everyone in the interest of the out-lier I realize, the actual patches would need to be presented -- though I've made them mostly obvious. But I'm just wondering if I should go the effort of presenting them .. porting to current, etc. I don't have them in an acceptable form yet. I apply them manually the first few times, then when I got tired of that, I apply them programmatically with Python. I'm loath to maintain a bunch of actual fragile diffs, with line numbers and such, and so far, not needed. So far code to apply them has felt less fragile, like "remove such and such a line", or "add line after line", or "search and replace" -- no line numbers, and they are all contained in one file. Maybe diff works well with context, and line numbers aren't important, I don't know. If nothing else -- collectors of non-gcc compiler bug lore -- I give you the above. :) - Jay
no response to cfarm request
Hi, I've followed the instructions to request access to the GCC compile farm (https://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F) but heard nothing for two weeks, despite a ping. Are the instructions still correct? Is there anyone else I can contact about it? Thanks, Jay.
Re: no response to cfarm request
Hi, On 9 December 2014 at 09:16, Jay Foad wrote: > I've followed the instructions to request access to the GCC compile > farm (https://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F) but > heard nothing for two weeks, despite a ping. Are the instructions > still correct? Is there anyone else I can contact about it? I've pinged again and waited another week with no response. Is there no-one else who can administer compile farm accounts? Thanks, Jay.
Re: Why is floor() only compiled to roundsd when using -funsafe-math-optimizations?
On 26 January 2015 at 23:50, Fredrik Tolf wrote:
> Dear list,
>
> Consider the following small program:
>
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
> double a;
>
> a = strtod(argv[0], NULL);
> printf("%f\n", floor(a));
> return(0);
> }
>
> When compiling this with a -march that supports the roundsd instruction, the
> floor() call seems to only be compiled to such an instruction if
> -funsafe-math-optimizations is specified.
>
> Why is this? I notice the glibc's floor() implementation (for SSE4.1-enabled
> processors) consists of only this instruction, so barring a bug in glibc,
> that would seem to imply to me the roundsd is IEEE-compliant and safe. Why
> does GCC consider it unsafe?
I asked the same thing: https://gcc.gnu.org/ml/gcc-help/2014-01/msg00051.html
Jay.
returning struct or union with just double on Win32/x86
typedef struct { double d; } Struct;
Struct f1 ()
{
Struct res = {3.0};
return res;
}
typedef union { double d; } Union;
Union f2 ()
{
Union res = {3.0};
return res;
}
x86 mingw 7.3.0
The first returns in ST0, the second in edx:eax.
Msvc returns first in edx:eax.
Seems like a bug?
Thank you,
- Jay
computed goto, const, truncated int, C++, etc.
computed goto.
The documentation advertises read only relative address.
Like this:
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
```
static const int array[] = { &&foo - &&foo, &&bar - &&foo,
&&hack - &&foo };
goto *(&&foo + array[i]);
```
However, this doesn't quite work and is a little flawed.
What one wants is:
1. int or int32_t, as stated.
1b. Or a target specific type provided by the compiler
that encompasses the largest distance in a function.
But in reality that is int/int32_t.
Not blow the space unnecessarily on a 64bit integer, if executables and
therefore distances within functions are limited to 32bits (I realize, there is
a signnedess problem hypothethically, but ultimately I expect an assembler or
linker warning for the label math overflow).
2. Syntax that works in C and C++.
And is truly const, no dynamic initializer.
This is crucial.
3. Preferably without casting.
But if I must, ok.
4. Instead of relative to a label, I should be able to use relative
to the array itself. Which then only allows a single ampersand.
Double might be nice, but whatever works.
I think that might save an instruction.
It isn't critical.
5. 32bit and 64bit.
Crucial.
Many combinations do work, but you sometimes have to cast
to char* or int or size_t.
Sometimes have to narrow.
Only sometimes can use the address of the array.
Not always valid C and C++.
And not all combinations do work.
We have code that compiles as C or C++, unless/until we decide
to use C++, and I couldn't make it work across the board.
But now I'll see if the code is really any better than switch...
- Jay
extern const initialized warns in C
extern const int foo = 123; Why does this warn? This is a valid portable form, with the same meaning across all compilers, and, importantly, portably to C and C++. I explicitly do not want to say: const int foo = 123 because I want the code to be valid and have the same meaning in C and C++ (modulo name mangling). I end up with: // Workaround gcc warning. #ifdef __cplusplus #define EXTERN_CONST extern const #else #define EXTERN_CONST const #endif EXTERN_CONST int foo = 123; and having to explain it to people. $ cat 1.c extern const int foo = 123; $ $HOME/gcc720/bin/gcc -c -S 1.c 1.c:1:18: warning: 'foo' initialized and declared 'extern' extern const int foo = 123; ^~~ $ $HOME/gcc720/bin/gcc -c -S -xc++ -Wall -pedantic 1$ $HOME/gcc720/bin/gcc -v Using built-in specs. COLLECT_GCC=/Users/jay/gcc720/bin/gcc COLLECT_LTO_WRAPPER=/Users/jay/gcc720/libexec/gcc/x86_64-apple-darwin16.7.0/7.2.0/lto-wrapper Target: x86_64-apple-darwin16.7.0 Configured with: ../gcc-7.2.0/configure -prefix=/Users/jay/gcc720 -disable-nls -disable-bootstrap Thread model: posix gcc version 7.2.0 (GCC) $ Thank you, - Jay
Re: extern const initialized warns in C
By this argument there is a missing warning for the equivalent:
const int foo = 123;
with no previous extern declaration.
As well, there is no warning in C++.
All three constructs are equivalent, yet only one gets a warning.
Interesting point, that I had not realized, and with an often acceptable
workaround, however also there exist coding conventions that prohibit use of
static.
Instead they "hide" things by omitting them from headers only.
That can still be worked around, just put the declaration right before the
definition,
in the same source file.
I realize there are many arguments for and against file level static.
- Jay
From: David Brown
Sent: Monday, January 22, 2018 8:32 AM
To: Jay K; gcc
Subject: Re: extern const initialized warns in C
On 21/01/18 08:12, Jay K wrote:
> extern const int foo = 123;
>
>
>
> Why does this warn?
> This is a valid portable form, with the same meaning
> across all compilers, and, importantly, portably
> to C and C++.
>
> I explicitly do not want to say:
>
> const int foo = 123
>
> because I want the code to be valid and have the same meaning
> in C and C++ (modulo name mangling).
>
> I end up with:
>
> // Workaround gcc warning.
> #ifdef __cplusplus
> #define EXTERN_CONST extern const
> #else
> #define EXTERN_CONST const
> #endif
>
>
> EXTERN_CONST int foo = 123;
>
> and having to explain it to people.
>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977>
45977 – "warning: 'i' initialized and declared 'extern ...
gcc.gnu.org
GCC Bugzilla – Bug 45977 "warning: 'i' initialized and declared 'extern'" could
use a separate warning flag controlling it Last modified: 2017-07-26 15:36:22
UTC
This suggests that gcc authors consider mixing "extern" and
initialization to be such bad style that the compiler warns by default.
But the "bug" is that there is no flag to turn off this warning.
(Ideally every warning should have a matching flag, even if the warning
is enabled by default.)
Usually you do not want to have "extern" and initialisation in the same
line - it indicates a questionable organisation of your sources which is
more likely to be error-prone than the standard idioms. (I say
"questionable", not necessarily wrong - but certainly I would question
it if I saw it in source code.)
Normally you want:
// file.h
// declaration, not definition
extern const int foo;
// file.c
#include
// definition
const int foo = 123;
// otherfile.c
#include
int usefoo(void) { return foo; }
The key advantages of this sort of setup are a cleaner separation
between declarations (which you need to /use/ things) and the
definitions (which should normally only exist once in the program -
certainly for C). The declarations and definitions only exist in one
place, and they are checked for consistency - there are no "extern"
declarations lying around in C files that might get out of step from
changes in the headers or other files with definitions.
To be consistent with this, and to work consistently with C and C++, I
have a strict policy that a C (or C++) file never contains declarations
without definitions (and initialisations as needed), with each
definition either also declared as "extern" in a matching header file,
or it is declared as "static".
This sort of arrangement is very common - though many people are lazy
about using "static". (In C++, you can also use anonymous namespaces,
but "static" works for consistency between C and C++.)
Still, gcc should have a flag to disable this warning if you have reason
to use "extern const int foo = 123;" - it is, after all, correctly
defined C code.
> $ cat 1.c
> extern const int foo = 123;
> $ $HOME/gcc720/bin/gcc -c -S 1.c
> 1.c:1:18: warning: 'foo' initialized and declared 'extern'
> extern const int foo = 123;
> ^~~
> $ $HOME/gcc720/bin/gcc -c -S -xc++ -Wall -pedantic 1$ $HOME/gcc720/bin/gcc -v
> Using built-in specs.
>
> COLLECT_GCC=/Users/jay/gcc720/bin/gcc
> COLLECT_LTO_WRAPPER=/Users/jay/gcc720/libexec/gcc/x86_64-apple-darwin16.7.0/7.2.0/lto-wrapper
> Target: x86_64-apple-darwin16.7.0
> Configured with: ../gcc-7.2.0/configure -prefix=/Users/jay/gcc720
> -disable-nls -disable-bootstrap
> Thread model: posix
> gcc version 7.2.0 (GCC) $
>
>
> Thank you,
> - Jay
>
>
>
>
>
Re: extern const initialized warns in C
Also the warning did not include a link explaining the desired workaround.
Since you advocate for static...and I know it has big value..
There are the following reasons against static:
- It is prohibited in some coding conventions.
They instead hide symbols by omitting them from any headers.
- It allows/encourages symbols duplicated from a human point of view,
leading to harder to read code; but this is also the point and good,
it offers scope to pick shorter names, or at least hide
names (you can still strive for globally unique names, in
case the symbols later have to be made extern)
- it leads to accidental duplication, static int foo = 123 in a header
- There are toolsets that don't resolve statics in disassembly
- It only allows for sharing within a file and hiding from all others,
it doesn't allow sharing for within a few files and hiding from others
- It sort of doesn't work with "unity builds" old fashioned LTO/LTCG where one
source file includes the rest
I think a linker switch to report symbols that could be static
might be useful.
I find the "scoping" too hard to pass it, and if I need to make
the symbol extern in future, I can afford a rename to do it.
- Jay
From: Jay K
Sent: Monday, January 22, 2018 9:31 AM
To: David Brown; gcc
Subject: Re: extern const initialized warns in C
By this argument there is a missing warning for the equivalent:
const int foo = 123;
with no previous extern declaration.
As well, there is no warning in C++.
All three constructs are equivalent, yet only one gets a warning.
Interesting point, that I had not realized, and with an often acceptable
workaround, however also there exist coding conventions that prohibit use of
static.
Instead they "hide" things by omitting them from headers only.
That can still be worked around, just put the declaration right before the
definition,
in the same source file.
I realize there are many arguments for and against file level static.
- Jay
From: David Brown
Sent: Monday, January 22, 2018 8:32 AM
To: Jay K; gcc
Subject: Re: extern const initialized warns in C
On 21/01/18 08:12, Jay K wrote:
> extern const int foo = 123;
>
>
>
> Why does this warn?
> This is a valid portable form, with the same meaning
> across all compilers, and, importantly, portably
> to C and C++.
>
> I explicitly do not want to say:
>
> const int foo = 123
>
> because I want the code to be valid and have the same meaning
> in C and C++ (modulo name mangling).
>
> I end up with:
>
> // Workaround gcc warning.
> #ifdef __cplusplus
> #define EXTERN_CONST extern const
> #else
> #define EXTERN_CONST const
> #endif
>
>
> EXTERN_CONST int foo = 123;
>
> and having to explain it to people.
>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977>
45977 – "warning: 'i' initialized and declared 'extern ...
gcc.gnu.org
GCC Bugzilla – Bug 45977 "warning: 'i' initialized and declared 'extern'" could
use a separate warning flag controlling it Last modified: 2017-07-26 15:36:22
UTC
45977 – "warning: 'i' initialized and declared 'extern ...
gcc.gnu.org
GCC Bugzilla – Bug 45977 "warning: 'i' initialized and declared 'extern'" could
use a separate warning flag controlling it Last modified: 2017-07-26 15:36:22
UTC
This suggests that gcc authors consider mixing "extern" and
initialization to be such bad style that the compiler warns by default.
But the "bug" is that there is no flag to turn off this warning.
(Ideally every warning should have a matching flag, even if the warning
is enabled by default.)
Usually you do not want to have "extern" and initialisation in the same
line - it indicates a questionable organisation of your sources which is
more likely to be error-prone than the standard idioms. (I say
"questionable", not necessarily wrong - but certainly I would question
it if I saw it in source code.)
Normally you want:
// file.h
// declaration, not definition
extern const int foo;
// file.c
#include
// definition
const int foo = 123;
// otherfile.c
#include
int usefoo(void) { return foo; }
The key advantages of this sort of setup are a cleaner separation
between declarations (which you need to /use/ things) and the
definitions (which should normally only exist once in the program -
certainly for C). The declarations and definitions only exist in one
place, and they are checked for consistency - there are no "extern"
declarations lying around in C files that might get out of step from
changes in the headers or other files with definitions.
To be consistent with this, and to work consistently with C and C++, I
have a strict policy that a C (or C++) file never con
Re: extern const initialized warns in C
> I find the "scoping" too hard to pass it, and if I need to make > the symbol extern in future, I can afford a rename to do it. I mean, I actually like like the ability to shorten file level static symbols. As you point out, true, you can have it both ways, static does not force shortening, merely allows it, and protects you from inadvertant duplication. Really, the prohibition against file level static is used in large code bases. You already have to chose unique extern names, and depend on the linker to diagnose duplicate externals for them. Extending this by barring statics isn't necessarily significant. Such code bases prefix every extern identifier with some "local" prefix, and any missing prefix is easy to spot and a stylistic mistake. (i.e. local to the subsystem or directory -- I realize it is the very definition of "local" that makes or break this) I understand that hiding by omission from headers is not hiding at the linker level. I agree there are scalability problems with naming in C, but it isn't clear static helps significantly. There is an interesting side effect though that I think is not very much appreciated. Large C code bases are more amenable to plain text search than large C++ code bases, due to the "more uniqueness" of symbols. This plain text search aspect is one of extremely few advantages I see to C over C++, perhaps the only one. - Jay From: David Brown Sent: Monday, January 22, 2018 10:14 AM To: Jay K; gcc Subject: Re: extern const initialized warns in C Hi, I made some points in my other reply. But for completeness, I'll tackle these too. On 22/01/2018 10:38, Jay K wrote: > Also the warning did not include a link explaining the desired workaround. > > > Since you advocate for static...and I know it has big value.. > > There are the following reasons against static: > > - It is prohibited in some coding conventions. > They instead hide symbols by omitting them from any headers. As noted before, that is insane. It gives no benefits but makes it easy to cause mistakes that are hard to find. > > - It allows/encourages symbols duplicated from a human point of view, > leading to harder to read code; but this is also the point and good, > it offers scope to pick shorter names, or at least hide > names (you can still strive for globally unique names, in > case the symbols later have to be made extern) Omitting "static" also allows symbol duplication. It just means that such duplication is an error in the code - which may or may not be caught at link time. You /can/ have a coding convention that discourages duplicate symbol names - even when using "static". That might help a little in understanding, but will quickly mean bloated source code that is harder to read and follow (because you end up with long-winded symbol names everywhere). Such conventions are not scalable, are hopeless for multi-programmer projects, terrible for code re-use, and can make code far harder to read and write. The scoping and naming in C is limited enough without omitting half the features it has to deal with modularisation. > > - it leads to accidental duplication, static int foo = 123 in a header It is quite simple - don't do that. It is appropriate for constant data - "static const int foo = 123;" in a header will be fine, because "foo" has the same value everywhere and is likely to be "optimised away". That is the reason C++ makes "const int foo = 123;" effectively static. Headers (in C, and mostly in C++) are for /declarations/, not definitions - at least if you want to write structured and modular code. > > - There are toolsets that don't resolve statics in disassembly Statics are local to the file. Disassemblies should show them when they are used. For the tiny, tiny proportion of C programmers that ever use a disassembler, if their toolchains are not good enough then they should get better toolchains. It should /never/ be a problem when using assembly listing files generated by the compiler, which are almost always more useful than disassembling object code. Making a coding convention to suit this requirement is like making gloves with 6 fingers so that they fit people with an extra digit. > > - It only allows for sharing within a file and hiding from all others, > it doesn't allow sharing for within a few files and hiding from others C has no good way to allow sharing between a few files and hiding from others. Such shared identifiers must be program-wide global. But that does /not/ mean you should make /everything/ program-wide global! It means you should minimise such sharing, prefix such shared names in a way likely to minimise conflicts, and organise your source c
Re: extern const initialized warns in C
> If you put static (non-const) > variables in your header files, you have misunderstood how to use header > files in C programming. Not me, and usually const, but people do it, both. Even the consts can get duplicated. Even the simple C++ const int one = 1; I can take the address of. It is also unusual and maybe dumb. There are too many programmers writing C and C++ with too little oversight to rule these out. The static prohibition might be too closed to identity. I understand about the local edit, but it behooves one to make the non-edited build debugable too. I know you can only go so far, can't litter it with printf or breakpoints or volatile, nor can compile it unoptimized and ship it, but uniquifying function/data names seems maybe affordable for debuggability of official builds. > If you want to switch from C to C++, that's fine by me But the rest of my team has to agree. > C++ gives you namespaces, which gives you > nother way to group your identifiers and control their scope. I know *all* about C++ but I think for newbies it is best to start out focusing on member functions. Pretend there is a type global namespace to replace C's function global namespace. That is a huge improvement on its own. > It makes a large difference - both for code size and speed I only recently learned of how static impacts ELF visibility and therefore performance. Windows does not work this way, and I'm sure MacOS does either. Non-static on Windows does not imply replacable at dynamic link time, not even if the function is exported. Symbols are always resolved directly within the dll/sharedobject by the static linker if they are present with no pointer or stub in the way. (Ok, if you incorrectly annotate as __declspec(dllexport) and you don't use LTO/LTCG, then you will call through a pointer, but no stub, no actual inter-positionableness, and it is a rare occurence.) There is also always a two level namespace -- imported functions are qualified by the dll name they are expected to be in. For multiple dlls to export the same function name creates no ambiguity and implies no replacement of one by the other, and no semantic difference depending on load order. Unless someone writes very wierd code calling dlopen/dlsym like crazy. There is no LD_PRELOAD, slight loss, and replacing e.g. operator new isn't really possible process-wide, only within the scope of the static link, and even that is so rare, that it is probably sufficient. There is no going out of the way to accurately simulate the static linker at dynamic link time. Functions are only exported if they are annotated in source or listed in a separate file. Not just by being non-static. - Jay From: David Brown Sent: Monday, January 22, 2018 10:42 AM To: Jay K; gcc Subject: Re: extern const initialized warns in C On 22/01/2018 11:14, Jay K wrote: > I meant: > > > extern const foo = 123; > > > does not warn in C++, but by these arguments, should. > Yes, I think it should. But I am a compiler user, not a compiler author, so my bias is strongly towards /my/ code rather than a wider audience. > > > I understand that const int foo = 123 is static in C++. > > It is this difference between C and C++ and the desire to write code > that means the same in C and C++ is why I write extern const int foo = > 123 in the first place. If I was just writing C forever and not planning > to compile as C++ ever then I would omit the redundant extern -- and not > get a warning -- the other inconsistency! As I suggested, put the declaration in the header and the definition in the source file. Then it is the same code for C and C++, works correctly, and gives no warnings no matter what flags you use. And it is modular, structured, and lets programmers see exactly what is "exported" from that C file by looking in a short header rather than digging through a long source file. > > > To repeat for clarity: > > > 1 C: extern const int foo = 123; => warns, for reasons explained and > understood even if not agreed > > 2 C: const int foo = 123; => means the same thing, but no warning; > inconsistent? > > 3 C++: extern const int foo = 123; => also no warning, inconsistent? > > > > The prohibition against file level static is actually quite widespread > and adhered to. > Can you give references or links? As I say, I think such a convention is /seriously/ wrong. (There are plenty of other conventions that I think are wrong - even famous and "professional" standards like MISRA have some daft ideas.) > > Along with it, of course, comes a mandate to pick globally unique names. That mandate I can understand. There are rational justifications for it, even though I don't agree wi
r9 on ARM32?
I'm wondering what is the role of r9 on ARM32, on Linux and Android. On Apple it is documented as long ago reserved, these days available for scratch. I've looked around a bit but haven't gotten the full answer. It is "the PIC register", I see. What does that imply? Volatile? Von-volatile? In particular I'm looking for a spare register, to pass an extra "special" parameter in, that can be considered volatile and never otherwise has a parameter. Most ABIs have a few candidates, but arm32 comes up relatively short. Intra procedural scratch (r12) probably cannot work for me. I know gcc uses it for nested function context and that is laudable. I wish I could guarantee no code between me setting it and it being consumed. And if it is volatile, I'd want the dynamic linker stubs to still preserve it incoming. Thank you, - Jay
how to generate x86 "narrowing" divide instruction
This source code:
$ cat rand.c
#include
uint32_t rand(uint32_t x) { return (uint64_t)x * 16807 % 0x7FFF; }
compiles to this optimised x86 code:
$ gcc -S -O3 -m32 -fomit-frame-pointer -o - rand.c
...
rand:
subl$28, %esp
movl$16807, %eax
mull32(%esp)
movl$2147483647, 8(%esp)
movl$0, 12(%esp)
movl%eax, (%esp)
movl%edx, 4(%esp)
call__umoddi3
addl$28, %esp
ret
Why does the compiler generate a call to __umoddi3, rather than a
single 64- to 32-bit divide/remainder instruction, "div"? Is it
lacking the necessary VRP to determine that the high part of the
dividend is strictly less than the divisor?
I'm using:
$ gcc --version
gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Thanks,
Jay.
suggest more inhibit_libc for ia64-linux -- problems with exception handling when haven't yet built glibc.
Building cross gcc and binutils is easy, but for the libc/libgcc parts. I've
wrestled with this a lot.
I'm trying to build an ia64-linux cross toolset from a Mac.
Including cross building glibc.
I've gone through many options and errors, including sysroot and not,
following the LFS stuff and the CLFS stuff.
(Linux-from-Scratch, Cross-Linux-from-Scratch)
(CLFS good in that it uses sysroot and is cross, but it uses older versions and
for
now I gave up, and non-cross-LFS is basically cross anyway.)
Some of what I hit:
In file included from /src/gcc-4.6.2/libgcc/../gcc/unwind-sjlj.c:30:0:
/obj/gcc/./gcc/include/unwind.h:214:20: fatal error: stdlib.h: No such file or
directory
/src/gcc-4.6.2/libgcc/../gcc/config/ia64/fde-glibc.c:33:20: fatal error:
stdlib.h: No such file or directory
/src/gcc-4.6.2/libgcc/../gcc/config/ia64/fde-glibc.c:36:18: fatal error:
link.h: No such file or directory
and suggest, more use of inhibit_libc:
jbook2:gcc-4.6.2 jay$ diff -u gcc/config/ia64/fde-glibc.c.orig
gcc/config/ia64/fde-glibc.c
--- gcc/config/ia64/fde-glibc.c.orig 2011-11-12 13:30:55.0 -0800
+++ gcc/config/ia64/fde-glibc.c 2011-11-12 13:32:47.0 -0800
@@ -25,6 +25,8 @@
/* Locate the FDE entry for a given address, using glibc ld.so routines
to avoid register/deregister calls at DSO load/unload. */
+#ifndef inhibit_libc
+
#ifndef _GNU_SOURCE
#define _GNU_SOURCE 1
#endif
@@ -160,3 +162,5 @@
return data.ret;
}
+
+#endif
jbook2:gcc-4.6.2 jay$ diff -u gcc/unwind-generic.h.orig gcc/unwind-generic.h
--- gcc/unwind-generic.h.orig 2011-11-12 13:02:32.0 -0800
+++ gcc/unwind-generic.h 2011-11-12 16:11:46.0 -0800
@@ -211,7 +211,9 @@
compatible with the standard ABI for IA-64, we inline these. */
#ifdef __ia64__
+#ifndef inhibit_libc
#include
+#endif
static inline _Unwind_Ptr
_Unwind_GetDataRelBase (struct _Unwind_Context *_C)
@@ -223,7 +225,9 @@
static inline _Unwind_Ptr
_Unwind_GetTextRelBase (struct _Unwind_Context *_C __attribute__
((__unused__)))
{
+#ifndef inhibit_libc
abort ();
+#endif
return 0;
}
I understand the result is "broken" and that a second build will be needed.
But that seems to be common practise in building a cross toolset when
"libc" doesn't already exist.
And even then, I'm not done. Maybe this still won't work.
I know about buildroot for example but they don't have IA64 support.
I'm going to see if there is an option for building without any exception
handling support.
It looks like not. Though this diff sort of does that.
Another thing I'll try is skipping libgcc for the first pass.
But I did get an error about missing libgcc when building glibc.
The 64bit math stuff at least ought to go in, but I realize it's probably not
needed for 64bit targets.
Thank you,
- Jay
FW: gcc uses too much stack?
Have people considered that stack space should be used more conservatively by gcc? More malloc, less alloca, fewer/smaller local variables? More std::stack or such, less recursion on the machine stack? (Yes, I know std::stack has no existing use in gcc yet.) Don't make the amount of stack used dependent on the input? If something can be compiled with N stack, then anything can be? Is a reasonable goal? You know, heap is generally much larger than stack, and easier to detect exhaustion of? Granted, yes, I understand very well, heap is much slower to allocate and requires explicit free, and is subject to fragmentation. Thanks, - Jay > Date: Sun, 8 Jan 2012 00:05:01 -0500 > To: djgpp-digest-da...@delorie.com > > 2012/01/07/15:03:06 ANNOUNCE: DJGPP port of GNU binutils 2.22 uploaded. > > -- > ... > DJGPP specific changes. > === > - This port allows a maximal number of 4294967296 relocations per object > file > and a maximal number of 4294967296 of lines per executable file. > The previous limits were the classical COFF limitations of 65536 for > boths. > Please note, that due to limitations inherent to DOS and memory ressources > not every file can be compiled. E.g.: to be able to compile a single file > containing up to 3 * 65536 relocations I had to increment stack space of > cc1.exe from 2MB to 10MB. If the file contains 4 * 65536 relocations then > cc1.exe aborts because memory has become exhausted. Neither as.exe nor > ld.exe have shown memory issues. Both have the standard stack space of > 512KB. In other words, even if 32 bit values for relocation and line > counters are now supported by DJGPP port of as.exe and ld.exe it does not > imply that large files can be successfully compiled and linked. There are > memory limitations that may not be solvable. ... > > Enjoy. > > Guerrero, Juan Manuel ...
Re: GMP and GCC 4.3.2
If it's the bug being discussed here: http://gmplib.org/list-archives/gmp-discuss/2009-April/003717.html ... then it was reported as fixed here: http://gcc.gnu.org/ml/gcc/2009-04/msg00562.html Jay.
Re: New no-undefined-overflow branch
> To support languages that have undefined semantics on overflowing > operations the middle-end gets new unary and binary operators > that implicitly encode value-range information about their operands > noting that the operation does not overflow. These does-not-overflow > operators transform the undefined behavior into a valid assumption > and thus make the GIMPLE IL fully defined. >From an optimisation pass's point of view, what's the difference between: 1. a PLUS expression that gives an undefined result on overflow, and 2. a PLUS expression with a guarantee that the result won't overflow. I can't see how they will be handled any differently in practice. Thanks, Jay.
dodgy syntax in acx.m4?
I've just noticed this in config/acx.m4:
dnl GCC_TARGET_TOOL(PROGRAM, TARGET-VAR, HOST-VAR, IN-TREE-TOOL, LANGUAGE)
AC_DEFUN([GCC_TARGET_TOOL],
[AC_MSG_CHECKING(where to find the target $1)
if test "x${build}" != "x${host}" ; then
...
else
ifelse([$4],,,
[ok=yes
case " ${configdirs} " in
*" patsubst([$4], [/.*], []) "*) ;;
*) ok=no ;;
esac
ifelse([$5],,,
[case ,${enable_languages}, in
*,$5,*) ;;
*) ok=no ;;
esac])
if test $ok = yes; then
# An in-tree tool is available and we can use it
$2='$$r/$(HOST_SUBDIR)/$4'
AC_MSG_RESULT(just compiled)
el])if expr "x[$]$2" : "x/" > /dev/null; then
^^
That "el])if" looks very odd. Is it meant to be like that?
Thanks,
Jay.
Re: dodgy syntax in acx.m4?
> If $4 is empty this expands to "if expr ...", otherwise you get "ok=yes > ... if test $ok = yes; then ... elif expr ..." Thanks for the explanation! I didn't realise it was trying to be that clever. Thanks, Jay.
gcc 4.5.0 vms-gcc_shell_handler.c needs #define __NEW_STARLET
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c: In function 'get_dyn_handler_pointer': /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: error: 'PDSCDEF' undeclared (first use in this function) /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: note: each undeclared identifier is reported only once for each function it appears in /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:13: error: 'pd' undeclared (first use in this function) /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: warning: cast to pointer from integer of different size /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: error: expected expression before ')' token /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:17: warning: cast to pointer from integer of different size /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:10: warning: cast to pointer from integer of different size make[4]: *** [vms-gcc_shell_handler.o] Error 1 make[3]: *** [multi-do] Error 1 make[2]: *** [all-multi] Error 2 make[1]: *** [all-target-libgcc] Error 2 make: *** [all] Error 2 fix, put this at top: #ifndef __NEW_STARLET #define __NEW_STARLET #endif - Jay
gcc 4.5.0 stddef.h clobbers __size_t with #define, breaks VMS (code already avoids similar on FreeBSD)
VMS decc$types.h: typedef unsigned int __size_t; but with GCC 4.5.0 this preprocesses as: typedef unsigned int ; and there are ensuing errors e.g. when compiling gcc/libiberty/regex.c probably because of: /usr/local/lib/gcc/alpha-dec-vms/4_5_0/include/stddef.h (it does get included) #if defined (__FreeBSD__) && (__FreeBSD__>= 5) /* __size_t is a typedef on FreeBSD 5!, must not trash it. */ #else #define __size_t #endif presumably should be more like: #if (defined (__FreeBSD__) && (__FreeBSD__>= 5)) || defined(__vms) /* __size_t is a typedef on FreeBSD 5 and VMS, must not trash it! */ #else #define __size_t #endif That gets further, then hits src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2': /src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn: (insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135) (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0) (const_int 5 [0x5]))) -1 (nil)) /src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in extract_insn, at recog.c:2103 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make: *** [regex.o] Error 1 - Jay
gcc-4.5.0 internal compiler error on alpha-dec-vms compiling libiberty/regex.c without -mbwx
> src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2':
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn:
> (insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135)
> (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0)
> (const_int 5 [0x5]))) -1 (nil))
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in
> extract_insn, at recog.c:2103
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
> make: *** [regex.o] Error 1
Fixed by saying make CFLAGS=-mbwx, which enables some byte/word instructions.
More information needed?
Let's see.
Here is the code:
/* Like `insert_op1', but for two two-byte parameters ARG1 and ARG2. */
/* ifdef WCHAR, integer parameter is 1 wchar_t. */
static void
PREFIX(insert_op2) (re_opcode_t op, UCHAR_T *loc, int arg1,
int arg2, UCHAR_T *end)
{
register UCHAR_T *pfrom = end;
register UCHAR_T *pto = end + 1 + 2 * OFFSET_ADDRESS_SIZE;
while (pfrom != loc)
*--pto = *--pfrom;
PREFIX(store_op2) (op, loc, arg1, arg2);
}
Here is a reduced/preprocessed form that hits the same problem:
jbook2:~ jay$ cat re.c
typedef unsigned char UCHAR;
void insert_op2 (UCHAR *loc, UCHAR *end)
{
UCHAR *pfrom = end;
UCHAR *pto = end + 1;
while (pfrom != loc)
*--pto = *--pfrom;
}
jbook2:~ jay$ alpha-dec-vms-gcc -c re.c
jbook2:~ jay$ alpha-dec-vms-gcc -c -O2 re.c
re.c: In function 'insert_op2':
re.c:10:1: error: unrecognizable insn:
(insn 58 57 59 5 re.c:9 (set (reg:DI 120)
(plus:SI (subreg/s:SI (reg/v/f:DI 108 [ pfrom ]) 0)
(const_int 1 [0x1]))) -1 (nil))
re.c:10:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
jbook2:~ jay$
I opened a bug in the database.
- Jay
gcc4.5.0/libiberty/pex-common.h missing pid_t on vms
In file included from /src/gcc-4.5.0/libiberty/pex-common.c:23:0: /src/gcc-4.5.0/libiberty/pex-common.h:73:3: error: expected specifier-qualifier-list before 'pid_t' the code: /* pid_t is may defined by config.h or sys/types.h needs to be included. */ #if !defined(pid_t) && defined(HAVE_SYS_TYPES_H) #include #endif proposed/tested fix: #ifdef __vms #include #endif or similar. This then hits: /usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/unistd.h:475:22: error: macro "geteuid" passed 1 arguments, but takes just 0 /usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/unistd.h:476:22: error: macro "getuid" passed 1 arguments, but takes just 0 make[2]: *** [pex-common.o] Error 1 But I say that's a bug in the VMS headers and I patch it: #if __USE_LONG_GID_T # pragma __extern_prefix __save # pragma __extern_prefix "__long_gid_" #elif __CRTL_VER>= 7000 && !defined(_VMS_V6_SOURCE) # if __CAN_USE_EXTERN_PREFIX # pragma __extern_prefix __save # pragma __extern_prefix "__unix_" # else -# define geteuid() __unix_geteuid() -# define getuid() __unix_getuid() +# define geteuid __unix_geteuid +# define getuid __unix_getuid # endif #endif __uid_t geteuid (void); __uid_t getuid (void); I did the same thing in the VMS header unixlib.h. Maybe something for fixincludes? (along with #define __NEW_STARLET, #define __int64 long long...) (Alternate interpretation is that gcc should implement __CAN_USE_EXTERN_PREFIX and the #pragmas. I'd be willing to #define __USE_LONG_GID_T but I assume the pragmas are a problem.) - Jay
gcc 4.5.0 libiberty .o vs. .obj confusion
build=i386-darwin
host=alpha-dec-vms
target=alpha-dec-vms
alpha-dec-vms-ar rc ./libiberty.a \
./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o
./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o
./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o
./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o
./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o
./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o
./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o
./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o
./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./asprintf.obj
./insque.obj ./memmem.obj ./mempcpy.obj ./mkstemps.obj ./stpcpy.obj
./stpncpy.obj ./strndup.obj ./strverscmp.obj ./vasprintf.obj ./vfork.obj
./strncmp.obj
alpha-dec-vms-ar: ./asprintf.obj: No such file or directory
make: *** [libiberty.a] Error 1
jbook2:libiberty jay$ edit Makefile
alpha-dec-gcc -c foo.c outputs foo.obj.
"Something" seems to know this, since:
libiberty/Makefile.in:
LIBOBJS = @LIBOBJS@
libiberty/Makefile:
LIBOBJS = ${LIBOBJDIR}./asprintf$U.obj ${LIBOBJDIR}./insque$U.obj
${LIBOBJDIR}./memmem$U.obj ${LIBOBJDIR}./mempcpy$U.obj
${LIBOBJDIR}./mkstemps$U.obj ${LIBOBJDIR}./stpcpy$U.obj
${LIBOBJDIR}./stpncpy$U.obj ${LIBOBJDIR}./strndup$U.obj
${LIBOBJDIR}./strverscmp$U.obj ${LIBOBJDIR}./vasprintf$U.obj
${LIBOBJDIR}./vfork$U.obj ${LIBOBJDIR}./strncmp$U.obj
and then later there are explicit rules for building asprintf.o, etc.
I'll probably just hack the configure Makefile to say .o.
This could be an autoconf/automake bug.
Or maybe libiberty is supposed to say $O or such in place of .o?
- Jay
RE: gcc 4.5.0 libiberty .o vs. .obj confusion
I'm guessing that every ".o" in libiberty/Makefile.in should be changed to
$(OBJEXT).
Thanks,
- Jay
> From: jay.kr...@cornell.edu
> To: gcc@gcc.gnu.org
> Subject: gcc 4.5.0 libiberty .o vs. .obj confusion
> Date: Mon, 3 May 2010 11:29:15 +
>
>
> build=i386-darwin
> host=alpha-dec-vms
>
> target=alpha-dec-vms
>
>
> alpha-dec-vms-ar rc ./libiberty.a \
> ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o
> ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o
> ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o
> ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o
> ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o
> ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o
> ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o
> ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o
> ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o
> ./xstrndup.o ./asprintf.obj ./insque.obj ./memmem.obj ./mempcpy.obj
> ./mkstemps.obj ./stpcpy.obj ./stpncpy.obj ./strndup.obj ./strverscmp.obj
> ./vasprintf.obj ./vfork.obj ./strncmp.obj
> alpha-dec-vms-ar: ./asprintf.obj: No such file or directory
> make: *** [libiberty.a] Error 1
> jbook2:libiberty jay$ edit Makefile
>
>
> alpha-dec-gcc -c foo.c outputs foo.obj.
>
> "Something" seems to know this, since:
>
> libiberty/Makefile.in:
> LIBOBJS = @LIBOBJS@
>
>
> libiberty/Makefile:
> LIBOBJS = ${LIBOBJDIR}./asprintf$U.obj ${LIBOBJDIR}./insque$U.obj
> ${LIBOBJDIR}./memmem$U.obj ${LIBOBJDIR}./mempcpy$U.obj
> ${LIBOBJDIR}./mkstemps$U.obj ${LIBOBJDIR}./stpcpy$U.obj
> ${LIBOBJDIR}./stpncpy$U.obj ${LIBOBJDIR}./strndup$U.obj
> ${LIBOBJDIR}./strverscmp$U.obj ${LIBOBJDIR}./vasprintf$U.obj
> ${LIBOBJDIR}./vfork$U.obj ${LIBOBJDIR}./strncmp$U.obj
>
>
> and then later there are explicit rules for building asprintf.o, etc.
> I'll probably just hack the configure Makefile to say .o.
>
>
> This could be an autoconf/automake bug.
> Or maybe libiberty is supposed to say $O or such in place of .o?
>
>
> - Jay
>
internal compiler error compiling gmp/get_d/gmpn_get_d for alpha-dec-vms
build=i386-darwin host=alpha-dec-vms target=alpha-dec-vms /bin/sh ../libtool --mode=compile alpha-dec-vms-gcc -mbwx -std=gnu99 -DHAVE_CONFIG_H -I. -I/src/gcc-4.5.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I/src/gcc-4.5.0/gmp -DOPERATION_`echo get_d | sed 's/_$//'` -g -O2 -c -o get_d.lo get_d.c alpha-dec-vms-gcc -mbwx -std=gnu99 -DHAVE_CONFIG_H -I. -I/src/gcc-4.5.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I/src/gcc-4.5.0/gmp -DOPERATION_get_d -g -O2 -c get_d.c -o get_d.obj get_d.c: In function '__gmpn_get_d': get_d.c:490:1: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:16269 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [get_d.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 jbook2:gmp jay$ I said make CFLAGS=-mieee and it seemed to fix it. I think that merely turned off optimization though. I did configure gcc in the first place with -disable-shared -enable-sjlj-exception, since there were problems compiling the libgcc/Dwarf stuff. I can try "normal" there again. - Jay
RE: gcc4.5.0/libiberty/pex-common.h missing pid_t on vms
> Use #ifdef HAVE_UNISTD_H instead. There are many examples in > libiberty. > > Ian Thanks Ian, that worked. --- /src/orig/gcc-4.5.0/libiberty/pex-common.h 2009-04-13 03:45:58.0 -0700 +++ /src/gcc-4.5.0/libiberty/pex-common.h 2010-05-04 06:43:24.0 -0700 @@ -31,6 +31,9 @@ #if !defined(pid_t) && defined(HAVE_SYS_TYPES_H) #include #endif +#ifdef HAVE_UNISTD_H +#include +#endif #define install_error_msg "installation problem, cannot exec `%s'" Perhaps someone can apply it.. Sorry, not me. - Jay
RE: gcc 4.5.0 libiberty .o vs. .obj confusion
> CC: gcc@ > From: iant@ > > Jay: >> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to >> $(OBJEXT). > > Yes. > > Ian Thanks. Specifically ".o" goes to "@objext@". There's no way I'm going to be able to get "the papers" in. I can try to squeak by via triviality of change. I'm slightly derailed on other aspects of targeting VMS (e.g. *crt0*.c, vms-crtl.h), but this did work for me, attached. It's many lines, but highly mechanical. There are a few places where ".o" occurs in comments, can be left alone. There is: .c.o: false > .c.obj: > false and < -rm -rf *.o pic core errs \#* *.E a.out > -rm -rf *.o *.obj pic core errs \#* *.E a.out and I wrapped the affected lines to one file per line, and spaces instead of tabs (consistent rendering) - Jay 119a120,122 > .c.obj: > false > 160,178c163,213 < REQUIRED_OFILES = \ < ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o\ < ./alloca.o ./argv.o \ < ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o \ < ./dyn-string.o \ < ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o\ < ./fnmatch.o ./fopen_unlocked.o \ < ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o\ < ./hashtab.o ./hex.o \ < ./lbasename.o ./lrealpath.o \ < ./make-relative-prefix.o ./make-temp-file.o \ < ./objalloc.o ./obstack.o\ < ./partition.o ./pexecute.o ./physmem.o \ < ./pex-common.o ./pex-one.o @pexecute@ \ < ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o \ <./strsignal.o \ < ./unlink-if-ordinary.o \ < ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o \ <./xstrerror.o ./xstrndup.o --- > REQUIRED_OFILES = \ > ./reg...@objext@\ > ./cplus-d...@objext@\ > ./cp-demang...@objext@ \ > ./m...@objext@ \ > ./sh...@objext@ \ > ./allo...@objext@ \ > ./ar...@objext@ \ > ./choose-te...@objext@ \ > ./conc...@objext@ \ > ./cp-demi...@objext@\ > ./crc...@objext@\ > ./dyn-stri...@objext@ \ > ./fdmat...@objext@ \ > ./fibhe...@objext@ \ > ./filename_c...@objext@ \ > ./floatform...@objext@ \ > ./fnmat...@objext@ \ > ./fopen_unlock...@objext@ \ > ./geto...@objext@ \ > ./getop...@objext@ \ > ./getp...@objext@ \ > ./getrunti...@objext@ \ > ./hasht...@objext@ \ > ./h...@objext@ \ > ./lbasena...@objext@\ > ./lrealpa...@objext@\ > ./make-relative-pref...@objext@ \ > ./make-temp-fi...@objext@ \ > ./objall...@objext@ \ > ./obsta...@objext@ \ > ./partiti...@objext@\ > ./pexecu...@objext@ \ > ./physm...@objext@ \ > ./pex-comm...@objext@ \ > ./pex-o...@objext@ \ > @pexecute@ \ > ./safe-cty...@objext@ \ > ./so...@objext@ \ > ./spac...@objext@ \ > ./splay-tr...@objext@ \ > ./strerr...@objext@ \ > ./strsign...@objext@\ > ./unlink-if-ordina...@objext@ \ > ./xatex...@objext@ \ > ./xex...@objext@\ > ./xmall...@objext@ \ > ./xmemd...@objext@ \ > ./xstrd...@objext@ \ > ./xstrerr...@objext@\ > ./xstrnd...@objext@ 183,203c218,276 < CONFIGURED_OFILES = ./asprintf.o ./atexit.o \ < ./basename.o ./bcmp.o ./bcopy.o ./bsearch.o ./bzero.o \ < ./calloc.o ./clock.o ./copysign.o \ < ./_doprnt.o \ < ./ffs.o \ < ./getcwd.o ./getpagesize.o ./gettimeofday.o \ < ./index.o ./insque.o\ < ./memchr.o ./memcmp.o ./memcpy.o ./memmem.o ./memmove.o \ <./mempcpy.o ./memset.o ./mkstemps.o
RE: gcc 4.5.0 libiberty .o vs. .obj confusion
oops, also need like:
--- /src/orig/gcc-4.5.0/libiberty/configure 2010-01-04 15:46:56.0
-0800
+++ /src/gcc-4.5.0/libiberty/configure 2010-05-05 05:40:52.0 -0700
@@ -6533,10 +6533,10 @@
# Figure out which version of pexecute to use.
case "${host}" in
- *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.o ;;
- *-*-msdosdjgpp*) pexecute=./pex-djgpp.o ;;
- *-*-msdos*) pexecute=./pex-msdos.o ;;
- *) pexecute=./pex-unix.o ;;
+ *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.$ac_objext ;;
+ *-*-msdosdjgpp*) pexecute=./pex-djgpp.$ac_objext ;;
+ *-*-msdos*) pexecute=./pex-msdos.$ac_objext ;;
+ *) pexecute=./pex-unix.$ac_objext ;;
esac
--- /src/orig/gcc-4.5.0/libiberty/configure.ac 2010-01-04 15:46:56.0
-0800
+++ /src/gcc-4.5.0/libiberty/configure.ac 2010-05-05 05:45:47.0 -0700
@@ -671,10 +671,10 @@
# Figure out which version of pexecute to use.
case "${host}" in
- *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.o ;;
- *-*-msdosdjgpp*) pexecute=./pex-djgpp.o ;;
- *-*-msdos*) pexecute=./pex-msdos.o ;;
- *) pexecute=./pex-unix.o ;;
+ *-*-mingw* | *-*-winnt*) pexecute=./pex-win32.$ac_objext ;;
+ *-*-msdosdjgpp*) pexecute=./pex-djgpp.$ac_objext ;;
+ *-*-msdos*) pexecute=./pex-msdos.$ac_objext ;;
+ *) pexecute=./pex-unix.$ac_objext ;;
esac
AC_SUBST(pexecute)
I manually edited configure.
I don't know how to keep multiple versions of autoconf installed/working, other
than to use Cygwin and its special packages dedicated to this problem.
configure.ac:3: error: Autoconf version 2.64 or higher is required
configure.ac:3: the top level
autom4te: /usr/bin/gm4 failed with exit status: 63
jbook2:libiberty jay$
- Jay
> From: jay.krell@
> To: i...@m
> CC: g...@g
> Subject: RE: gcc 4.5.0 libiberty .o vs. .obj confusion
> Date: Wed, 5 May 2010 10:10:15 +0000
>
>
>> CC: gcc@
>> From: iant@
>>
>> Jay:
>>> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to
>>> $(OBJEXT).
>>
>> Yes.
>>
>> Ian
>
> Thanks.
>
> Specifically ".o" goes to "@objext@".
>
> There's no way I'm going to be able to get "the papers" in.
> I can try to squeak by via triviality of change.
> I'm slightly derailed on other aspects of targeting VMS (e.g. *crt0*.c,
> vms-crtl.h), but this did work for me, attached.
> It's many lines, but highly mechanical.
> There are a few places where ".o" occurs in comments, can be left alone.
> There is:
>
> .c.o:
> false
>
>> .c.obj:
>>false
>
>
> and
> <-rm -rf *.o pic core errs \#* *.E a.out
>
>>-rm -rf *.o *.obj pic core errs \#* *.E a.out
>
>
> and I wrapped the affected lines to one file per line, and spaces instead of
> tabs (consistent rendering)
>
>
> - Jay
>
more .o vs. .obj targeting VMS
Here's the next one: alpha-dec-vms-ar cru libdecnumber.a decNumber.o decContext.o decimal32.o decimal64.o decimal128.o alpha-dec-vms-ar: decNumber.o: No such file or directory make[2]: *** [libdecnumber.a] Error 1 make[1]: *** [all-libdecnumber] Error 2 make: *** [all] Error 2 jbook2:vms jay$ ls libdecnumber/ Makefile config.log decNumber.obj decimal64.obj config.cache config.status decimal128.obj gstdint.h config.h decContext.obj decimal32.obj stamp-h1 - Jay
gcc/resource.h conflicts with sysroot/usr/include/resource.h (alpha-dec-vms)
lpha-dec-vms-gcc -c -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attri bute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. - I. -I/src/gcc-4.5.0/gcc -I/src/gcc-4.5.0/gcc/. -I/src/gcc-4.5.0/gcc/../include -I/src/gcc-4.5.0/gcc/../libcpp/include -I/obj/gcc/vms/. /gmp -I/src/gcc-4.5.0/gmp -I/obj/gcc/vms/./mpfr -I/src/gcc-4.5.0/mpfr -I/src/gcc-4.5.0/mpc/src -I/src/gcc-4.5.0/gcc/../libdecnumber - I/src/gcc-4.5.0/gcc/../libdecnumber/dpd -I../libdecnumber /src/gcc-4.5.0/gcc/c-lang.c -o c-lang.o In file included from /src/gcc-4.5.0/gcc/resource.h:24:0, from /usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/wait.h:74, from /usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/stdlib.h:51, from /src/gcc-4.5.0/gcc/system.h:211, from /src/gcc-4.5.0/gcc/c-lang.c:24: /src/gcc-4.5.0/gcc/hard-reg-set.h:42:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'HARD_REG_ELT_TYPE' The problem is that there is both gcc/resource.h and sysroot/usr/include/resource.h. When sysroot/usr/include/wait.h does: #if defined _XOPEN_SOURCE_EXTENDED || !defined _POSIX_C_SOURCE # include /* for siginfo_t */ # include /* for struct rusage */ #endif it gets the wrong resource.h for now I patched sysroot/usr/include/wait.h to #include "resource.h" instead. Unfortunate fix is maybe to rename to gcc/gccresource.h? - Jay
builtin ffs vs. renamed ffs (vms-crtl.h)
In gcc for VMS there is some mechanism to rename functions.
See the files:
/src/gcc-4.5.0/gcc/config/vms/vms-crtl-64.h
/src/gcc-4.5.0/gcc/config/vms/vms-crtl.h
which are mostly just lists of function from/to.
As well in gcc there is a mechanism for optimizing various "builtin" functions,
like ffs.
These two mechanisms seem to conflict or be applied in the wrong order.
I didn't look at it deeply.
The symptom is that if you add ffs (to decc$ffs) to vms-crtl.h, the translation
is not done, and you end up with unresolved external ffs.
If you #if out the support for "builtin ffs", it works.
My local hack is below but obviously that's not the way.
I'll enter a bug.
Thanks,
- Jay
diff -u /src/orig/gcc-4.5.0/gcc/builtins.c ./builtins.c
--- /src/orig/gcc-4.5.0/gcc/builtins.c 2010-04-13 06:47:11.0 -0700
+++ ./builtins.c 2010-05-07 23:11:30.0 -0700
@@ -51,6 +51,8 @@
#include "value-prof.h"
#include "diagnostic.h"
+#define DISABLE_FFS
+
#ifndef SLOW_UNALIGNED_ACCESS
#define SLOW_UNALIGNED_ACCESS(MODE, ALIGN) STRICT_ALIGNMENT
#endif
@@ -5899,6 +5901,7 @@
return target;
break;
+#ifndef DISABLE_FFS
CASE_INT_FN (BUILT_IN_FFS):
case BUILT_IN_FFSIMAX:
target = expand_builtin_unop (target_mode, exp, target,
@@ -5906,6 +5909,7 @@
if (target)
return target;
break;
+#endif
CASE_INT_FN (BUILT_IN_CLZ):
case BUILT_IN_CLZIMAX:
@@ -13612,6 +13616,7 @@
case BUILT_IN_ABORT:
abort_libfunc = set_user_assembler_libfunc ("abort", asmspec);
break;
+#ifndef DISABLE_FFS
case BUILT_IN_FFS:
if (INT_TYPE_SIZE < BITS_PER_WORD)
{
@@ -13620,6 +13625,7 @@
MODE_INT, 0), "ffs");
}
break;
+#endif
default:
break;
}
diff -u /src/orig/gcc-4.5.0/gcc/optabs.c ./optabs.c
--- /src/orig/gcc-4.5.0/gcc/optabs.c 2010-03-19 12:45:01.0 -0700
+++ ./optabs.c 2010-05-07 23:11:36.0 -0700
@@ -45,6 +45,8 @@
#include "basic-block.h"
#include "target.h"
+#define DISABLE_FFS
+
/* Each optab contains info on how this target machine
can perform a particular operation
for all sizes and kinds of operands.
@@ -3240,6 +3242,7 @@
return temp;
}
+#ifndef DISABLE_FFS
/* Try implementing ffs (x) in terms of clz (x). */
if (unoptab == ffs_optab)
{
@@ -3247,6 +3250,7 @@
if (temp)
return temp;
}
+#endif
/* Try implementing ctz (x) in terms of clz (x). */
if (unoptab == ctz_optab)
@@ -3268,7 +3272,11 @@
/* All of these functions return small values. Thus we choose to
have them return something that isn't a double-word. */
- if (unoptab == ffs_optab || unoptab == clz_optab || unoptab == ctz_optab
+ if (
+#ifndef DISABLE_FFS
+ unoptab == ffs_optab ||
+#endif
+ unoptab == clz_optab || unoptab == ctz_optab
|| unoptab == popcount_optab || unoptab == parity_optab)
outmode
= GET_MODE (hard_libcall_value (TYPE_MODE (integer_type_node),
@@ -6301,7 +6309,9 @@
init_optab (addcc_optab, UNKNOWN);
init_optab (one_cmpl_optab, NOT);
init_optab (bswap_optab, BSWAP);
+#ifndef DISABLE_FFS
init_optab (ffs_optab, FFS);
+#endif
init_optab (clz_optab, CLZ);
init_optab (ctz_optab, CTZ);
init_optab (popcount_optab, POPCOUNT);
@@ -6558,9 +6568,11 @@
one_cmpl_optab->libcall_basename = "one_cmpl";
one_cmpl_optab->libcall_suffix = '2';
one_cmpl_optab->libcall_gen = gen_int_libfunc;
+#ifndef DISABLE_FFS
ffs_optab->libcall_basename = "ffs";
ffs_optab->libcall_suffix = '2';
ffs_optab->libcall_gen = gen_int_libfunc;
+#endif
clz_optab->libcall_basename = "clz";
clz_optab->libcall_suffix = '2';
clz_optab->libcall_gen = gen_int_libfunc;
@@ -6643,11 +6655,13 @@
satfractuns_optab->libcall_basename = "satfractuns";
satfractuns_optab->libcall_gen = gen_satfractuns_conv_libfunc;
+#ifndef DISABLE_FFS
/* The ffs function operates on `int'. Fall back on it if we do not
have a libgcc2 function for that width. */
if (INT_TYPE_SIZE < BITS_PER_WORD)
set_optab_libfunc (ffs_optab, mode_for_size (INT_TYPE_SIZE, MODE_INT, 0),
"ffs");
+#endif
/* Explicitly initialize the bswap libfuncs since we need them to be
valid for things other than word_mode. */
Thanks,
- Jay
vmsdbgout.c int-to-enum cast and #define globalref
vmsdbgout.c has an int-to-enum warning and needs some form of "globalref" when host=alpha-dec-vms since that #includes the VMS system headers. Perhaps gcc should recognize globalref when target=*vms* and at least interpret it as extern. Thanks, - Jay diff -u /src/orig/gcc-4.5.0/gcc/vmsdbgout.c ./vmsdbgout.c --- /src/orig/gcc-4.5.0/gcc/vmsdbgout.c 2009-11-25 02:55:54.0 -0800 +++ ./vmsdbgout.c 2010-05-06 01:40:20.0 -0700 @@ -21,6 +21,8 @@ along with GCC; see the file COPYING3. If not see <http://www.gnu.org/licenses/>. */ +#define globalref extern + #include "config.h" #include "system.h" #include "coretypes.h" @@ -743,7 +745,7 @@ modbeg.dst_b_modbeg_flags.dst_v_modbeg_version = 1; modbeg.dst_b_modbeg_flags.dst_v_modbeg_unused = 0; modbeg.dst_b_modbeg_unused = 0; - modbeg.dst_l_modbeg_language = module_language; + modbeg.dst_l_modbeg_language = (DST_LANGUAGE)module_language; modbeg.dst_w_version_major = DST_K_VERSION_MAJOR; modbeg.dst_w_version_minor = DST_K_VERSION_MINOR; modbeg.dst_b_modbeg_name = strlen (module_name); @@ -822,7 +824,7 @@ + string count byte + string length */ header.dst__header_length.dst_w_length = DST_K_DST_HEADER_SIZE - 1 + 1 + 4 + 1 + strlen (go); - header.dst__header_type.dst_w_type = 0x17; + header.dst__header_type.dst_w_type = (DST_DTYPE)0x17; totsize += write_debug_header (&header, "transfer", dosizeonly);
pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction
I haven't tried 4.5.0 yet.
-bash-4.1$ /opt/csw/gcc4/bin/g++ -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/op
t/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/
csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --e
nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-st
age1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
Thread model: posix
gcc version 4.3.3 (GCC)
/opt/csw/gcc4/bin/g++ 1.cpp -fPIC -S -m64
"1.s", line 117 : Warning: Illegal subtraction - symbols from different
sections: ".LFB2", ".DOT-2"
"1.s", line 120 : Warning: Illegal subtraction - symbols from different
sections: ".LLSDA2", ".DOT-3"
void F1();
void F2()
{
try { F1(); } catch(...) {F2(); }
}
/usr/ccs/bin/as -xarch=amd64 1.s
or similar:
-bash-4.1$ cat 2.c
void F1() { }
/opt/csw/gcc4/bin/gcc -fPIC -S -funwind-tables -m64 2.c
/usr/ccs/bin/as -xarch=amd64 2.s
Assembler: 2.c
"2.s", line 38 : Warning: Illegal subtraction - symbols from different
sections: ".LFB2", ".DOT-1"
I'm aware of this thread:
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00908.html
I think I'll switch to GNU as, or omit -funwind-tables for now.
Or see if 4.5.0 fixes it.
Sparc32, sparc64, x86 work.
-gstabs+ also generated .stabd that Sun assembler didn't like.
I switched to -gstabs.
Maybe I messed up something though, as it looks like gcc is aware not to output
.stabd to non-gas.
More reason to use GNU assembler, understood.
http://gcc.gnu.org/install/specific.html#ix86-x-solaris210
could be a bit more precise:
>> Recent versions of the Sun assembler in /usr/ccs/bin/as work almost as
well, though.
"almost as well"?
Maybe that should say more, like, use -g or -gstabs instead of -gstabs+, don't
use 64bit+pic+unwind-tables or 64bit+pic+exceptions
I switched to Sun assembler because I'm seeing GNU as installed in different
places on different machines.
Some people don't install /usr/sfw and the install elsewhere.
- Jay
RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction
Ah, good point. I don't think my "real" scenario did that though.
I'll investigate more. Networking problems were?are hampering download 4.5.0 and
build and configure it.
I did come up with Makefile:
Assemble = $(shell if test -x /opt/csw/gnu/as ; then echo /opt/csw/gnu/as ; \
elif test -x /usr/sfw/bin/gas ; then echo /usr/sfw/bin/gas ; \
else echo "unable to find GNU assembler" ; fi )
:) which addresses why I wasn't using GNU as.
(Yes, I've heard of autoconf.)
Thanks, later,
- Jay
> From: pins...@gmail.com
> To: jay.kr...@cornell.edu
> Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section
> subtraction
> Date: Sun, 9 May 2010 17:48:04 -0700
> CC: gcc@gcc.gnu.org
>
>
>
> Sent from my iPhone
>
> On May 9, 2010, at 5:42 PM, Jay K wrote:
>
>>
>> I haven't tried 4.5.0 yet.
>>
>>
>> -bash-4.1$ /opt/csw/gcc4/bin/g++ -v
>> Using built-in specs.
>> Target: i386-pc-solaris2.10
>> Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --
>> exec-prefix=/op
>> t/csw/gcc4
>
>
>
>> --with-gnu-as
>
>
> You configured gcc to build with the gnu as but then run with it so
> what do you expect.
>
>
>> --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
>> usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-
>> prefix=/opt/
>> csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-
>> awt=xlib --e
>> nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix
>> --enable-st
>> age1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
>> Thread model: posix
>> gcc version 4.3.3 (GCC)
>>
>>
>> /opt/csw/gcc4/bin/g++ 1.cpp -fPIC -S -m64
>> "1.s", line 117 : Warning: Illegal subtraction - symbols from
>> different sections: ".LFB2", ".DOT-2"
>> "1.s", line 120 : Warning: Illegal subtraction - symbols from
>> different sections: ".LLSDA2", ".DOT-3"
>> void F1();
>> void F2()
>> {
>> try { F1(); } catch(...) {F2(); }
>> }
>>
>>
>> /usr/ccs/bin/as -xarch=amd64 1.s
>>
>>
>>
>> or similar:
>> -bash-4.1$ cat 2.c
>> void F1() { }
>>
>>
>> /opt/csw/gcc4/bin/gcc -fPIC -S -funwind-tables -m64 2.c
>> /usr/ccs/bin/as -xarch=amd64 2.s
>> Assembler: 2.c
>> "2.s", line 38 : Warning: Illegal subtraction - symbols from
>> different sections: ".LFB2", ".DOT-1"
>>
>>
>> I'm aware of this thread:
>> http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00908.html
>>
>>
>>
>> I think I'll switch to GNU as, or omit -funwind-tables for now.
>> Or see if 4.5.0 fixes it.
>> Sparc32, sparc64, x86 work.
>>
>>
>> -gstabs+ also generated .stabd that Sun assembler didn't like.
>> I switched to -gstabs.
>> Maybe I messed up something though, as it looks like gcc is aware
>> not to output .stabd to non-gas.
>> More reason to use GNU assembler, understood.
>>
>>
>> http://gcc.gnu.org/install/specific.html#ix86-x-solaris210
>> could be a bit more precise:
>>>> Recent versions of the Sun assembler in /usr/ccs/bin/as work
>>>> almost as well, though.
>>
>>
>> "almost as well"?
>> Maybe that should say more, like, use -g or -gstabs instead of -
>> gstabs+, don't use 64bit+pic+unwind-tables or 64bit+pic+exceptions
>>
>>
>> I switched to Sun assembler because I'm seeing GNU as installed in
>> different places on different machines.
>> Some people don't install /usr/sfw and the install elsewhere.
>>
>>
>> - Jay
RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction
Fix in 4.4.0.
I was getting:
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB2-. <<<
.long .LFE2-.LFB2
4.5.0 configured right:
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .l...@rel <<<
.long .LFE0-.LFB0
dw2_asm_output_encoded_addr_rtx =>
#ifdef ASM_OUTPUT_DWARF_PCREL
ASM_OUTPUT_DWARF_PCREL (asm_out_file, size, XSTR (addr, 0));
#else
dw2_assemble_integer (size, gen_rtx_MINUS (Pmode, addr, pc_rtx));
#endif
C:\src\gcc-4.4.0\gcc\config\i386\sol2-10.h(45):#define
ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
C:\src\gcc-4.5.0\gcc\config\i386\sol2-10.h(46):#define
ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
#define ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
do { \
fputs (integer_asm_op (SIZE, FALSE), FILE); \
assemble_name (FILE, LABEL); \
fputs (SIZE == 8 ? "@rel64" : "@rel", FILE); \
} while (0)
#endif
2009-01-29 Rainer Orth
* config/i386/sol2-10.h [!HAVE_AS_IX86_DIFF_SECT_DELTA]
(ASM_OUTPUT_DWARF_PCREL): Define.
http://gcc.gnu.org/viewcvs?view=revision&revision=143758
Thanks,
- Jay
> From: jay.kr...@cornell.edu
> To: pins...@gmail.com
> CC: gcc@gcc.gnu.org
> Subject: RE: pic+64bit+sun assembler+unwind-tables => illegal cross section
> subtraction
> Date: Mon, 10 May 2010 01:02:29 +
>
>
> Ah, good point. I don't think my "real" scenario did that though.
> I'll investigate more. Networking problems were?are hampering download 4.5.0
> and
> build and configure it.
>
> I did come up with Makefile:
>
> Assemble = $(shell if test -x /opt/csw/gnu/as ; then echo /opt/csw/gnu/as ; \
> elif test -x /usr/sfw/bin/gas ; then echo /usr/sfw/bin/gas ; \
> else echo "unable to find GNU assembler" ; fi )
>
> :) which addresses why I wasn't using GNU as.
>
> (Yes, I've heard of autoconf.)
>
> Thanks, later,
> - Jay
>
>
>
>> From: pins...@gmail.com
>> To: jay.kr...@cornell.edu
>> Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section
>> subtraction
>> Date: Sun, 9 May 2010 17:48:04 -0700
>> CC: gcc@gcc.gnu.org
>>
>>
>>
>> Sent from my iPhone
>>
>> On May 9, 2010, at 5:42 PM, Jay K wrote:
>>
>>>
>>> I haven't tried 4.5.0 yet.
>>>
>>>
>>> -bash-4.1$ /opt/csw/gcc4/bin/g++ -v
>>> Using built-in specs.
>>> Target: i386-pc-solaris2.10
>>> Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --
>>> exec-prefix=/op
>>> t/csw/gcc4
>>
>>
>>
>>> --with-gnu-as
>>
>>
>> You configured gcc to build with the gnu as but then run with it so
>> what do you expect.
>>
>>
>>> --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
>>> usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-
>>> prefix=/opt/
>>> csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-
>>> awt=xlib --e
>>> nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix
>>> --enable-st
>>> age1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
>>> Thread model: posix
>>> gcc version 4.3.3 (GCC)
>>>
>>>
>>> /opt/csw/gcc4/bin/g++ 1.cpp -fPIC -S -m64
>>> "1.s", line 117 : Warning: Illegal subtraction - symbols from
>>> different sections: ".LFB2", ".DOT-2"
>>> "1.s", line 120 : Warning: Illegal subtraction - symbols from
>>> different sections: ".LLSDA2", ".DOT-3"
>>> void F1();
>>> void F2()
>>> {
>>> try { F1(); } catch(...) {F2(); }
>>> }
>>>
>>>
>>> /usr/ccs/bin/as -xarch=amd64 1.s
>>>
>>>
>>>
>>> or similar:
>>> -bash-4.1$ cat 2.c
>>> void F1() { }
>>>
>>>
>>> /opt/csw/gcc4/bin/gcc -fPIC -S -funwind-tables -m64 2.c
>>> /usr/ccs/bin/as -xarch=amd64 2.s
>>> Assembler: 2.c
>>> "2.s", line 38 : Warning: Illegal subtraction - symbols from
>>> different sections: ".LFB2", ".DOT-1"
>>>
>>>
>>> I'm aware of this thread:
>>> http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00908.html
>>>
>>>
>>>
>>> I think I'll switch to GNU as, or omit -funwind-tables for now.
>>> Or see if 4.5.0 fixes it.
>>> Sparc32, sparc64, x86 work.
>>>
>>>
>>> -gstabs+ also generated .stabd that Sun assembler didn't like.
>>> I switched to -gstabs.
>>> Maybe I messed up something though, as it looks like gcc is aware
>>> not to output .stabd to non-gas.
>>> More reason to use GNU assembler, understood.
>>>
>>>
>>> http://gcc.gnu.org/install/specific.html#ix86-x-solaris210
>>> could be a bit more precise:
>>>>> Recent versions of the Sun assembler in /usr/ccs/bin/as work
>>>>> almost as well, though.
>>>
>>>
>>> "almost as well"?
>>> Maybe that should say more, like, use -g or -gstabs instead of -
>>> gstabs+, don't use 64bit+pic+unwind-tables or 64bit+pic+exceptions
>>>
>>>
>>> I switched to Sun assembler because I'm seeing GNU as installed in
>>> different places on different machines.
>>> Some people don't install /usr/sfw and the install elsewhere.
>>>
>>>
>>> - Jay
-disable-fixincludes doesn't quite work, minor
-disable-libgcc and/or -disable-fixincludes are useful, depending on your goal. Like if you just want to compile C to assembly or object files. It fails, but only after doing what I want anyway. make[2]: *** No rule to make target `../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh', needed by `stmp-fixinc'. Stop. gmake[2]: Leaving directory `/home/jkrell/obj/gcc.sparc/gcc' gmake[1]: *** [all-gcc] Error 2 Definitely not a big deal. $HOME/src/gcc-4.5.0/configure -without-gnu-ld -with-ld=/usr/ccs/bin/ld -without-gnu-as -with-as=/usr/ccs/bin/as -disable-nls -disable-fixincludes -verbose -disable-libgcc -disable-bootstrap gmake (I'd still like -disable-intl; I always just delete that directory. -disable-intl /might/ work, I should try it again. I'd also like -without-libiconv, which I'm sure doesn't work. This way the resulting gcc doesn't require libiconv, which isn't on all systems. I have automation to patch out the libiconv use.) - Jay
RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction
It might also be necessary to configure for i586-sun-solaris2.10 instead of
i586-solaris2.10.
Something I read said you can use various shorter forms, and I like the idea
for convenience and to avoid those "pc"s and "unknown"s,
but this seems to have bitten me a number of times, not just today.
Anyway, it is working for me, configure -without-gnu-as i586-sun-solaris2.10,
having applied Rainer's change to a 4.3 tree.
(Yes, I'd like to upgrade.)
It seems using GNU as might still be slightly preferred in order to move data
(jump tables) out of .text and into read only data, like, you know, "the less
that is executable, the more secure". Though for locality, .text might be
better.
For now I'm erring toward using what is more often present in the same location.
I should have just waited till I tested with 4.5, that would have shut me up. :)
Thanks,
- Jay
> From: jay.kr...@cornell.edu
> To: pins...@gmail.com
> CC: gcc@gcc.gnu.org
> Subject: RE: pic+64bit+sun assembler+unwind-tables => illegal cross section
> subtraction
> Date: Mon, 10 May 2010 03:17:40 +
>
>
> Fix in 4.4.0.
>
> I was getting:
>
> .LASFDE1:
> .long .LASFDE1-.Lframe1
> .long .LFB2-. <<<
> .long .LFE2-.LFB2
>
> 4.5.0 configured right:
>
> .LASFDE1:
> .long .LASFDE1-.Lframe1
> .long .l...@rel <<<
> .long .LFE0-.LFB0
>
> dw2_asm_output_encoded_addr_rtx =>
>
> #ifdef ASM_OUTPUT_DWARF_PCREL
> ASM_OUTPUT_DWARF_PCREL (asm_out_file, size, XSTR (addr, 0));
> #else
> dw2_assemble_integer (size, gen_rtx_MINUS (Pmode, addr, pc_rtx));
> #endif
>
>
> C:\src\gcc-4.4.0\gcc\config\i386\sol2-10.h(45):#define
> ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
> C:\src\gcc-4.5.0\gcc\config\i386\sol2-10.h(46):#define
> ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
>
>
> #define ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
> do { \
> fputs (integer_asm_op (SIZE, FALSE), FILE); \
> assemble_name (FILE, LABEL); \
> fputs (SIZE == 8 ? "@rel64" : "@rel", FILE); \
> } while (0)
> #endif
>
> 2009-01-29 Rainer Orth
> * config/i386/sol2-10.h [!HAVE_AS_IX86_DIFF_SECT_DELTA]
> (ASM_OUTPUT_DWARF_PCREL): Define.
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=143758
>
>
> Thanks,
> - Jay
>
>
>
>> From: jay.kr...@cornell.edu
>> To: pins...@gmail.com
>> CC: gcc@gcc.gnu.org
>> Subject: RE: pic+64bit+sun assembler+unwind-tables => illegal cross section
>> subtraction
>> Date: Mon, 10 May 2010 01:02:29 +
>>
>>
>> Ah, good point. I don't think my "real" scenario did that though.
>> I'll investigate more. Networking problems were?are hampering download 4.5.0
>> and
>> build and configure it.
>>
>> I did come up with Makefile:
>>
>> Assemble = $(shell if test -x /opt/csw/gnu/as ; then echo /opt/csw/gnu/as ; \
>> elif test -x /usr/sfw/bin/gas ; then echo /usr/sfw/bin/gas ; \
>> else echo "unable to find GNU assembler" ; fi )
>>
>> :) which addresses why I wasn't using GNU as.
>>
>> (Yes, I've heard of autoconf.)
>>
>> Thanks, later,
>> - Jay
>>
>>
>>
>>> From: pins...@gmail.com
>>> To: jay.kr...@cornell.edu
>>> Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section
>>> subtraction
>>> Date: Sun, 9 May 2010 17:48:04 -0700
>>> CC: gcc@gcc.gnu.org
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On May 9, 2010, at 5:42 PM, Jay K wrote:
>>>
>>>>
>>>> I haven't tried 4.5.0 yet.
>>>>
>>>>
>>>> -bash-4.1$ /opt/csw/gcc4/bin/g++ -v
>>>> Using built-in specs.
>>>> Target: i386-pc-solaris2.10
>>>> Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --
>>>> exec-prefix=/op
>>>> t/csw/gcc4
>>>
>>>
>>>
>>>> --with-gnu-as
>>>
>>>
>>> You configured gcc to build with the gnu as but then run with it so
>>> what do you expect.
>>>
>>>
>>>> --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
>>>> usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-
>>>> prefix=/opt/
>>>> csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-
>>>> awt=xlib --e
>>>> nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix
>&
RE: -disable-fixincludes doesn't quite work, minor
Ok if I do both or the emails are just annoying? I find that bugs are often ignored just as well (but not lost/forgotten, granted. :) ) Thanks, - Jay > To: jay.kr...@cornell.edu > CC: gcc@gcc.gnu.org > Subject: Re: -disable-fixincludes doesn't quite work, minor > From: i...@google.com > Date: Mon, 10 May 2010 09:50:01 -0700 > > Jay K writes: > >> -disable-libgcc and/or -disable-fixincludes are useful, depending on your >> goal. >> >> Like if you just want to compile C to assembly or object files. >> >> >> It fails, but only after doing what I want anyway. >> >> make[2]: *** No rule to make target >> `../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh', needed by >> `stmp-fixinc'. Stop. >> gmake[2]: Leaving directory `/home/jkrell/obj/gcc.sparc/gcc' >> gmake[1]: *** [all-gcc] Error 2 > > > Thanks for pointing these things out. However, I hope you are filing > bug reports about these issues you are raising. Problems which are > only reported to the mailing list will be reliably lost and forgotten. > If you want them to be fixed, please open bug reports. Thanks. > > Ian
rep prefix doesn't work with Solaris 2.9 Sun assembler
Solaris 2.9 x86 gcc 4.5.0 configure -without-gnu-as -with-as=/usr/ccs/bin/as
=> Assembly syntax errors in gcov.c whereever there is rep prefix.
I was actually looking for a problem with lock prefixes on 4.3 -- testing
4.5.0, found this instead, which is about about the same.
See:
http://gcc.gnu.org/viewcvs?view=revision&revision=127728
for handling of the lock prefix in a separate instruction.
See:
http://developers.sun.com/sunstudio/downloads/ssx/express_Feb2008_readme.html
"You can now place lock/rep/repnz/repz/repe/repne prefix on the same line as
the following instruction."
But I'd like to stay compatible with the existing Sun assembler
at /usr/ccs/bin/as.
I considered just changing them all to \;, like there is rep\;ret, but
I noticed this:
sync.md: "lock{%;| }or{l}\t{$0, (%%esp)|DWORD PTR [esp], 0}"
which appears to be an attempt to output Microsoft/Intel assembly, so I went
with the space usually and ; only for Darwin/Solaris, like how sync.md
was already using ; for Darwin.
Proposed patch below/attached.
(-w to hide indent change)
I'll open a bug. And test it on some machines maybe.
Any marked with TARGET_64BIT I left alone. Maybe that is too inconsistent
though.
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c ./i386.c
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.c Wed Apr 7 23:58:27
2010
+++ ./i386.c Tue May 11 10:01:54 2010
@@ -11896,11 +11896,10 @@
return;
case ';':
-#if TARGET_MACHO
+ if (TARGET_MACHO || TARGET_SOLARIS)
fputs (" ; ", file);
-#else
+ else
putc (' ', file);
-#endif
return;
default:
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.h ./i386.h
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.h Wed Mar 24 21:44:48
2010
+++ ./i386.h Tue May 11 09:59:01 2010
@@ -467,6 +467,9 @@
redefines this to 1. */
#define TARGET_MACHO 0
+/* Like TARGET_MACHO, redefined in sol2.h. */
+#define TARGET_SOLARIS 0
+
/* Likewise, for the Windows 64-bit ABI. */
#define TARGET_64BIT_MS_ABI (TARGET_64BIT && ix86_cfun_abi () == MS_ABI)
diff -uw /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.md ./i386.md
--- /home/jkrell/src/orig/gcc-4.5.0/gcc/config/i386/i386.md Wed Mar 24 19:49:49
2010
+++ ./i386.md Tue May 11 09:49:05 2010
@@ -13811,7 +13811,7 @@
[(return)
(unspec [(const_int 0)] UNSPEC_REP)]
"reload_completed"
- "rep\;ret"
+ "rep{%;| }ret"
[(set_attr "length" "2")
(set_attr "atom_unit" "jeu")
(set_attr "length_immediate" "0")
@@ -17772,7 +17772,7 @@
(mem:BLK (match_dup 4)))
(use (match_dup 5))]
"!TARGET_64BIT"
- "rep movs{l|d}"
+ "rep{%;| }movs{l|d}"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "both")
@@ -17808,7 +17808,7 @@
(mem:BLK (match_dup 4)))
(use (match_dup 5))]
"!TARGET_64BIT"
- "rep movsb"
+ "rep{%;| }movsb"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "both")
@@ -18023,7 +18023,7 @@
(use (match_operand:SI 2 "register_operand" "a"))
(use (match_dup 4))]
"!TARGET_64BIT"
- "rep stos{l|d}"
+ "rep{%;| }stos{l|d}"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "store")
@@ -18056,7 +18056,7 @@
(use (match_operand:QI 2 "register_operand" "a"))
(use (match_dup 4))]
"!TARGET_64BIT"
- "rep stosb"
+ "rep{%;| }stosb"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "store")
@@ -18188,7 +18188,7 @@
(clobber (match_operand:SI 1 "register_operand" "=D"))
(clobber (match_operand:SI 2 "register_operand" "=c"))]
"!TARGET_64BIT"
- "repz cmpsb"
+ "repz{%;| }cmpsb"
[(set_attr "type" "str")
(set_attr "mode" "QI")
(set_attr "prefix_rep" "1")])
@@ -18239,7 +18239,7 @@
(clobber (match_operand:SI 1 "register_operand" "=D"))
(clobber (match_operand:SI 2 "register_operand" "=c"))]
"!TARGET_64BIT"
- "repz cmpsb"
+ "repz{%;| }cmpsb"
[(set_attr "type" "str")
(set_attr "mode" "QI")
(set_attr "prefix_rep" "1")])
@@ -18305,7 +18305,7 @@
(clobber (match_operand:SI 1 "register_operand&qu
RE: rep prefix doesn't work with Solaris 2.9 Sun assembler
Understood, but I'll have to stick to "small" changes as I can't get the papers.
Uros pointed to:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00657.html
which appears to just be *very* coincident timing.
So I Rainer will fix it soon.
I have a patch now based on that discussion.
I used:
case ';':
if ((TARGET_MACHO || TARGET_SOLARIS) && ASSEMBLER_DIALECT == ASM_ATT)
fputs (" ; ", file);
else
fputc (' ', file);
return;
though even better might be to assume 64bit implies more recent assembler:
case ';':
if ((TARGET_MACHO || TARGET_SOLARIS) && ASSEMBLER_DIALECT == ASM_ATT &&
!TARGET_64BIT)
fputs (" ; ", file);
else
fputc (' ', file);
return;
I guess there was an obscure bug where -masm=intel didn't work for Darwin
targets?.
What, people use -masm=intel and masm/nasm/yasm instead of gas? Or just to
human read the output?
Thanks,
- Jay
> From: ebotca...@adacore.com
> To: jay.kr...@cornell.edu
> Subject: Re: rep prefix doesn't work with Solaris 2.9 Sun assembler
> Date: Tue, 11 May 2010 10:35:12 +0200
> CC: gcc@gcc.gnu.org
>
>> Proposed patch below/attached.
>> (-w to hide indent change)
>
> See http://gcc.gnu.org/contribute.html for guidelines.
>
>> I'll open a bug.
>
> See http://gcc.gnu.org/bugs for guidelines.
>
> Generally speaking, posting a patch inlined in a message on gcc@gcc.gnu.org
> will most likely result in it being lost and forgotten. In order to report
> an issue, please open a ticket with bugzilla. In order to submit a patch,
> please use gcc-patc...@gcc.gnu.org. In both cases, follow the guidelines
> written down in the aforementioned documentation. Thanks in advance.
>
> --
> Eric Botcazou
FW: [Bug c/44166] New: -fvisibility=protected doesn't work?
> Date: Mon, 17 May 2010 13:41:57 +
> Subject: [Bug c/44166] New: -fvisibility=protected doesn't work?
> To: jay.kr...@cornell.edu
> From: gcc-bugzi...@gcc.gnu.org
>
> -fvisibility=protected doesn't work?
>
> a...@xlin2:~$ cat 1.c
> void F1() { }
> void* F2() { return F1; }
>
> j...@xlin2:~$ $HOME/bin/gcc 1.c -fPIC -shared -fvisibility=protected
>
> /usr/bin/ld: /tmp/cc0d6EQ3.o: relocation R_386_GOTOFF against protected
> function `F1' can not be used when making a shared object
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
>
> j...@xlin2:~$ $HOME/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/home/jay/bin/gcc
> COLLECT_LTO_WRAPPER=/home/jay/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
> Target: i686-pc-linux-gnu
> Configured with: /src/gcc-4.5.0/configure -verbose -prefix=/home/jay
> -disable-bootstrap -disable-multilibs
> Thread model: posix
> gcc version 4.5.0 (GCC)
>
>
> --
> Summary: -fvisibility=protected doesn't work?
> Product: gcc
> Version: 4.5.0
> Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: c
> AssignedTo: unassigned at gcc dot gnu dot org
> ReportedBy: jay dot krell at cornell dot edu
> GCC build triplet: i686-pc-linux-gnu
> GCC host triplet: i686-pc-linux-gnu
> GCC target triplet: i686-pc-linux-gnu
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44166
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
alpha-dec-osf5.1 4.5 built/installed
per http://gcc.gnu.org/install/finalinstall.html Built/installed 4.5 on alpha-dec-osf. alphaev67-dec-osf5.1 bash-4.1$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper Target: alphaev67-dec-osf5.1 Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls -prefix=/home/jayk Thread model: posix gcc version 4.5.0 (GCC) C and C++ Though I meant to let it do "all". This isn't a "normal modern" 5.1, like 5.1a or 5.1b, but is old 5.1 rev 732. Not easy to get the prerequisites for running tests: http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00967.html More followup still to do. and I only ran make check in the gcc directory, to skip gmp/mpfr/mpc. - Jay
ARM FLOOR_MOD_EXPR?
Do FLOOR_DIV_EXPR and FLOOR_MOD_EXPR work on ARM, for 64bit signed integer? I have a front end (sort of), using gcc 4.3, generates trees, doesn't work. type_for_mode(TImode) is NULL and that is dereferenced. I realize TRUNC_* would be far more "normal", but I can't change that. I guess I'll just go back to generating function calls. - Jay
RE: ARM FLOOR_MOD_EXPR?
in calls.c: tfom = lang_hooks.types.type_for_mode (outmode, 0); if (aggregate_value_p (tfom, 0)) for 64bit mod, outmode ends up TImode. Our frontend doesn't support TImode -- reasonable? -- and so type_for_mode returns NULL here. aggregate_value_p then derefences that NULL. At least that's what happens in 4.3. I tried hacking the C frontend to interpret % as FLOOR instead of TRUNC. It works though -- the C frontend supports TImode. Seems a little bit odd to depend on that? - Jay > From: jay.kr...@cornell.edu > To: gcc@gcc.gnu.org > Subject: ARM FLOOR_MOD_EXPR? > Date: Sat, 19 Jun 2010 08:17:16 + > > > Do FLOOR_DIV_EXPR and FLOOR_MOD_EXPR work on ARM, for 64bit signed integer? > I have a front end (sort of), using gcc 4.3, generates trees, doesn't work. >type_for_mode(TImode) is NULL and that is dereferenced. > I realize TRUNC_* would be far more "normal", but I can't change that. > I guess I'll just go back to generating function calls. > > - Jay >
suggest assert wide_int larger than hashval_t
I get this in 4.3.5:
../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
./include/hashtab.h:typedef unsigned int hashval_t;
unsigned HOST_WIDE_INT hwi;
hashval_t h, *hp;
...
const int shift = sizeof (hashval_t) * CHAR_BIT;
const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
int i;
h ^= (hashval_t) hwi;
for (i = 1; i < n; ++i)
{
hwi >>= shift; here
It looks about the same in 4.5.0 except without const:
int shift = (sizeof (hashval_t) * CHAR_BIT);
Something is amiss here locally, for the types to be the same size.
But maybe add gcc_assert(sizeof(hashval_t) < sizeof(HOST_WIDE_INT),
outside the loop? It should be optimized away anyway.
Maybe I'd get -Werror but I use -disable-bootstrap.
Native compiler is gcc, but old.
Thanks,
- Jay
RE: suggest assert wide_int larger than hashval_t (32bit hwint?)
Hm, it seems on some 32bit systems, where there is no -m64, wideint can be a
mere 32bits.
In which case the code should probably say:
hwi = ((hwi >> (shift - 1)) >> 1);
This was targeting OpenBSD/x86.
Maybe I should just stick need_64bit_hwint = yes on config.gcc for that and
move along?
Assume there is always long long or __int64?
Coverage of this case is pretty rare now from my skimming.
- Jay
> From: jay.kr...@cornell.edu
> To: gcc@gcc.gnu.org
> Subject: suggest assert wide_int larger than hashval_t
> Date: Mon, 19 Jul 2010 06:44:33 +
>
>
> I get this in 4.3.5:
>
> ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
> ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
>
> ./include/hashtab.h:typedef unsigned int hashval_t;
>
> unsigned HOST_WIDE_INT hwi;
> hashval_t h, *hp;
> ...
> const int shift = sizeof (hashval_t) * CHAR_BIT;
> const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
> int i;
>
> h ^= (hashval_t) hwi;
> for (i = 1; i < n; ++i)
> {
> hwi >>= shift; here
>
>
> It looks about the same in 4.5.0 except without const:
>
>
> int shift = (sizeof (hashval_t) * CHAR_BIT);
>
>
> Something is amiss here locally, for the types to be the same size.
>
>
> But maybe add gcc_assert(sizeof(hashval_t) < sizeof(HOST_WIDE_INT),
> outside the loop? It should be optimized away anyway.
>
>
> Maybe I'd get -Werror but I use -disable-bootstrap.
> Native compiler is gcc, but old.
>
>
> Thanks,
> - Jay
>
>
RE: suggest assert wide_int larger than hashval_t
It's "just" a warning, no "real" affects seen.
I patched my copy to say
hwi = ((hwi >> (shift - 1)) >> 1);
Thanks,
- Jay
> From: i...@google.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
> Subject: Re: suggest assert wide_int larger than hashval_t
> Date: Mon, 19 Jul 2010 00:36:06 -0700
>
> Jay K writes:
>
> > I get this in 4.3.5:
> >
> > ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
> > ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
> >
> > ./include/hashtab.h:typedef unsigned int hashval_t;
> >
> > unsigned HOST_WIDE_INT hwi;
> > hashval_t h, *hp;
> > ...
> > const int shift = sizeof (hashval_t) * CHAR_BIT;
> > const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
> > int i;
> >
> > h ^= (hashval_t) hwi;
> > for (i = 1; i < n; ++i)
> > {
> > hwi >>= shift; here
>
> It's not an actual problem, because the code is never executed in the
> case where right shift count >= width of type. Note that the loop
> starts at 1. If this is breaking bootstrap that it needs to be
> addressed one way or another, otherwise it's not too serious.
>
> Ian
http://gcc.gnu.org/install/specific.html maybe should mention memory settings for OpenBSD
Possibly a note for: http://gcc.gnu.org/install/specific.html under OpenBSD. or just for the mail archives: Building a *slight* fork of 4.5.1 on OpenBSD/x86 4.7 I hit gcc -c -g -O2 -static -DIN_GCC -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute \ -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc -I../../gcc-4.5/gcc/. \ -I../../gcc-4.5/gcc/../include -I../../gcc-4.5/gcc/../libcpp/include \ -I/home/jay/dev2/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp \ -I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/gmp \ -I/home/jay/dev2/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr \ -I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/mpfr \ -I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/mpc/src \ -I../../gcc-4.5/gcc/../libdecnumber \ -I../../gcc-4.5/gcc/../libdecnumber/dpd -I../libdecnumber \ -I/usr/local/include insn-attrtab.c -o insn-attrtab.o cc1: out of memory allocating 304988696 bytes after a total of 0 bytes gmake: *** [insn-attrtab.o] Error 1 This was not a problem with 4.3.0 or 4.3.5. I don't know about 4.4.x. We skipped them, just because we are slow and lagging. I couldn't get ulimit to do anything as non-root. I do have swap. I changed these from 512 to 768, probably not all of them necessary: # pwd /etc # grep 768 login.conf :datasize-max=768M:\ :datasize-cur=768M:\ :datasize-cur=768M:\ and then I can proceed. System probably doesn't have much RAM, maybe only 512MB, so that could be where the previous values came from. I had never touched them. Smaller amounts of RAM seem "more normal" these days to pack more virtual machines onto one physical system. (Though this just an old laptop, not a virtual machine.) - Jay
internal compiler error: in referenced_var_lookup, at tree-dfa.c
So..we have a custom frontend.
That uses process boundaries to avoid GPL crossing into BSDish licensed code.
So maybe you don't want to help me. Understood.
But just in case:
We generate trees. Probably they aren't of great quality.
e.g. relatively devoid of types and do field accesses by offseting pointers and
casting.
We do our own layout earlier. Not great, but that's how it is.
Currently we use gcc 4.5.1.
When I enable inlining on some architectures, e.g. Macosx/x86, much code yields:
../FPrint.m3: In function 'FPrint__xCombine':
../FPrint.m3:25:0: internal compiler error: in referenced_var_lookup, at
tree-dfa.c:525
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Now I've spent a while debugging this. I'm not completely lazy.
The original source (again, not a standard frontend):
PROCEDURE xCombine (): INTEGER =
BEGIN
RETURN xFix32 (0);
END xCombine;
PROCEDURE xFix32 (x: INTEGER): INTEGER =
CONST a = 1;
BEGIN
IF Word.And (x, a) = 0 THEN
RETURN 0;
END;
RETURN 0;
END xFix32;
-fdump-tree-all, 003t.original:
FPrint__xCombine ()
{
int_32 D.985;
int_32 M3_AcxOUs__result;
int_32 M3_AcxOUs__result;
int_32 D.985;
D.985 = FPrint__xFix32 (0);
= D.985;
return ;
}
FPrint__xFix32 (int_32 M3_AcxOUs_x)
{
int_32 M3_AcxOUs__result;
int_32 M3_AcxOUs__result;
if ((M3_AcxOUs_x & 1) != 0)
{
goto ;
}
= 0;
return ;
:;
= 0;
return ;
}
040t.release_ssa:
;; Function FPrint__xFix32 (FPrint__xFix32)
Released 0 names, 0.00%
FPrint__xFix32 (int_32 M3_AcxOUs_x)
{
int_32 D.987;
:
D.987_3 = M3_AcxOUs_x_2(D) & 1;
if (D.987_3 != 0)
goto ();
else
goto ;
:
_4 = 0;
goto ;
:
_5 = 0;
:
# _1 = PHI <_4(3), _5(4)>
return _1;
}
Breakpoint 1, 0x0078f21a in copy_phis_for_bb (bb=0x4126a280, id=0xb5d8) at
../../gcc-4.5/gcc/tree-inline.c:1937
1937 {
(gdb) n
1938 basic_block const new_bb = (basic_block) bb->aux;
(gdb)
1943 jaykrell_check_1(); doesn't do anything now, was helping debug
(gdb)
1945 for (si = gsi_start (phi_nodes (bb)); !gsi_end_p (si); gsi_next (&si))
(gdb)
1947 tree res = { 0 }, new_res = { 0 };
(gdb)
1948 gimple new_phi = { 0 };
(gdb)
1949 edge new_edge = { 0 };
(gdb)
1951 phi = gsi_stmt (si);
(gdb)
1952 res = PHI_RESULT (phi);
(gdb)
1953 new_res = res;
(gdb)
1954 if (is_gimple_reg (res))
(gdb)
1956 walk_tree (&new_res, copy_tree_body_r, id, NULL);
(gdb)
1957 new_phi = create_phi_node (new_res, new_bb); This line split up
locally, ok.
(gdb)
1958 SSA_NAME_DEF_STMT (new_res) = new_phi;
(gdb) call debug_referenced_vars()
Referenced variables in FPrint__xCombine: 7
Variable: D.1036, UID D.1036, int_32gimple_default_def 0x412130a8 1036
Variable: D.1041, UID D.1041, int_32gimple_default_def 0x412130a8 1041
Variable: .MEM, UID D.1038, , is global, call
clobberedgimple_default_def 0x412130a8 1038
Variable: M3_AcxOUs_x, UID D.1039, int_32gimple_default_def 0x412130a8 1039
Variable: D.1040, UID D.1040, int_32gimple_default_def 0x412130a8 1040
Variable: , UID D.979, int_32gimple_default_def 0x412130a8 979
Variable: D.985, UID D.985, int_32gimple_default_def 0x412130a8 985
(gdb) n
1959 FOR_EACH_EDGE (new_edge, ei, new_bb->preds)
(gdb) call debug_referenced_vars()
Referenced variables in FPrint__xCombine: 7
Variable: D.1036, UID D.1036, int_32gimple_default_def 0x412130a8 1036
Variable: D.1041, UID D.1041, int_32gimple_default_def 0x412130a8 1041
Variable: .MEM, UID D.1038, , is global, call
clobberedgimple_default_def 0x412130a8 1038
Variable: M3_AcxOUs_x, UID D.1039, int_32gimple_default_def 0x412130a8 1039
Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def 0x412130a8
1093058884
Variable: , UID D.979, int_32gimple_default_def 0x412130a8 979
Variable: D.985, UID D.985, int_32gimple_default_def 0x412130a8 985
You can see D.1040 got overwritten with something else.
And then later the assertion is that it is missing.
Is it valid for uids to be so high?
Any clues/tips?
Thanks much,
- Jay
RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
Er, As I understand, lack of a process boundary automatically implies GPL "spread" through "linkage". Assuming "linkage" means "ld". I'm not sure I've seen "linkage" defined. However if "linkage" or "derivation" includes "interaction via file or network I/O", then a lot of folks will be upset, (and some people very pleased :) ) File and network I/O connect all code in the world. A process boundary at least gives you a chance. Some of the work -- the frontend -- is clearly derived, and linked, so it is GPL. > a derived work! You need to consult a knowledgable attorney before > proceeding in this direction. Most of the proceeding in this direction was done >10 years ago by others. Granted, I don't know what legal advise they had. I'm proceeding not much further, e.g. merging to current gcc, making debugging better. At some point I might generate C to fix a number of problems (including this assert and licensing, and debugging, and efficient exception handling, etc.), but that is a different matter. Anyway, I put this out there to give folks a chance to not "like" me and not help me. I'll address the technical part separately. Thanks, - Jay > Date: Fri, 10 Sep 2010 11:17:59 -0400 > From: de...@adacore.com > To: i...@google.com > CC: jay.kr...@cornell.edu; gcc@gcc.gnu.org > Subject: Re: internal compiler error: in referenced_var_lookup, at tree-dfa.c > > On 9/10/2010 11:08 AM, Ian Lance Taylor wrote: > > Jay K writes: > > > >> That uses process boundaries to avoid GPL crossing into BSDish licensed > >> code. > >> So maybe you don't want to help me. Understood. > > > > Note that different people have different opinions as to whether a > > process boundary means that your code is not a derived work. Not that > > we should get into that discussion on this mailing list. > > Indeed, it is important to realize that putting in an arbitrary > process boundary is not guarantee at all that you have not created > a derived work! You need to consult a knowledgable attorney before > proceeding in this direction.
RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
[licensing dealt with separately] > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def > > 0x412130a8 1093058884 > This is clearly wrong, though I have no idea what caused it. > > Is it valid for uids to be so high? > No. Thanks, that helps. > From your description, you've implemented some sort of customized tree > reader. Not exactly, by my understanding of terminology. We do end up making gcc trees but we serialize something that is separately specified and not really the same, though some level of resemblance is unavoidable since they both are involved with compilation, i.e. they both have operations like "add" and notions of locals, parameters, functions, etc. Ours is stack-based though for example (not my preference, but it was already there). > Does it play nicely with the garbage collector? I think so. We have the GTY annotations, I've managed to crash things when I got them wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even have to hack on the code a bit because GTY has to be in a different place. I put the type declarations in seperate .h files, maintain both, and copy one over the other before compilation. We do have an open bug report about causing the gcc garbage collector consuming infinite memory, maybe due to a cycle in our data. But really the system works a ton. I can compile and run tens of thousands of lines of code, for multiple architectures. I "just" have to turn off inlining, and a small number of other optimizations. Clearly we are pretty good, and flawed. Notice that the gcc middle end seemed to have created this variable with the high uid. I checked the globals that guide uid assignment, found them after sending the first mail. They aren't so high. I haven't yet found where this uid comes from. I kind of suspect it might be a type mismatch, overwriting part of a tree node with the wrong type or such. I'll have to dig more. I know it comes from here: copy_phis_for_bb: ... SSA_NAME_DEF_STMT (new_res) = new_phi = create_phi_node (new_res, new_bb); Thanks, - Jay
RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
> I kind of suspect it might be a type mismatch, overwriting part of a tree node configure -enable-checking: ?"Bmr?: In function 'FPrint__xCombine': `?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have var_decl in copy_phis_for_bb, at tree-inline.c:1950 and some other problems..I really need to fix those... - Jay > From: jay.kr...@cornell.edu > To: i...@google.com > CC: gcc@gcc.gnu.org > Subject: RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c > Date: Fri, 10 Sep 2010 20:38:58 + > > > [licensing dealt with separately] > > > > > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def > > > 0x412130a8 1093058884 > > This is clearly wrong, though I have no idea what caused it. > > > Is it valid for uids to be so high? > > No. > > Thanks, that helps. > > > > From your description, you've implemented some sort of customized tree > > reader. > > > Not exactly, by my understanding of terminology. > We do end up making gcc trees but we serialize something that is separately > specified and not really the same, though some level of resemblance is > unavoidable since they both are involved with compilation, i.e. they both > have operations like "add" and notions of locals, parameters, functions, etc. > Ours is stack-based though for example (not my preference, but it was already > there). > > > > Does it play nicely with the garbage collector? > > > I think so. > We have the GTY annotations, I've managed to crash things when I got them > wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even have > to hack on the code a bit because GTY has to be in a different place. > I put the type declarations in seperate .h files, maintain both, and copy one > over the other before compilation. > > > We do have an open bug report about causing the gcc garbage collector > consuming infinite memory, maybe due to a cycle in our data. > But really the system works a ton. I can compile and run tens of thousands of > lines > of code, for multiple architectures. I "just" have to turn off inlining, and > a small number of other optimizations. Clearly we are pretty good, and flawed. > > > Notice that the gcc middle end seemed to have created this variable with the > high uid. > I checked the globals that guide uid assignment, found them after sending the > first mail. They aren't so high. > I haven't yet found where this uid comes from. > I kind of suspect it might be a type mismatch, overwriting part of a tree node > with the wrong type or such. > I'll have to dig more. > > I know it comes from here: > copy_phis_for_bb: > ... > SSA_NAME_DEF_STMT (new_res) > = new_phi = create_phi_node (new_res, new_bb); > > > > Thanks, > - Jay >
RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
arg..well, I had replaced xmalloc with alloca, leading to some of the garbage
below, but
I am indeed still running afoul of the garbage collector.
I don't know if that is my original problem but I should probably fix this
first.
ie: now that I'm using -enable-checking, and I think it collects earlier/more
often.
I need to "map" my internal unsigned long arbitrary integers, to trees.
So I just have an array of struct {unsigned id; tree t };
I put GTY on the struct, on the field, and on the VEC of them.
When I append I mark it dirty.
When I search I qsort if dirty, then bsearch.
typedef struct GTY(()) m3type_t
{
unsigned long id;
tree GTY (()) t;
} m3type_t;
static GTY (()) VEC (m3type_t,gc)* m3type_table;
seems reasonable eh?
The files are in gtfiles. When I put the GTY in the wrong place I get compile
errors.
I guess I can try rolling my own "VEC" or even use a fixed size and see what
happens..
Thanks,
- Jay
> From: jay.kr...@cornell.edu
> To: i...@google.com
> CC: gcc@gcc.gnu.org
> Subject: RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
> Date: Sat, 11 Sep 2010 08:48:08 +
>
>
> > I kind of suspect it might be a type mismatch, overwriting part of a tree
> > node
>
> configure -enable-checking:
>
> ?"Bmr?: In function 'FPrint__xCombine':
> `?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have
> var_decl in copy_phis_for_bb, at tree-inline.c:1950
>
> and some other problems..I really need to fix those...
>
> - Jay
>
>
> > From: jay.kr...@cornell.edu
> > To: i...@google.com
> > CC: gcc@gcc.gnu.org
> > Subject: RE: internal compiler error: in referenced_var_lookup, at
> > tree-dfa.c
> > Date: Fri, 10 Sep 2010 20:38:58 +
> >
> >
> > [licensing dealt with separately]
> >
> >
> >
> > > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def
> > > > 0x412130a8 1093058884
> > > This is clearly wrong, though I have no idea what caused it.
> > > > Is it valid for uids to be so high?
> > > No.
> >
> > Thanks, that helps.
> >
> >
> > > From your description, you've implemented some sort of customized tree
> > > reader.
> >
> >
> > Not exactly, by my understanding of terminology.
> > We do end up making gcc trees but we serialize something that is separately
> > specified and not really the same, though some level of resemblance is
> > unavoidable since they both are involved with compilation, i.e. they both
> > have operations like "add" and notions of locals, parameters, functions,
> > etc.
> > Ours is stack-based though for example (not my preference, but it was
> > already there).
> >
> >
> > > Does it play nicely with the garbage collector?
> >
> >
> > I think so.
> > We have the GTY annotations, I've managed to crash things when I got them
> > wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even
> > have
> > to hack on the code a bit because GTY has to be in a different place.
> > I put the type declarations in seperate .h files, maintain both, and copy
> > one
> > over the other before compilation.
> >
> >
> > We do have an open bug report about causing the gcc garbage collector
> > consuming infinite memory, maybe due to a cycle in our data.
> > But really the system works a ton. I can compile and run tens of thousands
> > of lines
> > of code, for multiple architectures. I "just" have to turn off inlining, and
> > a small number of other optimizations. Clearly we are pretty good, and
> > flawed.
> >
> >
> > Notice that the gcc middle end seemed to have created this variable with
> > the high uid.
> > I checked the globals that guide uid assignment, found them after sending
> > the
> > first mail. They aren't so high.
> > I haven't yet found where this uid comes from.
> > I kind of suspect it might be a type mismatch, overwriting part of a tree
> > node
> > with the wrong type or such.
> > I'll have to dig more.
> >
> > I know it comes from here:
> > copy_phis_for_bb:
> > ...
> > SSA_NAME_DEF_STMT (new_res)
> > = new_phi = create_phi_node (new_res, new_bb);
> >
> >
> >
> > Thanks,
> > - Jay
> >
>
RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
I have it seemingly working now, much better, thanks for the nudges -- that
indeed high id is invalid, and to look again at my GTY use.
I don't know if it made the difference but I changed some whitespace to match
others, and
typedef struct foo_t { ... } foo_t;
to
typedef struct foo { ... } foo_t; without the _t on the struct tag.
- Jay
...snip...
eliminating mpc/mpfr and reducing gmp
Hi. You know, gmp/mpfr/mpc are a significant portion of building any frontend/backend. So I looked at it. mpc of course is only for complex numbers. Our frontend doesn't use them. Maybe only for "builtins" as well. #define do_mpc_arg1(a, b, c) NULL_TREE and such. mpfr appears to be used for floating point builtins. Not for floating point constant folding as I'd thought? We generate very few builtins, just memcmp, memset, memmove, memcpy, and *sync*. Either way, floating point doesn't matter to me much. #define do_mpfr_arg1(a,b,c) NULL_TREE and such. including something_logarithm, something_exponent. And #if out the version report in toplev.c. And the then unused conversions in real.c. and the #include in real.h. and then mpfr isn't needed. That is: changes to gcc to eliminate mpc and mpfr dependencies are pretty darn small. I used #if 1/#if 0, but it'd be easy enough to have configure -without-mpc -without-mpfr. I was able to do this for 4.5, and then 4.3 was trivial, the same except no mpc. And then, if you dig a bit more, you find that gmp contains "n", "q" (rational), "z", "f" (float), and miscellaneous e.g. *rand*. (apples and oranges: *rand* must operate on some mp type, of course) None of "q" and "f" are needed, and vast swaths of "n" and "z" are unused and can be deleted. Easier to truncate the files first when experimenting. Probably can do even better. There is a file in GMP dumbmp.c (as in dump, stupid) that contains a simple portable subset of GMP, used for some "generator" programs. First glance says it isn't sufficient, but it might be close.. The result is a lot faster to build, if you are just doing a just a single stage build of a compiler. To some extent it adds up -- multiple stages. To some extent it is is minor -- if you are building libstdc++/libada/libjava x multilibs. I build just a frontend/backend though. I understand you can also build/install the libraries once. That isn't a terrible option. I have operated that away. But does have drawbacks. It is harder for Canadian cross and "cross back" (cross build a native compiler), which admittedly, I don't do much. There were problems last I tried, esp. with enable-shared and fixincludes, and it always a pain to get the C runtime headers/libraries. The first I opened bugs for. The second can't really be fixed, except e.g. with an integrated tree with glibc/newlib. Maybe some people have scripts out there to scp the appropriate files. I end up taking way more than necessary and sometimes hunting around for what I missed. and gmp doesn't build with default gcc 4.0 on Intel MacOSX 10.5. Building within the gcc tree is one workaround, because how it fiddles with CFLAGS and seemingly accidentally avoids the problems with "inline". Granted, CC=gcc-4.2 is another easy one. Other options. Anyway. - Jay
RE: eliminating mpc/mpfr and reducing gmp
Wow that is fast. My fastest machine, and I have several slower: gmp time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" real 2m2.594s mpfr time sh -c "./configure -disable-shared -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" real 0m43.756s mpc time sh -c "./configure -disable-shared -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" real 0m15.495s which is still a significant fraction of building cc1 (I don't have that time sorry) I used to use Cygwin. Things add up much faster there. > mpfr et al. If you're not, it only happens once. Almost anything long but incremental can be justified via incrementality. But there is also, occasionally, mass bouts of trying to get the configure switches just right and starting over repeatedly...at least me being unsure of incrementality in the fact of rerunning configure... Anyway, just putting it out there, probably won't happen, but configure -without-mpc -without-mpfr might be nice and aren't difficult, -without-gmp much better, but I can't yet claim it isn't difficult. Maybe, something like, if gmp is "in tree", after configure, the Makefile could be hacked down to omit mpf, mpq, and lots others, but then the linkage between gcc and gmp gets messy. i.e. as gmp changes. - Jay > Date: Mon, 27 Sep 2010 11:37:04 +0100 > From: a...@redhat.com > To: jay.kr...@cornell.edu > CC: gcc@gcc.gnu.org > Subject: Re: eliminating mpc/mpfr and reducing gmp > > On 09/27/2010 01:23 AM, Jay K wrote: > > > > Hi. You know, gmp/mpfr/mpc are a significant > > portion of building any frontend/backend. > > I disagree. Most of the time I don't notice them. > > > The result is a lot faster to build, if you are just doing a just > > a single stage build of a compiler. > > Sure, but if you're working on the compiler you don't need to rebuild > mpfr et al. If you're not, it only happens once. > > On my box, for mpc: > > real 0m2.624s > user 0m3.336s > sys 0m1.663s > > and for mpfr: > > real 0m4.484s > user 0m12.006s > sys 0m5.127s > > Andrew.
RE: eliminating mpc/mpfr and reducing gmp
I only do one language, no driver, one stage, no libraries (none of libgcc, libstdc++, libjava, libada, etc.), no fixincludes (the headers are probably fine, and aren't used by this frontend anyway), the bootstrap compiler is always pretty decent, thus one stage (or I'll "cheat" and do one full regular bootstrap+install of a recent release on the occasional oddball host). It takes under 10 minutes on year old MacBook. (sorry, I didn't measure). I guess it is very unusual, but it is also actually very useful. Everyone else probably depends on good incrementality when actively changing stuff, or pays a higher price overall when occasionally building the entire thing clean and not changing stuff, so this is minor. We understand each other, fair enough. - Jay > Date: Tue, 28 Sep 2010 01:51:31 +0100 > From: dave.korn.cyg...@gmail.com > To: jay.kr...@cornell.edu > CC: a...@redhat.com; gcc@gcc.gnu.org > Subject: Re: eliminating mpc/mpfr and reducing gmp > > On 27/09/2010 12:39, Jay K wrote: > > > gmp > > time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared > > -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\"" > > real 2m2.594s > > > > mpfr > > time sh -c "./configure -disable-shared -enable-static && make && ssh > > r...@localhost \"cd `pwd` && make install\"" > > real 0m43.756s > > > > mpc > > time sh -c "./configure -disable-shared -enable-static && make && ssh > > r...@localhost \"cd `pwd` && make install\"" > > real 0m15.495s > > > > which is still a significant fraction of building cc1 (I don't have that > > time sorry) > > > Huh, am I doing something seriously wrong? It takes me four hours to > boostrap GCC at with all languages enabled at -j8 on an AMD2x64; I'm not too > concerned about 3 minutes per pass! > > cheers, > DaveK >
RE: eliminating mpc/mpfr and reducing gmp
> Well, the other thing is: why not just build them once and install them to > your $prefix? There's no need to build them in-tree every time if you have > sufficiently up-to-date versions installed. > > cheers, > DaveK I have a CVS tree, used by others, that builds a frontend. "Others" are a few people and a few automated build machines (using Hudson), with various operating systems (Linux, Solaris, Darwin, FreeBSD, etc.). The requirements on these machines isn't of course zero -- they exist, they are up and running -- but is kept low where possible. So the decision was made, not exactly by me, but I went along, to add gmp+mpfr to the tree, and later mpc. It's pretty simple, reliable, works. What I was often doing was deleting gmp/mpfr in my local CVS tree, leaving configure to find them in /usr/local. And then sometimes I'd accidentally restore them with cvs upd -dAP. I toyed with the idea of having it always check /usr/local first but didn't do that. What if user has an insufficient version there? I'd have to test for that and fallback to in-tree. Since we are using Hudson we could probably add nice automation, to build gmp/mpfr/mpc "somewhere", neither /usr/local, nor "in gcc", maybe install to $HOME/hudson, and point the frontend build at them. But the Hudson stuff...is not well known to me, I'd kind of rather leave it alone. And I'd have to e.g. deal with the gmp inline problem, just another small detail... I'm satisfied so far with the pruning. I can see it isn't for everyone. We'll see, maybe I'll grow to dislike it as well. - Jay
atomicity of x86 bt/bts/btr/btc?
gcc-4.5/gcc/config/i386/i386.md: ;; %%% bts, btr, btc, bt. ;; In general these instructions are *slow* when applied to memory, ;; since they enforce atomic operation. When applied to registers, I haven't found documented confirmation that these instructions are atomic without a lock prefix, having checked Intel and AMD documentation and random web searching. They are mentioned as instructions that can be used with lock prefix. - Jay
RE: atomicity of x86 bt/bts/btr/btc?
> Subject: Re: atomicity of x86 bt/bts/btr/btc? > From: foxmuldrsterm > To: jay.krell > CC: gcc@gcc.gnu.org > Date: Tue, 19 Oct 2010 02:52:34 -0500 > > > ;; %%% bts, btr, btc, bt. > > ;; In general these instructions are *slow* when applied to memory, > > ;; since they enforce atomic operation. When applied to registers, > > > > I haven't found documented confirmation that these instructions are atomic > > without a lock prefix, > > having checked Intel and AMD documentation and random web searching. > > They are mentioned as instructions that can be used with lock prefix. > > They do not automatically lock the bus. They will lock the bus with the > explicit LOCK prefix, and BTS is typically used for an atomic read/write > operation. > > - Rick Thanks Rick. I'll go back to using them. I'm optimizing mainly for size. The comment should perhaps be amended. The "since they enforce atomic operation" part seems wrong. - Jay
RE: atomicity of x86 bt/bts/btr/btc?
> Subject: RE: atomicity of x86 bt/bts/btr/btc?
> From: foxmuldrster
> To: jay
> CC: gcc
> Date: Tue, 19 Oct 2010 03:05:26 -0500
>
> > > They do not automatically lock the bus. They will lock the bus with the
> > > explicit LOCK prefix, and BTS is typically used for an atomic read/write
> > > operation.
>
> > Thanks Rick.
> > I'll go back to using them.
> > I'm optimizing mainly for size.
> > The comment should perhaps be amended.
> > The "since they enforce atomic operation" part seems wrong.
>
> Np. For citation, see here (page 166).
>
> http://www.intel.com/Assets/PDF/manual/253666.pdf
>
> - Rick
Yep that was one of my references.
It might be nice if optimizing for size would use them with code like e.g.:
void set_bit(size_t* a, size_t b)
{
const unsigned c = sizeof(size_t) * CHAR_BIT;
a[b / c] |= (((size_t)1) << (b % c));
}
void clear_bit(size_t* a, size_t b)
{
const unsigned c = sizeof(size_t) * CHAR_BIT;
a[b / c] &= ~(((size_t)1) << (b % c));
}
int get_bit(size_t* a, size_t b)
{
const unsigned c = sizeof(size_t) * CHAR_BIT;
return !!(a[b / c] & (((size_t)1) << (b % c)));
}
- Jay
is gcc garbage collector compacting?
Is the gcc garbage collector compacting? In particular I want to have ".def" file (like tree.def) where the macros generate struct declarations, and the fields might be tree. That won't work with the gcc garbage collection scheme. However, I'm willing also store all trees that go in these structs in a global VEC of trees, that does work with the garbage collector. That would suffice to keep them alive. But it wouldn't keep them up to date if the garbage collector is compacting. Heck, I guess, if need be, I'm willing to apply a slight hack to disable the garbage collector. If I really must -- if there is really much garbage to collect, I could run the preprocessor ahead of time and provide a file to gengtype that it understands. I'm leary of this approach, because I want only certain preprocessing to take place. I could output markers before/after the chunk I want though. Or, maybe the files do get preprocessed? Evidence is no, as when #if 0'ed out some types, gengtype still saw them. Something to consider, perhaps. Thanks, - Jay
RE: is gcc garbage collector compacting?
> Are you coding inside your branch, or just your plugin? > [implied] What are you actually doing? It isn't relevant or short, but if you really want to know: It is a front end, and indeed, a branch, it won't ever be contributed. It is the Modula-3 frontend, which plays slight licensing games and the original authors aren't around, so couldn't get to FSF, and current maintainers can't either. Honestly, long term, I'd like to generate C instead, for a variety of reasons. - no more license game - more portability (e.g. to platforms that also fork/maintain gcc, so we don't have to fork and patch also theirs: e.g. OpenBSD, iPhone; e.g. to platforms with no gcc such as NT/ia64) - generate C++ actually, for portable usually efficient exception handling Currently we use setjmp/longjmp and a thread local. It works and is very portable, but is very inefficient. - debuggability, with stock debuggers - solidly fix stuff I detail below - a source distribution story Yes, I realize, compilers must be distributed as binaries, but one can paint the world as layered on C or C++ and then only their compilers need binary distribution. - I realize compile speed would suffer. And expression evaluation in debugger would suffer. Those are the drawbacks. Making it a plugin might be viable in the future, but I'm more keen on generating C instead. We also have our own frontend for NT/x86, that writes out COFF .objs, which might be interesting to extend to others, but that is a lot of work. Historically we have generated very poor trees. One particular example is that our structs have size but no fields. I only realized this when targeting Solaris/sparc64 and hitting assertion failures in the middle end -- the code couldn't figure out how to pass such things. As well, historically, we made everything volatile, in order to defeat the optimizer. Now what we do is almost never use volatile, but still turn off a small number of optimizations. Nobody also had been using configure -enable-checking, and it complains variously. I've fixed some of that. So I'm working on filling in types much better. I have made good fast progress. This also greatly improves debugging with stock gdb, instead of forked/hacked gdb that we get debug info to in a somewhat sleazy but fairly portable way (custom stabs, as I understand, doesn't work e.g. on HP-UX/HPPA64 or on any MacOSX.) However some of the types are circular, and the code currently only makes one pass. So I simply want it to build up its own in-memory representation, make some passes over that, and then generate the "real" trees. The in-memory representation will contain some trees.. though I suppose now that I explain it, there is a way around that. The reading of the intermediate form is somewhat data driven, reading into locals. I want to reuse that but read into structs, and then loop over them. Simple stuff really. I could probably also make extra passes over the gcc trees instead, but I'm designing partly out of ignorance. I'm not sure when you can continue to change them vs. when they are frozen. The non-compacting of the gc makes this easier than it might be otherwise. Though looking at it, we already store many of our trees in global arrays. There's just a few stragglers I can also put in global arrays and be ok. Thanks, - Jay
RE: is gcc garbage collector compacting?
> I believe that your case is a very good example of why front-ends
> should be able to become plugins. It is not the case yet, and adding
Currently we do define a new tree code, I think just one.
And the implementation is *slightly* invasive.
I was tempted to write up a proposal to this list to add it to mainline gcc but
I ended up not.
I noticed the D/gcc frontend does something similar.
In particular..nested functions...taking their address..we implement them in a
way that
doesn't involve runtime codegen. Though there are significant downsides
to what we do. Having thought about it, I believe there is no particularly
good way to implemented nested functions (taking their address), just
multiple not very good ways.
What we do is, is that function pointers are rare in our language.
Before calling through any function pointer, we read the data it points to and
check for a marker -- -1, currently of size_t size, though probably should
always be 4 bytes (alignment issues), except maybe on IA64 (particularly
large instructions). This is a bit sleazy -- assumption
that code is readable and that -1 isn't valid code, but other target-dependent
markers could be specified. Anyway, if it -1, it is followed by actual function
pointer and frame pointer, and that is used instead of calling it directly.
Something like that.
The implication on the backend isn't perhaps clear from that, nor do I
necessarily
understand it. But certainly gcc's existing nested functions don't work this
way.
I understand, again, there are major tradeoffs either way. Ours is not
monotonically
better than gcc's.
Ah, I guess the new code is to load the static link following the -1.
A C-generating front end has other advantages:
I know what is well formed C.
I don't know what is well formed gcc/tree or gcc/gimple.
The various problems we have with the optimizer -- because our trees are
poorly formed -- would go away.
We wouldn't have to twiddle various optimizations off.
This is sort of "magic/special" -- I just happen to know far more about C
than gcc internals.
> (and there is also LLVM which could perhaps interest you).
Yeah, people have asked about using it. But nobody puts any work into
it from our side (we have precious few people doing anything!).
We aren't supposed to discuss it here. :)
And it has the same disadvantage vs. C/C++ that gcc/tree/gimple has -- I know
what is valid C/C++,
whereas LLVM is another big unknown to investigate. And it hits fewer targets.
Granted, both mainline gcc and LLVM hit plenty targets.
I do dream of having portability on par with: printf("hello world\n"); without
doing much porting myself/ourselves, and have access to wierd systems such as
VMS. :)
> future gimple front-end
Interesting. But again similar problems.
Given my knowledge, generating C/C++ easier than anything else.
Also have to wait until these versions of gcc are widespread.
Look at Apple and OpenBSD for how older gcc remains in use.
Anyway, knowing the garbage collector isn't compacting is good.
Thanks,
- Jay
> Date: Wed, 3 Nov 2010 10:23:14 +0100
> From: basile@
> To: jay.kr...@u
> CC: gcc@
> Subject: Re: is gcc garbage collector compacting?
>
[snip]
asm_fprintf inefficiency?
so..I was bemaining to self extra #ifs, extra autoconf..
the checking for puts_locked...
the fact that asm_fprintf calls putc one character at a time,
which probably benefits from _unlocked.
1) asm_fprintf probably should skip from % to %, calling
puts on each span, instead of putc one at a time.
Granted, its input strings tend to be short.
2) But more so..
given, e.g.:
asm_fprintf(file, "%Rfoo");
one could instead say
#ifndef REGISTER_PREFIX
#define REGISTER_PREFIX ""
#endif
fprintf(file, "%sfoo", REGISTER_PREFIX);
That works for all of asm_fprintf (I, L, R, U) except %O, and %O appears
little used or unused. And it doesn't handle {.
jbook2:gcc jay$ grep asm_fprintf */*/* | grep { | wc -l
33
jbook2:gcc jay$ grep asm_fprintf */*/* | wc -l
318
Maybe something else could be done for those 10%?
like:
before:
asm_fprintf (file, "\t{l|lwz} %s,", reg_names[0]);
after:
fprintf (file, "\t%s %s,", dialect_number ? "lwz" : "l", reg_names[0]);
or bigger/faster:
fprintf (file, dialect_number ? "\tlwz %s," : \tl %s,", reg_names[0]);
(Really I'd rather gcc just output .o files directly...)
- Jay
RE: asm_fprintf
> And putc_unlocked is a macro which appends to a buffer. puts is not. I *assumed* there is puts_unlocked like all the other *_unlocked. Maybe not. > (Really I'd rather gcc just output .o files directly...) > It would be an interesting project, but it's not a major component of > optimizing compilation time. I would certainly encourage any interested Perhaps when not optimizing? Eh, but I've taken no measurement. There is the possible fork() cost on Cygwin. But maybe spawn is used, much faster. - Jay
