[Bug testsuite/36292] [4.4 Regression]: Many failures in gcc.dg/pch/
--- Comment #3 from nathan at gcc dot gnu dot org 2008-05-22 06:33 --- 2008-05-22 Nathan Sidwell [EMAIL PROTECTED] * lib/dg-pch.exp (dg-pch): Fix if bracing. -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36292
[Bug c/36296] New: wrong warning about potential uninitialized variable
When compiling mpfr-2.3.1 with gcc-4.3, one gets the following warning
(among others):
{{{
lngamma.c: In function 'mpfr_lngamma_aux':
lngamma.c:160: warning: 'B' may be used uninitialized in this function
}}}
However, looking at the code shows that this variable cannot be used
uninitialized:
* a variable Bm is initialized to zero
* if Bm=0, B is initialized using an auxiliary function, and Bm is set to 2
(this code is in a do { ... } while loop, thus is always executed)
--
Summary: wrong warning about potential uninitialized variable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zimmerma+gcc at loria dot fr
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug c++/36297] New: false warning: 'variable' may be used uninitialized in this function
The follwoing code generates warning
warning: 'i' may be used uninitialized in this function
Code is compiled with g++ -O1 -Wall -c file.cpp -o file.o
on x86_64 Fedora Core 6 (2.6.22.9-61.fc6)
with gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
Changing code in almost any way (like removing destructor) disables the
warning.
class ObjBase {
public:
virtual ~ObjBase() {}
};
class Obj : public ObjBase {
int _c;
public:
Obj(int c) : _c(c){};
};
int _Find(const Obj key);
inline bool Find(const Obj key, int v)
{
static bool flag=true;
if (!flag) {
return false;
}
v=_Find(key);
return true;
}
int f() {
int i;
if (Find(0, i)) {
return i;
}
return 0;
}
int _Find(const Obj key){return 0;}
--
Summary: false warning: 'variable' may be used uninitialized in
this function
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paskhaver at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36297
[Bug c++/36297] false warning: 'variable' may be used uninitialized in this function
--- Comment #1 from paskhaver at yahoo dot com 2008-05-22 07:47 --- Created an attachment (id=15668) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15668action=view) result of -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36297
[Bug c++/36297] false warning: 'variable' may be used uninitialized in this function
--- Comment #2 from paskhaver at yahoo dot com 2008-05-22 07:48 --- Created an attachment (id=15669) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15669action=view) result of -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36297
[Bug libgomp/36298] New: gomp contains small memoryleak
Compiling the following piece of code shows a memoryleak when investigated with
valgrind.
int main() {
#pragma omp parallel for
for (int i = 100; i = 0; --i) {
}
return 0;
}
Below you find everything you need to know (i think). If something is missing,
let me know.
Regards
Klaas
[EMAIL PROTECTED] openmp]$ g++ -v
Using built-in specs.
Target: x86_64-manbo-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java
--host=x86_64-manbo-linux-gnu --with-cpu=generic --with-system-zlib
--enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp
Thread model: posix
gcc version 4.2.3 (4.2.3-6mnb1)
[EMAIL PROTECTED] openmp]$ cat memleak.cpp
int main() {
#pragma omp parallel for
for (int i = 100; i = 0; --i) {
}
return 0;
}
[EMAIL PROTECTED] openmp]$ g++ --openmp memleak.cpp
[EMAIL PROTECTED] openmp]$ valgrind --leak-check=full --show-reachable=yes
./a.out
==11971== Memcheck, a memory error detector.
==11971== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==11971== Using LibVEX rev 1804, a library for dynamic binary translation.
==11971== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==11971== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==11971== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==11971== For more details, rerun with: -v
==11971==
==11971==
==11971== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1)
==11971== malloc/free: in use at exit: 328 bytes in 2 blocks.
==11971== malloc/free: 5 allocs, 3 frees, 1,032 bytes allocated.
==11971== For counts of detected errors, rerun with: -v
==11971== searching for pointers to 2 not-freed blocks.
==11971== checked 8,585,392 bytes.
==11971==
==11971== 24 bytes in 1 blocks are still reachable in loss record 1 of 2
==11971==at 0x4C1ED1B: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==11971==by 0x4C1EE64: realloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==11971==by 0x53AB288: (within /usr/lib64/libgomp.so.1.0.0)
==11971==by 0x53AD4A0: (within /usr/lib64/libgomp.so.1.0.0)
==11971==by 0x4006CF: main (in /home/klaas/devel/testing/openmp/a.out)
==11971==
==11971==
==11971== 304 bytes in 1 blocks are possibly lost in loss record 2 of 2
==11971==at 0x4C1DE2C: calloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==11971==by 0x400FE62: _dl_allocate_tls (dl-tls.c:300)
==11971==by 0x57C3B41: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.7.so)
==11971==by 0x53AD3BE: (within /usr/lib64/libgomp.so.1.0.0)
==11971==by 0x4006CF: main (in /home/klaas/devel/testing/openmp/a.out)
==11971==
==11971== LEAK SUMMARY:
==11971==definitely lost: 0 bytes in 0 blocks.
==11971== possibly lost: 304 bytes in 1 blocks.
==11971==still reachable: 24 bytes in 1 blocks.
==11971== suppressed: 0 bytes in 0 blocks.
[EMAIL PROTECTED] openmp]$
--
Summary: gomp contains small memoryleak
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Klaas dot Vantournhout at UGent dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36298
[Bug middle-end/36296] wrong warning about potential uninitialized variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-22 08:22 --- It is most likely the case, that we have to use predicated PHI nodes to detect that the variable is no unitialized. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug middle-end/36296] wrong warning about potential uninitialized variable
--- Comment #2 from vincent at vinc17 dot org 2008-05-22 08:34 --- The severity should probably be changed to enhancement because gcc behaves as documented (well, almost). What can be done IMHO is: 1. Split the -Wuninitialized into two different warnings: one for which gcc knows that the variable is uninitialized and one for which it cannot decide. -Wuninitialized currently does both. 2. Provide an extension so that the user can tell gcc not to emit a warning for some particular variable. This would sometimes be better than adding a dummy initialization (which has its own drawbacks). In the mean time, make the documentation better concerning -Wuninitialized: change the first sentence Warn if an automatic variable is used without first being initialized [...] to Warn if an automatic variable *may be* used without first being initialized (though the behavior is detailed later). -- vincent at vinc17 dot org changed: What|Removed |Added CC||vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug c/36299] New: spurious and undocumented warning with -Waddress for a == 0 when a is an array
With -Waddress (implied by -Wall), I get the following warning when I use the
test a == 0 where a is an array: the address of 'a' will never be NULL. This
behavior is undocumented and inconsistent (see below). Here's a testcase:
int main (void)
{
char a[1], *b;
b = a;
if (a == 0)
return 1;
else if (a == (void *) 0)
return 2;
else if (b == 0)
return 3;
else if (b == (void *) 0)
return 4;
return 0;
}
gcc warns only for a == 0 (and this is OK to use 0 instead of (void *) 0
because it is a valid form for a null pointer constant).
Moreover this is very similar to code like
if (1) ...
or code given in bug 12963, for which gcc no longer emits warnings: indeed such
kind of correct and useful code is typically used in macros.
--
Summary: spurious and undocumented warning with -Waddress for a
== 0 when a is an array
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
[Bug middle-end/36296] wrong warning about potential uninitialized variable
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-22 10:21 --- A way to tell gcc a variable is not uninitialized is to perform self-initialization like int i = i; this will cause no code generation but inhibits the warning. Other compilers may warn about this construct of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug middle-end/36294] gcc exited and told me to report a bug (details follow)
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-22 10:17 --- Please attach the gtk.i file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
[Bug tree-optimization/36293] ICE or wrong code in vector-strided gap tests
--- Comment #2 from irar at gcc dot gnu dot org 2008-05-22 10:41 --- Subject: Bug 36293 Author: irar Date: Thu May 22 10:41:00 2008 New Revision: 135756 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135756 Log: PR tree-optimization/36293 * tree-vect-transform.c (vect_transform_strided_load): Don't check if the first load must be skipped because of a gap. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36293
[Bug tree-optimization/36293] ICE or wrong code in vector-strided gap tests
--- Comment #3 from irar at il dot ibm dot com 2008-05-22 10:48 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36293
[Bug tree-optimization/36293] ICE or wrong code in vector-strided gap tests
--- Comment #1 from irar at gcc dot gnu dot org 2008-05-22 10:40 --- Subject: Bug 36293 Author: irar Date: Thu May 22 10:39:44 2008 New Revision: 135755 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135755 Log: PR tree-optimization/36293 * tree-vect-transform.c (vect_transform_strided_load): Don't check if the first load must be skipped because of a gap. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36293
[Bug middle-end/36296] wrong warning about potential uninitialized variable
--- Comment #4 from vincent at vinc17 dot org 2008-05-22 11:01 --- (In reply to comment #3) A way to tell gcc a variable is not uninitialized is to perform self-initialization like int i = i; This doesn't seem to be valid C code. this will cause no code generation but inhibits the warning. Other compilers may warn about this construct of course. Or worse, generate non-working code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug middle-end/36296] wrong warning about potential uninitialized variable
--- Comment #5 from vincent at vinc17 dot org 2008-05-22 11:23 ---
BTW, the i = i trick, which is guaranteed to be valid and no-op only *after* i
has been initialized doesn't avoid the warning in such a case. I don't know if
this would be a good feature (the main drawback I can see would be to miss
warnings when this is a result of macro expansion). For instance:
#include assert.h
int foo (int x)
{
int y;
assert (x == 0 || x == 1);
if (x == 0)
y = 1;
else if (x == 1)
y = 2;
y = y; /* to tell the compiler that y has been initialized */
return y;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug ada/34898] Excessive memory consumption during compilation
--- Comment #2 from oliver dot kellogg at eads dot com 2008-05-22 11:23 --- Still happens with 4.4.0 20080522. Please advise if there is any further info that I could provide to help track the problem down. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-22 12:28 --- One slow leaker of memory for large TUs is the operands_bitmap_obstack from the operand scanner. From it the stmt annotation loaded and stored symbols bitmaps are allocated but never freed until after the last function has gone out of SSA. We should consider moving these to GC memory or to add support for using alloc pools for bitmap allocations. Memory partitioning uses loads of bitmaps for the parent tags: tree-ssa-alias.c:1311 (update_reference_c 5424467 433957360 433957360 433957360 76199616 Likewise PTA still does that: tree-ssa-structalias.c:4850 (find_what_p_ 62908 555059880 42045880 42032640 62415 Overall the variable annotations account for most of the GC memory used: tree-ssanames.c:146 (make_ssa_name_fn) 33297312: 2.1% 0: 0.0% 0: 0.0% 0: 0.0% 346847 bitmap.c:229 (bitmap_element_allocate)116709320: 7.4% 0: 0.0% 0: 0.0% 16672760:11.7%2084095 ggc-common.c:179 (ggc_calloc) 409212224:25.8% 12684056: 5.0%1974632: 2.2%4572784: 3.2% 194426 tree-dfa.c:153 (create_var_ann) 482008296:30.4% 0: 0.0% 0: 0.0% 43818936:30.6%5477367 Total1586488294255567175 90963544143104669 18411405 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-22 12:35 --- On the trunk things look different: tree find ref. vars : 22.59 (13%) usr 1.08 (13%) sys 24.42 (14%) wall 815888 kB (47%) ggc tree PTA : 1.43 ( 1%) usr 0.08 ( 1%) sys 1.39 ( 1%) wall 19446 kB ( 1%) ggc tree alias analysis : 5.64 ( 3%) usr 0.15 ( 2%) sys 5.71 ( 3%) wall 1611 kB ( 0%) ggc tree call clobbering : 15.15 ( 9%) usr 0.07 ( 1%) sys 15.56 ( 9%) wall 613 kB ( 0%) ggc tree flow sensitive alias: 1.85 ( 1%) usr 0.09 ( 1%) sys 2.06 ( 1%) wall 96898 kB ( 6%) ggc tree flow insensitive alias: 1.79 ( 1%) usr 0.00 ( 0%) sys 1.68 ( 1%) wall 0 kB ( 0%) ggc tree memory partitioning: 38.40 (23%) usr 0.53 ( 7%) sys 38.68 (22%) wall 820 kB ( 0%) ggc tree operand scan : 11.31 ( 7%) usr 0.16 ( 2%) sys 11.76 ( 7%) wall 58545 kB ( 3%) ggc TOTAL : 169.77 8.02 177.99 1747899 kB but the memory situation isn't different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-22 12:48 --- The root of all evil is the following code in add_referenced_var(): /* Scan DECL_INITIAL for pointer variables as they may contain address arithmetic referencing the address of other variables. Even non-constant intializers need to be walked, because IPA passes might prove that their are invariant later on. */ if (DECL_INITIAL (var) /* Initializers of external variables are not useful to the optimizers. */ !DECL_EXTERNAL (var)) walk_tree (DECL_INITIAL (var), find_vars_r, NULL, 0); this causes us to basically add all globals to all functions referenced vars once they reference one of the chained structs. We shouldn't be doing this but instead who needs those vars should add them. I suppose the IPA passes thing is just the lack of a global DECL_UID to tree mapping. So I am going to try to change the above to /* Scan DECL_INITIAL for pointer variables as they may contain address arithmetic referencing the address of other variables. As we are only interested in directly referenced globals or referenced locals restrict this to initializers than can refer to local variables. */ if (DECL_INITIAL (var) DECL_CONTEXT (var) == current_function_decl) walk_tree (DECL_INITIAL (var), find_vars_r, NULL, 0); This gets memory usage down to about 700MB and compile time down to 50s. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-22 12:48:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug middle-end/36294] gcc exited and told me to report a bug (details follow)
--- Comment #3 from paulbeard at gmail dot com 2008-05-22 14:31 --- Created an attachment (id=15670) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15670action=view) gtk.i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-22 14:39 --- I added gcc.c-torture/execute/20080522-1.c which points at two problems. First we need to add referenced vars as they come (there is already find_new_referenced_vars and some users, tree-ssa-ccp.c:get_symbol_constant_value needs to do it as well). Second we need to update alias information. This turns out to be a hard problem. For the testcase we need to add 'i' to the symbols SMT.7 aliases and update all statements that reference SMT.7 - which is not easily possible and expensive. We probably also need to update flow-sensitive alias info which is even harder if not impossible. So it looks like this is a dead end sofar, but still the root of the problem remains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug other/36301] New: target mips64vrel-elf, configure-target-libiberty error
I ran into this error while attempting building 4.2.4 configured as below. Any suggestion is appreciated. thanks in advance. /* configuration */ CFLAGS=-O2 $DEPACK_DIR/gcc-4.2.4/configure --target=mips64vrel-elf \ --prefix=$PREFIX_DIR --enable-languages=c,c++ --disable-__cxa_atexit \ --with-gnu-as --with-gnu-ld --with-newlib \ --with-gxx-include-dir=$PREFIX_DIR/mips64vrel-elf/include -v \ 21 | tee configure.log /* error: */ ...snip... Adding multilib support to Makefile in /ecostools/src/gcc-4.2.4/libiberty with_multisubdir=long64/vr5000 Running configure in multilib subdir long64/vr5400 pwd: /tmp/build-mips64vrel-elf-20080520/gcc/mips64vrel-elf configure: creating cache ./config.cache checking whether to enable maintainer-specific portions of Makefiles... no checking for makeinfo... makeinfo --split-size=500 checking for perl... perl checking build system type... i686-pc-cygwin checking host system type... mips64vrel-unknown-elf checking for mips64vrel-elf-ar... /ecostools/mips64vrel-elf-20080520/mips64vrel- elf/bin/ar checking for mips64vrel-elf-ranlib... /ecostools/mips64vrel-elf-20080520/mips64v rel-elf/bin/ranlib checking for mips64vrel-elf-gcc... /tmp/build-mips64vrel-elf-20080520/gcc/./gcc/ xgcc -B/tmp/build-mips64vrel-elf-20080520/gcc/./gcc/ -nostdinc -B/tmp/build-mips 64vrel-elf-20080520/gcc/mips64vrel-elf/newlib/ -isystem /tmp/build-mips64vrel-el f-20080520/gcc/mips64vrel-elf/newlib/targ-include -isystem /ecostools/src/gcc-4. 2.4/newlib/libc/include -B/ecostools/mips64vrel-elf-20080520/mips64vrel-elf/bin/ -B/ecostools/mips64vrel-elf-20080520/mips64vrel-elf/lib/ -isystem /ecostools/mi ps64vrel-elf-20080520/mips64vrel-elf/include -isystem /ecostools/mips64vrel-elf- 20080520/mips64vrel-elf/sys-include checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /tmp/build-mips64vrel-elf-20080520/gcc/./gcc/xgcc -B/tmp/build- mips64vrel-elf-20080520/gcc/./gcc/ -nostdinc -B/tmp/build-mips64vrel-elf-2008052 0/gcc/mips64vrel-elf/newlib/ -isystem /tmp/build-mips64vrel-elf-20080520/gcc/mip s64vrel-elf/newlib/targ-include -isystem /ecostools/src/gcc-4.2.4/newlib/libc/in clude -B/ecostools/mips64vrel-elf-20080520/mips64vrel-elf/bin/ -B/ecostools/mips 64vrel-elf-20080520/mips64vrel-elf/lib/ -isystem /ecostools/mips64vrel-elf-20080 520/mips64vrel-elf/include -isystem /ecostools/mips64vrel-elf-20080520/mips64vre l-elf/sys-include accepts -g... yes checking for /tmp/build-mips64vrel-elf-20080520/gcc/./gcc/xgcc -B/tmp/build-mips 64vrel-elf-20080520/gcc/./gcc/ -nostdinc -B/tmp/build-mips64vrel-elf-20080520/gc c/mips64vrel-elf/newlib/ -isystem /tmp/build-mips64vrel-elf-20080520/gcc/mips64v rel-elf/newlib/targ-include -isystem /ecostools/src/gcc-4.2.4/newlib/libc/includ e -B/ecostools/mips64vrel-elf-20080520/mips64vrel-elf/bin/ -B/ecostools/mips64vr el-elf-20080520/mips64vrel-elf/lib/ -isystem /ecostools/mips64vrel-elf-20080520/ mips64vrel-elf/include -isystem /ecostools/mips64vrel-elf-20080520/mips64vrel-el f/sys-include option to accept ANSI C... none needed checking how to run the C preprocessor... /tmp/build-mips64vrel-elf-20080520/gcc /./gcc/xgcc -B/tmp/build-mips64vrel-elf-20080520/gcc/./gcc/ -nostdinc -B/tmp/bui ld-mips64vrel-elf-20080520/gcc/mips64vrel-elf/newlib/ -isystem /tmp/build-mips64 vrel-elf-20080520/gcc/mips64vrel-elf/newlib/targ-include -isystem /ecostools/src /gcc-4.2.4/newlib/libc/include -B/ecostools/mips64vrel-elf-20080520/mips64vrel-e lf/bin/ -B/ecostools/mips64vrel-elf-20080520/mips64vrel-elf/lib/ -isystem /ecost ools/mips64vrel-elf-20080520/mips64vrel-elf/include -isystem /ecostools/mips64vr el-elf-20080520/mips64vrel-elf/sys-include -E checking whether /tmp/build-mips64vrel-elf-20080520/gcc/./gcc/xgcc -B/tmp/build- mips64vrel-elf-20080520/gcc/./gcc/ -nostdinc -B/tmp/build-mips64vrel-elf-2008052 0/gcc/mips64vrel-elf/newlib/ -isystem /tmp/build-mips64vrel-elf-20080520/gcc/mip s64vrel-elf/newlib/targ-include -isystem /ecostools/src/gcc-4.2.4/newlib/libc/in clude -B/ecostools/mips64vrel-elf-20080520/mips64vrel-elf/bin/ -B/ecostools/mips 64vrel-elf-20080520/mips64vrel-elf/lib/ -isystem /ecostools/mips64vrel-elf-20080 520/mips64vrel-elf/include -isystem /ecostools/mips64vrel-elf-20080520/mips64vre l-elf/sys-include accepts -Wc++-compat... yes checking whether /tmp/build-mips64vrel-elf-20080520/gcc/./gcc/xgcc -B/tmp/build- mips64vrel-elf-20080520/gcc/./gcc/ -nostdinc -B/tmp/build-mips64vrel-elf-2008052 0/gcc/mips64vrel-elf/newlib/ -isystem /tmp/build-mips64vrel-elf-20080520/gcc/mip s64vrel-elf/newlib/targ-include -isystem /ecostools/src/gcc-4.2.4/newlib/libc/in clude -B/ecostools/mips64vrel-elf-20080520/mips64vrel-elf/bin/ -B/ecostools/mips 64vrel-elf-20080520/mips64vrel-elf/lib/ -isystem /ecostools/mips64vrel-elf-20080
[Bug c/36300] New: Incorrect type used for inlined expression
System: Debian 2.6.22.8-mw017 GCC: gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) In the expression below: - VALUE has type uint32_T - Y gets a wrong result. - If VALUE is assigned to an int32_T variable, and the variable is used instead of VALUE, Y gets the correct result. See attached file missing_downcast.c for more details and reproduction steps - #define VALUE ((int32_T)((int64_T)U1 * (int64_T)3 2) + 2) Y = (int32_T)( (int64_T)(VALUE * VALUE) * (int64_T)954437177 29 ); -- Summary: Incorrect type used for inlined expression Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: acarmeli at mathworks dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug c/36300] Incorrect type used for inlined expression
--- Comment #1 from acarmeli at mathworks dot com 2008-05-22 14:43 --- Created an attachment (id=15671) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15671action=view) Wrong result if expression is inlined At the bottom of the file there are: - Instructions on how to compile - Version of OS and GCC on which it failed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug libfortran/36302] New: cshift and eoshift missing some kind=16 functions
As seen on the bottom of eoshift0.c and eoshift2.c: DEFINE_EOSHIFT (1); DEFINE_EOSHIFT (2); DEFINE_EOSHIFT (4); DEFINE_EOSHIFT (8); Similar for cshift0.c. I'll fix this. -- Summary: cshift and eoshift missing some kind=16 functions Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: tkoenig at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36302
[Bug libfortran/36302] cshift and eoshift missing some kind=16 functions
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-22 15:17:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36302
ada bug experimenting with limited_with
While experimenting with limited with as described in John Barnes Ada 2005 Rationale - Structure and visibility the following problem came up when trying to call Employees.Assign_Employee from Departments. The attachment contains the complete program compilation proceeded as follows: [EMAIL PROTECTED]:~/bugreport$ gnatmake main gcc-4.2 -c departments.adb +===GNAT BUG DETECTED==+ | 4.2.1 (Ubuntu 4.2.1-5ubuntu6) (i486-pc-linux-gnu) Assert_Failure sinfo.adb:1731| | Error detected at departments.adb:13:16 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.2 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. departments.adb departments.ads employees.ads compilation abandoned gnatmake: departments.adb compilation error
[Bug c/36300] Incorrect type used for inlined expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-22 16:10 ---
t = (int) ((long int) U1 * 3 2) + 2;
Y = (int) ((long int) (t * t) * 954437177 29);
if combined is folded to
Y = (int) (((long int) (int) ((long int) U1 * 3 2) * 954437177 +
1908874354) * (long int) ((int) ((long int) U1 * 3 2) + 2) 29);
We can see that for
int foo(int x)
{
return (long)(((int)((long)x * 3) + 2) * (int)((long)x * 3)) * 2;
}
the conversion to long is distributed on the operands and the
multiplication by 2 is then re-associated.
I bet this is extract_muldiv at its work again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||4.1.3 4.2.4 4.3.0
Last reconfirmed|-00-00 00:00:00 |2008-05-22 16:10:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug middle-end/36300] Incorrect type used for inlined expression
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-22 16:11 --- I will try to have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|c |middle-end Last reconfirmed|2008-05-22 16:10:38 |2008-05-22 16:11:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug libgcj/35020] Class.getSimpleName() differs from Sun Java
--- Comment #3 from aph at gcc dot gnu dot org 2008-05-22 16:21 --- Subject: Bug 35020 Author: aph Date: Thu May 22 16:20:55 2008 New Revision: 135771 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135771 Log: 2008-05-22 Andrew Haley [EMAIL PROTECTED] PR libgcj/35020 * java/lang/Class.java (getSimpleName): Import from GNU Classpath. Modified: trunk/libjava/ChangeLog trunk/libjava/classpath/lib/java/lang/Class$1.class trunk/libjava/classpath/lib/java/lang/Class.class trunk/libjava/java/lang/Class.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35020
[Bug c/36303] New: location list incomplete for spilled registers
Location list created for the following test case is incomplete for parameter
p1:
cc1 -v -dD fs.c -dA -m64 -mcmodel=small -gdwarf-2 -O2 -fno-omit-frame-pointer
-quiet
typedef struct s2 {
unsigned short f1;
unsigned short length;
char data[64];
} s2;
int func(s2 *p1, const char *p2)
{
if (((_LogEffectiveLevel(57)) = (3))) {
_Log(abc,
(__FUNCTION__+((__FUNCTION__[(sizeof(FSS) - 1)] == '_') ?
(sizeof(FSS) - 1) + 1 : (sizeof(FSS) - 1))),
237 ,
(p1)-f1,
(p1)-length,
*((unsigned int *)((p1)-data[0])),
*((unsigned int *)((p1)-data[4])),
*((unsigned int *)((p1)-data[8])),
*((unsigned int *)((p1)-data[12])),
*((unsigned int *)((p1)-data[16])),
*((unsigned int *)((p1)-data[20])),
*((unsigned int *)((p1)-data[24])),
*((unsigned int *)((p1)-data[28])),
*((unsigned long *)((p1)-data[32])),
*((unsigned long *)((p1)-data[40])),
*((unsigned long *)((p1)-data[48])),
*((unsigned long *)((p1)-data[56])), p2);
}
return 0;
}
The generated assembly shows the following:
.uleb128 0xb# (DIE (0xb2) DW_TAG_formal_parameter)
.ascii p1\0 # DW_AT_name
.byte 0x1 # DW_AT_decl_file (fs.c)
.byte 0x8 # DW_AT_decl_line
.long 0xea# DW_AT_type
.long .LLST1 # DW_AT_location
.LLST1:
.quad .LVL0-.Ltext0 # Location list begin address (*.LLST1)
.quad .LVL1-.Ltext0 # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x55# DW_OP_reg5
.quad .LVL1-.Ltext0 # Location list begin address (*.LLST1)
.quad .LVL2-.Ltext0 # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x5b# DW_OP_reg11
.quad .LVL4-.Ltext0 # Location list begin address (*.LLST1)
.quad .LVL5-.Ltext0 # Location list end address (*.LLST1)
.value 0x1 # Location expression size
.byte 0x5b# DW_OP_reg11
.quad 0x0 # Location list terminator begin (*.LLST1)
.quad 0x0 # Location list terminator end (*.LLST1)
This does not cover instructions between .LVL2 and .LVL4.
Looking at the assembly, you see that R11 is being saved to the stack across
the call to _LogEffectiveLevel() and then reloaded *before* .LVL4:
# fs.c:10
.LM4:
movq%r11, -48(%rbp)
.LVL2:
call_LogEffectiveLevel
.LVL3:
cmpl$2, %eax
movq-48(%rbp), %r11
jle .L2
# basic block 3
# fs.c:11
.LM5:
movl28(%r11), %ecx
.LVL4:
movq60(%r11), %rax
movq52(%r11), %rdx
So when gdb is stopped at line fs.c:11 it reports that p1's value is optimized
out.
I debugged var-tracking.c, and it does not look like it is tracking duplicate
locations, such as when a register is saved and restored from the stack.
It's also possible that one of the previous passes does not give enough
information to var-tracking.c about the variable being saved/restored.
I can see the following in the var tracking output:
(insn:TI 7 102 107 2 fs.c:10 (set (reg:SI 5 di)
(const_int 57 [0x39])) 47 {*movsi_1} (nil))
(note 107 7 83 2 ( p1 (expr_list:REG_DEP_TRUE (reg/v/f:DI 40 r11 [orig:75 p1 ]
[75])
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(insn 78 90 108 2 fs.c:10 (set (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -48 [0xffd0])) [10 S8 A8])
(reg:DI 40 r11)) 89 {*movdi_1_rex64} (expr_list:REG_DEAD (reg:DI 40
r11)
(nil)))
(note 108 78 9 2 ( p1 (nil)) NOTE_INSN_VAR_LOCATION)
(insn 79 11 12 2 fs.c:10 (set (reg:DI 40 r11)
(mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -48 [0xffd0])) [10 S8 A8])) 89
{*movdi_1_rex64} (nil))
It seems that when r11 is saved in insn 78 and reloaded in insn 79 it is not
marked as containing p1.
Unfortunately I don't have enough knowledge to continue debugging gcc to be
sure it's var-tracking.c or someone else's fault.
This happens with gcc 4.2.3 and gcc 4.3.0.
It does not happen with -O1, or if I remove even a single parameter from the
call to _LogEffectiveLevel().
However we observe a lot of value optimized out messages in other parts of
our code, and most of the time I tracked it to incomplete info in the location
list.
I hope this is enough information. Let me know if you need more.
Thanks,
Giampiero Caprino
--
Summary: location list incomplete for spilled registers
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcaprino at gmail dot com
GCC host triplet: host-i686-pc-linux-gnu
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36303
[Bug middle-end/36303] location list incomplete for spilled registers
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-22 17:15 --- This code also does violates C aliasing rules. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36303
[Bug fortran/29600] MINLOC, MAXLOC and SHAPE take an optional KIND argument
--- Comment #6 from jb at gcc dot gnu dot org 2008-05-22 18:13 --- The proper solution, which as a side effect would take care of the combinatorial explosion issue as well, would be to inline these intrinsics. See also PR 31067. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
[Bug middle-end/36303] location list incomplete for spilled registers
--- Comment #2 from gcaprino at gmail dot com 2008-05-22 18:15 --- (In reply to comment #1) This code also does violates C aliasing rules. I'm sorry, but I don't understand what you mean. Do you think there is a problem with the code portion such that it's not legal, safe C code? (btw this is part of a larger function which I reduced to facilitate debugging of this issue). It seems to me that nothing can change the value of p1, since no addresses are taken to write into the stack. p2 could point inside the structure pointed by p1, but it should not be possible for p2 to point at p1, right? Besides, p2 is only used after the register is saved/reloaded from the stack. Could you elaborate? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36303
[Bug target/35658] [4.3/4.4 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable
--- Comment #5 from sje at cup dot hp dot com 2008-05-22 18:52 --- Created an attachment (id=15672) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15672action=view) cutdown test case This smaller test case requires the same options as the original. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
[Bug target/35658] [4.3/4.4 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable
-- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-22 18:52:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-22 19:15 --- As noted in comment #1 variable annotations are a major problem (they are duplicated for global variables, for each function the variable is referenced from). It happens that sharing variable annotations for globals between functions reduces peak memory usage by 1GB. So that's were I'm currently looking at. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-22 19:22 --- That is, var annotations back to sanity: tree-dfa.c:150 (create_var_ann) 206016: 0.0% 15094400: 3.2% 142592: 0.1% 0: 0.0% 241297 compared to originally tree-dfa.c:153 (create_var_ann) 482008296:30.4% 0: 0.0% 0: 0.0% 43818936:30.6%5477367 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug treelang/24771] treelang does not have a man page
--- Comment #2 from tromey at gcc dot gnu dot org 2008-05-22 19:51 --- Treelang has been removed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24771
[Bug treelang/25341] tree_code_create_variable does not handle global variables properly
--- Comment #1 from tromey at gcc dot gnu dot org 2008-05-22 19:52 --- Treelang has been removed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25341
[Bug bootstrap/36243] make install doesn�t work under WinXP/cygwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-22 19:57 --- I can do a make install on the trunk using Windows Vista cygwin just fine. How did you configure GCC? Did you build in the source tree? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|other |bootstrap GCC target triplet||i?86-*-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36243
[Bug fortran/36276] [4.3/4.4 Regression] possible issue with opening fortran files?
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug c/36299] spurious and undocumented warning with -Waddress for a == 0 when a is an array
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-22 20:00 --- if (a == 0) return 1; else if (a == (void *) 0) Those two should warn about being address being zero. a decays to a pointer type and really a[0]. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
[Bug tree-optimization/36293] [4.3/4.4 Regression] ICE or wrong code in vector-strided gap tests
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to work||4.3.0 Summary|ICE or wrong code in vector-|[4.3/4.4 Regression] ICE or |strided gap tests |wrong code in vector-strided ||gap tests Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36293
[Bug middle-end/36294] gcc exited and told me to report a bug (details follow)
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-22 20:02 --- GCC is running out of memory. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
[Bug middle-end/36213] Wrong search path generation
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-22 20:07 --- Is there a reason why you use --enable-version-specific-runtime-libs ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|preprocessor|middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
[Bug tree-optimization/36218] [4.4 regression] VRP causes stack overflow while building libgcj
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|libgcj |tree-optimization Keywords|memory-hog | Summary|[4.4 regression] libgcj |[4.4 regression] VRP causes |causes stack overflow in|stack overflow while |jc1.exe |building libgcj Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug tree-optimization/36218] [4.2/4.3/4.4 regression] VRP causes stack overflow while building libgcj
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-22 20:10 --- VRP did not exist in 4.0.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to work||4.0.0 Summary|[4.4 regression] VRP causes |[4.2/4.3/4.4 regression] VRP |stack overflow while|causes stack overflow while |building libgcj |building libgcj Target Milestone|4.4.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug fortran/36233] [4.3/4.4 Regression] Array valued actual procedure argument rejected
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[Regression 4.4,4.3] Array |[4.3/4.4 Regression] Array |valued actual procedure |valued actual procedure |argument rejected |argument rejected Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36233
[Bug middle-end/36213] Wrong search path generation
--- Comment #3 from martin dot drab at fjfi dot cvut dot cz 2008-05-22 21:51 --- Is using --enable-version-specific-runtime-libs the problem? Should it not be used? I use it because from time to time I have more than one version installed at the same time. Do you say that it should not be used? I'll try if it gets any better that way, then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
[Bug libfortran/36302] cshift and eoshift missing some kind=16 functions
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-05-22 21:56 --- Subject: Bug 36302 Author: tkoenig Date: Thu May 22 21:55:43 2008 New Revision: 135777 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135777 Log: 2008-05-22 Thomas Koenig [EMAIL PROTECTED] PR libgfortran/36302 * gfortran.map (GFORTRAN_1.1): Add _gfortran_eoshift0_16, _gfortran_eoshift0_16_char, _gfortran_eoshift2_16, _gfortran_eoshift2_16_char,_gfortran_cshift0_16, _gfortran_cshift0_16_char. Sort alphabetically. * intrinsics/eoshift0.c: Add function for kind=16 integer. * intrinsics/eoshift2.c: Likewise. * intrinsics/cshift0.c: Likewise. 2008-05-22 Thomas Koenig [EMAIL PROTECTED] PR libgfortran/36302 * gfortran.dg/cshift_large_1.f90: New test. * gfortran.dg/eoshift_large_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/cshift_large_1.f90 trunk/gcc/testsuite/gfortran.dg/eoshift_large_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/cshift0.c trunk/libgfortran/intrinsics/eoshift0.c trunk/libgfortran/intrinsics/eoshift2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36302
[Bug libfortran/36302] cshift and eoshift missing some kind=16 functions
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-05-22 21:59 --- Fixed on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36302
[Bug middle-end/36303] location list incomplete for spilled registers
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-22 22:38 --- I'm sorry, but I don't understand what you mean. *((unsigned int *)((p1)-data[0])), You are accessing a char array as an unsigned int which violates C/C++ aliasing rules and causes undefined code at runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36303
[Bug c++/31923] g++ accepts a storage-class-specifier on a template explicit specialization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug middle-end/36303] location list incomplete for spilled registers
--- Comment #4 from gcaprino at gmail dot com 2008-05-22 23:03 --- (In reply to comment #3) I'm sorry, but I don't understand what you mean. *((unsigned int *)((p1)-data[0])), You are accessing a char array as an unsigned int which violates C/C++ aliasing rules and causes undefined code at runtime. Ah, I see what you mean. Yes, you are right. That came out of some macro expansion. Unfortunately I can still see the problem in the location list when I reference the array elements without the casts: _Log(abc, (__FUNCTION__+((__FUNCTION__[(sizeof(FSS) - 1)] == '_') ? (sizeof(FSS) - 1) + 1 : (sizeof(FSS) - 1))), 237 , (p1)-f1, (p1)-length, p1-data[0], p1-data[4], p1-data[8], p1-data[12], p1-data[16], p1-data[20], p1-data[24], p1-data[28], p1-data[32], p1-data[40], p1-data[48], p1-data[56], p2); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36303
[Bug middle-end/36294] gcc exited and told me to report a bug (details follow)
--- Comment #5 from paulbeard at gmail dot com 2008-05-22 23:18 --- emGCC is running out of memory./em Oh. I'll add a swapfile and see how that goes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
[Bug c/36304] New: A variable is reset for no apparent reason
$ gcc --version gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -Wall -o reversi reversi.c -DDEBUG=1 -save-temps reversi.c: In function 'alphabeta': reversi.c:376: warning: value computed is not used Expected behaviour: Loop prints 07 What happens: loop prints all 0's When I comment out the scanf call, 07 is printed as expected. I originally didn't use a second variable, but put it in out of desperation. The code compiles correctly with icc. There are no header files, the program is one self-contained C file. (If you are curious, it doesn't work.) -- Summary: A variable is reset for no apparent reason Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbarbero at cs dot washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36304
[Bug c/36304] A variable is reset for no apparent reason
--- Comment #1 from jbarbero at cs dot washington dot edu 2008-05-22 23:25 --- Created an attachment (id=15673) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15673action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36304
[Bug c/36304] A variable is reset for no apparent reason
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-22 23:51 --- This is not a bug as %s scans a string so the last x[7] will overwrite past the array. Doing: char x[9]; int k = i; sscanf(in[k], %s %s %s %s %s %s %s %s, x[0], x[1], x[2], x[3], x[4], x[5], x[6], x[7]); printf(i: %d\n, i); Fixes the issue but you really should use %c instead. -- 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=36304
[Bug c/36304] A variable is reset for no apparent reason
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-22 23:53 --- This is not a bug as %s scans a string so the last x[7] will overwrite past the array. That is it will write a NULL character at x[8] which is one past the array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36304
[Bug c/36304] A variable is reset for no apparent reason
--- Comment #4 from jbarbero at cs dot washington dot edu 2008-05-22 23:59 --- OK, thanks. Sorry to waste your time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36304
[Bug middle-end/36213] Wrong search path generation
--- Comment #4 from martin dot drab at fjfi dot cvut dot cz 2008-05-23 00:40 --- OK, tried current snapshot without the --enable-version-specific-runtime-libs and no change. :-( So, that was probably not the problem. --- $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: ../../../gcc-SVN-20080522/gcc-SVN-20080522/configure --build=x86_64-pc-linux-gnu --prefix=/usr/local/opt/MDL/opt/gcc-4.4 --exec-prefix=/usr/local/opt/MDL/opt/gcc-4.4 --sysconfdir=/etc --libdir=/usr/local/opt/MDL/opt/gcc-4.4/lib64 --libexecdir=/usr/local/opt/MDL/opt/gcc-4.4/libexec64 --includedir=/usr/local/opt/MDL/opt/gcc-4.4/include --infodir=/usr/local/opt/MDL/opt/gcc-4.4/share/info --mandir=/usr/local/opt/MDL/opt/gcc-4.4/share/man --program-suffix=-4.4 --sharedstatedir=/var --localstatedir=/var --enable-languages=c,c++,fortran --enable-generated-files-in-srcdir --enable-targets=all --disable-libada --enable-libssp --disable-werror --enable-shared --enable-static --enable-parallel-mark --with-gnu-ld --disable-werror-always --enable-multilib --enable-threads=posix --enable-tls --disable-rpath --with-demangler-in-ld --with-gnu-as --with-x --disable-coverage --disable-checking --enable-visibility --with-arch=core2 Thread model: posix gcc version 4.4.0 20080522 (experimental) (GCC) --- --- $ gcc -print-search-dirs install: /usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0x86_64-pc-linux-gnu/4.4.0/ programs: =/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../libexec64/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../libexec64/gcc/:/usr/local/opt/MDL/opt/gcc-4.4/libexec64/gcc/x86_64-pc-linux-gnu/4.4.0/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/libexec64/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/bin/ libraries: =/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/32/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/32/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib64/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib32/../lib64/:/usr/local/opt/MDL/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/lib64/../lib64/:/usr/local/opt/MDL/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/lib32/../lib64/:/lib64/x86_64-pc-linux-gnu/4.4.0/:/lib64/../lib64/:/lib32/x86_64-pc-linux-gnu/4.4.0/:/lib32/../lib64/:/usr/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/lib64/../lib64/:/usr/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/lib32/../lib64/:/usr/local/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/local/lib64/../lib64/:/usr/local/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/local/lib32/../lib64/:/usr/X11R6/lib64/x86_64-pc-linux-gnu/4.4.0/:/usr/X11R6/lib64/../lib64/:/usr/X11R6/lib32/x86_64-pc-linux-gnu/4.4.0/:/usr/X11R6/lib32/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../lib64/:/lib/x86_64-pc-linux-gnu/4.4.0/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.4.0/:/usr/lib/../lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/4.4.0/32/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib64/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/lib32/:/usr/local/opt/MDL/lib64/:/usr/local/opt/MDL/lib32/:/lib64/:/lib32/:/usr/lib64/:/usr/lib32/:/usr/local/lib64/:/usr/local/lib32/:/usr/X11R6/lib64/:/usr/X11R6/lib32/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../../x86_64-pc-linux-gnu/lib/:/usr/local/opt/MDL/opt/gcc-4.4/lib64/gcc/x86_64-pc-linux-gnu/../:/lib/:/usr/lib/ --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
[Bug middle-end/36213] Wrong search path generation
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-23 00:44 --- Is there a reason why you are supplying all these weird configure options? --exec-prefix=/usr/local/opt/MDL/opt/gcc-4.4 --sysconfdir=/etc --libdir=/usr/local/opt/MDL/opt/gcc-4.4/lib64 --libexecdir=/usr/local/opt/MDL/opt/gcc-4.4/libexec64 --includedir=/usr/local/opt/MDL/opt/gcc-4.4/include --infodir=/usr/local/opt/MDL/opt/gcc-4.4/share/info --mandir=/usr/local/opt/MDL/opt/gcc-4.4/share/man The default for them will be based on the prefix. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
[Bug middle-end/36213] Wrong search path generation
--- Comment #6 from martin dot drab at fjfi dot cvut dot cz 2008-05-23 00:49 --- One more thing I've forgotten to mention is that (no matter if the --enable-version-specific-runtime-libs is there or not) files limits.h and syslimits.h are not generated into the internal include directory of the gcc, but into the include-fixed directory, where, however, gcc can't find them. So I had to create a symlink there, otherwise lots of stuff can't be compiled. Though, I don't know if it is due to the badly generated paths. Maybe if they were correct, gcc would have found the files even in that directory. So, that may actually be OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
[Bug middle-end/36213] Wrong search path generation
--- Comment #7 from martin dot drab at fjfi dot cvut dot cz 2008-05-23 01:00 --- (In reply to comment #5) Is there a reason why you are supplying all these weird configure options? --exec-prefix=/usr/local/opt/MDL/opt/gcc-4.4 --sysconfdir=/etc --libdir=/usr/local/opt/MDL/opt/gcc-4.4/lib64 --libexecdir=/usr/local/opt/MDL/opt/gcc-4.4/libexec64 --includedir=/usr/local/opt/MDL/opt/gcc-4.4/include --infodir=/usr/local/opt/MDL/opt/gcc-4.4/share/info --mandir=/usr/local/opt/MDL/opt/gcc-4.4/share/man The default for them will be based on the prefix. Just to make sure they are where I want them to be. Basically most of them need not be there, because they are what they are based on the prefix. That's right. I just want to make sure, that the 64-bit library and libexec dirs get the *64 at the end (because I use it all over the system that way - Gentoo ;) and I really hate it when info and man is not generated into the share subdir. Though I admit, that since I install the entire gcc into a separate directory, i can probably leave this on automatic based on prefix. That's right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
[Bug middle-end/36213] Wrong search path generation
--- Comment #8 from martin dot drab at fjfi dot cvut dot cz 2008-05-23 01:09 --- But I have been using the prefixes like these for ages and it used to work with 4.3 and older versions just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #7 from mmitchel at gcc dot gnu dot org 2008-05-23 01:29 --- I agree on both points: (1) I should not have marked this P5, and (2) we do not yet have a test case. Marked as WAITING. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug fortran/36305] New: real and imaginary part of complex exponential
the following program does not work properly. The value of y2 should be equal to the value of y2. The real and the imaginary part of y2 are inverted!!! program riemann implicit none complex (KIND=8) y,y2,imag real (KIND=8) theta,dtheta,thetamax,Pi integer i,Ntheta C** imag=cmplx(0.0d0,1.0d0) Pi=dacos(-1.d0) Ntheta=100 thetamax=2.0d0*Pi dtheta=thetamax/real(Ntheta) do i=1,Ntheta theta=i*dtheta y=cdexp(imag*theta)**0.5 y2=cdexp(imag*theta/2.0d0) C** write(10,1000)real(y),aimag(y) ,real(y2),aimag(y2) end do stop 1000format(10E16.8) end program -- Summary: real and imaginary part of complex exponential Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rbustos76 at yahoo dot com dot ar http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36305
[Bug fortran/36305] real and imaginary part of complex exponential
--- Comment #1 from kargl at gcc dot gnu dot org 2008-05-23 03:02 --- Upgrade your compiler. 4.1.2 is extremely old, and the 4.1.x branch is no longer maintained. With 4.2.3, the first four values are 0.99950656E+00 0.31410759E-01 0.99950656E+00 0.31410759E-01 0.99802673E+00 0.62790520E-01 0.99802673E+00 0.62790520E-01 0.99556196E+00 0.94108313E-01 0.99556196E+00 0.94108313E-01 0.99211470E+00 0.12533323E+00 0.99211470E+00 0.12533323E+00 With 4.4.0, the first four values are 0.99950656E+00 0.31410759E-01 0.99950656E+00 0.31410759E-01 0.99802673E+00 0.62790520E-01 0.99802673E+00 0.62790520E-01 0.99556196E+00 0.94108313E-01 0.99556196E+00 0.94108313E-01 0.99211470E+00 0.12533323E+00 0.99211470E+00 0.12533323E+00 This PR should be closed with a WONTFIX. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Known to work||4.2.3 4.4.0 Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36305
[Bug c++/36306] New: accept invalid: double class name
Here testcase:
namespace foo {
struct bar {};
}
void f(foo::bar::bar ) {}
--
As you can see instead of foo::bar I wrote
foo::bar::bar, but
g++ -c -Wall test.cpp echo ok
ok
g++ --version
g++ (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
compiler from M$ VC++ 2005 and Comeau online found errors in this code
--
Summary: accept invalid: double class name
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36306
[Bug c++/36306] accept invalid: double class name
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-23 05:44 --- *** This bug has been marked as a duplicate of 11764 *** -- 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=36306
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-23 05:44 --- *** Bug 36306 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dushistov at mail dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
