[Bug target/24476] [4.1/4.2 Regression] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA64
--- Comment #2 from uros at kss-loka dot si 2005-11-24 08:09 --- The testsuite patch that fixes IA32 tests (and should also fix IA64 issues reported here) is at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01059.html. Patch is still waiting for review, however I can't test it on IA64. -- uros at kss-loka dot si changed: What|Removed |Added BugsThisDependsOn||24475 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24476
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #14 from jakub at gcc dot gnu dot org 2005-11-24 08:36 --- Comment #7 seems to suggest that (even just --enable-languages=c,fortran). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug tree-optimization/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
--- Comment #9 from amodra at bigpond dot net dot au 2005-11-24 08:59 --- Indeed it's not a stack slot. Instead, reg 1824 is an invariant, equal to sfp+16512. Code in reload1.c:eliminate_regs_1 substitutes r1 for sfp, then reorganises the order of the additions, so we get (r1+r11)+const not (r1+const)+r11. This of course isn't a valid address on powerpc, where indexed addresses can't take an offset. In case it isn't obvious, I'm a little lost. Hopefully my analysis will let someone more familiar with reload sort this out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-24 09:01 --- Subject: Re: Bootstrap: Failure to build doc/gcc.info pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #4) | still does not work with bubblestrap and friends | | After a clean build? YES. | See http://gcc.gnu.org/ml/gcc/2005-11/msg01173.html That does not solve the problem. I did not experience that before. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-24 09:03 --- Subject: Re: Bootstrap: Failure to build doc/gcc.info pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #3) | Subject: Re: Bootstrap: Failure to build doc/gcc.info | pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | | Actually this is invalid, you need to build with a clean object directory. | That is bullshit. what about bubblestrap and the like? | | well are you bubblestrapping in the gcc directory of the objdir or the toplevel | directory, if the latter, maybe just maybe this is a bug. the gcc directory of the builddir. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug java/25001] dos equis
--- Comment #2 from rmathew at gcc dot gnu dot org 2005-11-24 09:33 --- Confirmed on mainline. Also confirmed that GCJX does not have this bug. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-24 09:33:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25001
[Bug c++/9278] Illegal use of typedef to void
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg01734.html Status|NEW |ASSIGNED Keywords||monitored, patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278
[Bug rtl-optimization/24995] [4.1/4.2 Regression] gcc.dg/vect/vect-10.c fails for -march=athlon
--- Comment #2 from uros at kss-loka dot si 2005-11-24 10:19 --- This also fails for i686-pc-linux-gnu with '-march=athlon'. The patch at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01648.html fixes i86_64-pc-linux-gnu failure in original report and -march=athlon failure. FWIW, -fomit-frame-pointer also fixes these failures. This PR is a duplicate of 24982. *** This bug has been marked as a duplicate of 24982 *** -- uros at kss-loka dot si changed: What|Removed |Added Status|NEW |RESOLVED GCC target triplet|x86_64-linux-gnu|i686-pc-linux-gnu Resolution||DUPLICATE Summary|[4.1/4.2 Regression]|[4.1/4.2 Regression] |gcc.dg/vect/vect-10.c fails |gcc.dg/vect/vect-10.c fails |on x86_64 with -m32 |for -march=athlon http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24995
[Bug target/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p
--- Comment #5 from uros at kss-loka dot si 2005-11-24 10:19 --- *** Bug 24995 has been marked as a duplicate of this bug. *** -- uros at kss-loka dot si changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Bug 24982 depends on bug 24995, which changed state. Bug 24995 Summary: [4.1/4.2 Regression] gcc.dg/vect/vect-10.c fails for -march=athlon http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24995 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
[Bug tree-optimization/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
--- Comment #10 from amodra at bigpond dot net dot au 2005-11-24 10:21 --- I think I've sorted this out after all.. 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|2005-11-23 16:06:14 |2005-11-24 10:21:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug rtl-optimization/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p
--- Comment #6 from uros at kss-loka dot si 2005-11-24 10:24 --- (In reply to comment #4) I've proposed a patch to this PR in http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01648.html Does it solve PR 24995? Yes, both i86_64 and -march=athlon failures. -- uros at kss-loka dot si changed: What|Removed |Added CC||rth at gcc dot gnu dot org BugsThisDependsOn|24995 | URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg01648.html Status|UNCONFIRMED |NEW Component|target |rtl-optimization Ever Confirmed|0 |1 GCC host triplet|sh4-*-linux-gnu | GCC target triplet|sh4-*-linux-gnu | Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-11-24 10:24:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
[Bug c++/25014] New: seems to be a bug in optimization on sparc systems.
The following bug occurs only if -O (or higher optimization) is switched on.
I did not find out which of the single optimization switches is responsible for
it. The complete if statement is true, although none of each boolean value is
true. If I replace the enum variable Type by an int, the code works correct
even with optimization. Please let me know if this bug is already known or even
fixed.
Compiler:
../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.4.1
System (uname -a)
SunOS sun2 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Blade-1500
//gcc -O enumtest.cpp(has the bug)
//gcc -Oenumtest.cpp -lsupc++ (has the bug)
//or: gccenumtest.cpp -lsupc++ (is correct)
//output is(if used -O ):
//inside
//done
//output is(if not used -O ):
//done
//(as I expect)
#include stdio.h
enum ETestType
{
e_Zero = 0
, e_One
, e_Two
, e_Three
, e_Four
};
int main () {
ETestType Type= e_Four;
if( ( Type == e_One )
|| ( Type == e_Two)
|| ( Type == e_Three ) )
{
printf(inside\n);
}
printf(done\n);
return 0;
}
David
--
Summary: seems to be a bug in optimization on sparc systems.
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot obermann at callassoftware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25014
[Bug c++/25015] New: [gomp] Function names cannot be demangled due to .omp_fn suffix
Compiling the following code snippet with g++ -fopenmp -O -Wall
I get a hosed error message:
int i;
void foo()
{
#pragma omp parallel
{
int j;
i = j;
}
}
bug.cc: In function 'void _Z3foov.omp_fn.0(void*)':
bug.cc:8: warning: 'j' is used uninitialized in this function
Because of the .omp_fn.0 at the end of the function name the demangler
cannot process it.
Jakub, this is because of your patch
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01644.html
Should we regard the .omp_fn.0 suffix as an extension to the name
mangling scheme and teach the demangler how to handle those things?
This problem will probably also come up with debuggers etc.
--
Summary: [gomp] Function names cannot be demangled due to
.omp_fn suffix
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic, monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25015
[Bug c++/14024] g++ isn't reporting aliasing warnings
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-24 10:48 --- Subject: Bug 14024 Author: rguenth Date: Thu Nov 24 10:48:15 2005 New Revision: 107459 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107459 Log: 2005-11-24 Richard Guenther [EMAIL PROTECTED] Dirk Mueller [EMAIL PROTECTED] PR c++/14024 * c-common.h (strict_aliasing_warning): Declare. * c-common.c (strict_aliasing_warning): New function, split out from ... * c-typeck.c (build_c_cast): ... here. * typeck.c (build_reinterpret_cast_1): Use it. * g++.dg/warn/Wstrict-aliasing-1.C: New testcase. * g++.dg/warn/Wstrict-aliasing-2.C: Likewise. * g++.dg/warn/Wstrict-aliasing-3.C: Likewise. * g++.dg/warn/Wstrict-aliasing-4.C: Likewise. * g++.dg/warn/Wstrict-aliasing-5.C: Likewise. * g++.dg/warn/Wstrict-aliasing-6.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-1.C trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-2.C trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-3.C trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-4.C trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-5.C trunk/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-6.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14024
[Bug c++/14024] g++ isn't reporting aliasing warnings
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-24 10:55 --- Fixed in 4.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|3.3.3 3.4.0 3.4.4 4.0.0 |3.3.3 3.4.0 3.4.4 4.0.0 ||4.1.0 Known to work||4.2.0 Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14024
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #38 from ebotcazou at gcc dot gnu dot org 2005-11-24 11:14 --- That doesn't cover the Ada tools. They build for me at -O0 on PowerPC so with Andrew's FE patch + a possible tweak in the Makefile, you should have an Ada compiler. They even build for me at -O2 on PowerPC with Andrew's patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug libgcj/25016] New: Integer overflow in _Jv_CondWait
_Jv_CondWait makes no allowances for the possibility of an integer overflow, and this means we can return too early. This causes very hard to track down bugs. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161483 -- Summary: Integer overflow in _Jv_CondWait Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: aph at gcc dot gnu dot org ReportedBy: aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25016
[Bug libgcj/25016] Integer overflow in _Jv_CondWait
--- Comment #1 from aph at gcc dot gnu dot org 2005-11-24 11:48 ---
Consider this program:
public class TimedWait
{
public static void main (String[] argv)
throws InterruptedException
{
Object o = new Object();
synchronized (o)
{
o.wait(Long.MAX_VALUE);
}
}
}
It's obvious that we never expect this program to terminate, because
the delay is some 292 million years. However, try this on gcj and it
returns immediately -- because _Jv_CondWait is broken.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-24 11:48:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25016
[Bug libgcj/25016] Integer overflow in _Jv_CondWait
--- Comment #2 from aph at gcc dot gnu dot org 2005-11-24 11:48 --- Patch at http://gcc.gnu.org/ml/java-patches/2005-q4/msg00222.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25016
[Bug libgcj/25016] Integer overflow in _Jv_CondWait
-- aph at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Status|NEW |ASSIGNED Last reconfirmed|2005-11-24 11:48:04 |2005-11-24 11:54:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25016
[Bug libfortran/25017] New: sqrt, csqrt may give a wrong result if real part of compex argument is zero
Seen on intel architectures (i686, x86_64). Run following example code: program test complex cres1, cres2, ivc parameter(ivc = (0,1)) const= 0 fact = 0.5 cres1 = csqrt(const + ivc*fact) cres2 = csqrt(const - ivc*fact) print*,'cres1=',cres1, 'cres2=',cres2 const= 1.e-30 cres1 = csqrt(const + ivc*fact) cres2 = csqrt(const - ivc*fact) print*,'cres1=',cres1, 'cres2=',cres2 stop end The result is: cres1= ( 0.500, 0.500) cres2= (-0.500, 0.500) cres1= ( 0.500, 0.500) cres2= ( 0.500,-0.500) The first line shows the wrong result, the second is that what one expects. The compiler used it taken from gcc SVN. gfortran -v gives: gcc version 4.1.0 20051118 (experimental) -- Summary: sqrt, csqrt may give a wrong result if real part of compex argument is zero Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: harald dot vogt at desy dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug rtl-optimization/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-24 12:56 --- We see a _lot_ of ICEs like this on i686 package builds of f.i. xgl, MPlayer, openafs... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-24 13:05 --- This bug is in glibc (same code on non-glibc platform, such as sparc-solaris, will give the right answer). It was reported in glibc bugzilla as #1466 (http://sources.redhat.com/bugzilla/show_bug.cgi?id=1466), and is now fixed in glibc CVS. Perhaps we need to workaround that bug somewhere. Opinions, please! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|sqrt, csqrt may give a wrong|sqrt, csqrt may give a wrong |result if real part of |result if real part of |compex argument is zero |compex argument is zero http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug rtl-optimization/20586] bootstrap comparision fails with -funroll-loops.
--- Comment #2 from pluto at agmk dot net 2005-11-24 13:11 --- and another failure on 4.1 (rev 107414) on PPC: Bootstrap comparison failure! ./alias.o differs ./builtins.o differs ./combine.o differs ./ddg.o differs ./function.o differs ./global.o differs ./modulo-sched.o differs ./recog.o differs ./sched-deps.o differs ./tree-into-ssa.o differs ./tree-outof-ssa.o differs ada/osint.o differs build/genautomata.o differs build/genextract.o differs build/genrecog.o differs make[1]: *** [gnucompare] Error 1 --- 2 2005-11-24 12:54:59.486600992 + +++ 3 2005-11-24 12:55:03.225032664 + @@ -1,5 +1,5 @@ -alias.o.stage2: file format elf32-powerpc +alias.o.stage3: file format elf32-powerpc Disassembly of section .text: @@ -2934,23 +2934,23 @@ 2cac: 93 41 00 18 stw r26,24(r1) 2cb0: 3f 40 00 00 lis r26,0 2cb4: 93 81 00 20 stw r28,32(r1) -2cb8: 3b 97 00 00 addir28,r23,0 +2cb8: 3b 89 04 02 addir28,r9,1026 2cbc: 93 a1 00 24 stw r29,36(r1) 2cc0: 3b a0 00 00 li r29,0 2cc4: 93 c1 00 28 stw r30,40(r1) -2cc8: 3b c9 04 02 addir30,r9,1026 +2cc8: 3b d7 00 00 addir30,r23,0 2ccc: 93 61 00 1c stw r27,28(r1) 2cd0: 93 e1 00 2c stw r31,44(r1) 2cd4: 90 01 00 34 stw r0,52(r1) 2cd8: 48 00 01 14 b 2dec init_alias_once+0x164 2cdc: 3b 7d ff fe addir27,r29,-2 -2ce0: 3b de 00 01 addir30,r30,1 +2ce0: 3b 9c 00 01 addir28,r28,1 2ce4: 2b 1b 00 07 cmplwi cr6,r27,7 -2ce8: 3b 9c 00 04 addir28,r28,4 +2ce8: 3b de 00 04 addir30,r30,4 2cec: 3b fd 00 01 addir31,r29,1 -2cf0: 7f cb f3 78 mr r11,r30 +2cf0: 7f 8b e3 78 mr r11,r28 2cf4: 7f e4 fb 78 mr r4,r31 -2cf8: 7f 9b e3 78 mr r27,r28 +2cf8: 7f db f3 78 mr r27,r30 2cfc: 40 99 00 58 ble-cr6,2d54 init_alias_once+0xcc 2d00: 38 1d ff b2 addir0,r29,-78 2d04: 28 00 00 0b cmplwi r0,11 @@ -2977,9 +2977,9 @@ 2d58: 2f 89 00 00 cmpwi cr7,r9,0 2d5c: 40 9e 01 38 bne-cr7,2e94 init_alias_once+0x20c 2d60: 38 9f ff fe addir4,r31,-2 -2d64: 39 7e 00 01 addir11,r30,1 +2d64: 39 7c 00 01 addir11,r28,1 2d68: 2b 04 00 07 cmplwi cr6,r4,7 -2d6c: 3b bc 00 04 addir29,r28,4 +2d6c: 3b be 00 04 addir29,r30,4 2d70: 38 9f 00 01 addir4,r31,1 2d74: 40 99 00 58 ble-cr6,2dcc init_alias_once+0x144 2d78: 39 5f ff b2 addir10,r31,-78 @@ -3007,8 +3007,8 @@ 2dd0: 2f 88 00 00 cmpwi cr7,r8,0 2dd4: 40 9e 00 e0 bne-cr7,2eb4 init_alias_once+0x22c 2dd8: 2f 1f 00 70 cmpwi cr6,r31,112 -2ddc: 3b de 00 02 addir30,r30,2 -2de0: 3b 9c 00 08 addir28,r28,8 +2ddc: 3b 9c 00 02 addir28,r28,2 +2de0: 3b de 00 08 addir30,r30,8 2de4: 3b bf 00 02 addir29,r31,2 2de8: 41 9a 00 fc beq-cr6,2ee4 init_alias_once+0x25c 2dec: 38 7d ff fd addir3,r29,-3 @@ -3035,7 +3035,7 @@ 2e40: 81 1a 00 00 lwz r8,0(r26) 2e44: 75 09 04 00 andis. r9,r8,1024 2e48: 40 a2 fe 94 bne-2cdc init_alias_once+0x54 -2e4c: 89 5e 00 00 lbz r10,0(r30) +2e4c: 89 5c 00 00 lbz r10,0(r28) 2e50: 2c 8a 00 00 cmpwi cr1,r10,0 2e54: 41 86 fe 88 beq+cr1,2cdc init_alias_once+0x54 2e58: 7f a4 eb 78 mr r4,r29 @@ -3045,7 +3045,7 @@ 2e68: 7c 65 1b 78 mr r5,r3 2e6c: 38 60 00 04 li r3,4 2e70: 48 00 00 01 bl 2e70 init_alias_once+0x1e8 -2e74: 90 7c 00 00 stw r3,0(r28) +2e74: 90 7e 00 00 stw r3,0(r30) 2e78: 4b ff fe 64 b 2cdc init_alias_once+0x54 2e7c: 39 20 00 0d li r9,13 2e80: 4b ff ff b4 b 2e34 init_alias_once+0x1ac @@ -3062,7 +3062,7 @@ 2eac: 90 7b 00 00 stw r3,0(r27) 2eb0: 4b ff fe b0 b 2d60 init_alias_once+0xd8 2eb4: 38 60 00 09 li r3,9 -2eb8: 3b de 00 02 addir30,r30,2 +2eb8: 3b 9c 00 02 addir28,r28,2 2ebc: 48 00 00 01 bl 2ebc init_alias_once+0x234 2ec0: 38 80 00 00 li r4,0 2ec4: 7c 65 1b 78 mr r5,r3 @@ -3070,7 +3070,7 @@ 2ecc: 48 00 00 01 bl 2ecc init_alias_once+0x244 2ed0: 2f 1f 00 70 cmpwi cr6,r31,112 2ed4: 90 7d 00 00 stw r3,0(r29) -2ed8:
[Bug rtl-optimization/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-11-24 13:25 --- The patch seems to fix the failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
[Bug fortran/16206] Internal error on initialization expression
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-24 13:26
---
I think this bug is caused by the fact that simplification of array slices
isn't implemented yet; from expr.c (simplify_const_ref):
switch (p-ref-type)
{
.
.
.
default:
/* TODO: Simplify array subsections. */
return SUCCESS;
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
CC||eedelman at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug fortran/25018] New: Segfault with simple expression
[EMAIL PROTECTED]:~/src/work cat const.f90 module const real(8), parameter :: g = - sqrt(2._8) * Gf end module const [EMAIL PROTECTED]:~/src/work ../gcc/build/gcc/f951 const.f90 const.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED]:~/src/work The uninitialized variable is necessary for the segfault. In the debugger: (gdb) run const.f90 Starting program: /home/pcl331/schluter/src/gcc/build/gcc/f951 const.f90 Program received signal SIGSEGV, Segmentation fault. 0x0805efad in check_inquiry (e=0x8695ad0) at ../../gcc/fortran/expr.c:1382 1382 name = e-symtree-n.sym-name; (gdb) bt #0 0x0805efad in check_inquiry (e=0x8695ad0) at ../../gcc/fortran/expr.c:1382 #1 0x0806082b in check_init_expr (e=0x8695ad0) at ../../gcc/fortran/expr.c:1443 #2 0x0805edc6 in check_intrinsic_op (e=0x8695b28, check_function=0x80607c0 check_init_expr) at ../../gcc/fortran/expr.c:1284 #3 0x0806081d in check_init_expr (e=0x8695b28) at ../../gcc/fortran/expr.c:1434 #4 0x0805ed32 in check_intrinsic_op (e=0x8695c78, check_function=0x80607c0 check_init_expr) at ../../gcc/fortran/expr.c:1250 #5 0x0806081d in check_init_expr (e=0x8695c78) at ../../gcc/fortran/expr.c:1434 #6 0x0805ed32 in check_intrinsic_op (e=0x8695cd0, check_function=0x80607c0 check_init_expr) at ../../gcc/fortran/expr.c:1250 #7 0x0806081d in check_init_expr (e=0x8695cd0) at ../../gcc/fortran/expr.c:1434 #8 0x08060a52 in gfc_match_init_expr (result=0xbfffed64) at ../../gcc/fortran/expr.c:1543 #9 0x08059f00 in variable_decl (elem=Variable elem is not available. ) at ../../gcc/fortran/decl.c:1209 #10 0x0805aa82 in gfc_match_data_decl () at ../../gcc/fortran/decl.c:2240 #11 0x0807ec0a in match_word (str=Variable str is not available. ) at ../../gcc/fortran/parse.c:65 #12 0x0807ed1d in decode_statement () at ../../gcc/fortran/parse.c:134 #13 0x0807f745 in next_statement () at ../../gcc/fortran/parse.c:358 #14 0x08080a5b in parse_spec (st=ST_NONE) at ../../gcc/fortran/parse.c:1556 #15 0x080815f9 in gfc_parse_file () at ../../gcc/fortran/parse.c:2501 #16 0x0809cadd in gfc_be_parse_file (set_yydebug=0) at ../../gcc/fortran/f95-lang.c:286 #17 0x0836cf40 in toplev_main (argc=2, argv=0xbfffefd4) at ../../gcc/toplev.c:990 #18 0x080c766f in main (argc=Cannot access memory at address 0x0 ) at ../../gcc/main.c:35 (gdb) -- Summary: Segfault with simple expression Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25018
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #15 from jb at gcc dot gnu dot org 2005-11-24 13:38 --- Just to be sure, you should be building outside the gcc directory hierarchy. This is (a cleaned up version of the) script I use for doing a clean build: #!/bin/sh GCCDIR=trunk cd $GCCDIR contrib/gcc_update cd .. rm -rf objdir mkdir objdir cd objdir ../$GCCDIR/configure --enable-checking --prefix=$HOME/src/gfortran/install --enable-languages=fortran make make install cd gcc make check-fortran cd ../.. # EOF You see that the objdir where all the building is done, is entirely separate from the checked out gcc tree (trunk directory). As an added bonus, for a clean build you just blow away objdir, no need to check out gcc again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug ada/18659] [4.1/4.2 Regression] ACATS failures c32001e c64105b c95086b
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2005-11-24 14:09 --- Created an attachment (id=10332) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10332action=view) Reduced testcase. Compile at -O on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
[Bug rtl-optimization/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p
--- Comment #9 from uros at kss-loka dot si 2005-11-24 14:40 --- Critical, according to comment #7 and #8. -- uros at kss-loka dot si changed: What|Removed |Added CC||uros at kss-loka dot si Severity|normal |critical Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #39 from pluto at agmk dot net 2005-11-24 14:46 --- (In reply to comment #38) That doesn't cover the Ada tools. They build for me at -O0 on PowerPC so with Andrew's FE patch + a possible tweak in the Makefile, you should have an Ada compiler. They even build for me at -O2 on PowerPC with Andrew's patch. with minor makefile tweak ada builds with -O2 on ppc. --- gcc/gcc/ada/Makefile.in.orig2005-11-23 16:48:27.0 + +++ gcc/gcc/ada/Makefile.in 2005-11-24 10:14:25.987115520 + @@ -1899,6 +1899,12 @@ $(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O2 $(ADA_INCLUDES) \ $ $(OUTPUT_OPTION) +# [Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap + +make.o : make.adb make.ads + $(CC) -c $(ALL_ADAFLAGS) $(FORCE_DEBUG_ADAFLAGS) -O1 $(ADA_INCLUDES) \ + $ $(OUTPUT_OPTION) + adadecode.o : adadecode.c adadecode.h aux-io.o : aux-io.c argv.o: argv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug c/25019] New: Promoting long to long long generates no warning and/or incorrect result.
Promoting of longs to long longs gives incorrect results (i.e. sign extension is not done; upper half of result may in some cases be the upper half of a previous 64-bit computation), and does not give a warning in most cases. I have tried http://cjb.ie/32-64bug.c on the following, on various 32-bit x86 machines: gcc (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) gcc-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-8ubuntu2) gcc-3.3 (GCC) 3.3.6 (Ubuntu 1:3.3.6-8ubuntu1) gcc-4.0 (GCC) 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu7) gcc-4.0 (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) For all of the above, and different values for -O, results seem to be invariant: $ gcc -o 32-64bug 32-64bug.c 32-64bug.c: In function âmainâ: 32-64bug.c:13: warning: left shift count = width of type 32-64bug.c:14: warning: left shift count = width of type $ ./32-64bug 5500 expected for 85LL40, 5500 obtained. 100 expected for 140 (const expr as printf arg), 5500 obtained. 100 expected for 140 (const expr, precomputed), 0 obtained. 55000 expected for 85LL44, 55000 obtained. 100 expected for 140 (variable expr, precomputed), 100 obtained. 100 expected for 140 (variable expr, as printf arg), 100 obtained. 55 expected for 85LL48, 55 obtained. 1234567800 expected for 0x123456788 (const expr, as printf arg), 5534567800 obtained. 1234567800 expected for 0x123456788 (const expr, precomputed), 34567800 obtained. $ Note that a warning is only generated for the 140 constant expression, and others are miscomputed with no warning. If it's not easy to get the 'expected' and 'obtained' values to match above, would it be possible to just generate a warning any time a 32-bit value is promoted to 64-bit? -- Summary: Promoting long to long long generates no warning and/or incorrect result. Product: gcc Version: 3.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cjb at cjb dot ie GCC build triplet: i586-pc-linux-gnu GCC host triplet: i586-pc-linux-gnu GCC target triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25019
[Bug libgcj/25016] Integer overflow in _Jv_CondWait
--- Comment #3 from overholt at redhat dot com 2005-11-24 15:21 --- This test case does not work for me when I have not applied the patch. After application and building, it does appear to run forever :) Also, the Eclipse issue that spurred this on (referenced in comment #1) is fixed when I run with a patched gcc RPM set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25016
[Bug c/25019] Promoting long to long long generates no warning and/or incorrect result.
--- Comment #1 from cjb at cjb dot ie 2005-11-24 15:21 --- Created an attachment (id=10333) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10333action=view) Test case for 32-64 bit promotion bug Most recent version of this file available at http://cjb.ie/32-64bug.c or http://cjb.ie/32-64bug.c.txt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25019
[Bug fortran/25020] New: NAG extension: module F90_UNIX providing access to UNIX functions (abort ...)
Hi, it would be nice if gfortran implemented a facility like NAG's F90_UNIX module. The program implicit none call abort () end compiles and links with gfc -std=gnu but not with -std=f95 With the NAG compiler one can write USE f90_unix, ONLY: abort implicit none call abort () end have access to the intrinsics and be happy. See http://www.nag.co.uk/nagware/np/r50_doc/nag_modules.html http://www.nag.co.uk/nagware/np/r50_doc/f90_unix.html for details. Cheers, -ha -- Summary: NAG extension: module F90_UNIX providing access to UNIX functions (abort ...) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25020
[Bug middle-end/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug libfortran/24459] gfortran namelist problem
--- Comment #8 from ed at eh3 dot com 2005-11-24 16:26 --- Hi Jerry, thank you for looking into this issue and clarifing it! The use of correct array triplets is a very quick and easy thing for us to do. And its certainly a good idea to follow the Fortran standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
Re: [Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
fxcoudert at gcc dot gnu dot org wrote: --- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-24 13:05 --- This bug is in glibc (same code on non-glibc platform, such as sparc-solaris, will give the right answer). It was reported in glibc bugzilla as #1466 (http://sources.redhat.com/bugzilla/show_bug.cgi?id=1466), and is now fixed in glibc CVS. Perhaps we need to workaround that bug somewhere. Opinions, please! How long before next glibc release? This problem could be painful for folks that are using gfortran for real world applications who are not aware. Maybe we need to add an errata file to the tree and add a message at the end of configure to remind people to read the errata file. This would go for all of gcc, not just gfortran. Jerry
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #2 from jvdelisle at verizon dot net 2005-11-24 16:33 --- Subject: Re: sqrt, csqrt may give a wrong result if real part of compex argument is zero fxcoudert at gcc dot gnu dot org wrote: --- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-24 13:05 --- This bug is in glibc (same code on non-glibc platform, such as sparc-solaris, will give the right answer). It was reported in glibc bugzilla as #1466 (http://sources.redhat.com/bugzilla/show_bug.cgi?id=1466), and is now fixed in glibc CVS. Perhaps we need to workaround that bug somewhere. Opinions, please! How long before next glibc release? This problem could be painful for folks that are using gfortran for real world applications who are not aware. Maybe we need to add an errata file to the tree and add a message at the end of configure to remind people to read the errata file. This would go for all of gcc, not just gfortran. Jerry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-24 16:41 --- This is a dup of bug 24313. Gfortran cannot fix a glibc bug. We don't know when glibc is going to be released (also maybe if you complain to the distro you use they will release a newer glibc with the fix). *** This bug has been marked as a duplicate of 24313 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug libfortran/24313] complex sqrt function does not return principal value
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-24 16:41 --- *** Bug 25017 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||harald dot vogt at desy dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
[Bug java/25021] New: Can't compile ant 1.6.5 to machine code
Building ant 1.6.5 normally with gcj 4.0.2 works nicely; trying to compile the
resulting jar files into a binary fails:
After ant dist:
cd bin/lib
LINKTO=-L.
for i in *.jar; do
[ $i = ant-launcher.jar ] continue
gcj -O2 -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o
lib${i/.jar/.so} $i
LINKTO=$LINKTO -l${i/.jar/}
done
gcj -O2 -fjni -findirect-dispatch -o antbin
--main=org.apache.tools.ant.launcher.Launcher ant-launcher.jar $LINKTO
results in
/tmp/cc5M7IPD.o: In function `main':
ccy5f8qg.i:(.text+0x20): undefined reference to
`org::apache::tools::ant::launcher::Launcher::class$'
collect2: ld returned 1 exit status
ant-launcher.jar contains the org.apache.tools.ant.launcher.Launcher class as
expected, and can be run perfectly through gij.
--
Summary: Can't compile ant 1.6.5 to machine code
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25021
[Bug middle-end/25022] New: [4.2,4.1,4.0,3.4 regression] failure to transform the unlocked stdio calls
Given the following program:
#define _GNU_SOURCE
#include stdio.h
int main ()
{
fputs_unlocked(\n, stdout);
return 0;
}
GCC fails to turn fputs_unlocked into fputc_unlocked. This fails in all GCC
versions as of 3.4 through mainline, but works in gcc-3.3 so it's a regression.
The regular locked stdio transformation fputs-fputc works.
--
Summary: [4.2,4.1,4.0,3.4 regression] failure to transform the
unlocked stdio calls
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug c/25019] Promoting long to long long generates no warning and/or incorrect result.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-24 16:50 --- a=1b; is done in the type of b and not of type of a so this is invalid as the behavior is undefined. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25019
[Bug middle-end/25022] [4.2,4.1,4.0,3.4 regression] failure to transform the unlocked stdio calls
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-11-24 16:51 --- This happens because the replacement functions are obtained in builtins.c from the array implicit_built_in_decls. This array is initialized to null when the replacement function is an extension builtin, as are all _unlocked stdio calls. Therefore, no _unlocked calls will ever be replaced with another _unlocked call. I'm testing a patch. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-24 16:51:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug middle-end/25023] New: [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
We fail to build the linux kernel on i686 with debugging enabled. drivers/usb/media/w9968cf.c: /usr/lib/gcc/i586-suse-linux/4.1.0/cc1 -fpreprocessed w9968cf.i -quiet -dumpbase w9968cf.i -m32 -msoft-float -mpreferred-stack-boundary=2 -march=i586 -mregparm=3 -auxbase-strip drivers/usb/media/.tmp_w9968cf.o -g -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Wdeclaration-after-statement -Wno-pointer-sign -version -fno-strict-aliasing -fno-common -ffreestanding -fomit-frame-pointer -fno-unit-at-a-time -o /tmp/ccaO9lCn.s drivers/usb/media/w9968cf.c: In function w9968cf_set_picture: drivers/usb/media/w9968cf.c:1827: internal compiler error: in def_cfa_1, at dwarf2out.c:792 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.suse.de/feedback for instructions. (reducing) -- Summary: [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: critical Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug middle-end/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug middle-end/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-24 16:56 --- The candidate which likely broke it is 2005-11-17 Richard Henderson [EMAIL PROTECTED] * dwarf2out.c (dw_cfi_oprnd_struct): Reduce dw_cfi_reg_num to int. (lookup_cfa_1): Apply data alignment to DW_CFA_def_cfa_offset_sf and DW_CFA_def_cfa_sf. (def_cfa_1): Use DW_CFA_def_cfa_offset_sf with negative values. (dbx_reg_number): Don't assert particular registers here. (based_loc_descr): ... do it here instead. Fold in ... (eliminate_reg_to_offset): ... this function. (compute_frame_pointer_to_cfa_displacement): Fold in the effects of eliminate_reg_to_offset; use FRAME_POINTER_CFA_OFFSET. * unwind-dw2.c (execute_cfa_program): Apply data align factor to DW_CFA_def_cfa_offset_sf and DW_CFA_def_cfa_sf. * function.c (instantiate_new_reg): Use FRAME_POINTER_CFA_OFFSET. (instantiate_virtual_regs): Likewise. * var-tracking.c (adjust_stack_reference): Likewise. * doc/tm.texi (FRAME_POINTER_CFA_OFFSET): New. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug c++/24050] [3.4 Regression] Fails a template instantiation.
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-24 16:58
---
Testcase with fewer nesting levels of templates:
templateint struct A
{
static void foo() {}
};
void bar(void (*)()) {}
templateint struct B
{
B() { bar(A0::foo); }
};
B0 b;
int main()
{
return 0;
}
Compiles with optimization turned on.
--
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=24050
[Bug middle-end/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-24 16:58 --- Created an attachment (id=10334) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10334action=view) testcase (unreduced) testacse -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug middle-end/25022] [3.4/4.0/4.1/4.2 regression] failure to transform the unlocked stdio calls
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2,4.1,4.0,3.4 regression]|[3.4/4.0/4.1/4.2 regression] |failure to transform the|failure to transform the |unlocked stdio calls|unlocked stdio calls Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25022
[Bug c/25019] Promoting long to long long generates no warning and/or incorrect result.
--- Comment #3 from falk at debian dot org 2005-11-24 17:01 ---
Well, there's one actual issue here, namely that there is no warning about:
int f() {
int x = 40;
return 1 x;
}
even though we could of course detect this, albeit probably only in the
middle-end. It might be difficult to get this warning to be emitted reliably
and without false positives from there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25019
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-24 17:03 ---
Here's a version of the testcase that doesn't rely on _unlocked functions since
25022 inhibits the unlocked transformations. Compile at -O2 with and without
-DPUTCHAR_DIRECT to see the effect. Using putchar directly makes use of the
extern inline and transforms into _IO_putc, whereas the printf call only gets
as far as turning into putchar.
#include stdio.h
#undef putchar
int main ()
{
#ifdef PUTCHAR_DIRECT
putchar('\n');
#else
printf (\n);
#endif
return 0;
}
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-24 17:03:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #4 from kargl at gcc dot gnu dot org 2005-11-24 17:03 --- c99_functions.c contains implementations of csqrt[fl], which are the fixed glibc routines. We can remove the #if !defined(HAVE_CSQRTF) and simply have gfortran use its own versions. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug middle-end/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-24 17:04 --- Created an attachment (id=10335) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10335action=view) testcase reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-24 17:05 --- (In reply to comment #4) c99_functions.c contains implementations of csqrt[fl], which are the fixed glibc routines. We can remove the #if !defined(HAVE_CSQRTF) and simply have gfortran use its own versions. For only targets which have a broken csqrtf yes. Please don't do it all the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug c++/24979] DECL_MAIN_P is declared twice in cp-tree.h
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-11-24 17:10 --- Confirmed. The duplicate definition was introduced in GCC 3.0. I'll take care of the patch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24979
[Bug c++/24979] DECL_MAIN_P is declared twice in cp-tree.h
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-24 17:11:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24979
[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-24 17:11 --- -O2 -m32 -msoft-float -mpreferred-stack-boundary=2 -march=i586 -mregparm=3 -fno-strict-aliasing -fno-common -ffreestanding -fomit-frame-pointer -fno-unit-at-a-time -g -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug java/25021] Can't compile ant 1.6.5 to machine code
--- Comment #1 from bero at arklinux dot org 2005-11-24 17:20 --- Verified still broken with gcc 4.0.3 SVN 107424 -- bero at arklinux dot org changed: What|Removed |Added Known to fail||4.0.2 4.0.3 Version|4.0.2 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25021
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2005-11-24 17:22 --- Subject: Re: sqrt, csqrt may give a wrong result if real part of compex argument is zero On Thu, Nov 24, 2005 at 05:05:12PM -, pinskia at gcc dot gnu dot org wrote: (In reply to comment #4) c99_functions.c contains implementations of csqrt[fl], which are the fixed glibc routines. We can remove the #if !defined(HAVE_CSQRTF) and simply have gfortran use its own versions. For only targets which have a broken csqrtf yes. Please don't do it all the time. I've never used glibc. Does it define a _GLIBC_VERSION_MAJOR and _GLIBC_VERSION_MINOR? We could do #if !defined(HAVE_CSQRTF) || (xx_MAJOR 42 xx_MINOR 42) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug libfortran/24459] gfortran namelist problem
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-24 17:25 --- After going to comp.lang.fortran I determined this is not a bug and gfortran is correctly handling the given namelist. To get desired behavior use array qualifiers with array triplet notation. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug c/25019] Promoting long to long long generates no warning and/or incorrect result.
--- Comment #4 from schwab at suse dot de 2005-11-24 17:28 --- (In reply to comment #2) a=1b; is done in the type of b and not of type of a The type of the right operand of a shift expression has no significance at all. 1 has type int, so has 1b. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25019
[Bug tree-optimization/17863] [4.0/4.1/4.2 Regression] threefold performance loss, not inlining as much
--- Comment #30 from phython at gcc dot gnu dot org 2005-11-24 17:34 --- On powerpc-linux, I get the following timings: Using the following command line: g++ -O3 -o t41 -mcpu=7450 -mtune=7450 pr17863.cc -static real user 3.4 0m11.761s 0m11.148s 4.0 0m10.196s 0m9.495s 4.1 0m17.824s 0m16.832s 4.1 0m11.547s 0m10.502s -- With attribute flatten -- phython at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2004-12-24 20:36:17 |2005-11-24 17:34:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug java/24698] [4.1/4.2 regression] Failure locating .properties files inside jars
--- Comment #5 from bero at arklinux dot org 2005-11-24 18:07 --- This should be marked important regression IMO, it breaks a number of applications out there -- bero at arklinux dot org changed: What|Removed |Added Known to fail||4.1.0 4.2.0 Known to work||3.4.4 3.4.5 4.0.0 4.0.1 ||4.0.2 4.0.3 Summary|[4.1/4.2 regression]|[4.1/4.2 regression] Failure |Apparent problem getting|locating .properties files |non-.class files out of jars|inside jars http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug fortran/25024] New: ICE with external declaration inside same procedure
The following simple procedure causes an ICE: subroutine A() EXTERNAL A END Error message with compiler gcc version 4.2.0 20051124 (experimental) is: crash2.f:0: internal compiler error: in build_function_decl, at fortran/trans-decl.c:1114 With compiler gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) the message is essentially the same: crash2.f:0: internal compiler error: in build_function_decl, at fortran/trans-decl.c:1026 -- Summary: ICE with external declaration inside same procedure Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25024
[Bug libstdc++/25025] New: Failure to build, command line:1:2: error: missing '(' after predicate
Following is the relevant output from my make.
gmake[3]: Entering directory
`/usr/local/.src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++'
/bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile
/usr/local/src/gcc.obj/gcc/xgcc -shared-libgcc -B/usr/local/src/gcc.obj/gcc/
-nostdinc++ -L/usr/local/src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/usr/local/src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/usr/local/64bit/hppa64-hp-hpux11.11/bin/
-B/usr/local/64bit/hppa64-hp-hpux11.11/lib/ -isystem
/usr/local/64bit/hppa64-hp-hpux11.11/include -isystem
/usr/local/64bit/hppa64-hp-hpux11.11/sys-include
-I/usr/local/src/gcc-4.0.2/libstdc++-v3/../gcc
-I/usr/local/src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/usr/local/src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/usr/local/src/gcc-4.0.2/libstdc++-v3/libsupc++ -Aa
-D_INCLUDE__STDC_A1_SOURCE -O2 -g -mpa-risc-2-0 -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -c -o del_op.lo
/usr/local/src/gcc-4.0.2/libstdc++-v3/libsupc++/del_op.cc
/usr/local/src/gcc.obj/gcc/xgcc -shared-libgcc -B/usr/local/src/gcc.obj/gcc/
-nostdinc++ -L/usr/local/src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/usr/local/src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/usr/local/64bit/hppa64-hp-hpux11.11/bin/
-B/usr/local/64bit/hppa64-hp-hpux11.11/lib/ -isystem
/usr/local/64bit/hppa64-hp-hpux11.11/include -isystem
/usr/local/64bit/hppa64-hp-hpux11.11/sys-include
-I/usr/local/src/gcc-4.0.2/libstdc++-v3/../gcc
-I/usr/local/src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/usr/local/src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/usr/local/src/gcc-4.0.2/libstdc++-v3/libsupc++ -Aa
-D_INCLUDE__STDC_A1_SOURCE -O2 -g -mpa-risc-2-0 -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -c
/usr/local/src/gcc-4.0.2/libstdc++-v3/libsupc++/del_op.cc -o del_op.o
command line:1:2: error: missing '(' after predicate
gmake[3]: *** [del_op.lo] Error 1
gmake[3]: Leaving directory
`/usr/local/.src/gcc.obj/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++'
--
Summary: Failure to build, command line:1:2: error: missing '('
after predicate
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pda at freeshell dot org
GCC build triplet: hppa64-hp-hpux11.11
GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25025
[Bug target/21623] [4.0/4.1/4.2 regression] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Comment #5 from amylaar at gcc dot gnu dot org 2005-11-24 18:56 ---
Subject: Bug 21623
Author: amylaar
Date: Thu Nov 24 18:55:53 2005
New Revision: 107468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107468
Log:
PR target/21623:
* regclass.c (FORBIDDEN_INC_DEC_CLASSES): Remove
SECONDARY_INPUT_RELOAD_CLASS and SECONDARY_OUTPUT_RELOAD_CLASS tests.
(init_fake_stack_mems): Remove HAVE_SECONDARY_RELOADS test.
(memory_move_secondary_cost, init_reg_autoinc): Remove
SECONDARY_INPUT_RELOAD_CLASS / SECONDARY_OUTPUT_RELOAD_CLASS tests.
Replace SECONDARY_{IN,OUT}PUT_RELOAD_CLASS use with
secondary_reload_class call.
(copy_cost): Likewise. Add new parameter prev_sri. Changed all
callers.
* reload.c (entire file): Remove HAVE_SECONDARY_RELOADS checks.
(push_secondary_reload): Use secondary_reload target hook.
(secondary_reload_class, scratch_reload_class): New functions.
(push_reload): Remove SECONDARY_INPUT_RELOAD_CLASS and
SECONDARY_OUTPUT_RELOAD_CLASS tests. Replace
SECONDARY_{IN,OUT}PUT_RELOAD_CLASS use with secondary_reload_class
call.
* reload.h (HAVE_SECONDARY_RELOADS): Don't define nor test.
(secondary_reload_class, scratch_reload_class): Declare.
* reload1.c: Include target.h.
(reload_adjust_reg_for_temp): New function.
(reload_adjust_reg_for_icode): Likewise.
(choose_reload_regs): Remove SECONDARY_INPUT_RELOAD_CLASS test.
Replace SECONDARY_INPUT_RELOAD_CLASS use with secondary_reload_class
call.
(emit_input_reload_insns): Likewise. Rewrite secondary reload checks
for inheritance. Support case when both secondary tertiary reloads
are for intermediate registers.
(emit_output_reload_insns): Replace SECONDARY_OUTPUT_RELOAD_CLASS use
with secondary_reload_class call. Support case when both secondary
tertiary reloads are for intermediate registers.
* target-def.h (TARGET_SECONDARY_RELOAD): Provide default definition.
(TARGET_INITIALIZER) Add TARGET_SECONDARY_RELOAD.
* target.h (secondary_reload_info): New struct / typedef.
(struct gcc_target): New member secondary_reload.
* targhooks.c Include reload.h, optabs.h and recog.h.
(default_secondary_reload): New function.
* targhooks.h (default_secondary_reload): Declare.
* doc/tm.texi: Document secondary_reload target hook. Update
description of SECONDARY_*RELOAD_CLASS and reload_{in,out}mode.
* doc/md.texi: Likewise.
* sh-protos.h (sh_secondary_reload): Declare.
* sh.c (TARGET_SECONDARY_RELOAD): Override.
(sh_secondary_reload): New function.
* sh.h (SECONDARY_INOUT_RELOAD_CLASS): Don't define.
(SECONDARY_OUTPUT_RELOAD_CLASS): Likewise.
(SECONDARY_INPUT_RELOAD_CLASS): Likewise.
(HAVE_SECONDARY_RELOADS): Define.
* sh.md (reload_indf): Rename to:
(reload_indf__frn).
(reload_outdf): Rename to:
(reload_outdf__RnFRm).
(reload_insf): Rename to:
(reload_insf__frn).
(reload_insi): Rename to:
(reload_insi__i_fpul).
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-protos.h
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.h
trunk/gcc/config/sh/sh.md
trunk/gcc/doc/md.texi
trunk/gcc/doc/tm.texi
trunk/gcc/optabs.c
trunk/gcc/regclass.c
trunk/gcc/reload.c
trunk/gcc/reload.h
trunk/gcc/reload1.c
trunk/gcc/target-def.h
trunk/gcc/target.h
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21623
[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-24 20:03 --- Confirmed, the inline-asm is required (this testcase does not reduce any further really). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-24 20:03:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #40 from pluto at agmk dot net 2005-11-24 20:21 --- it also builds on i486. unfortunately amd64 fails on a-except even with -O0. (...) stage1/xgcc -Bstage1/ -B/usr/x86_64-pld-linux/bin/ -c -march=x86-64 -O2 -ggdb -gnatpg -gnata -g -O0 \ -I- -I. -Iada -I../../gcc/ada ../../gcc/ada/a-except.adb -o ada/a-except.o +===GNAT BUG DETECTED==+ | 4.1.0 20051123 (prerelease) (x86_64-pld-linux-gnu) Storage_Error stack overflow (or erroneous memory access)| | Error detected at a-except.adb:42:17 | -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-24 20:42 ---
Here is a reduced testcase as far as I can get it:
struct device_driver {
const char * name;
};
struct video_picture {
unsigned short a,b,c,d,e;
};
struct w9968cf_device {
struct device_driver *driver;
int vpp_flag;
};
int debug = 2;
int specific_debug = 0;
int w9968cf_set_picture(struct w9968cf_device* cam, struct video_picture pict)
{
short fmt, reg_v = 0x;
int err = 0;
long esi, edi;
switch (fmt) {
case 13:
reg_v |= 0x0002;
case 4:
case 5:
cam-vpp_flag = 8;
}
if (err = w9968cf_write_reg(cam, reg_v, 0x16))
if (err = w9968cf_sensor_update_picture(cam, pict))
__asm__ __volatile__(movsw
:=D(edi),=S(esi):0(edi),1(esi):memory);
if (((specific_debug) (debug == (1))) || ((!specific_debug) (debug =
(1
printk(4 %s %s: Failed to change picture settings \n ,
cam-driver-name );
return err;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug libgcj/25026] New: -libXtst not detected [--enable-java-awt=gtk]
my gcc is configured with: ../configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/X11R6/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++,ada,java --enable-c99 --enable-long-long --disable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --without-x --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo --enable-java-awt=gtk ppc-pld-linux CFLAGS=-O2 -ggdb CXXFLAGS=-O2 -ggdb TEXCONFIG=false but libgcj configure fails: (...) checking for gtk+-2.0 = 2.4... yes checking GTK_CFLAGS... -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 checking GTK_LIBS... -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lXrandr -lXi -lXinerama -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lXcursor -lXfixes -lcairo -lpangoft2-1.0 -lfontconfig -lfreetype -lz -lpango-1.0 -lm -lXrender -lX11 -lXext -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 checking for glib-2.0 = 2.4 gthread-2.0 = 2.4... yes checking GLIB_CFLAGS... -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include checking GLIB_LIBS... -pthread -lgthread-2.0 -lglib-2.0 checking for libart-2.0 = 2.1... yes checking LIBART_CFLAGS... -I/usr/include/libart-2.0 checking LIBART_LIBS... -lart_lgpl_2 checking for XTestQueryExtension in -lXtst... no configure: error: libXtst not found, required by java.awt.Robot make[2]: *** [configure-target-libjava] Error 1 $ ls -la /usr/X11R6/lib/libXtst* 14 Nov 15 08:01 /usr/X11R6/lib/libXtst.so - libXtst.so.6.1 14 Aug 1 23:06 /usr/X11R6/lib/libXtst.so.6 - libXtst.so.6.1 27012 Nov 15 01:26 /usr/X11R6/lib/libXtst.so.6.1 config.log: (...) configure:13839: checking for XTestQueryExtension in -lXtst configure:13874: /home/users/builder2/rpm/BUILD/gcc/obj-ppc-pld-linux/./gcc/xgcc -B/home/users/builder2/rpm/BUILD/gcc/obj-ppc-pld-linux/./gcc/ -B/usr/ppc-pld-linux/bin/ -B/usr/ppc-pld-linux/lib/ -isystem /usr/ppc-pld-linux/include -isystem /usr/ppc-pld-linux/sys-include -o conftest -O2 -O2 -ggdb conftest.c -lXtst 5 /usr/bin/ld: cannot find -lXtst collect2: ld returned 1 exit status configure:13880: $? = 1 (...) i don't see a -L/usr/X11R6/lib in test. -- Summary: -libXtst not detected [--enable-java-awt=gtk] Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: *-linux GCC host triplet: *-linux GCC target triplet: *-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25026
[Bug middle-end/24990] fold should convert ~a != C to a != ~C where C is a constant
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-24 21:19 --- Patch posted. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg01781.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24990
[Bug middle-end/24989] boolvar != 1 is not converted to !boolvar
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-24 21:19 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01780.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg01780.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24989
[Bug fortran/18428] No preprocessing option -cpp for gfortran
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-24 22:11 --- (In reply to comment #5) The -x option in gfortran is not really a good replacement as described in my comment #2. While I completely agree with you, I don't see a way to do that with the current framework. On the other hand, when (or if) we switch to cpplib, it will be fairly easy. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-05-12 02:03:57 |2005-11-24 22:11:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18428
[Bug fortran/21647] INQUIRE errors when using -fdefault-integer-8
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-11-24 22:14 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21647
[Bug target/24831] [4.1/4.2 regression] gthr-dce.h:77: error: expected expression before '{' token
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-24
22:33 ---
Subject: Re: [4.1 regression] gthr-dce.h:77: error: expected expression before
'{' token
HP-UX 10 is not a primary platform, but this seems an easy fix; let's fix it
if
we can.
The enclosed change appears to fix the __gthrw regressions on HP-UX 10.
I say appears because it hasn't been fully tested. It would need another
bootstrap and check for that.
On HP-UX 10.20, pthread_once_init and pthread_getunique_np are macro
defines. pthread_once_init is an initializer and pthread_getunique_np
is an expression (not a function). pthread_key_delete is not defined.
I've added some changes to fix warnings about unused arguments arising
from this file.
I'm not really sure how best to handle the issues arising from trying
to use __gthrw. This could vary from one system to another. Possibly,
HP-UX 10 is the only user of this file.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Index: gthr-dce.h
===
--- gthr-dce.h (revision 107400)
+++ gthr-dce.h (working copy)
@@ -55,12 +55,12 @@
typedef pthread_mutex_t __gthread_mutex_t;
typedef pthread_mutex_t __gthread_recursive_mutex_t;
-#define __GTHREAD_ONCE_INIT __gthrw_pthread_once_init
+#define __GTHREAD_ONCE_INIT pthread_once_init
#define __GTHREAD_MUTEX_INIT_FUNCTION __gthread_mutex_init_function
#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION
__gthread_recursive_mutex_init_function
-#define __GTHREAD_MUTEX_INIT_DEFAULT __gthrw_pthread_once_init
+#define __GTHREAD_MUTEX_INIT_DEFAULT pthread_once_init
#if SUPPORTS_WEAK GTHREAD_USE_WEAK
# define __gthrw(name) \
@@ -74,9 +74,7 @@
#endif
__gthrw(pthread_once);
-__gthrw(pthread_once_init);
__gthrw(pthread_keycreate);
-__gthrw(pthread_key_delete);
__gthrw(pthread_getspecific);
__gthrw(pthread_setspecific);
__gthrw(pthread_create);
@@ -96,7 +94,6 @@
__gthrw(pthread_cond_signal);
__gthrw(pthread_cond_wait);
__gthrw(pthread_exit);
-__gthrw(pthread_getunique_np);
__gthrw(pthread_mutex_destroy);
__gthrw(pthread_self);
__gthrw(pthread_yield);
@@ -262,7 +259,7 @@
{
pthread_t self = __gthrw_pthread_self ();
- return (objc_thread_t) __gthrw_pthread_getunique_np (self);
+ return (objc_thread_t) pthread_getunique_np (self);
}
else
return (objc_thread_t) 1;
@@ -371,7 +368,7 @@
/* Allocate a condition. */
static inline int
-__gthread_objc_condition_allocate (objc_condition_t condition)
+__gthread_objc_condition_allocate (UNUSED (objc_condition_t condition))
{
if (__gthread_active_p ())
/* Unimplemented. */
@@ -382,7 +379,7 @@
/* Deallocate a condition. */
static inline int
-__gthread_objc_condition_deallocate (objc_condition_t condition)
+__gthread_objc_condition_deallocate (UNUSED (objc_condition_t condition))
{
if (__gthread_active_p ())
/* Unimplemented. */
@@ -393,7 +390,8 @@
/* Wait on the condition */
static inline int
-__gthread_objc_condition_wait (objc_condition_t condition, objc_mutex_t mutex)
+__gthread_objc_condition_wait (UNUSED (objc_condition_t condition),
+ UNUSED (objc_mutex_t mutex))
{
if (__gthread_active_p ())
/* Unimplemented. */
@@ -404,7 +402,7 @@
/* Wake up all threads waiting on this condition. */
static inline int
-__gthread_objc_condition_broadcast (objc_condition_t condition)
+__gthread_objc_condition_broadcast (UNUSED (objc_condition_t condition))
{
if (__gthread_active_p ())
/* Unimplemented. */
@@ -415,7 +413,7 @@
/* Wake up one thread waiting on this condition. */
static inline int
-__gthread_objc_condition_signal (objc_condition_t condition)
+__gthread_objc_condition_signal (UNUSED (objc_condition_t condition))
{
if (__gthread_active_p ())
/* Unimplemented. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24831
[Bug middle-end/25027] New: libgcov.c:652: ICE: in default_secondary_reload, at targhooks.c:529
./xgcc -B./ -B/home/dave/opt/gnu/gcc/gcc-4.1.0/hppa-linux/bin/ -isystem /home/da ve/opt/gnu/gcc/gcc-4.1.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc- 4.1.0/hppa-linux/sys-include -L/home/dave/gnu/gcc-4.0/objdir/gcc/../ld -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-proto types -Wold-style-definition -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DH AVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -DL_gcov_merge_single -c ../../gcc/gcc/libgcov.c -o libgcc/./_gcov_merge_single .o ../../gcc/gcc/libgcov.c: In function '__gcov_merge_single': ../../gcc/gcc/libgcov.c:652: internal compiler error: in default_secondary_reloa d, at targhooks.c:529 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [libgcc/./_gcov_merge_single.o] Error 1 -- Summary: libgcov.c:652: ICE: in default_secondary_reload, at targhooks.c:529 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* GCC host triplet: hppa*-*-* GCC target triplet: hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25027
[Bug middle-end/25027] [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload, at targhooks.c:529
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-24 23:14 --- I see that you are having a bad couple of weeks. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Keywords||build, ice-on-valid-code Summary|libgcov.c:652: ICE: in |[4.2 Regression] |default_secondary_reload, at|libgcov.c:652: ICE: in |targhooks.c:529 |default_secondary_reload, at ||targhooks.c:529 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25027
[Bug middle-end/25027] [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload, at targhooks.c:529
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-24 23:22 --- Subject: Re: [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload, at targhooks.c:529 I see that you are having a bad couple of weeks. Yah. Definitely, slows progress on PA specific stuff. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25027
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #41 from debian-gcc at lists dot debian dot org 2005-11-24 23:29 --- builds on alpha-linux, powerpc-linux, mips-linux, s390-linux (Debian unstable) with the patch from the attachment and the patch from #39. No test results yet. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug middle-end/25027] [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload, at targhooks.c:529
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-24 23:55 --- Subject: Re: [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload, at targhooks.c:529 I see that you are having a bad couple of weeks. Thing were somewhat better before r107468. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25027
[Bug other/25028] New: TImode-to-floating conversions broken
int printf(const char *, ...);
typedef int TItype __attribute__((mode(TI)));
TItype x = -1;
int main(void) { printf(%f %f\n, (float)x, (double)x); return 0; }
displays
0.00 0.00
on x86_64-unknown-linux-gnu. The conversion functions in libgcc2.c work for
converting DImode values on the presumption that SImode values can be converted
exactly to DFmode and wider. They don't work for converting TImode values to
types which can't exactly represent all DImode values.
(I'd say these functions should have #if conditionals embodying their
prerequisites about type precisions, to make build fail for unsupported
combinations, but existing targets need fixing first.)
--
Summary: TImode-to-floating conversions broken
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25028
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #9 from mckelvey at maskull dot com 2005-11-25 02:01 --- I always build in an empty directory. After configuring, what good would a make clean do? Anyway, I noticed a complaint in the build log that makeinfo was too old. I installed the latest texinfo and was able to build to completion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #9 from joseph at codesourcery dot com 2005-11-25 02:51 ---
Subject: Patch for sparc-solaris build failure
This patch fixes some of the problems associated with the use of
libcalls for unsigned-to-floating conversions (bug 24998). The
underlying problem was that my patch did not allow for targets which
defined their own libcall names, referring to functions in libc.
It does not address the powerpc64-linux problem (where
config/rs6000/ppc64-fp.c needs unsigned functions added); I understand
from IRC that someone has an unsubmitted patch for that already. It
does not address the arm-netbsdelf problem (__floatsidf in libc),
which really needs to be addressed by someone who can test that
platform; likewise any other platform with the GNU names in libc.
Of the platforms using libcalls to libc, it fixes the issue for SPARC
(_Q_utoq specified in the ABI, _Q_ulltoq from the Solaris libc) and
PowerPC (_q_utoq in the ABI; for some reason glibc's
sysdeps/powerpc/soft-fp/q_utoq.c defines _q_uitoq but this looks like
a bug given the ABI and given that the Versions file says _q_utoq).
It doesn't fix the issue for ia64-hpux, which I intend to address in a
followup patch (the HP-UX libc has _U_Qfcnvxuf_dbl_to_quad for
unsigned DImode to TFmode conversion, but nothing for unsigned SImode
to TFmode conversion so I'll add a C wrapper). I can't test hppa-hpux
right now though the issues are probably similar. In the cases of
MIPS and FRV I hope the relevant maintainers can help. The MIPS issue
seems only to be with mips16.S which needs implementations of the
relevant functions. The FRV issue is that there are trivial C
implementations of the form
double __uitod (unsigned int a)
{
return a;
}
but unlike for the signed functions there is nothing to make the
compiler call those names; if the intention was for these functions to
use the wrapper around a signed libcall the compiler formerly
generated, the right approach (given that this seems to be a
soft-float target) might be to remove these trivial implementations
and instead treat them just like the signed functions.
The tests are much bigger than the rest of the patch, and I hope for
the most part more thorough than gcc.c-torture/execute/conversion.c
which tests similar things (and gets largely optimized away at higher
optimization levels).
If one of the included testcases fails on your platform because of
undefined references to __floatun*, and it does not have a
corresponding undefined reference to the corresponding signed
conversion function without un in the name, add a note to bug 24998.
If it fails for any other reason indicating a bug in GCC, open an
appropriate new bug if there isn't one already (I filed bug 25028 for
a problem with TImode conversions being broken, shown up by the
testcases). Some tests may fail because of external issues: the
__float128 tests are XFAILed on x86/x86_64 because they need an
external library implementing the TFmode functions (but when the fixes
are complete they should work OK on ia64-hpux which has enough
functions in libc).
I've verified that this patch makes a sparc-sun-solaris2.8 build go
beyond where it previously failed, and tested the new testcases for
syntax and XFAILs on x86_64-unknown-linux-gnu. OK to commit?
2005-11-25 Joseph S. Myers [EMAIL PROTECTED]
PR middle-end/24998
* config/rs6000/rs6000.c (rs6000_init_libfuncs): Use _q_utoq for
unsigned conversions from SImode to TFmode.
* config/sparc/sparc.c (sparc_init_libfuncs): Use _Q_utoq and
_Q_ulltoq for unsigned conversions from SImode and DImode to
TFmode.
testsuite:
2005-11-25 Joseph S. Myers [EMAIL PROTECTED]
PR middle-end/24998
* gcc.dg/torture/fp-int-convert-float.c,
gcc.dg/torture/fp-int-convert-double.c,
gcc.dg/torture/fp-int-convert-long-double.c,
gcc.dg/torture/fp-int-convert-timode.c,
gcc.dg/torture/fp-int-convert-float80.c,
gcc.dg/torture/fp-int-convert-float80-timode.c,
gcc.dg/torture/fp-int-convert-float128.c,
gcc.dg/torture/fp-int-convert-float128-timode.c,
gcc.dg/torture/fp-int-convert.h: New files.
diff -rupN GCC.orig/gcc/config/rs6000/rs6000.c GCC/gcc/config/rs6000/rs6000.c
--- GCC.orig/gcc/config/rs6000/rs6000.c 2005-11-23 14:11:11.0 +
+++ GCC/gcc/config/rs6000/rs6000.c 2005-11-24 23:34:31.0 +
@@ -9078,6 +9078,7 @@ rs6000_init_libfuncs (void)
set_conv_libfunc (sfix_optab, SImode, TFmode, _q_qtoi);
set_conv_libfunc (ufix_optab, SImode, TFmode, _q_qtou);
set_conv_libfunc (sfloat_optab, TFmode, SImode, _q_itoq);
+ set_conv_libfunc (ufloat_optab, TFmode, SImode, _q_utoq);
}
}
diff -rupN GCC.orig/gcc/config/sparc/sparc.c GCC/gcc/config/sparc/sparc.c
--- GCC.orig/gcc/config/sparc/sparc.c 2005-10-28 23:33:40.0 +
+++ GCC/gcc/config/sparc/sparc.c2005-11-24 23:40:27.0 +
@@ -7707,12 +7707,14 @@
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #10 from jsm28 at gcc dot gnu dot org 2005-11-25 03:53 --- Subject: Bug 24998 Author: jsm28 Date: Fri Nov 25 03:53:30 2005 New Revision: 107481 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107481 Log: PR middle-end/24998 * gcc/config/rs6000/rs6000.c (rs6000_init_libfuncs): Use _q_utoq for unsigned conversions from SImode to TFmode. * gcc/config/sparc/sparc.c (sparc_init_libfuncs): Use _Q_utoq and _Q_ulltoq for unsigned conversions from SImode and DImode to TFmode. * gcc/testsuite/gcc.dg/torture/fp-int-convert-float.c, gcc/testsuite/gcc.dg/torture/fp-int-convert-double.c, gcc/testsuite/gcc.dg/torture/fp-int-convert-long-double.c, gcc/testsuite/gcc.dg/torture/fp-int-convert-timode.c, gcc/testsuite/gcc.dg/torture/fp-int-convert-float80.c, gcc/testsuite/gcc.dg/torture/fp-int-convert-float80-timode.c, gcc/testsuite/gcc.dg/torture/fp-int-convert-float128.c, gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode.c, gcc/testsuite/gcc.dg/torture/fp-int-convert.h: New files. Added: branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-double.c branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-float.c branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128-timode.c branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-float128.c branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-float80-timode.c branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-float80.c branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-long-double.c branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode.c branches/csl-ppc4xx-branch/gcc/testsuite/gcc.dg/torture/fp-int-convert.h Modified: branches/csl-ppc4xx-branch/ChangeLog.csl branches/csl-ppc4xx-branch/gcc/config/rs6000/rs6000.c branches/csl-ppc4xx-branch/gcc/config/sparc/sparc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #11 from jsm28 at gcc dot gnu dot org 2005-11-25 03:57 --- Subject: Bug 24998 Author: jsm28 Date: Fri Nov 25 03:57:22 2005 New Revision: 107483 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107483 Log: PR middle-end/24998 * config/rs6000/rs6000.c (rs6000_init_libfuncs): Use _q_utoq for unsigned conversions from SImode to TFmode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24990] fold should convert ~a != C to a != ~C where C is a constant
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-25 04:55 --- Subject: Bug 24990 Author: pinskia Date: Fri Nov 25 04:54:59 2005 New Revision: 107487 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107487 Log: 2005-11-25 Andrew Pinski [EMAIL PROTECTED] PR middle-end/24990 * fold-const.c (fold_binary): Fold (~a) == C to a == ~C for C being INTEGER_CST. Likewise for !=. 2005-11-24 Andrew Pinski [EMAIL PROTECTED] PR middle-end/24990 * tree-ssa/pr24990-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr24990-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24990
[Bug middle-end/24990] fold should convert ~a != C to a != ~C where C is a constant
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-25 04:55 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24990
[Bug middle-end/24989] boolvar != 1 is not converted to !boolvar
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-25 05:05 --- Subject: Bug 24989 Author: pinskia Date: Fri Nov 25 05:05:26 2005 New Revision: 107488 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107488 Log: 2005-11-25 Andrew Pinski [EMAIL PROTECTED] PR middle-end/24989 * fold-const.c (fold_build): Convert bool_var != 1 and bool_var == 0 to !bool_var. 2005-11-24 Andrew Pinski [EMAIL PROTECTED] PR middle-end/24989 * gcc.dg/tree-ssa/bool-10.c: New test. * gcc.dg/tree-ssa/bool-11.c: New test. * gcc.dg/tree-ssa/bool-7.c: Un-xfail. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/bool-10.c trunk/gcc/testsuite/gcc.dg/tree-ssa/bool-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/bool-7.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24989
[Bug middle-end/24989] boolvar != 1 is not converted to !boolvar
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-25 05:05 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24989
[Bug middle-end/18908] Missed folding opportunities with bools
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-25 05:06 --- So now truely only f1 is the only one to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
[Bug tree-optimization/24575] -(i /- 10) is not foldded to i/-10
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-25 05:24 --- (In reply to comment #1) Confirmed, part of the issue here is that -i/10 is not converted to i/10 That should have been i/-10. I am going to make this bug about -(i/-10) to i/10. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|-(-i / 10) is not foldded to|-(i /- 10) is not foldded to |i/10|i/-10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24575
[Bug middle-end/23669] fold does convert (-a)/10 into a/-10 with -fno-wrapv
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-25 06:17 --- Ok, I have a patch which copies the code for Real divides into the int divides, though it adds !flag_wrapv. Though I am worry about the non truncate divide, I think it should be the same for them but for some reason I am worried. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23669
[Bug testsuite/23400] [4.1/4.2 Regression] make check fixinclude failure
--- Comment #8 from bkorb at gnu dot org 2005-11-25 07:25 --- A couple of issues: 1. Replacement fixes should not be checked, so it is interesting that the failure shows up. 2. fixincl should not create files without terminating new lines anyway. I've just applied a patch to fixfixes.c to fix this problem. I'll look into the former issue when my bootstrap finishes:) I'd assign this thing to myself, but I guess I'm not powerful enough -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23400
