[Bug c++/33035] [4.3 regression] ICE on local class destructor
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-15 09:06 --- Subject: Bug 33035 Author: paolo Date: Wed Aug 15 09:06:42 2007 New Revision: 127508 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127508 Log: /cp 2007-08-15 Paolo Carlini <[EMAIL PROTECTED]> PR c++/33035 * pt.c (push_template_decl_real): Depending on TYPE_P use either TYPE_CONTEXT or DECL_CONTEXT. /testsuite 2007-08-15 Paolo Carlini <[EMAIL PROTECTED]> PR c++/33035 * g++.dg/template/crash68.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash68.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33035
[Bug c++/33035] [4.3 regression] ICE on local class destructor
--- Comment #4 from pcarlini at suse dot de 2007-08-15 09:07 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33035
[Bug c++/33035] [4.3 regression] ICE on local class destructor
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33035
[Bug c++/33012] ICE on throwing copy of object returned by reference from method with traits-deduced return-type
--- Comment #2 from pcarlini at suse dot de 2007-08-15 09:14 --- So the problem is already fixed in all the active branches. Thanks, anyway! -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.1.2 4.2.1 4.3.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33012
[Bug fortran/29459] Spurious warnings about anonymous variables
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-15 09:16
---
OK, I've found the culprit: the variable is created in
gfc_trans_vla_one_sizepos(). However, it makes no sense to issue warnings about
anonymous variables, since these are emitted by the front-end for internal
business, and don't refer to user code. Thus, we can simply get rid of it as a
whole, with:
Index: trans.c
===
--- trans.c (revision 127490)
+++ trans.c (working copy)
@@ -102,7 +102,15 @@ remove_suffix (char *name, int len)
tree
gfc_create_var_np (tree type, const char *prefix)
{
- return create_tmp_var_raw (type, prefix);
+ tree t;
+
+ t = create_tmp_var_raw (type, prefix);
+
+ /* No warnings for anonymous variables. */
+ if (prefix == NULL)
+TREE_NO_WARNING (t) = 1;
+
+ return t;
}
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Summary|Spurious warning about |Spurious warnings about
|uninitialized optional |anonymous variables
|arguments |
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug fortran/33077] New: gfortran.dg/random_7.f90: a.out uses uninitialized memory/test failure
If I run gfortran -g gfortran.dg/random_7.f90 valgrind a.out ==27210== Conditional jump or move depends on uninitialised value(s) ==27210==at 0x400A35: MAIN__ (random_7.f90:12) ==27210==by 0x400D0B: main (fmain.c:22) Using gfortran -g -fdefault-integer-8, ./a.out aborts and valgrind shows: ==27279== Invalid read of size 8 ==27279==at 0x4EC9807: _gfortran_random_seed_i8 (random.c:735) ==27279==by 0x400CE3: test_random_seed.1377 (random_7.f90:18) ==27279==by 0x400965: MAIN__ (random_7.f90:10) ==27279==by 0x400D1B: main (fmain.c:22) ==27279== Address 0x4050708 is 0 bytes after a block of size 32 alloc'd ==27279==at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==27279==by 0x4E3E64A: _gfortran_allocate (memory.c:133) ==27279==by 0x4008C9: MAIN__ (random_7.f90:9) ==27279==by 0x400D1B: main (fmain.c:22) -- Summary: gfortran.dg/random_7.f90: a.out uses uninitialized memory/test failure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33077
[Bug fortran/33077] RANDOM_SEED failure for integer(kind=8)
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-15 09:54 --- (In reply to comment #0) > ==27210== Conditional jump or move depends on uninitialised value(s) > ==27210==at 0x400A35: MAIN__ (random_7.f90:12) > ==27210==by 0x400D0B: main (fmain.c:22) Humpf, stupid me, the testcase doesn't initialize seed. Adding seed(:) = huge(seed) gets rid of this one. > Using gfortran -g -fdefault-integer-8, ./a.out aborts It doesn't abort for me, but adding the non-zero initialization above makes it abort. I introduced it, I'll fix it! (not that it's much of a regression, because RANDOM_SEED never worked for integer(kind=8) before ;-) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-15 09:54:05 date|| Summary|gfortran.dg/random_7.f90: |RANDOM_SEED failure for |a.out uses uninitialized|integer(kind=8) |memory/test failure | Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33077
[Bug fortran/18850] padding within a sequence type
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-15 10:16 --- Fixing as FIXED: I think the -fpack-derived option is used for this very purpose. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18850
[Bug fortran/32310] Intel-darwin specific ICE on CP2K code
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-15 10:41 --- cp2k compiles fine on i686-darwin as of today, and I can't see the memory leak any more, so I'm closing this. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #142 from fxcoudert at gcc dot gnu dot org 2007-08-15 10:44 --- As there's only one bug left here, and it's been worked on, I'm closing this PR. Hopefully, with the inclusion of cp2k into regression-testers, we won't need to REOPEN it! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c++/31751] [4.1/4.2 regression] ICE with forgotten member declaration
--- Comment #1 from pcarlini at suse dot de 2007-08-15 11:22 --- Cannot be reproduced anymore in mainline, likely because of 33035. -- pcarlini at suse dot de changed: What|Removed |Added Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE |with forgotten member |with forgotten member |declaration |declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31751
[Bug middle-end/33074] [4.3 regression] ICE in copy_insn_1, at emit-rtl.c:4925
--- Comment #1 from jakub at gcc dot gnu dot org 2007-08-15 11:43 --- Caused by http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00571.html Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-08-14 22:34:02 |2007-08-15 11:43:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33074
[Bug fortran/32616] "Too short actual argument" for array element storage sequence
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-15 11:51:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32616
[Bug fortran/32928] DATA statement with array element as initializer is rejected
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-15 11:52:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32928
[Bug fortran/32986] Improve diagnostic message for COMMON with automatic object
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-15 11:54:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32986
[Bug fortran/33015] g77 extension: Implement support for DATA jhlf /'f'/
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-15 11:55:37 date|| Summary|g77/F66/vendor extension: |g77 extension: Implement |Implement support for DATA |support for DATA jhlf /'f'/ |jhlf /'f'/ | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33015
[Bug c++/32992] [4.1/4.2/4.3 Regression] Incorrect code generated for anonymous union and return
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-15 12:08 --- Subject: Bug 32992 Author: jakub Date: Wed Aug 15 12:08:42 2007 New Revision: 127510 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127510 Log: PR c++/32992 * typeck.c (check_return_expr): Don't NRV optimize vars in anonymous unions. * decl.c (finish_function): Comment fix. * g++.dg/opt/nrv14.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/nrv14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32992
[Bug middle-end/33074] [4.3 regression] ICE in copy_insn_1, at emit-rtl.c:4925
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-15 12:11 --- Subject: Bug 33074 Author: jakub Date: Wed Aug 15 12:11:38 2007 New Revision: 127511 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127511 Log: PR middle-end/33074 * emit-rtl.c (try_split): Use INSN_LIST instead of EXPR_LIST for REG_LIBCALL note. * gfortran.dg/pr33074.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr33074.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33074
[Bug middle-end/33074] [4.3 regression] ICE in copy_insn_1, at emit-rtl.c:4925
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-15 12:17 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33074
[Bug c++/32870] Unclear error message when declaring struct in wrong namespace
--- Comment #1 from pcarlini at suse dot de 2007-08-15 12:35 --- working on it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-15 12:35:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32870
[Bug fortran/33077] RANDOM_SEED failure for integer(kind=8)
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-15 12:36 --- Subject: Bug 33077 Author: fxcoudert Date: Wed Aug 15 12:35:57 2007 New Revision: 127512 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127512 Log: PR fortran/33077 * intrinsics/random.c (random_seed_i8): Fix code logic. * gfortran.dg/random_7.f90: Initialize variable. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/random_7.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/random.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33077
[Bug fortran/33077] RANDOM_SEED failure for integer(kind=8)
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-15 12:37 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33077
[Bug c++/33078] New: g++ treats extern "c" static void foo(void); different to extern "c" {static void foo(void);}
g++ --version
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
on debian lenny i386; reproduced on sid amd64 too.
g++ -DUNIX_THREADING -D_THREAD_SAFE -D_REENTRANT -ggdb -Wall -DLINUX -D_POSIX_
SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -DUSE_STRCASECMP -DUSE_STRNCASECMP -g -pg
-c test1.cpp
test1.cpp:3: error: invalid use of 'static' in linkage specification
test1.cpp: In function 'void* CheckServerThread(void*)':
test1.cpp:8: error: 'void* CheckServerThread(void*)' was declared 'extern' and
later 'static'
test1.cpp:4: error: previous declaration of 'void* CheckServerThread(void*)'
--
Summary: g++ treats extern "c" static void foo(void); different
to extern "c" {static void foo(void);}
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: room_debugs at outgesourced dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33078
[Bug c++/33078] g++ treats extern "c" static void foo(void); different to extern "c" {static void foo(void);}
--- Comment #1 from room_debugs at outgesourced dot org 2007-08-15 12:39 --- Created an attachment (id=14061) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14061&action=view) simple test file failing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33078
[Bug fortran/29459] Spurious warnings about anonymous variables
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-15 12:39 --- Subject: Bug 29459 Author: fxcoudert Date: Wed Aug 15 12:39:18 2007 New Revision: 127513 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127513 Log: PR fortran/29459 * trans.c (gfc_create_var_np): Do not emit warnings for anonymous variables. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug fortran/29459] Spurious warnings about anonymous variables
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-08-15 12:39 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29459
[Bug c++/33078] g++ treats extern "c" static void foo(void); different to extern "c" {static void foo(void);}
--- Comment #2 from room_debugs at outgesourced dot org 2007-08-15 12:40
---
Created an attachment (id=14062)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14062&action=view)
same code with {}; and not failing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33078
[Bug fortran/30658] Optionally, generate .mod files with the interface for files containing only procedures
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-15 12:56:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30658
[Bug libfortran/33079] New: Optional empty strings do not appear to be 'PRESENT'
Hi! See http://gcc.gnu.org/ml/fortran/2007-08/msg00336.html and http://gcc.gnu.org/ml/fortran/2007-08/msg00338.html GFortran seems to handle in a slightly surprising way optional empty strings... Cheers! Philippe PS: a testcase from François-Xavier Coudert CHARACTER(LEN=1) :: s s = " " CALL bar (s) CALL bar (trim(s)) CONTAINS SUBROUTINE bar (s) CHARACTER(LEN=*), OPTIONAL :: s IF (PRESENT (s)) THEN WRITE(*,"(A)") "Argument: |" // s // "|" ELSE WRITE(*,"(A)") "No argument" END IF END SUBROUTINE bar END -- Summary: Optional empty strings do not appear to be 'PRESENT' Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: P dot Schaffnit at access dot rwth-aachen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-08-15 13:05:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug target/32765] Testsuite failures due to undefined symbol ___emutls_get_address
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-15 13:11 --- Subject: Bug 32765 Author: fxcoudert Date: Wed Aug 15 13:11:40 2007 New Revision: 127514 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127514 Log: PR target/32765 * testsuite/libgomp.fortran/pr32550.f90: Use -static-libgcc on Darwin. * testsuite/libgomp.fortran/crayptr2.f90: Likwise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.fortran/crayptr2.f90 trunk/libgomp/testsuite/libgomp.fortran/pr32550.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32765
[Bug target/32765] Testsuite failures due to undefined symbol ___emutls_get_address
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-15 13:12 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32765
[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-15 14:05
---
The problem is shared by the TRIM and MIN/MAX. It is demonstrated by:
character(len=1) :: s
character(len=0) :: s0
s = " "
s0 = ""
call bar ("")
call bar (s)
call bar (s0)
call bar (trim(s))
call bar (min(s0,s0))
contains
subroutine bar (s)
character(len=*), optional :: s
if (.not. present (S)) call abort
end subroutine bar
end
The problem is that a zero-length character string isn't NULL, it's "" (ie a
pointer to a '\0'). The following patch fixes it:
Index: intrinsics/string_intrinsics.c
===
--- intrinsics/string_intrinsics.c (revision 127490)
+++ intrinsics/string_intrinsics.c (working copy)
@@ -167,16 +167,21 @@ string_trim (GFC_INTEGER_4 * len, void *
}
*len = i + 1;
- if (*len > 0)
+ if (*len == 0)
+{
+ /* A zero-length Fortran string is "". */
+ char * tmp = internal_malloc_size (1);
+ tmp[0] = '\0';
+ *dest = tmp;
+}
+ else
{
/* Allocate space for result string. */
*dest = internal_malloc_size (*len);
- /* copy string if necessary. */
+ /* Copy string if necessary. */
memmove (*dest, src, *len);
}
- else
-*dest = NULL;
}
@@ -403,14 +408,18 @@ string_minmax (GFC_INTEGER_4 *rlen, void
}
va_end (ap);
- if (*rlen > 0)
+ if (*rlen == 0)
+{
+ /* A zero-length Fortran string is "". */
+ char * tmp = internal_malloc_size (1);
+ tmp[0] = '\0';
+ *dest = tmp;
+}
+ else
{
char * tmp = internal_malloc_size (*rlen);
memcpy (tmp, res, reslen);
memset (&tmp[reslen], ' ', *rlen - reslen);
*dest = tmp;
}
- else
-*dest = NULL;
}
-
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Keywords||patch
Last reconfirmed|2007-08-15 13:05:53 |2007-08-15 14:05:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'
--- Comment #2 from schwab at suse dot de 2007-08-15 14:18 --- Why do you need to special case len == 0? The other strings aren't NUL terminated either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-15 14:22 --- (In reply to comment #2) > Why do you need to special case len == 0? The other strings aren't NUL > terminated either. The zero-termination is just a detail to avoid keeping memory uninitialized. The thing is that *dest should not be NULL, and malloc(0) will return NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
[Bug middle-end/179] gcc -O2 -Wuninitialized missing warning with &var under 2.95.x and 3.x
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-15 14:22 --- (In reply to comment #8) > *** Bug 17172 has been marked as a duplicate of this bug. *** > I see that the xfail is still there, so how can this be fixed ? http://gcc.gnu.org/svn/gcc/trunk/gcc/testsuite/gcc.dg/uninit-B.c -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=179
[Bug fortran/31820] Warning if case label value exceeds maximum value for type
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-15 14:38 --- (In reply to comment #1) > * An INTEGER SELECT construct has a CASE that can never be matched as its > lower value is greater than its upper value. It is also implemented: $ cat u1.f90 integer :: i, j select case (i) case (251:250) end select end $ gfortran u1.f90 -Wsurprising u1.f90:3.10: case (251:250) 1 Warning: Range specification at (1) can never be matched When an error occurs, though, we will not display the warning, which is fine IMHO. We still need to add a check for the initial testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31820
[Bug c/7258] The message "variable might be used uninitialised" does not tell the location
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-15 14:41 --- I am not so sure this is fixed. I need to double check this. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7258
[Bug middle-end/22456] [4.1/4.2/4.3 regression] missing "is used uninitialized" warning
--- Comment #13 from manu at gcc dot gnu dot org 2007-08-15 15:02 --- (In reply to comment #12) > Created an attachment (id=13354) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13354&action=view) [edit] > patch to preserve uninitialized PHI arguments in CCP > > like so. -O -Wall gives > > t.i: In function 'foo': > t.i:3: warning: 'i' may be used uninitialized in this function > I don't think we want to do this, since it works fine in a lot of testcases that will get hindered. See http://gcc.gnu.org/ml/gcc/2005-11/msg00028.html As far as I see this is a duplicate of PR18501. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug middle-end/22456] [4.1/4.2/4.3 regression] missing "is used uninitialized" warning
--- Comment #14 from manu at gcc dot gnu dot org 2007-08-15 15:05 --- Diego, I think this is caused by CCP silently merging UNDEFINED PHI nodes. We could group similar cases into PR18501, don't you think? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug c/30542] gcc 4.1.1 missing uninitialized variable warnings
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-15 15:21 ---
(In reply to comment #3)
> Is it really quite as 22456? That bug is about variable used for initializing
> itself, and really strange do-nothing code, while this one is straightforward
> use of unitialized variable:
>
> int main (void)
> {
> int i, foo;
> for (i = 0; i < 10; i++)
> {
> if (i > 5)
> foo = 8;
> printf ("%d\n", foo); /* uninitialized foo is printed six times */
> }
> }
I get ten times 8 printed. Roughly, an optimisation pass is assuming that the
initial value of foo is 8 (remember, undefined means we can assume whatever),
so foo is completely removed. Believe me, the optimisation is valid and
beneficial and in many situations the uninitialised value is never used (if we
were to warn, it will be a false positive). Unfortunately, this is not one of
these cases.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30542
[Bug tree-optimization/17506] [4.0/4.1 regression] warning about uninitialized variable points to wrong location
--- Comment #35 from manu at gcc dot gnu dot org 2007-08-15 15:23 --- If there are not going to be more releases of GCC 4.0 or 4.1, I guess we can close this, no? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
[Bug c++/31516] ICE on nested templates
--- Comment #4 from pcarlini at suse dot de 2007-08-15 15:25 --- This is a duplicate of 33035 and indeed the latter isn't a regression, I'm fixing that. *** This bug has been marked as a duplicate of 33035 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31516
[Bug c++/33035] [4.3 regression] ICE on local class destructor
--- Comment #5 from pcarlini at suse dot de 2007-08-15 15:25 --- *** Bug 31516 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33035
[Bug libstdc++/33080] New: Building libstdc++ with static libgcc
Add possibility (maybe a configure param) for building libstdc++ (and other gcc companion libraries) with libgcc linked-in staticaly. -- Summary: Building libstdc++ with static libgcc Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janka dot gcc at mailnull dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33080
[Bug c++/32596] [4.3 Regression] ICE with inline template specialization in anonymous namespace
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-15 15:31 --- Caused by PR31923. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32596
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
--- Comment #14 from manu at gcc dot gnu dot org 2007-08-15 15:36 --- Trying to improve the summary to help spot duplicates. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Summary|Missing uninitialized |V_MAY_DEF (taking address of |warning |var) causes missing ||uninitialized warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug bootstrap/33065] warning in Comparing stages 2 and 3: cd: stage3-gcc: No such file or directory
--- Comment #5 from mbo dot massimo at tiscali dot it 2007-08-15 15:56 --- Created an attachment (id=14063) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14063&action=view) make log of the build process log of the make produced during build gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33065
[Bug bootstrap/33065] warning in Comparing stages 2 and 3: cd: stage3-gcc: No such file or directory
--- Comment #6 from mbo dot massimo at tiscali dot it 2007-08-15 15:56 --- I tryed to build gcc in a different directory from the source directory and I obtained the following error: make[3]: Leaving directory `/home/compiler/build/temporary_build/build-gcc' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./libgcc/_chkstk.o differs Bootstrap comparison failure! ./ada/exp_aggr.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/compiler/build/temporary_build/build-gcc' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/compiler/build/temporary_build/build-gcc' make: *** [all] Error 2 The configure command was: ../gcc-4.2.1/configure \ --with-gnu-as --with-gnu-ld \ --enable-languages=c,c++,ada \ --with-gmp=/usr/local --with-mpfr=/usr/local \ --enable-threads=posix \ --disable-multilib \ --enable-shared \ --disable-win32-registry \ -v 2>&1 | tee configure.log In the attachment there is a new log of the make process: build_make_not_source_dir.log.gz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33065
[Bug libstdc++/33080] Building libstdc++ with static libgcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-15 16:44 --- Use --disable-shared --enable-shared=libstdc++, libffi,ada,libada,libjava,libobjc instead. Anyways you don't want to use the static version of libgcc in many places, because exceptions will not always work now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33080
[Bug c++/26068] [4.0 Regression] extern "C" static function should not be allowed
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-15 16:40 --- *** Bug 33078 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||room_debugs at outgesourced ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26068
[Bug c++/31382] Internal compiler Error (Is this a bug?)
--- Comment #2 from pcarlini at suse dot de 2007-08-15 16:37 --- Feedback not forthcoming... -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31382
[Bug c++/33078] g++ treats extern "c" static void foo(void); different to extern "c" {static void foo(void);}
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-15 16:40 --- This is on purpose. *** This bug has been marked as a duplicate of 26068 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33078
[Bug c++/31132] [4.1/4.2/4.3 regression] ICE on inconsistent friend declaration
--- Comment #2 from pcarlini at suse dot de 2007-08-15 17:07 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31132
[Bug target/33075] (mingw) Dwarf2-EH causes stack leak with VLA
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-15 17:14 --- >gcc version 3.4.5 (mingw special) Can you try the trunk as it was the officially (for FSF versions) got dwarf2 eh support recently for win32? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33075
[Bug tree-optimization/33082] New: [4.3 Regression] Revision 127491 causes FAIL: gcc.dg/dfp/convert-bfp-fold.c (test for excess errors)
This patch http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00705.html causes [EMAIL PROTECTED] rrs]$ /export/gnu/import/rrs/127491/usr/bin/gcc -O /export/gnu/import/rrs/127491/src/gcc/testsuite/gcc.dg/dfp/convert-bfp-fold.c /tmp/cc2dvlFs.o: In function `main': convert-bfp-fold.c:(.text+0x3a): undefined reference to `link_error' convert-bfp-fold.c:(.text+0x64): undefined reference to `link_error' convert-bfp-fold.c:(.text+0xc8): undefined reference to `link_error' convert-bfp-fold.c:(.text+0xf2): undefined reference to `link_error' convert-bfp-fold.c:(.text+0x16c): undefined reference to `link_error' /tmp/cc2dvlFs.o:convert-bfp-fold.c:(.text+0x192): more undefined references to `link_error' follow collect2: ld returned 1 exit status [EMAIL PROTECTED] rrs]$ -- Summary: [4.3 Regression] Revision 127491 causes FAIL: gcc.dg/dfp/convert-bfp-fold.c (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33082
[Bug tree-optimization/33082] [4.3 Regression] Revision 127491 causes FAIL: gcc.dg/dfp/convert-bfp-fold.c (test for excess errors)
--- Comment #1 from hjl at lucon dot org 2007-08-15 17:37 --- I saw it on both Linux/ia32 and Linux/x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33082
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #13 from andreasmeier80 at gmx dot de 2007-08-15 18:50 --- Fixed -- andreasmeier80 at gmx dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug c++/32364] Error from simple typedef/void combination
--- Comment #2 from craig dot powers at gmail dot com 2007-08-15 19:08
---
(In reply to comment #0)
> Came across this head-scratcher in building Qt with GCC 4.2.0. Heavily
> simplified version:
>
> foo.cxx:
> typedef void (*funcptr)(void);
>
> typedef void GLvoid;
> typedef GLvoid (*_GLUfuncptr)(GLvoid);
>
> int foo(void) { return 1; }
>
> $ g++ -c foo.cxx
> foo.cxx:4: error: '' has incomplete type
> foo.cxx:4: error: invalid use of 'GLvoid'
>
> Compiles fine with 4.1.2 and 2.95.4.
>
You can patch GL/glu.h as e.g.
#ifdef __cplusplus
typedef void (*_GLUfuncptr)(void);
#else
typedef GLvoid (*_GLUfuncptr)(GLvoid);
#endif
I'm assuming that the line that now fails to compile in C++ is still valid C.
I'll admit, I don't really see the point to using a typedef for void.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32364
[Bug c++/32364] Error from simple typedef/void combination
--- Comment #3 from craig dot powers at gmail dot com 2007-08-15 19:13 --- Looking at CVS for glu.h, the official patch is: #ifdef __cplusplus typedef GLvoid (*_GLUfuncptr)(); #else ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32364
[Bug target/32963] ICE in failed_reload, could not find a spill register
--- Comment #5 from sje at gcc dot gnu dot org 2007-08-15 20:08 --- Subject: Bug 32963 Author: sje Date: Wed Aug 15 20:08:43 2007 New Revision: 127523 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127523 Log: PR target/32963 caller-save.c (reg_save_code): Set invalide status on restore code. Modified: trunk/gcc/ChangeLog trunk/gcc/caller-save.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32963
[Bug target/32963] ICE in failed_reload, could not find a spill register
--- Comment #6 from sje at cup dot hp dot com 2007-08-15 20:12 --- Fixed with patch to caller-save.c -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32963
[Bug target/32963] [4.3 Regression] ICE in failed_reload, could not find a spill register
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in failed_reload, could |[4.3 Regression] ICE in |not find a spill register |failed_reload, could not ||find a spill register Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32963
[Bug target/33011] [4.3 Regression] frv: error: bad output_move_single operand
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-15 20:46 --- Can you try after revision 127523? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33011
[Bug c/33083] New: noreturn function should be invoked via JMP
When a noreturn function is called, the compiler should emit a "jmp"
instruction rather than "call", because the called function will not return.
Saving callee-save registers in the function prologue also seems unnecessary
since there won't be an epilogue to restore them.
The following example uses 'noinline' to prevent gcc from inlining these
trivial functions.
#define NOINLINE __attribute__((noinline))
#define NORETURN __attribute__((noreturn))
NORETURN NOINLINE
static void f1()
{
for (;;);
}
NORETURN NOINLINE
static void f2()
{
f1();
}
int main()
{
f2();
return 0;
}
This results in the following code:
08048228 :
8048228: 55 push %ebp
8048229: 89 e5 mov%esp,%ebp
804822b: eb fe jmp804822b
0804822d :
804822d: 55 push %ebp
804822e: 89 e5 mov%esp,%ebp
8048230: e8 f3 ff ff ff call 8048228 <= this should
be jmp
--
Summary: noreturn function should be invoked via JMP
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: us15 at os dot inf dot tu-dresden dot de
GCC build triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33083
[Bug target/33075] (mingw) Dwarf2-EH causes stack leak with VLA
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-08-16 05:59 --- This executes with no stack growth on mingw32 4.3.0 with Dwarf2 EH unwind. Ditto for 4.2.1. I think this may be related to the deallocation problem reported in PR 19771 Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33075
[Bug target/33075] (mingw) Dwarf2-EH causes stack leak with VLA
--- Comment #3 from darkxun at paran dot com 2007-08-16 06:14 --- Sorry, you are right, I found "Technology Preview: gcc-4.2.1-dw2-2" binaries at mingw Sourceforge site released a few days ago. And it works good! I should have checked it at least. Please close this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33075
[Bug tree-optimization/33082] [4.3 Regression] Revision 127491 causes FAIL: gcc.dg/dfp/convert-bfp-fold.c (test for excess errors)
--- Comment #2 from ubizjak at gmail dot com 2007-08-16 06:50 --- (In reply to comment #1) > I saw it on both Linux/ia32 and Linux/x86-64. -O2 is needed to reliably fold these testcases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33082
