[Bug bootstrap/20437] New: bootstrap --enable-maintainer-mode broken
$ ../gcc-4.1/configure --prefix=$HOME --enable-languages=c,f95 --enable-maintainer-mode creating cache ./config.cache checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for a BSD compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for gnatbind... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for correct version of gmp.h... yes checking for MPFR... yes *** This configuration is not supported in the following subdirectories: target-libada gnattools target-libstdc++-v3 target-libffi target-boehm-gc target-zlib target-libjava zlib fastjar target-libobjc (Any other directories should still work fine.) checking for bison... bison checking for bison... bison -y checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for i686-pc-linux-gnu-ar... no checking for ar... ar checking for i686-pc-linux-gnu-as... no checking for as... as checking for i686-pc-linux-gnu-dlltool... no checking for dlltool... dlltool checking for i686-pc-linux-gnu-ld... no checking for ld... ld checking for i686-pc-linux-gnu-nm... no checking for nm... nm checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking for i686-pc-linux-gnu-windres... no checking for windres... windres checking for i686-pc-linux-gnu-objcopy... no checking for objcopy... objcopy checking for i686-pc-linux-gnu-objdump... no checking for objdump... objdump checking for i686-pc-linux-gnu-ar... no checking for ar... ar checking for i686-pc-linux-gnu-as... no checking for as... as checking for i686-pc-linux-gnu-dlltool... no checking for dlltool... dlltool checking for i686-pc-linux-gnu-ld... no checking for ld... ld checking for i686-pc-linux-gnu-nm... no checking for nm... nm checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking for i686-pc-linux-gnu-windres... no checking for windres... windres checking whether to enable maintainer-specific portions of Makefiles... yes checking if symbolic links between directories work... yes updating cache ./config.cache creating ./config.status creating Makefile $ make bootstrap cd ../gcc-4.1 autogen Makefile.def cd ../gcc-4.1 autoconf configure.in:2207: error: possibly undefined macro: AS_FOR_TARGET If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [../gcc-4.1/configure] Error 1 $ grep version_string ../gcc-4.1/gcc/version.c const char version_string[] = 4.1.0 20050312 (experimental); $ autogen -v autogen - The Automated Program Generator - Ver. 5.6.6 $ autoconf -V autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: bootstrap --enable-maintainer-mode broken Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20437
[Bug libfortran/20438] New: conflicting types for int8_t with --enable-maintainer-mode
In an empty directory: $ ../gcc-4.0/configure --prefix=$HOME --enable-languages=c,f95 --enable-maintainer-mode ... $ make bootstrap ... make[5]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libmudflap' make[4]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libmudflap' make[3]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libmudflap' make[2]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libmudflap' /bin/sh ../gcc-4.0/mkinstalldirs i686-pc-linux-gnu/libgfortran ; \ rm -f i686-pc-linux-gnu/libgfortran/Makefile || : ; \ cp multilib.out i686-pc-linux-gnu/libgfortran/multilib.out mkdir -p -- i686-pc-linux-gnu/libgfortran Configuring in i686-pc-linux-gnu/libgfortran configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for i686-pc-linux-gnu-gcc... /home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem/home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include accepts -g... yes checking for /home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include option to accept ANSI C... none needed checking for i686-pc-linux-gnu-as... as checking for i686-pc-linux-gnu-ar... ar checking for i686-pc-linux-gnu-ranlib... ranlib checking whether make sets $(MAKE)... (cached) yes checking for a BSD-compatible install... /usr/bin/install -c checking for ld used by GCC... ld checking if the linker (ld) is GNU ld... yes checking for ld option to reload object files... -r checking for BSD-compatible nm... nm checking whether ln -s works... yes checking how to recognise dependant libraries... pass_all checking for i686-pc-linux-gnu-ranlib... (cached) ranlib checking for i686-pc-linux-gnu-strip... no checking for strip... strip updating cache ./config.cache loading cache ./config.cache within ltconfig checking whether -lc should be explicitly linked in... no checking for objdir... .libs checking for /home/ig25/gcc-4.0-bin/gcc/xgcc option to produce PIC... -fPIC -DPIC checking if /home/ig25/gcc-4.0-bin/gcc/xgcc PIC flag -fPIC -DPIC works... yes checking if /home/ig25/gcc-4.0-bin/gcc/xgcc static flag -static works... yes finding the maximum length of command line arguments... 49153 checking if /home/ig25/gcc-4.0-bin/gcc/xgcc supports -c -o file.o... yes checking if /home/ig25/gcc-4.0-bin/gcc/xgcc supports -fno-rtti -fno-exceptions ... no checking whether the linker (ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking command to parse nm output... ok checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes creating libtool updating cache ./config.cache configure: loading cache ./config.cache checking for i686-pc-linux-gnu-gfortran... /home/ig25/gcc-4.0-bin/gcc/gfortran -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include checking whether we are using the GNU Fortran compiler... yes checking whether /home/ig25/gcc-4.0-bin/gcc/gfortran -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include accepts -g... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGE_FILES value needed for large files... no checking how to run the C preprocessor... /home/ig25/gcc-4.0-bin/gcc/xgcc
[Bug middle-end/20434] pessimization of complex expression
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12 09:45 --- (In reply to comment #4) (In reply to comment #3) - Why the casts to double? Because that is required by the C standard. Isn't that covered by the as-if rule? I'm fairly sure the cast to double won't change the result of the operator :-) No but the addition is done in double. Again, the as-if rule: If a and b are floats, the expression a+b 0 should be the same for any a and b regardless wether they are done in float or double. The same is true, for float a,b and c, of c = a+b; It is _not_ true for exmperssions like c = a+b-a, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
[Bug libgcj/20392] invalid install/relink of llibgcj{,0_convenience} during `make install`
--- Additional Comments From pluto at pld-linux dot org 2005-03-12 10:02
---
I've noticed that below change fixes relinking.
Could anonyone merge this fix to Makefile{.am,.in} ?
--- libgcj0_convenience.la.orig 2005-03-12 06:07:36.0 +0100
+++ libgcj0_convenience.la 2005-03-12 10:49:59.865017152 +0100
@@ -5,16 +5,16 @@
# It is necessary for linking the library.
# The name that we can dlopen(3).
-dlname='libgcj0_convenience.so.0'
+dlname=''
# Names of this library.
-library_names='libgcj0_convenience.so.0.0.0 libgcj0_convenience.so.0
libgcj0_convenience.so'
+library_names=''
# The name of the static archive.
old_library='libgcj0_convenience.a'
# Libraries that this one depends upon.
-dependency_libs='
-L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libstdc++-v3/src
-L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libstdc++-v3/src/.libs
-L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/i686-pld-linux/libjava
-L/home/users/pluto/multimedia/rpm/BUILD/gcc-4.0-20050305/obj-i686-pld-linux/gcc
-L/usr/lib/gcc/i686-pld-linux/4.0.0
-L/usr/lib/gcc/i686-pld-linux/4.0.0/../../.. -lgcc_s -lc -lgcc_s'
+dependency_libs=''
# Version information for libgcj0_convenience.
current=0
@@ -29,4 +29,4 @@
dlpreopen=''
# Directory that this library needs to be installed in:
-libdir='/usr/lib'
+libdir=''
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20392
[Bug libgcj/20392] invalid install/relink of llibgcj{,0_convenience} during `make install`
-- What|Removed |Added CC||mmazur at kernel dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20392
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-12 11:14 --- Another reason why spelling needs preserving (in addition to implementing # correctly) is for the constraints on duplicate macro definitions. #define foo \u00c1 #define foo \u00C1 is invalid (different spelling in replacement), as is #define bar(\u00c1) #define bar(\u00C1) (different spelling of parameter names). However, #define \u00c1 foo #define \u00C1 foo is valid, since the spelling of the macro *name* doesn't need to be the same. It is true that we don't get the constraints on duplicate macro definitions right in all cases at present (bug 20078), but since spelling of identifiers needs preserving anyway for the # operator this seems no reason not to get this case right (with testcases, of course). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug bootstrap/20437] bootstrap --enable-maintainer-mode broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 12:30 --- The toplevel configure uses autoconf 2.13. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20437
[Bug c++/20240] [3.3/3.4/4.0/4.1 Regression] invalid using-redeclaration accepted
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-12 12:40 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01208.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20240
[Bug c++/20333] [3.4/4.0/4.1 Regression] ICE on invalid code, typename outside of a template
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-12 12:41 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01207.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20333
[Bug fortran/20334] Dimensioned parameters get their dimensions lost.
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-03-12 12:57 --- Sorry, should have looked at old bugs first ... *** This bug has been marked as a duplicate of 19926 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20334
[Bug fortran/19926] Incorrect rank with PARAMETER and array element.
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-03-12 12:57 --- *** Bug 20334 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||toon at moene dot indiv dot ||nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19926
[Bug libfortran/20438] conflicting types for int8_t with --enable-maintainer-mode
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-12 13:44 --- 'configure --enable-maintainer-mode' should be run in the source directory, and not be used during the build. If I understand correctly. -- What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
[Bug c++/20439] New: Dropped attributes on class members
//==
// Dropped attributes on class member
//==
// $ g++ -ansi -pedantic -Wall -c file
// Output:
// ... 'ASSERTION_FAILED_IN_LINE_42' ...
// Known to fail with:
// 3.4.3 (linux)
// 3.4.2 (linux)
// 3.4.2 (mingw)
// 3.3.4 (linux)
// 3.2.3 (mingw)
// Known to work with:
// 4.0.0-beta (linux)
//==
//--
// Simple compile time assertion facility to check the identity of two types
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
templatetypename X, typename Y struct same { enum { n = -1 }; };
templatetypename X struct sameX,X { enum { n = 1 }; };
#define ASSERT_SAME_TYPE(x,y) ASSERT_SAME_TYPE_IMPL_I(__LINE__,x,y)
#define ASSERT_SAME_TYPE_IMPL_I(i,x,y) ASSERT_SAME_TYPE_IMPL_II(i,x,y)
#define ASSERT_SAME_TYPE_IMPL_II(i,x,y) \
bool ASSERTION_FAILED_IN_LINE_ ## i [ ::samex,y::n ]
//--
// The problem
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#define CC __attribute__((__stdcall__))
typedef void CC type();
ASSERT_SAME_TYPE(type,void CC ()); // ok
struct X
{
typedef void CC type();
};
ASSERT_SAME_TYPE(X::type,void CC ()); // - here
//--
--
Summary: Dropped attributes on class members
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinger at neoscientists dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20439
[Bug c++/20439] Dropped attributes on class members
-- What|Removed |Added Known to fail||3.2.3 3.3.4 3.4.2 3.4.3 Known to work||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20439
[Bug c++/20439] Dropped attributes on class members
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 14:32 --- Fixed in 4.0.0. (after 3.5.0 20040909). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Known to fail|3.2.3 3.3.4 3.4.2 3.4.3 |3.2.3 3.3.4 3.4.2 3.4.3 ||3.0.4 2.95.3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20439
[Bug libfortran/20438] conflicting types for int8_t with --enable-maintainer-mode
--- Additional Comments From schwab at suse dot de 2005-03-12 14:59 --- This has nothing to do with maintainer-mode. See http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00874.html for a possible fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
[Bug c++/20234] ambiguity with friend name injection and using directive
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-12 15:13 --- The patch that fixes this bug is the same as the one in PR1016. Closing it as a duplicate. *** This bug has been marked as a duplicate of 1016 *** -- What|Removed |Added BugsThisDependsOn||1016 Status|ASSIGNED|RESOLVED Keywords||patch Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20234
[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-12 15:13 --- *** Bug 20234 has been marked as a duplicate of this bug. *** -- What|Removed |Added OtherBugsDependingO||20234 nThis|| CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1016
[Bug fortran/20440] New: error with fixed form one-liner
the following valid fixed-form program is rejected by gfortran: [EMAIL PROTECTED] tests]$ cat fix.f STOP IT = NOW; END [EMAIL PROTECTED] tests]$ g77 fix.f [EMAIL PROTECTED] tests]$ gfortran fix.f Error: Unexpected end of file in 'fix.f' [EMAIL PROTECTED] tests]$ -- Summary: error with fixed form one-liner Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20440
[Bug fortran/20440] error with fixed form one-liner
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-12 15:21 --- Forgot to say: putting then END statement on a new line lets this compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20440
Re: gcc-4.0.0 doesn't produce a valid assembler file
gcc-4.0.0 doesn't produce a valid assembler file. I didn't have this problems using gcc-3.4.2 Info at end of letter. Posting to gcc-bugs is deprecated. Please file a bugzilla PR instead: http://gcc.gnu.org/bugzilla/ -- Eric Botcazou
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
-- What|Removed |Added CC||jason at redhat dot com AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug fortran/18913] [3.3/3.4/4.0 Regression] seg. fault with -finit-local-zero option on complex array of dimension 1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 17:10 --- This is a regression also. -- What|Removed |Added Known to fail||3.2.3 3.3.3 3.4.0 Known to work||2.95.3 3.0.4 Last reconfirmed|2004-12-11 01:35:06 |2005-03-12 17:10:03 date|| Summary|[g77 only] seg. fault with -|[3.3/3.4/4.0 Regression] |finit-local-zero option on |seg. fault with -finit- |complex array of dimension 1|local-zero option on complex ||array of dimension 1 Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18913
[Bug fortran/20441] New: -finit-local-zero is missing from gfortran
I was just looking through bugs which have not been touched in 90 days and noticed there was a g77 bug (PR 18913) which really could not be tested with gfortran because -finit-local-zero is missing. This option is really only useful for very old fortran code. -- Summary: -finit-local-zero is missing from gfortran Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug middle-end/11375] rtl_dump_file problems in rest_of_compilation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 17:15 --- Some update on this bug. rest_of_handle_ssa is removed and has been since 3.4.0. -- What|Removed |Added Component|other |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375
[Bug fortran/20440] error with fixed form one-liner (gfortran does not have a sense of humor)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 17:17 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-12 17:17:11 date|| Summary|error with fixed form one- |error with fixed form one- |liner |liner (gfortran does not ||have a sense of humor) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20440
[Bug rtl-optimization/20413] VOIDmode LABEL_REFs are generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 17:27 --- Confirmed, I commented about the mode just recently. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-12 17:27:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20413
[Bug target/20360] 20021014-1.c fails on account of unsupported build option
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 17:28 --- (In reply to comment #2) If I understand the purpose of the test, it was to check whether profiling is working correctly, as far as being capable of building and running without a failure report. I've not found an explanation why certain targets, like cygwin, support only -pg, others only -p, and others both. The main point is to stop reporting a spurious error when running the testsuite. No it is just testing -p and not -pg, there is a difference but I don't remember what. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20360
[Bug fortran/20363] interface body has incorrect scope
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 17:29 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-03-12 17:29:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20363
[Bug target/19887] g++.dg/warn/weak1.C fails on HPUX
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-12 17:30:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19887
[Bug target/20095] gcc.dg/cleanup-5.c fails on ia64-hpux
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-12 17:33:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20095
[Bug middle-end/20432] complex reciprocal has too many operations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 17:35 --- I cannot remember the rules but -0.0 * 0.0 could be -0.0 (and not 0.0), someone needs to help me here. -- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20432
[Bug c++/20442] New: problem mixing C++ exceptions and setjmp/longjmp under Cygwin
This is a copy of a posting by John Eaton on the Cygwin list. I can confirm
that the problem starts with gcc-3.3 and is present in gcc-4.0
__
I believe the following program should print
main: calling doit
doit: calling toit
toit: throwing exception
toit: caught exception, longjumping
doit: longjump landed, throwing exception
main: caught exception
but on the current Cygwin (updated today) using the 1.5.13-1
cygwin.dll and either gcc 3.3 or 3.4, it crashes with a segfault just
after printing the next to last line:
doit: longjump landed, throwing exception
I tried going back to 1.5.12, but that did not fix the problem.
Can anyone reproduce this problem?
This problem affects GNU Octave, as it uses this technique to handle
interrupts in code that is a mixture of C++, C, and Fortran. If
SIGINT arrives in a section of Octave code, the signal handler sets a
flag and then returns, letting Octave check the flag periodically. At
some safe location, an exception is thrown that will return control
to the top level of the main interpreter loop. If SIGINT arrives
inside some foreign code (say, readline, or some Fortran code) then
the signal handler jumps back to the location of the call to the
foreign code. At that point, an exception is thrown to get back to
the top level. I've not had problems with this approach until
recently when I upgraded my Cygwin installation. Now Ctrl-C at the
prompt causes a segfault. The program below is a distillation of the
key features of the Octave code, and shows the same problem.
Any clues?
Thanks,
jwe
--
www.octave.org | [EMAIL PROTECTED]
#include setjmp.h
#include iostream
jmp_buf context;
class
exception
{
// empty;
};
static void
toit (void)
{
try
{
std::cerr toit: throwing exception std::endl;
throw exception ();
}
catch (exception)
{
std::cerr toit: caught exception, longjumping std::endl;
longjmp (context, 1);
}
}
static void
doit (void)
{
if (setjmp (context) == 0)
{
std::cerr doit: calling toit std::endl;
toit ();
}
else
{
std::cerr doit: longjump landed, throwing exception std::endl;
throw exception ();
}
}
int
main (void)
{
try
{
std::cerr main: calling doit std::endl;
doit ();
}
catch (exception)
{
std::cerr main: caught exception std::endl;
}
return 0;
}
--
Summary: problem mixing C++ exceptions and setjmp/longjmp under
Cygwin
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paulthomas2 at wanadoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20442] problem mixing C++ exceptions and setjmp/longjmp under Cygwin
-- What|Removed |Added Component|c++ |middle-end Keywords||EH, sjlj-eh, wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug libgcj/20392] invalid install/relink of llibgcj{,0_convenience} during `make install`
--- Additional Comments From pluto at pld-linux dot org 2005-03-12 17:55 --- finally I've fixed this problem with this patch. gcc was bootstraped and tested successfuly on ix86 and amd64. --- gcc-4.0-20050305/libjava/Makefile.am.orig +++ gcc-4.0-20050305/libjava/Makefile.am @@ -624,7 +624,7 @@ $(libgcj0_convenience_la_LINK) \ -objectlist libgcj0_convenience.objectlist \ $(libgcj0_convenience_la_LIBADD) \ - -rpath $(toolexeclibdir) $(libgcj0_convenience_la_LDFLAGS) $(LIBS) + $(libgcj0_convenience_la_LDFLAGS) $(LIBS) lib-gnu-awt-xlib.la: $(lib_gnu_awt_xlib_la_OBJECTS) $(lib_gnu_awt_xlib_la_DEPENDENCIES) @echo Creating list of files to link... --- gcc-4.0-20050305/libjava/Makefile.in.orig +++ gcc-4.0-20050305/libjava/Makefile.in @@ -26699,7 +26699,7 @@ $(libgcj0_convenience_la_LINK) \ -objectlist libgcj0_convenience.objectlist \ $(libgcj0_convenience_la_LIBADD) \ - -rpath $(toolexeclibdir) $(libgcj0_convenience_la_LDFLAGS) $(LIBS) + $(libgcj0_convenience_la_LDFLAGS) $(LIBS) lib-gnu-awt-xlib.la: $(lib_gnu_awt_xlib_la_OBJECTS) $(lib_gnu_awt_xlib_la_DEPENDENCIES) @echo Creating list of files to link... -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20392
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 18:00 --- Confirmed, this is happens on all target which use setjmp/longjmp exceptions. I forget if any of the primary/secondary targets still use sjlj exceptions but this is a regression from 2.95.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.1.0 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-03-12 18:00:03 date|| Summary|problem mixing C++ |[3.3/3.4/4.0 Regression] |exceptions and |problem mixing C++ |setjmp/longjmp under Cygwin |exceptions and ||setjmp/longjmp with SJLJ ||exceptions Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug middle-end/20434] pessimization of complex expression
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 18:07 --- (In reply to comment #5) Again, the as-if rule: If a and b are floats, the expression a+b 0 should be the same for any a and b regardless wether they are done in float or double. Well the real reason is creal/cimag returns double and not float. Use crealf/cimagf instead. Well yes this is a missed optimization, which should be filed separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
[Bug libfortran/20436] usring nested reshape functions gives runtime error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 18:01 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-12 18:01:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20436
[Bug c++/20443] New: ICE on invalid C++ code
When compiling the following code:
-test.cc---
// Trigger ICE with invalid input.
// Wolfgang Wieser 03/2005.
int foo(some_type x); // some_type is unknown here by purpose.
templatetypename Tint foo(T x) {}
...gcc will crash with the following output:
test.cc:4: error: 'some_type' was not declared in this scope
test.cc:5: error: 'templateclass T int foo(T)' redeclared as different kind
of symbol
test.cc:4: error: previous declaration of 'int foo'
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Obviously the code is invalid because some_type has not been declared.
Versions checked by me:
4.0.0: 20050219 (exp.): ICE
4.1.0: 20050312 (exp.): ICE
3.4.x: work correctly
--
Summary: ICE on invalid C++ code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wwieser at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20443
[Bug c++/20443] [4.0/4.1 Regression] ICE on invalid C++ code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 18:40 --- This has been broken for a while. With 3.5.0 20040909, I get the following ICE: t.cc:1: error: `some_type' was not declared in this scope t.cc:2: error: `templateclass T int foo(T)' redeclared as different kind of symbol t.cc:1: error: previous declaration of `int foo' t.cc:2: internal compiler error: tree check: expected class 'd', have 'x' (error_mark) in push_template_decl_real, at cp/pt.c:3067 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||error-recovery, ice-on- ||invalid-code Last reconfirmed|-00-00 00:00:00 |2005-03-12 18:40:49 date|| Summary|ICE on invalid C++ code |[4.0/4.1 Regression] ICE on ||invalid C++ code Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20443
[Bug objc/20444] New: Misleading error message on missing ';'
When an ';' is missing after method before @end in @interface GCC outpus following error: error: parse error before 'CPP_AT_NAME' token The error is misleading, as it is not clear to the user what the problem exactly is. -- Summary: Misleading error message on missing ';' Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: objc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: stefan at agentfarms dot net CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20444
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From marekm at amelek dot gda dot pl 2005-03-12 20:39 --- (In reply to comment #17) Marek, can you review this bug, the attached patches, and possibly approve committing the fix? I'm looking into it right now. I'm not sure about one thing: should movmemhi handle only constant block sizes, or variable block sizes too? If variable - is it safe to assume nonzero? (now 0 means 65536) Operand 2 (block size) has the const_int_operand predicate - doesn't this mean that (GET_CODE(operands[2]) == CONST_INT) is always true? Thanks, Marek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug bootstrap/20424] Bootstrap failure on alphaev56
--- Additional Comments From falk at debian dot org 2005-03-12 20:43 --- I think I know why this happens: there's a bug in alpha_fold_builtin_cmpbge. Will test a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |falk at debian dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20424
[Bug c/20445] New: garbage returned when trying to get the second word of a double value
gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparcv9-sun-solaris2/3.3.2/specs
Configured with: /usr/local/src/gnu/gcc-3.3.2/configure --enable-languages=c,c+Â¥
+ sparcv9-sun-solaris2
Thread model: posix
gcc version 3.3.2
cat test.c
#include stdio.h
typedef int int32;
void out(int32 i) {
printf(0x%x¥n, i);
}
double inp(void) {
return 123.456789;
}
void getlo() {
double d = inp();
int32 i = *((int32 *)d + 1);
out(i);
}
void gethi() {
double d = inp();
int32 i = *(int32 *)d;
out(i);
}
int main() {
gethi();
getlo();
return 0;
}
gcc -m32 -O2 test.c -o test
./test
0x405edd3c
0xfbbb3834
gcc -m32 -O test.c -o test
./test
0x405edd3c
0x7ee0b0b
--
Summary: garbage returned when trying to get the second word of a
double value
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sumii at saul dot cis dot upenn dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparcv9-sun-solaris2
GCC host triplet: sparcv9-sun-solaris2
GCC target triplet: sparcv9-sun-solaris2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20445
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From andrewhutchinson at cox dot net 2005-03-12 21:20 --- (In reply to comment #18) (In reply to comment #17) I think it is always true but the original used the same predicate and test (so I played safe). The pattern only helps if it is a constant. I also thought it should handle variable block size. However, I found gcc already produces optimal code for that case without any help. Marek, can you review this bug, the attached patches, and possibly approve committing the fix? I'm looking into it right now. I'm not sure about one thing: should movmemhi handle only constant block sizes, or variable block sizes too? If variable - is it safe to assume nonzero? (now 0 means 65536) Operand 2 (block size) has the const_int_operand predicate - doesn't this mean that (GET_CODE(operands[2]) == CONST_INT) is always true? Thanks, Marek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug c/20445] garbage returned when trying to get the second word of a double value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 21:23 --- You are violating C aliasing rules, try an union. Read http://gcc.gnu.org/bugs.html which show how to deal with this. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20445
[Bug middle-end/11375] rtl_dump_file problems in rest_of_compilation
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-12 21:28 --- (In reply to comment #0) Consider the relatively new bt-load optimization. It runs in the middle of the flow2 pass. It opens and closes its own dump file, DFI_branch_target_load. This is all well and good, but there is a problem here. Dump files don't stack. So when we calll open_dump_file for DFI_branch_target_load, we end up closing the DFI_flow2 file accidentally. Then when we close DFI_branch_target_load, we have no dump file at all. 35 lines later, we attempt to close DFI_flow2, but this does nothing at all. Meanwhile, lots of info that should have gone into the flow2 dump file disappears. In September 2004, open_dump_file was changed so that it aborts when a dump file is already open. That made the sh64-elf compiler abort when running with -da. I've fixed this with this patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01467.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From anton at mips dot complang dot tuwien dot ac dot at 2005-03-12 21:38 --- Subject: Re: [3.3/3.4 regression] pessimization of goto * steven at gcc dot gnu dot org wrote: --- Additional Comments From steven at gcc dot gnu dot org 2005-03-10 12:48 --- Maybe there should be another combining pass after the duplication of the indirect jumps. Should I create another PR for this? There should not be another combining pass (you really mean constant propagation). I meant Instruction combination (`combine.c'). Not sure if this is replaced by something else in the recent gccs. Why do you think I mean constant propagation? This new unfactoring stuff runs after register allocation, so such a pass would not really help, except maybe to make the code look prettier to you. Ouch. No way to fix that? That's the cost we wanted to avoid. But, is this: mov0xfffc(%ebx),%eax jmp*%eax slower than this: jmp*0xfffc(%ebx) or have you not tried that (e.g. by hacking the assembly by hand)? Ok, I hacked the assembly by hand, and this is what I got: All numbers are user times in seconds for gforth-fast-0.6.2: Pentium-4 2.26 GHz (i386 code): no-dynamic no-super dynamic combined? yes no yes noyes no siev 0.47 0.49 0.36 0.36 0.33 0.33 bubble 0.81 0.81 0.52 0.53 0.47 0.47 matrix 1.03 1.01 0.30 0.30 0.36 0.35 fib0.70 0.68 0.75 0.60 0.53 0.58 Opteron 2GHz (i386 code): no-dynamic no-super dynamic combined? yes no yes noyes no siev 0.46 0.47 0.37 0.36 0.33 0.32 bubble 0.73 0.74 0.50 0.51 0.50 0.51 matrix 0.93 0.95 0.35 0.34 0.31 0.32 fib0.63 0.64 0.49 0.50 0.44 0.45 No-super performs the same number of indirect branches (and anything else) as no-dynamic, but has better branch prediction. Dynamic is like no-super, but eliminates many of the indirect branches. So, overall the instruction combination alone does not make much of a difference on these CPUs. - anton -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug c/20445] garbage returned when trying to get the second word of a double value
--- Additional Comments From sumii at saul dot cis dot upenn dot edu 2005-03-12 21:40 --- (In reply to comment #1) You are violating C aliasing rules, try an union. Read http://gcc.gnu.org/bugs.html which show how to deal with this. Oops, my double stupidity (forgetting the ISO rule _and_ overlooking the FAQ entry)... Apology for bothering you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20445
[Bug fortran/20361] -fmax-stack-var-size=N not working for equivalence
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-12 21:44 --- Subject: Bug 20361 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-12 21:44:44 Modified files: gcc/fortran: ChangeLog trans-array.c trans-array.h trans-common.c trans-decl.c trans.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: largeequiv_1.f90 Log message: fortran/ PR fortran/20361 * trans-array.c (gfc_stack_space_left): Remove unused variable. (gfc_can_put_var_on_stack): Move to trans-decl.c, remove #if 0'ed code. * trans-array.h (gfc_stack_space_left, gfc_can_put_var_on_stack): Remove declaration / prototype. * trans-common.c (build_equiv_decl): Give union a name. Check if it can be put on the stack. * trans-decl.c (gfc_stack_space_left): Move function here. (gfc_build_qualified_array): Fix comment typo. * trans.h (gfc_put_var_on_stack): Add prototype. testsuite/ PR fortran/20361 * gfortran.dg/largeequiv_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.348r2=1.349 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gccr1=1.39r2=1.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.h.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-common.c.diff?cvsroot=gccr1=1.23r2=1.24 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gccr1=1.54r2=1.55 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gccr1=1.23r2=1.24 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5151r2=1.5152 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/largeequiv_1.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20361
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From stevenb at suse dot de 2005-03-12 21:54 --- Subject: Re: [3.3/3.4 regression] pessimization of goto * Combine runs before register allocation. You cannot run it after register allocation. I don't think you can run it twice, even. And no, after register allocation you are not magically going to win back that register. Tough luck. Given your numbers, replacing the reg with its known value might still be a win. But I'm not going to do it ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug fortran/20361] -fmax-stack-var-size=N not working for equivalence
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-12 21:56 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20361
[Bug fortran/20405] [meta-bug] equivalenced variable problems
-- Bug 20405 depends on bug 20361, which changed state. Bug 20361 Summary: -fmax-stack-var-size=N not working for equivalence http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20361 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20405
[Bug fortran/20361] -fmax-stack-var-size=N not working for equivalence
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-12 21:51 --- Subject: Bug 20361 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-12 21:50:51 Modified files: gcc/fortran: ChangeLog trans-array.c trans-array.h trans-common.c trans-decl.c trans.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: largeequiv_1.f90 Log message: fortran/ PR fortran/20361 * trans-array.c (gfc_stack_space_left): Remove unused variable. (gfc_can_put_var_on_stack): Move to trans-decl.c, remove #if 0'ed code. * trans-array.h (gfc_stack_space_left, gfc_can_put_var_on_stack): Remove declaration / prototype. * trans-common.c (build_equiv_decl): Give union a name. Check if it can be put on the stack. * trans-decl.c (gfc_stack_space_left): Move function here. (gfc_build_qualified_array): Fix comment typo. * trans.h (gfc_put_var_on_stack): Add prototype. testsuite/ PR fortran/20361 * gfortran.dg/largeequiv_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.9r2=1.335.2.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.39r2=1.39.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.7r2=1.7.18.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-common.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.23r2=1.23.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.54r2=1.54.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.23r2=1.23.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.37r2=1.5084.2.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/largeequiv_1.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20361
[Bug libfortran/19106] segfault in executable for print *,sum(a,dim=2,mask=a0)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12 22:52 --- The 0 as data pointer is a signal to the library that it needs to fill out the properties of the array, because the front end can't determine it. See http://gcc.gnu.org/ml/fortran/2005-03/msg00199.html http://gcc.gnu.org/ml/fortran/2004-08/msg00050.html http://gcc.gnu.org/ml/fortran/2004-08/msg00017.html http://gcc.gnu.org/ml/fortran/2004-08/msg00019.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |Thomas dot Koenig at online |dot org |dot de Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106
[Bug fortran/20441] -finit-local-zero is missing from gfortran
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-12 22:54:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug libfortran/20406] SIZE() matters?
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-12 23:00 --- Lowered priority to enhancement. While I agree that the standard's definition can be extended to the case of un-associated arrays, this is non-standard after all. Confirmed. -- What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-12 23:00:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20406
[Bug c++/20446] New: gcc-4.0.0 doesn't produce a valid assembler file.
I didn't have this problems using gcc-3.4.2
When I try to compile the file, gcc-4.0.0 reports error which is not reported
by gcc-3.4.2
Info follows:
version of GCC:
sparc-sun-solaris2.8-gcc-4.0.0 (GCC) 4.1.0 20050309 (experimental)
system type:
SunOS 5.8
GCC configure options:
./configure --prefix=/usr/local/toolchain-4.0.0 --with-gnu-as --with-gnu-l
d --enable-languages=c,c++
command line:
g++ -v -save-temps -gstabs+ -fPIC -c -o -DUNIX -DUSING_STLPORT -I/home/lib/S
TLport/stlport sugarconverter.o sugarconverter.cpp
compiler output:
home/lib/STLport/stlport sugarconverter.o sugarconverter.cpp
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with:
../gcc/configure --prefix=/usr/local/toolchain-4.0.0 --with-gnu-as --with-gn
u-ld --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0 20050309 (experimental)
/space/home/usr.local/toolchain-4.0.0/bin/../libexec/gcc/sparc-sun-solaris2.
8/4.1.0/cc1plus -E -quiet -v -I/home/lib/STLport/stlport -iprefix
/space/home/usr.local/toolchain-4.0.0/bin/../lib/gcc/sparc-sun-solaris2.8/4.
1.0/ -DUSING_STLPORT
sugarconverter.cpp -mcpu=v7 -fPIC -fworking-directory -fpch-preprocess -o
sugarconverter.ii
ignoring nonexistent directory
/space/home/usr.local/toolchain-4.0.0/bin/../lib/gcc/sparc-sun-solaris2.8/4
.1.0/../../../../sparc-sun-solaris2.8/include
ignoring duplicate directory
/usr/local/toolchain-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.1.0/../../../../i
nclude/c++/4.1.0
ignoring duplicate directory
/usr/local/toolchain-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.1.0/../../../../i
nclude/c++/4.1.0/sparc-sun-solaris2.8
ignoring duplicate directory
/usr/local/toolchain-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.1.0/../../../../i
nclude/c++/4.1.0/backward
ignoring duplicate directory
/usr/local/toolchain-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.1.0/include
ignoring nonexistent directory
/usr/local/toolchain-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.1.0/../../../../s
parc-sun-solaris2.8/include
#include ... search starts here:
#include ... search starts here:
/home/lib/STLport/stlport
/space/home/usr.local/toolchain-4.0.0/bin/../lib/gcc/sparc-sun-solaris2.8/4.
1.0/../../../../include/c++/4.1.0
/space/home/usr.local/toolchain-4.0.0/bin/../lib/gcc/sparc-sun-solaris2.8/4.
1.0/../../../../include/c++/4.1.0/sparc-sun-solaris2.8
/space/home/usr.local/toolchain-4.0.0/bin/../lib/gcc/sparc-sun-solaris2.8/4.
1.0/../../../../include/c++/4.1.0/backward
/space/home/usr.local/toolchain-4.0.0/bin/../lib/gcc/sparc-sun-solaris2.8/4.
1.0/include
/usr/local/include
/usr/local/toolchain-4.0.0/include
/usr/include
End of search list.
sugarconverter.cpp:4:10: warning: #pragma once in main file
/space/home/usr.local/toolchain-4.0.0/bin/../libexec/gcc/sparc-sun-solaris2.
8/4.1.0/cc1plus -fpreprocessed sugarconverter.ii -quiet -dumpbase
sugarconverter.cpp -mcpu=v7 -auxbase-strip -DUNIX -gstabs+ -version -fPIC -o
sugarconverter.s
GNU C++ version 4.1.0 20050309 (experimental) (sparc-sun-solaris2.8)
compiled by GNU C version 4.0.0 20050221 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/space/home/usr.local/toolchain-4.0.0/bin/../lib/gcc/sparc-sun-solaris2.8/4.
1.0/../../../../sparc-sun-solaris2.8/bin/as -V -Qy -s -K
PIC -xarch=v8 -o -DUNIX sugarconverter.s
GNU assembler version 2.14 (sparc-sun-solaris2.8) using BFD version 2.14
20030612
sugarconverter.s: Assembler messages:
sugarconverter.s:888: Error: can't resolve `.text' {.text section} -
`_ZThn4_N15TSugarConverter5VisitEPK1A'
{.gnu.linkonce.t._ZThn4_N15TSugarConverter5VisitEPK1A section}
distcc[3959] ERROR: compile (NULL) on localhost failed
--
Summary: gcc-4.0.0 doesn't produce a valid assembler file.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivanr at syncad dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug debug/20446] gcc-4.0.0 doesn't produce a valid assembler file.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 23:11 --- Is there a reason why you are using stabs+, the default debuging format on solaris is dwarf-2 which provides more information. -- What|Removed |Added Component|c++ |debug Summary|gcc-4.0.0 doesn't produce a |gcc-4.0.0 doesn't produce a |valid assembler file. |valid assembler file. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug debug/20446] gcc-4.0.0 doesn't produce a valid assembler file.
--- Additional Comments From ivanr at syncad dot com 2005-03-12 23:13 --- Created an attachment (id=8377) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8377action=view) preprocessed and assembler file for sugarconverter.cpp untar and apply this command: g++ -v -save-temps -gstabs+ -fPIC -c -o -DUNIX -DUSING_STLPORT -I/home/lib/S TLport/stlport sugarconverter.o sugarconverter.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug middle-end/20434] pessimization of complex expression
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12 23:13 --- (In reply to comment #6) Well the real reason is creal/cimag returns double and not float. Use crealf/cimagf instead. You're right, of course. Doing that gets me bb 0: foo (cr, ci); return cr + 0.0 + ci + 0.0 0.0; OK, the direct cast has gone away. I wonder if this still converts to double, though... Well yes this is a missed optimization, which should be filed separately. I think using crealf/cimagf pretty much solves this. If you lie to the compiler... :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
[Bug debug/20446] invalid assembly with -gstabs+
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-12 23:15 --- It's 4.1.0 if I read correctly. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Summary|gcc-4.0.0 doesn't produce a |invalid assembly with - |valid assembler file. |gstabs+ Version|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug target/20447] New: ICE in output_operand: invalid expression as operand
$ gcc -O2 bug.c bug.c: In function ‘baz’: bug.c:54: internal compiler error: output_operand: invalid expression as operand fails with 4.0.0 and mainline, might be related to bug 20342. -- Summary: ICE in output_operand: invalid expression as operand Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: belyshev at depni dot sinp dot msu dot ru CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20447
[Bug target/20447] ICE in output_operand: invalid expression as operand
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-03-12 23:24 --- Created an attachment (id=8378) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8378action=view) testcase (1302 bytes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20447
[Bug target/20447] ICE in output_operand: invalid expression as operand
-- What|Removed |Added Keywords||ssemmx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20447
[Bug target/20447] ICE in output_operand: invalid expression as operand
-- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20447
[Bug fortran/20323] optional arguments incorrectly accepted in specification expressions
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2005-03-12 23:37:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20323
[Bug libstdc++/20448] New: locale testsuite fails when GCC is configured with --disable-nls
=== libstdc++ tests === Running target unix FAIL: 22_locale/messages/members/char/1.cc execution test FAIL: 22_locale/messages/members/char/2.cc execution test FAIL: 22_locale/messages/members/char/wrapped_env.cc execution test FAIL: 22_locale/messages/members/char/wrapped_locale.cc execution test FAIL: 22_locale/messages_byname/named_equivalence.cc execution test XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) === libstdc++ Summary === # of expected passes3613 # of unexpected failures5 # of unexpected successes 1 # of expected failures 8 Compiler version: 4.1.0 20050312 (experimental) Platform: i686-pc-linux-gnu configure flags: --with-gnu-as --with-gnu-ld --disable-nls --enable-shared -- prefix=/home/dave/opt/gnu/gcc/gcc-4.1.0 --with-local-prefix=/home/dave/opt/gnu -- enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc= boehm --with-jacks --enable-java-awt=xlib --enable-languages=c,c++,f95,java,objc Probably, the locale tests shouldn't be run when --disable-nls is given. However, I think the actual cause of the fails is the fact that the catalogs aren't built in the po directory when USE_NLS = no. -- Summary: locale testsuite fails when GCC is configured with -- disable-nls Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu, hppa-unknown-linux-gnu GCC host triplet: i686-pc-linux-gnu, hppa-unknown-linux-gnu GCC target triplet: i686-pc-linux-gnu, hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
[Bug other/20449] New: [c++] internal compiler error
# g++ -c libcervisiapart_la.all_cpp.ii \ -O2 -march=i686 -mtune=pentium4 -fno-exceptions repositorydlg.cpp: In member function 'void RepositoryDialog::slotLoginClicked()': repositorydlg.cpp:396: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugs.pld-linux.org/ for instructions. -- Summary: [c++] internal compiler error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at pld-linux dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pld-linux GCC host triplet: i686-pld-linux GCC target triplet: i686-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20449
[Bug other/20449] [c++] internal compiler error
--- Additional Comments From pluto at pld-linux dot org 2005-03-12 23:54 --- Created an attachment (id=8379) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8379action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20449
[Bug fortran/20059] internal compiler error: Segmentation Fault - For common blocks
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-12 23:57 --- Does this still segfault on powerpc? On i686 I get: In file pr20059.f90:10 COMMON /CCPOOL/ RMIN,RMAX,ZMIN,ZMAX,IMIN,JMIN,IMAX,JMAX,NFLOP, 1 Warning: Padding of 4 bytes required before 'htp' in COMMON 'ccpool' at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059
[Bug other/20449] [c++] internal compiler error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 23:59 --- I cannot reproduce this with last nite's mainline or 4.0.0 from 20050225. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20449
[Bug libstdc++/20448] locale testsuite fails when GCC is configured with --disable-nls
--- Additional Comments From pcarlini at suse dot de 2005-03-13 00:01 --- This issue seems related (or maybe we should open a separate PR?) http://gcc.gnu.org/ml/gcc/2004-12/msg01140.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
[Bug fortran/16404] should reject invalid code with -pedantic -std=f95 ? (x8)
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-13 00:04 --- No 2 is PR18870. It also remains No 6. -- What|Removed |Added BugsThisDependsOn||18870 AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16404
[Bug fortran/20059] internal compiler error: Segmentation Fault - For common blocks
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-13 00:06 --- (In reply to comment #2) Does this still segfault on powerpc? On i686 I get: In file pr20059.f90:10 COMMON /CCPOOL/ RMIN,RMAX,ZMIN,ZMAX,IMIN,JMIN,IMAX,JMAX,NFLOP, 1 Warning: Padding of 4 bytes required before 'htp' in COMMON 'ccpool' at (1) This is most likely because building a compiler for i686, HWI is 32bits but for PPC, it is 64bit and because of PR 19387, we don't deal with HWI in the fortran front-end error/warning functions don't understand HWI. (HWI == Host_Wide_int). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059
[Bug other/20449] [c++] internal compiler error
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-03-13 00:12 --- I can reproduce this with --enable-checking mainline. -- What|Removed |Added Keywords||ice-checking, ice-on-valid- ||code Known to fail||4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20449
[Bug libstdc++/20448] locale testsuite fails when GCC is configured with --disable-nls
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-03-13 00:13 --- Subject: Re: locale testsuite fails when GCC is configured with --disable-nls This issue seems related (or maybe we should open a separate PR?) http://gcc.gnu.org/ml/gcc/2004-12/msg01140.html The effect of the missing po files is the same. However, I think there should be a separate PR for the above problem as it's really an issue of not creating the files when they should be created. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
[Bug fortran/20059] internal compiler error: Segmentation Fault - For common blocks
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-13 00:17
---
Can you try this patch, Andrew? The required padding should never overflow
2^32.
2005-03-13 Tobias Schluter [EMAIL PROTECTED]
PR fortran/20059
* trans-common.c (translate_common): Cast offset/common_segment-offset
to type int for warning message.
Index: trans-common.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/trans-common.c,v
retrieving revision 1.24
diff -u -p -r1.24 trans-common.c
--- trans-common.c 12 Mar 2005 21:44:32 - 1.24
+++ trans-common.c 13 Mar 2005 00:15:08 -
@@ -815,7 +815,7 @@ translate_common (gfc_common_head *commo
requirements. Insert padding immediately before this
segment. */
gfc_warning (Padding of %d bytes required before '%s' in
- COMMON '%s' at %L, offset, s-sym-name,
+ COMMON '%s' at %L, (int)offset, s-sym-name,
common-name, common-where);
}
else
@@ -841,7 +841,7 @@ translate_common (gfc_common_head *commo
if (common_segment-offset != 0)
{
gfc_warning (COMMON '%s' at %L requires %d bytes of padding at start,
- common-name, common-where, common_segment-offset);
+ common-name, common-where, (int)common_segment-offset);
}
create_common (common, common_segment);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20059
[Bug libstdc++/20448] locale testsuite fails when GCC is configured with --disable-nls
--- Additional Comments From pcarlini at suse dot de 2005-03-13 00:20 --- Agreed, tomorrow will create one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
[Bug target/19887] g++.dg/warn/weak1.C fails on HPUX
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-13 00:27 --- They are both issues with the HP linker and dynamic loader. In my opinion, they are different issues. Regarding, g++.dg/warn/weak1.C the dynamic loader will not execute an application binary that has undefined symbols. On hppa64-*-hpux11*, it's possible to create an application binary with undefined symbols. However, the dynamic loader will not execute the binary. Thus, the technique of testing the address of a weak function to see if it is defined or not won't work on this target. The failure of gcc.dg/special/weak-1.c on the 32-bit target occurs because the linker selects the weak/secondary definition instead of the primary definition. In my opinion, this is a HP linker bug. -- What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19887
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From marekm at amelek dot gda dot pl 2005-03-13
00:30 ---
Subject: Re: unable to find a register to spill in class `POINTER_REGS'
On Sat, Mar 12, 2005 at 09:20:18PM -, andrewhutchinson at cox dot net wrote:
The pattern only helps if it is a constant. I also thought it should handle
variable block size. However, I found gcc already produces optimal code for
that case without any help.
See below for revised patch (currently for mainline):
- FAIL if count is not a CONST_INT
- handle count == 0 (nothing to do)
- handle count 32767 (negative in RTL, mask with 0x)
- minor formatting fixes
But, I'm still concerned a little about the variable block size:
- __tmp_reg__ will not be used (some other register will)
- more importantly, can the problem from this PR (unable to find a register
to spill in class POINTER_REGS) still occur in the variable size case?
(only with a different, not yet known test case - this means we are
perhaps trying to hide the real bug instead of fixing it...)
If we have to handle the variable count case too, one more insn will
be needed (initially jump to decrementing the counter; test for carry
instead of zero). Some other targets handle this by calling a subroutine
in libgcc.S - smaller (but slower) than generating the loop inline.
Marek
2005-03-12 Andy Hutchinson [EMAIL PROTECTED]
PR target/18251
* config/avr/avr.md (movmemhi): Rewrite as RTL loop.
(*movmemqi_insn): Delete.
(*movmemhi): Delete.
Index: avr.md
===
RCS file: /cvs/gcc/gcc/gcc/config/avr/avr.md,v
retrieving revision 1.50
diff -c -3 -p -r1.50 avr.md
*** avr.md 6 Mar 2005 21:50:36 - 1.50
--- avr.md 12 Mar 2005 23:51:57 -
***
*** 346,421
;;=
;; move string (like memcpy)
(define_expand movmemhi
[(parallel [(set (match_operand:BLK 0 memory_operand )
! (match_operand:BLK 1 memory_operand ))
! (use (match_operand:HI 2 const_int_operand ))
! (use (match_operand:HI 3 const_int_operand ))
! (clobber (match_scratch:HI 4 ))
! (clobber (match_scratch:HI 5 ))
! (clobber (match_dup 6))])]
{
! rtx addr0, addr1;
! int cnt8;
enum machine_mode mode;
if (GET_CODE (operands[2]) != CONST_INT)
FAIL;
- cnt8 = byte_immediate_operand (operands[2], GET_MODE (operands[2]));
- mode = cnt8 ? QImode : HImode;
- operands[6] = gen_rtx_SCRATCH (mode);
- operands[2] = copy_to_mode_reg (mode,
- gen_int_mode (INTVAL (operands[2]), mode));
- addr0 = copy_to_mode_reg (Pmode, XEXP (operands[0], 0));
- addr1 = copy_to_mode_reg (Pmode, XEXP (operands[1], 0));
! operands[0] = gen_rtx_MEM (BLKmode, addr0);
! operands[1] = gen_rtx_MEM (BLKmode, addr1);
})
- (define_insn *movmemqi_insn
- [(set (mem:BLK (match_operand:HI 0 register_operand e))
- (mem:BLK (match_operand:HI 1 register_operand e)))
-(use (match_operand:QI 2 register_operand r))
-(use (match_operand:QI 3 const_int_operand i))
-(clobber (match_scratch:HI 4 =0))
-(clobber (match_scratch:HI 5 =1))
-(clobber (match_scratch:QI 6 =2))]
-
- ld __tmp_reg__,%a1+
- st %a0+,__tmp_reg__
- dec %2
- brne .-8
- [(set_attr length 4)
-(set_attr cc clobber)])
-
- (define_insn *movmemhi
- [(set (mem:BLK (match_operand:HI 0 register_operand e,e))
- (mem:BLK (match_operand:HI 1 register_operand e,e)))
-(use (match_operand:HI 2 register_operand !w,d))
-(use (match_operand:HI 3 const_int_operand ))
-(clobber (match_scratch:HI 4 =0,0))
-(clobber (match_scratch:HI 5 =1,1))
-(clobber (match_scratch:HI 6 =2,2))]
-
- *{
- if (which_alternative==0)
-return (AS2 (ld,__tmp_reg__,%a1+) CR_TAB
- AS2 (st,%a0+,__tmp_reg__) CR_TAB
- AS2 (sbiw,%A2,1) CR_TAB
- AS1 (brne,.-8));
- else
-return (AS2 (ld,__tmp_reg__,%a1+) CR_TAB
- AS2 (st,%a0+,__tmp_reg__) CR_TAB
- AS2 (subi,%A2,1) CR_TAB
- AS2 (sbci,%B2,0) CR_TAB
- AS1 (brne,.-10));
- }
- [(set_attr length 4,5)
-(set_attr cc clobber,clobber)])
-
;; =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0 =0
;; memset (%0, 0, %1)
--- 346,414
;;=
;; move string (like memcpy)
+ ;; implement as RTL loop
(define_expand movmemhi
[(parallel [(set (match_operand:BLK 0 memory_operand )
! (match_operand:BLK 1 memory_operand ))
! (use (match_operand:HI 2 const_int_operand ))
! (use (match_operand:HI 3 const_int_operand ))])]
{
! int prob, count;
enum machine_mode mode;
+ rtx label =
[Bug tree-optimization/13761] [tree-ssa] component refs to the same struct should not alias
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-13 00:46 --- Dale's testcase is now fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
[Bug c/20402] [4.1 regression] gcc.dg/noncompile/920923-1.c ICE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-13 01:10 --- Subject: Bug 20402 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-13 01:09:47 Modified files: gcc: ChangeLog c-parser.c gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg/noncompile: 920923-1.c Log message: PR c/20402 * c-parser.c (c_parser_struct_or_union_specifier): Don't fall through into call to parser_xref_tag after parse error. (c_parser_struct_declaration): Consistently return NULL_TREE on error. testsuite: * gcc.dg/noncompile/920923-1.c: Detail expected diagnostics for new parser. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7809r2=2.7810 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-parser.c.diff?cvsroot=gccr1=2.5r2=2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5153r2=1.5154 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/noncompile/920923-1.c.diff?cvsroot=gccr1=1.5r2=1.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20402
[Bug c/20402] [4.1 regression] gcc.dg/noncompile/920923-1.c ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-13 01:15 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20402
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From andrewhutchinson at cox dot net 2005-03-13
01:19 ---
Subject: Re: unable to find a register to spill in class
`POINTER_REGS'
The concerns have merit but can be discounted:.
The reload problem occurs because the original pattern demands two
pointers in parrallel existence.(Actually two pointers and a
counter!) The current register allocation is imperfect and with this
constraint (and only 3 pointers incl frame) fails to find a solution.
The new RTL expansion does not demand both pointer registers at the same
time - indeed they could be the same register in extreme circumstances.
Breaking up the RTL reveals this to GCC and allows the register
allocator to find a solution. So that is why it works.
The SAME result can also be realised by deleting the offending pattern -
in this situation GCC generates it's own solution which happens to be
identical RTL to the proposed solution (with a 16 bit counter). And
indeed there is no reload failure.
Since the proposed pattern FAILS, the variable case, we will still end
up with GCC's solution and we can conclude there will be no hidden
reload issue. (It should also be noted that a variable count is also
less retrictive on hard register use than a constant).
Now here is the neat bit!. Since GCC middle end generates the detailed
RTL loop, for a variable count, we can and should rely on it to
consider any restriction on the variable (ie variable count=0). If not,
its very very broken.
I was very tempted to submit a patch that just deletes the pattern,
however, that would produce worse code for the very common case where
fixed count255.
I hope this clarifies things.
marekm at amelek dot gda dot pl wrote:
--- Additional Comments From marekm at amelek dot gda dot pl 2005-03-13
00:30 ---
Subject: Re: unable to find a register to spill in class `POINTER_REGS'
On Sat, Mar 12, 2005 at 09:20:18PM -, andrewhutchinson at cox dot net
wrote:
The pattern only helps if it is a constant. I also thought it should handle
variable block size. However, I found gcc already produces optimal code for
that case without any help.
See below for revised patch (currently for mainline):
- FAIL if count is not a CONST_INT
- handle count == 0 (nothing to do)
- handle count 32767 (negative in RTL, mask with 0x)
- minor formatting fixes
But, I'm still concerned a little about the variable block size:
- __tmp_reg__ will not be used (some other register will)
- more importantly, can the problem from this PR (unable to find a register
to spill in class POINTER_REGS) still occur in the variable size case?
(only with a different, not yet known test case - this means we are
perhaps trying to hide the real bug instead of fixing it...)
If we have to handle the variable count case too, one more insn will
be needed (initially jump to decrementing the counter; test for carry
instead of zero). Some other targets handle this by calling a subroutine
in libgcc.S - smaller (but slower) than generating the loop inline.
Marek
2005-03-12 Andy Hutchinson [EMAIL PROTECTED]
PR target/18251
* config/avr/avr.md (movmemhi): Rewrite as RTL loop.
(*movmemqi_insn): Delete.
(*movmemhi): Delete.
Index: avr.md
===
RCS file: /cvs/gcc/gcc/gcc/config/avr/avr.md,v
retrieving revision 1.50
diff -c -3 -p -r1.50 avr.md
*** avr.md 6 Mar 2005 21:50:36 - 1.50
--- avr.md 12 Mar 2005 23:51:57 -
***
*** 346,421
;;=
;; move string (like memcpy)
(define_expand movmemhi
[(parallel [(set (match_operand:BLK 0 memory_operand )
! (match_operand:BLK 1 memory_operand ))
!(use (match_operand:HI 2 const_int_operand ))
!(use (match_operand:HI 3 const_int_operand ))
!(clobber (match_scratch:HI 4 ))
!(clobber (match_scratch:HI 5 ))
!(clobber (match_dup 6))])]
{
! rtx addr0, addr1;
! int cnt8;
enum machine_mode mode;
if (GET_CODE (operands[2]) != CONST_INT)
FAIL;
- cnt8 = byte_immediate_operand (operands[2], GET_MODE (operands[2]));
- mode = cnt8 ? QImode : HImode;
- operands[6] = gen_rtx_SCRATCH (mode);
- operands[2] = copy_to_mode_reg (mode,
- gen_int_mode (INTVAL (operands[2]), mode));
- addr0 = copy_to_mode_reg (Pmode, XEXP (operands[0], 0));
- addr1 = copy_to_mode_reg (Pmode, XEXP (operands[1], 0));
! operands[0] = gen_rtx_MEM (BLKmode, addr0);
! operands[1] = gen_rtx_MEM (BLKmode, addr1);
})
- (define_insn *movmemqi_insn
- [(set (mem:BLK (match_operand:HI 0 register_operand e))
- (mem:BLK (match_operand:HI 1 register_operand e)))
-(use (match_operand:QI 2 register_operand r))
-(use (match_operand:QI 3 const_int_operand i))
-
[Bug middle-end/11375] rtl_dump_file problems in rest_of_compilation
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-13 01:32 --- This open_dump_file change looks like a sufficient solution to me. That prevents us from accidentally trying to open two dump files at the same time. The equivalent problem with close_dump_file is not serious, and unlikely to happen without triggering the open_dump_file abort, so I don't think it needs a solution. -- What|Removed |Added Status|NEW |RESOLVED Known to work||4.0.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From schlie at comcast dot net 2005-03-13 02:06
---
(In reply to comment #20)
with reference to the most recent patch:
- anding with 0x may turn negatives positive so it seems wrong.
- there's no need limit byte counts to below 0x100 for bytes, as 0xFF is a
count as long is it was originally verifed that the integer value is
positive.
And just as a heads up, from when I was fooling a differnt varant, discovered
that (use (match_operand:HI 2 const_int_operand )) apparently
also matches variable operands when compiling avrlibc:
Apparently failing as no code is generated:
../../../../libc/stdlib/realloc.c:154: error: unrecognizable insn:
(insn 235 232 236 31 ../../../../libc/stdlib/realloc.c:151 (parallel [
(set (mem:BLK (reg/v/f:HI 49 [ memp ]) [0 A8])
(mem:BLK (reg/v/f:HI 60 [ ptr ]) [0 A8]))
(use (reg:HI 81 [ variable.sz ]))
(use (const_int 1 [0x1]))
]) -1 (insn_list:REG_DEP_TRUE 232 (nil))
(expr_list:REG_DEAD (reg:HI 81 [ variable.sz ])
(expr_list:REG_DEAD (reg/v/f:HI 49 [ memp ])
(nil
From the following yet another version of Andy's patch:
(and for the hell of it, enclosed at the end, a version which
attempts to handle variable counts, but couldn't figure out
how to get the conditional insertion of a forward branch
label generated correctly:)
- won't emit code unless (count 0).
- removes code for non-constant count moves; as it would have
generated incorrect code for move count = 0.
- allocates a temporary, rather than presuming r0 is safe to use.
(and seems to generate just as good code, as a step to freeing r0)
-- def --
;; move string (like memcpy)
;; implement as RTL loop
(define_expand movmemhi
[(parallel [(set (match_operand:BLK 0 memory_operand )
(match_operand:BLK 1 memory_operand ))
(use (match_operand:HI 2 const_int_operand ))
(use (match_operand:HI 3 const_int_operand ))] )]
{
int cnt8, prob;
enum machine_mode mode;
rtx loop_reg;
rtx label = gen_label_rtx ();
/* Copy pointers into new psuedos - they will be changed. */
rtx addr0 = copy_to_mode_reg (Pmode, XEXP (operands[0], 0));
rtx addr1 = copy_to_mode_reg (Pmode, XEXP (operands[1], 0));
/* If loop count is constant, try to use QImode counter. */
if ((GET_CODE (operands[2]) == CONST_INT) (INTVAL (operands[2]) 0))
{
/* See if constant fit 8 bits. */
cnt8 = byte_immediate_operand (operands[2], GET_MODE (operands[2]));
mode = cnt8 ? QImode : HImode;
/* Create loop counter register. */
loop_reg = copy_to_mode_reg (mode, gen_int_mode (INTVAL (operands[2]),
mode));
/* Create RTL code for move loop, with label at top of loop. */
emit_label (label);
/* Move one byte into scratch and inc pointer. */
rtx tmp_reg = copy_to_mode_reg (QImode, gen_rtx_MEM (QImode, addr1));
emit_move_insn (addr1, gen_rtx_PLUS (Pmode, addr1, const1_rtx));
/* Move scratch into mem, and inc other pointer. */
emit_move_insn (gen_rtx_MEM (QImode, addr0), tmp_reg);
emit_move_insn (addr0, gen_rtx_PLUS (Pmode, addr0, const1_rtx));
/* Decrement count. */
emit_move_insn (loop_reg, gen_rtx_PLUS (mode, loop_reg, constm1_rtx));
/* Compare with zero and jump if not equal. */
emit_cmp_and_jump_insns (loop_reg, const0_rtx, NE, NULL_RTX, mode, 1,
label);
/* Set jump probability based on loop count. */
rtx jump = get_last_insn ();
prob = REG_BR_PROB_BASE - (REG_BR_PROB_BASE / INTVAL (operands[2]));
REG_NOTES (jump) = gen_rtx_EXPR_LIST (REG_BR_PROB, GEN_INT (prob),
REG_NOTES (jump));
DONE;
}})
This time attempting to handle variable counts:
;; move string (like memcpy)
;; implement as RTL loop
(define_expand movmemhi
[(parallel [(set (match_operand:BLK 0 memory_operand )
(match_operand:BLK 1 memory_operand ))
(use (match_operand:HI 2 const_int_operand ))
(use (match_operand:HI 3 const_int_operand ))] )]
{
enum machine_mode mode = HImode;
int prob = (REG_BR_PROB_BASE * 95) / 100;
rtx test_label = 0; /* Initial no-test value. */
/* Specify default variable loop count initial value. */
rtx loop_cnt = copy_to_mode_reg (mode, operands[2]);
/* Only generate code for variable, or constant counts != 0. */
if ((GET_CODE (operands[2]) == CONST_INT) (INTVAL (operands[2]) == 0))
goto done;
if (GET_CODE (operands[2]) == CONST_INT) /* A constant count. */
{
/* Adjust loop count mode size as a function of const size. */
if (byte_immediate_operand (operands[2], GET_MODE (operands[2])))
{
mode = QImode;
}
/* Adjust jump probability based on known loop count. */
prob = REG_BR_PROB_BASE - (REG_BR_PROB_BASE / INTVAL (operands[2]));
/*
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From andrewhutchinson at cox dot net 2005-03-13
02:44 ---
Subject: Re: unable to find a register to spill in class
`POINTER_REGS'
This is a define EXPAND. predicates (such as const_int_operand) and
pattern have no effect at all on generated code or matching. This
pattern always emits DONE or FAIL.
That is why you need to test operand in body.
And with ox is wrong. As is trying to handle the variable count
case. That is fixing something that is not broke.
So looks like my patch is ok?
schlie at comcast dot net wrote:
--- Additional Comments From schlie at comcast dot net 2005-03-13 02:06
---
(In reply to comment #20)
with reference to the most recent patch:
- anding with 0x may turn negatives positive so it seems wrong.
- there's no need limit byte counts to below 0x100 for bytes, as 0xFF is a
count as long is it was originally verifed that the integer value is
positive.
And just as a heads up, from when I was fooling a differnt varant, discovered
that (use (match_operand:HI 2 const_int_operand )) apparently
also matches variable operands when compiling avrlibc:
Apparently failing as no code is generated:
../../../../libc/stdlib/realloc.c:154: error: unrecognizable insn:
(insn 235 232 236 31 ../../../../libc/stdlib/realloc.c:151 (parallel [
(set (mem:BLK (reg/v/f:HI 49 [ memp ]) [0 A8])
(mem:BLK (reg/v/f:HI 60 [ ptr ]) [0 A8]))
(use (reg:HI 81 [ variable.sz ]))
(use (const_int 1 [0x1]))
]) -1 (insn_list:REG_DEP_TRUE 232 (nil))
(expr_list:REG_DEAD (reg:HI 81 [ variable.sz ])
(expr_list:REG_DEAD (reg/v/f:HI 49 [ memp ])
(nil
From the following yet another version of Andy's patch:
(and for the hell of it, enclosed at the end, a version which
attempts to handle variable counts, but couldn't figure out
how to get the conditional insertion of a forward branch
label generated correctly:)
- won't emit code unless (count 0).
- removes code for non-constant count moves; as it would have
generated incorrect code for move count = 0.
- allocates a temporary, rather than presuming r0 is safe to use.
(and seems to generate just as good code, as a step to freeing r0)
-- def --
;; move string (like memcpy)
;; implement as RTL loop
(define_expand movmemhi
[(parallel [(set (match_operand:BLK 0 memory_operand )
(match_operand:BLK 1 memory_operand ))
(use (match_operand:HI 2 const_int_operand ))
(use (match_operand:HI 3 const_int_operand ))] )]
{
int cnt8, prob;
enum machine_mode mode;
rtx loop_reg;
rtx label = gen_label_rtx ();
/* Copy pointers into new psuedos - they will be changed. */
rtx addr0 = copy_to_mode_reg (Pmode, XEXP (operands[0], 0));
rtx addr1 = copy_to_mode_reg (Pmode, XEXP (operands[1], 0));
/* If loop count is constant, try to use QImode counter. */
if ((GET_CODE (operands[2]) == CONST_INT) (INTVAL (operands[2]) 0))
{
/* See if constant fit 8 bits. */
cnt8 = byte_immediate_operand (operands[2], GET_MODE (operands[2]));
mode = cnt8 ? QImode : HImode;
/* Create loop counter register. */
loop_reg = copy_to_mode_reg (mode, gen_int_mode (INTVAL (operands[2]),
mode));
/* Create RTL code for move loop, with label at top of loop. */
emit_label (label);
/* Move one byte into scratch and inc pointer. */
rtx tmp_reg = copy_to_mode_reg (QImode, gen_rtx_MEM (QImode, addr1));
emit_move_insn (addr1, gen_rtx_PLUS (Pmode, addr1, const1_rtx));
/* Move scratch into mem, and inc other pointer. */
emit_move_insn (gen_rtx_MEM (QImode, addr0), tmp_reg);
emit_move_insn (addr0, gen_rtx_PLUS (Pmode, addr0, const1_rtx));
/* Decrement count. */
emit_move_insn (loop_reg, gen_rtx_PLUS (mode, loop_reg, constm1_rtx));
/* Compare with zero and jump if not equal. */
emit_cmp_and_jump_insns (loop_reg, const0_rtx, NE, NULL_RTX, mode, 1,
label);
/* Set jump probability based on loop count. */
rtx jump = get_last_insn ();
prob = REG_BR_PROB_BASE - (REG_BR_PROB_BASE / INTVAL (operands[2]));
REG_NOTES (jump) = gen_rtx_EXPR_LIST (REG_BR_PROB, GEN_INT (prob),
REG_NOTES (jump));
DONE;
}})
This time attempting to handle variable counts:
;; move string (like memcpy)
;; implement as RTL loop
(define_expand movmemhi
[(parallel [(set (match_operand:BLK 0 memory_operand )
(match_operand:BLK 1 memory_operand ))
(use (match_operand:HI 2 const_int_operand ))
(use (match_operand:HI 3 const_int_operand ))] )]
{
enum machine_mode mode = HImode;
int prob = (REG_BR_PROB_BASE * 95) / 100;
rtx test_label = 0; /* Initial no-test value. */
/* Specify default variable loop count initial value. */
rtx loop_cnt =
[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-13 03:11 --- Dan's example doesn't work because 'int' is a predefined type. Use a unique structure type put the function call back in the inline function, and I get a nice little example (22 lines) that can reproduce the problem. If I compile it with ./xgcc -B./ -O -g tmp.cc and then run gdb on the a.out file, I get a gdb internal error. Looking at the debug info, I now have 4 DIEs for the variable i. There are the same 3 as Dan's example, plus a fourth one, with global scope, that has the abstract origin pointing back at the declaration inside the inline function. It is this fourth one that confuses gdb. This is using mainline, last updated Thursday March 10, on an x86-64 linux machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769
[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
--- Additional Comments From drow at false dot org 2005-03-13 03:36 --- Subject: Re: [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb Hmm, I can't reproduce the error using mainline for i386-linux, and several versions of GDB. Could you attach readelf -wi output for the file which does cause gdb to crash? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From schlie at comcast dot net 2005-03-13 03:39 --- (In reply to comment #23) This is a define EXPAND. predicates (such as const_int_operand) and pattern have no effect at all on generated code or matching. This pattern always emits DONE or FAIL. That is why you need to test operand in body. - thanks, understood. And with ox is wrong. As is trying to handle the variable count case. That is fixing something that is not broke. So looks like my patch is ok? - how about in the case of a variable count = 0 ? (or since only constants are handled, it falls back to letting gcc figure it out?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From andrewhutchinson at cox dot net 2005-03-13 04:05 --- Subject: Re: unable to find a register to spill in class `POINTER_REGS' You answered your own question. GCC handles variable moves just like anything else. Dealing with range of possible values and size etc and construct appropriate RTL. GCC does not need this backend define or expand. It is quite happy working out moves by itself. The pattern is *only* defined when the target can do a better job - i.e. when we have a constant byte count - but not otherwise. I have found it's a really bad idea to second guess compiler optimisations. - how about in the case of a variable count = 0 ? (or since only constants are handled, it falls back to letting gcc figure it out?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug target/20360] 20021014-1.c fails on account of unsupported build option
--- Additional Comments From tprince at computer dot org 2005-03-13 04:07 --- Subject: Re: 20021014-1.c fails on account of unsupported build option At 09:28 AM 3/12/2005, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-12 17:28 --- (In reply to comment #2) If I understand the purpose of the test, it was to check whether profiling is working correctly, as far as being capable of building and running without a failure report. I've not found an explanation why certain targets, like cygwin, support only -pg, others only -p, and others both. The main point is to stop reporting a spurious error when running the testsuite. No it is just testing -p and not -pg, there is a difference but I don't remember what. IIRC, the original code generation problem for which the test was instituted was the same for -p and -pg, for those targets which support both. Certain targets support only one or the other at link time, and choosing the wrong one produces a link time error. I don't care whether the policy is to disable the test for targets which don't support -p, or to switch over to -pg. I think general policy is to not declare a failure for a test which can't be supported for the target, and that policy should extend to cygwin. Tim Prince -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20360
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From schlie at comcast dot net 2005-03-13 04:17 --- (In reply to comment #25) Subject: Re: unable to find a register to spill in class `POINTER_REGS' ... GCC does not need this backend define or expand. It is quite happy working out moves by itself. - thanks again, sound's good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
[Bug other/20449] [c++] internal compiler error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-13 05:20 --- This is a dup of bug 20225. I don't know why I cannot reproduce this. *** This bug has been marked as a duplicate of 20225 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20449
[Bug middle-end/20225] [4.0/4.1 regression] ICE during GC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-13 05:20 --- *** Bug 20449 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||pluto at pld-linux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20225
[Bug debug/20446] invalid assembly with -gstabs+
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-13 05:31 --- This is most likely the same problem as PR 18170, the error messages are similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
[Bug c/17426] Emit mandatory warning for manual expansions of offsetof
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-12-12 01:43:40 |2005-03-13 05:37:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17426
[Bug c/17426] Emit mandatory warning for manual expansions of offsetof
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-13 05:38 --- A note here, glibc and a couple of other projects would have been helped by this warning as they have code which uses the manual expansion of offsetof. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17426
[Bug rtl-optimization/20450] New: ICE in postreload-gcse
postreload-gcse ICEs when trying to generate an illegal move insn between registers. This happens when compiling vpr on G5 with -fprofile-generate (gcc -O3 -fprofile-generate -mcpu=G5). I made a smaller test-case that causes the same failure. compiling the following code with -- Summary: ICE in postreload-gcse Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: mustafa at il dot ibm dot com ReportedBy: mustafa at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.6.0 GCC host triplet: powerpc-apple-darwin7.6.0 GCC target triplet: powerpc-apple-darwin7.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20450
