[Bug target/44919] ICE on ia64 with -O3 at sel-sched.c:4672
--- Comment #4 from joachim dot reichel at gmx dot de 2010-07-14 06:22 --- I tested your patch on gcc 4.4.4. I ran into PR 40974 and used the patch in comment #20. The full program (and the test case) now compiles fine. Note that I only compiled the program. I was not able to run it because it is plugin for a GUI program and I can only test in a chroot on a remote system without X server. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44919
[Bug middle-end/44928] volatile globals illegally ignored on optimization levels 0
--- Comment #2 from ramana at gcc dot gnu dot org 2010-07-14 07:39 --- Please submit a fully pre-processed source for someone to look at this as per comment #2. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44928
[Bug fortran/44925] [OOP] C_LOC with CLASS pointer
--- Comment #9 from janus at gcc dot gnu dot org 2010-07-14 08:09 --- Subject: Bug 44925 Author: janus Date: Wed Jul 14 08:09:05 2010 New Revision: 162169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162169 Log: 2010-07-14 Janus Weil ja...@gcc.gnu.org PR fortran/44925 * gfortran.h (gfc_is_data_pointer): Remove prototype. * dependency.c (gfc_is_data_pointer): Make it static. * intrinsic.texi: Update documentation on C_LOC. * resolve.c (gfc_iso_c_func_interface): Fix pointer and target checks and add a check for polymorphic variables. 2010-07-14 Janus Weil ja...@gcc.gnu.org PR fortran/44925 * gfortran.dg/c_loc_tests_15.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_loc_tests_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44925
[Bug fortran/44925] [OOP] C_LOC with CLASS pointer
--- Comment #10 from janus at gcc dot gnu dot org 2010-07-14 08:15 --- Fixed with r162169. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44925
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-07-14 08:20 --- Mine. -- 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 Last reconfirmed|2010-07-12 00:14:46 |2010-07-14 08:20:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-07-14 08:35 --- Created an attachment (id=21196) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21196action=view) patch Can you test this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug middle-end/43995] internal compiler error: Segmentation fault on Mips64 crossbuild of ext2progs
--- Comment #7 from gnuzip at gmail dot com 2010-07-14 08:39 --- I can confirm similar problem under openwrt buildroot environment (trunk r22177) with gcc 4.5.0. The build host is Debian testing, 2.6.32-trunk-686. reproduced with: staging_dir/toolchain-mips_r2_gcc-4.5.0_uClibc-0.9.31/usr/bin/mips-openwrt-linux-uclibc-gcc -c -O2 -mips32r2 -mtune=mips32r2 -fpic recovery.i -v Using built-in specs. COLLECT_GCC=/home/w/src/openwrt/trunk/staging_dir/toolchain-mips_r2_gcc-4.5.0_uClibc-0.9.31/usr/bin/mips-openwrt-linux-uclibc-gcc COLLECT_LTO_WRAPPER=/home/w/src/openwrt/trunk/staging_dir/toolchain-mips_r2_gcc-4.5.0_uClibc-0.9.31/usr/libexec/gcc/mips-openwrt-linux-uclibc/4.5.0/lto-wrapper Target: mips-openwrt-linux-uclibc Configured with: /home/w/src/openwrt/trunk/build_dir/toolchain-mips_r2_gcc-4.5.0_uClibc-0.9.31/gcc-4.5.0/configure --prefix=/home/w/src/openwrt/trunk/staging_dir/toolchain-mips_r2_gcc-4.5.0_uClibc-0.9.31/usr --build=i486-linux-gnu --host=i486-linux-gnu --target=mips-openwrt-linux-uclibc --with-gnu-ld --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-multilib --disable-nls --with-host-libstdcxx=-lstdc++ --with-float=soft --with-gmp=/home/w/src/openwrt/trunk/staging_dir/host --with-mpfr=/home/w/src/openwrt/trunk/staging_dir/host --disable-decimal-float --with-gmp=/home/w/src/openwrt/trunk/staging_dir/host --with-mpc=/home/w/src/openwrt/trunk/staging_dir/host --with-mpfr=/home/w/src/openwrt/trunk/staging_dir/host --disable-decimal-float --disable-libssp --disable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-threads --with-slibdir=/home/w/src/openwrt/trunk/staging_dir/toolchain-mips_r2_gcc-4.5.0_uClibc-0.9.31/lib --enable-lto --with-libelf=/home/w/src/openwrt/trunk/staging_dir/host --disable-tls Thread model: posix gcc version 4.5.0 (GCC) COLLECT_GCC_OPTIONS='-c' '-O2' '-mips32r2' '-mtune=mips32r2' '-fpic' '-v' '-msoft-float' '-mllsc' '-mno-synci' /home/w/src/openwrt/trunk/staging_dir/toolchain-mips_r2_gcc-4.5.0_uClibc-0.9.31/usr/libexec/gcc/mips-openwrt-linux-uclibc/4.5.0/cc1 -fpreprocessed recovery.i -quiet -dumpbase recovery.i -mips32r2 -mtune=mips32r2 -msoft-float -mllsc -mno-synci -auxbase recovery -O2 -version -fpic -o /tmp/cc0cB1Gx.s GNU C (GCC) version 4.5.0 (mips-openwrt-linux-uclibc) compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.5.0 (mips-openwrt-linux-uclibc) compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 14a39be08080cfbd5f8220cfad9b033e mips-openwrt-linux-uclibc-gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See https://dev.openwrt.org/ for instructions. -- gnuzip at gmail dot com changed: What|Removed |Added CC||gnuzip at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43995
[Bug middle-end/43995] internal compiler error: Segmentation fault on Mips64 crossbuild of ext2progs
--- Comment #8 from gnuzip at gmail dot com 2010-07-14 08:40 --- Created an attachment (id=21197) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21197action=view) recovery.i file (openwrt) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43995
[Bug c++/44810] [4.6 Regression] FAIL: g++.dg/torture/pr36745.C
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-07-14 08:42 --- Yeah, it looks like so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44810
[Bug target/44930] [4.6 Regression] another problem with line break in output with -fverbose-asm
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-14 09:07 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44930
[Bug target/44930] [4.6 Regression] another problem with line break in output with -fverbose-asm
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-14 09:07 --- Subject: Bug 44930 Author: rguenth Date: Wed Jul 14 09:06:34 2010 New Revision: 162174 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162174 Log: 2010-07-14 Richard Guenther rguent...@suse.de PR middle-end/44930 * tree-pretty-print.c (do_niy): Do not print a newline. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-pretty-print.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44930
[Bug middle-end/44928] volatile globals illegally ignored on optimization levels 0
--- Comment #3 from asche at primion dot de 2010-07-14 09:07 --- Created an attachment (id=21198) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21198action=view) see comment What do you mean preprocessed? What I can offer is in the attachment - a standalone C file that you can compile with the option set -mthumb -mcpu=cortex-m3 -std=gnu99 -Ox -c -g -pedantic -Wall -Wextra -Iinc -fshort-enums I built the file with x = 0, 2 and 3. The objects and screenshots from the generated assembly code in out IDE are included. Please let me know what else I can do to help you. The C source code contains a description of what the code does in real life, but that is really secondary; it is obvious that there are illegal optimizations performed - in =2 and =3 in this case, glbLoopCt is not assigned within the loop, only at the end; in our production case, the comparison is not done against glbDetectedEndRAM as required by the control flow but against the constant -1 which is also illegal and breaks the code. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44928
[Bug target/44930] [4.6 Regression] another problem with line break in output with -fverbose-asm
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44930
[Bug middle-end/44928] volatile globals illegally ignored on optimization levels 0
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-14 09:12 --- Only the pointed-to value is volatile. A volatile pointer would be unsigned char * volatile ptr; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44928
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #15 from yottui at yahoo dot co dot jp 2010-07-14 09:22 ---
I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
-- begin testcase --
// g++ -O -msse2 test.cpp
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
struct vec
{
__m128i v;
static vec load(const int * p)
{ return (__m128i) __builtin_ia32_loaddqu((char const *)p); }
const int operator [](int i) const
{
union u {
__m128i v;
int e[4];
};
return ((const u )v).e[i];
}
vec() {}
vec(const __m128i a) : v(a) {}
};
extern C {
int printf (const char*, ...);
}
int main( int argc, char * argv[] )
{
__attribute__((aligned(16))) int data[] =
{ 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5 };
vec a = vec::load(data);
printf(v: %d, %d, %d, %d\n, a[0], a[1], a[2], a[3]);
return 0;
}
-- end testcase --
-- begin output --
v: 16, 16, 14, 14
-- end output --
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug middle-end/44928] volatile globals illegally ignored on optimization levels 0
--- Comment #5 from asche at primion dot de 2010-07-14 09:35 --- well, in that case we stand revealed as goofballs. Kudos to the team, thanks for a great turnaround and sincerest apologies for submitting a bogus bug request. Let us know how we can get a keg of well deserved German chilled beer to you... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44928
[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4
--- Comment #2 from htl10 at users dot sourceforge dot net 2010-07-14 10:05 --- This seems to have become an regression - it worked in 4.3.3 and failed in 4.3.5 . -- htl10 at users dot sourceforge dot net changed: What|Removed |Added Known to fail||4.3.5 Known to work||4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #17 from jojelino at gmail dot com 2010-07-14 10:07 --- (In reply to comment #16) Created an attachment (id=21196) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21196action=view) [edit] patch Can you test this patch? yes. attached patch solves ICE. it works well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug fortran/44927] static linkage with -lgomp fails on simple program
--- Comment #7 from victor dot pasko at gmail dot com 2010-07-14 10:11 --- (In reply to comment #6) Please don't keep reopening this bug. Why? I disagree with your resolution. The symbols are weak undefs because libgfortran doesn't require (and shouldn't require) libpthread, it is thread-safe only when libpthread is linked in. Therefore, I don't like that libgfortran works incorrectly in this case :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-07-14 12:19 --- Subject: Bug 44824 Author: rguenth Date: Wed Jul 14 12:19:16 2010 New Revision: 162177 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162177 Log: 2010-07-14 Richard Guenther rguent...@suse.de PR tree-optimization/44824 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Use is_gimple_mem_ref_addr. (tree_ssa_forward_propagate_single_use_vars): Do not propagate non-decl_address_invariant_p addresses. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug middle-end/44824] [4.6 regression] internal compiler error: verify_stmts failed
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-07-14 12:19 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44824
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #16 from yottui at yahoo dot co dot jp 2010-07-14 12:24 ---
This is also the wrong result with MinGW gcc 3.4.5.
I'm expecting that all component of v will be 2500.
4.4.4 of MacPorts, 4.5.0 of MacPorts, 4.4.0 of MinGW and 4.5.0-1 of MinGW were
worked fine.
This time, I did not check 3.4.6 of MacPorts.
I tried to install gcc34 of MacPorts, but failed.
-- begin testcase --
// g++ -O -msse2 test.cpp
#include xmmintrin.h
#include emmintrin.h
extern C int printf (const char*, ...);
// There is no _mm_castps_si128() in gcc 3.4
inline __m128i my_castps_si128(const __m128 a)
{
//return *(const __m128i *)a; // same result
union u {
__m128 s;
__m128i i;
};
const u v = (const u )a;
return v.i;
}
inline __m128 my_castsi128_ps(const __m128i a)
{
//return *(const __m128 *)a; // same result
union u {
__m128 s;
__m128i i;
};
const u v = (const u )a;
return v.s;
}
int main( int argc, char * argv[] )
{
union u {
__m128i v;
int e[4];
};
__m128i a = _mm_set1_epi32(1250);
__m128i b = _mm_set1_epi32(2);
__m128i v0 = _mm_setzero_si128();
__m128i al = _mm_unpacklo_epi32(a, v0);
__m128i ah = _mm_unpackhi_epi32(a, v0);
__m128i bl = _mm_unpacklo_epi32(b, v0);
__m128i bh = _mm_unpackhi_epi32(b, v0);
__m128i lo = _mm_mul_epu32(al, bl);
__m128i hi = _mm_mul_epu32(ah, bh);
__m128 sl = my_castsi128_ps(lo);
__m128 sh = my_castsi128_ps(hi);
__m128 s = _mm_shuffle_ps(sl, sh, 0x88); // 2, 0, 2, 0
__m128i r = my_castps_si128(s);
u v = (u )r;
printf(v: %d, %d, %d, %d\n, v.e[0], v.e[1], v.e[2], v.e[3]);
return 0;
}
-- end testcase --
-- begin output --
v: 0, 0, 2500, 2500
-- end output --
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug driver/44933] New: --help=common undocumented
$ grep -A11 specifics\[] gcc/opts.c
specifics[] =
{
{ optimizers, CL_OPTIMIZATION },
{ target, CL_TARGET },
{ warnings, CL_WARNING },
{ undocumented, CL_UNDOCUMENTED },
{ params, CL_PARAMS },
{ joined, CL_JOINED },
{ separate, CL_SEPARATE },
{ common, CL_COMMON },
{ NULL, 0 }
};
./xgcc --help | grep help=
--help={target|optimizers|warnings|params|[^]{joined|separate|undocumented}}[,...]
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 6a0dae5..a1aad41 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -3366,7 +3366,7 @@ display_help (void)
fputs (_( -pass-exit-codes Exit with highest error code from a
phase\n), stdout);
fputs (_( --help Display this information\n), stdout);
fputs (_( --target-helpDisplay target specific command line
options\n), stdout);
- fputs (_(
--help={target|optimizers|warnings|params|[^]{joined|separate|undocumented}}[,...]\n),
stdout);
+ fputs (_(
--help={common|target|optimizers|warnings|params|[^]{joined|separate|undocumented}}[,...]\n),
stdout);
fputs (_( Display specific types of command line
options\n), stdout);
if (! verbose_flag)
fputs (_( (Use '-v --help' to display command line options of
sub-processes)\n), stdout);
oh and AFAICS there is no --help=debug that would list (e.g.)
-fdump-[rtl|tree]-pass
--
Summary: --help=common undocumented
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44933
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #17 from sezeroz at gmail dot com 2010-07-14 14:02 ---
(In reply to comment #16)
This is also the wrong result with MinGW gcc 3.4.5.
I'm expecting that all component of v will be 2500.
4.4.4 of MacPorts, 4.5.0 of MacPorts, 4.4.0 of MinGW and 4.5.0-1 of MinGW were
worked fine.
This time, I did not check 3.4.6 of MacPorts.
I tried to install gcc34 of MacPorts, but failed.
-- begin testcase --
// g++ -O -msse2 test.cpp
#include xmmintrin.h
#include emmintrin.h
extern C int printf (const char*, ...);
// There is no _mm_castps_si128() in gcc 3.4
inline __m128i my_castps_si128(const __m128 a)
{
//return *(const __m128i *)a; // same result
union u {
__m128 s;
__m128i i;
};
const u v = (const u )a;
return v.i;
}
inline __m128 my_castsi128_ps(const __m128i a)
{
//return *(const __m128 *)a; // same result
union u {
__m128 s;
__m128i i;
};
const u v = (const u )a;
return v.s;
}
int main( int argc, char * argv[] )
{
union u {
__m128i v;
int e[4];
};
__m128i a = _mm_set1_epi32(1250);
__m128i b = _mm_set1_epi32(2);
__m128i v0 = _mm_setzero_si128();
__m128i al = _mm_unpacklo_epi32(a, v0);
__m128i ah = _mm_unpackhi_epi32(a, v0);
__m128i bl = _mm_unpacklo_epi32(b, v0);
__m128i bh = _mm_unpackhi_epi32(b, v0);
__m128i lo = _mm_mul_epu32(al, bl);
__m128i hi = _mm_mul_epu32(ah, bh);
__m128 sl = my_castsi128_ps(lo);
__m128 sh = my_castsi128_ps(hi);
__m128 s = _mm_shuffle_ps(sl, sh, 0x88); // 2, 0, 2, 0
__m128i r = my_castps_si128(s);
u v = (u )r;
printf(v: %d, %d, %d, %d\n, v.e[0], v.e[1], v.e[2], v.e[3]);
return 0;
}
-- end testcase --
-- begin output --
v: 0, 0, 2500, 2500
-- end output --
--
sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #18 from sezeroz at gmail dot com 2010-07-14 14:05 --- (In reply to comment #15) I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW. This case fails with 4.4 on i686-linux too, printing 16, 16, 14, 14 instead of 16, 15, 14, 13 which 4.3 does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug c++/44909] [C++0x] Copy constructors implicitly deleted
--- Comment #3 from marc dot glisse at normalesup dot org 2010-07-14 14:08 --- Created an attachment (id=21199) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21199action=view) extra testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
[Bug c++/44909] [C++0x] Copy constructors implicitly deleted
--- Comment #4 from marc dot glisse at normalesup dot org 2010-07-14 14:14 --- The patch (or another one committed recently) seems to have broken the attached testcase (as you can see from the names, this comes from the same code), including in C++98 mode. If it is unrelated, sorry for adding it to this bug instead of creating a new one. (I am not reopening the bug, you probably know better than me what the appropriate action is) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
[Bug bootstrap/40894] [4.4/4.5/4.6 Regression] bootstrap4-lean failed crtfastmath.o comparision
--- Comment #6 from htl10 at users dot sourceforge dot net 2010-07-14 14:25 --- 4.3.5 also bootstrap4-lean alright (hit bug 40947 later with libjava). -- htl10 at users dot sourceforge dot net changed: What|Removed |Added Known to work|4.3.1 4.3.3 |4.3.1 4.3.3 4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894
[Bug c++/44909] [C++0x] Copy constructors implicitly deleted
--- Comment #5 from paolo dot carlini at oracle dot com 2010-07-14 14:30 --- I can confirm the new testcase doesn't compile anymore. Let's re-open this PR to be safe. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
[Bug bootstrap/40894] [4.4/4.5/4.6 Regression] bootstrap4-lean failed crtfastmath.o comparision
--- Comment #7 from htl10 at users dot sourceforge dot net 2010-07-14 14:44 --- 4.4.4 (built with 4.3.3) fails at stage 3 and 4 comparison. Comparing stages 3 and 4 Bootstrap comparison failure! ./crtfastmath.o differs make[2]: *** [compare3] Error 1 objdump -Dxzs stage3-gcc/crtfastmath.o stage3-dump objdump -Dxzs stage4-gcc/crtfastmath.o stage4-dump # diff -u stage3-dump stage4-dump --- stage3-dump 2010-07-14 15:30:13.0 +0100 +++ stage4-dump 2010-07-14 15:30:27.0 +0100 @@ -1,6 +1,6 @@ -stage3-gcc/crtfastmath.o: file format ecoff-littlealpha -stage3-gcc/crtfastmath.o +stage4-gcc/crtfastmath.o: file format ecoff-littlealpha +stage4-gcc/crtfastmath.o architecture: alpha, flags 0x0035: HAS_RELOC, HAS_LINENO, HAS_SYMS, HAS_LOCALS start address 0x @@ -70,7 +70,7 @@ 0010 00301f22 10807da7 00405b6b 0100ba27 .0..@[k...' 0020 2480bd23 5ea7 1000de23 0180fa6b $..#..^#...k Contents of section .xdata: - 0030 3100 02000204 1... + 0030 0100 02000204 Contents of section .pdata: 0040 ecff Contents of section .lita: @@ -100,7 +100,7 @@ Disassembly of section .xdata: 0030 .xdata: - 30: 31 00 00 00 call_pal0x31 + 30: 01 00 00 00 call_pal0x1 34: 02 00 02 04 .long 0x4020002 38: 00 00 00 00 halt 3c: 00 00 00 00 halt -- htl10 at users dot sourceforge dot net changed: What|Removed |Added Known to fail|4.4.0 4.4.1 |4.4.0 4.4.1 4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894
[Bug c++/44909] [C++0x] Copy constructors implicitly deleted
--- Comment #6 from paolo dot carlini at oracle dot com 2010-07-14 14:45 --- I can also confirm that r162158 accepted zut.cc and r162159 doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
[Bug fortran/44934] New: [4.6 Regression] Bogus Missing format for FORMATTED data transfer
Since at least revision 161984 (r158921 works), the test FM411 of the NIST suite fails. The following reduced test shows the problem: [macbook] f90/bug% cat FM411_red.f PROGRAM FM411 I04 = 8 ENDFILE I04 READ (I04) IVON01 END [macbook] f90/bug% gfc FM411_red.f [macbook] f90/bug% a.out At line 4 of file FM411_red.f (unit = 8, file = 'fort.8') Fortran runtime error: Missing format for FORMATTED data transfer -- Summary: [4.6 Regression] Bogus Missing format for FORMATTED data transfer Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug testsuite/44932] gcc.dg/uninit-pred-9_b.c fails
--- Comment #2 from pthaugen at gcc dot gnu dot org 2010-07-14 15:11 --- Created an attachment (id=21200) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21200action=view) dump file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44932
[Bug testsuite/44932] gcc.dg/uninit-pred-9_b.c fails
--- Comment #3 from pthaugen at gcc dot gnu dot org 2010-07-14 15:12 --- Created an attachment (id=21201) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21201action=view) dump file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44932
[Bug lto/44935] New: internal compiler error: in assign_stack_temp_for_type, at function.c:785
c++ -fno-rtti -O2 -fwhopr=24 -fuse-linker-plugin -pthread -fPIC ~/f?.ii -fpermissive -fno-strict-aliasing -fshort-wchar In file included from ../../../xpcom/glue/nsCOMPtr.h:512:0, from :110: ../../../xpcom/glue/GenericModule.cpp: In member function ‘GetClassObject’: ../../../xpcom/glue/GenericModule.cpp:63:41: internal compiler error: in assign_stack_temp_for_type, at function.c:785 -- Summary: internal compiler error: in assign_stack_temp_for_type, at function.c:785 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44935
[Bug lto/44935] internal compiler error: in assign_stack_temp_for_type, at function.c:785
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-07-14 15:37 --- Created an attachment (id=21202) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21202action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44935
[Bug lto/44935] internal compiler error: in assign_stack_temp_for_type, at function.c:785
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-07-14 15:38 --- Created an attachment (id=21203) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21203action=view) testcase 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44935
[Bug fortran/44931] For INPUT_UNIT, INQUIRE NAME= should not return stdin
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-14 15:44 --- Some remarks: a) The note 9.63 is nonnormative - still one should try to follow it b) Most of my compilers simply use , ifort uses /dev/pts/3 (for stdin/out/err), and Portland uses the same as gfortran: stdin, stdout, stderr. c) gfortran prints /dev/pts/3 when calling ttynam() with the relevant unit numbers. d) The name stdin etc. is set for error reporting at http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/io/unit.c;hb=HEAD#l86 -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44931
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #19 from hjl dot tools at gmail dot com 2010-07-14 15:52
---
(In reply to comment #15)
I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
-- begin testcase --
// g++ -O -msse2 test.cpp
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
struct vec
{
__m128i v;
static vec load(const int * p)
{ return (__m128i) __builtin_ia32_loaddqu((char const *)p); }
const int operator [](int i) const
{
union u {
__m128i v;
int e[4];
};
return ((const u )v).e[i];
}
vec() {}
vec(const __m128i a) : v(a) {}
};
extern C {
int printf (const char*, ...);
}
int main( int argc, char * argv[] )
{
__attribute__((aligned(16))) int data[] =
{ 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5 };
vec a = vec::load(data);
printf(v: %d, %d, %d, %d\n, a[0], a[1], a[2], a[3]);
return 0;
}
-- end testcase --
-- begin output --
v: 16, 16, 14, 14
-- end output --
This is caused by revision 134947:
http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00107.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug lto/44935] internal compiler error: in assign_stack_temp_for_type, at function.c:785
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-14 15:56 --- I will 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-14 15:56:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44935
[Bug c++/44810] [4.6 Regression] FAIL: g++.dg/torture/pr36745.C
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-07-13 21:23:08 |2010-07-14 16:39:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44810
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-07-14 16:41 --- (In reply to comment #15) I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW. I think the code in comment #15 is invalid and voilates C/C++ aliasing rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #21 from pinskia at gcc dot gnu dot org 2010-07-14 16:44 --- (In reply to comment #20) (In reply to comment #15) I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW. I think the code in comment #15 is invalid and voilates C/C++ aliasing rules. Even if it did not voilate aliasing rules, the IR looks good: D.4999_70 = VIEW_CONVERT_EXPRconst union u(D.4995_68).i; D.4863_25 = VIEW_CONVERT_EXPRunion u(D.4999_70).e[3]; D.4864_26 = VIEW_CONVERT_EXPRunion u(D.4999_70).e[2]; D.4865_27 = VIEW_CONVERT_EXPRunion u(D.4999_70).e[1]; D.4866_28 = VIEW_CONVERT_EXPRunion u(D.4999_70).e[0]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #22 from pinskia at gcc dot gnu dot org 2010-07-14 16:50 --- (In reply to comment #21) Even if it did not voilate aliasing rules, the IR looks good: The expansion looks incorrect though: (insn 39 38 40 t.cc:55 (set (reg:DI 107) (vec_select:DI (reg:V2DI 79 [ D.4999 ]) (parallel [ (const_int 1 [0x1]) ]))) -1 (nil)) (insn 40 39 41 t.cc:55 (set (reg:DI 108) (vec_select:DI (reg:V2DI 79 [ D.4999 ]) (parallel [ (const_int 1 [0x1]) ]))) -1 (nil)) (insn 41 40 42 t.cc:55 (set (reg:DI 109) (vec_select:DI (reg:V2DI 79 [ D.4999 ]) (parallel [ (const_int 0 [0x0]) ]))) -1 (nil)) (insn 42 41 43 t.cc:55 (set (reg:DI 110) (vec_select:DI (reg:V2DI 79 [ D.4999 ]) (parallel [ (const_int 0 [0x0]) ]))) -1 (nil)) (insn 43 42 44 t.cc:55 (set (reg:SI 37 r8) (subreg:SI (reg:DI 107) 0)) -1 (nil)) (insn 44 43 45 t.cc:55 (set (reg:SI 2 cx) (subreg:SI (reg:DI 108) 0)) -1 (nil)) (insn 45 44 46 t.cc:55 (set (reg:SI 1 dx) (subreg:SI (reg:DI 109) 0)) -1 (nil)) (insn 46 45 47 t.cc:55 (set (reg:SI 4 si) (subreg:SI (reg:DI 110) 0)) -1 (nil)) Please file that as a different bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug c++/44810] [4.6 Regression] FAIL: g++.dg/torture/pr36745.C
--- Comment #6 from jason at gcc dot gnu dot org 2010-07-14 17:01 --- Subject: Bug 44810 Author: jason Date: Wed Jul 14 17:01:15 2010 New Revision: 162189 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162189 Log: PR c++/44810 * g++.dg/torture/pr36745.C: Avoid undefined behavior. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr36745.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44810
[Bug c++/44810] [4.6 Regression] FAIL: g++.dg/torture/pr36745.C
--- Comment #7 from jason at gcc dot gnu dot org 2010-07-14 17:02 --- Fixed testcase. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44810
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #9 from rob1weld at aol dot com 2010-07-14 17:27 --- Thanks for working on this guys, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-14 17:32 ---
I think we agree that the code is invalid. But I also would prefer a message
such as GCC 4.5 had:
At line 4 of file aa.f90 (unit = 8, file = 'fort.8')
Fortran runtime error: End of file
The commit causing this diagnostics regression is probably Rev. : for PR
libfortran/44477, cf. http://gcc.gnu.org/viewcvs?root=gccview=revrev=161021
Actually, I am expecting the following error message from data_transfer_init:
+ if (dtp-u.p.current_unit-flags.access == ACCESS_SEQUENTIAL)
+ if (dtp-u.p.current_unit-endfile == AFTER_ENDFILE)
+ {
+ generate_error (dtp-common, LIBERROR_OPTION_CONFLICT,
+ Sequential READ or WRITE not allowed after
+ EOF marker, possibly use REWIND or BACKSPACE);
However,
(gdb) p dtp-u.p.current_unit-endfile
$2 = NO_ENDFILE
By the way, I think that check should be moved before the format checks.
Another question is why is the file marked as FORMATTED? READ (unit) should
be unformatted, shouldn't it? And the file has not been explicitly opened for
formatted I/O. Or have I missed some I/O fine print?
p dtp-u.p.current_unit-flags.form
$3 = FORM_FORMATTED
p dtp-common.flags
$5 = 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug fortran/44744] Missing -fcheck=bounds diagnostic for function assignment with tmp array
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-14 17:42 --- After PR 44773 has been fixed, we are back to things which failed before. Test case which has no diagnostic (same as the one in comment 0 but with TARGET attribute to force the creation of an array temporary) integer, target :: a(-4:1), b(0:4) b = 5 i = 0 a(i:1) = f(b) contains function f(x) integer :: x(:),f(size(x)) f = x end function end -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-07-14 17:42:11 date|| Summary|[4.6 Regression] Missed |Missing -fcheck=bounds |runtime error after revision|diagnostic for function |161550 |assignment with tmp array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-14 17:57 --- The original code has a line REWIND I04 after ENDFILE I04 I have removed it to reduce the test, but adding it does not change the runtime error. Also I doubt that the NIST suite contains invalid code. Apparently ENDFILE opens the file as formatted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug testsuite/42855] FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized *
--- Comment #4 from pthaugen at gcc dot gnu dot org 2010-07-14 18:18 --- Based on the last post in the patch thread should the patch be committed so the testsuite failures go away and this can be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #3 from kargl at gcc dot gnu dot org 2010-07-14 18:21 --- (In reply to comment #2) The original code has a line REWIND I04 after ENDFILE I04 I have removed it to reduce the test, but adding it does not change the runtime error. Also I doubt that the NIST suite contains invalid code. Apparently ENDFILE opens the file as formatted. Even with the rewind statement, the code may still be invalid. See 9.4.3 Connection of a file to a unit in F2003, and also see 9.7.2 ENDFILE statement. ENDFILE only operates on connected files. The unit number I04 in your example is not connected to a file at the point of execution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug fortran/44936] New: [OOP] Generic TBP not resolved correctly at compile time
Following the discussion in http://gcc.gnu.org/ml/fortran/2010-07/msg00174.html this is a split of a test case I had added to PR42385, taken from 43945, but it does not quite belong there. The problem is: the static resolution mechanism that is invoked when the type is knonwn at compile time goes wrong when the base type has a binding-name different from the procedure-name. -- Summary: [OOP] Generic TBP not resolved correctly at compile time Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it 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=44936
[Bug fortran/44936] [OOP] Generic TBP not resolved correctly at compile time
--- Comment #1 from sfilippone at uniroma2 dot it 2010-07-14 18:33 --- See attachment #21184 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44936
[Bug c/44937] New: crash due to null pointer deref
[reg...@gamow tmp420]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r162143-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r162143-install
--program-prefix=r162143- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100713 (experimental) (GCC)
[reg...@gamow tmp420]$ valgrind -q --trace-children=yes current-gcc -O2 small.c
-w
==30337== Invalid read of size 2
==30337==at 0x697485: walk_stmt_load_store_addr_ops (gimple.c:4776)
==30337==by 0x9B3512: rebuild_cgraph_edges (cgraphbuild.c:471)
==30337==by 0x72D5CD: execute_one_pass (passes.c:1565)
==30337==by 0x72D864: execute_pass_list (passes.c:1620)
==30337==by 0x72CACB: do_per_function_toporder (passes.c:1158)
==30337==by 0x72DC85: execute_ipa_pass_list (passes.c:1920)
==30337==by 0x9B8BF0: cgraph_optimize (cgraphunit.c:1851)
==30337==by 0x9B8E4A: cgraph_finalize_compilation_unit (cgraphunit.c:1171)
==30337==by 0x4A7C32: c_write_global_declarations (c-decl.c:9698)
==30337==by 0x7CED29: toplev_main (toplev.c:990)
==30337==by 0x5935ABC: (below main) (libc-start.c:220)
==30337== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==30337==
small.c: In function 'func_4':
small.c:29:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[reg...@gamow tmp420]$ cat small.c
int g_19;
int *g_42;
int **volatile g = g_42;
int g_67[5][9][2][1] = {
};
int
func_4 (int p_5, unsigned char p_6, unsigned char p_7)
{
unsigned char l_8[1];
if (p_6)
goto lbl_13;
for (p_6 = 0; p_6; p_6 = (p_6, 0))
if (0)
{
}
else
lbl_13:for (p_6 = 0; p_6 1; p_6 += 1)
l_8[p_6] = 0;
return 0;
}
int *
func_45 (unsigned long p_46, unsigned char p_47)
{
int *l_56 = g_19;
l_56 != g | !1 == func_4 (0, g_67[2][6][1][0], 0) ^ func_4 (1, 0, 0);
return 0;
}
--
Summary: crash due to null pointer deref
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
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=44937
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #20 from amylaar at gcc dot gnu dot org 2010-07-14 20:23 --- (In reply to comment #11) I wonder if there is any overlap with this bug and PR29404/42308? libiberty doesn't use $(toplevel_builddir)/gcc/site.exp, so there is no direct connection, but libiberty/Makefile.in also has CC = @CC@, where $(CC) is not the same as @CC@ if the former is overridden by the toplevel Makefile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug rtl-optimization/42621] [4.4 Regression] Computed gotos on AMD 800% slower
--- Comment #11 from jyasskin at gmail dot com 2010-07-14 20:49 --- Is this the same bug as PR 39284? -- jyasskin at gmail dot com changed: What|Removed |Added CC||jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
[Bug fortran/42385] [OOP] poylmorphic operators do not work
--- Comment #6 from burnus at gcc dot gnu dot org 2010-07-14 21:43 --- The test cases in comment 3 (attachment 21184) and comment 4 (attachment 20927) are now tracked in PR 44936 - and fixed by the draft patch there. The original test case (comment 0) still generates wrong code and the test from comment 1 still does compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42385
[Bug fortran/44936] [OOP] Generic TBP not resolved correctly at compile time
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-14 21:45 --- Draft patch: http://gcc.gnu.org/ml/fortran/2010-07/msg00176.html Fixes the test cases in comment 2 (attachment 21184) and attachment 20927 (cf. PR 42385 comment 4 and PR 43945 comment 19). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44936
[Bug c/44939] New: Questions on details of -pedantic
Why does it change the output of the compilation of certain programs? The
documentation implies strongly that it only affects the warnings produced. The
following program demonstrates this.
-
/* Authors: Florian Schanda and Martin Brain */
#include stdio.h
int main(int argc, char ** argv)
{
const int foo = 5;
int b;
void * ptr;
int * intptr;
ptr = (void*)foo;
intptr = (int*)ptr;
*intptr = 10;
b = foo;
if (b == 5) {
printf(You seem to constant fold stuff.\n);
} else {
printf(You don't seem to constant fold.\n);
}
return 0;
}
-
$ gcc -Wall -O3 stupid.c ./a.out
You seem to constant fold stuff.
$ gcc -Wall -O3 -pedantic stupid.c ./a.out
You don't seem to constant fold.
We note that this works as expected with g++, i.e. pedantic doesn't change
the output of the program.
--
Summary: Questions on details of -pedantic
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: florian at schanda dot org dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44939
[Bug c/44939] Questions on details of -pedantic
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-14 23:04 --- -pedantic should not change the behavior of defined code. This code is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44939
[Bug other/44940] New: XMEGA RAMPZ Initialization
When compiling a bootloader for the XMEGA128 (starting address 0x2), RAMPZ is initialized to 2 in the __do_copy_data section. This has the effect that any indirect register access will fail. For example the following code extract will result in the register NOT being set to 0xCB when RAMPZ = 2. 20c6e: 2b ec ldi r18, 0xCB ; 203 20c70: e0 e5 ldi r30, 0x50 ; 80 20c72: f0 e0 ldi r31, 0x00 ; 0 20c74: 22 83 std Z+2, r18; 0x02 To recreate this, simply put OSC.XOSCCTRL = 0xCB; in the main function and link to bootloader memory space. -- Summary: XMEGA RAMPZ Initialization Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: darkdragon2000 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44940
[Bug rtl-optimization/44941] New: [4.6 Regression] ICE: RTL check: expected code 'mem', have 'reg' in emit_block_move_hints, at expr.c:1189
Command line: $ gcc -O[123s] testcase.c Compiler output: $ gcc -O testcase.c testcase.c: In function 'foo': testcase.c:7:7: internal compiler error: RTL check: expected code 'mem', have 'reg' in emit_block_move_hints, at expr.c:1189 Unreduced testcase crashes with: $ gcc -O rarpd.i rarpd.c: In function 'load_if': rarpd.c:203:41: internal compiler error: in make_decl_rtl, at varasm.c:1346 Reduced testcase without rtl checking crashes with: $ gcc -O testcase.c testcase.c: In function 'foo': testcase.c:7:7: internal compiler error: Segmentation fault Tested revisions: r162193 - crash r162056 - crash r161659 - crash r161170 - OK -- Summary: [4.6 Regression] ICE: RTL check: expected code 'mem', have 'reg' in emit_block_move_hints, at expr.c:1189 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44941
[Bug rtl-optimization/44941] [4.6 Regression] ICE: RTL check: expected code 'mem', have 'reg' in emit_block_move_hints, at expr.c:1189
--- Comment #1 from zsojka at seznam dot cz 2010-07-14 23:25 --- Created an attachment (id=21204) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21204action=view) reduced testcase (from iptraf sources) Command line: $ gcc -O pr44941.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44941
[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
--- Comment #1 from jyasskin at gmail dot com 2010-07-15 00:34 --- My current guess is that the bug is at parser.c:16741, at the end of cp_parser_class_head(): DECL_SOURCE_LOCATION (TYPE_NAME (type)) = type_start_token-location; This updates the template's location, but it doesn't update the locations of any instantiations that have already been created. I'm going to try to find the existing instantiations to update them there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641
[Bug tree-optimization/44794] pre- and post-loops should not be unrolled.
--- Comment #4 from changpeng dot fang at amd dot com 2010-07-15 01:50 --- Created an attachment (id=21205) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21205action=view) Do not unroll pre and post loops I did a quick test on polyhedron before and after applying the preliminary patch. Tests are based on -O3 -fprefetch-loop-arrays -funroll-loops. timing (s) | size (B) before after %deduc | before after %deduc cacacita 14.35 10.88 24.18 | 90715 72843 19.7 gas_dyn 34.68 21.58 37.77 | 149608 100936 32.53 nf 33.91 19.32 43.03 | 139150 83054 40.31 protein 51.35 33.23 35.29 | 163672 122808 24.97 rnflow 60.9 43.28 28.93 | 268784 169152 37.07 test_fpu 52.61 30.35 42.31 | 234045 144285 38.35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44794
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-07-15 01:56 --- Caused by my patch -r161020, will fix, subtle -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug c/44942] New: Bug in argument passing of long double
On X86-64, the following code demonstrates how passing a long double as a fixed
argument causes corruption of the following variable arguments.
#include stdio.h
#include assert.h
#include stdarg.h
void test(int a, int b, int c, int d, int e, int f, int g, long double h, ...)
{
int i;
va_list ap;
va_start(ap, h);
i = va_arg(ap, int);
printf(Got %d, expected %d\n, i, 123456789);
va_end(ap);
}
int main() {
test(0, 0, 0, 0, 0, 0, 0, (long double)0.0, (int)123456789);
return 0;
}
--
Summary: Bug in argument passing of long double
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pdox at alum dot mit dot edu
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=44942
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-07-15 03:32 --- Created an attachment (id=21206) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21206action=view) Fix for this regression. Tobias said: Another question is why is the file marked as FORMATTED? READ (unit) should be unformatted, shouldn't it? And the file has not been explicitly opened for formatted I/O. Or have I missed some I/O fine print? Attached patch fixes this. I assumed unspecified would be correct. It is not. The patch cleans up whitespace in transfer.c, ignore that. The bug is in file_pos.c. Also, I botched endfile_2.f90 which was trying to tell me we had a regression. Thanks Dominique for reporting the problem. Regression tests ok. I will commit shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-07-15 03:41 --- Subject: Bug 44934 Author: jvdelisle Date: Thu Jul 15 03:40:56 2010 New Revision: 162203 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162203 Log: 2010-07-14 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/44934 * io/file_pos.c (st_endfile): Correctly set unit flags for form. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-07-15 03:42 --- Subject: Bug 44934 Author: jvdelisle Date: Thu Jul 15 03:42:29 2010 New Revision: 162204 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162204 Log: 2010-07-14 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/44934 * gfortran.dg/endfile_2.f90: Fix to unformatted file type. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/endfile_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug fortran/44934] [4.6 Regression] Bogus Missing format for FORMATTED data transfer
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-07-15 03:44 --- Fixed. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44934
[Bug tree-optimization/44900] [4.5 Regression] The variable of SSE will be broken
--- Comment #23 from yottui at yahoo dot co dot jp 2010-07-15 03:45 --- (In reply to comment #22) Please file that as a different bug. May I enter comment #15 as a new bug to Bugzilla? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
[Bug c/44943] New: Need documentation on the intended semantics of volatile (in C)
[Filing this as gcc 4.4.4 since that is the version of the docs I'm looking at, however, we care about behavior from gcc 3.4 and onward.] A major disagreement has developed inside the Linux kernel community about the semantics that gcc imposes on volatile. One school of thought states that volatile operations (both volatile memory references and asm volatile) are equivalent to device I/O and therefore: a) will be issued exactly once per programmatic execution; b) will not be reordered with respect to each other (as opposed to with respect to nonvolatile operations). We have relied pretty hard on these two properties in the Linux kernel, but the documentation makes it unclear if this is indeed the intended semantics. It would be good if this could be clarified and documented. Since this is affecting current Linux kernel code, we would appreciate a formal reply as quickly as possible. The examples in the documentation are all volatile vs. non-volatile. We are clear on the fact that volatiles can be reordered with respect to nonvolatiles, except that asm volatile takes all of memory as an implicit input, and obviously memory clobbers are used to make all of memory an implicit output. I believe the following statement in the documentation does, indeed, provide the guarantee we need, but we would like to make it explicit, especially since (a) it is found in a section about C++, and (b) it technically refers to the C/C++ standards, and asm is inherently non-standard. Both the C and C++ standard have the concept of volatile objects. These are normally accessed by pointers and used for accessing hardware. The standards encourage compilers to refrain from optimizations concerning accesses to volatile objects. The C standard leaves it implementation defined as to what constitutes a volatile access. The C++ standard omits to specify this, except to say that C++ should behave in a similar manner to C with respect to volatiles, where possible. The minimum either standard specifies is that at a sequence point all previous accesses to volatile objects have stabilized and no subsequent accesses have occurred. Thus an implementation is free to reorder and ^ combine volatile accesses which occur between sequence points, but ^^ cannot do so for accesses across a sequence point. The use of ^^ volatiles does not allow you to violate the restriction on updating objects multiple times within a sequence point. Your help in authoritatively clarifying the situation would be most appreciated. -- Summary: Need documentation on the intended semantics of volatile (in C) Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hpa at zytor dot com GCC build triplet: any GCC host triplet: any GCC target triplet: any http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44943
[Bug c++/44944] New: g++ segfault with -fvisibility-inlines-hidden -O2 -fno-exceptions
Using gcc-4.5 (r162000) to build webkit, cc1plus slowly exhausted all my memory (6gb + 6gb swap) and was OOM killed. Compiling the preprocessed file reduced the problem to a quick (5 second) segfault. -- Summary: g++ segfault with -fvisibility-inlines-hidden -O2 -fno- exceptions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: graham dot gower at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: mipsel-oe-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44944
[Bug c++/44944] g++ segfault with -fvisibility-inlines-hidden -O2 -fno-exceptions
--- Comment #1 from graham dot gower at gmail dot com 2010-07-15 05:12 --- Created an attachment (id=21207) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21207action=view) preprocessed file from webkit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44944
[Bug c++/44944] g++ segfault with -fvisibility-inlines-hidden -O2 -fno-exceptions -fPIC
--- Comment #2 from graham dot gower at gmail dot com 2010-07-15 05:13 --- g...@eye7:/tmp$ ~/oe2/tmp/cross/mipsel/bin/mipsel-oe-linux-g++ -c FrameLoader.ii -fvisibility-inlines-hidden -O2 -fno-exceptions -fPIC mipsel-oe-linux-g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. -- graham dot gower at gmail dot com changed: What|Removed |Added Summary|g++ segfault with - |g++ segfault with - |fvisibility-inlines-hidden -|fvisibility-inlines-hidden - |O2 -fno-exceptions |O2 -fno-exceptions -fPIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44944
