[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #23 from hubicka at gcc dot gnu dot org 2008-02-26 09:31 --- I guess we need 1) Get the patch to check overwritability of body to mainline and branch, since it is quite wrong to optimize based on knowledge of body that might be replaced 2) Figure out how to get Apple's linker in sync with Darwin backend in GCC. If the symbols are locally bound I guess the backend should just output the direct call, not via PLT table. If the objects are not locally bound we need to change the predicate. I am not terribly familiar with MACHOPIC, what is the case? (ie does MACHOPIC allow overwritting -fpic symbols like ELF?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #24 from jh at suse dot cz 2008-02-26 09:43 --- Subject: Re: Stack not aligned at mod 16 byte boundary in x86_64 code I guess we need 1) Get the patch to check overwritability of body to mainline and branch, since it is quite wrong to optimize based on knowledge of body that might be replaced 2) Figure out how to get Apple's linker in sync with Darwin backend in GCC. If the symbols are locally bound I guess the backend should just output the direct call, not via PLT table. If the objects are not locally bound we need to change the predicate. I am not terribly familiar with MACHOPIC, what is the case? (ie does MACHOPIC allow overwritting -fpic symbols like ELF?) So in short both fixes are at GCC rather than linker side, assuming that linker will link direct call to externally visible symbol at link time, rather than dynamic load time that would be case of ELF? Can someone check this? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug c++/35323] [4.3/4.4 regression] ICE calling functions with fixed-point type parameter
--- Comment #2 from paolo at gcc dot gnu dot org 2008-02-26 10:10 --- Subject: Bug 35323 Author: paolo Date: Tue Feb 26 10:09:43 2008 New Revision: 132669 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132669 Log: /cp 2008-02-26 Paolo Carlini [EMAIL PROTECTED] PR c++/35323 * name-lookup.c (arg_assoc_type): Handle FIXED_POINT_TYPE. /testsuite 2008-02-26 Paolo Carlini [EMAIL PROTECTED] PR c++/35323 * g++.dg/lookup/crash7.C: New. Added: trunk/gcc/testsuite/g++.dg/lookup/crash7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
[Bug ada/35372] New: Memory corruption at unchecked deallocation of the interface classwide type
Unchecked deallocation of the access to interface classwide type has corupt memory. Valgrind output: ==8176== Invalid read of size 4 ==8176==at 0x804EF32: system__finalization_implementation__finalize_list (s-finimp.adb:360) ==8176==by 0x804EFE8: system__finalization_implementation__finalize_global_list (s-finimp.adb:327) ==8176==by 0x8049611: main (b~driver.adb:171) ==8176== Address 0x4187030 is 8 bytes inside a block of size 16 free'd ==8176==at 0x402288A: free (vg_replace_malloc.c:323) ==8176==by 0x8051787: __gnat_free (s-memory.adb:117) ==8176==by 0x8049BBB: driver__z.182 (driver.adb:9) ==8176==by 0x8049B0A: _ada_driver (driver.adb:13) ==8176==by 0x804960C: main (b~driver.adb:170) ==8176== ==8176== Invalid read of size 4 ==8176==at 0x804EF37: system__finalization_implementation__finalize_list (s-finimp.adb:361) ==8176==by 0x804EFE8: system__finalization_implementation__finalize_global_list (s-finimp.adb:327) ==8176==by 0x8049611: main (b~driver.adb:171) ==8176== Address 0x4187028 is 0 bytes inside a block of size 16 free'd ==8176==at 0x402288A: free (vg_replace_malloc.c:323) ==8176==by 0x8051787: __gnat_free (s-memory.adb:117) ==8176==by 0x8049BBB: driver__z.182 (driver.adb:9) ==8176==by 0x8049B0A: _ada_driver (driver.adb:13) ==8176==by 0x804960C: main (b~driver.adb:170) ==8176== -- Summary: Memory corruption at unchecked deallocation of the interface classwide type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vgodunko at rostel dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35372
[Bug middle-end/35249] miscompilation of Emacs at -O
--- Comment #10 from simon dot marshall at misys dot com 2008-02-26 10:36 --- With CFLAGS=-g -O1 -fno-unit-at-a-time -fno-crossjumping -Wno-pointer-sign, I cannot hit the breakpoint on error (ie, if I put a breakpoint on error itself). Also, I cannot hit the breakpoint at intervals2.c:34 if I add -fno-delayed-branch to the compilation of intervals2.c. The original motivation for this report was that I was trying to reproduce the occasional problem of error being called (a this should never happen sanity check) at this place in the code. I thought I had managed to do that with the bugzilla reported simple sequence of events immediately after starting emacs. Does your finding suggest that my supposed reproduction of the error call was an illusion? (And that there is no miscompilation either.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35249
[Bug bootstrap/35373] New: [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578
As reported in http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01134.html, bootstraping on powerpc-apple-darwin9 fails with revision 132578: ... libtool: compile: /opt/gcc/darwin_buildw/./gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.4-work/libgfortran -I. -iquote../../../gcc-4.4-work/libgfortran/io -I../../../gcc-4.4-work/libgfortran/../gcc -I../../../gcc-4.4-work/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -g -O2 -MT maxloc1_4_r16.lo -MD -MP -MF .deps/maxloc1_4_r16.Tpo -c ../../../gcc-4.4-work/libgfortran/generated/maxloc1_4_r16.c -fno-common -DPIC -o .libs/maxloc1_4_r16.o ../../../gcc-4.4-work/libgfortran/generated/maxloc1_4_r16.c: In function 'mmaxloc1_4_r16': ../../../gcc-4.4-work/libgfortran/generated/maxloc1_4_r16.c:220: internal compiler error: in memory_address, at explow.c:492 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [maxloc1_4_r16.lo] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libgfortran] Error 2 make: *** [all] Error 2 The build completes if I remove the line 492 in explow.c. -- Summary: [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35373
[Bug c++/35374] New: ICE during instanciation of a template expr. with typeof()
The following code:
// START of CODE, FILE 'try.cpp'
templateclass A,class B
typeof(A(0)+B(0)) add( A a , B b )
{
return a + b;
}
void f( double S , double X , int Y )
{
S = add( X , Y );
}
// END OF CODE
causes g++ to emit an ICE error, as shown of the following sessions transcript.
I joined the try.ii file even if I think it can be easily re-created, as the
bug-triggering code contains non #include... statement.
-
gcc -v -save-temps try.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -E -quiet -v -D_GNU_SOURCE try.cpp
-mtune=i686 -fpch-preprocess -o try.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/i486-linux-gnu
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.1.2/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1plus -fpreprocessed try.ii -quiet
-dumpbase try.cpp -mtune=i686 -auxbase try -version -o try.s
GNU C++ version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (i486-linux-gnu)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64575
Compiler executable checksum: 183d42a838ed2b7313bffcb8f2f2fda7
try.cpp: In function '__typeof__ (((A)(0) + (B)(0))) add(A, B) [with A =
double, B = int]':
try.cpp:4: internal compiler error: in write_type, at cp/mangle.c:1651
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
Preprocessed source stored into /tmp/ccAaaM0z.out file, please attach this to
your bugreport.
-
cat try.ii
# 1 try.cpp
# 1 built-in
# 1 command line
# 1 try.cpp
templateclass A,class B
typeof(A(0)+B(0)) add( A a , B b )
{
return a + b;
}
void f( double S , double X , int Y )
{
S = add( X , Y );
}
-
--
Summary: ICE during instanciation of a template expr. with
typeof()
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe dot hoogvorst at neuf dot fr
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35374
[Bug c++/35374] ICE during instanciation of a template expr. with typeof()
--- Comment #1 from pcarlini at suse dot de 2008-02-26 10:57 --- *** This bug has been marked as a duplicate of 13740 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35374
[Bug other/35376] New: #pragma GCC diagnostic expand function.
#pragma GCC diagnostic clear // added to clear all current in file diagnostic over rides. #pragma GCC diagnostic warning clear // Clear all warnings alerations done by diagnostic. #pragma GCC diagnostic error clear // same as above but for error #pragma GCC diagnostic ignored clear //same as above but for ignored end like option as well so they can be stacked. end clears only the 1 back. This might be a bad idea but here it is just the same. PS sorry could not remember what section pragma's are processed in. -- Summary: #pragma GCC diagnostic expand function. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oiaohm at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35376
[Bug ada/35372] Memory corruption at unchecked deallocation of the interface classwide type
--- Comment #1 from vgodunko at rostel dot ru 2008-02-26 10:33 --- Created an attachment (id=15232) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15232action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35372
[Bug web/35375] New: A couple of typos in links on Status of Experimental C++0x Support page
Some links ot the page http://gcc.gnu.org/gcc-4.3/cxx0x_status.html contain typos: strongly-typed enums paper is called N2347 (not N2437); real N3437 (`Explicit conversion operators') has the wrong link, it should refer to pdf file instead of html; link to 2346 has an unnecessary `l'; correct link: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm; -- Summary: A couple of typos in links on Status of Experimental C++0x Support page Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pavel dot shved at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35375
[Bug c++/13740] ICE when mangling template which uses typeof
--- Comment #15 from pcarlini at suse dot de 2008-02-26 10:57 --- *** Bug 35374 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||philippe dot hoogvorst at ||neuf dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13740
[Bug other/35377] New: stack-protector: multiple definition of `__stack_chk_fail_local'
I was compiled and installed gcc-4.2.3 on Linux 2.4, glibc 2.3.6 main configure options was: --enable-shared=libstdc++ --enable-static --disable-debug --enable-cpp --enable-languages=c,c++ --enable-threads After successfully compile and install got some problems when compiling apps using the -fstack-protector option: Linking C executable at-parser /pkg/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../libssp.a(ssp.o): In function `__stack_chk_fail_local': /home/gzp/src/gcc-4.2.3/obj/i686-pc-linux-gnu/libssp/../../../libssp/ssp.c:175: multiple definition of `__stack_chk_fail_local' /pkg/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../libssp_nonshared.a(libssp_nonshared_la-ssp-local.o):/home/gzp/src/gcc-4.2.3/obj/i686-pc-linux-gnu/libssp/../../../libssp/ssp-local.c:48: first defined here collect2: ld returned 1 exit status make[3]: *** [tests/at-parser] Error 1 libssp present only in static format, as libssp_nonshared. -- Summary: stack-protector: multiple definition of `__stack_chk_fail_local' Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gzp at gmx dot net 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=35377
[Bug target/33963] [4.3/4.4 Regression] Dllimport attribute wrongly accepted on typedefs
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-02-26 12:13 --- Mark confirms this should not be accepted for scalar types, so a regression. Working on a patch. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||accepts-invalid Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-02-26 12:13:45 date|| Summary|Dllimport attribute wrongly |[4.3/4.4 Regression] |accepted on typedefs|Dllimport attribute wrongly ||accepted on typedefs Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33963
[Bug ada/35372] Memory corruption at unchecked deallocation of the interface classwide type
--- Comment #2 from vgodunko at rostel dot ru 2008-02-26 12:17 --- GNAT register allocated object of the T type in the finalization list at the creation time, but at the deallocation time it only free object storage and don't remove reference to the deallocated object from the finalization list. Finalization of the finalization list try to deallocate object one more time using reference in the finalization list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35372
[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target Keywords||build Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35373
[Bug fortran/33759] ICE in transfer_simplify_4.f90 at any level of optimization
--- Comment #12 from pault at gcc dot gnu dot org 2008-02-26 12:44 --- Have changed the keyword to represent comment #6 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Keywords|diagnostic |ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759
[Bug web/35375] A couple of typos in links on Status of Experimental C++0x Support page
--- Comment #1 from pavel dot shved at gmail dot com 2008-02-26 12:33 --- (In reply to comment #0) Well, my comment has typos as well... real N3437 (`Explicit conversion operators') is is N2437, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35375
[Bug bootstrap/35378] New: Bootstrap fails with BOOT_CFLAGS=-g -O0
../gcc/configure --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i 686-apple-darwin9 --with-gnu-as --enable-shared --prefix=/opt/gnu/gcc/gcc-4.3.0 --enable-debug=no --disable-nls --enable-languages=c,c++,objc,fortran,obj-c++,j ava ... make BOOT_CFLAGS=-g -O0 bootstrap ... Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1objplus-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./dbxout.o differs ./fortran/check.o differs ./fortran/trans-decl.o differs ./java/class.o differs ./varasm.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 make: *** [bootstrap] Error 2 Tue 26 Feb 2008 01:38:35 EST john-david-anglins-mac-pro:stage3-gcc dave$ ./xgcc -B./ -v Reading specs from ./specs Target: i686-apple-darwin9 Configured with: ../gcc/configure --build=i686-apple-darwin9 --host=i686-apple-darwin9 --target=i686-apple-darwin9 --with-gnu-as --enable-shared --prefix=/opt/gnu/gcc/gcc-4.3.0 --enable-debug=no --disable-nls --enable-languages=c,c++,objc,fortran,obj-c++,java Thread model: posix gcc version 4.3.0 20080226 (prerelease) [gcc-4_3-branch revision 132666] (GCC) -- Summary: Bootstrap fails with BOOT_CFLAGS=-g -O0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35378
[Bug bootstrap/35378] Bootstrap fails with BOOT_CFLAGS=-g -O0
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-26 13:01 --- Did you check if it is only debug info that differs? That is, does BOOT_CFLAGS=-O0 work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35378
[Bug c/34351] Please get us the volatile register warning back
--- Comment #4 from manu at gcc dot gnu dot org 2008-02-26 14:04 --- Subject: Bug 34351 Author: manu Date: Tue Feb 26 14:04:09 2008 New Revision: 132675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132675 Log: 2008-02-26 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR 34351 * doc/invoke.texi (-Wall): Add -Wvolatile-register-var. * c-opts.c (c_common_handle_option): Wall enables Wvolatile-register-var. * common.opt: Move Wvolatile-register-var to... * c.opt: ...here. testsuite/ * gcc.dg/pr34351.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr34351.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351
[Bug c/34351] Please get us the volatile register warning back
--- Comment #5 from manu at gcc dot gnu dot org 2008-02-26 14:06 --- Fixed in 4.4. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34351
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #12 from manu at gcc dot gnu dot org 2008-02-26 14:17 --- Subject: Bug 26264 Author: manu Date: Tue Feb 26 14:16:13 2008 New Revision: 132677 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132677 Log: 2008-02-26 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR 26264 * builtins.def (BUILT_IN_STDARG_START): Remove. * builtins.c (expand_builtin): Remove BUILT_IN_STDARG_START. * tree-stdarg.c (execute_optimize_stdarg): Likewise. * tree-inline.c (inline_forbidden_p_1): Likewise. cp/ * call.c (magic_varargs_p): Remove BUILT_IN_STDARG_START. testsuite/ * 20021023-1.c: Use __builtin_va_start instead of __builtin_stdarg_start. * pr17301-1.c: Likewise. * pr17301-2.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/builtins.def trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/20021023-1.c trunk/gcc/testsuite/gcc.dg/pr17301-1.c trunk/gcc/testsuite/gcc.dg/pr17301-2.c trunk/gcc/tree-inline.c trunk/gcc/tree-stdarg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug preprocessor/35379] New: -MT generates a target string too long over two lines
Precondition: an empty file named dummy.c exists in the current directory. The following command: arm-elf-gcc -c -MM -MT 123456789a123456789b123456789c123456789d123456789e123456789f123456789g123 dummy.c generates the following output: \ 123456789a123456789b123456789c123456789d123456789e123456789f123456789g123: \ dummy.c Starting with a redundant \newline . The length of the -MT argument is 73 characters. For 72 characters this does not happen. The following command: arm-elf-gcc -c -MM -MT 123456789a123456789b123456789c123456789d123456789e123456789f123456789g12 dummy.c generates the following output: 123456789a123456789b123456789c123456789d123456789e123456789f123456789g12: \ dummy.c (the redundant spaces may interfere with make operation, apparently) arm-elf-gcc -v output: Using built-in specs. Target: arm-elf Configured with: ../../gcc-4.1.1/configure --enable-languages=c,c++ --enable-int erwork --enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --d isable-shared --disable-threads --disable-libssp --disable-libstdcxx-pch --disab le-libmudflap --disable-win32-registry --disable-nls --disable-debug --without-h eaders --with-newlib --target=arm-elf --prefix=c:/WinARM -v Thread model: single gcc version 4.1.1 (WinARM) -- Summary: -MT generates a target string too long over two lines Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uriah at mobiletornado dot com GCC host triplet: Win32 GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35379
[Bug bootstrap/35378] Bootstrap fails with BOOT_CFLAGS=-g -O0
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-26 14:31 --- Subject: Re: Bootstrap fails with BOOT_CFLAGS=-g -O0 Did you check if it is only debug info that differs? That is, does BOOT_CFLAGS=-O0 work? Removing -g works. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35378
[Bug preprocessor/35379] -MT generates a target string too long over two lines
--- Comment #1 from rwild at gcc dot gnu dot org 2008-02-26 14:48 --- (the redundant spaces may interfere with make operation, apparently) Can you show in which way they interfere? If they cause an error, then post it, please. Which make implementation? -- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35379
[Bug tree-optimization/26264] Extraneous warning with __builtin_stdarg_start and optimization
--- Comment #13 from manu at gcc dot gnu dot org 2008-02-26 14:45 --- Fixed in GCC 4.4 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26264
[Bug c++/35380] New: ICE with attribute 'aligned' in template parameter
The following program produces an ICE on my machine
#include tr1/array
class Foo
{
char foo[3];
};
int main(){
std::tr1::arrayFoo __attribute__((aligned(8))),2 bar;
}
Output:
cd /home/haile/sander/tmp/
g++ test.cc
test.cc: In function int main():
test.cc:9: internal compiler error: Speicherzugriffsfehler
Please submit a full bug report,
with preprocessed source if appropriate.
My compiler:
g++ (GCC) 4.2.3 (Debian 4.2.3-1)
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.
--
Summary: ICE with attribute 'aligned' in template parameter
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sander at mi dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35380
[Bug middle-end/35307] Missing Simplication for div op
--- Comment #3 from segher at kernel dot crashing dot org 2008-02-26 16:16 --- Not equivalent in the presence of overflow. You mean defined overflow :). No, I mean overflow. Let's assume int is 16-bit (just to keep the numbers smallish); now take i=1, j=1000, k=1000. i/j/k is perfectly well-defined, but i/(j*k) overflows in the j*k computation. Segher -- segher at kernel dot crashing dot org changed: What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35307
[Bug c++/35368] [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-26 16:30 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-02-25 15:54:38 |2008-02-26 16:30:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
[Bug c++/35368] [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation
--- Comment #6 from mmitchel at gcc dot gnu dot org 2008-02-26 17:06 --- We need to be careful about this. We have a lot of ways to specify visibility: dllimport/dllexport attributes, notshared attribute, visibility attributes on classes. I actually think the compiler is behaving as intended here. To me: #pragma GCC push visibility(hidden) is equivalent to applying: __attribute__((visibility(hidden))) to all declarations in the scope of the #pragma. And, a class with hidden visibility does have a hidden virtual table. Why do we think this is a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #57 from howarth at nitro dot med dot uc dot edu 2008-02-26 17:15 --- Uros, You changes in d.diff.txt are fine with the exception of the missing extra set of parentheses for the ACONCAT macro call. I have tested the patch with those corrections and powerpc-apple-darwin9 properly uses $LDBL128 with it. Can you post the corrected patch to gcc-patches? I would like to post a backport of FX and your changes for gcc 4.3. Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug c++/35368] [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation
--- Comment #7 from jakub at gcc dot gnu dot org 2008-02-26 17:19 --- Created an attachment (id=15233) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15233action=view) gcc43-pr35368.patch Patch I'm testing. The reasons it should IMNSHO have default visibility is: 1) these are compiler generated references and libsupc++.a/libstdc++.a provided symbols. For e.g. builtins we use default visibility as well, rather than the current default one 2) the same reason why do the typeinfo etc. headers have those #pragma GCC visibility push(default)/#pragma GCC visibility pop around them -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
[Bug fortran/35381] New: Real initialization problem (invalid error): Exponent at (1) must be INTEGER for an initialization expression
We have a set of code that works with SUN and Intel compilers and that should be correct to the best of our knowledge, but triggers a strange error by gfortran 4.1.0 and 4.2.3 . The stripped-down exapmple here has been tested with 4.1.0 on x86-64, I got the qualitatively same error on the full source with 4.2.3 on x86, too. Here is the output of compilation: [EMAIL PROTECTED] gfortran -v -save-temps -c -g baddata.f90 Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux Thread model: posix gcc version 4.1.0 (SUSE Linux) /usr/lib64/gcc/x86_64-suse-linux/4.1.0/f951 baddata.f90 -quiet -dumpbase baddata.f90 -mtune=generic -auxbase baddata -g -version -o baddata.s GNU F95 version 4.1.0 (SUSE Linux) (x86_64-suse-linux) compiled by GNU C version 4.1.0 (SUSE Linux). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 In file baddata.f90:50 1._dp / (1._dp - rxyzkappa), 1 Error: Exponent at (1) must be INTEGER for an initialization expression In file baddata.f90:72 rerg = rconst * rrhoTheta**dat_sig%gamma 1 Error: Symbol 'rconst' at (1) has no IMPLICIT type And here is the code (baddata.f90): ! This example file is stripped from a program that compiles and works fine with Intel or SUN compilers... ! gfortran 4.2.3 showed an identical error as 4.1.0 ! During reduction of code for the example, the complained position varied but the basic parser error stayed the same with 4.1.0 . ! The essence is this: !1._dp / (1._dp - rxyzkappa), !1 !Error: Exponent at (1) must be INTEGER for an initialization expression MODULE precision IMPLICIT NONE PUBLIC INTEGER, PARAMETER :: dp = 4 END MODULE precision MODULE data USE precision IMPLICIT NONE PRIVATE INTEGER, PARAMETER :: dat_dimension = 2 TYPE dat_sigtype INTEGER :: dimension real(kind=4), DIMENSION(dat_dimension) :: rmin real(kind=4), DIMENSION(dat_dimension) :: rmax real(kind=4) :: gravity real(kind=4) :: omega real(kind=4) :: gasconst real(kind=4) :: p0 real(kind=4) :: kappa real(kind=4) :: gamma real(kind=4) :: rcp END TYPE dat_sigtype real(kind=4), PARAMETER :: rxyzR= 287.E-6_dp real(kind=4), PARAMETER :: rxyzkappa= 0.284_dp TYPE(dat_sigtype), PARAMETER :: dat_sig = dat_sigtype( dat_dimension, (/ 0._dp, 0._dp /), (/ 28.0E3_dp, 10.0_dp /), 9.81E-3_dp, 7.292E-5_dp, rxyzR, .101300_dp, rxyzkappa, 1._dp / (1._dp - rxyzkappa), rxyzR / rxyzkappa ) CONTAINS ! The code compiles fine when you remove that function. ! It has trouble with rconst... !rerg = rconst * rrhoTheta**dat_sig%gamma !1 ! Error: Symbol 'rconst' at (1) has no IMPLICIT type FUNCTION dat_diagP(rrhoTheta) RESULT(rerg) IMPLICIT NONE real(kind=4), INTENT(in) :: rrhoTheta real(kind=4) :: rerg real(kind=4), PARAMETER :: rconst = dat_sig%gasconst**dat_sig%gamma / dat_sig%p0**(dat_sig%kappa*dat_sig%gamma) rerg = rconst * rrhoTheta**dat_sig%gamma END FUNCTION dat_diagP END MODULE data -- Summary: Real initialization problem (invalid error): Exponent at (1) must be INTEGER for an initialization expression Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35381
[Bug c++/35368] [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation
--- Comment #8 from benjamin at smedbergs dot us 2008-02-26 17:25 --- Yes, to make it clear: the class typeinfo object may have hidden visibility... it's the __cxxabiv1::__class_type_info class that should have default visibility always. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
[Bug fortran/35381] Misleading error message with derived types: Exponent at (1) must be INTEGER for an initialization expression
--- Comment #1 from thomas dot orgis at awi dot de 2008-02-26 17:37 --- I stripped a bit more and I think I got the root of the problem, illustrated by this more minimal example: MODULE data IMPLICIT NONE PRIVATE INTEGER, PARAMETER :: dat_dimension = 2 TYPE dat_sigtype real(kind=4) :: gamma END TYPE dat_sigtype TYPE(dat_sigtype), PARAMETER :: dat_sig = dat_sigtype( 1.3_4 ) real(kind=4), PARAMETER :: expo = 1.3_4 real(kind=4), PARAMETER :: rconst = 2._4**dat_sig%gamma real(kind=4), PARAMETER :: rconst2 = 2._4**expo CONTAINS END MODULE data ...and these gcc messages: In file baddata.f90:11 TYPE(dat_sigtype), PARAMETER :: dat_sig = dat_sigtype( 1.3_4 ) 1 Error: Exponent at (1) must be INTEGER for an initialization expression In file baddata.f90:16 real(kind=4), PARAMETER :: rconst2 = 2._4**expo 1 Error: Exponent at (1) must be INTEGER for an initialization expression So we are dealing with a limitation (in accordance to F95 standard, as I read... and thus correct here) with initialization. The problem I still have with gcc here is that when the exponent comes from a derived type, the error message points to the exponents definition (which is correct code) and not the the bad initialization code (which is not correct code). -- thomas dot orgis at awi dot de changed: What|Removed |Added Summary|Real initialization problem |Misleading error message |(invalid error): Exponent at|with derived types: Exponent |(1) must be INTEGER for an |at (1) must be INTEGER for |initialization expression |an initialization expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35381
[Bug c++/35368] [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation
--- Comment #9 from jakub at gcc dot gnu dot org 2008-02-26 17:39 ---
BTW, not sure why 4.1.x/4.2.x is listed as broken. Only 4.3+ has H.J's:
http://gcc.gnu.org/viewcvs?root=gccview=revrev=119764
Without that change, although __cxxabiv1::* symbols are incorrectly marked
as hidden, GCC doesn't emit .hidden directives for the external symbols and all
these symbols of course are external, as they are defined in
libsupc++.a/libstdc++.{so,a}, and as they are referenced just in the RTTI
pointers, not in code directly, it makes zero difference to the generated code
whether they are hidden or not.
BTW, I've noticed that for _ZTI*/_ZTV* symbols defined in the assembly .hidden
directives are emitted twice, once at the definition spot and once at the end
of the file. Guess assemble_external_real should skip decls that lost
DECL_EXTERNAL flag (became defined in the current TU).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
[Bug testsuite/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-02-26 17:53 --- Isn't this a dup of 34168? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-26 17:53:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug c++/35368] [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation
--- Comment #10 from mark at codesourcery dot com 2008-02-26 17:57 --- Subject: Re: [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation benjamin at smedbergs dot us wrote: --- Comment #8 from benjamin at smedbergs dot us 2008-02-26 17:25 --- Yes, to make it clear: the class typeinfo object may have hidden visibility... it's the __cxxabiv1::__class_type_info class that should have default visibility always. Oh, I see! Yes, __cxxabiv1::* should definitely have default visibility. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
[Bug testsuite/35382] New: Invalid gcc.dg/pr34351.c
I got /export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/pr34351.c:4: error: invalid register name for 'x' on Linu/ia32 since r13 register int * volatile x asm (r13); isn't a valid register. -- Summary: Invalid gcc.dg/pr34351.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35382
[Bug testsuite/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2008-02-26 18:00 --- Subject: Re: fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math. On Tue, Feb 26, 2008 at 05:53:52PM -, ghazi at gcc dot gnu dot org wrote: --- Comment #6 from ghazi at gcc dot gnu dot org 2008-02-26 17:53 --- Isn't this a dup of 34168? It appears to be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug c++/35315] [4.4 regression] ICE with attribute transparent_union
--- Comment #2 from jason at gcc dot gnu dot org 2008-02-26 18:09 --- Subject: Bug 35315 Author: jason Date: Tue Feb 26 18:09:02 2008 New Revision: 132681 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132681 Log: PR c++/35315 * attribs.c (decl_attributes): Leave ATTR_FLAG_TYPE_IN_PLACE alone if it's the naming decl for the type's main variant. * cp/decl.c (grokdeclarator): Allow a typedef of an unnamed struct to name the struct for linkage purposes even if it has attributes. (start_decl): In that case, set ATTR_FLAG_TYPE_IN_PLACE. Added: trunk/gcc/testsuite/g++.dg/ext/attrib32.C Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
[Bug testsuite/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #8 from ghazi at gcc dot gnu dot org 2008-02-26 18:29 --- (In reply to comment #7) Isn't this a dup of 34168? It appears to be. Can you implement Uros' suggestion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug ada/35372] Memory corruption at unchecked deallocation of the interface classwide type
--- Comment #3 from vgodunko at rostel dot ru 2008-02-26 18:43 --- I have trace and compare execution of the two program, one use anonymous access type to tagged type and another use anonymous access type to interface type. In the program which use tagged type GNAT: - creates not only finalization list object but also list controller object; - attach created object the finalization list with mode 2 (it uses mode 1 in the case of interface type). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35372
[Bug c++/35383] New: Lookup of template dependent function with overloads fails for namespace-qualified parameter
Can someone confirm if this is the same non-bug reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29844 or if it is a regression?
The code compiles in gcc 3.4.4 and 4.0.2 but not in 4.1.2, and I don't
understand why. Especially since func2() doesn't have the same problem that
func() does.
templatetypename T
struct Holder
{
T item;
};
templatetypename T
void func(HolderT hold)
{
hold.item.a = 2; // OK
func(hold.item); // OK for Wilma, but fails for Foo::Fred, see below
func2(hold.item); // OK, not overloaded name
}
namespace Foo {
struct Fred { int a; };
}
struct Wilma { int a; };
void func(Foo::Fred f); // move this line inside namespace Foo, and all is OK
void func(Wilma w);
void func2(Foo::Fred f);
void func2(Wilma w);
int main()
{
HolderFoo::Fred fred;
func(fred);
HolderWilma wilma;
func(wilma);
return 0;
}
/*
$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure
--verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x
--enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
--disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization
--enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
$ g++ -c -W -Wall gcc-dependent-name-lookup.cpp
**
$ g++ -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=i386-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
$ g++ -c -W -Wall gcc-dependent-name-lookup.cpp
**
C:\ccppc -v
Using built-in specs.
Target: powerpc-wrs-vxworks
Configured with: /scratch/nathan/vxworks/src/gcc-4.1/configure
--build=i686-pc-linux-gnu --host=i686-mingw32 --target=powerpc-wrs-vxworks
--enable-threads --disable-libmudflap --disable-libssp --disable-libgomp
--disable-libstdcxx-pch --enable-sjlj-exceptions --disable-hosted-libstdcxx
--enable-version-specific-runtime-libs --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --disable-shared --disable-hosted-libstdcxx
--with-cxxabi=/scratch/nathan/vxworks/src/dinkum-20021215/include
--with-pkgversion='Wind River VxWorks G++ 4.1-82'
[EMAIL PROTECTED] --disable-nls --prefix=/opt/codesourcery
--exec-prefix='/x86-win32' --libdir='/lib'
--program-transform-name='s,^gcc$,cc,;s,$,ppc,'
--with-libiconv-prefix=/scratch/nathan/vxworks/powerpc/obj/host-libs-4.1-82-powerpc-wrs-vxworks-i686-mingw32/usr
--with-gxx-include-dir=''\''/'\''include/c++/4.1'
--with-license=/scratch/nathan/vxworks/powerpc/obj/host-libs-4.1-82-powerpc-wrs-vxworks-i686-mingw32/usr
--with-csl-license-version=20071015
--with-csl-license-feature=gcc_Power_VxWorks --enable-poison-system-directories
Thread model: vxworks
gcc version 4.1.2 (Wind River VxWorks G++ 4.1-82)
C:\ccppc -c -W -Wall gcc-dependent-name-lookup.cpp
gcc-dependent-name-lookup.cpp: In function 'void func(HolderT) [with T =
Foo::Fred]':
gcc-dependent-name-lookup.cpp:30: instantiated from here
gcc-dependent-name-lookup.cpp:11: error: no matching function for call to
'func(Foo::Fred)'
*/
--
Summary: Lookup of template dependent function with overloads
fails for namespace-qualified parameter
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpfurlani at raytheon dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35383
[Bug c++/35383] Lookup of template dependent function with overloads fails for namespace-qualified parameter
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-26 18:59 --- func(hold.item); // OK for Wilma, but fails for Foo::Fred, see below This is correct. func2(hold.item); // OK, not overloaded name This is not and we still have a bug with respect of not having any overloaded function before. This should fail the same way func fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35383
[Bug c/35384] Variables declared as 'static char * avar = some string;' cannot be modified
--- Comment #1 from Quinlan at ACM dot org 2008-02-26 18:59 --- I am building with compiler flags set to: -c -DLINUX -gdwarf-2 -g3 -g -O -DDEBUG -- Quinlan at ACM dot org changed: What|Removed |Added Summary|Variables declared as |Variables declared as |'static char * avar = some |'static char * avar = some |string;' cannot be modified|string;' cannot be modified http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35384
[Bug c/35384] Variables declared as 'static char * avar = some string;' cannot be modified
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-26 19:00 --- some string is a string literal so it is constant. What you are trying to do is change the string literal which is undefined behavior so you are getting a runtime seg fault. -- 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=35384
[Bug testsuite/35382] Invalid gcc.dg/pr34351.c
--- Comment #1 from manu at gcc dot gnu dot org 2008-02-26 19:02 --- H.J. Could you suggest a more robust testcase? Or if that is not possible, there should be a way to only compile the testcase for valid targets. Ideas? -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-26 19:02:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35382
[Bug c/35384] New: Variables declared as 'static char * avar = some string;' cannot be modified
A variable is declared similar to this: static char * avar = some string; Then an attempt to change the value like this will throw a SIGSEGV: avar[4] = '_'; The problem occurs when the variable is declared locally in a function, and when the variable is declared globally. Adding a cast to the assignment (as suggested in another bug solution I found during my search) does not alter the behavior: avar[4] = (unsigned char)'_'; Changing the way the variable is declared does work around the problem: static char * avar = NULL; // Local or global ... if(avar == NULL) avar = some string; // In a function ... avar[4] = '_'; // Now this will work I am seeing this problem using Linux Kernel 2.6.21.5 and gcc version 4.1.2. I am using the gcc build from the Slackware 12.0 distribution. -- Summary: Variables declared as 'static char * avar = some string;' cannot be modified Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Quinlan at ACM dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35384
[Bug testsuite/35382] Invalid gcc.dg/pr34351.c
--- Comment #2 from hjl dot tools at gmail dot com 2008-02-26 19:30 ---
(In reply to comment #1)
Could you suggest a more robust testcase?
Or if that is not possible, there should be a way to only compile the testcase
for valid targets. Ideas?
You can use
/* { dg-add-options register } */
register int * volatile x asm REGISTER; /* { dg-warning optimization may
eliminate reads and/or writes to register variables } */
You need to define add_options_for_register to add proper
-DREGITSR=.
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35382
[Bug fortran/35385] New: gfortran does not support the COCO preprocessor
COCO is part 3 of the Fortran 95 standard. Dan Nagle provides a GPL licensed implementation at http://users.erols.com/dnagle/coco.html, perhaps it's possible to use that? -- Summary: gfortran does not support the COCO preprocessor Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35385
[Bug c/35384] Variables declared as 'static char * avar = some string;' cannot be modified
--- Comment #3 from Quinlan at ACM dot org 2008-02-26 20:10 ---
I appreciate your answer, however shouldn't this declaration:
static char * avar = some string;
be identical to this:
static char * avar = NULL;
avar = some string;
Yet when the application executes:
avar[4] = '_';
with the first declaration I get SIGSEGV while with the second declaration the
fifth character is changed. Why? Does the behavior of the second declaration
result from a bug and if so should I not be using this approach as it is likely
to stop working with the next gcc upgrade? In both instance avar is a pointer
to a constant string!
Note that I encountered this problem in code that was written about 10 years
ago, and that works with early gcc versions and with Microsoft's compilers.
To avoid making a change to a constant variable do I really need to replace a
simple line of code like:
static char * avar = NULL;
with this much more complicated approach:
static char * orig_var = some string;
static char * avar = NULL;
if(avar == NULL) { avar = (char *)calloc(12,1); memcpy(avar,orig_var,12);}
// Now I can safely modify characters in avar
free(avar); // Sometime before the application exits
--
Quinlan at ACM dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35384
[Bug testsuite/35382] Invalid gcc.dg/pr34351.c
--- Comment #3 from manu at gcc dot gnu dot org 2008-02-26 20:14 ---
(In reply to comment #2)
You can use
/* { dg-add-options register } */
register int * volatile x asm REGISTER; /* { dg-warning optimization may
eliminate reads and/or writes to register variables } */
You need to define add_options_for_register to add proper
-DREGITSR=.
That seems too complicated for a simple diagnostics test. Moreover, I couldn't
find a single example of that in the testsuite. Why not simply?
/* { dg-do compile } */
/* { dg-options -Wall } */
#ifdef __i386__
register unsigned int volatile reg __asm (esi); /* { dg-warning optimization
may eliminate reads and/or writes to register variables } */
#elif defined __x86_64__
register int * volatile x __asm (r13); /* { dg-warning optimization may
eliminate reads and/or writes to register variables } */
#else
unsigned int reg;
#endif
I can only test in x86_64-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35382
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Comment #16 from tromey at gcc dot gnu dot org 2008-02-26 20:48 --- *** Bug 35312 has been marked as a duplicate of this bug. *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug preprocessor/35312] Invalid syntax in PP expressions not diagnosed in strict mode
--- Comment #2 from tromey at gcc dot gnu dot org 2008-02-26 20:48 --- I agree, closing as dup. I have a patch for that bug. I forget what happened to it, but I'll look into it soon. *** This bug has been marked as a duplicate of 22168 *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35312
[Bug c/35384] Variables declared as 'static char * avar = some string;' cannot be modified
--- Comment #4 from Quinlan at ACM dot org 2008-02-26 21:05 ---
If the problem is that the char pointer is pointing to a constant value in:
static char * avar = some string;
then perhaps initializing with an array of one string as in this line work:
static char * avar = {some string};
That approach doesn't work. Converting avar from a pointer to an array like
this however does work:
static char avar[] = {some string};
This provides a simple workaround that we will use for now. The big problem
remaining is: There are inconsistent behaviors exhibited in these tests. The
previous approach works, but it still is allowing a constant value to be
modified. Is this a bug that may be fixed in the future and break our
applications, or can we expect the C standard be upgraded at some point to
provide for this type of behavior?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35384
[Bug c/35384] Variables declared as 'static char * avar = some string;' cannot be modified
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-02-26 21:09 ---
Converting avar from a pointer to an array like
this however does work:
static char avar[] = {some string};
This is an array value which is initialized via a string literal. The array is
writable.
The behavior is still undefined for writing in string literals.
-- Pinski
--
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=35384
[Bug fortran/29549] matmul slow for complex matrices
--- Comment #14 from jb at gcc dot gnu dot org 2008-02-26 21:15 --- Closing as fixed. Timings for a small test program comparing matrix multiplication done manually vs. libgfortran for real and complex. Results without the committed patch (-O3 -funroll-loops, 1.6 GHz Pentium-M): Manual real: 0.2140 Real matmul: 0.2390 Complex manual: 0.8259 Complex matmul: 3.8654 with the patch: Manual real: 0.2130 Real matmul: 0.2520 Complex manual: 0.8149 Complex matmul: 0.8099 I.e. almost a factor of five speedup. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549
[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-02-26 21:45 --- If we don't have a way to truncate a file, we won't have an easy time enforcing Fortran semantics. Are there any other ways of truncating a file on that particular target? If there aren't, we could a) refuse to configure for that target at all b) fail at runtime (noisily) and xfail the corresponding test cases c) juggle the file offsets, never read past the (logical) end of file and do a copy-on-close. Yuck. My personal preference would go towards b), but again - there has to be a way of truncating a file, right? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
[Bug fortran/35033] Valid ASSIGNMENT(=) rejected
--- Comment #4 from burnus at gcc dot gnu dot org 2008-02-26 22:34 --- Subject: Bug 35033 Author: burnus Date: Tue Feb 26 22:33:35 2008 New Revision: 132689 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132689 Log: 2008-02-26 Tobias Burnus [EMAIL PROTECTED] PR fortran/35033 * interface.c (check_operator_interface): Show better line for * error messages; fix constrains for user-defined assignment operators. (gfc_extend_assign): Fix constrains for user-defined assignment operators. 2008-02-26 Tobias Burnus [EMAIL PROTECTED] PR fortran/35033 * gfortran.dg/assignment_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/assignment_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35033
[Bug fortran/35033] Valid ASSIGNMENT(=) rejected
--- Comment #5 from burnus at gcc dot gnu dot org 2008-02-26 22:41 --- FIXED on the trunk (4.4.0). The not-so-helpful error message is now PR 35267. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35033
[Bug c/28800] warning ISO C forbids an empty source file could be improved
--- Comment #2 from rwild at gcc dot gnu dot org 2008-02-26 22:42 --- Subject: Bug 28800 Author: rwild Date: Tue Feb 26 22:41:16 2008 New Revision: 132690 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132690 Log: gcc/: PR c/28800 * c-parser.c (c_parser_translation_unit): Warn for empty translation unit, not empty source file. gcc/testsuite/: PR c/28800 * gcc.dg/empty-source-2.c: Adjust for warning message. * gcc.dg/empty-source-3.c: Likewise. * gcc.dg/pack-test-2.c: Adjust comment. * gcc.dg/pragma-ep-2.c: Likewise. * gcc.dg/pragma-re-2.c: Likewise. * gcc.dg/va-arg-2.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/empty-source-2.c trunk/gcc/testsuite/gcc.dg/empty-source-3.c trunk/gcc/testsuite/gcc.dg/pack-test-2.c trunk/gcc/testsuite/gcc.dg/pragma-ep-2.c trunk/gcc/testsuite/gcc.dg/pragma-re-2.c trunk/gcc/testsuite/gcc.dg/va-arg-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28800
[Bug c/28800] warning ISO C forbids an empty source file could be improved
--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-26 22:47 --- Fixed. -- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28800
[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.
--- Comment #8 from hp at gcc dot gnu dot org 2008-02-26 22:47 --- (In reply to comment #7) If we don't have a way to truncate a file, we won't have an easy time enforcing Fortran semantics. Are there any other ways of truncating a file on that particular target? I can certainly add support for this particular target, but the same goes for *all* newlib targets except sh and spu. a) refuse to configure for that target at all I mentioned this in the analysis (second url in description), but I'd advise against it, as it'd imply breaking builds for all newlib targets configured without --enable-targets=all-except-fortran - except for the one that marks fortran as unsupported (using unsupported_languages in top/configure.ac). b) fail at runtime (noisily) and xfail the corresponding test cases *sigh* ok, I'll do it, except for the noise. As I mentioned, there are a few bugs there anyway, but nobody commented on that. c) juggle the file offsets, never read past the (logical) end of file and do a copy-on-close. Yuck. Not me. My personal preference would go towards b), but again - there has to be a way of truncating a file, right? There's no incentive. Bare-iron targets rarely really care about having a full POSIX-or-whatever set of file operations. -- hp at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-26 22:47:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
[Bug testsuite/35382] Invalid gcc.dg/pr34351.c
--- Comment #4 from ubizjak at gmail dot com 2008-02-26 22:59 ---
(In reply to comment #3)
That seems too complicated for a simple diagnostics test. Moreover, I couldn't
find a single example of that in the testsuite. Why not simply?
What about this:
--cut here--
/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
/* { dg-options -Wall } */
register int * volatile x asm (ebx); /* { dg-warning optimization may
eliminate reads and/or writes to register variables } */
--cut here--
This will work for all x86 targets. We already have a couple of generic tests
that are tested on x86 only (gcc.dg/register-var-1.c for example), so one more
won't hurt. And it will surely get enough coverage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35382
[Bug c++/35386] New: Invalid vector code generated with -O2
A simple vector addition loop fails to generate any addition code when -O2 optimization is used; the loop is essentially empty. -- Summary: Invalid vector code generated with -O2 Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kes at smolek dot com 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=35386
[Bug c++/35386] Invalid vector code generated with -O2
--- Comment #1 from kes at smolek dot com 2008-02-26 23:17 --- Created an attachment (id=15234) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15234action=view) temp file output demonstrating the bug Command line: gcc -v -save-temps -O2 -S -msse3 ComputeEven.cpp Note: bug occurs on 4.2.1, 4.2.2; 4.1.2 works okay. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35386
[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-02-26 23:19 --- (In reply to comment #8) b) fail at runtime (noisily) and xfail the corresponding test cases *sigh* ok, I'll do it, except for the noise. Thanks a lot! You'll probably want to make the truncate a no-op if we are at the end of file already. IIRC, there may be a few places in the library where we call ftruncate() even if we don't really need to. As I mentioned, there are a few bugs there anyway, but nobody commented on that. We know :-( The alloc stream facility has quite a few bugs in unexpected places that tend to be exposed by seemingly harmless changes far away. It needs to be replaced someday, but so far nobody has made a start on this. This is PR 25561, dated 2005-12-25. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
[Bug c++/35386] Invalid vector code generated with -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-26 23:20 --- You are violating C/C++ aliasing rules: typedef float v4sf __attribute__ ((vector_size(16))); v4sf vSum; complexfloat *vp = (complexfloat *) vSum; ... spectra[4*j] = vp[0]; spectra[4*j+2] = vp[1]; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35386
[Bug libfortran/35293] [4.4 Regression] truncation errors with gfortran.dg/streamio_11.f90, 3, 4 and 15.
--- Comment #10 from hp at gcc dot gnu dot org 2008-02-26 23:37 --- (In reply to comment #9) You'll probably want to make the truncate a no-op if we are at the end of file already. No, that'd be an unrelated change. I don't wanna mix things up and/or together. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293
[Bug c++/35386] Invalid vector code generated with -O2
--- Comment #3 from kes at smolek dot com 2008-02-27 01:50 --- Subject: Re: Invalid vector code generated with -O2 Oops. Sorry for the false alarm. But shouldn't there be an error, or at least a warning? pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-26 23:20 --- You are violating C/C++ aliasing rules: typedef float v4sf __attribute__ ((vector_size(16))); v4sf vSum; complexfloat *vp = (complexfloat *) vSum; ... spectra[4*j] = vp[0]; spectra[4*j+2] = vp[1]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35386
[Bug c++/35386] Invalid vector code generated with -O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-02-27 01:59 --- (In reply to comment #3) Subject: Re: Invalid vector code generated with -O2 Oops. Sorry for the false alarm. But shouldn't there be an error, or at least a warning? There should be a warning but sometimes getting warnings for undefined behavior is hard. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35386
[Bug fortran/35381] Misleading error message with derived types: Exponent at (1) must be INTEGER for an initialization expression
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-02-27 02:14 --- The problem exists in gfortran 4.2 but is fixed in 4.3 Suggest you update to 4.3. You can get binaries at http://gcc.gnu.org/wiki/GFortranBinaries if your distro does not provide 4.3 yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35381
[Bug fortran/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-02-27 04:38 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
