[Bug fortran/37961] [F2003] random_seed - allow integer(8) for the arguments
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 06:57 --- Subject: Re: [F2003] random_seed - allow integer(8) for the arguments On Fri, Oct 31, 2008 at 06:44:07AM -, burnus at gcc dot gnu dot org wrote: > > INVALID - only default integers are allowed > Tobias, thanks. In reviewing my previous post, the post may have appeared confrontational. That was completely unintention. I was just trying to convey what the various standards say. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37961
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #33 from bonzini at gnu dot org 2008-10-31 06:52 --- > Since the problem is that libintl.h can't be found No, the problem is that INCINTL is not set correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug fortran/37961] [F2003] random_seed - allow integer(8) for the arguments
--- Comment #3 from burnus at gcc dot gnu dot org 2008-10-31 06:44 --- INVALID - only default integers are allowed -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37961
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #20 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 04:55 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Fri, Oct 31, 2008 at 04:27:23AM -, deji_aking at yahoo dot ca wrote: > > >> >> From comment 1: >> >>Adw_xabcd_8(1:n) = transfer(-1,1.0) ! Adw_xabcd_8 is REAL >> >> That makes sense: One assigns NaN to a real variable (though a >> comment would be helpful). However >> > Does this mean gfortran shouldn't give an error message on the > first part (with the real variable) of the bug report? It seems > the patch to fix this only deals with the integer variable assignment. > No. gfortran is giving you an error because you are trying to convert a NaN for a REAL type to a DOUBLE PRECISION value. This also makes no sense. If you want a DOUBLE PRECISION NaN, then use transfer(-1,1.d0). The conversion code for REAL to DOUBLE PRECISION properly handled this problem. The patch I submitted for INTEGER was for a code path into the REAL to INTEGER routine that no one had ever triggered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2008-10-31 04:52 --- Subject: Bug 37930 Author: jvdelisle Date: Fri Oct 31 04:51:04 2008 New Revision: 141489 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141489 Log: 2008-10-30 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/37930 * gfortran.dg/int_conv_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/int_conv_2.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2008-10-31 04:46 --- Subject: Bug 37930 Author: jvdelisle Date: Fri Oct 31 04:45:28 2008 New Revision: 141488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141488 Log: 2008-10-30 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/37930 * fortran/arith.c (gfc_mpfr_to_mpz): Test for NaN and Inf values. Remove stale comment and kludge code for MPFR 2.0.1 and older. (gfc_real2int): Error on conversion of NaN or Inf. (gfc_complex2int): Ditto. * fortran/arith.h: Update mpfr_to_mpz prototype. * fortran/simplify.c (gfc_simplify_ceiling, gfc_simplify_floor, gfc_simplify_ifix, gfc_simplify_idint, simplify_nint): Update function calls to include locus. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/arith.h trunk/gcc/fortran/simplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #17 from deji_aking at yahoo dot ca 2008-10-31 04:27 --- (In reply to comment #14) > --- > > From comment 1: > > Adw_xabcd_8(1:n) = transfer(-1,1.0) ! Adw_xabcd_8 is REAL > > That makes sense: One assigns NaN to a real variable (though a comment would > be > helpful). However > Does this mean gfortran shouldn't give an error message on the first part (with the real variable) of the bug report? It seems the patch to fix this only deals with the integer variable assignment. > Adw_Fn_I (n) = transfer(-1,1.0) ! Adw_Fn_I is an INTEGER > > does not make sense as there is no NaN for integers. Here, one could have used > "-HUGE(Adw_Fn_I)" or similar. I think the programmer simply missed that > Adw_Fn_I is no real variable; as long as compiler digest this number it does > its purpose - initializing the variable with garbage, but syntactically it > does > not make sense - and a compiler has all rights to reject it. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug testsuite/37960] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #8 from eric dot weddington at atmel dot com 2008-10-31 04:26 --- (In reply to comment #7) > Eric, > > Could you modify the testcase to use 100 instead of 1000 and run it under AVR? > The test is successful if the 1000 is changed to 100. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-31
04:22 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI
version detected
> Same on hppa2.0w-hp-hpux11.11.
>
> (gdb) bt
> #0 _Jv_CheckABIVersion (value=0)
> at ../../../gcc/libjava/java/lang/natClassLoader.cc:273
> #1 0xc3f81ab4 in _Jv_RegisterClasses (classes=0x7eff2c78)
> at ../../../gcc/libjava/java/lang/natClassLoader.cc:295
> #2 0xc3f81b48 in _Jv_RegisterClass (klass=0x0)
> at ../../../gcc/libjava/java/lang/natClassLoader.cc:441
> #3 0xc4e37894 in global constructors keyed to
> 65535_0__var_tmp__ccxwp2Cmjx_4B3F0796_6CD682F9 ()
> at
> ../../../../../gcc/libjava/classpath/external/sax/org/xml/sax/SAXNotRecognizedException.java:49
The backtrace is somewhat inaccurate. However, it seems that some klass
objects are not being correctly initialized:
...
klass=0x77afa164
klass->next_or_version=0xc0061a81
klass=0x77afa1fc
klass->next_or_version=0xc0061a81
klass=0x77af8b50
klass->next_or_version=0x0
(gdb) p ((jclass) 0x77af8b50)->next_or_version
$9 = (jclass) 0x0
(gdb) p *((jclass) 0x77af8b50)
$10 = {<> = {}, static class$ = {<> = {},
static class$ = ,
next_or_version = 0x40062a20, name = 0x7714d2cc, accflags = 49,
(gdb) x/4x 0x77af8b50
0x77af8b50: 0x7714d084 0x 0x 0x77afa530
(gdb) x/4x 0x7714d084
0x7714d084: 0x7714d190 0x0002 0x76f421d6 0x400013aa
(gdb) x/4x 0x7714d190
0x7714d190: 0x7714d084 0x 0x40062a20 0x7714d2cc
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug target/37909] internal compiler error: in fixup_mova, at config/sh/sh.c:3756
--- Comment #7 from kkojima at gcc dot gnu dot org 2008-10-31 03:52 --- Subject: Bug 37909 Author: kkojima Date: Fri Oct 31 03:50:02 2008 New Revision: 141487 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141487 Log: PR target/37909 Backport from mainline: * config/sh/sh.c (untangle_mova): Return -1 when NEW_MOVA has no address. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37909
[Bug target/37909] internal compiler error: in fixup_mova, at config/sh/sh.c:3756
--- Comment #6 from kkojima at gcc dot gnu dot org 2008-10-31 03:45 --- Subject: Bug 37909 Author: kkojima Date: Fri Oct 31 03:43:20 2008 New Revision: 141486 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141486 Log: PR target/37909 Backport from mainline: * config/sh/sh.c (untangle_mova): Return -1 when NEW_MOVA has no address. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37909
[Bug fortran/37974] gfortran runtime segmentation fault
--- Comment #3 from kargl at gcc dot gnu dot org 2008-10-31 03:39 --- (In reply to comment #2) > (In reply to comment #1) > > call seg_sub(ip, sig, 1) > > > > Is that last argument a literal constant, name 'one'? > > Or is it the letter 'ell'? > > > It is a literal constant 'one'. What really bugs me is why does it segfault at > all. > Thanks. It segfaults because the constant 1 is in read-only memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37974
[Bug fortran/37974] gfortran runtime segmentation fault
--- Comment #2 from deji_aking at yahoo dot ca 2008-10-31 03:31 --- (In reply to comment #1) > call seg_sub(ip, sig, 1) > > Is that last argument a literal constant, name 'one'? > Or is it the letter 'ell'? > It is a literal constant 'one'. What really bugs me is why does it segfault at all. Thanks. > Either way it is impossible to reliable detect that > a user writes code that either tries to change the > value of a literal constant or uses an unitialized > variable. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37974
[Bug regression/37976] ICE in insert_into_preds_of_block
--- Comment #1 from dirtyepic at gentoo dot org 2008-10-31 02:58 --- Created an attachment (id=16594) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16594&action=view) percent_x.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
[Bug regression/37976] New: ICE in insert_into_preds_of_block
This looks like PR #29922, but I'm hitting it on the trunk while compiling tcp-wrappers-7.6. It didn't fail on my last system rebuild a week or two ago. Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.0_pre/work/gcc-4.4.0-/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.0-pre --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.0-pre --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.0-pre/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.0-pre/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --enable-libgomp --enable-cld --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion= --enable-linux-futex --enable-checking Thread model: posix gcc version 4.4.0-pre9999 built 20081030 (Gentoo SVN ebuild) rev. 141462 () COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-O2' '-E' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.0-pre/cc1 -E -quiet -v percent_x.c -mtune=generic -O2 -fpch-preprocess ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/include-fixed /usr/include End of search list. COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.0-pre/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.0-pre/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.0-pre/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-O2' '-E' '-mtune=generic' Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.0_pre/work/gcc-4.4.0-/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.0-pre --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.0-pre --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.0-pre/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.0-pre/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.0-pre/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --enable-libgomp --enable-cld --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion= --enable-linux-futex --enable-checking Thread model: posix gcc version 4.4.0-pre built 20081030 (Gentoo SVN ebuild) rev. 141462 () COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-O2' '-o' '/var/cache/ccache/tmp.hash.kali.5429.o' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.0-pre/cc1 -fpreprocessed /var/cache/ccache/percent_x.tmp.kali.5429.i -quiet -dumpbase percent_x.tmp.kali.5429.i -mtune=generic -auxbase-strip /var/cache/ccache/tmp.hash.kali.5429.o -O2 -version -o percent_x.tmp.kali.5429.s GNU C () version 4.4.0-pre built 20081030 (Gentoo SVN ebuild) rev. 141462 (x86_64-pc-linux-gnu) compiled by GNU C version 4.4.0-pre built 20081030 (Gentoo SVN ebuild) rev. 141462, GMP version 4.2.4, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: e9c90fc3428f6f69e680d8fe0bdc6284 percent_x.c: In function 'percent_
[Bug fortran/37974] gfortran runtime segmentation fault
--- Comment #1 from kargl at gcc dot gnu dot org 2008-10-31 02:19 --- call seg_sub(ip, sig, 1) Is that last argument a literal constant, name 'one'? Or is it the letter 'ell'? Either way it is impossible to reliable detect that a user writes code that either tries to change the value of a literal constant or uses an unitialized variable. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37974
[Bug c/37975] Incorrect argument checking for printf: "format not a string literal, argument types not checked", where it can be checked
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-31 02:13 --- Also you can change what fmt points to really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37975
[Bug c/37975] Incorrect argument checking for printf: "format not a string literal, argument types not checked", where it can be checked
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-31 02:13 --- C says fmt is not a constant expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37975
[Bug c/37975] Incorrect argument checking for printf: "format not a string literal, argument types not checked", where it can be checked
--- Comment #1 from rilium at mail dot ru 2008-10-31 02:11 --- Created an attachment (id=16593) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16593&action=view) Preproccessed file test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37975
[Bug c/37975] New: Incorrect argument checking for printf: "format not a string literal, argument types not checked", where it can be checked
I wrote i simple code snippet to demonstrate problem:
#include
#include
#include
void f(const char* str1, const char* str2)
{
const char* fmt = "Something is: %s, and something another is: %s\n";
const size_t buff_len = strlen(fmt) + strlen(str1) + strlen(str2) + 1;
char* buff = (char*)malloc(buff_len);
sprintf(buff, fmt, "Str1", "str2");
/* Do something with buff */
free(buff);
}
int main()
{
return EXIT_SUCCESS;
}
I compile it this way:
[EMAIL PROTECTED]:/tmp$ LANG=C gcc test.c -Wall -Wformat=2
test.c: In function 'f':
test.c:9: warning: format not a string literal, argument types not checked
I think, that in this case, warning is not correct, format is string literal,
and is not gotten in function parameters(as i saw in previous bug reports for
this warning), so compiler really can check argument types.
Please, resolve this problem.
My gcc -v output:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
System: Debian lenny
test.i:
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "/usr/include/string.h" 1 3 4
# 26 "/usr/include/string.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 330 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 348 "/usr/include/sys/cdefs.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 349 "/usr/include/sys/cdefs.h" 2 3 4
# 331 "/usr/include/features.h" 2 3 4
# 354 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 5 "/usr/include/gnu/stubs.h" 2 3 4
# 1 "/usr/include/gnu/stubs-32.h" 1 3 4
# 8 "/usr/include/gnu/stubs.h" 2 3 4
# 355 "/usr/include/features.h" 2 3 4
# 27 "/usr/include/string.h" 2 3 4
# 1 "/usr/lib/gcc/i486-linux-gnu/4.3.2/include/stddef.h" 1 3 4
# 214 "/usr/lib/gcc/i486-linux-gnu/4.3.2/include/stddef.h" 3 4
typedef unsigned int size_t;
# 34 "/usr/include/string.h" 2 3 4
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern void *memmove (void *__dest, __const void *__src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern void *memccpy (void *__restrict __dest, __const void *__restrict __src,
int __c, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern void *memset (void *__s, int __c, size_t __n) __attribute__
((__nothrow__)) __attribute__ ((__nonnull__ (1)));
extern int memcmp (__const void *__s1, __const void *__s2, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1, 2)));
extern void *memchr (__const void *__s, int __c, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1)));
# 82 "/usr/include/string.h" 3 4
extern char *strcpy (char *__restrict __dest, __const char *__restrict __src)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern char *strncpy (char *__restrict __dest,
__const char *__restrict __src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern char *strcat (char *__restrict __dest, __const char *__restrict __src)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern char *strncat (char *__restrict __dest, __const char *__restrict __src,
size_t __n) __attribute__ ((__nothrow__)) __attribute__ ((__nonnull__
(1, 2)));
extern int strcmp (__const char *__s1, __const char *__s2)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1, 2)));
extern int strncmp (__const char *__s1, __const char *__s2, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1, 2)));
extern int strcoll (__const char *__s1, __const char *__s2)
__attribute__ ((__nothrow__)) __attribute__ ((__pure__)) __attribute__
((__nonnull__ (1, 2)));
extern size_t strxfrm (char *__restrict __dest,
__const char *__restrict __src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (2)));
# 130 "/usr/include/string.h" 3 4
extern char *strdup (__const char *__s)
__attribute__ ((__nothrow__)) __attribute__ ((__malloc__)) __attribute__
((__nonnull__ (1))
[Bug fortran/37974] New: gfortran runtime segmentation fault
Using Gfortran, I'm getting a segmentation fault from running a code which reduces to the following; ... PROGRAM seg_main INTEGER :: ip real :: sig ip = 26314400 call seg_sub(ip, sig, 1) write(*,*) 'sig is', sig END PROGRAM SUBROUTINE seg_sub(ip, p, kind0) implicit none integer ip, kind0 real p kind0 = 2 - 1 p = ip return END SUBROUTINE ... I'm not sure if the code violates some fortran standards, although it seems valid to me. But I think gfortran should give some warning or error messages instead of just segfaulting. The code works fine with pgf90 on Linux and xlf on AIX, but similarly segfault with ifort on Linux. -- Summary: gfortran runtime segmentation fault Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: deji_aking at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37974
[Bug c++/37972] static variables of template class not emitted if no initializer given
--- Comment #2 from rysto32 at gmail dot com 2008-10-31 01:50 ---
Subject: Re: static variables of template class not emitted if no initializer
given
What if I explicitly instantiate Base?
template
class Base
{
public:
static int foo;
};
template class Base;
template<> int Base::foo;
g++ 3.4 emits Base::foo, but 4.3.2 and 4.2.4 don't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37972
[Bug c/37973] New: -MM fails with when used with -combine
> echo > x1.c > echo > x2.c > gcc -combine -MM x1.c x2.c cc1: error: too many filenames given. Type cc1 --help for usage > gcc -combine -MM -save-temps x1.c x2.c i686-apple-darwin9-gcc-4.2.1: internal gcc abort in main, at /var/tmp/gcc_42/gcc_42-5564~1/src/gcc/gcc.c:6967 >gcc -v -combine -MM x1.c x2.c Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc_42/gcc_42-5564~1/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-gxx-include-dir=/usr/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5564) /usr/libexec/gcc/i686-apple-darwin9/4.2.1/cc1 -E -quiet -v -MM -D__DYNAMIC__ x1.c x2.c -fPIC -mmacosx-version-min=10.5.5 -mtune=core2 ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin9/4.2.1/../../../../i686-apple-darwin9/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/i686-apple-darwin9/4.2.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. cc1: error: too many filenames given. Type cc1 --help for usage -- Summary: -MM fails with when used with -combine Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jdybnis at gmail dot com GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37973
[Bug rtl-optimization/37782] [4.4 regression] Stage2 ada compiler miscompiled
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-10-31 01:40 --- Mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37782
[Bug testsuite/37703] Ada testsuites lack multilib support
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-10-31
01:24 ---
Subject: Ada testsuites lack multilib support
While testing the fix for PR ada/37681, I tried to test both multilibs
(default and amd64) on i386-pc-solaris2.10, and found that I had to make
the following changes:
* For ada/acats, the necessary changes are restricted to the run_acats
script:
--- run_acats.save Wed May 30 17:59:57 2007
+++ run_acats Thu Oct 9 17:55:35 2008
@@ -13,7 +13,7 @@
BASE=`cd $ROOT/../../..; ${PWDCMD-pwd}`
PATH=$BASE:$ROOT:$PATH
-ADA_INCLUDE_PATH=$BASE/ada/rts
+ADA_INCLUDE_PATH=$BASE/ada/rts_sparcv9
LD_LIBRARY_PATH=$ADA_INCLUDE_PATH:$BASE:$LD_LIBRARY_PATH
ADA_OBJECTS_PATH=$ADA_INCLUDE_PATH
@@ -33,7 +33,7 @@
fi
GCC_DRIVER="$BASE/xgcc"
-GCC="$BASE/xgcc -B$BASE/"
+GCC="$BASE/xgcc -B$BASE/ -m64"
export PATH ADA_INCLUDE_PATH ADA_OBJECTS_PATH GCC_DRIVER GCC LD_LIBRARY_PATH
echo '#!/bin/sh' > host_gnatchop
To properly handle this, the script needs to iterate over the available
multilibs and append _ to $ADA_INCLUDE_PATH and the
multilib flag to $GCC.
One problem here is that unlike the dejagnu based testsuite, where the
user can influence the multilibs to test via the RUNTESTFLAGS environment
variable, it seems to be unnecessarily complex to parse that
dejagnu-specific variable (which might look like
--target_board "unix{,-m64}"
in the present case), so instead the default should be to iterate over
all available multilibs.
* For gnat, the situation is similar with one twist:
--- gnat.exp.save Mon Sep 3 18:05:02 2007
+++ gnat.expThu Oct 9 17:54:58 2008
@@ -127,10 +127,10 @@
global ld_library_path
global gnat_libgcc_s_path
-setenv ADA_INCLUDE_PATH "${rootme}/ada/rts"
+setenv ADA_INCLUDE_PATH "${rootme}/ada/rts_amd64"
set ld_library_path ".:${gnat_libgcc_s_path}"
lappend options "compiler=$GNAT_UNDER_TEST -q -f"
-lappend options "incdir=${rootme}/ada/rts"
+lappend options "incdir=${rootme}/ada/rts_amd64"
if { [target_info needs_status_wrapper]!="" && [info exists gluefile] } {
lappend options "libs=${gluefile}"
@@ -244,7 +244,7 @@
}
if { $file != "" } {
set root [file dirname $file]
- set CC "$file -I$root/ada/rts --GCC=$root/xgcc
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs
--GCC=$root/xgcc -B$root -margs";
+ set CC "$file -I$root/ada/rts_amd64 --GCC=$root/xgcc
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs
--GCC=$root/xgcc -B$root -m64 -margs";
} else {
set CC [transform gnatmake]
}
Again, one needs to add _ to ADA_INCLUDE_PATH and friends.
The multilib flag is already appended to $CC by the dejagnu framework,
but one issue remains: unlike gnatmake, gnatlink doesn't pass unknown
flags (like -m64 in this case) to gcc, but ignores them. If invoking
gnatlink via the shell, it is possible to use
-largs --GCC="$root/xgcc -B$root -m64"
and pass -B and -m64 through gnatlink. With the dejagnu/tcl framework,
I've found no way to achieve the same effect, i.e. to pass a single
argument which includes whitespace. Maybe some testsuite expert can help
here?
If this were not done, compilations performed by gnatlink `behind the
scenes' would produce objects for the default multilib, leading to link
failures in the final link step.
As a workaround, I've replaced xgcc by a script that always passes -m64:
#!/bin/sh
exec $0.bin -m64 "$@"
With those changes, I could at least manually test both multilibs on
sparc-sun-solaris2.11 and i386-pc-solaris2.10.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37703
[Bug c++/37972] static variables of template class not emitted if no initializer given
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-31 01:04 --- >For some reason, Base::foo is not emitted. Because that is only a specialization and not an instatulation. -- 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=37972
[Bug fortran/37961] [F2003] random_seed - allow integer(8) for the arguments
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 01:02 --- Subject: Re: [F2003] random_seed - allow integer(8) for the arguments I just checked the F2008 draft for the next standard. It says 13.7.95 RANDOM SEED ([SIZE, PUT, GET]) Description. Restarts or queries the pseudorandom number generator used by RANDOM_NUMBER. Class. Subroutine. Arguments. There shall either be exactly one or no arguments present. SIZE (optional) shall be scalar and of type default integer. It is an INTENT (OUT) argument. It is assigned the number N of integers that the processor uses to hold the value of the seed. PUT (optional) shall be a default integer array of rank one and size N . It is an INTENT (IN) argument. It is used in a processor-dependent manner to compute the seed value accessed by the pseudorandom number generator. GET (optional) shall be a default integer array of rank one and size N It is an INTENT (OUT) argument. It is assigned the current value of the seed. I think this PR should be closed with a WONTFIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37961
[Bug c++/37972] New: static variables of template class not emitted if no initializer given
[EMAIL PROTECTED] tmp]cat test.cc
template
class Base
{
static int foo;
};
template<> int Base::foo;
template<> int Base::foo = 0;
[EMAIL PROTECTED] tmp]g++ -c test.cc
[EMAIL PROTECTED] tmp]nm --demangle test.o
B Base::foo
[EMAIL PROTECTED] tmp]g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
For some reason, Base::foo is not emitted. I've tested it with 3.4.6,
4.0.2, 4.3.0 and 4.3.2 as well, and it's broken on all of them. The 4.0.2 and
4.3.0 gccs were i686-cygwin-hosted i686-freebsd6-targeted cross-compilers, so
it's not specific to x86_64-linux-gnu.
--
Summary: static variables of template class not emitted if no
initializer given
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rysto32 at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37972
[Bug c++/37971] [4.2/4.3/4.4 Regression] Rejects default argument that is a template via access failure
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-31 00:38 ---
Explictly by the following new code:
{
mark_used (fn);
/* We could not check access when this expression was originally
created since we did not know at that time to which function
the expression referred. */
if (DECL_FUNCTION_MEMBER_P (fn))
{
gcc_assert (access_path);
perform_or_defer_access_check (access_path, fn, fn);
}
}
Since this was already "bound", to the template we should not be performing
access checks for this template function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
[Bug c++/37971] [4.2/4.3/4.4 Regression] Rejects default argument that is a template via access failure
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-31 00:35 --- Caused by the patch which fixes PR 28588. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Known to fail||4.4.0 4.3.0 4.2.0 Known to work||4.1.1 4.0.2 Summary|[4.3/4.4 Regression] Rejects|[4.2/4.3/4.4 Regression] |default argument that is a |Rejects default argument |template via access failure |that is a template via ||access failure Target Milestone|4.3.3 |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
[Bug c++/37971] [4.3/4.4 Regression] Rejects default argument that is a template via access failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-31 00:13 --- This is valid code via 8.3.6/5: "The names in the expressions are bound, and the semantics constraints are checked, at the point where the default argument expression appears. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
[Bug c++/37971] [4.3/4.4 Regression] Rejects default argument that is a template
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
[Bug c++/37971] New: [4.3/4.4 Regression] Rejects default argument that is a template
Take:
struct foo
{
private:
template
static bool func(const U& x) {}
static bool func1(const int& x) {}
public:
unsigned int Find(const int& x, bool (*pFunc) (const int&) = func) const {}
unsigned int Find1(const int& x, bool (*pFunc) (const int&) = func1) const {}
};
foo b;
void f(void)
{
b.Find1(1);
b.Find(1);
}
--- CUT ---
Only the call to Find is rejected with the following error message:
t.cc: In function void f():
t.cc:5: error: static bool foo::func(const U&) [with U = int] is private
t.cc:16: error: within this context
This is wrong as func is not private in the default argument.
--
Summary: [4.3/4.4 Regression] Rejects default argument that is a
template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37971
[Bug tree-optimization/37969] [4.3 Regression] "-O2 -funswitch-loops" causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-10-30 23:51 --- Confirmed. I cannot reproduce this with 4.2 or 4.4 (but maybe that just requires a more reduced testcase). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.3.2 Known to work||4.2.4 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-10-30 23:51:33 date|| Summary|"-O2 -funswitch-loops" |[4.3 Regression] "-O2 - |causes ICE in |funswitch-loops" causes ICE |build_int_cst_wide, at |in build_int_cst_wide, at |tree.c:891 (OpenOffice.org) |tree.c:891 (OpenOffice.org) Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug middle-end/37969] "-O2 -funswitch-loops" causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-30 23:48 --- Created an attachment (id=16592) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16592&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug c++/37970] ICE in some (probably mal-formed) template code
--- Comment #1 from keenan dot forbes at gmail dot com 2008-10-30 23:35 --- Created an attachment (id=16591) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16591&action=view) preprocessed file for ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37970
[Bug c++/37970] New: ICE in some (probably mal-formed) template code
This code (for better or worse) appeared to have built with 4.0.1. By adding the "class" stuff in the template specialization the static member was actually instantiated. With just <> no instantiation occurred. g++ -v -save-temps -c tmp.cc Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE tmp.cc -mtune=i686 -fpch-preprocess -o tmp.ii ignoring nonexistent directory "/usr/local/include/i486-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include" ignoring nonexistent directory "/usr/include/i486-linux-gnu" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2 /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/i486-linux-gnu /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.1.2/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -fpreprocessed tmp.ii -quiet -dumpbase tmp.cc -mtune=i686 -auxbase tmp -version -o tmp.s GNU C++ version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (i486-linux-gnu) compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96557 Compiler executable checksum: 183d42a838ed2b7313bffcb8f2f2fda7 tmp.cc: In constructor ChainHashTable::ChainHashTable() [with Key = const elfsymbol*, Value = CF::ElxrFunction*, HashFunc = elfsymbol_hash]: tmp.cc:35: instantiated from MemoryManager::Link> ChainHashTable::linkmanager tmp.cc:35: instantiated from ChainHashTable::ChainHashTable() [with Key = const elfsymbol*, Value = CF::ElxrFunction*, HashFunc = elfsymbol_hash] tmp.cc:65: instantiated from here tmp.cc:35: internal compiler error: in instantiate_decl, at cp/pt.c:11775 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . Preprocessed source stored into /tmp/ccy7OWHQ.out file, please attach this to your bugreport. I don't see a way to attach the file, but perhaps that's available after I commit... -- Summary: ICE in some (probably mal-formed) template code Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: keenan dot forbes at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37970
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-30 23:27 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected > On AIX, _Jv_CheckABI is invoked with version argument of 0 instead of 404000 > GCC version constant. Same on hppa2.0w-hp-hpux11.11. (gdb) bt #0 _Jv_CheckABIVersion (value=0) at ../../../gcc/libjava/java/lang/natClassLoader.cc:273 #1 0xc3f81ab4 in _Jv_RegisterClasses (classes=0x7eff2c78) at ../../../gcc/libjava/java/lang/natClassLoader.cc:295 #2 0xc3f81b48 in _Jv_RegisterClass (klass=0x0) at ../../../gcc/libjava/java/lang/natClassLoader.cc:441 #3 0xc4e37894 in global constructors keyed to 65535_0__var_tmp__ccxwp2Cmjx_4B3F0796_6CD682F9 () at ../../../../../gcc/libjava/classpath/external/sax/org/xml/sax/SAXNotRecognizedException.java:49 #4 0xc3f2497c in _GLOBAL () at ../../../gcc/libjava/gcj/cni.h:61 #5 0xc003a560 in shl_invoke_initfini () from /usr/lib/dld.sl #6 0xc0037640 in invoke_init_elab () from /usr/lib/dld.sl #7 0xc0037610 in invoke_init_elab () from /usr/lib/dld.sl #8 0xc0037610 in invoke_init_elab () from /usr/lib/dld.sl #9 0xc0028d94 in finish_dld_main () from /usr/lib/dld.sl #10 0xc002ba6c in _dld_main () from /usr/lib/dld.sl #11 0x2d2c in __map_dld () #12 0x21dc in $START$ () Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug middle-end/37969] "-O2 -funswitch-loops" causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-30 23:26 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug middle-end/37969] "-O2 -funswitch-loops" causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-30 23:22 --- Created an attachment (id=16590) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16590&action=view) unincluded testcase Fails with -O2 -funswitch-loops -m64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug middle-end/37969] "-O2 -funswitch-loops" causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
--- Comment #2 from h dot mth at web dot de 2008-10-30 23:14 --- Too big to attach. See: http://geki.ath.cx/hacks/b3dgeom.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug middle-end/37943] [graphite] ICE : in build_graphite_scops, at graphite.c:1823
--- Comment #3 from spop at gcc dot gnu dot org 2008-10-30 22:54 --- Tobias, your patch looks good. Please test with bootstrap and make check and then commit to trunk. Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37943
[Bug target/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
-- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenther at suse dot de Keywords||wrong-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2
--- Comment #6 from hjl dot tools at gmail dot com 2008-10-30 22:51 --- (In reply to comment #5) > So, is this a target issue or a register allocator issue now? Has the costs > fix > been applied? > It is an IRA issue since -fno-ira is still faster with -mtune=generic. IRA should be fixed first before changing Core 2 cost. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2008-10-30 22:47 --- Since the problem is that libintl.h can't be found, shouldn't we have a toplevel check for libintl and a configure option to set the directory with --with-libintl=%p or such? The INCL_LIBINTL set in the toplevel could then be passed down to the libcpp subdirectory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #7 from manu at gcc dot gnu dot org 2008-10-30 22:44 --- The location info seems to be fixed in mainline. Nonetheless, I agree completely with Richard. This warning belongs in the front-end. Moreover we fail to diagnose: const char *s = 'x' + "y"; in both C and C++. Also, this warning does not really requires -O2, so it should work at -O0 too. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression] |Location information|offset warning should be |incorrect on string bounds |given in the front-end |warning | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug middle-end/37929] [graphite] ICE :in single_succ_edge, at basic-block.h:642
--- Comment #4 from spop at gcc dot gnu dot org 2008-10-30 22:41 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37929
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #31 from pinskia at gcc dot gnu dot org 2008-10-30 22:18 --- This really happens on all targets. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-apple-darwin9 |*-*-* GCC host triplet|i686-apple-darwin9 |*-*-* GCC target triplet|i686-apple-darwin9 |*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug c++/37965] [4.4 regression] ICE with invalid auto variable in template
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-10-30 21:41 --- I think the problems due to the 'auto' keyword are scattered through the whole compiler since the TEMPLATE_TYPE_PARM can propagate through the whole frontend. Therefore these bugs merit different PRs IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37965
[Bug middle-end/37969] "-O2 -funswitch-loops" causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:20 --- We need preprocessed source as a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug testsuite/37960] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #7 from manu at gcc dot gnu dot org 2008-10-30 21:17 --- Eric, Could you modify the testcase to use 100 instead of 1000 and run it under AVR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug c++/37968] [4.4 regression] ICE with auto as template parameter
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:06 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.2 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-10-30 21:06:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37968
[Bug rtl-optimization/37948] [4.4 Regression] IRA generates slower code for -mtune=core2
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-30 21:05 --- So, is this a target issue or a register allocator issue now? Has the costs fix been applied? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-10-30 21:04 --- i686-apple-darwin is still a primary target, so P1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug c++/37967] [4.4 regression] ICE with function returning auto
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:00 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.2 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-10-30 21:00:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37967
[Bug c++/37966] [4.4 regression] ICE with ptr-to-mem-fun-returning-auto
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:00 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.2 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-10-30 21:00:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37966
[Bug c++/37965] [4.4 regression] ICE with invalid auto variable in template
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 21:00 --- Confirmed. (This maybe artificially raises the regression count - can we group the auto related ICEs, that may be even similar?) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.2 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-10-30 21:00:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37965
[Bug c++/37969] New: "-O2 -funswitch-loops" causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
CFLAGS="-O2 -funswitch-loops" for OpenOffice.org build cause this: # LC_ALL=C g++ -Wreturn-type -fmessage-length=0 -c -O2 -fno-strict-aliasing -Wuninitialized -DENABLE_LAYOUT=0 -I. -I../../unxlngx6.pro/inc/base3d -I../inc -I../../inc/pch -I../../inc -I../../unx/inc -I../../unxlngx6.pro/inc -I. -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/solver/300/unxlngx6.pro/inc/stl -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/solver/300/unxlngx6.pro/inc/external -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/solver/300/unxlngx6.pro/inc -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/solenv/unxlngx6/inc -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/solenv/inc -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/res -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/solver/300/unxlngx6.pro/inc/stl -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/solenv/inc/Xp31 -I/usr/lib/icedtea-6.1.4.12_pre20081028/include -I/usr/lib/icedtea-6.1.4.12_pre20081028/include/linux -I/usr/lib/icedtea-6.1.4.12_pre20081028/include/native_threads/include -Idefault_x_includes -I/mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/solver/300/unxlngx6.pro/inc/offuh -I. -I../../res -I. -pipe -funswitch-loops -w -Wno-ctor-dtor-privacy -fno-use-cxa-atexit -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fpic -DLINUX -DUNX -DVCL -DGCC -DC341 -DX86_64 -DCVER=C341 -DNPTL -DGLIBC=2 -DX86_64 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 -DSUPD=300 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DGSTREAMER -DCUI -DSOLAR_JAVA -DSHAREDLIB -D_DLL_ -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o ../../unxlngx6.pro/slo/b3dgeom.o /mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/goodies/source/base3d/b3dgeom.cxx /mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/goodies/source/base3d/b3dgeom.cxx: In member function 'void B3dGeometry::CreateDefaultTexture(sal_uInt16, sal_Bool)': /mnt/data/tmp/portage/app-office/openoffice-3.0.0._pre9/work/ooo-build/build/ooo300-m9/goodies/source/base3d/b3dgeom.cxx:837: internal compiler error: in build_int_cst_wide, at tree.c:891 CFLAGS="-O1 -funswitch-loops" compile it just fine. # LC_ALL=C gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /mnt/data/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --enable-cld --disable-libgcj --enable-languages=c,c++,treelang --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2 p1.0' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2 p1.0) Gentoo bugreport https://bugs.gentoo.org/show_bug.cgi?id=237997 Failing loop to unswitch http://lxr.go-oo.org/source/graphics/goodies/source/base3d/b3dgeom.cxx#813 -- Summary: "-O2 -funswitch-loops" causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org) Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: h dot mth at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug c++/37968] [4.4 regression] ICE with auto as template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37968
[Bug c++/37968] New: [4.4 regression] ICE with auto as template parameter
Using auto as template parameter triggers ICEs in lots of different
places on mainline, e.g.
==
template struct A
{
enum { e };
};
A a;
==
bug.cc: In instantiation of 'A':
bug.cc:6: instantiated from here
bug.cc:2: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2333
Please submit a full bug report, [etc.]
==
template struct A
{
A() : i() {}
int i;
};
A a;
==
bug.cc: In constructor 'A::A() [with T = auto]':
bug.cc:7: instantiated from here
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Shouldn't auto as a template parameter trigger an error right away?
These bugs appeared with the patches for the new 'auto' semantics.
--
Summary: [4.4 regression] ICE with auto as template parameter
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37968
[Bug c++/37964] [4.4 regression] ICE with operator auto
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 20:59 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.2 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-10-30 20:59:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37964
[Bug c++/37963] [4.4 regression] ICE with (auto) cast
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 20:58 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.2 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-10-30 20:58:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37963
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-30 20:58 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.2 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-10-30 20:58:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug c++/37967] [4.4 regression] ICE with function returning auto
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37967
[Bug c++/37967] New: [4.4 regression] ICE with function returning auto
The following code snippet triggers an ICE on mainline: == auto foo(); == bug.cc:1: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] The bug appeared with the patches for the new 'auto' semantics. -- Summary: [4.4 regression] ICE with function returning auto Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37967
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #14 from pault at gcc dot gnu dot org 2008-10-30 20:47 --- Subject: Bug 37903 Author: pault Date: Thu Oct 30 20:45:09 2008 New Revision: 141467 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141467 Log: 2008-10-30 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37903 * trans-array.c (gfc_trans_create_temp_array): If n is less than the temporary dimension, assert that loop->from is zero (reverts to earlier versions). If there is at least one null loop->to[n], it is a callee allocated array so set the size to NULL and break. (gfc_trans_constant_array_constructor): Set the offset to zero. (gfc_trans_array_constructor): Remove loop shifting around the temporary creation. (gfc_conv_loop_setup): Prefer zero-based descriptors if possible. Calculate the translation from loop variables to array indices if an array constructor. 2008-10-30 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37749 * trans-array.c (gfc_trans_create_temp_array): If size is NULL use the array bounds for loop->to. 2008-10-30 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37903 * gfortran.dg/vector_subscript_4.f90: New test. 2008-10-30 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37749 * gfortran.dg/vector_subscript__5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/vector_subscript_4.f90 trunk/gcc/testsuite/gfortran.dg/vector_subscript_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/37749] ICE on array section with vector subscript
--- Comment #4 from pault at gcc dot gnu dot org 2008-10-30 20:47 --- Subject: Bug 37749 Author: pault Date: Thu Oct 30 20:45:09 2008 New Revision: 141467 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141467 Log: 2008-10-30 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37903 * trans-array.c (gfc_trans_create_temp_array): If n is less than the temporary dimension, assert that loop->from is zero (reverts to earlier versions). If there is at least one null loop->to[n], it is a callee allocated array so set the size to NULL and break. (gfc_trans_constant_array_constructor): Set the offset to zero. (gfc_trans_array_constructor): Remove loop shifting around the temporary creation. (gfc_conv_loop_setup): Prefer zero-based descriptors if possible. Calculate the translation from loop variables to array indices if an array constructor. 2008-10-30 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37749 * trans-array.c (gfc_trans_create_temp_array): If size is NULL use the array bounds for loop->to. 2008-10-30 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37903 * gfortran.dg/vector_subscript_4.f90: New test. 2008-10-30 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37749 * gfortran.dg/vector_subscript__5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/vector_subscript_4.f90 trunk/gcc/testsuite/gfortran.dg/vector_subscript_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37749
[Bug testsuite/37960] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #6 from eric dot weddington at atmel dot com 2008-10-30 20:42 --- (In reply to comment #5) > (In reply to comment #3) > > > > Note that AVR has 8-bit chars, 16-bit ints and pointers, 32-bit longs. > > Just a guess, given the above: for unsigned char b, b*1000 is signed integer > and it may overflow, so probably this is causing the warning. Perhaps we > should > only run this testcase with int32plus targets. This is what happened on bug #37663 recently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug c++/37966] [4.4 regression] ICE with ptr-to-mem-fun-returning-auto
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37966
[Bug c++/37966] New: [4.4 regression] ICE with ptr-to-mem-fun-returning-auto
The following code snippet triggers an ICE on mainline:
==
struct A {};
bool b = (auto (A::*)())0;
==
bug.cc:3: internal compiler error: in type_contains_placeholder_1, at
tree.c:2600
Please submit a full bug report, [etc.]
The bug appeared with the patches for the new 'auto' semantics.
--
Summary: [4.4 regression] ICE with ptr-to-mem-fun-returning-auto
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37966
[Bug c++/37965] [4.4 regression] ICE with invalid auto variable in template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37965
[Bug c++/37965] New: [4.4 regression] ICE with invalid auto variable in template
The following code snippet triggers an ICE on mainline:
template struct A
{
auto i;
};
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The bug appeared with the patches for the new 'auto' semantics.
--
Summary: [4.4 regression] ICE with invalid auto variable in
template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37965
[Bug c++/37962] New: [4.4 regression] ICE with (auto*) casts
The following code snippet triggers an ICE on mainline: int i = *(auto*)0; bug.cc:1: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2459 Please submit a full bug report, [etc.] A slightly different version triggers a similar ICE in a different place: struct A* p = (auto*)0; bug.cc:1: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_base, at cp/search.c:214 Please submit a full bug report, [etc.] The bugs appeared with the patches for the new 'auto' semantics. -- Summary: [4.4 regression] ICE with (auto*) casts Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug c++/37964] [4.4 regression] ICE with operator auto
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37964
[Bug c++/37964] New: [4.4 regression] ICE with operator auto
The following code snippet triggers an ICE on mainline:
struct A
{
operator auto();
};
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The bug appeared with the patches for the new 'auto' semantics.
--
Summary: [4.4 regression] ICE with operator auto
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37964
[Bug testsuite/37960] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #5 from manu at gcc dot gnu dot org 2008-10-30 20:27 --- (In reply to comment #3) > > Note that AVR has 8-bit chars, 16-bit ints and pointers, 32-bit longs. Just a guess, given the above: for unsigned char b, b*1000 is signed integer and it may overflow, so probably this is causing the warning. Perhaps we should only run this testcase with int32plus targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug c++/37963] [4.4 regression] ICE with (auto) cast
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37963
[Bug c++/37963] New: [4.4 regression] ICE with (auto) cast
The following code snippet triggers an ICE on mainline:
void foo()
{
(auto) { 0 };
}
bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The bug appeared with the patches for the new 'auto' semantics.
--
Summary: [4.4 regression] ICE with (auto) cast
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37963
[Bug c++/37962] [4.4 regression] ICE with (auto*) casts
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37962
[Bug fortran/37961] [F2003] random_seed - allow integer(8) for the arguments
--- Comment #1 from kargl at gcc dot gnu dot org 2008-10-30 20:20 --- (In reply to comment #0) > Fortran 2003 allows all kinds for arguments (-> please re-check). Not according to my draft of F2003. SIZE (optional) shall be scalar and of type default integer. It is an INTENT (OUT) argument. It is assigned the number N of integers that the processor uses to hold the value of the seed. > For i8 the library already contains: random_seed_i8. How to handle i16? > > Note: One still needs to support calls with different integer types, esp. if > one needs to modify the variable (-> convert back). [Unless there can be only > one argument at a time.] According th F2003 standard: Arguments. There shall either be exactly one or no arguments present. > Additionally, the front end currently rejects i8: > > Error: 'size' argument of 'random_seed' intrinsic at (1) must be of kind 4 > >1 > Error: 'put' argument of 'random_seed' intrinsic at (1) must be of kind 4 This is the correct behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37961
[Bug testsuite/37960] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #4 from manu at gcc dot gnu dot org 2008-10-30 20:17 --- (In reply to comment #3) > > I don't know if it is in the Compile Farm, or not. But I can test for you. > I need a way to debug this. I have no idea what the issue is. > Note that AVR has 8-bit chars, 16-bit ints and pointers, 32-bit longs. That doesn't ring a bell. Anyway, this is not a regression. My patch added the testcase. The bogus warning was there already. -- manu at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] FAIL: |FAIL: gcc.dg/pr11492.c |gcc.dg/pr11492.c (test for |(test for bogus messages, |bogus messages, line 8) |line 8) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug fortran/37961] New: [F2003] random_seed - allow integer(8) for the arguments
Fortran 2003 allows all kinds for arguments (-> please re-check). For i8 the library already contains: random_seed_i8. How to handle i16? Note: One still needs to support calls with different integer types, esp. if one needs to modify the variable (-> convert back). [Unless there can be only one argument at a time.] Additionally, the front end currently rejects i8: Error: 'size' argument of 'random_seed' intrinsic at (1) must be of kind 4 1 Error: 'put' argument of 'random_seed' intrinsic at (1) must be of kind 4 -- Summary: [F2003] random_seed - allow integer(8) for the arguments Product: gcc Version: 4.4.0 Status: UNCONFIRMED 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=37961
[Bug testsuite/37960] [4.4 Regression] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #3 from eric dot weddington at atmel dot com 2008-10-30 19:57 --- (In reply to comment #2) > I don't know how to compile/test AVR. Is it in the CompileFarm? > > To anyone with more knowledge on AVR, any suggestion what could cause this? Is > there any special about signed/unsigned multiplication on AVR? > I don't know if it is in the Compile Farm, or not. But I can test for you. Note that AVR has 8-bit chars, 16-bit ints and pointers, 32-bit longs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug testsuite/37960] [4.4 Regression] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #2 from manu at gcc dot gnu dot org 2008-10-30 19:04 --- I don't know how to compile/test AVR. Is it in the CompileFarm? To anyone with more knowledge on AVR, any suggestion what could cause this? Is there any special about signed/unsigned multiplication on AVR? -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-30 19:04:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug testsuite/37960] [4.4 Regression] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #1 from eric dot weddington at atmel dot com 2008-10-30 18:56 --- Bug caused by: 2008-10-29 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR 11492 * gcc.dg/pr11492.c: New. * g++.dg/warn/pr11492.C: New. Manuel, could you take a look at this? -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug testsuite/37960] New: [4.4 Regression] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8) New regression test from bug 11492 fails for AVR with: Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc -B/usr/local/avrdev/gcc/build/gcc/ /usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr11492.c -Wsign-compare -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -S -DSIGNAL_SUPPRESS -mmcu=atmega128 -o pr11492.s(timeout = 300) /usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr11492.c: In function 'main': /usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr11492.c:8: warning: comparison between signed and unsigned integer expressions output is: /usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr11492.c: In function 'main': /usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.dg/pr11492.c:8: warning: comparison between signed and unsigned integer expressions FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8) -- Summary: [4.4 Regression] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eric dot weddington at atmel dot com GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #2 from manu at gcc dot gnu dot org 2008-10-30 18:43 --- So what is this? Is the warning logic wrong or is the IR wrong? It seems to me that IR is valid. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-30 18:43:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug middle-end/37861] Bogus array bounds warning
--- Comment #1 from jamborm at gcc dot gnu dot org 2008-10-30 17:43 ---
Well, yes, we do generate that code. However, the loop is unrolled
later on and the IR code on which the vrp complains later on actually is:
main ()
{
unsigned int ivtmp.27;
unsigned int pretmp.17;
int pretmp.16;
unsigned int pretmp.15;
unsigned int anz.0;
unsigned int D.1258;
char * D.1259;
int anz;
# BLOCK 2 freq:909
# PRED: ENTRY [100.0%] (fallthru,exec)
D.1259_28 = &formatstr[0][0];
printf (&"%d %s\n"[0], 0, D.1259_28);
D.1259_39 = &formatstr[0][100];
printf (&"%d %s\n"[0], 1, D.1259_39);
D.1259_50 = &formatstr[0][200];
printf (&"%d %s\n"[0], 2, D.1259_50);
D.1259_61 = &formatstr[0][300];
printf (&"%d %s\n"[0], 3, D.1259_61);
D.1259_72 = &formatstr[0][400];
printf (&"%d %s\n"[0], 4, D.1259_72);
D.1259_83 = &formatstr[0][500];
printf (&"%d %s\n"[0], 5, D.1259_83);
D.1259_94 = &formatstr[0][600];
printf (&"%d %s\n"[0], 6, D.1259_94);
D.1259_105 = &formatstr[0][700];
printf (&"%d %s\n"[0], 7, D.1259_105);
D.1259_116 = &formatstr[0][800];
printf (&"%d %s\n"[0], 8, D.1259_116);
D.1259_7 = &formatstr[0][900];
printf (&"%d %s\n"[0], 9, D.1259_7);
printf (&" %d\n"[0], 10);
return 0;
# SUCC: EXIT [100.0%]
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-10-30 16:55 --- Known-to-work for whatever testcase you want to see this PR as a regression. As it sounds that this problem comes and goes for different testcases in different releases more testing coverage in the testsuite would probably a good idea, even for cases where it works now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug libstdc++/37958] num_get<>::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #3 from paolo dot carlini at oracle dot com 2008-10-30 16:51 --- Ok, now I see, weird. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|paolo at gcc dot gnu dot org| AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-30 16:51:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #20 from janis at gcc dot gnu dot org 2008-10-30 16:46 ---
To add to comment #18, after r128272 GCC for powerpc-linux no longer generates
bdnz for:
int reg_values[1024];
void
clear_table (unsigned int n)
{
unsigned int i;
for (i = 0; i < n; i++)
reg_values[i] = 0;
}
The patch referenced in comment #17, applied to current 4.3 branch, generates
that instruction again for this test but causes gfortran to segfault often.
As for comment #19, known to work for which particular testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-10-30 16:30 --- Can someone please specify a Known-to-work version? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||missed-optimization Priority|P1 |P3 Target Milestone|4.4.0 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug libstdc++/37958] num_get<>::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #2 from paolo dot carlini at oracle dot com 2008-10-30 16:15 --- Maybe now I see, what's behind your report: you believe that, when val is set, eofbit should be set only when seeking another character to match. But that would essentially boil down to *never* set it, in that case, because val is set only when a target sequence is uniquely matched, thus we don't look beyond the last matched character. If anything, I think this issue qualifies for a DR, I don't see compelling reasons to change the current behavior of v3, which makes sense and its consistent with the other numeric parsings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get<>::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-30 16:07 --- (In reply to comment #0) > It seems that implementation always set str.eofbit when after call of the > function (in == end). > > But standard states(22.2.2.1.2, p16) that this flag should be set only when: > "if, when seeking another character to match, it is found that (in == end)" > (on > success) > or "if the reason for the failure was that (in == end)" (on fail) > > This conditions are not the same as simply (in == end). Frankly, I don't get it. In my reading of the standard, either when val is set or val is not set, when in == end at the end then we have eofbit. Maybe you should simply attach a testcase where the behavior is incorrect, the provided one is fine (and consistent with the general behavior for numeric parsing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug target/29141] static constructors beyond 64k fail
--- Comment #4 from eric dot weddington at atmel dot com 2008-10-30 16:03 --- See also WinAVR bug #2209796 on SourceForge: https://sourceforge.net/tracker/?func=detail&atid=520074&aid=2209796&group_id=68108 -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-30 16:03:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29141
[Bug debug/37959] New: g++ does not emit DW_AT_explicit
g++ -g does not emit DW_AT_explicit for explicit constructors. It should; I think it is impossible to correctly parse some expressions without this information. -- Summary: g++ does not emit DW_AT_explicit Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37959
[Bug libstdc++/37958] New: num_get<>::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
There are some examples in the description of member function of the num_get<>
facet
iter_type do_get(iter_type in, iter_type end, ios_base& str, ios_base::iostate&
err, bool& val) const
for the case when (str.flags() & ios_base::boolalpha) != 0, that clarify the
algorithm that the function implements (22.2.2.1.2, p16):
For targets true: "1" and false: "0", the input sequence "1" yields val == true
and err == str.goodbit. For empty targets (""), any input sequence yields err
==
str.failbit.
But in both cases implementation also sets flag str.eofbit in err.
It seems that implementation always set str.eofbit when after call of the
function (in == end).
But standard states(22.2.2.1.2, p16) that this flag should be set only when:
"if, when seeking another character to match, it is found that (in == end)" (on
success)
or "if the reason for the failure was that (in == end)" (on fail)
This conditions are not the same as simply (in == end).
Short test reproduce this difference for targets "true" and "false" and input
sequence "true" (similar to the first example):
test.cpp:
#include
#include
using namespace std;
int main()
{
istringstream is("true");
bool result;
is >> boolalpha >> result;
if(is.rdstate() & ios_base::eofbit)
cout << "eofbit was set." << endl;
else
cout << "eofbit wasn't set." << endl;
return 0;
}
[EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ test.cpp && ./a.out
eofbit was set.
[EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ --version
g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
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.
The detailed bug description can be found at:
http://linuxtesting.org/results/report?num=S0735
--
Summary: num_get<>::do_get(bool) sets eofbit flag incorrectly
when boolalpha == true
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #18 from dje at gcc dot gnu dot org 2008-10-30 14:49 --- GCC no longer generates branch on count instructions on PowerPC. -- dje at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|arm-none-eabi |arm-none-eabi,powerpc-linux Priority|P3 |P1 Summary|Missed induction variable |[4.3/4.4 regression] Missed |optimization|induction variable ||optimization Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug middle-end/37929] [graphite] ICE :in single_succ_edge, at basic-block.h:642
--- Comment #3 from mitul dot thakkar at amd dot com 2008-10-30 14:43 --- (In reply to comment #2) > Under FreeBSD x68 this works in trunk and branch. I've tested it from my side and it works with current graphite branch. Thanks, Mitul Thakkar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37929
[Bug libstdc++/37957] New: Wrong behaviour of num_get<>::do_get(bool) in the case when one target sequence is a prefix of the other one
There are some examples in the description of member function of the num_get<> facet iter_type do_get(iter_type in, iter_type end, ios_base& str, ios_base::iostate& err, bool& val) const for the case when (str.flags() & ios_base::boolalpha) != 0, that clarify the algorithm that the function implements (22.2.2.1.2, p16): For targets true: "a" and false: "abb", the input sequence "a" yields val == true and err == str.eofbit; the input sequence "abc" yields err = str.failbit, with in ending at the 'c'. In the last example, however, the attached test program shows the following: [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ test.cpp && ./a.out failbit wasn't set, and result is true Rest of stream is 'bc'. It seems (from this and other tests), that the implementation stops reading from 'in' when it founds a sequence that matches one of the target sequences. But it should test, whether the sequence is a (proper) prefix of another target sequence. And if it is, the function should continue reading. This behaviour doesn't follow obviously from the description of the function, but it follows from the examples. The detailed bug description can be found at: http://linuxtesting.org/results/report?num=S0736 -- Summary: Wrong behaviour of num_get<>::do_get(bool) in the case when one target sequence is a prefix of the other one Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsyvarev at ispras dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
