Re: trying to fix a bug in m6812 front-end
On Fri, Jan 19, 2007 at 05:10:27PM -0700, Sean D'Epagnier wrote: > I am using gcc 3.3.5 with the latest m68hc1x patches to compile programs for a > 9s12 processor, and cc1 calls abort when compiling the following code: It would be most useful to have the exact error message. I'm guessing that the problem here is an unrecognizable instruction. > It looks like somewhere before generating rtl in the second case, it split > the instruction > as this architecture cannot handle the second instruction in the first case. > xor behaves > similarly to or and works as well. > > I am trying to find out what part of gcc to look in so I can make the change > so that the and > instruction is handled the same way. I think the andhi3 expander (m68hc11.md) is at fault. Compare the predicates for operand 2 with the ones for iorhi3 and xorhi3: (define_expand "andhi3" [(set (match_operand:HI 0 "register_operand" "") (and:HI (match_operand:HI 1 "register_operand" "") (match_operand:HI 2 "general_operand" "")))] "" "") (define_expand "iorhi3" [(set (match_operand:HI 0 "register_operand" "") (ior:HI (match_operand:HI 1 "register_operand" "") (match_operand:HI 2 "splitable_operand" "")))] "" "") (define_insn "xorhi3" [(set (match_operand:HI 0 "register_operand" "=d,d,!*A") (xor:HI (match_operand:HI 1 "splitable_operand" "%0,0,0") (match_operand:HI 2 "splitable_operand" "im,!u*A,!ium*A")))] "" ... I'd try changing operand 2 of andhi3 from general_operand to splitable_operand, because none of the andhi3 insn patterns seem to match (set (reg:HI) (and:HI (reg:HI) (mem:HI (mem:HI .... In particular, *andhi3_gen needs operand 2 to be a splitable_operand, which (mem:HI (mem:HI ...)) is not. -- Rask Ingemann Lambertsen
Compiling libgcc functions with non-default LIBGCC2_UNITS_PER_WORD
Somewhere in the libgcc build machinery, there is mechanism to override the default LIBGCC2_UNITS_PER_WORD setting when compilng a function, so you could in principle provide e.g. _divsi3 as well as _divdi3. It there a way of making use of this facility in a more elegant way than putting the whole gcc command line in a target makefile fragment? -- Rask Ingemann Lambertsen
Re: Running GCC tests on installed compiler
Gerald,
> > This script seems quite outdated: it tests g77 and not gfortran, even
> > with the latest 4.3.0 snapshot (20070112). ...
>
> Would you mind submitting this as a patch?
--- gcc-4.3-20070120/contrib/test_installed Fri Jul 11 08:05:01 2003
+++ gcc-4.3-20070119/contrib/test_installed Sat Jan 13 17:53:01 2007
@@ -16,12 +16,12 @@
# will be appended to the srcdir.
# You may specify where the binaries to be tested should be picked up
-# from. If you specify --prefix=/some/dir, gcc, g++ and g77 will be
+# from. If you specify --prefix=/some/dir, gcc, g++ and gfortran will be
# looked for at /some/dir/bin. Each one may be overridden by
# specifying --with-gcc=/pathname/to/gcc, --with-g++=/pathname/to/g++
-# and --with-g77=/pathname/to/g77. If you specify --without-gcc,
-# --without-g++ or --without-g77, the test for the specified program
-# will be skipped. By default, gcc, g++ and g77 will be searched in
+# and --with-gfortran=/pathname/to/gfortran. If you specify --without-gcc,
+# --without-g++ or --without-gfortran, the test for the specified program
+# will be skipped. By default, gcc, g++ and gfortran will be searched in
# the PATH.
# An additional argument may specify --tmpdir=/some/dir; by default,
@@ -50,16 +50,16 @@
--prefix=*) prefix=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--with-gcc=*) GCC_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--with-g++=*) GXX_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
- --with-g77=*) G77_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
+ --with-gfortran=*) GFORTRAN_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`;
shift;;
--without-gcc) GCC_UNDER_TEST=no; shift;;
--without-g++) GXX_UNDER_TEST=no; shift;;
- --without-g77) G77_UNDER_TEST=no; shift;;
+ --without-gfortran) GFORTRAN_UNDER_TEST=no; shift;;
--without-objc) OBJC_UNDER_TEST=no; shift;;
--tmpdir=*) tmpdir=`echo "$1" | sed 's/[^=]*=//'`; shift;;
--help) cat <<\EOF
-Runs the testsuite for an installed version of gcc/g++/g77/objc
+Runs the testsuite for an installed version of gcc/g++/gfortran/objc
Copyright (C) 1998 Free Software Foundation
by Alexandre Oliva <[EMAIL PROTECTED]>
@@ -71,13 +71,13 @@
--srcdir=/some/dirsame as --with-testsuite=/some/dir/gcc/testsuite
[deduced from shell-script pathname]
---prefix=/some/diruse gcc, g++ and g77 from /some/dir/bin [PATH]
+--prefix=/some/diruse gcc, g++ and gfortran from /some/dir/bin
[PATH]
--with-gcc=/some/dir/bin/gcc use specified gcc program [gcc]
--with-g++=/some/dir/bin/g++ use specified g++ program [g++]
---with-g77=/some/dir/bin/g77 use specified g77 program [g77]
+--with-gfortran=/some/dir/bin/gfortran use specified gfortran program
[gfortran]
--without-gcc do not run gcc testsuite
--without-g++ do not run g++ testsuite
---without-g77 do not run g77 testsuite
+--without-gfortrando not run gfortran testsuite
--without-objcdo not run objc testsuite
--tmpdir=/some/dircreate temporaries and leave failed programs
@@ -109,13 +109,13 @@
set CXXFLAGS ""
set GCC_UNDER_TEST "${GCC_UNDER_TEST-${prefix}${prefix+/bin/}gcc}"
set GXX_UNDER_TEST "${GXX_UNDER_TEST-${prefix}${prefix+/bin/}g++}"
-set G77_UNDER_TEST "${G77_UNDER_TEST-${prefix}${prefix+/bin/}g77}"
+set GFORTRAN_UNDER_TEST
"${GFORTRAN_UNDER_TEST-${prefix}${prefix+/bin/}gfortran}"
set OBJC_UNDER_TEST "${OBJC_UNDER_TEST-${prefix}${prefix+/bin/}gcc}"
EOF
test x"${GCC_UNDER_TEST}" = x"no" || runtest --tool gcc ${1+"$@"}
test x"${GXX_UNDER_TEST}" = x"no" || runtest --tool g++ ${1+"$@"}
-test x"${G77_UNDER_TEST}" = x"no" || runtest --tool g77 ${1+"$@"}
+test x"${GFORTRAN_UNDER_TEST}" = x"no" || runtest --tool gfortran ${1+"$@"}
test x"${OBJC_UNDER_TEST}" = x"no" || runtest --tool objc ${1+"$@"}
exit 0
If this is OK along with no copyright assignment, I can submit a PR.
The copyright should probably extended to 2007. I think also than one
should notify Alexandre Oliva.
> I do not know whether you have a copyright assignment on file, but
> perhaps it is simply enough that we can take it even without one.
I haven't any copyright assignment unless there is a global one with the
french CNRS (Centre National de la Recherche Scientifique), but if one is
required to replace g77 by gfortran we are really living in a sad world!
> > I looked again to the manual (http://gcc.gnu.org/install/test.html) and
> > did not find this script documented anywhere. Am I missing something
> > or is t
Re: Top level libgcc checked in
On Wed, Jan 03, 2007 at 11:28:29PM -0500, Daniel Jacobowitz wrote: > I've just committed the approved top level libgcc patches, which > create a top level "libgcc" directory. I updated to revision 120997 for my Intel x86 16-bit port, to find: Checking multilib configuration for libgcc... Configuring in ia16-elf/libgcc [snip] checking whether decimal floating point is supported... no *** Configuration ia16-unknown-elf not supported make[1]: *** [configure-target-libgcc] Fejl 1 make[1]: Leaving directory /mnt/sysfs/rask/cvsbuild/gcc' make: *** [all] Fejl 2 Say what? Libgcc used to build fine without decimal float support. -- Rask Ingemann Lambertsen
Re: Top level libgcc checked in
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes: > Checking multilib configuration for libgcc... > Configuring in ia16-elf/libgcc > [snip] > checking whether decimal floating point is supported... no > *** Configuration ia16-unknown-elf not supported > make[1]: *** [configure-target-libgcc] Fejl 1 > make[1]: Leaving directory /mnt/sysfs/rask/cvsbuild/gcc' > make: *** [all] Fejl 2 > > Say what? Libgcc used to build fine without decimal float support. There is no connection between decimal fp support and your target being unsupported. It's just that libgcc/config.host does not know anything about ia16-unknown-elf. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Preventing warnings
Nevertheless, I (and others seem to agree) would like to name that particular warning, so it can be enabled/disabled. Also, there is a similar warning for unsigned >= 0 and unsigned < 0 in -Wextra. There are bug reports about the inconsistency (http://gcc.gnu.org/PR23587). So, it would be nice to unify them, give them a name and properly document the new option. I agree it would be a useful feature to be able to enable and disable this warning (and various others) for the whole compilation. That future would be a way to prevent these spurious and expected warnings. However, this is not the best solution, because it would also suppress any other warnings of the same kind that might occur unexpectedly in other code in Emacs. Those warnings might indicate real bugs. The ideal solution to this would be a construct we can use to turn off warnings in a small piece of the code. We could use it to turn off these warnings in FIXNUM_OVERFLOW_P, and the warning would still be enabled for the rest of the Emacs source code. In Emacs Lisp, there is a feature called `with-no-warnings'. If you write `(with-no-warnings ...)' around an expression, it suppresses all compiler warnings from that expression. You use it around small expressions that you know will produce warnings which do not indicate anything is wrong. It would be nice to have such a construct in GNU C, something that could be used in a macro expansion, and would turn off _all_ warnings for the code within the construct. This feature could use _Pragma, or __attributes__.
Re: Preventing warnings
On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote: > It would be nice to have such a construct in GNU C, something that > could be used in a macro expansion, and would turn off _all_ warnings > for the code within the construct. http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html But it says: Also, while it is syntactically valid to put these pragmas anywhere in your sources, the only supported location for them is before any data or functions are defined. Doing otherwise may result in unpredictable results depending on how the optimizer manages your sources. Maybe this will be better if all warnings only come from the front-end. -- Pinski
