toplevel *again* out of sync
I hate to say this when I don't have the time to fix it myself, but toplevel of gcc and src is once more out of sync, and this is bad. I think that we should apply a *very* strict policy of not approving toplevel patches unless the toplevel files are in sync. Thanks in advance to anyone that volunteers to fix things... Paolo
Re: toplevel *again* out of sync
Hi Paolo, * Paolo Bonzini wrote on Sat, Oct 02, 2010 at 10:47:18AM CEST: I think that we should apply a *very* strict policy of not approving toplevel patches unless the toplevel files are in sync. Thanks in advance to anyone that volunteers to fix things... You beat me by a couple of hours. I'll fix it later today, it's only a couple of patches (not from me though). Cheers, Ralf
make recheck?
Is there a way to rerun only failed tests after a 'make -k check'? If not, should there be, and how would one go about implementing this (I know the makefile parts but not the dejagnu bits). Asking because it could help speed up patch development: 1) hack hack hack 2) make -k check-$whatever 3) go back to (1) until satisfactory 4) git commit patch, undo patch in work tree, rebuild 5) run 'make recheck' to ensure all new failures were already old. This doesn't satisfy patch submission rules, but for patch series development it might, in stages before actually submitting. Thanks, Ralf
Re: toplevel *again* out of sync
This is how things look like currently:
There are five patches in GCC not in src, four for toplevel and one for
config/; there are no patches in src not in GCC. There is one
problematic sync.
Not in src:
b9a8e4c49ae2f195c2c0c4646a75f33ff926986f aka r162482
4ae8c98f346e631b735be15b09a41a1a043454d2 aka r163839
62932e4dc2db82e1bdef5e2afbad33154bb8d5f2 aka r164481
d34b0d1e4502f0a0879adac335534686cc5b550a aka r164756
The combined patch for the above four is at the end of this message.
The following patch has been committed to GCC and to src, but the two
commits are not identical, and the commit to src is lacking a ChangeLog
entry:
65b688d722ec8d604aa6e37a7fa16eb21c72fd8c aka r162530 aka
| 2010-07-26 Naveen.H.S navee...@kpitcummins.com
|
| * configure.ac: Support all v850 targets.
| * configure: Regenerate.
Nick, Naveen, the diff between the GCC and the src commits is this;
which variant is correct?
| --- gcc/configure.ac2010-10-02 09:33:07.0 +0200
| +++ src/configure.ac2010-10-02 14:20:36.0 +0200
| @@ -968,7 +968,7 @@
| noconfigdirs=$noconfigdirs bfd binutils gas gcc gdb ld
target-libstdc++-v3 opcodes target-libgloss ${libgcj}
| ;;
|v850*-*-*)
| -noconfigdirs=$noconfigdirs target-libgloss ${libgcj}
| +noconfigdirs=$noconfigdirs ${libgcj}
| ;;
|vax-*-vms)
| noconfigdirs=$noconfigdirs bfd binutils gdb ld target-newlib opcodes
target-libgloss ${libgcj}
|
Please fix the wrong side, and fix src/ChangeLog. Thanks.
Other than that, below is the combined patch I intend to commit to src
unless there are disagreements.
Thanks,
Ralf
ChangeLog:
2010-10-02 Ralf Wildenhues ralf.wildenh...@gmx.de
Sync from GCC:
2010-09-30 Michael Eager ea...@eagercon.com
* configure.ac (microblaze): Add target-libssp to noconfigdirs.
* configure: Regenerate.
2010-09-21 Iain Sandoe ia...@gcc.gnu.org
* configure.ac (enable-lto): Add Darwin to the list of supported lto
targets and amend comment.
* configure: Regenerate.
2010-09-03 Jack Howarth howa...@bromo.med.uc.edu
* configure.ac: Enable LTO by default on Darwin.
* configure: Regenerate.
2010-07-23 Marc Glisse marc.gli...@normalesup.org
PR bootstrap/44455
* configure.ac (extra_mpfr_configure_flags): Copy from
extra_mpc_gmp_configure_flags.
* configure: Re-generated.
config/ChangeLog:
2010-10-02 Ralf Wildenhues ralf.wildenh...@gmx.de
Sync from GCC:
2010-09-10 Jonathan Yong jo...@users.sourceforge.net
* dfp.m4: Enable decimal float for i?86 cygwin
and mingw, and for x86_64 mingw.
Index: configure.ac
===
RCS file: /cvs/src/src/configure.ac,v
retrieving revision 1.106
diff -u -r1.106 configure.ac
--- configure.ac27 Sep 2010 20:22:46 - 1.106
+++ configure.ac2 Oct 2010 12:33:36 -
@@ -887,7 +887,7 @@
noconfigdirs=$noconfigdirs ld binutils gprof target-libgloss ${libgcj}
;;
microblaze*)
-noconfigdirs=$noconfigdirs gprof ${libgcj}
+noconfigdirs=$noconfigdirs gprof target-libssp ${libgcj}
;;
mips*-sde-elf*)
skipdirs=$skipdirs target-libiberty
@@ -1348,7 +1348,7 @@
if test x$with_gmp$with_gmp_include$with_gmp_lib = x test -d
${srcdir}/gmp; then
gmplibs='-L$$r/$(HOST_SUBDIR)/gmp/'$lt_cv_objdir $gmplibs
gmpinc='-I$$r/$(HOST_SUBDIR)/gmp -I$$s/gmp '$gmpinc
- extra_mpfr_configure_flags='--with-gmp-build=$$r/$(HOST_SUBDIR)/gmp'
+ extra_mpfr_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp
--with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/'$lt_cv_objdir
extra_mpc_gmp_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp
--with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/'$lt_cv_objdir
# Do not test the gmp version. Assume that it is sufficient, since
# it is in the source tree, and the library has not been built yet
@@ -1787,17 +1787,19 @@
AC_SUBST(libelflibs)
AC_SUBST(libelfinc)
fi],[if test x$default_enable_lto = xyes ; then
-# On non-ELF platforms, LTO must be explicitly enabled.
-enable_lto=no
+case $target in
+ *-apple-darwin*) ;;
+ # On other non-ELF platforms, LTO must be explicitly enabled.
+ *) enable_lto=no ;;
+esac
else
- # Apart from ELF platforms, only Windows supports LTO so far. It
- # would also be nice to check the binutils support, but we don't
+ # Apart from ELF platforms, only Windows and Darwin support LTO so far.
+ # It would also be nice to check the binutils support, but we don't
# have gcc_GAS_CHECK_FEATURE available here. For now, we'll just
# warn during gcc/ subconfigure; unless you're bootstrapping with
# -flto it won't be needed until after installation anyway.
case $target in
- *-cygwin*|*-mingw*) ;;
- *-apple-darwin*) ;;
+ *-cygwin*|*-mingw* | *-apple-darwin*) ;;
*) if test
Re: toplevel *again* out of sync
Other than that, below is the combined patch I intend to commit to src unless there are disagreements. Ok, thanks. DJ, can you amend your scripts so that the head of gcc/ChangeLog and src/ChangeLog is included? This will make it easier to bug relevant people. Paolo
Re: make recheck?
On Sat, Oct 2, 2010 at 5:54 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Is there a way to rerun only failed tests after a 'make -k check'? If not, should there be, and how would one go about implementing this (I know the makefile parts but not the dejagnu bits). Asking because it could help speed up patch development: 1) hack hack hack 2) make -k check-$whatever 3) go back to (1) until satisfactory 4) git commit patch, undo patch in work tree, rebuild 5) run 'make recheck' to ensure all new failures were already old. This doesn't satisfy patch submission rules, but for patch series development it might, in stages before actually submitting. Thanks, Ralf I know there's a way to run a specific exp file, and a specific test from that file: RUNTESTFLAGS=file.exp RUNTESTFLAGS=file.exp=test Something like that. That's not entirely what you want, though.
Re: make recheck?
* NightStrike wrote on Sat, Oct 02, 2010 at 05:47:24PM CEST: On Sat, Oct 2, 2010 at 5:54 AM, Ralf Wildenhues wrote: Is there a way to rerun only failed tests after a 'make -k check'? If not, should there be, and how would one go about implementing this (I know the makefile parts but not the dejagnu bits). I know there's a way to run a specific exp file, and a specific test from that file: RUNTESTFLAGS=file.exp RUNTESTFLAGS=file.exp=test Something like that. That's not entirely what you want, though. Well, I'd like a reverse mapping from the failures in recorded *.log files to a set of RUNTESTFLAGS arguments to pass. That's how we implemented 'recheck' in Autotest and in the Automake parallel-tests driver. Ahh, maybe some sed scripting is enough to there though ... Thanks, Ralf
Re: make recheck?
On Sat, Oct 2, 2010 at 05:54, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Asking because it could help speed up patch development: 1) hack hack hack 2) make -k check-$whatever 3) go back to (1) until satisfactory 4) git commit patch, undo patch in work tree, rebuild 5) run 'make recheck' to ensure all new failures were already old. This sounds like a great idea. You'd need to extract the FAIL lines from the .log file and backtrack to figure out which .exp file produced them. This would give you the input for RUNTESTFLAGS=f.exp=... I don't recall if you can specify more than one file in the RUNTESTFLAGS argument, though. Diego.
Re: Range-based for in c++98
2010/10/1 Jason Merrill ja...@redhat.com:
It took me some searching, but yes, it does:
A type-specifier-seq shall not define a class or enumeration unless it
appears in the type-id of an alias-declaration (7.1.3).
Normal declarations don't have a type-specifier-seq, they have a
decl-specifier-seq.
No wonder I couldn't find it!
I would change cp_parser_range_for to use cp_parser_decl_specifier_seq
instead of cp_parser_type_specifier_seq and then wait to complain about
defining a type until after we've seen the ':'.
I already tried that, but it didn't work. It seemed to me that it was
because it called cp_parser_commit_to_tentative_parse(), and if then I
wanted to roll-back the parsing of the range-for, I went badly. I had
to agree with Manuel that the tentative parsing is a bit messy...
But, I managed to solve this particual issue with the following patch
(no improvement in the error messages, however):
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 164871)
+++ gcc/cp/parser.c (working copy)
@@ -8644,21 +8644,13 @@ cp_parser_range_for (cp_parser *parser)
tree stmt, range_decl, range_expr;
cp_decl_specifier_seq type_specifiers;
cp_declarator *declarator;
- const char *saved_message;
tree attributes, pushed_scope;
cp_parser_parse_tentatively (parser);
- /* New types are not allowed in the type-specifier-seq for a
- range-based for loop. */
- saved_message = parser-type_definition_forbidden_message;
- parser-type_definition_forbidden_message
-= G_(types may not be defined in range-based for loops);
/* Parse the type-specifier-seq. */
cp_parser_type_specifier_seq (parser, /*is_declaration==*/true,
- /*is_trailing_return=*/false,
+ /*is_trailing_return=*/true,
type_specifiers);
- /* Restore the saved message. */
- parser-type_definition_forbidden_message = saved_message;
/* If all is well, we might be looking at a declaration. */
if (cp_parser_error_occurred (parser))
{
Admittedly, this is not a trailing_return_type, but AFAICT it has
exactly the same restrictions. Maybe renaming the parameter would be a
good idea.
Regards.
Rodrigo
[rfc] stack alignment macro cleanup
Currently we have STACK_BOUNDARY -- minimum alignment enforced by hardware. PREFERRED_STACK_BOUNDARY -- a preserved alignment greater than what the hw enforces (defaults to STACK_BOUNDARY) INCOMING_STACK_BOUNDARY -- an alignment provided by callers on function entry. (defaults to PREFERRED_STACK_BOUNDARY) MIN_STACK_BOUNDARY (undocumented; local to i386 atm) -- appears to be the ABI specified stack boundary, i.e. the minimum that must be in place at a call site. This somehow differs from I_S_B due to proliferation of command-line options. MAX_STACK_ALIGNMENT -- biggest stack alignment guaranteed by the backend. (defaults to STACK_BOUNDARY, @c sez ought to be P_S_B) MAX_SUPPORTED_STACK_ALIGNMENT (undocumented; defined solely by defaults.h) -- the same as M_S_A, but with the P_S_B default. I would like to reduce this to STACK_BOUNDARY -- unchanged INCOMING_STACK_BOUNDARY -- default to S_B; x86 backend drops MIN_S_B. MAX_STACK_BOUNDARY -- default to I_S_B. and delete many of the x86 backend options that fiddle stuff that users ought not be fiddling. Like forcing the use of DRAP register. Thoughts? r~
gcc-4.6-20101002 is now available
Snapshot gcc-4.6-20101002 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101002/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 164908 You'll find: gcc-4.6-20101002.tar.bz2 Complete GCC (includes all of below) MD5=4066c6774584c697fc6d91b21dbfa46f SHA1=7a20fc478638ffcd283306c22f530b810dd8d280 gcc-core-4.6-20101002.tar.bz2C front end and core compiler MD5=c9579385729be1299eae0a22a8cd527b SHA1=3b4ef93b70afa9934bded4c164ed648a177e31ec gcc-ada-4.6-20101002.tar.bz2 Ada front end and runtime MD5=c284c8e3ac2c35b6db49e93591c541f3 SHA1=ff16f7eb3d6fbcd5f21323f5e1efaa87a17f647d gcc-fortran-4.6-20101002.tar.bz2 Fortran front end and runtime MD5=771dbf6bbec828cbd31669f6f94587ab SHA1=9f729eb34e689e458f500278b88d9e88de6c522e gcc-g++-4.6-20101002.tar.bz2 C++ front end and runtime MD5=ebaaf3ac1350a1040fb801d396b1119d SHA1=ad07d73791819f3c88cfee4a4f9ce06d6d4d8a26 gcc-java-4.6-20101002.tar.bz2Java front end and runtime MD5=d9d9673a0f2ca6b6410c80671044552d SHA1=0f4650ebe7f12c843be2f3428be3150c9170a1e2 gcc-objc-4.6-20101002.tar.bz2Objective-C front end and runtime MD5=2a0ae098848c12df00a8db9751a40509 SHA1=b54cc7bc9a117fde30f8e9a96d77bdced744fc9d gcc-testsuite-4.6-20101002.tar.bz2 The GCC testsuite MD5=23a0d9581d1a67b2f36eb9bef6abab0d SHA1=57589d5586ca8f1ef9d27f906bb5752ffaaba9d4 Diffs from 4.6-20100925 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [rfc] stack alignment macro cleanup
On Sat, Oct 2, 2010 at 1:01 PM, Richard Henderson r...@redhat.com wrote: Currently we have STACK_BOUNDARY -- minimum alignment enforced by hardware. PREFERRED_STACK_BOUNDARY -- a preserved alignment greater than what the hw enforces (defaults to STACK_BOUNDARY) INCOMING_STACK_BOUNDARY -- an alignment provided by callers on function entry. (defaults to PREFERRED_STACK_BOUNDARY) MIN_STACK_BOUNDARY (undocumented; local to i386 atm) -- appears to be the ABI specified stack boundary, i.e. the minimum that must be in place at a call site. This somehow differs from I_S_B due to proliferation of command-line options. It is used to implement -mstackreliagn. I think you should just move it to i386.c. Otherwise, you have to copy the same logic to where it is used in i386.c. MAX_STACK_ALIGNMENT -- biggest stack alignment guaranteed by the backend. (defaults to STACK_BOUNDARY, @c sez ought to be P_S_B) MAX_SUPPORTED_STACK_ALIGNMENT (undocumented; defined solely by defaults.h) -- the same as M_S_A, but with the P_S_B default. I would like to reduce this to STACK_BOUNDARY -- unchanged INCOMING_STACK_BOUNDARY -- default to S_B; x86 backend drops MIN_S_B. On ia32, INCOMING_STACK_BOUNDARY may be different from PREFERRED_STACK_BOUNDARY. It is used to support linking against libraries with 4byte incoming stack boundary and generate 16byte outgoing stack boundary. MAX_STACK_BOUNDARY -- default to I_S_B. and delete many of the x86 backend options that fiddle stuff that users ought not be fiddling. Like forcing the use of DRAP register. -mdrap is mainly for testing purpose and used in testsuite. It has caught many bugs. Removing it means regressions may become latent. -- H.J.
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062 --- Comment #18 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-02 06:44:41 UTC --- (In reply to comment #16) Interpretation request for the June J3 meeting: http://j3-fortran.org/doc/meeting/192/10-146.txt Proposed edit is to allow ALLOCATABLEs. (In reply to comment #17) Any further direction on this? Updated IR: http://j3-fortran.org/doc/meeting/192/10-146r1.txt Status at the meeting: http://j3-fortran.org/doc/meeting/193/10-198.txt 0. List of papers passed at meeting #192 The interpretations passed by this meeting were: [...] F08/0002 == 10-146r1 [...]
[Bug libmudflap/38339] libtool: compile: not configured to build any kind of library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38339 --- Comment #19 from Gabor Z. Papp gzp at papp dot hu 2010-10-02 06:56:43 UTC --- (In reply to comment #15) make configure-target-libmudflap make: *** No rule to make target `configure-target-libmudflap'. Stop.
[Bug libmudflap/38339] libtool: compile: not configured to build any kind of library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38339 --- Comment #20 from Gabor Z. Papp gzp at papp dot hu 2010-10-02 06:58:38 UTC --- (In reply to comment #19) make configure-target-libmudflap make: *** No rule to make target `configure-target-libmudflap'. Stop. My bad. I'm building gcc in ./obj So running make configure-target-libmudflag in obj: $ make configure-target-libmudflap Checking multilib configuration for libmudflap...
[Bug libmudflap/38339] libtool: compile: not configured to build any kind of library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38339 --- Comment #23 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-10-02 07:13:39 UTC --- The 'make configure-target-libmudflap' log you just sent does not show the 'expr syntax error' failures from the log.make in comment 1 any more. Can you please verify that your build error is gone now also? Should be sufficient to make all-target-libmudflap Thanks.
[Bug libmudflap/38339] libtool: compile: not configured to build any kind of library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38339 --- Comment #24 from Gabor Z. Papp gzp at papp dot hu 2010-10-02 07:17:33 UTC --- (In reply to comment #23) The 'make configure-target-libmudflap' log you just sent does not show the 'expr syntax error' failures from the log.make in comment 1 any more. Can you please verify that your build error is gone now also? Should be sufficient to make all-target-libmudflap Yes: $ make all-target-libmudflap Checking multilib configuration for libmudflap... make[1]: Entering directory `/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libmudflap' make AR_FLAGS=rc CC_FOR_BUILD=gcc CFLAGS=-g -O2 CXXFLAGS=-g -O2 -D_GNU_SOURCE CFLAGS_FOR_BUILD=-g -O2 CFLAGS_FOR_TARGET=-g -O2 INSTALL=/pkg/bin/install -c INSTALL_DATA=/pkg/bin/install -c -m 644 INSTALL_PROGRAM=/pkg/bin/install -c INSTALL_SCRIPT=/pkg/bin/install -c JC1FLAGS= LDFLAGS= LIBCFLAGS=-g -O2 LIBCFLAGS_FOR_TARGET=-g -O2 MAKE=make MAKEINFO=makeinfo --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh RUNTESTFLAGS= exec_prefix=/pkg infodir=/pkg/info libdir=/pkg/lib prefix=/pkg includedir=/pkg/include AR=ar AS=/home/gzp/src/gcc-4.4.5/obj/./gcc/as CC=/home/gzp/src/gcc-4.4.5/obj/./gcc/xgcc -B/home/gzp/src/gcc-4.4.5/obj/./gcc/ -B/pkg/i686-pc-linux-gnu/bin/ -B/pkg/i686-pc-linux-gnu/lib/ -isystem /pkg/i686-pc-linux-gnu/include -isystem /pkg/i686-pc-linux-gnu/sys-include CXX=/home/gzp/src/gcc-4.4.5/obj/./gcc/g++ -B/home/gzp/src/gcc-4.4.5/obj/./gcc/ -nostdinc++ -nostdinc++ -I/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libstdc++-v3/include -I/home/gzp/src/gcc-4.4.5/libstdc++-v3/libsupc++ -I/home/gzp/src/gcc-4.4.5/libstdc++-v3/include/backward -I/home/gzp/src/gcc-4.4.5/libstdc++-v3/testsuite/util -L/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libstdc++-v3/src -L/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/pkg/i686-pc-linux-gnu/bin/ -B/pkg/i686-pc-linux-gnu/lib/ -isystem /pkg/i686-pc-linux-gnu/include -isystem /pkg/i686-pc-linux-gnu/sys-include LD=/home/gzp/src/gcc-4.4.5/obj/./gcc/collect-ld LIBCFLAGS=-g -O2 NM=/home/gzp/src/gcc-4.4.5/obj/./gcc/nm PICFLAG= RANLIB=ranlib DESTDIR= all-recursive make[2]: Entering directory `/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libmudflap' Making all in testsuite make[3]: Entering directory `/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libmudflap/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libmudflap/testsuite' make[3]: Entering directory `/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libmudflap' if /bin/sh ./libtool --tag=CC --mode=compile /home/gzp/src/gcc-4.4.5/obj/./gcc/xgcc -B/home/gzp/src/gcc-4.4.5/obj/./gcc/ -B/pkg/i686-pc-linux-gnu/bin/ -B/pkg/i686-pc-linux-gnu/lib/ -isystem /pkg/i686-pc-linux-gnu/include -isystem /pkg/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../libmudflap -I.-Wall -ffunction-sections -fdata-sections -g -O2 -MT mf-runtime.lo -MD -MP -MF .deps/mf-runtime.Tpo -c -o mf-runtime.lo ../../../libmudflap/mf-runtime.c; \ then mv -f .deps/mf-runtime.Tpo .deps/mf-runtime.Plo; else rm -f .deps/mf-runtime.Tpo; exit 1; fi libtool: compile: not configured to build any kind of library libtool: compile: See the libtool documentation for more information. libtool: compile: Fatal configuration error. make[3]: *** [mf-runtime.lo] Error 1 make[3]: Leaving directory `/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libmudflap' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libmudflap' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/gzp/src/gcc-4.4.5/obj/i686-pc-linux-gnu/libmudflap' make: *** [all-target-libmudflap] Error 2
[Bug fortran/42831] Unnecessary array temporary produced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42831 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-10-02 08:00:55 UTC --- Author: tkoenig Date: Sat Oct 2 08:00:50 2010 New Revision: 164900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164900 Log: 2010-10-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/42831 * gfortran.dg/dependency_37.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_37.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/42831] Unnecessary array temporary produced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42831 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-10-02 08:06:21 UTC --- Test case committed. Closing.
[Bug fortran/45748] [4.5/4.6 Regression] -fimplicit-none failures when using intrinsic MAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45748
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||janus at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #5 from janus at gcc dot gnu.org 2010-10-02 08:06:53 UTC ---
The following (pretty obvious) patch fixes it:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 164899)
+++ gcc/fortran/resolve.c(working copy)
@@ -297,11 +297,9 @@ resolve_formal_arglist (gfc_symbol *proc)
continue;
}
- if (sym-ts.type == BT_UNKNOWN)
-{
- if (!sym-attr.function || sym-result == sym)
-gfc_set_default_type (sym, 1, sym-ns);
-}
+ if (sym-ts.type == BT_UNKNOWN !proc-attr.intrinsic
+ (!sym-attr.function || sym-result == sym))
+gfc_set_default_type (sym, 1, sym-ns);
gfc_resolve_array_spec (sym-as, 0);
[Bug fortran/30409] [fortran] missed optimization with pure function arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30409 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-10-02 08:10:51 UTC --- Related to PR 45777.
[Bug other/38920] dw2 exceptions don't work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org 2010-10-02 08:51:15 UTC --- It isn't planned to support dw2 exception mechanism for x64 windows. So I close this bug as won't be fixed
[Bug other/45864] New: system.h is crufty maybe? Raise the level fo ANSI C89?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45864 Summary: system.h is crufty maybe? Raise the level fo ANSI C89? Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: jay.kr...@cornell.edu I recently found a compiler that didn't like spaces after the # in preprocessor directives. In system.h: Do any systems lack stddef.h? (it is in ANSI C89) Do any systems lack #define NULL? (ditto) Do any systems lack limits.h? (ditto) Ditto: string.h? time.h? (ditto) errno declared in errno.h? (ditto) SEEK_SET, SEEK_CUR, SEEK_END (ditto) F_OK, X_OK, W_OK, R_OK O_RDONLY, O_WRONLY atof, atol, free, getenv, strstr, abort, offsetof? (ditto) malloc, calloc, realloc? (ditto) Posixy systems that gcc can be hosted on: getcwd, getwd, sbrk? I wonder if all the compability stuff needs to stay. Along with suggesting a new one -- no spaces after #. I wonder if the _unlocked stuff is worthwhile. One should be sure to have reasonably large inputs/outputs, not just getchar one at a time, for example. Maybe some of this is for header-less environments? I grant, getting headers for cross build scenarios can be a pain. But I do need the libraries anyway. - Jay
[Bug middle-end/44984] gcc passes unsigned instead of int for printf width/precision (warnings generated)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44984 --- Comment #3 from Jay jay.krell at cornell dot edu 2010-10-02 10:27:53 UTC --- which compiler produces this I'm afraid I'm not sure and can't quickly/easily make it happen again. Sorry.
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322 --- Comment #7 from Jay jay.krell at cornell dot edu 2010-10-02 10:29:06 UTC --- It looks like the machine I was using might not be available any longer. Sorry.
[Bug fortran/45748] [4.5/4.6 Regression] -fimplicit-none failures when using intrinsic MAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45748 --- Comment #6 from janus at gcc dot gnu.org 2010-10-02 10:38:45 UTC --- Author: janus Date: Sat Oct 2 10:38:42 2010 New Revision: 164901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164901 Log: 2010-10-02 Janus Weil ja...@gcc.gnu.org PR fortran/45748 * resolve.c (resolve_formal_arglist): Avoid setting default type for formal arguments of intrinsic procedures. 2010-10-02 Janus Weil ja...@gcc.gnu.org PR fortran/45748 * gfortran.dg/intrinsic_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #8 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-10-02 10:47:00 UTC --- Closing as worksforme. If you (or anybody else) can reproduce this issue elsewhere, feel free to reopen. Thanks.
[Bug bootstrap/38339] libtool: compile: not configured to build any kind of library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38339 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|libmudflap |bootstrap Resolution||INVALID --- Comment #25 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-10-02 11:09:14 UTC --- We hashed this out a bit off-list, to avoid filling the audit trail with more bad guessing of mine. Anyway, turned out the exposer for this issue was the passing of a number of configure command lines that conflicted: --enable-shared --disable-static --enable-shared=libstdc++ --enable-static I told Gabor to rebuild with --disable-shared --enable-static --enable-shared=libstdc++-v3 intending to create a shared C++ library but everything else static. The build finished successfully, but without creating a shared C++ library. I now checked the libstdc++-v3/configure code, and sorry to say so, but I was wrong, libstdc++-v3/configure defines $PACKAGE as libstdc++, so that the right set of args would have been --disable-shared --enable-static --enable-shared=libstdc++ instead. Gabor, can I ask you to retry with these argumenst one more time? If that fails to produce a shared C++ library, then please open a new PR building only some GCC libraries shared against component bootstrap, point to this PR, Cc: me, and attach the build log, gzip'ed. Thank you. I'm closing this PR as invalid. (I don't want to retitle it because the old name should remain searchable.)
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-02 11:33:43 UTC --- Summary as far I understand it. Cf. http://j3-fortran.org/pipermail/j3/2010-September/003852.html : module m procedure(), pointer :: p, p2 protected :: p end module m subroutine two use m procedure(), pointer :: ptr2 ptr2 = p ! Invalid end subroutine two It is invalid as p is PROTECTED, but gfortran does not diagnose this. That's something the variable-definition patch misses. * * * subroutine one use m procedure(), pointer :: ptr1 = p2 end subroutine one That's invalid as p2 is a pointer, cf. PR 45290.
[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621 --- Comment #6 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-10-02 11:39:45 UTC --- Author: rwild Date: Sat Oct 2 11:39:41 2010 New Revision: 164902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164902 Log: Fix unportable shell quoting. /: PR bootstrap/44621 * configure.ac: Fix unportable shell quoting. * configure: Regenerate. config/: * po.m4 (AM_PO_SUBDIRS): Fix unportable shell quoting. intl/: PR bootstrap/44621 * configure: Regenerate. Modified: branches/gcc-4_5-branch/ChangeLog branches/gcc-4_5-branch/config/ChangeLog branches/gcc-4_5-branch/config/po.m4 branches/gcc-4_5-branch/configure branches/gcc-4_5-branch/configure.ac branches/gcc-4_5-branch/intl/ChangeLog branches/gcc-4_5-branch/intl/configure
[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621 --- Comment #7 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-10-02 11:40:35 UTC --- Author: rwild Date: Sat Oct 2 11:40:32 2010 New Revision: 164903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164903 Log: Fix unportable shell quoting. /: PR bootstrap/44621 * configure.ac: Fix unportable shell quoting. * configure: Regenerate. config/: * po.m4 (AM_PO_SUBDIRS): Fix unportable shell quoting. intl/: PR bootstrap/44621 * configure: Regenerate. Modified: branches/gcc-4_4-branch/ChangeLog branches/gcc-4_4-branch/config/ChangeLog branches/gcc-4_4-branch/config/po.m4 branches/gcc-4_4-branch/configure branches/gcc-4_4-branch/configure.ac branches/gcc-4_4-branch/intl/ChangeLog branches/gcc-4_4-branch/intl/configure
[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-10-02 11:41:25 UTC --- Fixed.
[Bug target/36126] ICE: postreload.c:401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36126 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||WORKSFORME --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2010-10-02 11:44:46 UTC --- I tested this preprocessed sources on 4.4.x (sezero's version) and against 4.5.x and current trunk. I can't reproduce this failure anymore. So I close this bug as solved.
[Bug libobjc/34315] libobjc warnings with Win64 target=x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34315 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org 2010-10-02 11:50:22 UTC --- So this bug is to be closed. Well, missed that.
[Bug fortran/45794] [4.6 Regression] ICE: Segmentation fault in gfc_conv_procedure_call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45794 --- Comment #2 from janus at gcc dot gnu.org 2010-10-02 11:57:49 UTC --- I think this regression is due to r153793, which was Tobias' fix for PR41850. The reason for the ICE is that the formal argument mask of _gfortran_mmaxloc0_4_r4 has as = NULL (while the actual argument has nonzero rank). I'm not sure if the missing array spec is special to MAXLOC, or if this is the case for all intrinsics.
[Bug debug/45865] New: [4.6 regression] Failed to build 403.gcc in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45865 Summary: [4.6 regression] Failed to build 403.gcc in SPEC CPU 2006 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 164827 gave: gcc -m32 -c -o jump.o -DSPEC_CPU -DNDEBUG -I. -O2 -msse2 -mfpmath=sse -ffast-math jump.c [...@gnu-16 build_base_lnx32-gcc.]$ grep jump.c make.err jump.c: In function 'reversed_comparison_code_parts': jump.c:761:1: internal compiler error: in dwarf2out_cfi_begin_epilogue, at dwarf2out.c:2930 [...@gnu-16 build_base_lnx32-gcc.]$
[Bug libstdc++/45866] New: std::ratio_add, ratio_sub, ratio_multiply, ratio_divide do not have num and den members.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45866
Summary: std::ratio_add, ratio_sub, ratio_multiply,
ratio_divide do not have num and den members.
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kal...@gmail.com
The latest C++ draft (which I think is n3126) says this about ratio_add:
The type ratio_addR1, R2 shall be a synonym for ratioT1, T2 where T1 has
the value R1::num * R2::den + R2::num * R1::den and T2 has the value R1::den *
R2::den.
The current implementation in libstdc++ is:
templatetypename _R1, typename _R2
struct ratio_add
{
private:
static const intmax_t __gcd =
__static_gcd_R1::den, _R2::den::value;
public:
typedef ratio
__safe_add
__safe_multiply_R1::num, (_R2::den / __gcd)::value,
__safe_multiply_R2::num, (_R1::den / __gcd)::value::value,
__safe_multiply_R1::den, (_R2::den / __gcd)::value type;
};
Which places the result in a nested type. I interpret the wording of the
standard to mean that ratio_addR1, R2 should have the static members num and
den.
[Bug other/45864] system.h is crufty maybe? Raise the level fo ANSI C89?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45864 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-10-02 12:10:46 UTC --- On Sat, 2 Oct 2010, jay.krell at cornell dot edu wrote: I recently found a compiler that didn't like spaces after the # in preprocessor directives. The requirement for several years has been that you have a C90 compiler, which means that your compiler is not supported, but not necessarily a C90 library. The principle of requiring a C++98 compiler has been agreed and it is likely in practice to go along with requiring more substantial C90 support in the library (e.g. prototypes for standard functions), so a few of these bits might be able to go away when the C++ requirements goes in. Bugzilla is not a useful place to discuss possible changes to requirements; do that on the gcc list. If you believe certain configure checks are no longer needed *in the context of the existing host requirements* you should send patches to remove them (minimal patches removing just a specific check). Posixy systems that gcc can be hosted on: getcwd, getwd, sbrk? sbrk appears to be used only conditionally in mips-tfile.c (which is only used on alpha-dec-osf, so the question is what declarations that system has - all these conditionals are about the possibility of a system having a function but not a header prototype for it). Portable code shouldn't be using sbrk at all; it would be better just to keep the malloc case of the code.
[Bug c/45867] New: Sparc64: bogus %g4 reference in libgcc __udivti3()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45867
Summary: Sparc64: bogus %g4 reference in libgcc __udivti3()
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blauwir...@gmail.com
Sparc64 GCC (at least 4.2.4 and 4.5.0 cross compilers) generates incorrect code
for the minimal test case below.
I found the bug because of obscure crashes in OpenBIOS inside libgcc, in
__udivti3(). The problem can be isolated from __udivti3() to
count_leading_zeros() macro and further to this minimal test case.
As can be seen in the output, there is a strange extra instruction, 'add
%g1, %g4, %g1'. %g4 is not initialized anywhere in the function but any
previous value will be used. Thus the __clz_tab table access can lead to
crashes. This may in theory even have some security implications if %g4 value
could be feasibly controlled by an attacker.
$ cat libgcc2.c
extern const char __clz_tab[256];
char test(void)
{
return __clz_tab[0];
}
$ sparc64-elf-gcc-4.2.4 -save-temps -S libgcc2.c -O2
$ cat libgcc2.s
.file libgcc2.c
.section.text
.align 4
.global test
.type test, #function
.proc 04
test:
sethi %hi(__clz_tab), %g1
add %g1, %g4, %g1
ldsb[%g1+%lo(__clz_tab)], %o0
jmp %o7+8
sra%o0, 0, %o0
.size test, .-test
.ident GCC: (GNU) 4.2.4
$ cat libgcc2.i
# 1 libgcc2.c
# 1 built-in
# 1 command-line
# 1 libgcc2.c
extern const char __clz_tab[256];
char test(void)
{
return __clz_tab[0];
}
$ sparc64-elf-gcc-4.2.4 -v
Using built-in specs.
Target: sparc64-elf
Configured with: ../configure --target=sparc64-elf
--enable-targets=sparc-elf,sparc64-elf --disable-nls --disable-threads
--enable-languages=c --disable-shared --enable-multilib : (reconfigured)
../configure --target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf
--disable-nls --disable-threads --enable-languages=c --disable-shared
--enable-multilib --disable-ssp : (reconfigured) ../configure
--target=sparc64-elf --enable-targets=sparc-elf,sparc64-elf --disable-nls
--disable-threads --enable-languages=c --disable-shared --enable-multilib
--disable-libssp
Thread model: single
gcc version 4.2.4
Same case with 4.5.0:
$ sparc64-elf-gcc-4.5.0 -save-temps -S libgcc2.c -O2
$ cat libgcc2.s
.file libgcc2.c
.section.text
.align 4
.global test
.type test, #function
.proc 02
test:
sethi %hi(__clz_tab), %g1
add %g1, %g4, %g1
jmp %o7+8
ldsb [%g1+%lo(__clz_tab)], %o0
.size test, .-test
.ident GCC: (GNU) 4.5.0
$ cat libgcc2.i
# 1 libgcc2.c
# 1 built-in
# 1 command-line
# 1 libgcc2.c
extern const char __clz_tab[256];
char test(void)
{
return __clz_tab[0];
}
$ sparc64-elf-gcc-4.5.0 -v
Using built-in specs.
COLLECT_GCC=sparc64-elf-gcc-4.5.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sparc64-elf/4.5.0/lto-wrapper
Target: sparc64-elf
Configured with: ../configure --target=sparc64-elf --enable-targets=sparc64-elf
--disable-nls --disable-threads --enable-languages=c --disable-shared
--disable-multilib --disable-libssp
Thread model: single
gcc version 4.5.0 (GCC)
The above are cross compilers, with host:
$ uname -srvmo
Linux 2.6.36-rc5+ #3 SMP Sat Sep 25 17:06:06 UTC 2010 x86_64 GNU/Linux
It doesn't happen with native 3.3.5 from OpenBSD/Sparc64:
$ gcc -save-temps -S libgcc2.c -O2
$ cat libgcc2.s
.file libgcc2.c
.section.text
.align 4
.align 32
.globl test
.type test, @function
.proc 04
test:
!#PROLOGUE# 0
!#PROLOGUE# 1
sethi %h44(__clz_tab), %g1
or %g1, %m44(__clz_tab), %g1
sllx%g1, 12, %g1
retl
ldsb[%g1+%l44(__clz_tab)], %o0
.size test, .-test
$ cat libgcc2.i
# 1 libgcc2.c
# 1 built-in
# 1 command line
# 1 libgcc2.c
extern const char __clz_tab[256];
char test(void)
{
return __clz_tab[0];
}
$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc64-unknown-openbsd4.6/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)
$ uname -mrsv
OpenBSD 4.6 GENERIC#43 sparc64
[Bug libstdc++/45866] [C++0x] std::ratio_add, ratio_sub, ratio_multiply, ratio_divide do not have num and den members.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45866 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.02 12:40:19 Summary|std::ratio_add, ratio_sub, |[C++0x] std::ratio_add, |ratio_multiply, |ratio_sub, ratio_multiply, |ratio_divide do not have|ratio_divide do not have |num and den members.|num and den members. Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-02 12:40:19 UTC --- We currently implement the spec from n3035, the definitions changed in n3090
[Bug libstdc++/45866] [C++0x] std::ratio_add, ratio_sub, ratio_multiply, ratio_divide do not have num and den members.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45866 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Depends on||45114 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-02 12:43:38 UTC --- It's not possible to implement the new spec without template aliases, so this PR depends on PR c++/45114
[Bug debug/45865] [4.6 regression] Failed to build 403.gcc in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45865 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||bernds at codesourcery dot ||com --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-02 13:06:39 UTC --- It is caused by revision 164552: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00849.html
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.02 13:25:23 Ever Confirmed|0 |1 --- Comment #4 from janus at gcc dot gnu.org 2010-10-02 13:25:23 UTC --- Note: The problem not only applies to procedure pointers, but also to data pointers, as the following example shows: module m integer, pointer :: p protected :: p end module m use m integer, pointer :: ptr2 ptr2 = p ! Invalid per F08:C551 (undiagnosed) end
[Bug c/45867] reference to %g4 in code generated for sparc64-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45867 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target||sparc64-elf Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||WORKSFORME Summary|Sparc64: bogus %g4 |reference to %g4 in code |reference in libgcc |generated for sparc64-elf |__udivti3() | --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-10-02 13:40:39 UTC --- As can be seen in the output, there is a strange extra instruction, 'add %g1, %g4, %g1'. %g4 is not initialized anywhere in the function but any previous value will be used. Thus the __clz_tab table access can lead to crashes. This may in theory even have some security implications if %g4 value could be feasibly controlled by an attacker. The attacker is supposed to be you here. The sparc64-elf compiler defaults to the CM_EMBMEDANY memory model: TARGET_CM_EMBMEDANY: 64-bit address space. The text and data segments have a maximum size of 2GB (31-bit span) and may be located anywhere in memory. The global register %g4 contains the start address of the data segment. Programs are statically linked and PIC is not supported.
[Bug c++/44871] Invalid type mismatches while merging C and C++ sources
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2010-07-08 14:47:48 |2010-10-02 14:47:48 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2010-10-02 14:12:02 UTC --- reconfirmed.
[Bug tree-optimization/44897] -fwhopr + ipa-sra misoptimize sqlite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2010-07-18 20:21:12 |2010-10-02 20:21:12 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2010-10-02 14:13:03 UTC --- reconfirmed.
[Bug lto/45089] -Os -g -fwhopr dwarf2out ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45089 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2010-07-27 09:17:50 |2010-10-02 9:17:50 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2010-10-02 14:16:08 UTC --- Reconfirmed. Probably major show stopper for mozilla now as there is no workaround.
[Bug bootstrap/45816] [4.6 Regression] --enable-checking=release causes a comparison failure on powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45816 --- Comment #5 from Bernd Schmidt bernds at gcc dot gnu.org 2010-10-02 14:18:07 UTC --- We'll need to find out why stage1 gcc and stage2 gcc produce different output. To do that, the easiest thing to do is to copy object files from stage1 to stage2, rebuild cc1, and then compile cfghooks.o normally. Once you arrive at a cfghooks.o which is identical to the one produced by stage1, you've found the object file that was miscompiled in stage2.
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740 --- Comment #5 from janus at gcc dot gnu.org 2010-10-02 14:19:18 UTC --- (In reply to comment #4) Note: The problem not only applies to procedure pointers, but also to data pointers, as the following example shows: Well, at least this example is invalid by the same logic as the original test case. However, I'm not sure I fully understand this logic ... In contrast to my annotation in the previous example, C551 does not apply (since it only talks about nonpointers). And C552 only says that a protected pointer cannot appear in a pointer association context (i.e. the LHS of a pointer assignment). It does not say that a protected pointer cannot appear on the RHS of a pointer assignment!?!
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-02 14:39:30 UTC --- (In reply to comment #5) In contrast to my annotation in the previous example, C551 does not apply (since it only talks about nonpointers). And C552 only says that a protected pointer cannot appear in a pointer association context (i.e. the LHS of a pointer assignment). It does not say that a protected pointer cannot appear on the RHS of a pointer assignment!?! I think I scratch that part. I still do not see what is meant by the proc-pointer part in C551 A nonpointer object that has the PROTECTED attribute and is accessed by use association shall not appear [...] as the [...] proc-target in a pointer-assignment-stmt. as PROTECTED can only be applied to proc pointers (and normal variables). I think I will close this PR as INVALID - as the other issue is taken care of in PR 45290.
[Bug fortran/45746] [OOP] ICE in fold_convert_loc: pointer to allocatable array with select type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45746 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from janus at gcc dot gnu.org 2010-10-02 14:44:33 UTC --- (In reply to comment #4) (In reply to comment #3) I do not see the error on x86_64-unknown-linux-gnu at r164767. Can anyone confirm that? Ditto for my 4.6.0 20100930 built also on x86_64-unknown-linux-gnu; I tried it using valgrind. Ok, so I guess we can close this one (supposedly it was fixed by some middle-end patch). Hans, if you encounter the issue after all, please feel free to re-open.
[Bug bootstrap/45174] Make fails in zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174 --- Comment #25 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-10-02 14:52:12 UTC --- Author: rwild Date: Sat Oct 2 14:52:07 2010 New Revision: 164904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164904 Log: Allow to pass separate configure arguments for build, host and target. /: PR bootstrap/45326 PR bootstrap/45174 * configure.ac: Honor initial values of $build_configargs, $host_configargs, $target_configargs. Mark the precious, so environment settings get recorded. * configure: Regenerate. gcc/: * doc/install.texi (Configuration): Document build_configargs, host_configargs, target_configargs. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug bootstrap/45326] gmp's use of C99 keeps breaking my compiles, suggest set autoconf variables to avoid inttypes/stdint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45326 --- Comment #2 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-10-02 14:52:12 UTC --- Author: rwild Date: Sat Oct 2 14:52:07 2010 New Revision: 164904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164904 Log: Allow to pass separate configure arguments for build, host and target. /: PR bootstrap/45326 PR bootstrap/45174 * configure.ac: Honor initial values of $build_configargs, $host_configargs, $target_configargs. Mark the precious, so environment settings get recorded. * configure: Regenerate. gcc/: * doc/install.texi (Configuration): Document build_configargs, host_configargs, target_configargs. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug bootstrap/45868] New: --disable-shared --enable-static --enable-shared=libstdc++ doesn't build shared libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45868 Summary: --disable-shared --enable-static --enable-shared=libstdc++ doesn't build shared libstdc++ Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@papp.hu This is a continue of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38339 --disable-shared --enable-static --enable-shared=libstdc++ doesn't build shared libstdc++.so
[Bug bootstrap/45868] --disable-shared --enable-static --enable-shared=libstdc++ doesn't build shared libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45868 --- Comment #1 from Gabor Z. Papp gzp at papp dot hu 2010-10-02 15:03:55 UTC --- BTW somewhere I read, that shared libstdc++ needs shared libgcc_s.so, probably thats the problem, since this configuration build static libgcc_s only.
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #7 from janus at gcc dot gnu.org 2010-10-02 15:25:04 UTC --- (In reply to comment #6) I still do not see what is meant by the proc-pointer part in C551 A nonpointer object that has the PROTECTED attribute and is accessed by use association shall not appear [...] as the [...] proc-target in a pointer-assignment-stmt. as PROTECTED can only be applied to proc pointers (and normal variables). Ok, I think the only way this half-sentence and the interpretation on the J3 mailing list make sense, is via the following interpretation. Consider: integer, pointer :: lhs, rhs lhs = rhs In such a pointer assignment statement, the object on the right hand side supposedly does not have the pointer attribute (the pointer is dereferenced, so that 'lhs' will point to the target of 'rhs'). With this reading, C551 can be applied to (proc-/data-)pointer assignments as well, and the sentence about 'proc-target' does make sense. [I hate these kinds of subtleties in reading the standard and hope I got it right this time.] Also, from a common sense POV, it is important to reject protected pointers on the rhs of a pointer assignment, otherwise the PROTECTED feature could be circumvented this way.
[Bug other/32998] -frecord-gcc-switches issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998 --- Comment #9 from Jan Kratochvil jan.kratochvil at redhat dot com 2010-10-02 16:06:39 UTC --- Wouldn't be appropriate to append these flags also/instead to DW_AT_producer? This way they get easily associated with the specific CU.
[Bug bootstrap/45816] [4.6 Regression] --enable-checking=release causes a comparison failure on powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45816 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-02 16:07:53 UTC --- We'll need to find out why stage1 gcc and stage2 gcc produce different output. To do that, the easiest thing to do is to copy object files from stage1 to stage2, rebuild cc1, and then compile cfghooks.o normally. Once you arrive at a cfghooks.o which is identical to the one produced by stage1, you've found the object file that was miscompiled in stage2. Sorry, but I don't understand what you ask to do: (1) AFAICT stage1 gcc and stage2 gcc have to produce different output (different compilers, different options and so on, the gcc directories contain 345 binary files that are different between stage 1 and 2); (2) Even between stage2 and stage3 the raw files are different and have to be filtered with contrib/compare-debug before doing the comparisons. I think that before starting a very lengthy (and boring process) it would be better to do some postmortem analysis: (1) why does contrib/compare-debug chokes on the stage3 cfghooks.o? (2) then why the bad sequence is generated? (3) why this depends on the value of --enable-checking=? (4) what is changed by revision 164552 with this respect? (5) and so on.
[Bug bootstrap/42176] bootstrap fails while building libstdc++-v3 on debian sarge (related to cstdio and similar to #30915)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42176 --- Comment #2 from gcc-bugzilla at gehrels dot info 2010-10-02 16:20:01 UTC --- I can confirm this bug using gentoo linux: uname -a Linux vadmin631 2.6.26-2-xen-amd64 #1 SMP Tue Aug 31 11:17:26 UTC 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux emerge --info (shortened) Portage 2.1.8.3 (default/linux/amd64/10.0/server, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26-2-xen-amd64 x86_64) = System uname: linux-2.6.26-2-xen-amd64-x86_64-intel-r-_core-tm-2_quad_cpu_q66...@_2.40ghz-with-gentoo-1.12.13 Timestamp of tree: Sun, 26 Sep 2010 23:30:01 + app-shells/bash: 4.0_p37 dev-lang/python: 2.6.5-r3, 3.1.2-r4 sys-apps/baselayout: 1.12.13 sys-apps/sandbox:1.6-r2 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.1.2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS=amd64 CBUILD=x86_64-pc-linux-gnu CFLAGS=-O2 -pipe CHOST=x86_64-pc-linux-gnu CXXFLAGS=-O2 -pipe LDFLAGS=-Wl,-O1 -Wl,--as-needed I tried to attach a build.log, but it is too large to be attached, so please contact me (or leave a note here), i will then send it by email.
[Bug bootstrap/42176] bootstrap fails while building libstdc++-v3 on debian sarge (related to cstdio and similar to #30915)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42176 --- Comment #3 from gcc-bugzilla at gehrels dot info 2010-10-02 16:22:48 UTC --- Oh, and, btw: The Version i was trying to compile was gcc-4.4.3
[Bug bootstrap/45816] [4.6 Regression] --enable-checking=release causes a comparison failure on powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45816 --- Comment #7 from Bernd Schmidt bernds at gcc dot gnu.org 2010-10-02 16:35:28 UTC --- The files between stage1 and stage2 are supposed to differ. What isn't supposed to differ (after stripping optional debug information) is stage2 and stage3, which are produced by stage1 and stage2. The bootstrap comparison failure shows that gcc/cfghooks.o is the only file that differs in such a way. The process isn't that lengthy, it's a binary search and shouldn't take more than half an hour maximum to identify the file that's being miscompiled. In my experience none of the other questions can easily be answered without identifying a testcase in such a way.
[Bug tree-optimization/45649] -Wunsafe-loop-optimizations fail to recognize finite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45649 --- Comment #1 from Dmitry G. Dyachenko dimhen at gmail dot com 2010-10-02 16:38:02 UTC --- gcc version 4.6.0 20101002 (experimental) [trunk revision 164903] (GCC) FAIL too
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||g...@integrable-solutions.ne ||t --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-10-02 16:59:28 UTC --- I would personally like to have this. I know most people that want this use a wrapper around gcc (or have moved to clang), but the output of gcc is not designed to be machine readable, so I think there is a benefit on implementing this in GCC. Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just color the diagnostic markers: error: (bold red) warning: (magenta) note: (blue? green?) I would follow the very simple implementation used by grep. It will default to off of course, I don't plan to implement automatic detection of capabilities or anything like that. So before I waste my time, would such a thing be ever accepted in GCC?
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-02 17:03:33 UTC --- This is a dup of bug 36150. *** This bug has been marked as a duplicate of bug 36150 ***
[Bug other/36150] colorize output of gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-02 17:03:33 UTC --- *** Bug 45850 has been marked as a duplicate of this bug. ***
[Bug target/45820] FAIL: gcc.c-torture/compile/pr45728.c at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45820 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2010-10-02 17:20:26 UTC --- Actually, the insn doesn't satisfy its constraints because %r31 should be %r1. Have a patch. This is an old regression caused by a change to pa_secondary_reload.
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #3 from Gabriel Dos Reis g...@integrable-solutions.net 2010-10-02 17:30:05 UTC --- On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What |Removed |Added CC| |g...@integrable-solutions.ne | |t --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-10-02 16:59:28 UTC --- I would personally like to have this. I know most people that want this use a wrapper around gcc (or have moved to clang), but the output of gcc is not designed to be machine readable, I believe different people have different take on this. I've seen people argue and get stuff in on the basis that the output should be machine readable. I would suggest restraint from sweeping statements, in the quest for consensus. so I think there is a benefit on implementing this in GCC. Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just color the diagnostic markers: error: (bold red) warning: (magenta) note: (blue? green?) my copy of GCC (under openSUSE) colors the output and let me customize the colors. That is quite system dependent. Getting the same stuff under non-Unix like system require more constraints on the environment. How far should we go to emulate an IDE?
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #4 from Gabriel Dos Reis g...@integrable-solutions.net 2010-10-02 17:32:08 UTC --- On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just color the diagnostic markers: error: (bold red) warning: (magenta) note: (blue? green?) I would follow the very simple implementation used by grep. IDEs let users get the colors they want -if they ever wanted. (the above is certainly a wrong default for me -- the background of my terminal is always dark. :-)
[Bug target/45820] FAIL: gcc.c-torture/compile/pr45728.c at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45820 --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2010-10-02 17:38:38 UTC --- Author: danglin Date: Sat Oct 2 17:38:35 2010 New Revision: 164905 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164905 Log: PR target/45820 * config/pa/pa.c (pa_secondary_reload): Handle symbolic operands earlier. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c
[Bug target/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2010-10-02 17:42:15 UTC --- (In reply to comment #14) Closing as fixed. Thanks for the patch. Looks like r156786 should have been backported to gcc-4_4-branch and gcc-4_5-branch. The regressions... FAIL: gcc.dg/darwin-weakimport-1.c scan-assembler-not weak_[a-z \t]*_b FAIL: gcc.dg/darwin-weakimport-3.c scan-assembler-not coalesced have popped up in the release gcc 4.4.5 build at -m32 and -m64.
[Bug other/36150] colorize output of gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150 --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-10-02 17:52:39 UTC --- Somehow I missed this bug when searching. For those here in favour of color, clang has it and people love it [*]. Luckily, this is one of those clang things that can be done in GCC, and it works with localized messages. I have a prototype patch and it is not too big. Unluckily, it seems it would be rejected anyway, so I won't bother to clean it up and do all the bureaucracy stuff. Shame. [*] http://fseek.me/2010/03/how-to-convince-any-c-developer-to-dump-gcc-and-use-clang/
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-10-02 18:04:00 UTC --- my copy of GCC (under openSUSE) colors the output and let me customize the colors. That is quite system dependent. Getting the same stuff under non-Unix like system require more constraints on the environment. How far should we go to emulate an IDE? So how does it work in openSUSE? Do they have patches that FSF GCC doesn't have? I really don't care about non-unix environments. Not all features of GCC work on all operating systems. And you say that you have colored output but you don't want FSF GCC to have it? Am I misunderstanding you?
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-10-02 18:30:45 UTC --- (In reply to comment #4) On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org IDEs let users get the colors they want -if they ever wanted. The output of GCC is not designed to be parsed by IDEs: http://gcc.gnu.org/PR19165 nor is GCC designed to be tightly integrated with an IDE. (the above is certainly a wrong default for me -- the background of my terminal is always dark. :-) It is readable in my black background. It also looks nice here: http://fseek.me/2010/03/how-to-convince-any-c-developer-to-dump-gcc-and-use-clang/ and in the examples here: http://llvm.org/devmtg/2009-10/StateOfClang.pdf Those colors are also readable in a white background. But feel free to suggest defaults, and I will be happy with them. Of course, customization, like grep, and ls, could be added later.
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #7 from Gabriel Dos Reis g...@integrable-solutions.net 2010-10-02 18:35:26 UTC --- On Sat, Oct 2, 2010 at 1:04 PM, manu at gcc dot gnu.org he environment. How far should we go to emulate an IDE? So how does it work in openSUSE? Do they have patches that FSF GCC doesn't have? I did not look into their pacthes GC -- every vendor patches GCC in one way or the other. I really don't care about non-unix environments. Not all features of GCC work on all operating systems. I think that it a problem. And you say that you have colored output but you don't want FSF GCC to have it? Am I misunderstanding you? I think you are. I don't know if it is on purpose.
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #8 from Gabriel Dos Reis g...@integrable-solutions.net 2010-10-02 18:41:28 UTC --- On Sat, Oct 2, 2010 at 1:30 PM, manu at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-10-02 18:30:45 UTC --- (In reply to comment #4) On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org IDEs let users get the colors they want -if they ever wanted. The output of GCC is not designed to be parsed by IDEs: http://gcc.gnu.org/PR19165 nor is GCC designed to be tightly integrated with an IDE. that PR is a proof of what? One reason we have standardized on 'warning: ', 'error: ', etc. prefixes is precisely so that IDEs or other tools can differentiate them. The fact that we have not succeeded in many other areas is more of a shortcoming than a design goal. (the above is certainly a wrong default for me -- the background of my terminal is always dark. :-) It is readable in my black background. It also looks nice here: I think we may just have found two sets of people who disagree on what is readable with a dark background. Which is precisely the point of my original message.
[Bug c/45869] New: type mismatch in shift expression produces ice with -O3 and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45869 Summary: type mismatch in shift expression produces ice with -O3 and -m32 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com This bug has a failure mode similar to bug #42927, except the failure occurs only when compiling the attached test case with both -O3 and -m32 on an x86_64 host. Checks must also be enabled. The following output is produced: vec-shift-m32-O3-ice.c: In function 'foo': vec-shift-m32-O3-ice.c:22:1: error: type mismatch in vector shift expression vector char * vector char * unsigned int vect_var_.26_65 = vect_var_.23_64 v 64; vec-shift-m32-O3-ice.c:22:1: error: type mismatch in vector shift expression vector char * vector char * unsigned int vect_var_.26_67 = vect_var_.26_66 v 32; vec-shift-m32-O3-ice.c:22:1: internal compiler error: verify_stmts failed Although the bug was detected in the 4.5.1 release, it can be reproduced in the gcc-4.6-20100925 snapshot (SVN revision revision 164623) as well.
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740 janus at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #8 from janus at gcc dot gnu.org 2010-10-02 18:51:21 UTC --- Patch: Index: gcc/fortran/expr.c === --- gcc/fortran/expr.c(revision 164900) +++ gcc/fortran/expr.c(working copy) @@ -3250,6 +3250,14 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex return FAILURE; } + /* Check for F08:C551. */ + if (rvalue-expr_type == EXPR_VARIABLE + rvalue-symtree-n.sym-attr.is_protected + rvalue-symtree-n.sym-attr.use_assoc) +gfc_error (Variable '%s' is PROTECTED and can not appear in a + pointer assignment statement at %L, + rvalue-symtree-n.sym-name, rvalue-where); + proc_pointer = lvalue-symtree-n.sym-attr.proc_pointer; rank_remap = false;
[Bug c/45869] type mismatch in shift expression produces ice with -O3 and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45869 --- Comment #2 from Gary Funck gary at intrepid dot com 2010-10-02 18:55:10 UTC --- Running reghunt against the 4.5 branch indicates that the following update causes the failure: r161951 | rguenth | 2010-07-08 11:56:08 + (Thu, 08 Jul 2010) | 46 lines 2010-07-08 Richard Guenther rguent...@suse.de Backport from mainline 2010-05-27 Richard Guenther rguent...@suse.de PR tree-optimization/44284 * tree-vect-stmts.c (vectorizable_assignment): Handle sign-changing conversions as simple copy. [...]
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-10-02 19:46:31 UTC --- (In reply to comment #7) On Sat, Oct 2, 2010 at 1:04 PM, manu at gcc dot gnu.org he environment. How far should we go to emulate an IDE? So how does it work in openSUSE? Do they have patches that FSF GCC doesn't have? I did not look into their pacthes GC -- every vendor patches GCC in one way or the other. I did. They don't have a patch for this so I really wonder how this is possible. Are you sure you didn't install some wrapper around gcc? Anyway, it is clear that is not something widely available. The fact that you have it enabled and openSUSE supports this is an indication that it is a desirable feature, at least for a subset of users. I really don't care about non-unix environments. Not all features of GCC work on all operating systems. I think that it a problem. Why? It only seems to work on openSUSE right now, definitely not in Ubuntu, so extending it to all unix supported by FSF GCC seems an improvement to me. And you say that you have colored output but you don't want FSF GCC to have it? Am I misunderstanding you? I think you are. I don't know if it is on purpose. I want to add a feature to the FSF GCC. You are the one that can allow it, but you seem not in favour of it, despite using this feature in a customized version of GCC. So it is definitely in my best interest to understand why this is so, to try to address your concerns, or otherwise realize that this is not possible at all and give up.
[Bug other/36150] colorize output of gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-10-02 19:51:34 UTC --- For future reference, more examples of color diagnostics in clang can be found here: http://llvm.org/devmtg/2009-10/StateOfClang.pdf but that is quite old, recent clang versions may produce a different output.
[Bug fortran/45740] PROCEDURE POINTER and PROTECTED: Accepts/ICEs on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45740 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-02 19:52:17 UTC --- (In reply to comment #7) Ok, I think the only way this half-sentence and the interpretation on the J3 mailing list make sense, is via the following interpretation. I disagree and start to come to the conclusion that one should asked at the J3 mailing list - I just have no idea how to ask sensible for the proc-target part of C551. Consider: integer, pointer :: lhs, rhs lhs = rhs In such a pointer assignment statement, the object on the right hand side supposedly does not have the pointer attribute Why? I see on the right hand side a data-target looks perfectly like a pointer and matches also the definition Entities with the POINTER attribute can be associated with different data objects or procedures during execution of a program. I could do: rhs = targer while (even if rhs were an array) I could not do rhs(4) = target that 'lhs' will point to the target of 'rhs'). With this reading, C551 can be applied to (proc-/data-)pointer assignments as well, and the sentence about 'proc-target' does make sense. Well, it makes sense here - but you open at the same time the box of the Pandora. Also, from a common sense POV, it is important to reject protected pointers on the rhs of a pointer assignment, otherwise the PROTECTED feature could be circumvented this way. Actually: How? I see how you can modify the pointer target - but not the pointer itself. Thus: - I think C551's or proc-target does not make sense as it is unreachable - With regards to C551/C552 gfortan handles it seemingly correctly - I need a stronger coffee when reading the fine prints of the Fortran standard With your definition, you allow for: pointer :: ptr2 = ptr1 which is difficult to get correct and I believe is invalid as ptr1 has the POINTER and not the TARGET attribute. A POINTER is allowed for a normal, non-initialization expression.
[Bug bootstrap/45816] [4.6 Regression] --enable-checking=release causes a comparison failure on powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45816 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-02 21:03:38 UTC --- The process isn't that lengthy, it's a binary search and shouldn't take more than half an hour maximum to identify the file that's being miscompiled. In my experience none of the other questions can easily be answered without identifying a testcase in such a way. I have already spent half an hour to go nowhere and I can probably spend days (I don't have) without progress. So if you want to do that your way, I need precise directives: -step1 do this -step2 do that ... and so on.
[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45856 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from John David Anglin danglin at gcc dot gnu.org 2010-10-02 21:58:43 UTC --- Also seen on hppa-unknown-linux-gnu.
[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45856 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2010-10-02 22:10:20 UTC --- On hppa, fails on flt (x=0, y=1). flt returns `T', but result is `F'.
[Bug c/45850] support color diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850 --- Comment #10 from Gabriel Dos Reis g...@integrable-solutions.net 2010-10-02 22:35:12 UTC --- On Sat, Oct 2, 2010 at 2:46 PM, manu at gcc dot gnu.org And you say that you have colored output but you don't want FSF GCC to have it? Am I misunderstanding you? I think you are. I don't know if it is on purpose. I want to add a feature to the FSF GCC. You are the one that can allow it, but you seem not in favour of it, You seem to equate `discussing the technical problems (because there are) associated with this' with 'seem not to favour' to the point of attributing claims I have not made to me. That makes it difficult to discern when you are discussing technical problem as opposed anything else. It makes hard to listen to what you are saying. despite using this feature in a customized version of GCC. So it is definitely in my best interest to understand why this is so, to try to address your concerns, or otherwise realize that this is not possible at all and give up. There is a difference between `asking question in order to understand' and `making a claim and attributing it to me'.
[Bug bootstrap/45816] [4.6 Regression] --enable-checking=release causes a comparison failure on powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45816 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2010-10-02 23:13:10 UTC --- This may be related to PR 45865 since the same checkin caused both PRs. PR 45865 can be reproduced on Linux/ia32.
[Bug c/45869] [4.5/4.6 Regression] type mismatch in shift expression produces ice with -O3 and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45869 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com Target Milestone|--- |4.5.2 Summary|type mismatch in shift |[4.5/4.6 Regression] type |expression produces ice |mismatch in shift |with -O3 and -m32 |expression produces ice ||with -O3 and -m32
[Bug c/45869] [4.5/4.6 Regression] type mismatch in shift expression produces ice with -O3 and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45869 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.02 23:19:59 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1
[Bug debug/45865] [4.6 regression] Failed to build 403.gcc in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45865 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug libstdc++/45863] [4.6 regression] FAIL: libstdc++-abi/abi_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45863 --- Comment #7 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-03 00:31:09 UTC --- Author: hjl Date: Sun Oct 3 00:31:06 2010 New Revision: 164913 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164913 Log: Revert the pvs change. 2010-10-02 H.J. Lu hongjiu...@intel.com PR libstdc++/45863 * scripts/extract_symvers: Revert the pvs change. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/scripts/extract_symvers
[Bug libstdc++/45863] [4.6 regression] FAIL: libstdc++-abi/abi_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45863 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2010-10-03 02:32:25 UTC --- Fixed.
[Bug debug/45870] New: note: non-delegitimized UNSPEC 5 found (-O1 -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45870 Summary: note: non-delegitimized UNSPEC 5 found (-O1 -g) Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com The attached C source file will generate the following notes when compiled with (-01 -g, checks enabled): non-delegit-uspec-5-g-O1.c: In function 'main': non-delegit-uspec-5-g-O1.c:41:1: note: non-delegitimized UNSPEC 5 found in variable location non-delegit-uspec-5-g-O1.c:41:1: note: non-delegitimized UNSPEC 5 found in variable location
[Bug debug/45870] note: non-delegitimized UNSPEC 5 found (-O1 -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45870 --- Comment #2 from Gary Funck gary at intrepid dot com 2010-10-03 04:04:48 UTC --- reghunt on the 4.5 branch indicates that the following update produces the notes described above (-O1 -g, checks enabled): r161414 | aoliva | 2010-06-25 21:11:56 + (Fri, 25 Jun 2010) | 3 lines PR debug/44610 * simplify-rtx.c (delegitimize_mem_from_attrs): Don't use a base address if the offset is unknown.
[Bug debug/45870] note: non-delegitimized UNSPEC 5 found (-O1 -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45870 --- Comment #3 from Gary Funck gary at intrepid dot com 2010-10-03 04:10:32 UTC --- This bug can also be reproduced in the 4.6 snapshot, gcc-4.6-20100925 (svn revision 164623).
