[Bug bootstrap/32835] [4.3 regression] Bootstrap failure under SGI Irix
--- Comment #3 from P dot Schaffnit at access dot rwth-aachen dot de 2007-08-07 06:45 --- Hi! Fixed: revision 127237 builds smoothly Thanks! Philippe === gcc Summary === # of expected passes43910 # of unexpected failures33 # of unexpected successes 2 # of expected failures 97 # of unresolved testcases 9 # of untested testcases 35 # of unsupported tests 398 /usr/local_people/Philippe/Compilation/gcc/xgcc version 4.3.0 20070806 (experimental) === gfortran Summary === # of expected passes19925 # of unexpected failures93 # of unexpected successes 7 # of expected failures 9 # of unsupported tests 28 /usr/local_people/Philippe/Compilation/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070806 (experimental) -- P dot Schaffnit at access dot rwth-aachen dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32835
[Bug target/33008] New: [4.1/4.2 regression] code pessimization after -fforce-mem removal.
unsigned short load( void* p )
{
unsigned short v;
__builtin_memcpy( v, p, sizeof( v ) );
return v;
}
recent 4.2 branch produces:
load: movzwl (%rdi), %eax
movw%ax, -2(%rsp)
movzwl %ax, %eax
ret
revsion 101665 produces optimal code:
load: movzwl (%rdi), %eax
ret
the regression was introduced by Fariborz Jahanian:
http://gcc.gnu.org/viewcvs?view=revrevision=101666
--
Summary: [4.1/4.2 regression] code pessimization after -fforce-
mem removal.
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33008
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #23 from pluto at agmk dot net 2007-08-07 07:22 --- (In reply to comment #22) There are 2 issues, convert and load. They may be caused by different patches and should be tracked separately when doing binary search. i've filled the 'load' issue as PR33008. the gcc-reload-second-2.patch fixes 'convert' and finally this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #4 from nickc at redhat dot com 2007-08-07 08:11 --- Subject: Re: -frecord-gcc-switches issues Hi Roland, Absolute file names are a very bad idea. That makes for gratuitous differences in builds due to the build or source directory name, i.e. unrepeatable builds. The names in .debug_line and .debug_info are already expected by post-processing tools and taken care of. Do not add another location in the object that might contain absolute file names. Ok. :-} I think at the moment we are just discussing how the -frecord-gcc-switches feature can be improved. Nothing is set in stone. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #5 from nickc at redhat dot com 2007-08-07 08:25 --- Subject: Re: -frecord-gcc-switches issues Hi Ben, Is there an easy way to separate out the include and link (-I, -L) bits from the macro defines and compiler option flags? Could the just the include bits be put into one string? Sure. We could add some intelligence to the recording function which looks for these switches and groups them all together. There are quite a lot of them though: -B, -I, -J, -L, -iquote, -isystem, -include, -imacros, -idirafter, -iwithprefixbefore, -imultilib, -isysroot. When doing this does it make sense to define the base_dir and then use it as a substitution instead of putting in absolute addresses everywhere? This might cut down on size. Well that sounds like a good idea to me. But Roland was objecting to recording absolute paths of any kind, so he might not like this. I think that in order to fix this the .GCC.command.line section creation code will have to be made more complex and have access to the entire command line options table. However can you expand on your comment above? What do you mean by have access to the entire command line options table? Would you dump the entire table? Oh no. What I meant was that in order for the recording code to be more intelligent it would need access to gcc's command line options structure, so that, for example, it can tell when a switch takes an argument (and hence correctly deduce whether an entry in the argv[] array should be included in the same string as the previous entry or if it is a new command line switch in its own right). Access to this table would also make it possible to do things like: * group all the optimization switches together in one part of the .GCC.command.line section. * locate switches which negate the effect of previous switches and then skip recording those previous switches. My concern however is that adding this sort of thing complicates the code, and hence is more likely to introduce bugs. Still if it makes the feature useful, then it is worth considering. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug middle-end/33007] [4.3 Regression] Revision 127185 causes NINT to ICE
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-07 08:54 --- Testcase reduced to: subroutine foo(x) integer :: x real :: t t = x call bar(nint(t)) end subroutine foo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug c++/32756] [4.3 Regression] wrong ambiguous overload error?
--- Comment #3 from nathan at gcc dot gnu dot org 2007-08-07 09:32 --- This is something to do with the rvalue reference patches -- nathan at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-07 09:32:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
[Bug c++/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- Comment #2 from saliu at de dot ibm dot com 2007-08-07 11:31 --- Is this really a regression from 4.1.1? I got the same error on 4.1.1, before the patch r117696 was applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #24 from hjl at lucon dot org 2007-08-07 12:57 --- (In reply to comment #23) (In reply to comment #22) There are 2 issues, convert and load. They may be caused by different patches and should be tracked separately when doing binary search. i've filled the 'load' issue as PR33008. the gcc-reload-second-2.patch fixes 'convert' and finally this PR. Which checkin caused the convert regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug c/33009] New: [dataflow] cc1 goes into infinite loop
On trunk (currently r127248), with the testcase for PR11832 cc1 goes into an infinite loop (ctrl-c after 10 minutes). trunk from 20070418 can compile the same example fine. flags used to reproduce: gcc-4.3-HEAD -Os -fomit-frame-pointer -frtl-abstract-sequences -S -o s.S pr11832.c -- Summary: [dataflow] cc1 goes into infinite loop Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i386-linux-gnu GCC host triplet: i386-linux-gnu GCC target triplet: i386-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug middle-end/29881] union causes inefficient code
--- Comment #5 from jose dot r dot fonseca at gmail dot com 2007-08-07
14:01 ---
Note that this problem is actually more general. I bumped into this when doing
a very used pattern for MMX/SSE2 programming, which is making a union between a
vector type and an array of integers:
union I16x8 {
__m128i m;
short v[8];
};
For example this code:
#include emmintrin.h
union I16x8 {
__m128i m;
short v[8];
};
void test(I16x8 *p) {
I16x8 a, c;
a = *p;
c.m = _mm_add_epi16(a.m, a.m);
*p = c;
}
Generates unnecessary copying in the body of the function:
movl8(%ebp), %edx
movl(%edx), %eax
movl%eax, -24(%ebp)
movl4(%edx), %eax
movl%eax, -20(%ebp)
movl8(%edx), %eax
movl%eax, -16(%ebp)
movl12(%edx), %eax
movl%eax, -12(%ebp)
movdqa -24(%ebp), %xmm0
paddw %xmm0, %xmm0
movdqa %xmm0, -40(%ebp)
movl-40(%ebp), %eax
movl%eax, (%edx)
movl-36(%ebp), %eax
movl%eax, 4(%edx)
movl-32(%ebp), %eax
movl%eax, 8(%edx)
movl-28(%ebp), %eax
movl%eax, 12(%edx)
The more strange is that eliminating the array member of the union as following
union I16x8 {
__m128i m;
};
Also generates *exactly* the same redundant code:
movl8(%ebp), %edx
movl(%edx), %eax
movl%eax, -24(%ebp)
movl4(%edx), %eax
movl%eax, -20(%ebp)
movl8(%edx), %eax
movl%eax, -16(%ebp)
movl12(%edx), %eax
movl%eax, -12(%ebp)
movdqa -24(%ebp), %xmm0
paddw %xmm0, %xmm0
movdqa %xmm0, -40(%ebp)
movl-40(%ebp), %eax
movl%eax, (%edx)
movl-36(%ebp), %eax
movl%eax, 4(%edx)
movl-32(%ebp), %eax
movl%eax, 8(%edx)
movl-28(%ebp), %eax
movl%eax, 12(%edx)
However overwriting the assignment operator as:
union I16x8 {
__m128i m;
short v[8];
I16x8 operator =(I16x8 o) {
m = o.m;
return *this;
}
};
Generates the right assembly code for the function above:
movl8(%ebp), %eax
movdqa (%eax), %xmm0
paddw %xmm0, %xmm0
movdqa %xmm0, (%eax)
Also strange, is that a dummy structure as follows:
struct I16x8 {
__m128i m;
};
Also generates the right code (exactly as above):
movl8(%ebp), %eax
movdqa (%eax), %xmm0
paddw %xmm0, %xmm0
movdqa %xmm0, (%eax)
The union of vector type with a array of integers is an example used in almost
every tutorial of the SIMD intrinsics out there. This bug was causing gcc to
perform poorly with my code compared with Microsoft Visual C++ Compiler and
Intel C++ Compiler, but after working around this it generated faster code than
both.
--
jose dot r dot fonseca at gmail dot com changed:
What|Removed |Added
CC||jose dot r dot fonseca at
||gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29881
[Bug bootstrap/33010] New: bootstrap fails with assembler error
bootstrap for me worked fine on August 6th. Today (August 7th) it fails with: gmake[6]: Entering directory `/u01/var/tmp/gcc_trunk_svn/gcc_20070807/gcc' /u01/var/tmp/gcc_trunk_svn/gcc_20070807/./gcc/xgcc -B/u01/var/tmp/gcc_trunk_svn/gcc_20070807/./gcc/ -B/opt/gcc-4.3/i386-pc-solaris2.11/bin/ -B/opt/gcc-4.3/i386-pc-solaris2.11/lib/ -isystem /opt/gcc-4.3/i386-pc-solaris2.11/include -isystem /opt/gcc-4.3/i386-pc-solaris2.11/sys-include -O2 -O2 -msse2 -march=native -mtune=native -O3 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I/u01/var/tmp/gcc_trunk_svn/gcc_20070807/i386-pc-solaris2.11/amd64/libgcc -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc//u01/var/tmp/gcc_trunk_svn/gcc_20070807/i386-pc-solaris2.11/amd64/libgcc -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc/../include -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc/../libdecnumber -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -g -fkeep-inline-functions -m64 -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \ -c /u01/var/tmp/gcc_trunk_svn/gcc/gcc/crtstuff.c -DCRT_BEGIN \ -o /u01/var/tmp/gcc_trunk_svn/gcc_20070807/i386-pc-solaris2.11/amd64/libgcc/crtbegin.o /var/tmp//ccjpaqV3.s: Assembler messages: /var/tmp//ccjpaqV3.s:91: Error: suffix or operands invalid for `pop' /var/tmp//ccjpaqV3.s:92: Error: Incorrect register `%rdx' used with `l' suffix gmake[6]: *** [/u01/var/tmp/gcc_trunk_svn/gcc_20070807/i386-pc-solaris2.11/amd64/libgcc/crtbegin.o] Error 1 This is from my nightly build of trunk, with no config changes on the server. Let me know if you need more information to debug. Brett Albertson -- Summary: bootstrap fails with assembler error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brett dot albertson at stratech dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33010
[Bug middle-end/29881] union causes inefficient code
--- Comment #6 from jose dot r dot fonseca at gmail dot com 2007-08-07 14:18 --- Created an attachment (id=14031) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14031action=view) Example code This is the source-code for my example above. To get the assembly run as: gcc -S -DCASE=0 -O3 -msse2 -o sse2-union-0.s sse2-union.cpp gcc -S -DCASE=1 -O3 -msse2 -o sse2-union-1.s sse2-union.cpp gcc -S -DCASE=2 -O3 -msse2 -o sse2-union-2.s sse2-union.cpp gcc -S -DCASE=3 -O3 -msse2 -o sse2-union-3.s sse2-union.cpp This was run on (gcc -v): Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.3 20070718 (prerelease) (Debian 4.1.2-14) But I actually first discovered this in an unofficial build of gcc-4.2 for MinGW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29881
[Bug target/33011] New: [4.3 Regression] frv: error: bad output_move_single operand
Revision 126878 works while revision 126879 fails with:
/home/rask/build/gcc-frv-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-frv-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-frv-unknown-elf/frv-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-frv-unknown-elf/frv-unknown-elf/newlib/targ-include
-isystem /n/12/rask/src/all/newlib/libc/include
-B/home/rask/build/gcc-frv-unknown-elf/frv-unknown-elf/libgloss/frv
-L/home/rask/build/gcc-frv-unknown-elf/frv-unknown-elf/libgloss/libnosys
-L/n/12/rask/src/all/libgloss/frv -B/usr/local/frv-unknown-elf/bin/
-B/usr/local/frv-unknown-elf/lib/ -isystem /usr/local/frv-unknown-elf/include
-isystem /usr/local/frv-unknown-elf/sys-include
-L/home/rask/build/gcc-frv-unknown-elf/./ld -c -DHAVE_CONFIG_H -O2 -g -O2
-mcpu=fr400 -I. -I/n/12/rask/src/all/libiberty/../include -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
/n/12/rask/src/all/libiberty/regex.c -o regex.o
/n/12/rask/src/all/libiberty/regex.c: In function 'byte_re_match_2_internal':
/n/12/rask/src/all/libiberty/regex.c:7481: error: bad output_move_single
operand
(insn:TI 3960 3959 1596 /n/12/rask/src/all/libiberty/regex.c:6810 (set (reg:DI
12 gr12)
(mem/c:DI (plus:SI (reg/f:SI 2 fp)
(const_int -168 [0xff58])) [66 S8 A64])) 6
{*movsi_load} (nil))
/n/12/rask/src/all/libiberty/regex.c:7481: internal compiler error: in
output_move_single, at config/frv/frv.c:4423
Configure flags:
--target=frv-unknown-elf --enable-languages=c --with-newlib --disable-gdb
--
Summary: [4.3 Regression] frv: error: bad output_move_single
operand
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: frv-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33011
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-07 14:32 --- -frtl-abstract-sequences is not well tested at all. It is in the same situation as -fsee. There are no testcases which test it so how do we know it is broken. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization Summary|[dataflow] cc1 goes into|-frtl-abstract-sequences |infinite loop |causes an infinite loop http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-07 14:37 --- I get an ICE: t.c: In function 'foo': t.c:28: error: unrecognizable insn: (insn 177 0 0 (set (reg:SI 0 ax) (symbol_ref:SI (*L9) [flags 0x2])) -1 (nil)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug middle-end/33007] [4.3 Regression] Revision 127185 causes NINT to ICE
--- Comment #5 from hjl at lucon dot org 2007-08-07 14:40 ---
There is a disconnect between middle-end and back-end. There are many
places in builtins.c with
/* If argument is already integer valued, and we don't need to worry
about setting errno, there's no need to perform rounding. */
if (! flag_errno_math integer_valued_real_p (arg))
However, the x86 back-end doesn't have this info:
(define_expand lroundSSEMODEF:modeSSEMODEI24:mode2
[(match_operand:SSEMODEI24 0 nonimmediate_operand )
(match_operand:SSEMODEF 1 register_operand )]
SSE_FLOAT_MODE_P (SSEMODEF:MODEmode) TARGET_SSE_MATH
((SSEMODEI24:MODEmode != DImode) || TARGET_64BIT)
!flag_trapping_math !flag_rounding_math
!optimize_size
{
ix86_expand_lround (operand0, operand1);
DONE;
})
That is why it fails to expand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug target/33010] bootstrap fails with assembler error
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|bootstrap |target Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33010
[Bug target/33011] [4.3 Regression] frv: error: bad output_move_single operand
--- Comment #1 from rask at gcc dot gnu dot org 2007-08-07 14:44 --- Created an attachment (id=14032) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14032action=view) Testcase to compile with -O2 -mcpu=fr400 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33011
[Bug target/33011] [4.3 Regression] frv: error: bad output_move_single operand
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33011
[Bug middle-end/33007] [4.3 Regression] Revision 127185 causes NINT to ICE
--- Comment #6 from hjl at lucon dot org 2007-08-07 14:56 ---
Here is a testcase in C:
bash-3.2$ cat x.c
extern void bar (int *);
void
foo (int *i)
{
float x;
int y;
x = *i;
y = (int) __builtin_lroundf (x);
bar (y);
}
bash-3.2$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -S x.c -ffast-math
-ftrapping-math
x.c: In function foo:
x.c:10: internal compiler error: in get_callee_fndecl, at tree.c:6521
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
bash-3.2$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug tree-optimization/32975] [4.3 Regression] ICE segfault (verify_cgraph failure after ipa-cp) with -finline-functions -fipa-cp
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-07 15:04 --- This has to do with folding of __builtin_strlen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32975
[Bug bootstrap/32973] [4.3 regression] bootstrap failure with indented structure declaration in macro
--- Comment #5 from schwab at gcc dot gnu dot org 2007-08-07 15:32 --- Subject: Bug 32973 Author: schwab Date: Tue Aug 7 15:31:56 2007 New Revision: 127272 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127272 Log: PR bootstrap/32973 * gengtype-lex.l: Ignore backslash/newline pair while scanning a struct definition. Modified: trunk/gcc/ChangeLog trunk/gcc/gengtype-lex.l -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32973
[Bug bootstrap/32973] [4.3 regression] bootstrap failure with indented structure declaration in macro
--- Comment #6 from schwab at suse dot de 2007-08-07 16:05 --- Fixed. -- schwab at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32973
[Bug middle-end/33007] [4.3 Regression] builtin lround doesn't work
--- Comment #7 from hjl at lucon dot org 2007-08-07 16:24 ---
A more simple testcase also fails on Linux/ia64:
[EMAIL PROTECTED] lround]$ cat x.c
int
foo (int *i)
{
float x;
int y;
x = *i;
y = (int) __builtin_lroundf (x);
return y;
}
[EMAIL PROTECTED] lround]$ make x.s
/export/build/gnu/gcc/build-ia64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/gcc/ -O -ffast-math -ftrapping-math -S
x.c
x.c: In function foo:
x.c:8: internal compiler error: in get_callee_fndecl, at tree.c:6521
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make: *** [x.s] Error 1
[EMAIL PROTECTED] lround]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug middle-end/33007] [4.3 Regression] builtin lround doesn't work
--- Comment #8 from hjl at lucon dot org 2007-08-07 16:27 ---
This is the smallest testcase I find:
long
foo (int i)
{
float x;
x = i;
return __builtin_lroundf (x);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug middle-end/33007] [4.3 Regression] builtin lround doesn't work
--- Comment #9 from hjl at lucon dot org 2007-08-07 17:03 ---
Does this patch:
--- builtins.c.round2007-07-29 13:18:40.0 -0700
+++ builtins.c 2007-08-07 09:58:46.0 -0700
@@ -2689,6 +2689,16 @@ expand_builtin_int_roundingfn_2 (tree ex
start_sequence ();
+ if (TREE_CODE (exp) == NOP_EXPR)
+switch (TREE_CODE (TREE_OPERAND (exp, 0)))
+ {
+ case FIX_TRUNC_EXPR:
+ builtin_optab = sfixtrunc_optab;
+ break;
+ default:
+ gcc_unreachable ();
+ }
+
if (expand_sfix_optab (target, op0, builtin_optab))
{
/* Output the entire sequence. */
@@ -2698,6 +2708,8 @@ expand_builtin_int_roundingfn_2 (tree ex
return target;
}
+ gcc_assert (TREE_CODE (exp) == CALL_EXPR);
+
/* If we were unable to expand via the builtin, stop the sequence
(without outputting the insns) and call to the library function
with the stabilized argument list. */
make any senses?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug java/32862] bug in EnumMap implementation
--- Comment #3 from tromey at gcc dot gnu dot org 2007-08-07 17:38 --- Fixed via classpath import. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32862
[Bug c++/33012] New: ICE on throwing copy of object returned by reference from method with traits-deduced return-type
Compiling a .cpp file with the following contents triggers an internal compiler
error:
/*
* The two Traits templates here are essentially std::iterator_traits
* stripped right down with just enough left to make the test-case work:
*/
templatetypename _Type struct Traits;
templatetypename _Type
struct Traits_Type * { typedef _Type reference; };
/*
* TraitedWrapper is essentially __gnu_cxx::__normal_iterator stripped
* to the minimum required to make the test-case work:
*/
templatetypename _Pointer
class TraitedWrapper {
public:
typedef typename Traits_Pointer::referencereference;
TraitedWrapper(const _Pointer pointer) : pointer_(pointer) { }
reference get() const { return *pointer_; }
private:
_Pointer pointer_;
};
/*
* SpecialWrapper is essentially a form of TraitedWrapper that is
* specialised for the pointer case in the way that Traits is.
*/
templatetypename _Typeclass SpecialWrapper;
templatetypename _Type
class SpecialWrapper_Type * {
public:
SpecialWrapper(_Type *pointer) : pointer_(pointer) { }
_Type get() const { return *pointer_; }
private:
_Type *pointer_;
};
/*
* inner() throws a copy of an object returned by reference from
* a method whose return-type is sometimes deduced by some template
* indirection. It's templated to show what happens with different
* combinations of return-type deduction and copy-constructor origin.
*/
templatetemplatetypename class _Wrapper, typename _Type
voidinner()
{
_Type orig;
_Wrapper_Type * wrapper(orig);
/*
* No problem copy-constructing a stack-variable from the iterator:
*/
_Type copy(wrapper.get());
if( true )
/*
* No problem throwing the stack-variable:
*/
throw copy;
else
/*
* ICE can happen here, when directly throwing a copy,
* depending on template parameters:
*/
throw _Type(wrapper.get());
}
struct Generated { };
struct Manual {
Manual() { }
Manual(const Manual) { }
};
voidouter()
{
innerSpecialWrapper, Manual();
innerSpecialWrapper, Generated();
innerTraitedWrapper, Manual();
/*
* ICE when the wrapper get-method has a traits-deduced return-type
* and the class has a compiler-supplied copy-constructor:
*/
innerTraitedWrapper, Generated();
}
Issued command-line:
g++ -Wall -W -Wundef -Wpointer-arith -g -O0 -c -o /dev/null bug.cpp
Resulting output:
bug.cpp: In function 'void inner() [with _Wrapper = TraitedWrapper, _Type =
Generated]':
bug.cpp:101: instantiated from here
bug.cpp:79: internal compiler error: in stabilize_call, at cp/tree.c:2248
Please submit a full bug report,
...
Full output from running with -v --save-temps is as follows:
g++ -v -save-temps -Wall -W -Wundef -Wpointer-arith -g -O0 -c -o /dev/null
bug.cpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
Thread model: posix
gcc version 4.1.1
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -E -quiet -v
-D_GNU_SOURCE bug.cpp -mtune=pentiumpro -Wall -W -Wundef -Wpointer-arith
-fworking-directory -O0 -fpch-preprocess -o bug.ii
ignoring nonexistent directory NONE/include
ignoring nonexistent directory
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/i686-pc-linux-gnu
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/include
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/include
/usr/include
End of search list.
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -fpreprocessed bug.ii
-quiet -dumpbase bug.cpp -mtune=pentiumpro -auxbase-strip /dev/null -g -O0
-Wall -W -Wundef -Wpointer-arith -version -o bug.s
GNU C++ version 4.1.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63424
Compiler executable checksum: 5c1ee95ea2451a4e1aafd30c10a207cb
bug.cpp: In function 'void inner() [with _Wrapper = TraitedWrapper, _Type =
Generated]':
bug.cpp:101: instantiated from here
bug.cpp:79: internal compiler error: in stabilize_call, at cp/tree.c:2248
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE on throwing copy of object returned by reference
from method with traits-deduced return-type
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #25 from pluto at agmk dot net 2007-08-07 17:51 ---
(In reply to comment #24)
(In reply to comment #23)
(In reply to comment #22)
There are 2 issues, convert and load. They may be caused by different
patches and should be tracked separately when doing binary search.
i've filled the 'load' issue as PR33008.
the gcc-reload-second-2.patch fixes 'convert' and finally this PR.
Which checkin caused the convert regression?
i don't know but the 'convert' issue is almost fixed.
gcc-4.2 patched against PR27567 and gcc-reload-second-2.patch produces:
float convert_int2float( int in )
{
float f;
__builtin_memcpy( f, in, sizeof( f ) );
return f;
}
double convert_long2double( long in )
{
double f;
__builtin_memcpy( f, in, sizeof( f ) );
return f;
}
{-m64 -O2}
convert_int2float:
movl%edi, -4(%rsp)
movss -4(%rsp), %xmm0
ret
convert_long2double:
movq%rdi, -8(%rsp)
movsd -8(%rsp), %xmm1 == reload-second patch doesn't work here.
movapd %xmm1, %xmm0 == /
ret
{-m32 -O2 -fomit-frame-pointer}
convert_int2float:
flds4(%esp)
ret
convert_long2double:
fldl4(%esp)
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #26 from pluto at agmk dot net 2007-08-07 17:53 --- (In reply to comment #25) errata: double convert_long2double( long in ) wrong post, should be 'long long'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug c++/33012] ICE on throwing copy of object returned by reference from method with traits-deduced return-type
--- Comment #1 from raymond at corvil dot com 2007-08-07 17:59 ---
I have been able to reproduce the same ICE in 3.4.2,
gcc version 3.4.2 20040827 (prerelease) [FreeBSD]
but not in 2.95.4 or 4.1.2:
gcc version 2.95.4 20020320 [FreeBSD]
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
I originally found the ICE in some code that was throwing a copy of an object
in a std::vector on the stack. By playing around with the test code I posted,
I found that it seems to trigger only when the following three conditions occur
together:
* the copy is directly thrown, and not when the a copy is declared on the stack
and then thrown;
* the method that provides the reference to be copied has a return-type deduced
from a traits template;
* the class of the object being thrown does not provide a copy-constructor.
I've tried to illustrate in the full test case that, if any one of these
conditions is false, then the ICE doesn't happen.
The following shorter test-case also triggers the error. I know it includes a
standard header, and I haven't provided pre-processed sources for this, but
it's just for illustration purposes.
#include vector
/*
* inner() throws a copy of an object contained in a vector.
* It's templated to show what happens with different _Types.
*/
templatetypename _Type
voidinner()
{
typename std::vector_Type vector(1);
throw _Type(*vector.begin());
}
struct Generated { };
struct Manual {
Manual() { }
Manual(const Manual) { }
};
voidouter()
{
// No problems when the class has a hand-written copy-constructor:
innerManual();
// ICE when the class has a compiler-supplied copy-constructor:
innerGenerated();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33012
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #27 from hjl at lucon dot org 2007-08-07 18:10 ---
Created an attachment (id=14033)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14033action=view)
An updated patch
My patch works on gcc 4.3:
[EMAIL PROTECTED] 30961]$ cat c.c
double
convert4(long long in )
{
double f;
__builtin_memcpy( f, in, sizeof( in ) );
return f;
}
[EMAIL PROTECTED] 30961]$ make c.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -O2
-fno-asynchronous-unwind-tables c.c
[EMAIL PROTECTED] 30961]$ cat c.s
.file c.c
.text
.p2align 4,,15
.globl convert4
.type convert4, @function
convert4:
movq%rdi, -8(%rsp)
movsd -8(%rsp), %xmm0
ret
.size convert4, .-convert4
.ident GCC: (GNU) 4.3.0 20070806 (experimental) [trunk revision
127248]
.section.note.GNU-stack,,@progbits
[EMAIL PROTECTED] 30961]$
If you can find which patch causes this regression, it will be easier to
find a solution for 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug c/33013] New: Documentation for __builtin_choose_expr is wrong
The info page says: This built-in function returns EXP1 if CONST_EXP, which is a constant expression that must be able to be determined at compile time, is nonzero. Otherwise it returns 0. The last sentence should read, Otherwise it returns EXP2. -- Summary: Documentation for __builtin_choose_expr is wrong Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brian at oddchange dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33013
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #7 from patchapp at dberlin dot org 2007-08-07 19:15 --- Subject: Bug number PR c++/31749 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00452.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
[Bug c/33014] New: Documentation for __builtin_choose_expr is wrong
The info page says: This built-in function returns EXP1 if CONST_EXP, which is a constant expression that must be able to be determined at compile time, is nonzero. Otherwise it returns 0. The last sentence should read, Otherwise it returns EXP2. -- Summary: Documentation for __builtin_choose_expr is wrong Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brian at oddchange dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33014
[Bug c/33013] Documentation for __builtin_choose_expr is wrong
--- Comment #1 from brian at oddchange dot com 2007-08-07 19:40 --- *** Bug 33014 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33013
[Bug c/33014] Documentation for __builtin_choose_expr is wrong
--- Comment #1 from brian at oddchange dot com 2007-08-07 19:40 --- *** This bug has been marked as a duplicate of 33013 *** -- brian at oddchange dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33014
[Bug fortran/33015] New: F66/Vendor extension: Implement support for DATA jhlf/'f'/
Possible extension to be added is the support of:
data jhlf,jhlg/'f','g'/
Which is interpreted as follows (thanks to Steve Lionel of Intel):
| The character literals are blank-padded on the right to the length of the
| corresponding variables (or truncated as necessary) and then the ASCII
| equivalent is assigned. So what you have here could be replaced by:
|
| data jhlf,jhlg /Z'20202066',Z'20202067'/
|
| or use transfer('f ',jhlf), etc.
|
| Effectively, this is the old F66 Hollerith constant style of
| programming.
Found in Cowan's rcn program, which started in 1961.
ftp://aphysics.lanl.gov/pub/cowan/
I don't feel strong about it, but it would make life easier for such old
programs.
Actually, ifort also supports:
integer :: jhlf
jhlf = 'f'
Such a character - integer/real/complex conversion would be something for
-std=legacy.
--
Summary: F66/Vendor extension: Implement support for DATA
jhlf/'f'/
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33015
[Bug c++/33016] New: type_info::before() will not return the same value
gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --with-gmp=/home/pneveu/apps/gcc-4.1.2/gmp --with-mpfr=/home/pneveu/apps/gcc-4.1.2/mpfr --prefix=/build/pcitools/gcc4.1.2 Thread model: posix gcc version 4.1.2 If you compile the file before.cpp, with and without defining the PRINT_TYPE_INFO_BEFORE define, the type_info::before() function will not generate the same output. Here are the steps to reproduce the bug: In this case A is not before B: typeid(A).before(typeid(B)) == false g++ before.cpp -o before ./before A is before B: 0 typeid(A).name(): 1A typeid(B).name(): 1B In this case A is before B: typeid(A).before(typeid(B)) == true g++ -DPRINT_TYPE_INFO_NAME_BEFORE before.cpp -o before ./before typeid(A).name(): 1A typeid(B).name(): 1B A is before B: 1 Regards, Phelippe Neveu -- Summary: type_info::before() will not return the same value Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pneveu at pcigeomatics dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33016
[Bug c++/33016] type_info::before() will not return the same value
--- Comment #1 from pneveu at pcigeomatics dot com 2007-08-07 20:07 --- Created an attachment (id=14034) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14034action=view) Defines a class B that inherit the class A, and print the returned value of typeid(A).before(typeid(B)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33016
[Bug c++/33016] type_info::before() will not return the same value
--- Comment #2 from pneveu at pcigeomatics dot com 2007-08-07 20:10 --- Created an attachment (id=14035) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14035action=view) The temporary file created when compiling before.cpp without defining PRINT_TYPE_INFO_NAME_BEFORE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33016
[Bug c++/33016] type_info::before() will not return the same value
--- Comment #3 from pneveu at pcigeomatics dot com 2007-08-07 20:11 --- Created an attachment (id=14036) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14036action=view) The temporary file created when compiling before.cpp with defining PRINT_TYPE_INFO_NAME_BEFORE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33016
[Bug fortran/33015] g77/F66/vendor extension: Implement support for DATA jhlf /'f'/
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-07 20:13 --- Just for completeness: This is a regression with regards to g77. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Known to work||3.3.5 Summary|F66/Vendor extension: |g77/F66/vendor extension: |Implement support for DATA |Implement support for DATA |jhlf/'f'/ |jhlf /'f'/ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33015
[Bug middle-end/30969] [4.3 Regression] The polyhedron test 'fatigue.f90' is no longer working.
--- Comment #10 from steven at gcc dot gnu dot org 2007-08-07 21:01 --- Never confirmed, and reported says the bug seems to be fixed. If the bug is still there, please re-open this PR. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #28 from pluto at agmk dot net 2007-08-07 21:20 ---
(In reply to comment #27)
If you can find which patch causes this regression, it will be easier to
find a solution for 4.2.
r80888 works fine (below) and r85770 is broken.
i can't bisect more dueto build errors.
gcc{42/40} rejects libbanshee/engine/setif-sort.c.
convert_int2float:
movl%edi, -4(%rsp)
movss -4(%rsp), %xmm0
ret
convert_long2double:
movq%rdi, -8(%rsp)
movlpd -8(%rsp), %xmm0
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug c/33017] New: tree check fail for legal code
I just tried to compile Suse Linux package ddiwrapper-0.2-86 with the GNU C compiler version 4.3 snapshot 20070803. The compiler said write_msft.c: In function 'ctl2_alloc_string': write_msft.c:562: internal compiler error: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:566 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Preprocessed source attached. Flags -O2 -ftree-vectorize -m32 required. -- Summary: tree check fail for legal code Product: gcc Version: 4.3.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: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33017
[Bug c/33017] tree check fail for legal code
--- Comment #1 from dcb314 at hotmail dot com 2007-08-07 21:43 --- Created an attachment (id=14037) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14037action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33017
[Bug java/33018] New: Not able to get past this error
linux:~/Desktop/D/gcc-4.2.1# make [ -f stage_final ] || echo stage3 stage_final . .. make[3]: Entering directory `/D/gcc-4.2.1/host-i686-pc-linux-gnu/gcc' /root/Desktop/D/gcc-4.2.1/host-i686-pc-linux-gnu/prev-gcc/xgcc -B/root/Desktop/D/gcc-4.2.1/host-i686-pc-linux-gnu/prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -Ijava -I../.././gcc -I../.././gcc/java -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../libdecnumber../.././gcc/java/jcf-write.c -o java/jcf-write.o ../.././gcc/java/jcf-write.c: In function 'make_class_file_name': ../.././gcc/java/jcf-write.c:3494: error: too few arguments to function 'mkdir' make[3]: *** [java/jcf-write.o] Error 1 make[3]: Leaving directory `/D/gcc-4.2.1/host-i686-pc-linux-gnu/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/D/gcc-4.2.1' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/D/gcc-4.2.1' make: *** [all] Error 2 -- Summary: Not able to get past this error Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: maybe_guess_who_is at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33018
[Bug tree-optimization/32544] gcc 4.2.1 miscompiles Mesa's r300 DRI driver with -ftree-vrp
--- Comment #5 from pixel at mandriva dot com 2007-08-07 22:33 --- Created an attachment (id=14038) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14038action=view) miscompiles with gcc 4.2 -O2 here is a simple test case reproducing the issue. eg: % gcc -O2 ivopts-issue.c ./a.out gcc -O2 -fno-ivopts ivopts-issue.c ./a.out 0 0 1 2 2 2 1 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544
[Bug tree-optimization/32544] gcc 4.2.1 miscompiles Mesa's r300 DRI driver with -ftree-vrp
--- Comment #6 from pixel at mandriva dot com 2007-08-07 22:41 --- more info: the tree-vrp issue is raised by ivopts pass: without ivopts: D.1541_13 = 3 - i_31; D.1542_14 = (unsigned int) D.1541_13; D.1543_15 = D.1542_14 * 4; D.1544_16 = (int *) D.1543_15; with ivopts: D.1607_62 = (int *) i_31; D.1608_63 = D.1607_62 * -4B; D.1544_64 = D.1608_63 + 12B; D.1544_16 = D.1544_64; vrp finds that D.1608_63 is 0, and so replaces D.1544_64 with 12 D.1607_62 = (int *) i_31; D.1608_63 = D.1607_62 * -4B; D.1544_64 = D.1608_63 + 12B; D.1544_16 = D.1544_64; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544
[Bug rtl-optimization/32776] [4.3 Regression] ICE RTL check: expected code 'reg', have 'concatn' in rhs_regno, at rtl.h:972
--- Comment #3 from ian at gcc dot gnu dot org 2007-08-07 22:44 --- Subject: Bug 32776 Author: ian Date: Tue Aug 7 22:43:55 2007 New Revision: 127282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127282 Log: PR rtl-optimization/32776 * lower-subreg.c (resolve_clobber): Call resolve_reg_notes. (resolve_use): Likewise. (decompose_multiword_subregs): Remove changed local variable. Modified: trunk/gcc/ChangeLog trunk/gcc/lower-subreg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32776
[Bug tree-optimization/32544] gcc 4.2.1 miscompiles Mesa's r300 DRI driver with -ftree-vrp
--- Comment #7 from pixel at mandriva dot com 2007-08-07 22:45 ---
the following patch fixes the testcase ivopts-issue.c, but breaks everything
else... someone else will find a correct patch :)
--- gcc-4.2.1/gcc/tree-ssa-loop-ivopts.c.pix2006-10-06 21:32:04.0
+0200
+++ gcc-4.2.1/gcc/tree-ssa-loop-ivopts.c2007-08-08 00:23:49.0
+0200
@@ -3061,7 +3061,9 @@ get_computation_aff (struct loop *loop,
expr = fold_convert (ctype, expr);
}
- if (TYPE_UNSIGNED (utype))
+ if (POINTER_TYPE_P (utype))
+uutype = ctype;
+ else if (TYPE_UNSIGNED (utype))
uutype = utype;
else
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544
[Bug rtl-optimization/32776] [4.3 Regression] ICE RTL check: expected code 'reg', have 'concatn' in rhs_regno, at rtl.h:972
--- Comment #4 from ian at airs dot com 2007-08-07 22:47 --- Fixed. -- ian at airs dot com changed: What|Removed |Added CC|ian at gcc dot gnu dot org |ian at airs dot com Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32776
[Bug c++/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- Comment #3 from janis at gcc dot gnu dot org 2007-08-07 23:17 --- It compiles quickly for me with GCC 4.1.1 for powerpc64-linux and with a 4.1.1 cross compiler for i686-linux. Is your 4.1.1 compiler from FSF sources, or might it have additional backports? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #29 from hjl at lucon dot org 2007-08-08 00:33 --- With revision 85770, I got [EMAIL PROTECTED] rrs]$ cat convert.s .file convert.c .text .align 4 .p2align 4,,15 .globl convert4 .type convert4, @function convert4: movq%rdi, -8(%rsp) movq%rdi, -16(%rsp) movlpd -8(%rsp), %xmm0 ret .size convert4, .-convert4 .ident GCC: (GNU) 3.5.0 20040810 (experimental) .section.note.GNU-stack,,@progbits Remove the extra mvoq won't solve this regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #25 from s_j_newbury at yahoo dot co dot uk 2007-08-08 01:45 --- Created an attachment (id=14039) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14039action=view) Prevent fixincludes false positive on gentoo stdio.h wrapper The fixincludes script is hitting a false positive when it scans the /usr/include/stdio.h header wrapper on gentoo multilib systems. Adding a bypass for gentoo-multilib to the relevant fix solves this issue. A multilib build successfully concludes with this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug libfortran/33019] New: FORTRAN NAMELIST Run Time Problem
Unable to tell the difference between 'CODE' and 'CODEtwo' namelist names in attachments to follow. -- Summary: FORTRAN NAMELIST Run Time Problem Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: jvdelisle at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33019
[Bug libfortran/33019] FORTRAN NAMELIST Run Time Problem
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-08-08 02:18 --- Created an attachment (id=14040) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14040action=view) Namelist input file Test case using attached input: PROGRAM namelist CHARACTER*25 CHAR NAMELIST /CODE/ CHAR, X NAMELIST /CODEtwo/ X C OPEN(5, file='namelist.in') 100 CHAR = 'Initialize string ***' X= -777. READ(5, nml=CODE, END=999) WRITE(6,*) CHAR, X GO TO 100 999 STOP 'namelist' END PROGRAM namelist -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33019
[Bug libfortran/33019] FORTRAN NAMELIST Run Time Problem
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-08-08 02:19 --- Created an attachment (id=14041) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14041action=view) Namelist input file Correct input file. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Attachment #14040|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33019
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #30 from hjl at lucon dot org 2007-08-08 03:01 --- This patch http://gcc.gnu.org/ml/gcc-cvs/2006-09/msg00042.html causes this regression. -- hjl at lucon dot org changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug rtl-optimization/11222] arm/thumb __Unwind_SjLj_Register prologue optimization causes crash on interrupts
--- Comment #9 from guested dot portrayed dot stephen at blacksapphire dot
com 2007-08-08 05:15 ---
Created an attachment (id=14042)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14042action=view)
This fixes a very similar bug in 4.1.1
gcc version 4.1.1 contains a very similar (but not quite the same) bug where
function epilogues like this are generated for ARM thumb targets.
empty:
push{r7, lr}
add r7, sp, #8
mov sp, r7
sub sp, sp, #8
@ sp needed for prologue
pop {r7}
pop {r0}
bx r0
The problem is that between mov sp, r7 and sub sp, #8, the stack pointer
points above the valid stack bottom, and if an interrupt occurs between these
points, stack contents get overwritten.
To generate the above code, use this test.c file:
--- test.c
void empty(void);
void empty()
{
}
--- end test.c
Use this command:
/opt/arm-none-eabi/bin/arm-none-eabi-gcc -S -o test.s test.c -mthumb
-fno-omit-frame-pointer -O2
The attached patch fixes this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11222
