[Bug libstdc++/38340] New: Error in pthread.h
Hi, I am facing an error in pthread.h while compiling my application using gcc 4.1.2. But I don't have any error if I compile same applicaiton using gcc 3.2.3. Can anyone help me? GCC Build: Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) Error: In file included from restart.c:48: /usr/include/pthread.h:495: error: expected specifier-qualifier-list before '__jmp_buf' make[3]: *** [restart.o] Error 1 make[2]: *** [lib] Error 2 make[1]: *** [svc_libs] Error 2 make[1]: Leaving directory `/home/skrishn4/services' make: *** [default] Error 2 -- Summary: Error in pthread.h Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: saravanan-2 dot krishnamoorthy-2 at cognizant dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38340
[Bug libmudflap/38339] libtool: compile: not configured to build any kind of library
--- Comment #1 from gzp at gmx dot net 2008-12-01 08:03 --- Created an attachment (id=16796) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16796action=view) config.log environment log.configure log.make Inside the files.tar you can find the following files: config.log environment log.configure log.make -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38339
[Bug c/38341] New: Wrong warning comparison of promoted ~unsigned with unsigned
Compiler gives wrong warning for comparison of promoted ~unsigned with
unsigned when compiling with ARM-ELF.
Submit script for building arm-elf toolchain and testcode.
Compilation using;
arm-elf-gcc -c cast.c -W
cast.c: In function 'test_cast':
cast.c:13: warning: comparison of promoted ~unsigned with unsigned
Best Regards
Fredrik Hederstierna
FILE: cast.c
typedef unsigned char u8_t;
void test_cast(void) {
unsigned char c1 = 0;
unsigned char c2 = 0;
u8_t u1 = 0;
u8_t u2 = 0;
if (c1 == (unsigned char)(~c2)) {
}
if (u1 == (u8_t)(~u2)) { // THIS WILL GIVE WARNING
}
}
FILE: build_toolchain.sh
set -e -x
TARGET=arm-elf
BINUTILS_VERSION=2.19
GCC_VERSION=4.3.2
NEWLIB_VERSION=1.16.0
GDB_VERSION=6.8
INSIGHT_VERSION=6.8
DEST=/usr/local/gcc/arm-elf-tools-$GCC_VERSION
BINUTILS_DIR=binutils-$BINUTILS_VERSION
GCC_DIR=gcc-$GCC_VERSION
NEWLIB_DIR=newlib-$NEWLIB_VERSION
GDB_DIR=gdb-$GDB_VERSION
INSIGHT_DIR=insight-$INSIGHT_VERSION
# set rwx access
umask 022
# unpack tar-balls
rm -fr $BINUTILS_DIR $GCC_DIR $NEWLIB_DIR $GDB_DIR $INSIGHT_DIR
tar xvjf binutils-$BINUTILS_VERSION.tar.bz2
tar xvjf gcc-$GCC_VERSION.tar.bz2
tar xvzf newlib-$NEWLIB_VERSION.tar.gz
tar xvjf gdb-$GDB_VERSION.tar.bz2
tar xvjf insight-$INSIGHT_VERSION.tar.bz2
cd $GCC_DIR
ln -s ../$NEWLIB_DIR/newlib newlib
ln -s ../$NEWLIB_DIR/libgloss libgloss
cd ..
rm -fr build
mkdir -p build/binutils build/gcc build/gdb build/insight build/newlib
# Build binutils
cd build/binutils
../../$BINUTILS_DIR/configure --target=$TARGET --prefix=$DEST
--disable-nls
make LDFLAGS=-s all install
# Build GCC
cd ../gcc
PATH=$DEST/bin:$PATH
../../$GCC_DIR/configure --enable-languages=c,c++ --target=$TARGET
--prefix=$DEST --with-gnu-as --with-gnu-ld --disable-nls --with-newlib
--disable-__cxa_atexit --with-ecos
make LDFLAGS=-s all all-gcc all-target-libstdc++-v3 install install-gcc
install-target-libstdc++-v3
# Build GDB and Insight
cd ../gdb
# Without insight
../../$GDB_DIR/configure --target=$TARGET --prefix=$DEST
make -w all install
cd ../insight
# With insight
../../$INSIGHT_DIR/configure --target=$TARGET --prefix=$DEST
make -w all install
# Remove uncompressed sources
cd ../..
rm -fr $BINUTILS_DIR $GCC_DIR $NEWLIB_DIR $GDB_DIR $INSIGHT_DIR build
--
Summary: Wrong warning comparison of promoted ~unsigned with
unsigned
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fredrik dot hederstierna at securitas-direct dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-elf-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
[Bug c++/38342] New: __attribute__((__progmem__)) not propagated from typedef to data
The program source is trivial (yes, I've attached the .ii file as well):
#include avr/pgmspace.h
prog_uchar foo [10][10] = { 0 };
When compiled with g++ 4.3.0, this does not actually put the data in program
space.
BillW-MacOSX1063 /Downloads/arduino-0012/hardware/tools/avr/bin/avr-g++
pgmspace.c -mmcu=atmega168 -c -o pgmspace43c++.o --version
avr-g++ (GCC) 4.3.0
Copyright (C) 2008 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.
BillW-MacOSX1064 /Downloads/arduino-0012/hardware/tools/avr/bin/avr-g++
pgmspace.c -mmcu=atmega168 -c -o pgmspace43c++.o
BillW-MacOSX1065 /Downloads/arduino-0012/hardware/tools/avr/bin/avr-size
pgmspace43c++.o
textdata bss dec hex filename
0 0 100 100 64 pgmspace43c++.o
It works correctly with gcc 4.3.0 (from the same distribution), and it works
correctly with g++ 4.1
BillW-MacOSX1060 /Downloads/arduino-0012/hardware/tools/avr/bin/avr-gcc
pgmspace.c -mmcu=atmega168 -c -o pgmspace43cc.o --version
avr-gcc (GCC) 4.3.0
Copyright (C) 2008 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.
BillW-MacOSX1061 /Downloads/arduino-0012/hardware/tools/avr/bin/avr-gcc
pgmspace.c -mmcu=atmega168 -c -o pgmspace43cc.o
BillW-MacOSX1062 /Downloads/arduino-0012/hardware/tools/avr/bin/avr-size
pgmspace43cc.o
textdata bss dec hex filename
100 0 0 100 64 pgmspace43cc.o
BillW-MacOSX1063
--
Summary: __attribute__((__progmem__)) not propagated from typedef
to data
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: westfw at yahoo dot com
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c++/38342] __attribute__((__progmem__)) not propagated from typedef to data
--- Comment #1 from westfw at yahoo dot com 2008-12-01 09:16 --- Created an attachment (id=16797) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16797action=view) output from g++ -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c++/38342] __attribute__((__progmem__)) not propagated from typedef to data
--- Comment #2 from westfw at yahoo dot com 2008-12-01 09:18 --- Created an attachment (id=16798) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16798action=view) pgmspace.ii for the failing g++ compilation Actual compile command: /Downloads/arduino-0012/hardware/tools/avr/bin/avr-g++ pgmspace.c -mmcu=atmega168 -c -o pgmspace43c++.o -save-temps -v foo.out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c++/38342] __attribute__((__progmem__)) not propagated from typedef to data
--- Comment #3 from westfw at yahoo dot com 2008-12-01 09:20 --- Bug has been reproduced on at least two hosts. See also avrfreaks discussion: http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=515859#515859 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c/38337] Wrong is used uninitialized in this function warning
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-01 09:45 --- works for me -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Wrong is used uninitialized|Wrong is used uninitialized |in this function warning |in this function warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38337
[Bug middle-end/38338] [4.4 Regression] Compile abort when compiling code which used to work
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-01 09:47 --- This is a recent regression, r141893 works. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at redhat dot com Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Known to fail||4.4.0 Known to work||4.3.2 Last reconfirmed|-00-00 00:00:00 |2008-12-01 09:47:49 date|| Summary|Compile abort when compiling|[4.4 Regression] Compile |code which used to work |abort when compiling code ||which used to work Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug c++/38334] pmf accesses violate strict-aliasing rules
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-01 09:49 --- There's a pointer-adjustment in the original code (we just cprop a zero). If there was a suitable member forwprop should have re-constructed an access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38334
[Bug c/38343] New: ice for legal code with -O2
I just tried to compile the Suse Linux package MyODBC-unixODBC-3.51.26r1127-1.62 with the GNU C compiler version 4.4 snapshot 20081128. The compiler said gcc -DHAVE_CONFIG_H -I. -DNONTHREADSAFE -I/usr/include -O3 -DDBUG_OFF -I/usr/include/mysql -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -g -DPIC -fPIC -DUNDEF_HAVE_INITGROUPS -fno-strict-aliasing -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -MT libmyodbc3_la-error.lo -MD -MP -MF .deps/libmyodbc3_la-error.Tpo -c error.c -fPIC -DPIC -o .libs/libmyodbc3_la-error.o In file included from /usr/include/string.h:428, from /usr/include/mysql/m_string.h:30, from ../MYODBC_MYSQL.h:16, from myodbc3.h:37, from error.c:37: /usr/include/bits/string3.h: In function 'myodbc_sqlstate3_init': /usr/include/bits/string3.h:113: internal compiler error: in expand_expr_real_1, at expr.c:9295 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required. -- Summary: ice for legal code with -O2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38343
[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-01 10:01 --- /* Warn if two unsigned values are being compared in a size larger than their original size, and one (and only one) is the result of a `~' operator. This comparison will always fail. Also warn if one operand is a constant, and the constant does not have all bits set that are set in the ~ operand when it is extended. */ note that integer promotion is done on the operand(!) of ~. So u1 == (u8_t)(~u2) is equal to (int)u1 == (int)(u8_t)(~(int)u2) that we do not warn for the first case is because it is optimized to u1 == ~u2 before. Why do you think the warning is incorrect? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
[Bug c/38343] ice for legal code with -O2
--- Comment #1 from dcb314 at hotmail dot com 2008-12-01 10:01 --- Created an attachment (id=16799) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16799action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38343
[Bug middle-end/38274] why the option -fstack-protector-all doesn't works?
--- Comment #2 from zuogang at huawei dot com 2008-12-01 10:13 --- (In reply to comment #1) Works for me with the trunk on i386-darwin8.11: [236:~] apinski% ~/local-gcc/bin/gcc t.c -fstack-protector-all [236:~] apinski% ./a.out ?,a:-1,b2 *** stack smashing detected ***: terminated Illegal instruction what 's the version of the gcc src code you tried? can you try the gcc version 4.1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38274
[Bug other/38340] Error in pthread.h
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-01 10:34 --- Certainly nothing to do with the C++ runtime library. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38340
[Bug c++/38342] __attribute__((__progmem__)) not propagated from typedef to data
--- Comment #4 from j at uriah dot heep dot sax dot de 2008-12-01 10:37 --- Note that this is a GCC 4.3.x regression; GCC 4.2.x compiled the code the way expected. -- j at uriah dot heep dot sax dot de changed: What|Removed |Added CC||eric dot weddington at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
[Bug c/38343] ice for legal code with -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-01 10:42 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38343
[Bug middle-end/38343] [4.4 Regression] ice for legal code with -O2
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-01 10:50 ---
typedef struct myodbc3_err_str {
char sqlstate[6];
} MYODBC3_ERR_STR;
static MYODBC3_ERR_STR myodbc3_errors[] = { { 01000 } };
void myodbc_sqlstate2_init(void)
{
__builtin_stpcpy(myodbc3_errors[0].sqlstate, S0022);
}
for internal compiler error: in expand_expr_real_1, at expr.c:9295
typedef struct myodbc3_err_str {
char sqlstate[6];
} MYODBC3_ERR_STR;
static MYODBC3_ERR_STR myodbc3_errors[] = { { 01000 } };
char *myodbc_sqlstate2_init(void)
{
return __builtin_stpcpy(myodbc3_errors[0].sqlstate, S0022);
}
for internal compiler error: in build2_stat, at tree.c:3303
possibly related. r141893 was ok.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.4.0
Known to work||4.3.2
Last reconfirmed|-00-00 00:00:00 |2008-12-01 10:50:37
date||
Summary|ice for legal code with -O2 |[4.4 Regression] ice for
||legal code with -O2
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38343
[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.3.3 Known to work||4.3.2 Priority|P3 |P1 Summary|[4.3 regression] bootstrap |[4.3 Regression] bootstrap |failure in libjava/link.cc |failure in libjava/link.cc |(ICE in invariant_for_use) |(ICE in invariant_for_use) Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-01 11:06 --- Can you figure out which patch is the cause? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug target/38344] [4.3 Regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
--- Comment #3 from doko at ubuntu dot com 2008-12-01 11:08 --- doing this, but it will be slow ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug target/38326] [4.3 regression] libjava build failure on ia64-linux-gnu
--- Comment #2 from doko at ubuntu dot com 2008-12-01 11:16 --- afaics no ia64 specific changes besides the proposed patch for pr27880 to configure --with-system-libunwind. trunk fails as well, build log at https://launchpad.net/ubuntu/+source/gcc-snapshot/20081130-0ubuntu1/+build/800751 no relevant patches applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
[Bug target/38344] [4.3 regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
--- Comment #1 from doko at ubuntu dot com 2008-12-01 10:59 --- Created an attachment (id=16800) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16800action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug target/38344] New: [4.3 regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use)
seen with 4.3.3 20081029, seen the last successful bootstrap with 20081022, not seen on the trunk. /home/doko/gcc/4.3/java/gcj-4.3-4.3.2/build/gcc/cc1plus -quiet -nostdinc++ -v -g -O2 -Wswitch-enum -Wextra -Wall -version -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -fPIC link.ii Program received signal SIGSEGV, Segmentation fault. invariant_for_use (use=0x8fde18) at ../../src/gcc/loop-invariant.c:251 251 basic_block bb = BLOCK_FOR_INSN (use-insn), def_bb; (gdb) p use-insn $1 = (rtx) 0x0 -- Summary: [4.3 regression] bootstrap failure in libjava/link.cc (ICE in invariant_for_use) Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38344
[Bug c++/38345] New: redeclaration of name introduced in a condition
The example in 6.4p3 is not diagnosed by GCC:
if (int x = f()) {
int x; // ill-formed, redeclaration of x
}
else {
int x; // ill-formed, redeclaration of x
}
This compiles without warnings on every version of GCC I tried from 3.3 to 4.3
--
Summary: redeclaration of name introduced in a condition
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38345
[Bug rtl-optimization/33828] Issues with code hoisting implementation in gcse.c
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-01 12:24 ---
After fixing the issue mentioned in comment#2 and comment #8, gcse.c hoisting
hoists things too far up, e.g.:
{ pred ENTRY }
BB1
if (...) goto BB2 else goto BB3
{ succ BB2, BB3 }
{ pred BB1 }
BB2
...
goto BB4
{ succ BB4 }
{ pred BB2 }
BB3
...
goto BB4
{ succ BB4 }
{ pred BB2, BB3 }
BB4
if (...) goto BB5 else goto BB6
{ succ BB5, BB6 }
{ pred BB4 }
BB5
r1 - exp1
goto BB7
{ succ BB7 }
{ pred BB4 }
BB6
r2 - exp1
goto BB7
{ succ BB7 }
{ pred BB5, BB6 }
BB7
...
{ succ EXIT }
is transformed to:
{ pred ENTRY }
BB1
r3 - exp1
if (...) goto BB2 else goto BB3
{ succ BB2, BB3 }
{ pred BB1 }
BB2
...
goto BB4
{ succ BB4 }
{ pred BB2 }
BB3
...
goto BB4
{ succ BB4 }
{ pred BB2, BB3 }
BB4
if (...) goto BB5 else goto BB6
{ succ BB5, BB6 }
{ pred BB4 }
BB5
r1 - r3
goto BB7
{ succ BB7 }
{ pred BB4 }
BB6
r2 - r3
goto BB7
{ succ BB7 }
{ pred BB5, BB6 }
BB7
...
{ succ EXIT }
when it would be better to hoist up only to BB4:
{ pred ENTRY }
BB1
if (...) goto BB2 else goto BB3
{ succ BB2, BB3 }
{ pred BB1 }
BB2
...
goto BB4
{ succ BB4 }
{ pred BB2 }
BB3
...
goto BB4
{ succ BB4 }
{ pred BB2, BB3 }
BB4
r3 - exp1
if (...) goto BB5 else goto BB6
{ succ BB5, BB6 }
{ pred BB4 }
BB5
r1 - r3
goto BB7
{ succ BB7 }
{ pred BB4 }
BB6
r2 - r3
goto BB7
{ succ BB7 }
{ pred BB5, BB6 }
BB7
...
{ succ EXIT }
GCC should not hoist up further than up to the first common dominator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828
[Bug target/38254] [4.4 Regression] Revision 142160 causes PR27908 -O3
--- Comment #4 from uros at gcc dot gnu dot org 2008-12-01 12:29 --- Subject: Bug 38254 Author: uros Date: Mon Dec 1 12:28:05 2008 New Revision: 142310 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142310 Log: Backport from mainline: 2008-11-25 Uros Bizjak [EMAIL PROTECTED] PR target/38254 * config/i386/sync.md (memory_barrier_nosse): New insn pattern. (memory_barrier): Generate memory_barrier_nosse insn for !(TARGET_64BIT || TARGET_SSE2). * config/i386/sse.md (*sse2_mfence): Also enable for TARGET_64BIT. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/sse.md branches/gcc-4_3-branch/gcc/config/i386/sync.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38254
[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned
--- Comment #2 from fredrik dot hederstierna at securitas-direct dot com
2008-12-01 12:40 ---
Then why dont we get warning on the first if-statement?
Shouldnt these lines be equal?
if (c1 == (unsigned char)(~c2)) {
}
if (u1 == (u8_t)(~u2)) { // THIS WILL GIVE WARNING
}
The first if-statement does not give warnings, should this be evaluated the
same way?
if ((int)c1 == (int)(unsigned char)(~(int)c2)) {
My idea was that either of the if-statements are wrong. Either both or none
should give warnings, or am I wrong? The typedef to unsigned char should be
the same as using primitive types regarding this warning, or?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-01 12:49 --- As I said, for the first case we optimize away the promotions before the warning code comes along. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned
--- Comment #4 from fredrik dot hederstierna at securitas-direct dot com
2008-12-01 12:55 ---
Heres another example, then I do not think the warnings are due to
optimization.
I have same warnings with both -O0 and -O3.
#include stdio.h
typedef unsigned char u8_t;
void test_cast(unsigned char c1, unsigned char c2, u8_t u1, u8_t u2)
{
if (c1 == (unsigned char)(~c2)) {
printf(No warning);
}
if (c1 == ~c2) {
printf(This gives warning);
}
if (u1 == (u8_t)(~u2)) {
printf(This gives warning);
}
if ((unsigned char)u1 == (unsigned char)(~u2)) {
printf(This gives warning);
}
}
The original code that caused this warnings are the TCP/IP stack lwIP, then I
constructed this minimal example.
Original code from lwIP TCP/IP stack:
-
static u8_t ip_reassbitmap[IP_REASS_BUFSIZE / (8 * 8) + 1];
static const u8_t bitmap_bits[8] = { 0xff, 0x7f, 0x3f, 0x1f, 0x0f, 0x07, 0x03,
0x01 };
/.../
if (ip_reassbitmap[ip_reasslen / (8 * 8)] !=
(u8_t) ~ bitmap_bits[ip_reasslen / 8 7]) {
/.../
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
[Bug c/38346] New: NTPL pthread_create is thread safe ?
Dears, I'm currently develop a multi-threaded application using GCC pthread (NTPL). My application start a thread who start another sub-thread. During the creation of the subthread, i invoke the pthread_cancel on the first thread. This result sometime a Sigfault (see the diagram bellow). Main thread | pthread_create (thread 1) | pthread_create (finish) Thread 1 | | |pthread_create (thread 2) pthread_cancel (thread 1) | = Segfault ? | | | | V V I'll try to post some sample code today. Regards, Alexandre Martins -- Summary: NTPL pthread_create is thread safe ? Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: deadmaxfr at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38346
[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned
--- Comment #5 from fredrik dot hederstierna at securitas-direct dot com 2008-12-01 13:35 --- On Intel i386-GCC (4.2.3) we just get warning only for the line if (c1 == ~c2) The other lines does not give warnings, so maybe its just the ARM-backend that catch this warning. I guess you mean that for ARM target the optimization tree does things that silence the warning. Is it good that optimizations can silence possible warnings/errors? And that it differs depending on which backend I'm running? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
[Bug middle-end/38347] New: [4.4 Regression] gfortran.dg/alloc_comp_constructor_1.f90 ICE with -O2 -fdefault-integer-8
On powerpc-apple-darwin9 at revision 142300, compiling
gfortran.dg/alloc_comp_constructor_1.f90 with -O2 -fdefault-integer-8 gives and
ICE:
[karma] dominiq/test% gfc -O2 -fdefault-integer-8
/opt/gcc/gcc-4.4-work/gcc/testsuite/gfortran.dg/alloc_comp_constructor_1.f90
/opt/gcc/gcc-4.4-work/gcc/testsuite/gfortran.dg/alloc_comp_constructor_1.f90:
In function 'test_constructor':
/opt/gcc/gcc-4.4-work/gcc/testsuite/gfortran.dg/alloc_comp_constructor_1.f90:9:
internal compiler error: in operand_subword, at emit-rtl.c:1364
I don't see this ICE on i686-apple-darwin9. Note that
alloc_comp_constructor_1.f90 gives other failures related to pr38324.
The backtrace before the ICE gives:
#0 operand_subword (op=0x40f09410, offset=0, validate_address=1,
mode=VOIDmode) at ../../gcc-4.4-work/gcc/emit-rtl.c:1361
#1 0x002b8118 in operand_subword_force (op=0x40f09410, offset=0,
mode=VOIDmode) at ../../gcc-4.4-work/gcc/emit-rtl.c:1407
#2 0x0027849c in do_jump_by_parts_zero_rtx (mode=value temporarily
unavailable, due to optimizations, op0=0x40f09410, if_false_label=0x41d6df30,
if_true_label=0x0) at ../../gcc-4.4-work/gcc/dojump.c:678
#3 0x0027aba0 in do_jump (exp=0x40f09410, if_false_label=0x0,
if_true_label=0x41d6df30) at ../../gcc-4.4-work/gcc/dojump.c:307
#4 0x00208ce0 in expand_gimple_basic_block (bb=0x41c00040) at
../../gcc-4.4-work/gcc/cfgexpand.c:1665
#5 0x00209534 in gimple_expand_cfg () at
../../gcc-4.4-work/gcc/cfgexpand.c:2377
#6 0x0044cc18 in execute_one_pass (pass=0x904ea0) at
../../gcc-4.4-work/gcc/passes.c:1279
#7 0x0044ceb8 in execute_pass_list (pass=0x41cc3e80) at
../../gcc-4.4-work/gcc/passes.c:1328
#8 0x00587394 in tree_rest_of_compilation (fndecl=0x40f56600) at
../../gcc-4.4-work/gcc/tree-optimize.c:418
#9 0x007257c4 in cgraph_expand_function (node=0x40f07900) at
../../gcc-4.4-work/gcc/cgraphunit.c:1047
#10 0x00727cac in cgraph_expand_all_functions [inlined] () at
../../gcc-4.4-work/gcc/cgraphunit.c:1106
#11 cgraph_optimize () at ../../gcc-4.4-work/gcc/cgraphunit.c:1311
#12 0x000976a0 in gfc_be_parse_file (set_yydebug=value temporarily
unavailable, due to optimizations) at
../../gcc-4.4-work/gcc/fortran/f95-lang.c:240
#13 0x0051d3d8 in compile_file [inlined] () at
../../gcc-4.4-work/gcc/toplev.c:968
#14 toplev_main (argc=value temporarily unavailable, due to optimizations,
argv=value temporarily unavailable, due to optimizations) at
../../gcc-4.4-work/gcc/toplev.c:2191
#15 0x1908 in start ()
(gdb) p *op
$1 = {
code = CONST_INT,
mode = VOIDmode,
jump = 0,
call = 0,
unchanging = 0,
volatil = 0,
in_struct = 0,
used = 0,
frame_related = 0,
return_val = 0,
u = {
fld = {{
rt_int = 0,
rt_uint = 0,
rt_str = 0x0,
rt_rtx = 0x0,
rt_rtvec = 0x0,
rt_type = VOIDmode,
rt_addr_diff_vec_flags = {
min_align = 0,
base_after_vec = 0,
min_after_vec = 0,
max_after_vec = 0,
min_after_base = 0,
max_after_base = 0,
offset_unsigned = 0,
scale = 0
},
rt_cselib = 0x0,
rt_bit = 0x0,
rt_tree = 0x0,
rt_bb = 0x0,
rt_mem = 0x0,
rt_reg = 0x0,
rt_constant = 0x0
}},
hwint = {1},
block_sym = {
fld = {{
rt_int = 0,
rt_uint = 0,
rt_str = 0x0,
rt_rtx = 0x0,
rt_rtvec = 0x0,
rt_type = VOIDmode,
rt_addr_diff_vec_flags = {
min_align = 0,
base_after_vec = 0,
min_after_vec = 0,
max_after_vec = 0,
min_after_base = 0,
max_after_base = 0,
offset_unsigned = 0,
scale = 0
},
rt_cselib = 0x0,
rt_bit = 0x0,
rt_tree = 0x0,
rt_bb = 0x0,
rt_mem = 0x0,
rt_reg = 0x0,
rt_constant = 0x0
}, {
rt_int = 1,
rt_uint = 1,
rt_str = 0x1 Address 0x1 out of bounds,
rt_rtx = 0x1,
rt_rtvec = 0x1,
rt_type = BLKmode,
rt_addr_diff_vec_flags = {
min_align = 0,
base_after_vec = 0,
min_after_vec = 0,
max_after_vec = 0,
min_after_base = 0,
max_after_base = 0,
offset_unsigned = 0,
scale = 0
},
rt_cselib = 0x1,
rt_bit = 0x1,
rt_tree = 0x1,
rt_bb = 0x1,
rt_mem = 0x1,
rt_reg = 0x1,
rt_constant = 0x1
}, {
rt_int = -1347440721,
rt_uint = 2947526575,
rt_str = 0xafafafaf Address 0xafafafaf out of bounds,
rt_rtx = 0xafafafaf,
rt_rtvec = 0xafafafaf,
rt_type = 2947526575,
rt_addr_diff_vec_flags = {
min_align = 175,
base_after_vec = 1,
min_after_vec = 0,
[Bug middle-end/37908] atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand
--- Comment #16 from uros at gcc dot gnu dot org 2008-12-01 13:50 --- Subject: Bug 37908 Author: uros Date: Mon Dec 1 13:48:52 2008 New Revision: 142313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142313 Log: PR middle-end/37908 * config/alpha/alpha.c (alpha_split_atomic_op): Properly handle NAND case by calculating ~(new_reg val) instead of (~new_reg val). * config/alpha/sync.md (sync_nandmode): Change insn RTX to (not:I48MODE (and:I48MODE (...))). (sync_old_nandmode): Ditto. (sync_new_nandmode): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.c trunk/gcc/config/alpha/sync.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37908
[Bug fortran/38324] Wrong lbound given to allocatable components
--- Comment #1 from dominiq at lps dot ens dot fr 2008-12-01 13:54 --- AFAICT this pr is the cause of half of the failures of gfortran.dg/alloc_comp_constructor_1.f90 on i686-apple-darwin9 with -fdefault-integer-8: FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 scan-tree-dump-times original builtin_free 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O1 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O1 scan-tree-dump-times original builtin_free 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O2 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O2 scan-tree-dump-times original builtin_free 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer scan-tree-dump-times original builtin_free 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original builtin_free 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions scan-tree-dump-times original builtin_free 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -g execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -g scan-tree-dump-times original builtin_free 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -Os execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -Os scan-tree-dump-times original builtin_free 21 The second half is due to 24 builtin_free in the original dump. This is the cause of some failures of this test on powerpc-apple-darwin9 (-O0/1, I have filled pr38347 against the middle-end for the ICE got with higher optimizations). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38324
[Bug c++/38348] New: ICE from c_finish_omp_for
int a[10];
template int N
void foo ()
{
#pragma omp for
for (int *p = a; p a + 10; p++)
;
}
ICEs with -fopenmp, fold_convert is called with NULL second argument fro
c_finish_omp_for.
--
Summary: ICE from c_finish_omp_for
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38348
[Bug c++/38348] ICE from c_finish_omp_for
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-01 14:22:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38348
[Bug c++/38348] [4.4 Regression] ICE from c_finish_omp_for
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE from c_finish_omp_for |[4.4 Regression] ICE from ||c_finish_omp_for Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38348
[Bug preprocessor/38322] ICE in gcc.dg/cpp/trad/include.c -fno-show-column at -m32 and -m64
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-12-01 14:23 --- I don't see any c++ comments in the included system headers. Is there a way in gcc to dump the preprocessed source in a manner that won't parse out the comments? When I dropped the '-fno-show-column -traditional-cpp' flags, the abort was eliminated but the resulting include.i is missing the comments. A manual search of the system headers didn't show any but it would be nice to be able to verify through gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38322
[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-01 14:36 --- Subject: Bug 38245 Author: jakub Date: Mon Dec 1 14:34:51 2008 New Revision: 142317 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142317 Log: PR rtl-optimization/38245 * tree-vrp.c (abs_extent_range): New function. (extract_range_from_binary_expr): Compute range for *_DIV_EXPR even if vr1 is VR_VARYING, VR_ANTI_RANGE or includes zero or if vr1 is VR_RANGE and op0 has some other range. * gcc.dg/pr38245-1.c: New test. * gcc.dg/pr38245-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr38245-1.c trunk/gcc/testsuite/gcc.dg/pr38245-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug ada/37440] [4.4 Regression] GNAT Bug Box a-ngcefu.adb:397
--- Comment #1 from joel at gcc dot gnu dot org 2008-12-01 14:39 --- Still broken: +===GNAT BUG DETECTED==+ | 4.4.0 20081126 (experimental) [trunk revision 142228] (arm-unknown-rtems4.10) GCC error:| | in find_valid_class, at reload.c:700 | | Error detected around a-ngcefu.adb:397 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ -- joel at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
[Bug c/38346] NTPL pthread_create is thread safe ?
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-01 14:44 --- This is not related to GCC. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38346
[Bug boehm-gc/38349] New: Error Building Ada (h8300)
4.4.0 20081126 (experimental) [trunk revision 142228] /n/12/joel/test-gcc/b-gcc2-h8300/./gcc/xgcc -B/n/12/joel/test-gcc/b-gcc2-h8300/./gcc/ -nostdinc -B/n/12/joel/test-gcc/b-gcc2-h8300/h8300-rtems4.10/newlib/ -isystem /n/12/joel/test-gcc/b-gcc2-h8300/h8300-rtems4.10/newlib/targ-include -isystem /n/12/joel/test-gcc/gcc-svn/newlib/libc/include -B/n/12/joel/test-gcc/install/h8300-rtems4.10/bin/ -B/n/12/joel/test-gcc/install/h8300-rtems4.10/lib/ -isystem /n/12/joel/test-gcc/install/h8300-rtems4.10/include -isystem /n/12/joel/test-gcc/install/h8300-rtems4.10/sys-include -c -g -O2 -W -Wall -gnatpg a-calari.adb -o a-calari.o checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... s-parame.ads:96:51: value not in range of type System.Parameters.Size_Type s-parame.ads:96:51: static expression fails Constraint_Check Line 96 is this: Default_Env_Stack_Size : constant Size_Type := 8_192_000; -- Assumed size of the environment task, if no other information -- is available. This value is used when stack checking is -- enabled and no GNAT_STACK_LIMIT environment variable is set. I think this is because the H8 only has a limited address range and 8MB is too large for its default environment stack size. I am recalling that 64K is the limit for offsets and that the larger parts in the family only have 24 address bits for 16MB. -- Summary: Error Building Ada (h8300) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: h8300-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38349
[Bug c++/38348] [4.4 Regression] ICE from c_finish_omp_for
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-01 15:11 --- Subject: Bug 38348 Author: jakub Date: Mon Dec 1 15:10:25 2008 New Revision: 142318 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142318 Log: PR c++/38348 * c-omp.c (c_finish_omp_for): Only transform pointer ++ or -- into MODIFY_EXPR if second argument is non-NULL. * g++.dg/gomp/for-19.C: New test. * testsuite/libgomp.c++/for-6.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/for-19.C trunk/libgomp/testsuite/libgomp.c++/for-6.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-omp.c trunk/gcc/testsuite/ChangeLog trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38348
[Bug c++/38348] [4.4 Regression] ICE from c_finish_omp_for
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-01 15:14 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38348
[Bug ada/38349] Error Building Ada (h8300)
--- Comment #1 from joel at gcc dot gnu dot org 2008-12-01 15:15 --- Ada not boehm-gc. Selected wrong box. -- joel at gcc dot gnu dot org changed: What|Removed |Added Component|boehm-gc|ada http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38349
[Bug target/38350] New: odd extra unused stack space/register allocated with asm
For the attached code, there's no reason why the generated code at -O2 would need an unused stack-slot (a second with -march=v10, a first with -march=v32) when operand 5 (the last) of the asm is g than if it's X. Using X seems a little awkward life-time-wise because the input is supposed to be valid. I don't see this oddness on the host with native 4.1.2 on the host, with/without -m32. -- Summary: odd extra unused stack space/register allocated with asm Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: hp at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38350
[Bug target/38350] odd extra unused stack space/register allocated with asm
--- Comment #1 from hp at gcc dot gnu dot org 2008-12-01 15:20 --- Created an attachment (id=16801) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16801action=view) testcase Change the last constraint from g to X and compile with 4.3-branch r142284 with -O2 -march=v32 and -O2 -march=v10 to expose the oddness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38350
[Bug target/38350] odd extra unused stack space/register allocated with asm
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-01 15:20:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38350
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #32 from uros at gcc dot gnu dot org 2008-12-01 15:21 --- Subject: Bug 33642 Author: uros Date: Mon Dec 1 15:19:40 2008 New Revision: 142319 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142319 Log: PR rtl-optimization/33642 * gcc.c-torture/compile/pr11832.c: Extend XFAIL to alpha*-*-*. * gcc.c-torture/compile/pr33009.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug c++/38257] [4.4 regression] ICE with auto and #pragma omp parallel
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-01 15:28 --- Subject: Bug 38257 Author: jakub Date: Mon Dec 1 15:27:12 2008 New Revision: 142320 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142320 Log: PR c++/38257 * parser.c (cp_parser_omp_for_loop): Handle auto. * pt.c (tsubst_omp_for_iterator): Likewise. * testsuite/libgomp.c++/for-7.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/for-7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38257
[Bug c++/38257] [4.4 regression] ICE with auto and #pragma omp parallel
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-01 15:30 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38257
[Bug middle-end/38338] [4.4 Regression] Compile abort when compiling code which used to work
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-01 15:35 --- It is caused by either revision 142115 or 142116. Revision 142116: http://gcc.gnu.org/ml/gcc-cvs/2008-11/msg00617.html is my first guess. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug middle-end/38338] [4.4 Regression] Compile abort when compiling code which used to work
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-01 15:37 ---
-fno-ira also failed:
[EMAIL PROTECTED] rrs]$ ./142116/usr/bin/gcc -fPIC -m32 -S y.c -fno-ira
y.c: In function âapply_charâ:
y.c:11: error: unable to find a register to spill in class âQ_REGSâ
y.c:11: error: this is the insn:
(insn 3 2 7 2 y.c:8 (set (mem/c/i:QI (plus:SI (reg/f:SI 20 frame)
(const_int -20 [0xffec])) [0 data+0 S1 A8])
(subreg:QI (reg:SI 4 si [63]) 0)) 62 {*movqi_1} (expr_list:REG_DEAD
(reg:SI 4 si [63])
(nil)))
y.c:11: internal compiler error: in spill_failure, at reload1.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[EMAIL PROTECTED] rrs]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug middle-end/38338] [4.4 Regression] Compile abort when compiling code which used to work
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-01 15:45 --- Yes, the problem is that eax, edx and ecx are live there (might be arguments) and ebx is reserved for PIC pointer, so at that spot is no QImode register available. I guess either my builtins.c change could be conditionalized on if it is really needed, or on i386 it would need to avoid a QImode store and use SImode instead. Looking into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #8 from swagiaal at redhat dot com 2008-12-01 16:12 --- DW_AT_MIPS_linkage_name should be removed from GCC only after the DW_AT_name scoping/qualification will get fully fixed. GDB currently already contains the DW_AT_MIPS_linkage_name reader and there is probably no need to disable it (except for testing purposes). Agreed. My patch fixes test cases where DW_AT_MIPS_linkage_name was not generated by gcc, but the patch should be smarter about falling back on DW_AT_MIPS_linkage_name when the correct canonical name cannot be constructed. On GDB CVS HEAD for gdb.cp/m-static.exp a command `print gnu_obj_4::elsewhere' works for me as it can find (presumably) the corrent .symtab mangled symbol. Sure it would be good to get DW_AT_name fixed in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug fortran/38351] New: poor error message
MODULE M1 TYPE T1 INTEGER :: I END TYPE T1 INTERFACE OPERATOR(+) MODULE PROCEDURE add END INTERFACE CONTAINS TYPE(T1) FUNCTION add(a,b) TYPE(T1), INTENT(IN) :: a,b END FUNCTION END MODULE M1 USE M1 TYPE(T1), DIMENSION(2,2) :: a,b a=a+b END gfortran test.f90 test.f90:15.2: a=a+b 1 Error: Operands of binary numeric operator '+' at (1) are TYPE(t1)/TYPE(t1) the operator '+' is of course defined for TYPE(t1)/TYPE(t1). The issue here is rank (or elemental) -- Summary: poor error message Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38351
[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation
--- Comment #16 from jason at gcc dot gnu dot org 2008-12-01 16:29 --- (In reply to comment #8) Which I guess is invalid because the definition of Cdeque is not complete at the time we bind iterator::pointer to CdequeT::pointer. This is not an issue because CdequeT::pointer is a member of the current instantiation (per 14.6.2.1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
[Bug c/38352] New: cos() returns incorrect value in FE_UPWARD rounding mode
The attached test case produces the erroneous value of -20763584.029346 for cos(2 * Pi / 4) when the rounding mode is set to FE_UPWARD, instead of the correct value (close to) 0. Other rounding modes do not show this error, compiling with optimization enabled (-O1, -O2 or -O3) or as a 32 bit binary with -m32 also do not show the error. If the binary is linked statically with -static, the bug disappears as well. Compile with gcc -O0 -o cos_bug cos_bug.c -lm Compilers used (both show the bug) are gcc (GCC) 4.3.2 and gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) Processor is Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz. Math library is from Redhat Fedora 9, glibc-2.8-8.x86_64 package. -- Summary: cos() returns incorrect value in FE_UPWARD rounding mode Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kruppaal at loria dot fr GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38352
[Bug fortran/38291] Rejects I/O with POS= if FMT=*
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-12-01 16:32 --- So the read statement by itself is invalid. ??? I was testing with and without the open statement in the test case and saw that we were not catching that error either. Regardless, the problem is that I was using dt-rec instead of dt-pos and our runtime just defaulted to using the dt-rec for stream I/O. This fix is that we have to use dt-pos in the matchers and actually test conditions for pos= instead of rec= . I will post the patch tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
[Bug c/38352] cos() returns incorrect value in FE_UPWARD rounding mode
--- Comment #1 from kruppaal at loria dot fr 2008-12-01 16:33 --- Created an attachment (id=16802) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16802action=view) Test case for incorrect value of cos() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38352
[Bug c/38352] cos() returns incorrect value in FE_UPWARD rounding mode
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-01 16:36 --- Not a GCC issue. And invalid anyway, C99 math always rounds to even. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38352
[Bug fortran/38291] Rejects I/O with POS= if FMT=*
--- Comment #5 from burnus at gcc dot gnu dot org 2008-12-01 16:40 --- (In reply to comment #4) So the read statement by itself is invalid. ??? I was testing with and without the open statement in the test case and saw that we were not catching that error either. Ah, you are also talking about the run-time check in the library and not only about the compile-time check in f951. I will post the patch tonight. Thanks a ton! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
[Bug fortran/38351] poor error message
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-01 16:48 --- The best message other compilers had are: a) NAG f95: Error: fgjf.f90, line 15: No specific match for reference to operator + Error: fgjf.f90, line 15: Incompatible data types for the + operator b) openf95: openf95-380 openf95: ERROR MAIN__, File = fgjf.f90, Line = 15, Column = 4 No specific match to the defined generic operation + can be found. All others, including ifort and Lahey have less useful messages such as (Lahey): 2104-S: SOURCE.F90, line 15, column 4: Combination of operand types invalid. Admittedly, the message of gfortran - while essentially the same - is less helpful has the mentioning of the TYPEs is misleading. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38351
[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4
--- Comment #9 from hjl at gcc dot gnu dot org 2008-12-01 17:04 --- Subject: Bug 37514 Author: hjl Date: Mon Dec 1 17:03:13 2008 New Revision: 142324 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142324 Log: 2008-12-01 Vladimir Makarov [EMAIL PROTECTED] PR rtl-optimization/37514 * reload1.c (reload_as_needed): Invalidate reg_last_reload from previous insns. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37514
[Bug fortran/38353] New: Define statments in an include file are not preprocessed.
Define statments in an include file are not preprocessed before a main file is compile. E.g. main.F include header.h a=1.0 if (debug) print *,a header.h #define debug .TRUE. -- Summary: Define statments in an include file are not preprocessed. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yonhan dot chong at rolls-royce dot com GCC build triplet: i586-pc-mingw32 GCC host triplet: win32 GCC target triplet: i586-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38353
[Bug middle-end/38343] [4.4 Regression] ice for legal code with -O2
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-01 17:35 --- The bug is in expand_builtin_stpcpy, where it doesn't handle COMPOUND_EXPRs resulting from build_call_expr as other routines do. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-01 10:50:37 |2008-12-01 17:35:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38343
[Bug c/38337] Wrong is used uninitialized in this function warning
--- Comment #2 from yakov at emc dot com 2008-12-01 18:16 ---
Subject: Re: Wrong is used uninitialized in this function
warning
Richard,
it work for me too if T_SRS_ID would be modified
typedef struct S_SPS_ID
{
unsigned char dir;
unsigned char loop;
unsigned char dae_idx;
unsigned char lcc;
unsigned char rack_side;
unsigned char rack_indx;
unsigned char in_rack_loc;
unsigned char pad;
} T_SPS_ID;
like this:
typedef struct S_SPS_ID
{
unsigned char dir;
unsigned char loop;
unsigned char dae_idx;
unsigned char lcc;
unsigned char rack_side;
unsigned char rack_indx;
unsigned long pad;
} T_SPS_ID;
Also it would works with this modification:
typedef struct S_SPS_ID
{
unsigned short dir;
unsigned short lcc;
unsigned short rack_side;
unsigned short pad;
} T_SPS_ID;
thanks,
yakov
rguenth at gcc dot gnu dot org wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-01 09:45
---
works for me
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38337
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #30 from ubizjak at gmail dot com 2008-12-01 18:26 --- (In reply to comment #29) Other compilers do this kind of transformation via reverse copy propagation. GCC could perhaps add something like that too, when it transforms a 3-address insn to a 2-address insn. Will this also solve PR 19398, where we have: fstps -4(%ebp) (*) movss -4(%ebp), %xmm0 (*) cvttss2si %xmm0, %eax leave Note, that we could simply have: cvttss2si -4(%ebp), %eax -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug libstdc++/38244] [4.4 Regression] bitset initialization from 0 rejected.
--- Comment #8 from cgd at google dot com 2008-12-01 18:30 --- (re: my last comment on 11/24: I see you added the test case in the original commit! Sorry, didn't notice that! Thanks much for resolving the issue.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug middle-end/38338] [4.4 Regression] __builtin_apply causes an ICE on x86
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-01 18:56 --- /me wishes __builtin_apply would just go away. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu |i?86-*-* Summary|[4.4 Regression] Compile|[4.4 Regression] |abort when compiling code |__builtin_apply causes an |which used to work |ICE on x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug c++/38345] redeclaration of name introduced in a condition
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-01 19:02 --- I think this is a dup of bug 18770. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38345
[Bug fortran/38252] [4.4 Regression] Empty function with CONTAINS triggers Internal Error
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-01 19:32 --- Subject: Bug 38252 Author: mikael Date: Mon Dec 1 19:30:55 2008 New Revision: 142327 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142327 Log: 2008-12-01 Mikael Morin [EMAIL PROTECTED] PR fortran/38252 * parse.c (parse_spec): Skip statement order check in case of a CONTAINS statement. 2008-12-01 Mikael Morin [EMAIL PROTECTED] PR fortran/38252 * gfortran.dg/empty_function_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/empty_function_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4
--- Comment #10 from vmakarov at gcc dot gnu dot org 2008-12-01 19:33 --- Subject: Bug 37514 Author: vmakarov Date: Mon Dec 1 19:31:41 2008 New Revision: 142328 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142328 Log: 2008-12-01 Vladimir Makarov [EMAIL PROTECTED] PR rtl-optimization/37514 * reload1.c (reload_as_needed): Invalidate reg_last_reload from previous insns. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37514
[Bug fortran/38353] Define statments in an include file are not preprocessed.
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-12-01 19:42 --- http://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-and-conditional-compilation.html If a preprocessed file includes another file with the Fortran INCLUDE statement, the included file is not preprocessed. To preprocess included files, use the equivalent preprocessor statement #include. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38353
[Bug fortran/38252] [4.4 Regression] Empty function with CONTAINS triggers Internal Error
--- Comment #7 from mikael at gcc dot gnu dot org 2008-12-01 19:52 --- I hope one day I'll be able to commit properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
[Bug fortran/38252] [4.4 Regression] Empty function with CONTAINS triggers Internal Error
--- Comment #8 from mikael at gcc dot gnu dot org 2008-12-01 19:53 --- Subject: Bug 38252 Author: mikael Date: Mon Dec 1 19:52:15 2008 New Revision: 142331 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142331 Log: 2008-12-01 Mikael Morin [EMAIL PROTECTED] PR fortran/38252 * gfortran.dg/empty_function_1.f90: Fix latest commit. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/empty_function_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
[Bug middle-end/38347] [4.4 Regression] gfortran.dg/alloc_comp_constructor_1.f90 ICE with -O2 -fdefault-integer-8
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-01 20:23 --- This works on PPC64-linux with revision 141772. GNU Fortran (GCC) version 4.4.0 2008 (experimental) [trunk revision 141772] (powerpc64-unknown-linux-gnu) I don't have anything newer right now though, I will try to get a newer revision later today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38347
[Bug middle-end/38338] [4.4 Regression] __builtin_apply causes an ICE on x86
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||12/msg00041.html Status|NEW |ASSIGNED Last reconfirmed|2008-12-01 09:47:49 |2008-12-01 20:35:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38338
[Bug c/38354] New: Spurious error: initializer element is not computable at load time
The following code is from gcc docs and works as expected:
#include stdio.h
int
main (int argc, char **argv)
{
static const int array[] = { foo-foo, bar-foo, hack-foo };
int i = argc - 1;
goto *(array[i]+foo);
foo:
printf (foo\n);
return 0;
bar:
printf (bar\n);
return 0;
hack:
printf (hack\n);
return 0;
}
However, if I change the array type from:
static const int array[] = { foo-foo, bar-foo, hack-foo };
to:
static const void *array[] = { foo-foo, bar-foo, hack-foo };
I get the error:
label-value.c:6: error: initializer element is not computable at load time
This doesn't make any sense to me.
--
Summary: Spurious error: initializer element is not computable at
load time
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at behdad dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354
[Bug tree-optimization/23286] missed fully redundant expression
--- Comment #24 from steven at gcc dot gnu dot org 2008-12-01 22:00 --- Created an attachment (id=16803) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16803action=view) patch to implement code hoisting in tree-ssa-pre.c This passes bootstrap+testing on ia64-linux and amd64-linux. It causes a few vectorizer failures (4 on ia64) that I have not analyzed yet. -- steven at gcc dot gnu dot org changed: What|Removed |Added Attachment #16784|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23286
[Bug middle-end/38204] PRE for post dominating expressions
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-01 22:12 --- davidxl, my latest patch to bug 23286 (tree-hoist_v3.diff) makes PRE in tree-ssa-pre.c code-size aware. I have tested this with CSiBE on mips-unknown-elf. Without the patch, code size at -Os with PRE enabled is ~17% larger than -Os without PRE. With the patch, the code size increase with -Os and PRE enabled is 0.2%. With the patch and with tree hoisting enabled at -Os, code size is reduced by just a little less than 1%. With the patch and with tree hoisting enabled at -Os but RTL code hoisting disabled (i.e. the pass in gcse.c), code size is reduced by just a little less than 0.6%. (The RTL pass will be necessary mostly to hoist copies from out-of-ssa, and frame/stack pointer adjustments.) davidxl, if you have some time or someone else with time to play with this further, that'd be much appreciated. I've done my part, but having done the trick, the fun is gone and I have no intention to persue code-size aware PRE further ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38204
[Bug tree-optimization/38355] New: ICE with -fipa-struct-reorg / -fipa-pta
[forwarded from http://bugs.debian.org/PR498708] seen with 4.3 branch and trunk 20081130, building without -fipa-struct-reorg works. $ g++ -O3 -fwhole-program -fipa-struct-reorg xx.cc xx.cc:289: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. $ g++ -O3 -fwhole-program -fipa-pta xx.cc /usr/include/c++/4.3/bits/vector.tcc: In member function 'void std::vector_Tp, _Alloc::_M_insert_aux(__gnu_cxx::__normal_iteratortypename std::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp, _Alloc , const _Tp) [with _Tp = int, _Alloc = std::allocatorint]': /usr/include/c++/4.3/bits/vector.tcc:283: internal compiler error: in initialize_flags_in_bb, at tree-into-ssa.c:437 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. -- Summary: ICE with -fipa-struct-reorg / -fipa-pta Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38355
[Bug tree-optimization/38355] ICE with -fipa-struct-reorg / -fipa-pta
--- Comment #1 from debian-gcc at lists dot debian dot org 2008-12-01 22:50 --- Created an attachment (id=16804) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16804action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38355
[Bug tree-optimization/38355] ICE with -fipa-struct-reorg / -fipa-pta
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-01 22:54 --- -fipa-pta does nothing ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38355
[Bug tree-optimization/38355] ICE with -fipa-struct-reorg / -fipa-pta
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-01 22:55 --- *** This bug has been marked as a duplicate of 32305 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38355
[Bug c++/32305] ICE in initialize_flags_in_bb with -O -fipa-pta
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-12-01 22:55 --- *** Bug 38355 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug c++/32305] ICE in initialize_flags_in_bb with -O -fipa-pta
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-01 23:04 --- With so many dups, IMHO this ought to be fixed for the releases... -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-06-12 15:08:11 |2008-12-01 23:04:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug c++/38232] [4.4 Regression] value-initialization of reference warning too strict
--- Comment #4 from cgd at google dot com 2008-12-01 23:28 --- Decided to try to verify again with current head of trunk compiler (since several other bugs I reported have been fixed, and one was related to value initialization). gcc version 4.4.0 20081201 (experimental) (GCC) configured/built same way as before. This error still occurs. (FYI.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38232
[Bug c/38354] Spurious error: initializer element is not computable at load time
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-01 23:33 --- What's the rationale for using a pointer type for something that is integral (difference of 2 pointers)? I don't see why we should support that as a valid constant initializer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354
[Bug c/38354] Spurious error: initializer element is not computable at load time
--- Comment #2 from gnu at behdad dot org 2008-12-01 23:38 --- It's not a useful use case, agreed, but I don't see how that affects the computability of a value at load time, whatever that means. It did trick me: I was converting a vtable to use label values, and before converting the function pointer type of the array to int, I tried a compile and got the error. I didn't expect the error to go away if I replace the function pointer type with an int. To my surprise, it did. What I'm saying is that the statement in the error message is false. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354
[Bug tree-optimization/38356] New: ICE with -ftree-parallelize-loops
[forwarded from http://bugs.debian.org/487776] seen with 4.3 branch 20081129, fixed on the trunk, omitting -ftree-parallelize-loops=2 lets the compile succeed. Matthias g++ -g -O3 -ffast-math -fomit-frame-pointer -ftree-parallelize-loops=2 -c -o dcraw.o dcraw.ii g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. -- Summary: ICE with -ftree-parallelize-loops Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38356
[Bug tree-optimization/38356] ICE with -ftree-parallelize-loops
--- Comment #1 from debian-gcc at lists dot debian dot org 2008-12-01 23:42 --- Created an attachment (id=16805) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16805action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38356
[Bug c++/38357] New: [4.2/4.3/4.4 regression] ICE cc1plus (Segmentation fault)
4.1 branch gives an error, message, 4.2 and up segfault.
Matthias
$ g++-4.1 -save-temps bug.cc
bug.cc:17: error: could not convert template argument 'BUG::name' to 'bool'
$ g++ -save-temps bug.cc
bug.cc:17: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
class BUG
{
public:
bool name() { return true; }
};
template bool T
struct BUG1_5
{
};
template bool name
class BUG2 : BUG
{
public:
typedef BUG1_5name ptr;
};
int main()
{
BUG2false b;
return 0;
}
--
Summary: [4.2/4.3/4.4 regression] ICE cc1plus (Segmentation
fault)
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38357
[Bug c++/38253] g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on powerpc-apple-darwin9
--- Comment #4 from janis at gcc dot gnu dot org 2008-12-02 00:00 --- This test also fails on powerpc64-unknown-linux-gnu for both -m32 and -m64. It passed on 2008-08-24 (r138089) and failed on 2008-08-25 (r138121). Let me know if you'd like me to run a regression hunt and/or provide dump files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38253
[Bug c/38358] New: Could not compile gcc using large include files
I am trying to compile a typical c file with include option turned on. The include option includes .h file as part of the array element declaration for the c file. When I did compile:- gcc c.c -include myfile.h -D STS In file included from /usr/include/sys/cdefs.h:0, from /usr/include/features.h:33, from /usr/include/stdio.h:9, from c.c:19: /usr/include/bits/wordsize.h:1: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. I have checked the c.c:19 and they are commentation without any code before and after that line. My exact code only starts at line 40. I included the same .h file but with smaller size of .h file. It works perfectly and compilable.This file size is around 1-2MB. But the previous .h file which gives the above error has 1GB of file size. Is this a bug or do i need to specify any extra options to handle this special case? Please advise. Thanks. -- Summary: Could not compile gcc using large include files Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ahjiefreak at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38358
[Bug middle-end/38358] Could not compile gcc using large include files
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-02 00:03 --- Did you see: See URL:http://bugzilla.redhat.com/bugzilla for instructions. ?? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38358
[Bug middle-end/38219] gcc.dg/tree-ssa/vrp47.c fails on powerpc-apple-darwin9
--- Comment #3 from janis at gcc dot gnu dot org 2008-12-02 00:05 --- This test also fails on powerpc64-unknown-linux-gnu for both -m32 and -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38219
[Bug tree-optimization/38359] New: [4.3/4.4 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:466
[forwarded from http://bugs.debian.org/PR492505]
works with 4.2 branch, fails with 4.3 branch and trunk, succeeds with -O0
$ gcc-4.3 000.c -c -O1
000.c: In function '_ov_64_seek_lap':
000.c:33: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487
Please submit a full bug report,
with preprocessed source if appropriate.
void _ov_64_seek_lap (void)
{
unsigned x1, x2, x3;
unsigned ltmp_3978_7;
unsigned ltmp_3978_7__PHI_TEMPORARY;
unsigned ltmp_4011_7__PHI_TEMPORARY;
unsigned ltmp_4012_7;
signed ltmp_4011_7;
if (x1)
{
if (x2)
{
goto llvm_cbe__ov_initset_2e_exit;
}
}
while (1)
;
llvm_cbe__ov_initset_2e_exit:
if (x3)
{
ltmp_3978_7__PHI_TEMPORARY = 0xff7e;
goto llvm_cbe_ov_halfrate_p_2e_exit;
}
ltmp_3978_7__PHI_TEMPORARY = 1;
llvm_cbe_ov_halfrate_p_2e_exit:
ltmp_3978_7 = ltmp_3978_7__PHI_TEMPORARY;
ltmp_4011_7__PHI_TEMPORARY = 0x;
ltmp_4011_7 = ltmp_4011_7__PHI_TEMPORARY;
ltmp_4012_7 = ltmp_4011_7 ltmp_3978_7;
}
--
Summary: [4.3/4.4 regression] ICE in set_lattice_value, at tree-
ssa-ccp.c:466
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38359
[Bug tree-optimization/38359] [4.3/4.4 regression] ICE in set_lattice_value, at tree-ssa-ccp.c:466
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-02 00:11 ---
Here is a shorter testcase:
void _ov_64_seek_lap (void)
{
_Bool x1, x2, x3;
unsigned ltmp_3978_7;
unsigned ltmp_3978_7__PHI_TEMPORARY;
unsigned ltmp_4011_7__PHI_TEMPORARY;
unsigned ltmp_4012_7;
signed ltmp_4011_7;
if (!x1 || !x2)
while (1) ;
if (x3)
ltmp_3978_7__PHI_TEMPORARY = 0xff7e;
else
ltmp_3978_7__PHI_TEMPORARY = 1;
ltmp_3978_7 = ltmp_3978_7__PHI_TEMPORARY;
ltmp_4011_7__PHI_TEMPORARY = 0x;
ltmp_4011_7 = ltmp_4011_7__PHI_TEMPORARY;
ltmp_4012_7 = ltmp_4011_7 ltmp_3978_7;
}
--
pinskia 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-12-02 00:11:53
date||
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38359
