Re: i read that i should send here email
Piotr Marasz wrote: I try compile example program gcc.exe -Ic:\gcc\include -Lc:\gcc\lib c:\gcc\bin\program.c gcc.exe: Internal error: (null) (program as) Please submit bug report. First the bug report should not go here but to http://gcc.gnu.org/bugzilla (this is a list for development of gcc). Second, you need to tell which version you are using of gcc, where did you get it from, what system you are on, and what program you are compiling. All information that http://gcc.gnu.org/bugs.html (found on google by searching for report gcc bug) tells you we need. Free is bad? Several thousands (million?) users of gcc don't agree, but everybody can of course make his own opinion. Paolo
Question about build error
hi, When I build gcc-3.2.2 for mips target, there's an error. What's the problem? Thanks Eirc ake[1]: Leaving directory `/home/cii/qwang_gcc/libiberty' xgcc: specs file malformed after 4096 characters xgcc: specs file malformed after 4096 characters xgcc: specs file malformed after 4096 characters make[1]: Entering directory `/home/cii/qwang_gcc/gcc' (cd intl make all) make[2]: Entering directory `/home/cii/qwang_gcc/gcc/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/cii/qwang_gcc/gcc/intl' echo int xxy_us_dummy; tmp-dum.c /home/cii/qwang_gcc/gcc/xgcc -B/home/cii/qwang_gcc/gcc/ -B/opt/qwang-toolchain/m ipsel-linux/bin/ -B/opt/qwang-toolchain/mipsel-linux/lib/ -isystem /opt/qwang-to olchain/mipsel-linux/include -S tmp-dum.c xgcc: specs file malformed after 4096 characters make[1]: *** [s-under] Error 1 make[1]: Leaving directory `/home/cii/qwang_gcc/gcc' make: *** [all-gcc] Error 2
Re: Reloading Problems and Memory Addressing
On Wed, Apr 12, 2006 at 07:47:32AM +0200, Frank Riese wrote: On Monday 10 April 2006 19:48, you wrote: Can it at least add (small) immediates to registers? Nope, sry. The only instructions that take other arguments than registers are the aforementioned LDL/LDH (load low/high), branch instructions (they take a memory address) and four bit operations which can mask, invert, set or delete a bit in a register. This will increase the probability of reload failures when storing through a pointer, because of the need for an extra register to hold the offset in some cases. For example int x, *p; p[15] = x; /* p not used after this */ LDL R[4], 30 LDH R[4], 0 ADD R[3], R[3], R[4] STO R[3], R[2] #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \ if (REG_P (X)) \ goto LABEL; I tried that out today. I wasn't sure about the exact contexts in which this macro is used. It seems to work fine, though. Various parts of GCC (combine and reload, for example) build memory addresses and will use this macro to verify that they are supported. Predicates such as memory_operand, nonimmediate_operand and general_operand use it to check memory operands for supported addresses. For example, combine might try to generate an insn such as (set (reg:HI 20) (mem:HI (plus:HI (reg:HI 21) (reg:HI 22 out of (set (reg:HI 23) (plus:HI (reg:HI 21) (reg:HI 22))) (set (reg:HI 20) (mem:HI (reg:HI 23))) but this will be rejected by GO_IF_LEGITIMATE_ADDRESS() in your case. $ gcc function1.c [...] function1.c: In function 'main': function1.c:10: internal compiler error: Segmentation fault (gdb) bt #0 0x0829028f in htab_find_slot (htab=0x5b52202c, element=0xbf805284, insert=INSERT) at ../../gcc-4.0.2/libiberty/hashtab.c:707 I have no idea. I haven't seen such a failure before. 1) Does BP really have to be fixed? You are sufficiently desparate for registers than you'll not fix BP unless the hardware itself mandates this. I thought it needs to be fixed if I want to set it aside as the frame pointer. See the macros FRAME_POINTER_REQUIRED and ELIMINABLE_REGS. You want the former to be 0 and the latter to contain an elimination of FRAME_POINTER_REGNUM into STACK_POINTER_REGNUM. Also check CAN_DEBUG_WITHOUT_FP. [not making BP fixed] Can I do the same thing with SP? I don't know. The difficulty is somewhere between nontrivial and impossible. Don't try this at first. -- Rask Ingemann Lambertsen
RE: Reloading Problems and Memory Addressing
On 12 April 2006 06:48, Frank Riese wrote: Yes, you're right. When I started writing this backend I didn't have much experience with it. I took the smallest backend I could find and tried to adjust it to me needs. The number of macros in the internals docs was a bit overwhelming at first and GCC kept segfaulting on me - something I'm definately not used to from GCC. So, I was happy when I had something working to start with. But now I think it would have been cleaner to start from scratch. Or you could track down the segfaults to bugs in the modifications you've made; these are very often a sign that you've made a false assumption about what's in an rtx and as a consequence used the wrong kind of accessors (XINT, XEXP, etc) on it or its operands. Get used to the habit of adding lots of calls to print_rtl - under the control of a target flag, for preference! It is still easier to start with an existing backend that's similar to your target than to build one from complete scratch. #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \ if (REG_P (X)) \ goto LABEL; I tried that out today. I wasn't sure about the exact contexts in which this macro is used. [ I'll try and answer this, because I've just been studying this area of the compiler myself, and the revision will do me good. Please bear in mind that what I say is not authoritative as it's fairly new to me and so I may have some errors in the details, but the outline is right. EOE, caveat lector! ] It's used when gcc needs to form a (mem X) rtx and wants to know what kind of rtxen can be used (as the 'X') to represent the cpu's natural addressing modes as understood by the assembler. Whatever forms of rtx are accepted by G_I_L_A will be the forms of rtx passed to PRINT_OPERAND_ADDRESS when they crop up as the operands matched by the constraints in an insn pattern; when code generation matches some rtl with a bunch of operands against a define_insn pattern with operand constraints, it starts outputting the output template from the define insn and calls P_O_A with the relevant operand when it performs an operand substitution. So, e.g. if your CPU had register, register+offset, and immediate addressing modes, G_I_L_A would accept 1) a (reg ...) rtx 2) a (plus (reg ...) (const_int ...)) rtx and 3) a (const_int ...) rtx. Then, in P_O_A, you might use sprintf (STREAM, [r%d], REGNO(X)) if X had code REG, or sprintf (STREAM, [0x%x, r%d], INTVAL(XEXP(X, 1)), REGNO(XEXP(X, 0))); for the PLUS or just sprintf (STREAM, [0x%x], INTVAL(X)) for the CONST_INT that represents your immediate addressing mode. (Note that I might have the form of the (plus) rtx slightly wrong there w.r.t. insn canonicalisation and I'm not sure whether you might not also see any (minus) rtxen likewise). cheers, DaveK -- Can't think of a witty .sigline today
[gomp] EH problems with OpenMP
Hi, OpenMP is currently more or less unusable with the C++ front-end because of EH issues (see PR26823). This unfortunate situation is dragging on for more than two months now and makes further testing impossible. Some of the problems were fixed in PR26084, some still remain: The original (unreduced) testcase from PR26084 still causes an ICE. This is probably the same problem as in PR26823. We also have a third PR about an EH problem (PR26913) which has probably the same cause. Alas there seems to be no activity in that direction since PR26084 was closed. Could somebody of the gomp-maintainers please have a look? Thanks a lot in advance, Volker
Re: R_PPC_REL24 overflow
I suppose I should summarize what this problem was in case it's useful to anyone else searching the archives. A buggy cross-build process did not create libc.so. The static linker didn't find libc.so so it silently used libc.a instead. Libc.a is not built with -fPIC so the load problem showed up. Thanks for your comments. Jim. -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
Catching up on status reports
I'm behind on two RM duties: bug priorities and status reports. Fortunately, I'm not traveling this week, so I'll get caught up shortly. I just wanted to let everyone know that I'd not forgotten there's stuff to be done... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
[Ada] multilibbed implementation?
It's that time again... I just want to ask if there's any progress on Ada being multilibbed? -- Cheers, /ChJ
Question about gcc-lib and building on SPARC
Hello - this is definitely a newbie question, so bear with me... We've been using gcc under Solaris on SPARC hardware for some time now. The guy who was here before me set up the previous version (gcc-3.3.3) and now I'm trying to get gcc-3.4.4 to build. In the old gcc-3.3.3 install tree, I have the following directory: $prefix/lib/gcc-lib/sparc-sun-solaris2.9/3.3.3 gcc 3.3.3 was compiled with the following configure flags: [EMAIL PROTECTED] mark]$ gcc -v Reading specs from /cdl/apps/.software/sun/gcc-3.3.3/lib/gcc-lib/sparc-sun-solaris2.9/3.3.3/specs Configured with: configure --with-gnu-as --with-as=/cdl/apps/bin/sun/as --with-gnu-ld --with-ld=/cdl/apps/bin/sun/ld --enable-langauges=c,c++ --disable-shared --prefix=/cdl/apps/.software/sun/gcc-3.3.3 Thread model: posix gcc version 3.3.3 [EMAIL PROTECTED] mark]$ I've successfully built and installed gcc-3.4.4 with the following configure flags: [EMAIL PROTECTED] bin]$ ./gcc -v Reading specs from /cdl/apps/.software/sun/gcc-3.4.4/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.4/specs Configured with: /cdl/apps/.software/sun/build/gcc-3.4.4-build/gcc-3.4.4/configure --disable-shared --prefix=/cdl/apps/.software/sun/gcc-3.4.4/ --enable-languages=c,c++ Thread model: posix gcc version 3.4.4 [EMAIL PROTECTED] bin]$ However, in this case, I don't have the gcc-lib directory anymore. When I try to build stuff with this compiler (a simple helloworld), the linker returns symbol errors, likely because the Sun-supplied ld and not the GNU ld is being used (even though a GNU ld exists in my PATH) The obvious answer is that I didn't specify --with-gnu-ld and --with-ld=path in my gcc-3.4.4 configure. I would have done this, but our Developers need to use Purify Plus on Sun, and if I do this, it breaks Purify because it somehow uses it's own linker at buld time. The solution from Purify tech support was to go into $prefix/lib/gcc-lib/sparc-sun-solaris2.9/version and drop in symbolic links to the GNU ld and as. When I attempted to do this though, I realized this directory doesn't seem to exist under gcc-3.4.4 So, to make a painfully long story short, I need to know how gcc 3.4.4 decides upon which linker / assembler it uses. I read the configure instructions and found that when the compiler is built is uses a whole bunch of rules to find as and ld, and it seems apparent that I'm using the Sun ld and as instead of the GNU one. However, the old trick of putting symlinks in $prefix/lib/gcc-lib/sparc-sun-solaris2.9/version doesn't work anymore. Could someone please point a newbie in the right direction? Thanks in advance, Mark Mark Cuss, B. Sc. Software Developer Systems Administrator CDL Systems Ltd. Suite 220 3553 31 Street NW Calgary, AB, Canada T2L 2K7 Phone 403 289 1733 ext 226 Fax 403 289 3967 [EMAIL PROTECTED] www.cdlsystems.com
Problem in function in-lining
We had ported gcc-3.4.2 to our own RISC, and meet a strange
case in optimization level 3 (-O3).
The compiler produce wrong assembly code in O3 and
correct result if we add -fno-inline flag.
It seems that there some problem in function in-lining.
What can I do and what should I do to solve this problem ?
Source : xyz.c
...
... skip
...
#undef errno
int errno;
int _write (int fd, char *buf, int nbytes);
#ifdef REENTRANT_SYSCALLS_PROVIDED
volatile
int
_write_r (struct _reent *r, int fd, char *buf, int nbytes)
{
return _write(fd, buf, nbytes);
}
#endif
/*
* write -- write bytes to the serial port. Ignore fd, since
* stdout and stderr are the same. Since we have no filesystem,
* open will only return an error.
*/
int
_write (int fd, char *buf, int nbytes)
{
__asm__ volatile (li r8,2
:::r8);
SemiHostedSyscall ();
}
Assembly file genereated with O3 optimization
==
.text
.align2
.globl_write
.ent_write
_write:
.framer0,0,r3, 1# vars= 0, regs= 0,
args= 0, gp= 0
.mask0x,0
#APP
.set volatile
li r8,2
sdbbp 0xb
mv r4, r4
mv r5, r11
#NO_APP
.set optimize
swr5,errno
br!r3
.end_write
.align2
.globl_write_r
.ent_write_r
_write_r:
.framer0,0,r3, 1# vars= 0, regs= 0,
args= 0, gp= 0
.mask0x,0
#APP
.set volatile
li r8,2
sdbbp 0xb == inline function call _write with worng arguments
mv r4, r4
mv r5, r11
#NO_APP
.set optimize
swr5,errno
br!r3
.end_write_r
.commerrno,4,4
Assembly file genereated with O3 and -fno-inline flag
==
.text
.align2
.globl_write
.ent_write
_write:
.framer0,0,r3, 1# vars= 0, regs= 0,
args= 0, gp= 0
.mask0x,0
#APP
.set volatile
li r8,2
sdbbp 0xb
mv r4, r4
mv r5, r11
#NO_APP
.set optimize
swr5,errno
br!r3
.end_write
.align2
.globl_write_r
.ent_write_r
_write_r:
.framer0,0,r3, 1# vars= 0, regs= 0,
args= 0, gp= 0
.mask0x,0
mv! r4, r5
mv! r5, r6
mv! r6, r7
j_write
.end_write_r
.commerrno,4,4
Re: GCC Compiler Engineer job (I am not a recruiter)
Gerald Pfeifer wrote: On Mon, 10 Apr 2006, Mark Mitchell wrote: It seems like we're getting consensus around that approach, despite the initial sentiment in the other direction from Mike and Joe. Mike, Joe, do either of you care to argue the point? If not, I'll volunteer to write some text for the web pages, and ask Gerald to find a place to put it. http://gcc.gnu.org/lists.html probably would be the best place for such a note. I applied the following patch. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: lists.html === RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v retrieving revision 1.94 diff -c -5 -p -r1.94 lists.html *** lists.html 28 Oct 2005 19:58:26 - 1.94 --- lists.html 13 Apr 2006 05:46:06 - *** as well as in *** 38,47 --- 38,53 lipba href=http://gcc.gnu.org/ml/gcc/;gcc/a/b is a high volume list for general development discussions about GCC. Anything relevant to the development or testing of GCC and not covered by other mailing lists is suitable for discussion here./p + pRecruiting postings, including recruiting for GCC or other + free software jobs, are not permitted on this list, or on any of the + other GCC mailing lists. If you are interested in hiring a GCC + developer, please visit the a href=http://www.fsf.org/jobs;FSF + jobs page/a./p + pAll major decisions and changes, like abandoning ports or front ends, should be announced and discussed here. Ideally, this list should be sufficient to follow the major trends and important news in GCC's development process./p/li
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
-- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 07:11:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug middle-end/27095] [4.1/4.2 Regression] O2 produces duplicate code
--- Comment #3 from amodra at bigpond dot net dot au 2006-04-12 07:12 --- Testing a fix -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-04-09 21:49:06 |2006-04-12 07:12:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #2 from bonzini at gnu dot org 2006-04-12 07:30 --- And the funny part is, it is again Dale's patch that causes the failure. I'm more and more inclined to revert that part, but it may be a latent bug as in the AIX case (note: David Edelsohn decided to fix the bug by making sure the problematic RTL is not produced, but it still was an rs6000 latent bug in some sense). So, if Joern wants to take a look... -- bonzini at gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug c/27126] New: -Wswitch-enums doesn't detect impossible cases in switch()
Given:
int main(void)
{
enum foo { A, B, C, D} bar;
bar = D;
if(bar == A) {
;
} else if(bar == B) {
;
} else {
switch(bar) {
case C:
case D:
;
}
}
return 0;
}
barbeque/zarathustra:src: /usr/local/bin/gcc-4.1.0 -Wswitch-enum a.c
a.c: In function 'main':
a.c:10: warning: enumeration value 'A' not handled in switch
a.c:10: warning: enumeration value 'B' not handled in switch
A B aren't valid targets for the switch statement by the time it's hit as
they have been handled by the if statements above.
Locally built gcc:
barbeque/zarathustra:src: /usr/local/bin/gcc-4.1.0 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.0/configure --prefix=/usr/local/stow/gcc-4.1.0
--enable-languages=c,c++,objc --infodir=/usr/local/stow/gcc-4.1.0/share/info
--mandir=/usr/local/stow/gcc-4.1.0/share/man --enable-shared --enable-threads
--enable-tls --program-suffix=-4.1.0 --enable-__cxa_atexit
--enable-version-specific-runtime-libs
--enable-targets=x86_64-unknown-linux-gnu --enable-bootstrap=lean
--disable-biarch --disable-multilib
Thread model: posix
gcc version 4.1.0
On Debian/stable from amd64.debian.net.
Also happens on gcc 3.3.5 from the Debian apt archives.
--
Summary: -Wswitch-enums doesn't detect impossible cases in
switch()
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramune+gcc at net-ronin dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27126
[Bug java/27127] New: internal compiler error when compiling libjava with jc1
I'm trying to build gcc on solaris8 sparc. after the command below, Class.d is 0 bytes in size. I don't see any other temporary files left behind by -save-temps [EMAIL PROTECTED]:~/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava$ /export/home/rainer/gcc-3.4.6/gcc/gcj -v -save-temps -B/export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava/ -B/export/home/rainer/gcc-3.4.6/gcc/ --encoding=UTF-8 -Wno-deprecated -fclasspath= -fbootclasspath=/export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava -g -O2 -m64 -MD -MT java/lang/Class.lo -MF java/lang/Class.d -c ../../.././libjava/java/lang/Class.java -fPIC -o java/lang/.libs/Class.o Reading specs from /export/home/rainer/gcc-3.4.6/gcc/specs Reading specs from /export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava/libgcj.spec rename spec lib to liborig Configured with: ./configure --prefix=/usr/local/gcc-4.1.0 --program-suffix=4.1.0 --with-gnu-ld=/usr/local/bin/ld --with-gnu-as=/usr/local/bin/as Thread model: posix gcc version 3.4.6 /export/home/rainer/gcc-3.4.6/gcc/jc1 ../../.././libjava/java/lang/Class.java -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet -dumpbase Class.java -m64 -auxbase-strip java/lang/.libs/Class.o -g -O2 -Wno-deprecated -version -fencoding=UTF-8 -fclasspath= -fbootclasspath=/export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava -fPIC -MD_ -MT java/lang/Class.lo -MF java/lang/Class.d -o Class.s GNU Java version 3.4.6 (sparc-sun-solaris2.8) compiled by GNU C version 3.4.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Class path starts here: ./ /export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava/ (system) ../../.././libjava/java/lang/Class.java: In class `java.lang.Class': ../../.././libjava/java/lang/Class.java: In method `java.lang.Class.getDeclaredFields()': ../../.././libjava/java/lang/Class.java:85: internal compiler error: in size_binop, at fold-const.c:1601 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error when compiling libjava with jc1 Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainer-gccbugzilla at 7val dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27127
[Bug java/27127] internal compiler error when compiling libjava with jc1
--- Comment #1 from rainer-gccbugzilla at 7val dot com 2006-04-12 08:38 --- Created an attachment (id=11247) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11247action=view) Class.s, as built by gcj/jc1 before failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27127
[Bug java/27127] internal compiler error when compiling libjava with jc1
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-04-12 09:06 --- This is known to work, please make sure to read carefully the instructions at http://gcc.gnu.org/install/specific.html#x-x-solaris2 In particular, use the recommended config shell and do not build in the source directory. And --with-gnu-as=/usr/local/bin/as --with-gnu-ld=/usr/local/bin/ld is not the correct syntax, please see http://gcc.gnu.org/install/configure.html. Also make sure to bootstrap (gmake bootstrap) and not simply build the compiler. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27127
[Bug ada/18818] ACATS cd10002 fails at runtime
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-04-12 09:09 --- Presumably fixed everywhere. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
[Bug c++/27129] New: [4.1/4.2 Regression] ICE in get_expr_operands
static const float a = 0.299f;
static const float b = 0.114f;
static const float c = 1 - a - c;
float
foo (void)
{
return a + b + c;
}
ICEs at -O and higher. There is a typo (should have been 1 - a - b of course),
but IMHO that just triggers undefined behavior.
G++ 4.0.x would initialize c in __static_initialization_and_destruction_0(int,
int) and compile it without ICE, where foo would be return 0.413f + c;
In 4.1.0+, apparently c is initialized to error_mark_node, although no error
nor even a warning is emitted at compile time, and obviously various later
optimizers are upset when seeing error_mark_node on unexpected places,
errorneous
input is not supposed to reach that far ever.
--
Summary: [4.1/4.2 Regression] ICE in get_expr_operands
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug c/27130] New: wrong long long elementary computations
This is a completetest file: 10 lines are enough,
with only 3 lines of actual code
#include stdio.h
int main(void)
{
long long x;
long long y;
x=3;
y=5;
printf (%Ld %Ld %Ld %Ld \n,x,y,x+y,x-y);
return 0;
}
gives the obviously absurd output
0 3 0 5
adding inttypes.h make no difference
The gcc version is
gcc (GCC) 4.1.1 20060331 (prerelease)
Compiled form sources on a SUN Blade 1000 Solaris 9
with the only configure option
--enable-languages=c
below is the .i file:
# 1 longlong.c
# 1 interne
# 1 ligne de commande
# 1 longlong.c
# 1 /usr/include/stdio.h 1 3 4
# 20 /usr/include/stdio.h 3 4
#pragma ident @(#)stdio.h 1.7901/04/16 SMI
# 1 /usr/include/iso/stdio_iso.h 1 3 4
# 32 /usr/include/iso/stdio_iso.h 3 4
#pragma ident @(#)stdio_iso.h 1.2 99/10/25 SMI
# 1 /usr/include/sys/feature_tests.h 1 3 4
# 13 /usr/include/sys/feature_tests.h 3 4
#pragma ident @(#)feature_tests.h 1.1899/07/26 SMI
# 1 /usr/include/sys/isa_defs.h 1 3 4
# 9 /usr/include/sys/isa_defs.h 3 4
#pragma ident @(#)isa_defs.h 1.2099/05/04 SMI
# 16 /usr/include/sys/feature_tests.h 2 3 4
# 36 /usr/include/iso/stdio_iso.h 2 3 4
# 1 /usr/include/sys/va_list.h 1 3 4
# 9 /usr/include/sys/va_list.h 3 4
#pragma ident @(#)va_list.h1.1301/02/08 SMI
# 26 /usr/include/sys/va_list.h 3 4
typedef void *__va_list;
# 37 /usr/include/iso/stdio_iso.h 2 3 4
# 1 /usr/include/stdio_tag.h 1 3 4
# 9 /usr/include/stdio_tag.h 3 4
#pragma ident @(#)stdio_tag.h 1.3 98/04/20 SMI
# 21 /usr/include/stdio_tag.h 3 4
typedef struct __FILE __FILE;
# 38 /usr/include/iso/stdio_iso.h 2 3 4
# 1 /usr/include/stdio_impl.h 1 3 4
# 9 /usr/include/stdio_impl.h 3 4
#pragma ident @(#)stdio_impl.h 1.1301/11/16 SMI
# 22 /usr/include/stdio_impl.h 3 4
typedef int ssize_t;
# 38 /usr/include/stdio_impl.h 3 4
struct __FILE
{
ssize_t _cnt;
unsigned char *_ptr;
unsigned char *_base;
unsigned char _flag;
unsigned char _file;
unsigned __orientation:2;
unsigned __ionolock:1;
unsigned __seekable:1;
unsigned __filler:4;
};
# 39 /usr/include/iso/stdio_iso.h 2 3 4
# 59 /usr/include/iso/stdio_iso.h 3 4
typedef long long __longlong_t;
# 75 /usr/include/iso/stdio_iso.h 3 4
typedef __FILE FILE;
typedef unsigned int size_t;
typedef long fpos_t;
# 147 /usr/include/iso/stdio_iso.h 3 4
extern __FILE __iob[20];
# 164 /usr/include/iso/stdio_iso.h 3 4
extern int remove(const char *);
extern int rename(const char *, const char *);
extern FILE *tmpfile(void);
extern char *tmpnam(char *);
extern int fclose(FILE *);
extern int fflush(FILE *);
extern FILE *fopen(const char *, const char *);
extern FILE *freopen(const char *, const char *, FILE *);
extern void setbuf(FILE *, char *);
extern int setvbuf(FILE *, char *, int, size_t);
extern int fprintf(FILE *, const char *, ...);
extern int fscanf(FILE *, const char *, ...);
extern int printf(const char *, ...);
extern int scanf(const char *, ...);
extern int sprintf(char *, const char *, ...);
extern int sscanf(const char *, const char *, ...);
extern int vfprintf(FILE *, const char *, __va_list);
extern int vprintf(const char *, __va_list);
extern int vsprintf(char *, const char *, __va_list);
extern int fgetc(FILE *);
extern char *fgets(char *, int, FILE *);
extern int fputc(int, FILE *);
extern int fputs(const char *, FILE *);
extern int getc(FILE *);
extern int putc(int, FILE *);
extern int getchar(void);
extern int putchar(int);
extern char *gets(char *);
extern int puts(const char *);
extern int ungetc(int, FILE *);
extern size_t fread(void *, size_t, size_t, FILE *);
extern size_t fwrite(const void *, size_t, size_t, FILE *);
extern int fgetpos(FILE *, fpos_t *);
extern int fseek(FILE *, long, int);
extern int fsetpos(FILE *, const fpos_t *);
extern long ftell(FILE *);
extern void rewind(FILE *);
extern void clearerr(FILE *);
extern int feof(FILE *);
extern int ferror(FILE *);
extern void perror(const char *);
extern int __filbuf(FILE *);
extern int __flsbuf(int, FILE *);
# 23 /usr/include/stdio.h 2 3 4
# 91 /usr/include/stdio.h 3 4
typedef long off_t;
typedef __longlong_t off64_t;
# 109 /usr/include/stdio.h 3 4
typedef __longlong_t fpos64_t;
# 137 /usr/include/stdio.h 3 4
extern unsigned char _sibuf[], _sobuf[];
# 179 /usr/include/stdio.h 3 4
extern unsigned char *_bufendtab[];
extern FILE *_lastbuf;
# 215 /usr/include/stdio.h 3 4
extern void setbuffer(FILE *, char *, size_t);
extern int setlinebuf(FILE *);
extern int vfscanf(FILE *, const char *, __va_list);
extern int vscanf(const char *, __va_list);
extern int vsscanf(const char *, const char *, __va_list);
extern int snprintf(char *, size_t, const char *, ...);
extern int vsnprintf(char *, size_t, const char *, __va_list);
# 244 /usr/include/stdio.h 3 4
extern FILE *fdopen(int, const char *);
extern char *ctermid(char *);
extern int fileno(FILE *);
# 270 /usr/include/stdio.h 3 4
extern FILE *popen(const char *, const char *);
extern char *cuserid(char *);
extern char *tempnam(const
[Bug c/27130] wrong long long elementary computations
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 10:14 --- Use %lld, the L length modifier is for floating point formats to enable long double. -- 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=27130
[Bug c/27126] -Wswitch-enums doesn't detect impossible cases in switch()
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 10:17 --- Confirmed. But this is unlikely to be fixed as it would require moving the diagnostic to the middle-end where this information is available. And diagosticts from the middle-end are notoriously frowned upon. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||diagnostic Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2006-04-12 10:17:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27126
[Bug c++/27129] [4.1/4.2 Regression] ICE in get_expr_operands
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-04-12 11:17 --- Confirmed. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code, monitored Last reconfirmed|-00-00 00:00:00 |2006-04-12 11:17:02 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug c++/27115] [4.0/4.1/4.2 Regression] ICE in cp_expr_size or miscompilation
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-12 11:34
---
Confirmed.
Shorter testcase that crashes at -O0:
struct A
{
A (const A);
A operator= (const A);
};
void foo(A a)
{
A b = ({ a; });
}
bug.cc: In function 'void foo(A)':
bug.cc:9: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
Please submit a full bug report, [etc.]
The problem seems to be the statement-expression.
Just initializing A b = a; makes the ICE go away.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2006-04-12 11:34:16
date||
Target Milestone|4.0.4 |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #6 from jakub at gcc dot gnu dot org 2006-04-12 11:46 ---
It is a GC problem, when build_over_call calls mark_used, it certainly doesn't
expect mark_used to do a gcc_collect underneath it, as it has several tree
pointers stored in local variables. I guess build_over_call isn't the only
place that trusts mark_used doesn't do that, e.g. build_call,
build_op_delete_call, finish_eh_spec_block etc. likely suffer from the same
problem.
The call chain that leads to ggc_collect is mark_used -
{synthetize_method,instantiate_decl} - expand_or_defer_fn -
cgraph_finalize_function - ggc_collect.
So, either we change mark_used to never trigger GC from underneath us
(e.g. by function_depth++; synthetise_method (...); function_depth--; and
probably similarly for instantiate_decl), or we add an argument to mark_used
if it is ok to ggc_collect (similarly to cgraph_finalize_function's NESTED
argument), or we change all mark_used callers that might suffer from this
(either by adding function_depth++/function_depth-- around the call, or by
registering its temporaries with GC before calling mark_used).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at redhat dot com,
||mark at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug c++/27115] [4.0/4.1/4.2 Regression] ICE in cp_expr_size or miscompilation
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-04-12 12:11
---
Here's a shorter testcase for the wrong-code problem (using -O):
It should return 0, but returns something else since GCC 4.0.2.
The compiler crashes on this testcase with GCC 3.3 - 4.0.1.
=
struct A
{
int i;
A (int j) : i(j) {}
A (const A j) : i(j.i) {}
A operator= (const A j) { i = j.i; return *this; }
};
A foo(int j)
{
return ({ j ? A(1) : A(0); });
}
int main()
{
return foo(1).i-1;
}
=
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #33 from rakdver at gcc dot gnu dot org 2006-04-12 12:20 --- Created an attachment (id=11248) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248action=view) Patch to speed up update_ssa This patch makes update_ssa significantly faster in cases like this (when update_ssa is called often), by ensuring that we do not perform unnecessary expensive tasks (walking all statements or ssa names) each time update_ssa is called. Several more improvements are possible, especially in the phi insertion phase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug middle-end/27132] New: Fold does not canonicalize i - -1
Fold does not canonicalize i - -1 to i + 1 where allowed. It has /* A - B - A + (-B) if B is easily negatable. */ if (negate_expr_p (arg1) ((FLOAT_TYPE_P (type) /* Avoid this transformation if B is a positive REAL_CST. */ (TREE_CODE (arg1) != REAL_CST || REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1 || (INTEGRAL_TYPE_P (type) flag_wrapv !flag_trapv))) return fold_build2 (PLUS_EXPR, type, fold_convert (type, arg0), fold_convert (type, negate_expr (arg1))); but that doesn't trigger if !flag_wrapv. -- Summary: Fold does not canonicalize i - -1 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug bootstrap/27133] New: Fails to build because of funny version of makeinfo
This may actually be several distinct minor bugs. On my Sparc machine, I have what I think is a strang version of makeinfo, installed by TeX (or at least, in the tex tree) -- makeinfo --version returns: makeinfo (GNU texinfo 3.12) 1.68 This results in the compiler system (most specifically fastjar) failing to build. I will apply the obvious fix in my case -- install a correct version of makeinfo from sources. However... The makeinfo pages say that all GNU distributions should come with prebuilt info files, thus makeinfo should not be needed. If you notice a distribution that does not come with *.info files, please report it as a bug. Whence this bug report. Two possible improvements while I'm at it: there really could be an error message (or a warning) in configure, where you check the version, and (more a question) is there a simple way to build without building the documentation -- I've already got it from the Linux build anyway? -- Summary: Fails to build because of funny version of makeinfo Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkanze at cheuvreux dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug c++/27134] New: ICE when compiling vtk-5.0
When compiling vtk-5.0 with gcc-4.1.0 there occurs an ICE.. preprocessed sourcefile attached. -- Summary: ICE when compiling vtk-5.0 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: xtv at tveith dot homelinux dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27134
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 12:53 ---
Testcase:
/* { dg-do compile } */
/* { dg-options -fdump-tree-gimple } */
int foo(int i)
{
return i - -1;
}
/* { dg-final { scan-tree-dump i \\+ 1 gimple } } */
/* { dg-final { cleanup-tree-dump gimple } } */
I have a patch. But that conflicts with negate_expr_p - see
http://gcc.gnu.org/ml/gcc/2006-04/msg00063.html
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-04-12 12:53:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug c++/27134] ICE when compiling vtk-5.0
--- Comment #1 from xtv at tveith dot homelinux dot com 2006-04-12 12:54 --- Created an attachment (id=11249) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11249action=view) preprocessed source file preprocessed sourcefile compressed with gzip to meet the size requirements for submitting non-patches to bugzilla -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27134
[Bug c++/27135] New: parser.c:10895: warning: 'is_parenthesized_init' may be used uninitialized in this function
/home/dave/gnu/gcc-4.2/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./ prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -c -g -O2 -DIN_GC C -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definiti on -Wmissing-format-attribute -Werror -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Icp -I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../ gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/cp/parser.c -o cp/parser.o cc1: warnings being treated as errors ../../gcc/gcc/cp/parser.c: In function 'cp_parser_init_declarator': ../../gcc/gcc/cp/parser.c:10895: warning: 'is_parenthesized_init' may be used un initialized in this function make[3]: *** [cp/parser.o] Error 1 make[3]: Leaving directory `/home/dave/gnu/gcc-4.2/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/dave/gnu/gcc-4.2/objdir' make[1]: *** [stage2-bubble] Error 2 -- Summary: parser.c:10895: warning: 'is_parenthesized_init' may be used uninitialized in this function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27135
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-12 13:35 --- PASS: g++.old-deja/g++.mike/dyncast7.C (test for excess errors) FAIL: g++.old-deja/g++.mike/dyncast7.C execution test const Foo* and Foo* are really not compatible. We can just exchange Foo* for const Foo* for loads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-12 13:37 --- Created an attachment (id=11250) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11250action=view) updated patch Patch I will clean and test instead. Also fixes 27090. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #11227|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-12 13:46 --- sh64 has indexed addressing, but the addition is always done as 64 bit, and there are currently no implemenmtations that allow the 64 bit logical address space to be re-mapped into a 32 physical address space - instead they trap on any access to an address that does not fit into a 32 bit address space. This makes using indexed addressing with Pmode for -m5-32media (where Pmode is SImode) unsafe, since some optimizations can fold additions into indexed addressing and thus cause out-of-range addresses. Therefore, INDEX_REG_CLASS is NO_REGS for -m5-32media. The division code produces an address with a DImode plus of two registers - this is safe, since we exactly describe what the hardware does. However, find_reloads_address_1 sees a plus and recurses with CONTEXT set to 1, and then uses INDEX_REG_CLASS; it does not take into account that the mode is not Pmode. I think the best solution is to have an INDEX_REG_CLASS_FOR_MODE macro, which defaults to INDEX_REG_CLASS. Then this macro can be defined for the SH to return GENERAL_REGS for DImode when compiling SHmedia code. A kludgy solution would be to make reload reload the sum into a base register (to cover the general case), and make the SH LEGITIMIZE_RELOAD_ADDRESS recognize a sum with a non-pmode PLUS, and only reload pseudos inside into GENERAL_REGS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug c++/27129] [4.1/4.2 Regression] ICE in get_expr_operands
--- Comment #2 from prigault at oricom dot ca 2006-04-12 14:00 ---
IMO, the line defining c should trigger an error message because it needs to
use c before creating the variable, or else undefined behaviour occurs.
This message could be:
error: #8216;c#8217; was not declared in this scope
or:
error: 'c' is used uninitialized
Consider:
$ more test.cc
#include stdio.h
static const float f = 1 - a;
int main(void)
{
printf(%f\n, f);
return 0;
}
$ g++ -Wall -O2 -o test test.cc
test.cc:3: error: #8216;a#8217; was not declared in this scope
$ more test1.cc
#include stdio.h
static const float f = 1 - f;
int main(void)
{
printf(%f\n, f);
return 0;
}
$ g++ -Wall -O2 -o test1 test1.cc
$
There should be an error message there as well.
--
prigault at oricom dot ca changed:
What|Removed |Added
CC||prigault at oricom dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #34 from dnovillo at redhat dot com 2006-04-12 14:09 --- Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/06 08:20, rakdver at gcc dot gnu dot org wrote: -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248action=view) Patch to speed up update_ssa Fails building libgcc with checking disabled on x86. Starting program: /notnfs/dnovillo/BLD-gcc-native/gcc/cc1 -fpreprocessed libgcov.i -quiet -dumpbase libgcov.c -mtune=generic -auxbase-strip libgcc/./_gcov.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes - -Wmissing-prototypes -Wold-style-definition -version -fPIC -o libgcov.s Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xb000 GNU C version 4.2.0 20060412 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20060304 (Red Hat 4.1.0-3). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128991 Compiler executable checksum: 3c4ee7023c10209f81749c69d1323e23 Program received signal SIGSEGV, Segmentation fault. 0x0813d8f4 in bitmap_first_set_bit (a=0x86ec974) at /home/dnovillo/gcc/src/gcc/bitmap.c:595 595 bit_no = elt-indx * BITMAP_ELEMENT_ALL_BITS; (gdb) up #1 0x080da1da in set_livein_block (var=0xb7ce9034, bb=0xb7cc0d20) at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:486 486 int def_block_index = bitmap_first_set_bit (db_p-def_blocks); (gdb) up #2 0x080ddd3b in mark_use_interesting (var=0xb7ce9034, stmt=0xb7cd8f50, bb=0xb7cc0d20, blocks=0x86ec8c0, insert_phi_p=1 '\001') at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:1924 1924set_livein_block (var, bb); (gdb) #3 0x080dde71 in prepare_use_sites_for (name=0xb7ce9034, blocks=0x86ec8c0, insert_phi_p=1 '\001') at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:2045 2045 mark_use_interesting (name, stmt, bb, blocks, insert_phi_p); (gdb) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPQooUTa2oAUaiwQRAkAIAKCE4Sy7b0HCuZXv2M6a0OP0EBrQWgCgg5CT 7er5u0KdZhzL7y6sHsLVZts= =B10i -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2006-04-12 14:09 --- Subject: Re: [4.2 Regression] gcc fails to build on sh64-elf targets I think the best solution is to have an INDEX_REG_CLASS_FOR_MODE macro, which defaults to INDEX_REG_CLASS. Then this macro can be defined for the SH to return GENERAL_REGS for DImode when compiling SHmedia code. Thanks for the analysis. I quickly tested that your approach works for Kaz's testcase. However I don't feel confident enough to write this patch though -- and even less to document it. Are you going to do it, or should I go on and revert the regclass.c change? This is what I tested BTW: Index: reload.c === --- reload.c(revision 112658) +++ reload.c(working copy) @@ -5316,7 +5316,7 @@ find_reloads_address_1 (enum machine_mod RTX_CODE code = GET_CODE (x); if (context == 1) -context_reg_class = INDEX_REG_CLASS; +context_reg_class = GET_MODE (x) == DImode ? GENERAL_REGS : INDEX_REG_CLASS; else context_reg_class = base_reg_class (mode, outer_code, index_code); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #35 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-12 14:20 --- Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248action=view) Patch to speed up update_ssa Fails building libgcc with checking disabled on x86. forgot to say: mostly untested patch, still work in progress :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #36 from dnovillo at redhat dot com 2006-04-12 14:23 --- Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/06 10:20, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote: forgot to say: mostly untested patch, still work in progress :-) Oh, OK. I got the impression you were submitting it. I'll wait for your final version then. Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPQ1sUTa2oAUaiwQRApY5AJ4v+ve2Yl2mkv8+nMVSo0XvOBEF0wCeOLKr aojItQJu1BeKQcMIwzfLKSM= =5Ole -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug fortran/26834] gfc_todo: Not Implemented: Unable to determine rank of expression
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-12
14:32 ---
(In reply to comment #1)
Confirmed, PR 25669 and bug 18003 are very closely related (it might turn out
this is a dup of one of them).
They are indeed the same. Attached below is a patch that fixes all three and a
testcase that demonstrates that this is so. The patch is still testing but I
am pretty sure it is OK (ie. this is a path that ICEd previously). I will
submit tonight, if all is well.
Paul
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (révision 112853)
+++ gcc/fortran/trans-array.c (copie de travail)
@@ -2393,6 +2393,19 @@
loop-dimen = ss-data.info.dimen;
break;
+ /* Cope with the likes of PRINT *, lbound (a), where nothing
+ better is available. */
+ case GFC_SS_INTRINSIC:
+ switch (ss-expr-value.function.isym-generic_id)
+ {
+ case GFC_ISYM_LBOUND:
+ case GFC_ISYM_UBOUND:
+ loop-dimen = ss-data.info.dimen;
+
+ default:
+ break;
+ }
+
default:
break;
}
@@ -2418,6 +2431,15 @@
gfc_conv_section_startstride (loop, ss, n);
break;
+ case GFC_SS_INTRINSIC:
+ switch (ss-expr-value.function.isym-generic_id)
+ {
+ case GFC_ISYM_LBOUND:
+ case GFC_ISYM_UBOUND:
+ break;
+ default:
+ continue;
+ }
case GFC_SS_CONSTRUCTOR:
case GFC_SS_FUNCTION:
for (n = 0; n ss-data.info.dimen; n++)
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (révision 112853)
+++ gcc/fortran/trans-intrinsic.c (copie de travail)
@@ -3710,6 +3710,7 @@
newss-type = GFC_SS_INTRINSIC;
newss-expr = expr;
newss-next = ss;
+ newss-data.info.dimen = 1;
return newss;
}
! { dg-do compile }
! This tests the fix for PRs 26834, 25669 and 18803, in which
! shape information for the lbound and ubound intrinsics was not
! transferred to the scalarizer. For this reason, an ICE would
! ensue, whenever these functions were used in temporaries.
!
! The tests are lifted from the PRs and some further checks are
! done to make sure that nothing is broken.
!
! This is PR26834
subroutine gfcbug34 ()
implicit none
type t
integer, pointer :: i (:) = NULL ()
end type t
type(t), save :: gf
allocate (gf%i(20))
write(*,*) 'ubound:', ubound (gf% i)
write(*,*) 'lbound:', lbound (gf% i)
end subroutine gfcbug34
! This is PR25669
subroutine foo (a)
real a(*)
call bar (a, LBOUND(a),2)
end subroutine foo
subroutine bar (b, i, j)
real b(i:j)
print *, i, j
print *, b(i:j)
end subroutine bar
! This is PR18003
subroutine io_bug()
integer :: a(10)
print *, ubound(a)
end subroutine io_bug
! This checks that lbound and ubound are OK in temporary
! expressions.
subroutine io_bug_plus()
integer :: a(10, 10), b(2)
print *, ubound(a)*(/1,2/)
print *, (/1,2/)*ubound(a)
end subroutine io_bug_plus
character(4) :: ch(2), ech(2) = (/'ABCD', 'EFGH'/)
real(4) :: a(2)
equivalence (ech,a)
integer(1) :: i(8) = (/(j, j = 1,8)/)
! Check that the bugs have gone
call io_bug ()
call io_bug_plus ()
call foo ((/1.0,2.0,3.0/))
call gfcbug34 ()
! Check that we have not broken other intrinsics.
print *, cos ((/1.0,2.0/))
print *, transfer (a, ch)
print *, i(1:4) * transfer (a, i, 4) * 2
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26834
[Bug fortran/27124] Incorrect dependency for assignment from function with array section actual arg.
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-12
14:34 ---
I have a fix for it, which is regtesting right now. Even if it fails in this
form, it is along the right lines and there will be a version that is pukkah. I
hope to submit the patch tonight.
Quite simply, the fix consists of gathering up all the argument post_blocks,
which contain the unpacking and freeing of argument temporaries, and putting
them into a separate block. Once the function call is translated, it either
goes in the se-pre block or becomes the se expression, depending on how the
value is returned. Depending on this same choice, we now add the argument post
block to se-pre or to se-post. This ensures that the results of byref calls
that produce temporaries are transferred to the destination array AFTER the
unpacking of the argument. The reduced testcase below now runs correctly.
The patch and testcase appear below.
Paul
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(révision 112853)
+++ gcc/fortran/trans-expr.c(copie de travail)
@@ -1832,6 +1832,7 @@
gfc_charlen cl;
gfc_expr *e;
gfc_symbol *fsym;
+ stmtblock_t post;
arglist = NULL_TREE;
retargs = NULL_TREE;
@@ -1861,6 +1862,7 @@
else
info = NULL;
+ gfc_init_block (post);
gfc_init_interface_mapping (mapping);
need_interface_mapping = ((sym-ts.type == BT_CHARACTER
sym-ts.cl-length
@@ -1970,7 +1972,7 @@
gfc_add_interface_mapping (mapping, fsym, parmse);
gfc_add_block_to_block (se-pre, parmse.pre);
- gfc_add_block_to_block (se-post, parmse.post);
+ gfc_add_block_to_block (post, parmse.post);
/* Character strings are passed as two parameters, a length and a
pointer. */
@@ -2177,6 +2179,11 @@
}
}
+ if (byref)
+gfc_add_block_to_block (se-pre, post);
+ else
+gfc_add_block_to_block (se-post, post);
+
return has_alternate_specifier;
}
! { dg-do run }
! Tests the fix for PR27124 in which the unpacking of argument
! temporaries and of array result temporaries occurred in the
! incorrect order.
!
! Test is based on the original example, provided by
! Philippe Schaffnit [EMAIL PROTECTED]
!
PROGRAM Test
INTEGER :: Array(2, 3) = reshape ((/1,4,2,5,3,6/),(/2,3/))
integer :: Brray(2, 3) = 0
Brray(1,:) = Function_Test (Array(1,:))
if (any(reshape (Brray, (/6/)) .ne. (/11, 0, 12, 0, 13, 0/))) call abort ()
Array(1,:) = Function_Test (Array(1,:))
if (any(reshape (Array, (/6/)) .ne. (/11, 4, 12, 5, 13, 6/))) call abort ()
contains
FUNCTION Function_Test (Input)
INTEGER, INTENT(IN) :: Input(1:3)
INTEGER :: Function_Test(1:3)
Function_Test = Input + 10
END FUNCTION Function_Test
END PROGRAM Test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
[Bug middle-end/27134] [4.1/4.2 regression] ICE with floor and -ffast-math
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-12 14:59
---
Confirmed.
Reduced testcase (compile with -O -ffast-math):
==
double floor(double);
inline int bar(double x) { return (int)floor(x); }
int foo(int i) { return bar(i); }
==
bug.c: In function 'foo':
bug.c:3: internal compiler error: in get_callee_fndecl, at tree.c:5809
Please submit a full bug report, [etc.]
Happens with C and C++ frontend.
There seems to be something wrong with -ffast-math and floor.
Renaming floor to something else in the above testcase makes things
work again.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed|0 |1
Keywords||ice-on-valid-code, monitored
Last reconfirmed|-00-00 00:00:00 |2006-04-12 14:59:12
date||
Summary|ICE when compiling vtk-5.0 |[4.1/4.2 regression] ICE
||with floor and -ffast-math
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27134
[Bug fortran/27124] Incorrect dependency for assignment from function with array section actual arg.
--- Comment #3 from P dot Schaffnit at access dot rwth-aachen dot de
2006-04-12 15:02 ---
Subject: Re: Incorrect dependency for assignment from
functionwith array section actual arg.
Merci!
Philippe
paul dot richard dot thomas at cea dot fr wrote:
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-12
14:34 ---
I have a fix for it, which is regtesting right now. Even if it fails in this
form, it is along the right lines and there will be a version that is pukkah.
I
hope to submit the patch tonight.
Quite simply, the fix consists of gathering up all the argument post_blocks,
which contain the unpacking and freeing of argument temporaries, and putting
them into a separate block. Once the function call is translated, it either
goes in the se-pre block or becomes the se expression, depending on how the
value is returned. Depending on this same choice, we now add the argument
post
block to se-pre or to se-post. This ensures that the results of byref calls
that produce temporaries are transferred to the destination array AFTER the
unpacking of the argument. The reduced testcase below now runs correctly.
The patch and testcase appear below.
Paul
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(révision 112853)
+++ gcc/fortran/trans-expr.c(copie de travail)
@@ -1832,6 +1832,7 @@
gfc_charlen cl;
gfc_expr *e;
gfc_symbol *fsym;
+ stmtblock_t post;
arglist = NULL_TREE;
retargs = NULL_TREE;
@@ -1861,6 +1862,7 @@
else
info = NULL;
+ gfc_init_block (post);
gfc_init_interface_mapping (mapping);
need_interface_mapping = ((sym-ts.type == BT_CHARACTER
sym-ts.cl-length
@@ -1970,7 +1972,7 @@
gfc_add_interface_mapping (mapping, fsym, parmse);
gfc_add_block_to_block (se-pre, parmse.pre);
- gfc_add_block_to_block (se-post, parmse.post);
+ gfc_add_block_to_block (post, parmse.post);
/* Character strings are passed as two parameters, a length and a
pointer. */
@@ -2177,6 +2179,11 @@
}
}
+ if (byref)
+gfc_add_block_to_block (se-pre, post);
+ else
+gfc_add_block_to_block (se-post, post);
+
return has_alternate_specifier;
}
! { dg-do run }
! Tests the fix for PR27124 in which the unpacking of argument
! temporaries and of array result temporaries occurred in the
! incorrect order.
!
! Test is based on the original example, provided by
! Philippe Schaffnit [EMAIL PROTECTED]
!
PROGRAM Test
INTEGER :: Array(2, 3) = reshape ((/1,4,2,5,3,6/),(/2,3/))
integer :: Brray(2, 3) = 0
Brray(1,:) = Function_Test (Array(1,:))
if (any(reshape (Brray, (/6/)) .ne. (/11, 0, 12, 0, 13, 0/))) call abort
()
Array(1,:) = Function_Test (Array(1,:))
if (any(reshape (Array, (/6/)) .ne. (/11, 4, 12, 5, 13, 6/))) call abort
()
contains
FUNCTION Function_Test (Input)
INTEGER, INTENT(IN) :: Input(1:3)
INTEGER :: Function_Test(1:3)
Function_Test = Input + 10
END FUNCTION Function_Test
END PROGRAM Test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #28 from edmar at freescale dot com 2006-04-12 15:36 --- I double checked everything. The sources I checked out last night has the patches of comments 17, 21, and 25. This time I got a failure just like the on comment 7. The insn is the same The original attachment: floatformat.i, still good. I can reproduce the error with it. /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/powerpc-unknown-linux-gnuspe/libiberty /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/xgcc -B/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/ -B/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/bin/ -B/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/lib/ -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/include -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc-trunk/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../../gcc-trunk/libiberty/floatformat.c -o floatformat.o -v --save-temps Reading specs from /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/specs Target: powerpc-unknown-linux-gnuspe Configured with: ../gcc-trunk/configure --prefix=/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2 --with-local-prefix=/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2 --enable-languages=c,c++ --enable-threads --target=powerpc-unknown-linux-gnuspe --disable-shared --disable-multilib --disable-linux-futex --enable-e500_double Thread model: posix gcc version 4.2.0 20060411 (experimental) /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/cc1 -E -quiet -v -I. -I../../../gcc-trunk/libiberty/../include -iprefix /temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/ -isystem /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/include -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -DHAVE_CONFIG_H -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/include -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/sys-include ../../../gcc-trunk/libiberty/floatformat.c -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat -fworking-directory -O2 -O2 -fpch-preprocess -o floatformat.i ignoring nonexistent directory /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/include ignoring nonexistent directory /temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include ignoring nonexistent directory /temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/sys-include ignoring nonexistent directory /temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/include ignoring duplicate directory /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/sys-include ignoring nonexistent directory /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/include #include ... search starts here: #include ... search starts here: . ../../../gcc-trunk/libiberty/../include /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/include /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/sys-include /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include End of search list. /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/cc1 -fpreprocessed floatformat.i -quiet -dumpbase floatformat.c -auxbase-strip floatformat.o -g -O2 -O2 -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat -version -o floatformat.s GNU C version 4.2.0 20060411 (experimental) (powerpc-unknown-linux-gnuspe) compiled by GNU C version 3.4.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 46d139d3138e283288bcfc291691aee0 ../../../gcc-trunk/libiberty/floatformat.c: In function 'floatformat_to_double': ../../../gcc-trunk/libiberty/floatformat.c:415: error: unrecognizable insn: (insn 342 340 128 14 ../../../gcc-trunk/libiberty/floatformat.c:383 (set (reg:DF 11 11)
[Bug classpath/24481] SecureRandom.setSeed has no impact
--- Comment #10 from cvs-commit at developer dot classpath dot org 2006-04-12 16:39 --- Subject: Bug 24481 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Casey Marshall [EMAIL PROTECTED] 06/04/12 16:38:50 Modified files: . : ChangeLog gnu/java/security/jce/prng: SecureRandomAdapter.java gnu/java/security/prng: MDGenerator.java Log message: 2006-04-12 Casey Marshall [EMAIL PROTECTED] Fixes PR classpath/24481. * gnu/java/security/jce/prng/SecureRandomAdapter.java (init): initialize the adaptee. (setSeed): call `addRandomBytes;' don't re-initialize the adaptee. * gnu/java/security/prng/MDGenerator.java (addRandomByte, addRandomBytes): new methods. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.7086tr2=1.7087r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/java/security/jce/prng/SecureRandomAdapter.java.diff?tr1=1.1tr2=1.2r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/java/security/prng/MDGenerator.java.diff?tr1=1.2tr2=1.3r1=textr2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
[Bug rtl-optimization/26961] [4.0/4.1/4.2 Regression] ICE simplify_subreg:3813
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-04-12 17:24
---
Even shorter testcase:
===
int foo(int i, int j)
{
return i ? (long long)(!j) : 0;
}
===
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
[Bug c/27136] New: Compile failure with -O -ffast-math
This program, compiled -O -ffast-math, seems to consume infinite stack space
/* -O -ffast-math */
void foo()
{
double x;
for (x = 2; x 10; x *= x)
;
}
--
Summary: Compile failure with -O -ffast-math
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-12 17:34 --- Yes I already filed a couple bugs about turning this on for the !flag_wrapv case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug java/27101] GCJ rejects valid code (for Sun's measure of valid')
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-12 17:38 --- I thought this looked like a dup, but I can't find the original. In any case, ISTR looking at the logic here in gcj at one point, and finding that it was all screwed up. Pinski: you can do: sed 's/^.//d' File.java and then cut and paste... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-12 17:39 --- You need to fix PR 25148 first before fixing this bug really otherwise you will get a testsuite failure as I got before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25148 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-12 17:40 --- (In reply to comment #9) PASS: g++.old-deja/g++.mike/dyncast7.C (test for excess errors) FAIL: g++.old-deja/g++.mike/dyncast7.C execution test I did not get that failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug java/13021] GCJ Boehm descriptor may be incorrect if alignment != sizeof(void*)
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-12 17:42 --- I don't have a convenient way to test a fix for this. But it does not look very hard to fix... just adding an extra check in boehm.c:mark_reference_fields. Note that the corresponding code in libgcj already seems to handle this case: // If we run into a weird situation, we bail. if (off % sizeof (void *) != 0) return (void *) (GCJ_DEFAULT_DESCR); -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13021
[Bug middle-end/27134] [4.1/4.2 regression] ICE with floor and -ffast-math
--- Comment #3 from uros at kss-loka dot si 2006-04-12 17:54 --- There seems to be something wrong with -ffast-math and floor. I have done some analysis on this. Start from expand_builtin_int_roundingfn() in builtins.c source, where we fallback to FP rounding optab. fallback_fndecl from mathfn_builtin looks like: function_decl 0x2d992200 __builtin_floor type function_type 0x2d9756e0 type real_type 0x2d970420 double DF size integer_cst 0x2d951d80 constant invariant 64 unit size integer_cst 0x2d951db0 constant invariant 8 align 64 symtab 0 alias set -1 precision 64 pointer_to_this pointer_type 0x2d970630 QI size integer_cst 0x2d9517e0 constant invariant 8 unit size integer_cst 0x2d951810 constant invariant 1 align 8 symtab 0 alias set -1 arg-types tree_list 0x2d9740f0 value real_type 0x2d970420 double chain tree_list 0x2d96be10 value void_type 0x2d9700b0 void pointer_to_this pointer_type 0x2dabad10 readonly used nothrow public external built-in decl_6 QI file built-in line 0 built-in BUILT_IN_NORMAL:BUILT_IN_FLOOR attributes tree_list 0x2d9918d0 (mem:QI (symbol_ref:DI (floor) [flags 0x41] function_decl 0x2d992200 __builtin_floor) [0 S1 A8]) chain function_decl 0x2d992300 floor After that, build_function_call_expr() is called, with an argument list: tree_list 0x2dabf180 value float_expr 0x2d95b240 type real_type 0x2d970420 double DF size integer_cst 0x2d951d80 constant invariant 64 unit size integer_cst 0x2d951db0 constant invariant 8 align 64 symtab 0 alias set -1 precision 64 pointer_to_this pointer_type 0x2d970630 arg 0 parm_decl 0x2d958780 i type integer_type 0x2d9604d0 int used SI file pr27134.c line 5 size integer_cst 0x2d951bd0 constant invariant 32 unit size integer_cst 0x2d9516f0 constant invariant 4 align 32 context function_decl 0x2daa1600 foo initial integer_type 0x2d9604d0 int (reg/v:SI 59 [ i ]) arg-type integer_type 0x2d9604d0 int This is simplified in fold_build3() to: nop_expr 0x2dac5300 type real_type 0x2d970420 double DF size integer_cst 0x2d951d80 constant invariant 64 unit size integer_cst 0x2d951db0 constant invariant 8 align 64 symtab 0 alias set -1 precision 64 pointer_to_this pointer_type 0x2d970630 arg 0 float_expr 0x2d95b240 type real_type 0x2d970420 double arg 0 parm_decl 0x2d958780 i type integer_type 0x2d9604d0 int used SI file pr27134.c line 5 size integer_cst 0x2d951bd0 constant invariant 32 unit size integer_cst 0x2d9516f0 constant invariant 4 align 32 context function_decl 0x2daa1600 foo initial integer_type 0x2d9604d0 int (reg/v:SI 59 [ i ]) arg-type integer_type 0x2d9604d0 int incoming-rtl (reg:SI 5 di [ i ]) It looks to me, that fold_convert3() is trying to kill (int) __builtin_lfloor ((double) i), where i is an integer argument. Uros. -- uros at kss-loka dot si changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-12 14:59:12 |2006-04-12 17:54:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27134
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-12 18:06 --- This is basicially PR 23295. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23295 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug middle-end/23295] fold does not simplify -a - (5) to (-5) - a
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-12 18:10 --- Didn't we have the canonicalization to put the constant in operand2 if possible? A lot of transformations rely on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
[Bug bootstrap/27133] Fails to build because of funny version of makeinfo
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 18:18 --- Are you building from a release version, correct? Otherwise you do need makeinfo as explained by: http://gcc.gnu.org/install/prerequisites.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug classpath/24481] SecureRandom.setSeed has no impact
--- Comment #11 from csm at gnu dot org 2006-04-12 18:19 --- Fixed for message digest-based PRNGs. -- csm at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |0.91 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
[Bug bootstrap/27135] [4.2 Regression] parser.c:10895: warning: 'is_parenthesized_init' may be used uninitialized in this function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 18:20 --- Fixed by: http://gcc.gnu.org/ml/gcc-cvs/2006-04/msg00302.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |bootstrap Resolution||FIXED Summary|parser.c:10895: warning:|[4.2 Regression] |'is_parenthesized_init' may |parser.c:10895: warning: |be used uninitialized in|'is_parenthesized_init' may |this function |be used uninitialized in ||this function Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27135
[Bug tree-optimization/24609] [4.1/4.2 regression] Same value duplicated in two different registers
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug libgcj/27066] libgcj native socket code does not support IPv6
--- Comment #5 from cjw at daneel dot dyndns dot org 2006-04-12 19:08 --- There are probably disadvantages: it doesn't seem possible to bind to 127.0.0.1 this way. So choosing the socket domain that matches the address to bind/connect to is probably a good idea. I thought other java implementations use the IPv4-in-IPv6 system but now I'm not so sure about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
[Bug preprocessor/27137] New: Without -I- gcc needs another way to defer source dir. search
The -I option inhibits the use of the current file directory as the first search directory for #include file. This is important for software development which uses partially populated source trees for which the build looks through other trees to find the missing pieces. Without -I- gcc should offer something like the IBM xlc -qidirfirst option: Specifies the search order for files included with the '#include' file_name directive. Use -qidirfirst with the -I option. If -qidirfirst is specified, the directories specified by the -Idirectory option are searched before the directory where the current file resides. The default is -qnoidirfirst. This is all we need, but over the last 10 years we have instead pushed vendors to support the -I- option. It is sadly ironic that gcc deprecates it. My employer does not use `nmake', but `nmake' has noticed this too: http://www.bell-labs.com/project/nmake/newsletters/issue021.html -- Summary: Without -I- gcc needs another way to defer source dir. search Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trt at acm dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
[Bug fortran/25597] ICE with allocate on the return value of a function, character array with a len of an argument
--- Comment #7 from patchapp at dberlin dot org 2006-04-12 19:28 --- Subject: Bug number PR25597 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/2006-04/msg00350.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25597
[Bug fortran/27124] Incorrect dependency for assignment from function with array section actual arg.
--- Comment #4 from patchapp at dberlin dot org 2006-04-12 19:30 --- Subject: Bug number PR27124 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/2006-04/msg00468.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
[Bug fortran/26834] gfc_todo: Not Implemented: Unable to determine rank of expression
--- Comment #3 from patchapp at dberlin dot org 2006-04-12 19:55 --- Subject: Bug number PR26834 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/2006-04/msg00469.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26834
[Bug libgcj/23829] FreeBSD 5 support for libjava
--- Comment #7 from gerald at gcc dot gnu dot org 2006-04-12 19:57 --- Subject: Bug 23829 Author: gerald Date: Wed Apr 12 19:57:02 2006 New Revision: 112897 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112897 Log: PR libgcj/23829 * configure.ac: Link against -lpthread rather than -lc_r on FreeBSD 5 and above. * configure: Regenerate. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug libgcj/23829] FreeBSD 5 support for libjava
--- Comment #8 from gerald at pfeifer dot com 2006-04-12 19:59 --- I committed this to HEAD and the 4.1-branch now. Thanks to everyone who helped review this, and of course the original submitter! -- gerald at pfeifer dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-04-12 19:59 --- Created an attachment (id=11251) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11251action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug libgomp/25938] [4.2 regression] libgomp installs header files in version and target independent location
--- Comment #7 from gerald at pfeifer dot com 2006-04-12 20:01 --- RTH, Jakub, would you mind having a look at this regression? -- gerald at pfeifer dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25938
[Bug target/27060] divide libcall size has increased
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-04-12 20:09 --- Subject: Bug 27060 Author: amylaar Date: Wed Apr 12 20:09:41 2006 New Revision: 112898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112898 Log: 2006-04-12 Jorn Rennecke [EMAIL PROTECTED] PR target/27060 * config/sh/lib1funcs.h: New file, broken out of: * config/sh/lib1funcs.asm. * config/sh/lib1funcs.h (DR00, DR01, DR20, DR21, DR40, DR41): New macros. * config/sh/lib1funcs.asm (udivsi3_i4): Use them. * config/sh/lib1funcs-Os-4-200.asm: New file. * config/sh/embed-elf.h (LIBGCC_SPEC): Use -lgcc-Os-4-200. * config/sh/t-sh (OPT_EXTRA_PARTS): New variable. (EXTRA_MULTILIB_PARTS): Include it. ($(T)sdivsi3_i4i-Os-4-200.o): New rule. ($(T)udivsi3_i4i-Os-4-200.o, $(T)libgcc-Os-4-200.a): Likewise. * config/sh/t-superh (EXTRA_MULTILIB_PARTS): Include OPT_EXTRA_PARTS. * config/sh/sh.h (OVERRIDE_OPTIONS): Recognize -mdiv=call-table for TARGET_SH2. Added: trunk/gcc/config/sh/lib1funcs-Os-4-200.asm trunk/gcc/config/sh/lib1funcs.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/embed-elf.h trunk/gcc/config/sh/lib1funcs.asm trunk/gcc/config/sh/sh.h trunk/gcc/config/sh/t-sh trunk/gcc/config/sh/t-superh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27060
[Bug crypto/27111] SecureRandom isn't seeded on creation
--- Comment #3 from csm at gnu dot org 2006-04-12 20:17 --- *** This bug has been marked as a duplicate of 24642 *** -- csm at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27111
[Bug classpath/24642] Failure to produce random values.
--- Comment #3 from csm at gnu dot org 2006-04-12 20:17 --- *** Bug 27111 has been marked as a duplicate of this bug. *** -- csm at gnu dot org changed: What|Removed |Added CC||csm at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24642
[Bug preprocessor/27137] Without -I- gcc needs another way to defer source dir. search
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 20:18 --- What do you need exactly that -iquote or any of the -i* options provide? Or even what this patch should provide: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html That adds an option to do what exactly -I- did except for not change the behavior of -I* after -I-. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
[Bug classpath/24642] Failure to produce random values.
--- Comment #4 from csm at gnu dot org 2006-04-12 20:18 --- Testing a patch. -- csm at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |csm at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24642
[Bug preprocessor/19541] deprecation of -I- makes precompiled headers less usable
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-12 20:19 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg01197.html Status|UNCONFIRMED |NEW Component|pch |preprocessor Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-04-12 20:19:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
[Bug preprocessor/27137] Without -I- gcc needs another way to defer source dir. search
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-12 20:19 --- If that patch does the trick for you, then this is a dup of bug 19541. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
[Bug fortran/27138] New: gfortran: Fails to
-- Summary: gfortran: Fails to Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug fortran/27138] gfortran: Fails to
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-04-12 20:45 --- Created an attachment (id=11252) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11252action=view) test.tar.gz containing inp-test and test.F This is SUSE's gcc-fortran-4.1.0-15, Merge[d] up to rev 112748 for gfortran changes on the branch. The attached program test.F reads an inputfile (also attached), which contains three lines: 1| igrd=1,lwb=F,ndvgrd=6,idsprs=0,chng=-0.100D-11 2| 3| 12 This file is read by three READ (5,*,END=n,ERR=n) ntype lines. With Ifort, the first READ has an error and the second read gets the 12. With gfortran, all three reads get an error. Expected: Either the second or the third read picks up the 12. The attached program prints with the Intel Fortran Compiler 9.0.033: Second read: ntype = 12 whereas with gfortran it only shows: Error glancing at inp-file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug middle-end/27139] New: Optimize double INT-FP-INT conversions
This testcase:
int test (int a)
{
return (double) a;
}
Produces:
cvtsi2sd%edi, %xmm0
cvttsd2si %xmm0, %eax
ret
However, following code does the same (at least for -ffast-math):
movl%edi, %eax
ret
--
Summary: Optimize double INT-FP-INT conversions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27139
[Bug fortran/25619] temporary array of constant size character type goes wrong
--- Comment #8 from hjl at gcc dot gnu dot org 2006-04-12 20:58 --- Subject: Bug 25619 Author: hjl Date: Wed Apr 12 20:58:04 2006 New Revision: 112899 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112899 Log: gcc/fortran/ 2006-04-12 H.J. Lu [EMAIL PROTECTED] PR fortran/25619 Backport from mainline 2006-04-04 H.J. Lu [EMAIL PROTECTED] * trans-array.c (gfc_conv_expr_descriptor): Only dereference character pointer when copying temporary. PR fortran/23634 Backport from mainline 2006-04-04 H.J. Lu [EMAIL PROTECTED] * trans-array.c (gfc_conv_expr_descriptor): Properly copy temporary character with non constant size. gcc/testsuite/ 2006-04-12 H.J. Lu [EMAIL PROTECTED] PR fortran/23634 PR fortran/25619 Backport from mainline 2006-04-04 Paul Thomas [EMAIL PROTECTED] * gfortran.dg/actual_array_constructor_1.f90: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25619
[Bug fortran/23634] temporary array of character ICE with non constant size
--- Comment #8 from hjl at gcc dot gnu dot org 2006-04-12 20:58 --- Subject: Bug 23634 Author: hjl Date: Wed Apr 12 20:58:04 2006 New Revision: 112899 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112899 Log: gcc/fortran/ 2006-04-12 H.J. Lu [EMAIL PROTECTED] PR fortran/25619 Backport from mainline 2006-04-04 H.J. Lu [EMAIL PROTECTED] * trans-array.c (gfc_conv_expr_descriptor): Only dereference character pointer when copying temporary. PR fortran/23634 Backport from mainline 2006-04-04 H.J. Lu [EMAIL PROTECTED] * trans-array.c (gfc_conv_expr_descriptor): Properly copy temporary character with non constant size. gcc/testsuite/ 2006-04-12 H.J. Lu [EMAIL PROTECTED] PR fortran/23634 PR fortran/25619 Backport from mainline 2006-04-04 Paul Thomas [EMAIL PROTECTED] * gfortran.dg/actual_array_constructor_1.f90: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23634
[Bug fortran/27138] gfortran: read(*,*) myInt advances only one character on error
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-12 21:05 ---
If one replaces the third read by
character(len=300) :: str
READ (5,*,END=100,ERR=99) str
WRITE(*,*) trim(str)
one sees that the first two failing READs advance by one character each
('i','g').
The third (string) read then reads up to the comma ('td=1')
I would expect (as well as the program writer) that after the failed read one
is still in the next line (as ADVANCE=YES is implied).
Why the read(5,*) str only reads up to the comma and not the whole line, is
also an enigma for me.
G95 (GCC 4.0.3 (g95!) Apr 4 2006,
pgf95 6.0-5
PathScale EKOPath Version 2.1
(and as mentioned) Intel Fortran Compiler 9.0.033
all read the 12 with the second read.
--
tobias dot burnus at physik dot fu-berlin dot de changed:
What|Removed |Added
Summary|gfortran: Fails to |gfortran: read(*,*) myInt
||advances only one character
||on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding
--- Comment #12 from steven at gcc dot gnu dot org 2006-04-12 21:28 --- fold_truthop is called with this input: Breakpoint 11, fold_truthop (code=TRUTH_ANDIF_EXPR, truth_type=0x2adff4d0, lhs=0x2adf64b0, rhs=0x2adf6690) at fold-const.c:4820 4820 if (TREE_SIDE_EFFECTS (lhs) || TREE_SIDE_EFFECTS (rhs)) (gdb) p debug_generic_expr(lhs) (intD.0) wordD.1878 1 $50 = void (gdb) p debug_generic_expr(rhs) ((intD.0) wordD.1878 08000) == 32768 $51 = void (gdb) And it folds this input to 0, which is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #6 from kkojima at gcc dot gnu dot org 2006-04-12 21:43 --- -#define INDEX_REG_CLASS \ - (!ALLOW_INDEXED_ADDRESS ? NO_REGS : TARGET_SHMEDIA ? GENERAL_REGS : R0_REGS) +#define INDEX_REG_CLASS_FOR_MODE(MODE) \ + ((MODE) == DImode TARGET_SHMEDIA ? 1 \ Should this last 1 be GENERAL_REGS? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #18 from wilson at gcc dot gnu dot org 2006-04-12 22:10 --- Subject: Bug 26483 Author: wilson Date: Wed Apr 12 22:10:49 2006 New Revision: 112900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112900 Log: Fix IA-64 problems with denorms getting clobbered by type conversions. PR libgcj/26483 * src/ia64/ffi.c (stf_spill, ldf_fill): Rewrite as macros. (hfa_type_load): Call stf_spill. (hfa_type_store): Call ldf_fill. (ffi_call): Adjust calls to above routines. Add local temps for macro result. Modified: trunk/libffi/ChangeLog trunk/libffi/src/ia64/ffi.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #19 from wilson at gcc dot gnu dot org 2006-04-12 22:21 --- IA-64. Mine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 22:21:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #20 from wilson at gcc dot gnu dot org 2006-04-12 22:22 --- Fixed on mainline. Testcase added to mainline. The fix should probably be backported to one or more active release branches. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC|wilson at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug middle-end/26823] ICE with OpenMP in add_stmt_to_eh_region_fn, at tree-eh.c:100
--- Comment #2 from giovannibajo at libero dot it 2006-04-12 22:25 --- RTH, this bug is very serious for OpenMP and C++. Can you please have a look? -- giovannibajo at libero dot it changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 22:41:46 date|| Summary|Some OpenMP semantics are |[4.2 Regression] Some OpenMP |caught too late (in the |semantics are caught too |gimplifier) |late (in the gimplifier) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751
[Bug middle-end/27139] Optimize double INT-FP-INT conversions with -ffast-math
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 23:59 --- Confirmed, I doubt this shows up that much anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|x86_64-unknown-linux-gnu| Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-04-12 23:59:25 date|| Summary|Optimize double INT-FP-INT|Optimize double INT-FP-INT |conversions |conversions with -ffast-math http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27139
[Bug fortran/27138] gfortran: read(*,*) myInt advances only one character on error
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-04-13 00:22 --- I will investigate. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-13 00:22:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-13 00:54 --- It has to be the: /* See if the comparisons can be merged. Then get all the parameters for each side. */ which gets it wrong for some reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug middle-end/23295] fold does not simplify -a - (5) to (-5) - a
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-13 01:01 --- (In reply to comment #7) Didn't we have the canonicalization to put the constant in operand2 if possible? A lot of transformations rely on that. Why should they in this case, they only rely on that for operations that are comunitive and minus is not. (-5) - a is simplier than -a - 5 in reality. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
[Bug target/26961] [4.0/4.1/4.2 Regression] ICE simplify_subreg:3813
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-13 01:05 --- the TRUTH_AND_EXPR is long long here and we produce an ICE while expanding to RTL so this is a middle-end issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
[Bug c++/27115] [4.0/4.1/4.2 Regression] ICE in cp_expr_size or miscompilation with statement expressions and constructors (and ?: )
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-13 01:17 --- for the orginal expample: 3.3.3 ICE 3.4.0 worked 3.2.2 ICE 3.0.4 ICE 2.95.3 ICE I don't think we should call this critical as this is using an extension in the first place and it only ICEs with the extension in fact. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1/4.2 Regression] ICE |in cp_expr_size or |in cp_expr_size or |miscompilation with |miscompilation with |statement expressions and |statement expressions and |constructors|constructors (and ?: ) Target Milestone|4.1.1 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug c/27126] -Wswitch-enums doesn't detect impossible cases in switch()
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 01:27 --- *** This bug has been marked as a duplicate of 23577 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27126
[Bug c/23577] suprious warnings about unhanled cases in switches
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 01:27 --- *** Bug 27126 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ramune+gcc at net-ronin dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23577
[Bug middle-end/27136] [4.0/4.1/4.2 Regression] Compile failure with -O -ffast-math
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-13 01:37 --- Confirmed. -- pinskia 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.0.0 4.1.0 4.2.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2006-04-13 01:37:35 date|| Summary|Compile failure with -O - |[4.0/4.1/4.2 Regression] |ffast-math |Compile failure with -O - ||ffast-math Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
