[Bug target/21761] [4.1 Regression] mainline gcc causing internal compiler error.
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-05-30 06:13 --- Should work now, but please verify. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21761
[Bug target/21761] [4.1 Regression] mainline gcc causing internal compiler error.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 06:10 --- Subject: Bug 21761 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-30 06:10:06 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr21761.c Log message: 2005-05-29 Geoffrey Keating <[EMAIL PROTECTED]> PR target/21761 * config/rs6000/rs6000.md: Remove stray TARGET_32BIT from pattern involving `:P'. Index: testsuite/ChangeLog 2005-05-29 Geoffrey Keating <[EMAIL PROTECTED]> PR target/21761 * gcc.c-torture/compile/pr21761.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8944&r2=2.8945 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcc&r1=1.369&r2=1.370 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5557&r2=1.5558 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21761.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21761
[Bug other/21812] New: libgcc could use some target specific optimizations
libgcc is currently contains pure C functions with simple (i.e. non-optimal implementations). Allowing individual targets to provide their own versions of the functions could boost performance. i.e. comparing the libgcc C implementation of __popcountdi2 to the assembly version provided in the Opteron optimization manual, we find that the AMD supplied version is half the instructions, branchless, uses no data tables (and thus causes no cache misses), and runs in about 1/3 to 1/2 less time. -- Summary: libgcc could use some target specific optimizations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nmiell at comcast dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21812
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-05-30 02:55 --- Hello, this is a mingw runtime bug. The mingw version of mcount does not take enough care with saving call-clobbered registers. Please close this bug and submit to mingw.org. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-30 02:08 --- I checked this in to 4.0, the trunk, and Classpath. I put the test case in Mauve. I'm not planning to put the fix into 3.4.x, but someone could if they wanted to. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20273
[Bug target/21760] [4.1 Regression] Powerpc atomic builtins missing PPC405 errata
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-30 01:40 --- This is a regression because libstdc++ previously worked correctly on PPC405 and now it does not. -- What|Removed |Added Summary|Powerpc atomic builtins |[4.1 Regression] Powerpc |missing PPC405 errata |atomic builtins missing ||PPC405 errata http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21760
[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 02:02 --- Subject: Bug 20273 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-30 02:02:03 Modified files: libjava: ChangeLog libjava/java/util: LinkedHashMap.java Log message: 2005-05-29 Michael Koch <[EMAIL PROTECTED]> PR libgcj/20273: * java/util/LinkedHashMap.java (access): Set 'root.pred'. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.79&r2=1.3391.2.80 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/LinkedHashMap.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20273
[Bug libgcj/20273] LinkedHashMap breaks linked list when access() is called
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 02:01 --- Subject: Bug 20273 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-30 02:01:15 Modified files: libjava: ChangeLog libjava/java/util: LinkedHashMap.java Log message: 2005-05-29 Michael Koch <[EMAIL PROTECTED]> PR libgcj/20273: * java/util/LinkedHashMap.java (access): Set 'root.pred'. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3638&r2=1.3639 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/LinkedHashMap.java.diff?cvsroot=gcc&r1=1.6&r2=1.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20273
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-30 00:30 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 00:23 --- Subject: Bug 20846 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-30 00:23:46 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: inquire_8.f90 Log message: PR fortran/20846 * gfortran.dg/inquire_8.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.208&r2=1.5084.2.209 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/inquire_8.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 00:21 --- Subject: Bug 20846 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-30 00:21:34 Modified files: gcc/fortran: ChangeLog io.c Log message: PR fortran/20846 * io.c (gfc_match_inquire): Implement constraints on UNIT and FILE usage. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.57&r2=1.335.2.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19.10.3&r2=1.19.10.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug fortran/20846] inquire(FILE=..., UNIT=...) not flagged as error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30 00:19 --- Subject: Bug 20846 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-30 00:19:44 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: inquire_8.f90 Log message: PR fortran/20846 * gfortran.dg/inquire_8.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.&r2=1.5556 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/inquire_8.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20846
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From oliverst at online dot de 2005-05-30 00:05 --- Maybe you should add Danny Smith to the CC list. -- What|Removed |Added Component|target |gcov/profile http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug target/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30 00:04 --- (In reply to comment #8) > With -pg: This works on i686-pc-linux-gnu. Hopefully someone will look into this then, this is a target problem. -- What|Removed |Added Component|gcov/profile|target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From oliverst at online dot de 2005-05-30 00:03 --- With -pg: Program received signal SIGSEGV, Segmentation fault. 0x00401329 in [EMAIL PROTECTED] () (gdb) bt #0 0x00401329 in [EMAIL PROTECTED] () #1 0x00401375 in main () Without -pg: Program exited with code 010577614 -- What|Removed |Added Component|target |gcov/profile http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug target/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30 00:01 --- I mean mingw32. -- What|Removed |Added GCC target triplet||i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug target/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30 00:00 --- Could you try this testcase with -pg on cygwin? typedef struct STRING_POOL { int a; } STRING_POOL; typedef struct XML_Memory_Handling_Suite { int t; } XML_Memory_Handling_Suite; #define FASTCALL __attribute__((stdcall, regparm(3))) static void FASTCALL poolInit(STRING_POOL *pool, const XML_Memory_Handling_Suite *ms) { pool->a = 1; } int main(void) { STRING_POOL a; XML_Memory_Handling_Suite d; poolInit(&a, &d); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug target/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:57 --- Hmm, I want to say this is a bug dealing with FASTCALL. -- What|Removed |Added Component|gcov/profile|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From oliverst at online dot de 2005-05-29 23:54 --- Created an attachment (id=8988) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8988&action=view) isolated source from MAME 0.96u3 call "make maketree" and then "make xml2info.exe" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From oliverst at online dot de 2005-05-29 23:52 --- I attached a stripped down version of the source. You have to call "make maketree" and then "make xml2info.exe". The resulting executable with the backtrace seen in the initial post. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug inline-asm/8788] ICE in emit_move_insn, at expr.c:3089
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:48 --- Fixed on the mainline for 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8788
[Bug inline-asm/8788] ICE in emit_move_insn, at expr.c:3089
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:48 --- *** Bug 21811 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||larry at barello dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8788
[Bug c/21811] Union of odd byte array with integer causes asm constraint to fail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:48 --- *** This bug has been marked as a duplicate of 8788 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21811
[Bug c/21811] Union of odd byte array with integer causes asm constraint to fail
--- Additional Comments From larry at barello dot net 2005-05-29 23:42 --- Created an attachment (id=8987) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8987&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21811
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:41 --- Also do you have a simple testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug c/21811] New: Union of odd byte array with integer causes asm constraint to fail
-- Compiler --- Reading specs from C:/WinAVR/bin/../lib/gcc/avr/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=m:/WinAVR --build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++ --with-dwarf2 Thread model: single gcc version 3.4.3 -- Error message -- avr-gcc -g -Wall -Os -mmcu=atmega16 -DARC -DLED_DDR=DDRB -DLED=PB4 -DLED_PORT=PORTB -DSW_DDR=DDRB -DSW_PORT=PORTB -DSW_PIN=PINB -DSW=PB6 -DF_CPU=1600 -gdwarf-2 -mshort-calls -c -o foo.o foo.c foo.c: In function `foo': foo.c:12: internal compiler error: in emit_move_insn, at expr.c:2809 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [foo.o] Error 1 --- Source --- #include void foo (void) { union { uint16_t word; uint8_t byte[3];// <<< HERE IS THE BUG } bar; asm volatile ( "\tnop\n" : :"r" (bar) ); } commentary -- I simplified the test case to the bare essentials. The error occurs if the union is in SRAM or Registers, but oddly enough, NOT if it is on the stack (put it there by taking an address of the union...) If the array "byte" is made two long, then this doesn't occur. If "word" is a long, then "byte" needs to be 4 long (or it breaks). Someone from the avr-gcc list tried this out on the x86 compiler and it failed there as well (with the union in static ram rather than automatic) so it seems more generic than just an avr-gcc bug. -- Summary: Union of odd byte array with integer causes asm constraint to fail Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: larry at barello dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21811
[Bug gcov/profile/21810] -pg causes libexpat code to crash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 23:41 --- Are you sure that this is not a newlib/cygwin bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug c++/19756] -Wparentheses doesn't warn on ambiguous if in C++
--- Additional Comments From oliverst at online dot de 2005-05-29 23:38 --- If this is not going to be added any time soon for C++, maybe at least the manual should reflect, that it is a C-only warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19756
[Bug gcov/profile/21810] New: -pg causes libexpat code to crash
When you compile a program with "-pg" against libexpat 1.95.8 and you call XML_ParserCreate() it does crash. this is not happening, if you don't add "-pg". The source I used was distributed with the official MAME source code package (http://www.mame.net/downmain.html - win32 sourcecode, but the related source should be platform-independent). The easiest way to test it, is just to compile the "xml2info" tool, that part is of MAME, add "-pg" to compiler and linkers flags and run it, it will crash immediately. Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 5874 pool->blocks = NULL; (gdb) bt #0 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 #1 0x0040d339 in dtdCreate (ms=0x3f2554) at src/expat/xmlparse.c:5428 #2 0x00403193 in parserCreate (encodingName=0x0, memsuite=0x0, nameSep=0x0, dtd=0x0) at src/expat/xmlparse.c:737 #3 0x00402fb7 in XML_ParserCreate_MM (encodingName=0x0, memsuite=0x0, nameSep=0x0) at src/expat/xmlparse.c:671 #4 0x00402f4b in XML_ParserCreate (encodingName=0x0) at src/expat/xmlparse.c:648 #5 0x00402b7c in process (is=0x7803a690, os=0x7803a6b0) at src/xml2info.c:766 #6 0x00402efe in main (argc=1, argv=0x3f24c8) at src/xml2info.c:835 My GCC version: Reading specs from C:/MINGW/BIN/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host= mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable -languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz ation --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) -- Summary: -pg causes libexpat code to crash Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliverst at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21784
[Bug c++/21210] [4.0/4.1 Regression] Trouble with __complex__ types default construction
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-29 21:27 --- See: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02777.html for additional analysis regarding this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
[Bug target/21315] Unable to link Fortran executables: __builtin_isfinite is undefined
-- Bug 21315 depends on bug 19933, which changed state. Bug 19933 Summary: Problem with define of HUGE_VAL in math_c99. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21315
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-29 20:52 --- Patch backported to 3.4 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 20:45 --- Subject: Bug 19933 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-05-29 20:45:44 Modified files: gcc: ChangeLog gcc/testsuite : ChangeLog gcc/fixinc : fixincl.x inclhack.def Added files: gcc/testsuite/gcc.dg: c99-math-double-1.c c99-math-float-1.c c99-math.h c99-math-long-double-1.c gcc/fixinc/tests/base/iso: math_c99.h Log message: PR target/19933 * fixinc/inclhack.def (solaris_math_6_1): New fix. (solaris_math_9): Rewrite and guard with #ifdef __sparc__. * fixinc/fixincl.x: Regenerate. * fixinc/tests/base/iso/math_c99.h: Adjust for above changes. Backport from mainline: 2005-05-19 Eric Botcazou <[EMAIL PROTECTED]> Joseph S. Myers <[EMAIL PROTECTED]> * fixinc/inclhack.def: New fixes solaris_math_[1-9]. * fixinc/fixincl.x: Regenerate. * fixinc/tests/base/iso/math_c99.h: New. Backport from mainline: 2005-05-10 Joseph S. Myers <[EMAIL PROTECTED]> * fixinc/inclhack.def (stdio_stdarg_h, stdio_va_list): Bypass on *-*-solaris2.1[0-9]*, not just *-*-solaris2.1[0-9]. * fixinc/fixincl.x: Regenerate. Backport from mainline: 2004-11-26 Mark Mitchell <[EMAIL PROTECTED]> * fixinc/inclhack.def (gnu_types): Do not use on Solaris 2.1x. (stdio_va_list): Likewise. (stdio_stdarg.h): Likewise. (solaris_stdio_tag): Add bypass. * fixinc/fixincl.x: Regenerated. testsuite/ * gcc.dg/c99-math.h: New * gcc.dg/c99-math-float-1.c: New test. * gcc.dg/c99-math-double-1.c: Likewise. * gcc.dg/c99-math-long-double-1.c: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.872&r2=2.2326.2.873 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.398&r2=1.3389.2.399 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-double-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-float-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-long-double-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/fixincl.x.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.177.4.10&r2=1.177.4.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/inclhack.def.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.190.4.10&r2=1.190.4.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/tests/base/iso/math_c99.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug c++/17166] Improve diagnostic for empty overload set listing the rejected overloads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 20:37 --- *** Bug 21808 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17166
[Bug c++/21808] Uninformative diagnostic for name lookup for template functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 20:37 --- But the problem with the error message is the same which is why I closed it as a dup. My point is that being in a template have nothing to do with it here and the error message could be improved yes which is why 17166 is not closed. *** This bug has been marked as a duplicate of 17166 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
[Bug c++/21808] Uninformative diagnostic for name lookup for template functions
--- Additional Comments From veksler at il dot ibm dot com 2005-05-29 20:33 --- I disagree. 1. Because it is a template the "correct" error is supressed. 2. It passes with gcc-3.3, but fails with gcc-3.4.3 This is unlike your example: template struct A { T t; }; // Swap following 2 functions to get conforming C++ template struct B {static const int t = i;}; template void foo1(const A& data); void foo(const A& data) { foo1((int)data.t); } void foo1(int data); Which works neither with gcc-3.3 nor with gcc-3.4.4 -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 20:09 --- > You seem like someone who does not want to do the leg work > of getting your programs fixed so you don't depend on this. Regardless, other poeple dependant on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/20191] ICE in reload_cse_simplify_operands, on powerpc linux
-- What|Removed |Added GCC build triplet|powerpc-unknown-linux-gnu | GCC host triplet|powerpc-unknown-linux-gnu | GCC target triplet|powerpc-unknown-linux-gnu |powerpc-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20191
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:56 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:56 --- (In reply to comment #20) > Yes, assert fails in some cases (I think of a hundred at moment!). See now you did not read my comment, I said it is _ALLOWED by the standard to ___FAIL___. How much clearer do you need it? ALSO READ UP on excessive precision. You seem like someone who does not want to do the leg work of getting your programs fixed so you don't depend on this. Note this is how x87 works, live with it. Just stop buying x86 machines if you don't like this. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:51 --- (In reply to comment #19) > That is not going to change, the assert is allowed to fail by the standard by the way. > Yes, assert fails in some cases (I think of a hundred at moment!). -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:47 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:47 --- That is not going to change, the assert is allowed to fail by the standard by the way. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:46 --- > Again just use -ffloat-store as required not get the excessive precision. > This should included in gcc spec file by defaults. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:43 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:43 --- (In reply to comment #15) > x86-64 has support for SSE3 so it would use that instead. Actually that is wrong, the subset which is supported by AMD and Intel (EM64T) only have SSE, SSE2, and MMX. AMD's x86_64 which in my mind the true x86_64 has also support for 3dnow. Intel's EM64t have SSE3. Again just use -ffloat-store as required not get the excessive precision. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From joseph at codesourcery dot com 2005-05-29 19:37 --- Subject: Re: New: [3.4/4.0/4.1 Regression] Floating Optimization Bug On Sun, 29 May 2005, themis_hv at yahoo dot co dot uk wrote: > This case (test-case.c) works with gcc -O0 without a problem. > > But with gcc {-O1,-O2,-O3,-Os} causes the following error: > test: test.c:9: main: Assertion 'a == x' failed' Not if you use -ffloat-store, as is required if you wish to avoid such instances of paradoxical excess precision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:36 --- > > It be good idea to do that by default then? > It is on x86_64, remember SSE is not every where. > x86-64 has support for SSE3 so it would use that instead. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:35 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:35 --- (In reply to comment #13) > (In reply to comment #10) > > Please go read the papers. Basically x87 is broken in this respect, use > eithera different machine or use > > SSE. > It be good idea to do that by default then? It is on x86_64, remember SSE is not every where. Just use -ffloat-store instead. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug libfortran/15160] Generated files don't regenerate
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-29 19:32 --- To be more precise, on i686-pc-linux-gnu, I created an empty directory, cd'd into it, and then ran ../gcc-4.0/configure --prefix=$HOME --enable-maintainer-mode --enable-languages=c,f95 make bootstrap Same thing for 4.1. Thomas -- What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15160
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:32 --- (In reply to comment #10) > Please go read the papers. Basically x87 is broken in this respect, use eithera different machine or use > SSE. It be good idea to do that by default then? -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:31 --- (In reply to comment #11) > This is *not* related to precission. > > This is behaviour, you would expect from a compiler. For non floating point, yes but floating point is different with respect with precission. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:28 --- Read the code carefully: test-case.c: #include volatile float x = 3; int main() { float a = 1 / x; x = a; assert(a == x); } Notice x = a before assertion, both of these variables are of the same data type. This is *not* related to precission. This is behaviour, you would expect from a compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:24 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:24 --- Please go read the papers. Basically x87 is broken in this respect, use either a different machine or use SSE. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:18 --- Surely assigning a float value to another float variable should not cause any rounding as they are same data type. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:06 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 19:06 --- when you store it to memory the precission goes down (aka rounding) read 323 and all the rest of the problems related to it. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 19:01 --- It should be logical equivalent regardless of how it stored in memory. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 18:27 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 18:27 --- (In reply to comment #5) > Should I put this as separate PR? Actually this is all a dup of bug 323. The "problem" is excessive pression, which most non fp developers will not know about, read the full PR 323 and the references to papers which talk about this. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug java/21695] ICE when building gnu-xml.lo in libjava directory
-- What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21695
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 17:58 --- This also occurs with double, using test-case.c but with float replaced with double, so code fragment looks like: test-case.c: #include volatile double x = 3; int main() { double a = 1 / x; x = a; assert(a == x); } Should I put this as separate PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug c++/17413] [3.4 regression] local classes as template argument
--- Additional Comments From mark at codesourcery dot com 2005-05-29 17:18 --- Subject: Re: [3.4 regression] local classes as template argument Geoffrey Keating wrote: > Hi Mark, > > Consider this code: > > struct Attribute { }; > template void fun (const Attribute &attr, const T &value); > extern void fun (int attr, int value); > enum { anon = 666 }; > > void test(int foo) > { fun (foo, anon); } > > I believe this is valid C++. Template argument deduction will fail > when it compares the type of the *first* parameter of fun(), since no > value of T can be found that will make the first parameter match. As you've discovered, we don't perform template argument deduction on arguments that do not involve template types. I agree that there's nothing in the standard to support that behavior. However, there are a lot of DRs in this area, and we should check the behavior of other compilers before making any changes here. Those checks should be done without using anonymous enums, since there's additional controversy around that particular issue; instead, some way to isolate what set of template functions can be deduced is required. I don't remember the origin of the comment in the code that refers to infinite recursion. I don't think adding DEDUCE_CALL to the condition makes sense, though; either we should always do the comparsion, or only when DEDUCE_EXACT. Furthermore, your change is not correct, in that deduction permits non-exact matches for calls; see [temp.deduct.call]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17413
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 17:04 --- This is a target problem, as the RTL is correct. Looks like there is a forgotten rounding back to float. -- What|Removed |Added Component|rtl-optimization|target GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Summary|[3.4/4.0/4.1 Regression]|Floating Optimization Bug |Floating Optimization Bug | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/21809] [3.4/4.0/4.1 Regression] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29 16:44 --- x and a should be identical, so assertion should not fail at all. since a is assigned to x, it has *SAME* rounding precision. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/21809] [3.4/4.0/4.1 Regression] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:39 --- Note every GCC from 2.95.3 gives the same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:24 --- *** Bug 21809 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||themis_hv at yahoo dot co ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug rtl-optimization/21809] [3.4/4.0/4.1 Regression] Floating Optimization Bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:24 --- *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/21809] New: [3.4/4.0/4.1 Regression] Floating Optimization Bug
This problems occurs with GCC 3.4.4, gcc-4.0-20050521 snapshot and gcc-4.1-20050528 snapshot. test-case.c: #include volatile float x = 3; int main() { float a = 1 / x; x = a; assert(a == x); } This case (test-case.c) works with gcc -O0 without a problem. But with gcc {-O1,-O2,-O3,-Os} causes the following error: test: test.c:9: main: Assertion 'a == x' failed' -- Summary: [3.4/4.0/4.1 Regression] Floating Optimization Bug Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: themis_hv at yahoo dot co dot uk CC: gcc-bugs at gcc dot gnu dot org,themis_hv at yahoo dot co dot uk 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=21809
[Bug target/21297] [4.0 Regression] buf[i+i]=0 stores buf[i] when -O2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 21297 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.44&r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21297
[Bug fortran/18890] ICE at assign CHARACTER POINTER array to POINTER or ALLOCATABLE one
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 18890 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.44&r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18890
[Bug fortran/17202] ice-on-valid-code, trans-array.c:217: gfc_conv_descriptor_dtype Assertion failed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 17202 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.44&r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17202
[Bug fortran/18689] Internal compiler error with character pointer association in module subroutine
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 18689 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.44&r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18689
[Bug fortran/16939] Pointers not passed as subroutine arguments
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 16939 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.44&r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16939
[Bug fortran/17192] Functions returning character pointer via argument are broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 17192 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.44&r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17192
[Bug c++/21808] Uninformative diagnostic for name lookup for template functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:02 --- If you called a different function name instead of a template one, I get the following error: t.cc: In function void foo(const A&): t.cc:7: error: there are no arguments to foo1 that depend on a template parameter, so a declaration of foo1 must be available t.cc:7: error: (if you use -fpermissive, G++ will accept your code, but allowing the use of an undeclared name is deprecated) template struct A { T t; }; // Swap following 2 functions to get conforming C++ template struct B {static const int t = i;}; template void foo(const A& data) { foo1((int)data.t); } void foo1(int data); In fact this has nothing to do with dependent or not, see the following code (which gives the same error message in 3.3.3 also): template struct A { T t; }; // Swap following 2 functions to get conforming C++ template struct B {static const int t = i;}; template void foo1(const A& data); void foo(const A& data) { foo1((int)data.t); } void foo1(int data); So the error message problem, in fact that is PR 17166 which I am going to mark this as a dup of. *** This bug has been marked as a duplicate of 17166 *** -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Keywords||diagnostic Resolution||DUPLICATE Summary|Uninformative diagnostic for|Uninformative diagnostic for |name lookup from template |name lookup for template |function|functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
[Bug c++/17166] Improve diagnostic for empty overload set listing the rejected overloads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:02 --- *** Bug 21808 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||veksler at il dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17166
[Bug fortran/17193] [meta-bug] Pointer arguments not working correctly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 16:02 --- Subject: Bug 17193 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 16:02:11 Modified files: gcc/fortran: trans-array.c trans-expr.c Log message: 2005-05-29 Paul Thomas <[EMAIL PROTECTED]> PR fortran/16939 PR fortran/17192 PR fortran/17193 PR fortran/17202 PR fortran/18689 PR fortran/18890 PR fortran/21297 * fortran/trans-array.c (gfc_conv_resolve_dependencies): Add string length to temp_ss for character pointer array assignments. * fortran/trans-expr.c (gfc_conv_variable): Correct errors in dereferencing of characters and character pointers. * fortran/trans-expr.c (gfc_conv_function_call): Provide string length as return argument for various kinds of handling of return. Return a char[]* temporary for character pointer functions and dereference the temporary upon return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.44&r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17193
[Bug c++/17166] Improve diagnostic for empty overload set listing the rejected overloads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 16:02 --- The testcase really boils down to: template int foo (); int i = foo(1); OR template struct f{}; template int foo (f); int i = foo(1); -- What|Removed |Added Last reconfirmed|2004-10-28 03:58:46 |2005-05-29 16:02:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17166
[Bug c++/21808] New: Uninformative diagnostic for name lookup from template function
Template code that used to work prior to gcc-3.4 fails in very uninformative ways. Diagnostic should be improved. For example: $ cat t.cpp template struct A { T t; }; // Swap following 2 functions to get conforming C++ template void foo(const A& data) { foo((int)data.t); } void foo(int data); $ g++ t2.cpp t2.cpp: In function `void foo(const A&)': t2.cpp:5: error: no matching function for call to `foo(int&)' As an exaple for a good diagnostic: int f() { for (int i=0 ; i < 4 ; ++i) {} return i; } t4.cpp: In function `int f()': t4.cpp:5: name lookup of `i' changed for new ISO `for' scoping t4.cpp:3: using obsolete binding at `i' It would be nice to have something like: t2.cpp: In function `void foo(const A&)': t2.cpp:5: error: name lookup of `foo(int&)' changed for new ISO `template' functions. t2.cpp:9: error: using not dependent `foo(int)' is no longer supported. -- Summary: Uninformative diagnostic for name lookup from template function Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: veksler at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
[Bug tree-optimization/21639] [4.1 Regression] poisoned ggc memory used for -ftree-vectorize
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:40 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21639
[Bug tree-optimization/21805] loop optimizers are not GC safe
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:40 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-29 14:40:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21805
[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:16 --- (In reply to comment #12) > Will the patch be applied to 4.0 branch too? No because it is too big in that it also changes the inliner to be a CFG aware inliner. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699
[Bug middle-end/21790] gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:09 --- *** Bug 21807 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21790
[Bug middle-end/21807] gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:09 --- *** This bug has been marked as a duplicate of 21790 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21807
[Bug c++/21806] Incorrect stack allocation of complex objects
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-29 14:06 --- Could you attach the preprocessed source? -- What|Removed |Added Severity|critical|normal Summary|Incorrect stack allocation |Incorrect stack allocation |of complex objects |of complex objects http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21806
[Bug c/21807] New: gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds
Using a host system of Linux 2.6.8.1, binutils version 2.16 and the aforementioned GCC, I have observed the following gcc segmentation faults: util-linux-2.12q: -pipe -O2 -mtune=i486 -fomit-frame-pointer (defaults) fdiskbsdlabel.c: In function 'bselect' (void): fdiskbsdlabel.c: 164: internal compiler error: Segmentation fault sfdisk.c: In function 'do_fdisk (static void)': sfdisk.c:3006: internal compiler error: Segmentation fault I have also found that many variations of '-march=pentium4 -OX' segfault when compiling different instantiations of quotearg. For example: patch-2.5.9: quotearg.c: In function 'quotearg_char' quotearg.c:619: internal compiler error: Segmentation fault when -O3 was used, but worked fine with a -O2 optimization. (I realize that optimizations greater than -O2 are risky but I didn't expect the compiler to choke with a segmentation fault). I marked this as critical because it causes a seg fault and thought that someone might want to know. Sean McLinden Allegheny County Health Department -- Summary: gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mclinden at informed dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i696-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21807
[Bug c++/21806] New: Incorrect stack allocation of complex objects
The bug leads to corruption of program's data. Two objects on the stack overlap so that the constructor of the second one erases some data of the first one. I've checked the whole program with valgrind and it didn't report anything incorrect that I might have done with memory allocation, pointers etc. Bug exists independently from optimization flags. Incorrect program fragment: - int main(int argc, char* argv[]) { THttpServer HttpServer; THttpSessionBroker SessionBroker;// error occurs at this line SessionBroker.SetServletConstructor(&TMainServlet::Create); HttpServer.RegisterServlet(&SessionBroker, "/"); HttpServer.SetLocalPort(); HttpServer.Run(); } GDB session that proves objects are not placed on the stack as they should be: -- GNU gdb 5.3 Copyright 2002 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 "i386-slackware-linux"... (gdb) break main.cpp:25 Breakpoint 1 at 0x80492a4: file main.cpp, line 25. (gdb) run Starting program: /home/pkolaczk/projects/dns/dns [New Thread 16384 (LWP 5218)] [New Thread 32769 (LWP 5219)] [New Thread 16386 (LWP 5220)] [New Thread 32771 (LWP 5221)] [New Thread 49154 (LWP 5222)] [Switching to Thread 16384 (LWP 5218)] Breakpoint 1, main (argc=1, argv=0xb7f4) at main.cpp:26 26 THttpServer HttpServer; (gdb) next [New Thread 65539 (LWP 5223)] [New Thread 81924 (LWP 5224)] [New Thread 98309 (LWP 5225)] [New Thread 114694 (LWP 5226)] [New Thread 131079 (LWP 5227)] 27 THttpSessionBroker SessionBroker; (gdb) print &HttpServer $1 = (THttpServer *) 0xb760 (gdb) print sizeof(HttpServer) $2 = 48 (gdb) print &SessionBroker $3 = (THttpSessionBroker *) 0xb6a0 (gdb) print sizeof(SessionBroker) $4 = 272 (gdb) print &SessionBroker.SessionTimer $5 = (class TTimer *) 0xb6e0 (gdb) print &SessionBroker.SessionTimer.Stopper $6 = (TMutex *) 0xb758 (gdb) print &SessionBroker.SessionTimer.TaskListProtection $7 = (TMutex *) 0xb774 // ITS BEYOND 0xb760 !!! (gdb) x/8xa 0xb760 0xb760: 0x804e2d8 0x804e2d0 0x804e670 0x804e668 0xb770: 0x804e3d0 0x804e3c8 0x804e200 0x804e1f8 (gdb) next// create the second object [New Thread 147464 (LWP 5228)] 29 HttpServer.RegisterServlet(&SessionBroker, "/"); (gdb) x/8xa 0xb760 0xb760: 0x0 0x0 0xbebff990 0x0 0xb770: 0x804e3d0 0x804e3c8 0x0 0x0 (gdb) Seems the overlapping area is at least 28 bytes large. By more extensive debugging I've found out that the stack corruption occurs in the constructor of SessionBroker.SessionTimer.Stopper object which only sets some of its fields and doesn't do any pointer arithmetic or anything that could write to memory it shouldn't. Everytime I run the program, everything goes the same way. The bug is not random as opposed to ordinary memory bugs. I've also made some experiments - putting an array between the two objects helps: int main(int argc, char* argv[]) { THttpServer HttpServer; int a[8]; THttpSessionBroker SessionBroker; //SessionBroker.SetServletConstructor(&TMainServlet::Create); HttpServer.RegisterServlet(&SessionBroker, "/"); HttpServer.SetLocalPort(); HttpServer.Run(); } Also if compiled with gcc 2.95.3, everything worked fine. Having this evidence (especially the gdb output), can it be the fault of my program or is it rather a compiler bug? Have I missed something? I can send you a complete source code if needed. Additional information: system type: Linux 2.6.11.7 processor: i686 (Pentium Celeron 2.4 GHz / 128k L2 cache) gcc version: 3.4.4 built from sources in a default way: "./configure" without any additional options -- Summary: Incorrect stack allocation of complex objects Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pkolaczk at elka dot pw dot edu dot pl CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: 3.4.4 GCC host triplet: 3.4.4 GCC target triplet: 3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21806
[Bug libfortran/15160] Generated files don't regenerate
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-29 12:40 --- Configuring with --enable-maintainer-mode fails: /home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.0/libgfortran -I. -iquote../../../gcc-4.0/libgfortran/io -std=gnu99 -Wall -O2 -g -O2 -c ../../../gcc-4.0/libgfortran/runtime/environ.c -fPIC -DPIC -o .libs/environ.o In file included from ../../../gcc-4.0/libgfortran/runtime/environ.c:35: ../../../gcc-4.0/libgfortran/libgfortran.h:63: error: conflicting types for 'int8_t' /usr/include/sys/types.h:191: error: previous declaration of 'int8_t' was here make[3]: *** [environ.lo] Error 1 make[3]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/ig25/gcc-4.0-bin' make: *** [bootstrap] Error 2 -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15160
[Bug libfortran/20006] $ format extension doesn't work
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 12:23 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:50 Modified files: gcc/fortran: ChangeLog io.c libgfortran: ChangeLog libgfortran/io : format.c transfer.c Log message: PR libfortran/20006 * io.c (format_item_1): Add check and extension warning for $ edit descriptor. * io/format.c (parse_format_list): Set repeat count of $ format node to 1. * io/transfer.c (read_sf): Add g.seen_dollar to the test concerning advancing I/O. (data_transfer_init): Likewise. (finalize_transfer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.437&r2=1.438 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&r1=1.22&r2=1.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.230&r2=1.231 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.41&r2=1.42 --- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 12:23 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:54 Modified files: gcc/fortran: ChangeLog io.c libgfortran: ChangeLog libgfortran/io : format.c transfer.c Log message: PR libfortran/20006 * io.c (format_item_1): Add check and extension warning for $ edit descriptor. * io/format.c (parse_format_list): Set repeat count of $ format node to 1. * io/transfer.c (read_sf): Add g.seen_dollar to the test concerning advancing I/O. (data_transfer_init): Likewise. (finalize_transfer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.56&r2=1.335.2.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19.10.2&r2=1.19.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.44&r2=1.163.2.45 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9.12.1&r2=1.9.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.3&r2=1.32.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20006
[Bug libfortran/20006] $ format extension doesn't work
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 12:23 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:50 Modified files: gcc/fortran: ChangeLog io.c libgfortran: ChangeLog libgfortran/io : format.c transfer.c Log message: PR libfortran/20006 * io.c (format_item_1): Add check and extension warning for $ edit descriptor. * io/format.c (parse_format_list): Set repeat count of $ format node to 1. * io/transfer.c (read_sf): Add g.seen_dollar to the test concerning advancing I/O. (data_transfer_init): Likewise. (finalize_transfer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.437&r2=1.438 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&r1=1.22&r2=1.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.230&r2=1.231 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.41&r2=1.42 --- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-29 12:23 --- Subject: Bug 20006 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-29 12:22:54 Modified files: gcc/fortran: ChangeLog io.c libgfortran: ChangeLog libgfortran/io : format.c transfer.c Log message: PR libfortran/20006 * io.c (format_item_1): Add check and extension warning for $ edit descriptor. * io/format.c (parse_format_list): Set repeat count of $ format node to 1. * io/transfer.c (read_sf): Add g.seen_dollar to the test concerning advancing I/O. (data_transfer_init): Likewise. (finalize_transfer): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.56&r2=1.335.2.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19.10.2&r2=1.19.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.44&r2=1.163.2.45 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/format.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.9.12.1&r2=1.9.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.3&r2=1.32.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20006
[Bug fortran/21063] ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function
--- Additional Comments From aj at gcc dot gnu dot org 2005-05-29 08:44 --- This ICE happens also with one of the SPEC CPU 2005 candidate benchmarks. I used: GNU Fortran 95 (GCC 4.0.1 20050529 (prerelease)) on Linux/x86-64. -- What|Removed |Added OtherBugsDependingO|21359 |15502 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code
--- Additional Comments From ismail at kde dot org dot tr 2005-05-29 07:41 --- Will the patch be applied to 4.0 branch too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699