[Bug other/32185] unused result warnings and -werror
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-02 06:16 --- First you should be using the trunk to create patches. Second we do check later on if there was an error on the write so I think glibc is wrong in warning about this case. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32185
[Bug fortran/32049] Support on x86_64 also kind=16
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-02 07:37 --- (In reply to comment #2) http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/ieee754/?cvsroot=glibc Look into ldbl-128 directory... I don't think that's built into glibc on x86_64, is it? And, as far as I know, politics prevents us from integrating parts of glibc into gcc (the libgcc-math issue). What do you think is the best route for us? Can we convince the glibc maintainers to build and expose that library? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-02 07:37:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #15 from rakdver at kam dot mff dot cuni dot cz 2007-06-02 07:49 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop Has anyone measured impact of adding DCE on SPEC CPU 2000/2006 peformance? Take a look at: http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/172_mgrid_recent_big.png actually, the mgrid jump is due to predictive commoning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug fortran/25252] ICE on invalid code
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-06-02 08:30 --- I have a patch for PR18923 that also appears to fix this. Testing now. I think this is a duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug c++/32186] New: -ggdb emits broken debug info
Compiling with 'g++ -ggdb' confuses both gdb-6.5 and gdb-6.6 into thinking
they've got corrupted stacks. My programs all seem to execute properly, both
alone and inside gdb -- it's just hard to debug anything. Using 'g++ -g'
instead seems to work fine.
Consider 'g++ -ggdb foo.cpp' with the following code snippet:
void foo() {
int i;
i=1;
}
int main() {
foo();
return 0;
}
Below is the gdb output as I step through the resulting executable.
Current directory is c:/cygwin/home/johnsory/experiments/
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) start
Breakpoint 1 at 0x401071: file foo.cpp, line 6.
Starting program: /home/johnsory/experiments/a.exe
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
main () at foo.cpp:6
(gdb) step
(gdb) bt
#0 main () at foo.cpp:7
(gdb) step
foo () at foo.cpp:1
(gdb) bt
#0 foo () at foo.cpp:1
#1 0x00401050 in mainCRTStartup ()
(gdb) step
(gdb) bt
#0 foo () at foo.cpp:3
#1 0x00401056 in foo () at foo.cpp:1
#2 0x00401056 in foo () at foo.cpp:1
#3 0x00401056 in foo () at foo.cpp:1
#4 0x00401056 in foo () at foo.cpp:1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) step
(gdb) bt
#0 foo () at foo.cpp:4
#1 0x0040105d in foo () at foo.cpp:3
#2 0x0040105d in foo () at foo.cpp:3
#3 0x0040105d in foo () at foo.cpp:3
#4 0x0040105d in foo () at foo.cpp:3
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) step
main () at foo.cpp:8
(gdb) bt
#0 main () at foo.cpp:8
(gdb) step
(gdb) bt
#0 main () at foo.cpp:9
(gdb) step
0x61006198 in dll_crt0_1 () from /usr/bin/cygwin1.dll
(gdb) bt
#0 0x61006198 in dll_crt0_1 () from /usr/bin/cygwin1.dll
#1 0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll
#2 0x in ?? ()
(gdb) step
Single stepping until exit from function _Z10dll_crt0_1Pv,
which has no line number information.
Program exited normally.
(gdb)
--
Summary: -ggdb emits broken debug info
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32186
[Bug c++/32186] -ggdb emits broken debug info
--- Comment #1 from scovich at gmail dot com 2007-06-02 09:37 --- It also appears that 'next' is broken and acts like 'step' (enter all functions), while 'finish' acts like 'continue' (run to completion, barring a breakpoint). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32186
[Bug fortran/31310] gfortran is missing -fcase-preserve option
--- Comment #3 from mralanmorgan at gmail dot com 2007-06-02 09:51 --- Wow. Nothing is happening. Glad I bothered raising the bug. Now I know not to waste time documenting the other ten or so bugs I've found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug fortran/29819] Error/warning message should ignore comments for 1 in %C output
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-02 11:32 --- *** Bug 30942 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29819
[Bug fortran/30942] Error location is wrong in error message
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-02 11:32 --- *** This bug has been marked as a duplicate of 29819 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30942
[Bug fortran/29819] Error/warning message should ignore comments for 1 in %C output
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-02 11:33:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29819
[Bug c++/32182] [4.2 Regression] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-02 11:35 --- Confirmed. Actually compiling Wrapper.cxx with -fstrict-aliasing is enough to trigger the failure. In getItem() the difference is bb 2: - D.3769 = _local_result + 4B; - this = (struct BaseClass *) D.3769; - this-d_self = 0B; + D.3821 = _local_result + 4B; + this = (struct BaseClass *) D.3821; this = (struct NextClass *) _local_result; iftmp.0 = (int (*__vtbl_ptr_type) (void) *) _ZTT9TestClass[2]; - this-_vptr.NextClass = iftmp.0; _local_result.D.2186._vptr.NextClass = _ZTV9TestClass[4]; this-_vptr.NextClass = _ZTV9TestClass[4]; D.2853 = at (cont-d_cont, ind) [return slot optimization]; in addItem() @@ -547,14 +541,12 @@ tmp.D.2186._vptr.NextClass = _ZTV9TestClass[4]; this.9 = (struct NextClass *) tmp; this.9-_vptr.NextClass = (int (*__vtbl_ptr_type) (void) *) _ZTT9TestClass[2] ; - D.4100 = tmp + 4B; - this = (struct BaseClass *) D.4100; - D.4135 = this-d_self; - if (D.4135 != 0B) goto L21; else goto L12; + D.4160 = tmp + 4B; + D.4195 = ((struct BaseClass *) D.4160)-d_self; + if (D.4195 != 0B) goto L21; else goto L12; L21:; - deleteRef (D.4135); - this-d_self = 0B; + deleteRef (D.4195); L12:; exception object = save_eptr.48; @@ -565,14 +557,12 @@ tmp.D.2186._vptr.NextClass = _ZTV9TestClass[4]; this.9 = (struct NextClass *) tmp; this.9-_vptr.NextClass = (int (*__vtbl_ptr_type) (void) *) _ZTT9TestClass[2] ; - D.4155 = tmp + 4B; - this = (struct BaseClass *) D.4155; - D.4190 = this-d_self; - if (D.4190 != 0B) goto L39; else goto L4; + D.4215 = tmp + 4B; + D.4250 = ((struct BaseClass *) D.4215)-d_self; + if (D.4250 != 0B) goto L39; else goto L4; L39:; - deleteRef (D.4190); - this-d_self = 0B; + deleteRef (D.4250); Note that making the inheritance non-virtual and fixing up TestClass::TestClass(TestClass::ior_t*) to initialize NextClass instead of BaseClass fixes the problem as well. So this may be a C++ frontend problem with virtual inheritance or an invalid testcase as well. (What happens if you initialize BaseClass from TestClass, but not NextClass -- if NextClass is default constructed then it will default construct BaseClass as well? C++ language lawyer question.) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||alias, wrong-code Last reconfirmed|-00-00 00:00:00 |2007-06-02 11:35:26 date|| Summary|-fstrict-aliasing |[4.2 Regression] -fstrict- |optimizations cause |aliasing optimizations cause |constructor not to run for |constructor not to run for |object causing segfault |object causing segfault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug c++/32182] [4.2 Regression] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-06-02 11:45 --- It looks like 12.6.2/5-6 specify it enough to make the testcase valid. The BaseClass is only once initialized by the most derived object initializer specification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
[Bug fortran/31310] gfortran is missing -fcase-preserve option
--- Comment #4 from burnus at gcc dot gnu dot org 2007-06-02 12:45 --- Wow. Nothing is happening. You are right that unfortunately not much happened regarding this feature request during the last two and a half months, however, in total quite a lot happened: http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/ChangeLog?view=log The current focus is on fixing those bugs which reject valid Fortran 95 code. (Note that most gfortran work is done in the spare time, which inevitable slows down the development.) Regarding this feature request: The problem is that the input is quite early converted to lower case, namely in gfc_next_char(). The task is now to preserve the case for all symbols, but keep the case-insensitivity for keywords. Actually, it is not clear where to preserve the case and where not: - IF, ELSE, CALL - .true., .false. (vs. .userDefinedOp.) - .eq. - OPEN, CLOSE, INQUIRE, integer, Real - Intrinsic procedures: int(), cmplx(), cos(), sizeof(), get_command_argument() - open(UNIT=, int(..., KiNd=, ...) (The Fortran 77/90/95/2003/2008draft standard requires case insensitivity throughout.) I try to find some time to work on this feature request, but I don't want to make any promises time wise. Glad I bothered raising the bug. Now I know not to waste time documenting the other ten or so bugs I've found. Especially internal compiler errors or rejection of valid Fortran 95 code have a high priority and might well be fixed in =48h (or take a month); trivial other problems might be also fixed relatively quickly. Thus please report the your bugs - we depend on bugreports; at least the goal is to fix all reported bugs and feature requests, even if it takes sometimes over a year :-( [Currently, there are 283 open bugs/feature requests.] Not that is helps with big legacy code, but for new program one can use Fortran 2003's ISO C Bindings, which allow to give procedures and global variable a case sensitive name; gfortran support this in the Fortran-Experimental branch and it will soon be merged into 4.3: function Foo() bind(c,name=_My_Case_Sensitive_Name) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31310
[Bug target/32187] New: Complex __float128 is rejected
I've been trying to use the complex type associated with __float128, but it's
rejected:
$ cat u.c
int main (void) { __complex__ __float128 z; }
$ gcc u.c
u.c: In function main:
u.c:1: error: expected =, ,, ;, asm or __attribute__ before z
--
Summary: Complex __float128 is rejected
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug bootstrap/29196] gcc fails to build on x86-64 linux
--- Comment #2 from begert at gmail dot com 2007-06-02 13:18 --- (In reply to comment #1) /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or direc\ tory That means you don't have the 32bit userland installed which means you either use --disable-multilib or install it. I have this same problem, the issue is that my stubs-32.h is located in /usr/include/i486-linux-gnu/gnu/stubs-32.h not in /usr/local/gnu. I am running kubunut 7.04 64bit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29196
[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop
--- Comment #16 from hjl at lucon dot org 2007-06-02 14:20 --- Here are SPEC CPU 2K -O2 -ffast-math differences between revision 125029 and revision 125029 on Intel64 C2D: (r125030 - r125029)/r125029 164.gzip 0.0706714% 175.vpr -0.116077% 176.gcc -1.83805% 181.mcf 0.968263% 186.crafty 0.351975% 197.parser -0.15456% 252.eon -0.324675% 253.perlbmk -0.0394945% 254.gap -0.318471% 255.vortex 0.211775% 256.bzip20.300601% 300.twolf0% Est. SPECint_base2000-0.0983284% 168.wupwise 0.92511% 171.swim -0.0767165% 172.mgrid0.179856% 173.applu-3.62731% 177.mesa 0.0398565% 178.galgel -4.55329% 179.art -1.38686% 183.equake 0.303819% 187.facerec -0.383583% 188.ammp -0.7768% 189.lucas-1.30465% 191.fma3d1.38667% 200.sixtrack -0.135318% 301.apsi 0.0545256% Est. SPECfp_base2000 -0.660502% Here are SPEC CPU 2K -O2 -ffast-math differences between revision 125029 with DCE change disabled and revision 125029 on Intel64: (r125030 no DCE - r125029)/r125029 164.gzip 0.0706714% 175.vpr 0% 176.gcc 0% 181.mcf 0.484131% 186.crafty 0.195542% 197.parser -0.15456% 252.eon -0.202922% 253.perlbmk 0.35545% 254.gap 0.181984% 255.vortex 0.16942% 256.bzip2-0.150301% 300.twolf0.0389257% Est. SPECint_base20000.0983284% 168.wupwise 0.264317% 171.swim -0.0383583% 172.mgrid0% 173.applu0.0711238% 177.mesa 0% 178.galgel 0.123062% 179.art -3.16302% 183.equake 0.0434028% 187.facerec -0.115075% 188.ammp 0.0517866% 189.lucas0.0705219% 191.fma3d0% 200.sixtrack -0.135318% 301.apsi 0.163577% Est. SPECfp_base2000 -0.176134% Given the impact of DCE change, it isn't a real surprise. It not only may not optimize loop, but may make a loop to run slow. I will bet you will find the similar results on other architectures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
[Bug other/32188] New: DFP instrinic document is out of date
We have DPD and BID versions of DFP instrinsics. However, libgcc.texi still documents the old intrinsic names. -- Summary: DFP instrinic document is out of date Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32188
[Bug other/32188] DFP instrinic document is out of date
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-02 16:14 --- Well considering this was introduced by you (and Michael Meissner and Marius Cornea). It seems like you should have just fixed it instead of filing a bug :). -- 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 |2007-06-02 16:14:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32188
[Bug target/32189] New: FAIL: gcc.target/i386/sse-13.c
I got
bash-3.1$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.target/i386/sse-13.c -O2 -msse4.1
-msse4a -fno-show-column -S -m32 -o sse-13.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/smmintrin.h: In function
â_mm_blendv_pdâ:
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/smmintrin.h:136: error:
unable to find a register to spill in class âFIRST_SSE_REGâ
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/smmintrin.h:136: error:
this is the insn:
(insn:HI 14 8 20 2
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/smmintrin.h:136 (set
(reg/i:V2DF 21 xmm0 [ result ])
(unspec:V2DF [
(reg:V2DF 21 xmm0 [ __X ])
(reg:V2DF 22 xmm1 [ __Y ])
(reg:V2DF 23 xmm2 [ __M ])
] 134)) 1243 {sse4_1_blendvpd} (nil)
(expr_list:REG_DEAD (reg:V2DF 23 xmm2 [ __M ])
(expr_list:REG_DEAD (reg:V2DF 22 xmm1 [ __Y ])
(nil
/export/build/gnu/gcc/build-x86_64-linux/gcc/include/smmintrin.h:136: confused
by earlier errors, bailing out
--
Summary: FAIL: gcc.target/i386/sse-13.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32189
tiff compile error
I cannot compile tiff in my system, FreeBSD ports, with error msg internal compiler error: Segmentation fault: 11 Please submit a full bug report. Details are listed below. * the exact version of GCC; GCC 3.4.4 * the system type; FreeBSD 6.1 release-p17 * the options given when GCC was configured/built; No any option to configure * the complete command line that triggers the bug; tif_stream.cxx:238: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Thank you very much.
[Bug target/32189] FAIL: gcc.target/i386/sse-13.c
--- Comment #1 from ubizjak at gmail dot com 2007-06-02 18:38 --- Fixed by reverting the patch that caused the failure. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|FAIL: gcc.target/i386/sse- |FAIL: gcc.target/i386/sse- |13.c|13.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32189
[Bug fortran/32124] Execution stops with stat= in ALLOCATE
--- Comment #9 from dominiq at lps dot ens dot fr 2007-06-02 19:09 --- It also fails on powerpc-linux (32bits). It also fails on powerpc-apple-darwin7.9.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32124
[Bug target/32187] Complex __float128 is rejected
--- Comment #1 from ubizjak at gmail dot com 2007-06-02 19:44 ---
Is this a parser problem? Compilation fails even for generic:
--cut here--
typedef float DFtype __attribute__((mode(DF)));
__complex__ DFtype z;
void test(void) { z = 1.0+2.0i; }
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug c++/32190] New: bad diagnostic
This code:
templatetypename T class foo{ };
int main() {
fooint i;
foofooint j;
int k;
int l;
fooint m;
return 0;
}
gets you:
~/ootbc/sim/sandbox$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:8: error: template argument 1 is invalid
foo.cc:8: error: invalid type in declaration before ';' token
~/ootbc/sim/sandbox$ fg
The real problem is a missing three lines earlier.
--
Summary: bad diagnostic
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug target/32187] Complex __float128 is rejected
--- Comment #2 from joseph at codesourcery dot com 2007-06-02 20:09 --- Subject: Re: Complex __float128 is rejected On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote: Is this a parser problem? Compilation fails even for generic: --cut here-- typedef float DFtype __attribute__((mode(DF))); __complex__ DFtype z; Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the possible sets of type specifiers. __float128 is a built-in typedef, but there probably is a case for allowing certain such typedefs to be treated like keywords with regard to adding _Complex, signed or unsigned. You should be able to use typedef _Complex float TCtype __attribute__((mode(TC))); or similar to access _Complex __float128 at present. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug target/32187] Complex __float128 is rejected
--- Comment #3 from gdr at cs dot tamu dot edu 2007-06-02 20:28 --- Subject: Re: Complex __float128 is rejected joseph at codesourcery dot com [EMAIL PROTECTED] writes: | Subject: Re: Complex __float128 is rejected | | On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote: | | Is this a parser problem? Compilation fails even for generic: | | --cut here-- | typedef float DFtype __attribute__((mode(DF))); | | __complex__ DFtype z; | | Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the | possible sets of type specifiers. Out of curiosity, do you happen to know why typedefs to floating point types should be disallowed? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug c++/32190] bad diagnostic
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-02 20:57 --- On the mainline I just get: t.cc: In function 'int main()': t.cc:7: error: template argument 1 is invalid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug target/32189] [4.3 Regression] FAIL: gcc.target/i386/sse-13.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: gcc.target/i386/sse- |[4.3 Regression] FAIL: |13.c|gcc.target/i386/sse-13.c Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32189
[Bug target/32191] New: ICE with complex __float128
That one is weird, because it's only triggered with -std=c99 (or -std=gnu99):
$ cat foo.c
void foo ()
{
typedef _Complex float __attribute__((mode(TC))) c128;
c128 x, y;
x *= y;
}
$ gcc -c foo.c
$ gcc -c -std=c99 foo.c
foo.c: In function foo:
foo.c:6: internal compiler error: Segmentation fault
--
Summary: ICE with complex __float128
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191
[Bug target/32191] ICE with complex __float128
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-02 21:06 ---
This works for me with powerpc64-linux-gnu which has a TCmode.
I think the reason why it is only triggered with -std=c99/-std=gnu99 is because
__multc3 is only called then. __multc3 returns a TCmode. So you most likely
can also reproduce it with:
typedef _Complex float __attribute__((mode(TC))) c128;
c128 g(void);
void foo ()
{
c128 x, y;
x = g();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #20 from patchapp at dberlin dot org 2007-06-02 21:10 --- Subject: Bug number PR18923 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00111.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug target/32191] ICE with complex __float128
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-06-02 21:10
---
(In reply to comment #1)
typedef _Complex float __attribute__((mode(TC))) c128;
c128 g(void);
void foo ()
{
c128 x, y;
x = g();
}
Nope. That one doesn't ICE. The backtrace for the ICE my code in the original
PR is:
Program received signal SIGSEGV, Segmentation fault.
build_call_expr (fndecl=0x0, n=4) at ../../trunk/gcc/builtins.c:10379
10379 tree fntype = TREE_TYPE (fndecl);
(gdb) where
#0 build_call_expr (fndecl=0x0, n=4) at ../../trunk/gcc/builtins.c:10379
#1 0x0068d0bd in expand_complex_libcall (bsi=0x7fbfffed20, ar=Variable
ar is not available.
)
at ../../trunk/gcc/tree-complex.c:903
#2 0x0068ff78 in tree_lower_complex_O0 ()
at ../../trunk/gcc/tree-complex.c:1560
#3 0x005fb881 in execute_one_pass (pass=0xd3f080)
at ../../trunk/gcc/passes.c:1068
#4 0x005fba3c in execute_pass_list (pass=0xd3f080)
at ../../trunk/gcc/passes.c:1120
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32191
[Bug target/32187] Complex __float128 is rejected
--- Comment #4 from joseph at codesourcery dot com 2007-06-02 21:35 --- Subject: Re: Complex __float128 is rejected On Sat, 2 Jun 2007, gdr at cs dot tamu dot edu wrote: | Of course, 6.7.2 paragraph 2 does not include _Complex typedef-name in the | possible sets of type specifiers. Out of curiosity, do you happen to know why typedefs to floating point types should be disallowed? Typedefs have never been allowed along with other type specifiers; it's much the same as not allowing unsigned T or T unsigned where T is a typedef for int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug target/31679] Incorrect result of multiplication long long by 0xFFFFFFFFLL constant.
--- Comment #6 from tromey at gcc dot gnu dot org 2007-06-02 21:52 --- I see this bug when I compile the test case without -O. I tried svn trunk and also 4.1.1 20070105 (Red Hat 4.1.1-51) -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-02 21:52:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31679
[Bug fortran/25052] intrinsic name cannot be a common block name
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-06-02 23:20 --- Closing. I get an error message that seems OK -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25052
[Bug c++/32190] bad diagnostic
--- Comment #2 from igodard at pacbell dot net 2007-06-02 23:40 --- Either way, it is reporting on the first line after the point of actual error that contains a use of a template. The space between error and report is thus arbitrarily large and may cross files, and the flagged line has nothing wrong on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32190
[Bug other/32185] unused result warnings and -werror
--- Comment #3 from robert at linuxfromscratch dot org 2007-06-03 00:50 --- I checked whether it was fixed in trunk, but you're right I should have made a patch that applies to trunk. Glibc is giving a false positive here, but the programmer and compiler are the only ones able to know. Could the check in the code be moved futher up so the compiler can see that the checking is being done? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32185
[Bug c++/32192] New: Assembler errors compiling g++
$ g++ -c -g -fno-elide-constructors -DNO_INTL=1 -pedantic-errors -Werror -ansi -fno-common -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith -Wundef -Wwrite-strings -Winvalid-pch -Woverloaded-virtual -Wcast-qual -Wextra -Wredundant-decls -Wshadow -Wcast-align -Wcomment -fstrict-aliasing -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wlogical-op -Wunused -MMD -fimplicit-templates -I. -I.. -o test049.o --save-temps test049.cc test049.s: Assembler messages: test049.s:1631: Warning: end of file in string; '' inserted test049.s:1640: Warning: .stabs: missing comma $ uname -a CYGWIN_NT-5.1 McKelvey-PC 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin $ g++ -v Using built-in specs. Target: i686-pc-cygwin Configured with: /cygdrive/f/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --disable-win32-registry --enable-languages=c,c++ Thread model: posix gcc version 4.3.0 20070527 (experimental) $ alias CONFIGURECVS alias CONFIGURECVS='/cygdrive/f/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --disable-win32-registry --enable-languages=c,c++' $ alias BUILD alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g -O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' bootstrap' -- Summary: Assembler errors compiling g++ Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mckelvey at maskull dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32192
[Bug c++/32192] Assembler errors compiling g++
--- Comment #1 from mckelvey at maskull dot com 2007-06-03 01:39 --- Created an attachment (id=13652) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13652action=view) ii and s files from compilation in b2zipped tar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32192
[Bug fortran/23852] Array element as format specification.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-03 01:55 --- Closing, Did not here any objections. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23852
[Bug other/32185] unused result warnings and -werror
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-03 02:00 --- Could the check in the code be moved futher up so the compiler can see that the checking is being done? Not if glibc is marking the functions as warn_unused_result. Also the front-end would need some flow analysis to figure out if a warning is needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32185
[Bug fortran/24965] Wrong file name in error message
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-06-03 03:27 --- The Comment #3 example is not the same as the original report. The attached example is already preprocessed source with file name information embedded in lines beginning with '#' This is handled in scanner.c. The filenames are being extracted properly in the function preprocessor_line(). The filename information is not getting into the scanners gfc_line and gfc_file structures correctly. I would guess it needs to fixed around about line 1492 of scanner.c. Looks like we are just not doing anything with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24965
[Bug target/32163] Compiling with stack protector causes reigster spill failure
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-06-03 04:39 --- Subject: Bug 32163 Author: kkojima Date: Sun Jun 3 04:38:52 2007 New Revision: 125292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125292 Log: PR target/32163 * config/sh/sh.md (symGOT_load): Don't schedule insns when the symbol is generated with the stack protector. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32163
[Bug libgomp/32193] New: Upgrading GNU/Linux to libc6_2.6~20070518-2 breaks libgomp make - FIX given
Compiled gcc version 4.3.0 20070602 with tzdata 2007b-1 and libc6 2.3.6.ds1-13 everything went well enough and make -i check was not too bad ... Decided to upgrade. Everything compiled fine until the _last_ library (of course), otherwise it would have worked fine. wget http://ftp.debian.org/debian/pool/main/t/tzdata/tzdata_2007f-6_all.deb wget http://ftp.debian.org/debian/pool/main/g/glibc/libc6_2.6~20070518-2_i386.deb dpkg -i tzdata_2007f-6_all.deb dpkg -i libc6_2.6~20070518-2_i386.deb Notes in /etc/init.d/glibc.sh # The GNU libc requires 2.6 kernel (except on m68k) because we drop to support linuxthreads # HPPA boxes require latest fixes (2.6.9 ) in the kernel to function properly. # The GNU libc is now built with --with-kernel= = 2.4.1 on m68k Notes in /usr/share/doc/libc6/README All Linux kernel versions prior to 2.6.16 are known to have some bugs that may cause some of the tests related to pthreads in make check to fail. If you see such problems, please try the test suite on the most recent Linux kernel version that you can use, before pursuing those bugs further. # Echo Yes, this is a legal command # /lib/libc-2.6.so GNU C Library stable release version 2.6, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.1.3 20070514 (prerelease) (Debian 4.1.2-7). Compiled on a Linux 2.6.20-1-686 system on 2007-05-20. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B # /lib/libpthread-2.6.so Native POSIX Threads Library by Ulrich Drepper et al Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Forced unwind support included. Here is the problem: if /bin/sh ./libtool --tag=CC --mode=compile /opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libgomp -I. -I/root/downloads/gcc-4_3-trunk/libgomp/config/linux/x86 -I/root/downloads/gcc-4_3-trunk/libgomp/config/linux -I/root/downloads/gcc-4_3-trunk/libgomp/config/posix -I/root/downloads/gcc-4_3-trunk/libgomp -Wall -Werror -ftls-model=initial-exec -Wc,-pthread -O2 -g -O2 -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c -o proc.lo /root/downloads/gcc-4_3-trunk/libgomp/config/linux/proc.c; \ then mv -f .deps/proc.Tpo .deps/proc.Plo; else rm -f .deps/proc.Tpo; exit 1; fi libtool: compile: /opt/gcc-4_3-build/./gcc/xgcc -B/opt/gcc-4_3-build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/root/downloads/gcc-4_3-trunk/libgomp -I. -I/root/downloads/gcc-4_3-trunk/libgomp/config/linux/x86 -I/root/downloads/gcc-4_3-trunk/libgomp/config/linux -I/root/downloads/gcc-4_3-trunk/libgomp/config/posix -I/root/downloads/gcc-4_3-trunk/libgomp -Wall -Werror -pthread -ftls-model=initial-exec -O2 -g -O2 -MT proc.lo -MD -MP -MF .deps/proc.Tpo -c /root/downloads/gcc-4_3-trunk/libgomp/config/linux/proc.c -fPIC -DPIC -o .libs/proc.o cc1: warnings being treated as errors /root/downloads/gcc-4_3-trunk/libgomp/config/linux/proc.c: In function 'gomp_init_num_threads': /root/downloads/gcc-4_3-trunk/libgomp/config/linux/proc.c:78: error: implicit declaration of function 'pthread_getaffinity_np' make[4]: *** [proc.lo] Error 1 make[4]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp' make[1]: *** [all-target-libgomp] Error 2 make[1]: Leaving directory `/opt/gcc-4_3-build' make: *** [all] Error 2 The function pthread_getaffinity_np is used in gcc-4_3-trunk/libgomp/config/linux/affinity.c and gcc-4_3-trunk/libgomp/config/linux/proc.c in functions gomp_init_affinity and gomp_init_num_threads . Also see this thread: bootstrap broken on powerpc: implicit declaration of function 'pthread_getaffinity_np' http://gcc.gnu.org/ml/gcc/2007-04/msg00814.html Following Andrew's advice I found this (first file is libc6_2.3.6, second is libc6_2.6~20070518-2): # diff -Naur /opt/gcc-4_3-build-libc6_2.3.6.ds1-13/i686-pc-linux-gnu/libgomp/config.log /opt/gcc-4_3-build/i686-pc-linux-gnu/libgomp/config.log --- /opt/gcc-4_3-build-libc6_2.3.6.ds1-13/i686-pc-linux-gnu/libgomp/config.log 2007-06-02 08:46:43.0 -0700 +++ /opt/gcc-4_3-build
[Bug libgomp/32193] Upgrading GNU/Linux to libc6_2.6~20070518-2 breaks libgomp make - FIX given
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-03 05:37 --- Change that to: /* #include pthread.h */ #include nptl/pthread.h That is wrong and non portable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193
