[Bug testsuite/23304] [4.1 Regression] testsuite failures: g++.dg/ext/packed3.C, packed4.C, packed8.c and g++.dg/other/crash-4.C
--- Comment #5 from hp at gcc dot gnu dot org 2005-10-22 07:40 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01369.html>. -- hp at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23304
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2005-10-22 08:24 --- Not SPARC/Solaris specific. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|sparc-sun-solaris2.8| GCC host triplet|sparc-sun-solaris2.8| GCC target triplet|sparc-sun-solaris2.8| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21554] [4.0/4.1 Regression] ext/array_allocator/2.cc execution fails
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-10-22 08:29 --- Present on mainline for SPARC 64-bit too: http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00788.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0 Regression]|[4.0/4.1 Regression] |ext/array_allocator/2.cc|ext/array_allocator/2.cc |execution fails |execution fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21554
[Bug target/14537] sparc-rtems predefines unix
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-10-22 08:34 --- 2005-01-24 Eric Botcazou <[EMAIL PROTECTED]> PR bootstrap/19364 * config.gcc (sparc-*-elf*): Remove sol2.h, sparc/sol2.h and sparc/elf.h, add sparc/sp-elf.h. (sparc-*-rtems*): Likewise. (sparclite-*-elf*): Remove sol2.h, sparc/sol2.h, sparc/elf.h and tm-dwarf2.h, add sparc/sp-elf.h. (sparc86x-*-elf): Likewise. (sparc64-*-elf*): Remove sol2.h, sparc/sol2.h and tm-dwarf2.h. * config/sparc/liteelf.h (TARGET_SUB_OS_CPP_BUILTINS): Rename into TARGET_OS_CPP_BUILTINS. * config/sparc/sp86x-elf (TARGET_SUB_OS_CPP_BUILTINS): Likewise. * config/sparc/rtemself.h (TARGET_SUB_OS_CPP_BUILTINS): Likewise. Undefine it. * config/sparc/openbsd64.h (NO_IMPLICIT_EXTERN_C): Undefine. * config/sparc/sp64-elf.h (NO_IMPLICIT_EXTERN_C): New macro. (SWITCH_TAKES_ARG): Likewise. (LOCAL_LABEL_PREFIX): Likewise. (ASM_GENERATE_INTERNAL_LABEL): Likewise. (TARGET_N_FORMAT_TYPES): Delete. (TARGET_FORMAT_TYPES): Likewise. (ASM_DECLARE_FUNCTION_SIZE): Likewise. * config/sparc/elf.h: Delete. * config/sparc/sp-elf.h: New file. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14537
[Bug ada/24480] subtype declared in generic child fails to match actual
--- Comment #1 from laurent at guerby dot net 2005-10-22 09:08 --- I confirm that 4.0.2 and 4.1.0 20051021 (experimental) show the same error: $ gcc -c levelx.adb levelx.adb:25:51: no visible subprogram matches the specification for "Any_Image3" levelx.adb:26:51: no visible subprogram matches the specification for "Any_Image3" levelx.adb:27:47: no visible subprogram matches the specification for "Any_Image3" I think this is indeed a bug, albeit for a very complex generics use :). -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-22 09:08:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24480
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #13 from olle at cb dot uu dot se 2005-10-22 09:43 --- (In reply to comment #12) > Workaround patch here: > http://gcc.gnu.org/ml/gcc/2005-09/msg00930.html > > Rest of discussion here: > http://gcc.gnu.org/ml/gcc/2005-10/msg00016.html > > Seems to be a gnatbind bug present on 4.0 and 4.1. Just confirmed that the suggested workaround works on tru64 5.1B with gcc-4.0.2 -- olle at cb dot uu dot se changed: What|Removed |Added CC||olle at cb dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug target/18631] [4.0 Regression] missing error messages passing vectors with -mno-altivec -mabi=altivec
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2005-10-22 09:52 --- Subject: Re: [4.0 Regression] missing error messages passing vectors with -mno-altivec -mabi=altivec I *think* it is also fixed on 4.0; a grep for the error message in config/rs6000/rs6000.c would confirm or deny this. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18631
[Bug bootstrap/24297] [4.1 Regression] libtool: link: unable to infer tagged configuration
--- Comment #10 from cvs-commit at gcc dot gnu dot org 2005-10-22 10:37 --- Subject: Bug 24297 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-22 10:37:17 Modified files: . : ChangeLog Makefile.tpl Makefile.in Log message: 2005-10-22 Paolo Bonzini <[EMAIL PROTECTED]> PR bootstrap/24297 * Makefile.tpl (do-[+make-target+], do-check, install, stage[+id+]-bubble, [+compare-target+]): Ensure $$r and $$s are set before recursing. * Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.1160&r2=1.1161 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.tpl.diff?cvsroot=gcc&r1=1.145&r2=1.146 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.282&r2=1.283 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24297
[Bug bootstrap/24297] [4.1 Regression] libtool: link: unable to infer tagged configuration
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-10-22 10:38 --- fix committed, the more complex patch will have to wait for 4.2 -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24297
[Bug c/24484] New: unrecognizable insn in extract_insn, at recog.c:2083
PROBLEM:
Tried to compile libapreq2-2.06 from the FreeBSD ports collection. Failed with
this message:
---
cc -DHAVE_CONFIG_H -I. -I. -I../include
-I/usr/local/include/apache2/modules/perl -I/usr/local/include/apache2
-I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -O -pipe -march=athlon -c
util.c -MT util.lo -MD -MP -MF .deps/util.TPlo -fPIC -DPIC -o .libs/util.o
util.c: In function `apreq_atoi64f':
util.c:52: error: unrecognizable insn:
(insn 66 172 67 8 util.c:44 (set (reg/f:SI 75)
(match_insn 677090144 ("C"))) -1 (nil)
(nil))
util.c:52: internal compiler error: in extract_insn, at recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
---
SYSTEM:
FreeBSD 5.3-RELEASE-p18 (Mon Jul 11 15:26:16 CEST 2005)
/usr/obj/usr/src/sys/DEVVV01 i386
GCC VERSION:
#gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
COMMAND LINE:
cc -DHAVE_CONFIG_H -I. -I. -I../include
-I/usr/local/include/apache2/modules/perl -I/usr/local/include/apache2
-I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -O -pipe -march=athlon -c
util.c -MT util.lo -MD -MP -MF .deps/util.TPlo -fPIC -DPIC -o .libs/util.o
Bug appears without -march and -O, too
Will append the .i file. Do you need more source code? It is available from the
libapreq page.
--
Summary: unrecognizable insn in extract_insn, at recog.c:2083
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richard at hirner dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
[Bug c/24484] unrecognizable insn in extract_insn, at recog.c:2083
--- Comment #1 from richard at hirner dot at 2005-10-22 11:05 --- Created an attachment (id=10044) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10044&action=view) generated with -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
[Bug libstdc++/21554] [4.0/4.1 Regression] ext/array_allocator/2.cc execution fails
--- Comment #8 from christian dot joensson at gmail dot com 2005-10-22 11:49 --- oops, sorry, present on sparc/sparc64 linux too, see, e.g, http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00927.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21554
[Bug libstdc++/21554] [4.0/4.1 Regression] ext/array_allocator/2.cc execution fails
--- Comment #9 from christian dot joensson at gmail dot com 2005-10-22 11:50 --- (In reply to comment #8) > oops, sorry, present on sparc/sparc64 linux too, see, e.g, > http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00927.html hmm, make that sparc64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21554
[Bug libgcj/24461] array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib
--- Comment #1 from jrandom-gcc at i2p dot net 2005-10-22 11:57 ---
Found the cause & can reproduce it. The bug can be reproduced by dealing with
a truncated gzip stream, as shown below. The fix, I believe, would have
GZIPInputStream using inf.getRemaining() to determine the tmp[] buffer size,
instead of the fixed 8 bytes. Note that classpath does not have the same
GZIPInputStream.read(byte[],int,int), and this bug hasn't been tested on a JVM
using classpath, so it may be gcj-specific.
[EMAIL PROTECTED] /tmp/b $ gcj -o bug --main=gunzipbug gunzipbug.java
[EMAIL PROTECTED] /tmp/b $ ./bug
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int,
int) (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0)
at java.util.zip.GZIPInputStream.read(byte[], int, int)
(/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0)
at gunzipbug.main(java.lang.String[]) (Unknown Source)
at gnu.java.lang.MainThread.call_main()
(/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0)
[EMAIL PROTECTED] /tmp/b $ javac gunzipbug.java
[EMAIL PROTECTED] /tmp/b $ java -cp . gunzipbug
java.io.EOFException: Unexpected end of ZLIB input stream
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:215)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:134)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:87)
at gunzipbug.main(gunzipbug.java:19)
[EMAIL PROTECTED] /tmp/b $ cat gunzipbug.java
import java.util.Random;
import java.util.zip.*;
import java.io.*;
public class gunzipbug {
public static void main(String args[]) {
try {
ByteArrayOutputStream full = new ByteArrayOutputStream(1024);
GZIPOutputStream gzout = new GZIPOutputStream(full);
byte buf[] = new byte[1024];
new Random().nextBytes(buf);
gzout.write(buf);
gzout.close();
byte gzdata[] = full.toByteArray();
// now only read the first 128 bytes of that data
ByteArrayInputStream truncated = new ByteArrayInputStream(gzdata, 0,
128);
GZIPInputStream gzin = new GZIPInputStream(truncated);
byte read[] = new byte[1024];
int cur = 0;
while ( (cur = gzin.read(read, cur, read.length-cur)) != -1)
; //noop
} catch (Exception e) {
e.printStackTrace();
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
[Bug target/24484] unrecognizable insn in extract_insn, at recog.c:2083
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-22 13:05 ---
The following instruction does not make sense at all:
(insn 66 172 67 8 util.c:44 (set (reg/f:SI 75)
(match_insn 677090144 ("C"))) -1 (nil)
(nil))
If you try to compile again, does it work?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |target
GCC target triplet||i386-pc-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
[Bug target/24484] unrecognizable insn in extract_insn, at recog.c:2083
--- Comment #3 from richard at hirner dot at 2005-10-22 13:34 --- No, I get the same error, even if I compile again without -O and -march. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
[Bug target/24484] unrecognizable insn in extract_insn, at recog.c:2083
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-22 13:40 --- I cannot reproduce this on i686-pc-linux-gnu, Can you report this to freebsd? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B
--- Comment #14 from bugzilla-gcc at thewrittenword dot com 2005-10-22 13:40 --- (In reply to comment #13) > (In reply to comment #12) > > Workaround patch here: > > http://gcc.gnu.org/ml/gcc/2005-09/msg00930.html > > > > Rest of discussion here: > > http://gcc.gnu.org/ml/gcc/2005-10/msg00016.html > > > > Seems to be a gnatbind bug present on 4.0 and 4.1. > > Just confirmed that the suggested workaround works on tru64 5.1B with > gcc-4.0.2 > Works on Tru64 UNIX 4.0D and 5.1 with gcc-4.0.2 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug c++/4882] fails to lookup a template specialization dependent of an outer template
--- Comment #9 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:55 --- Won't work on it for a long while. -- lerdsuwa at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4882
[Bug c++/8355] befriending a template specialization in another namespace
--- Comment #5 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:56 --- Won't work on it for a long while. -- lerdsuwa at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8355
[Bug c++/10574] Partial specialization selection failure involving a default template parameter from inside a template
--- Comment #5 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:56 --- Won't work on it for a long while. -- lerdsuwa at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10574
[Bug c++/13088] templatizing outer class hides specialization of inner template class
--- Comment #25 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:57 --- Won't work on it for a long while. -- lerdsuwa at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13088
[Bug c++/13166] DR136 not implemented
--- Comment #6 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:57 --- Won't work on it for a long while. -- lerdsuwa at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13166
[Bug c++/14032] non type boolean template argument partial specialization to argument in parent never matches
--- Comment #7 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:57 --- Won't work on it for a long while. -- lerdsuwa at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14032
[Bug c++/17122] Unable to compile friend operator within template
--- Comment #8 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:58 --- Won't work on it for a long while. -- lerdsuwa at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17122
[Bug c++/20420] Incorrectly Accepts double declarations
--- Comment #3 from lerdsuwa at gcc dot gnu dot org 2005-10-22 13:58 --- Won't work on it for a long while. -- lerdsuwa at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20420
[Bug c++/24485] New: g++ says 'ambiguous call'
Hi, While compiling this (very simplified) code under Linux <<"int" seem natural contrarily to the one from an enum -> char -> "const C &" using "C(char)" Obviously it is easy to write "(int) c + a" or "c + (int) a" to solve this problem. I apologize if this code is really ambiguous Best regards Bruno Pages -- Summary: g++ says 'ambiguous call' Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: minor Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bru dot pages at wanadoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24485
[Bug c/24486] New: gcc generates incorrect assignment because of reordering
Below you will find the C code for which I believe `gcc' generates an incorrect
assignment in `my_buggy_routine' (below) because it computes the destination
address too early. In other word, the assignment:
*(char *)(Current + 9) = my_computation (Current, i);
as the effect of
char * tmp = Current + 9
*tmp = my_computation (Current, i);
but this is incorrect because `Current' was actually modified by
`my_computation' and thus we assign to the wrong location.
I believe 3.x and earlier version of `gcc' were not doing that.
The version of gcc I'm using is the one that comes in Fedora Core 4 running on
a AMD64:
gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
The command line I'm using to compile `bug.c' is the following:
gcc -Wall -g bug.c -o bug
There are no errors/warnings triggered by this compilation.
Here is the `bug.c' file:
#include
#include
#include
typedef char * REFERENCE;
static REFERENCE * stack [10];
char my_computation (REFERENCE Current, int i) {
*stack[0] = *stack[0] + 10;
return 'a';
}
void my_buggy_routine (REFERENCE Current, int i) {
stack[0] = &Current;
*(char *)(Current + 9) = my_computation (Current, i);
}
int main () {
REFERENCE Current;
Current = (REFERENCE) malloc (100);
memset (Current, 0, 10);
my_buggy_routine (Current, 10);
return 0;
}
For reporting the bug, I've used the following command line:
gcc -Wall -g bug.c -o bug -v -save-temps
Which generates the following output
Using built-in specs.
Target: x86_64-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=x86_64-redhat-linux
Thread model: posix
gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/cc1 -E -quiet -v bug.c -mtune=k8
-Wall -fworking-directory -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/include
/usr/include
End of search list.
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/cc1 -fpreprocessed bug.i -quiet
-dumpbase bug.c -mtune=k8 -auxbase bug -g -Wall -version -o bug.s
GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8) (x86_64-redhat-linux)
compiled by GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128087
as -V -Qy -o bug.o bug.s
GNU assembler version 2.15.94.0.2.2 (x86_64-redhat-linux) using BFD version
2.15.94.0.2.2 20041220
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/collect2 --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o bug
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../.. -L/lib/../lib64
-L/usr/lib/../lib64 bug.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crtn.o
Thanks for looking into that matter.
Regards,
Manu
--
Summary: gcc generates incorrect assignment because of reordering
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: blocker
Priority: P1
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manus at eiffel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2005-10-22 16:24 --- > In other word, the assignment: > > *(char *)(Current + 9) = my_computation (Current, i); > > as the effect of > > char * tmp = Current + 9 > *tmp = my_computation (Current, i); > > but this is incorrect because `Current' was actually modified by > `my_computation' and thus we assign to the wrong location. 6.5.16 Assignment Operators ยง4 The order of evaluation of the operands is unspecified. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #2 from manus at eiffel dot com 2005-10-22 16:37 --- I'm fine that you comply to the standard, but what I was reporting was not an incoherence with the standard, but with the fact that for the past 15 years `gcc' has always evaluated the source before evaluating the target. In other words this is a breaking change. Is there an explanation at why this was changed? In my case, I'm doing a moving GC and this will force code generators to always do assignments in 2 steps because of this suprising behavior. Regards, Manu -- manus at eiffel dot com changed: What|Removed |Added CC||manus at eiffel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2005-10-22 16:50 --- > In other words this is a breaking change. The change breaks nothing except invalid code. Your code has worked by accident up to now with GCC, it may never have worked with another compiler. > Is there an explanation at why this was changed? Probably new Tree-SSA infrastructure, i.e. high-level optimization framework. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug fortran/24426] gfortran ICE for valid derived type definition with default initialization
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-22 17:02 --- Subject: Bug 24426 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-22 17:02:42 Modified files: gcc/fortran: ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: der_pointer_4.f90 Log message: 2005-10-22 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/24426 * decl.c (variable_decl): Don't assign default initializers to pointers. 2005-10-22 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/24426 * gfortran.dg/der_pointer_4.f90: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.591&r2=1.592 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&r1=1.43&r2=1.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6230&r2=1.6231 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/der_pointer_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24426
[Bug fortran/24426] gfortran ICE for valid derived type definition with default initialization
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-22 17:09 --- Subject: Bug 24426 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-22 17:09:04 Modified files: gcc/fortran: ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: der_pointer_4.f90 Log message: 2005-10-22 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/24426 * decl.c (variable_decl): Don't assign default initializers to pointers. 2005-10-22 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/24426 * gfortran.dg/der_pointer_4.f90: New. 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.132&r2=1.335.2.133 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31.2.6&r2=1.31.2.7 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.479&r2=1.5084.2.480 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/der_pointer_4.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=24426
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #4 from manus at eiffel dot com 2005-10-22 17:20 --- I agree that relying on gcc's behavior might be the wrong thing to do, but when this is 15 years old code, you can expect that it will still continue to work. Moreover, it works on all the C compilers I've ever used except gcc 4.0. This includes: - SGI C compiler - Sun C compiler - Borland C - Microsoft C Too bad that gcc 4.0 breaks this. The other things is that it occurs without any optimization. I realize that most of the `unspecified' in the standard is for allowing more optimization, but when you compile without them, it is rather strange that it does this one. Would it make sense to have a new option in `gcc' to say that target is always evaluated after source is? I think that would make transition to gcc 4.0. For now I can only recommend to my users to stick with the 3.x based versions. Regards, Manu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
Re: [Bug c/24486] gcc generates incorrect assignment because of reordering
On Saturday 22 October 2005 13:20, manus at eiffel dot com wrote: > Would it make sense to have a new option in `gcc' to say that target is > always evaluated after source is? > Not really possible. You are correct that it occurs at any optimization level. The bug in your code is exposed when GCC creates the intermediate representation for your program. In that intermediate representation, GCC is explicitly exposing the sequence points in expression evaluation using the standard rules. Your program breaks simply because it is not following the sequence points dictated by the standard.
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #5 from dnovillo at redhat dot com 2005-10-22 17:32 --- Subject: Re: gcc generates incorrect assignment because of reordering On Saturday 22 October 2005 13:20, manus at eiffel dot com wrote: > Would it make sense to have a new option in `gcc' to say that target is > always evaluated after source is? > Not really possible. You are correct that it occurs at any optimization level. The bug in your code is exposed when GCC creates the intermediate representation for your program. In that intermediate representation, GCC is explicitly exposing the sequence points in expression evaluation using the standard rules. Your program breaks simply because it is not following the sequence points dictated by the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-10-22 17:34 --- > Would it make sense to have a new option in `gcc' to say that target is always > evaluated after source is? I think that would make transition to gcc 4.0. No, the compiler has already far too many command line switches. And that would probably be a nightmare to implement, let alone to maintain. > For now I can only recommend to my users to stick with the 3.x based versions. A better advice would be to read the ISO standard at least once, to clear simple misconceptions about the language like this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
Re: [Bug c/24486] gcc generates incorrect assignment because of reordering
On Saturday 22 October 2005 13:32, Diego Novillo wrote: > The bug in your code is exposed when GCC creates the intermediate > representation for your program. In that intermediate representation, > GCC is explicitly exposing the sequence points in expression evaluation > using the standard rules. > BTW, you can ask GCC to show you this initial representation with -fdump-tree-gimple. The file with extension .gimple shows you how this translation is done.
[Bug c/24486] gcc generates incorrect assignment because of reordering
--- Comment #7 from dnovillo at redhat dot com 2005-10-22 17:42 --- Subject: Re: gcc generates incorrect assignment because of reordering On Saturday 22 October 2005 13:32, Diego Novillo wrote: > The bug in your code is exposed when GCC creates the intermediate > representation for your program. In that intermediate representation, > GCC is explicitly exposing the sequence points in expression evaluation > using the standard rules. > BTW, you can ask GCC to show you this initial representation with -fdump-tree-gimple. The file with extension .gimple shows you how this translation is done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486
[Bug c++/24485] g++ says 'ambiguous call'
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-22 17:46 --- The C++ standard says they are ambiguous. -- 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=24485
[Bug c++/24485] g++ says 'ambiguous call'
--- Comment #2 from bru dot pages at wanadoo dot fr 2005-10-22 17:58 --- (In reply to comment #1) > The C++ standard says they are ambiguous. > ok, in this case g++ 3.3.3 is wrong because it says nothing, even with -Wall regards -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24485
[Bug gcov/profile/24487] New: Basic block frequencies inaccurate
The basic block frequencies used when compiling without profiling information appear to be non-sensical. For instance, a case where block 0 is fed by the entry block but has a frequency of 0. This causes EDGE_FREQUENCY to return zero, which affects optimizations such as final.c:compute_alignments(). An example is deflate.c from gzip-1.2.4a. Compiled with GCC mainline on powerpc-linux with options -m32 -O3 -mcpu=power4 -ffast-math -funroll-loops -fpeel-loops -ftree-loop-linear deflate.c.50.compgotos shows the following information for function deflate: Reordered sequence: 0 bb 0 [0] 1 bb 1 [0] 2 bb 2 [1] 3 bb 3 [1] 4 bb 4 [0] 5 bb 5 [0] 6 bb 6 [0] 7 bb 7 [0] 8 bb 8 [0] 9 bb 9 [0] 10 bb 10 [0] 11 bb 11 [0] 12 bb 12 [0] 13 bb 13 [0] 14 bb 14 [0] 15 bb 15 [0] 16 bb 16 [0] 17 bb 17 [0] 18 bb 18 [1] 19 bb 19 [0] 20 bb 20 [0] 21 bb 21 [0] 22 bb 22 [5] 23 bb 23 [5] 24 bb 24 [5] 25 bb 25 [3] 26 bb 26 [4] 27 bb 27 [4] 28 bb 28 [2] 29 bb 29 [1] 30 bb 30 [1250] 31 bb 31 [625] 32 bb 32 [1250] 33 bb 33 [625] 34 bb 34 [1250] 35 bb 35 [625] 36 bb 36 [1250] 37 bb 37 [625] 38 bb 38 [1250] 39 bb 39 [625] 40 bb 40 [1250] ... Basic blocks 10-11 contain a critical loop, but the basic block frequencies misrepresent it as a very cold block. -- Summary: Basic block frequencies inaccurate Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P2 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC target triplet: powerpc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24487
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #13 from arno at heho dot snv dot jussieu dot fr 2005-10-22 20:58 --- Shouldn't part of boehm-gc .h and config files be installed and picked up by #include ? Especially boehm-gc doc says pthread_create (and some other thread-functions) should not be called directly, but rather by including gc.h, which redefines them. And those redefinitions depend on values from gc_config.h (especially GC__THREADS). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug fortran/24426] gfortran ICE for valid derived type definition with default initialization
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-22 21:22 --- Fixed in 4.0.3 and above. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24426
[Bug target/24484] unrecognizable insn in extract_insn, at recog.c:2083
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24484
[Bug bootstrap/24394] Bootstrap failure: conflicting types for 'floatformat_to_double', others
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24394
[Bug objc/24393] [3.4/4.0/4.1 Regression] fatal error when missing closing paren in method argument type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24393
[Bug target/21623] [4.0/4.1 regression] ICE in reload_cse_simplify_operands, at postreload.c:391
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.3 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21623
[Bug target/24445] "unable to find a register to spill in class 'R0_REGS"
--- Comment #8 from rpjday at mindspring dot com 2005-10-22 21:36 --- Just now tested with new snapshot gcc-4.1-20051022, same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug ada/18819] [4.1 Regression] ACATS cdd2a02 fails at runtime
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/18819] [4.1 Regression] ACATS cdd2a02 fails at runtime
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/20548] [4.1 Regression] ACATS c52103x c52104x c52104y segfault at runtime on x86_64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
[Bug ada/21717] [4.1 regression] Endless stream of exceptions ( c95085a, c95085b and c95086a)
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-22 21:51 --- Does this work now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21717
[Bug middle-end/21953] [4.1 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
[Bug target/22017] [3.4/4.0/4.1 Regression] Error to pass struct parameter when compile with mingw's gcc.exe using "-march=i386 -mrtd" flags
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
[Bug preprocessor/22042] [3.4/4.0/4.1 Regression] stringification BUG
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-22 21:53 --- Sorry but my machine went bonkers and I cannot submit this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22042
[Bug ada/22333] [4.1 Regression] ACATS FAIL c34007p c34007r c45282b spurious discriminant CONSTRAINT_ERROR
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22333
[Bug middle-end/22429] [4.1 Regression] -1073741824 <= n && n <= 1073741823 is true where n is 1073741824
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-22 21:55 --- I am no longer working on this and my machine went bust today, sorry. If someone wants to take my patch and fix up for future comments, please do. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22429
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical GCC target triplet|i686-pc-* |i686-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug ada/22561] [4.1 Regression] ACATS ca11c01 wrong code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22561
[Bug tree-optimization/23109] [4.1 Regression] compiler generates wrong code leading to spurious division by zero with -funsafe-math-optimizations (instead of -ftrapping-math)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
[Bug tree-optimization/23115] [4.1 Regression] -ftree-vectorize generates wrong code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23115
[Bug rtl-optimization/23567] [3.4/4.0/4.1 regression] if-conversion causes wrong code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23567
[Bug target/23775] [4.1 Regression] wrong code in argument passing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
[Bug target/23731] [4.1 regression] [hppa] 475 test failures in libjava
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23731
[Bug c++/24488] New: GCC should warn about poorly implemented copy assignment operators
It would be nice for the C++ compiler to warn users when they implement copy
assignment operator that does not copy all parts of an object.
Build the following (contrived) program at maximum warning level:
class Copy
{
public:
Copy() : m_value(0), m_flag(false) {}
Copy& operator=(const Copy& source)
{
m_value = source.m_value;
return *this;
}
private:
int m_value;
bool m_flag;
};
int main()
{
Copy instance;
Copy another;
another = instance;
return 0;
}
Results:
No warning will results
Expected:
The C++ compiler could warn the user that certain members (i.e. m_flag) are not
copied in the implementation of the copy assignment operator.
--
Summary: GCC should warn about poorly implemented copy assignment
operators
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P5
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tron dot thomas at verizon dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24488
[Bug ada/23836] [4.0/4.1 Regression] Invalid code generated when accessing packed arrays / aliasing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23836
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug middle-end/23954] [4.1 regression] FAIL: gcc.c-torture/execute/20040709-1.c execution, -Os
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
[Bug middle-end/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-10-22 21:58 --- This most likely can be produced using C code, just has not found a testcase yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug middle-end/24178] [4.0/4.1 regression] generates code that produces unaligned access exceptions
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-22 21:59 --- Can someone try sparc-linux, I would not doubt this could be reproduced there too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug c++/24488] GCC should warn about poorly implemented copy assignment operators
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-22 22:02 --- Use -O1 -Wuninitialize and use another.m_flag and you will see that it warns about that. Copy constructs and copy assignment operators should never be treated special. -- 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=24488
[Bug libfortran/23272] [mingw32] inquire via filename fails
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-10-22 22:31 --- Patch posted (for simple cases only). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||10/msg01387.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-09-02 21:27:11 |2005-10-22 22:31:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23272
[Bug middle-end/24178] [4.0/4.1 regression] generates code that produces unaligned access exceptions
--- Comment #8 from falk at debian dot org 2005-10-22 22:42 --- (In reply to comment #7) > Can someone try sparc-linux, I would not doubt this could be reproduced there > too. Actually, it can't, as I tried to explain in comment #6, it is probably a bug in config/alpha/predicates.md (and it in fact goes away if I remove those two lines). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug libfortran/24489] New: read_block wrong execution order
The following test case reads past the end of record because sf_read is being executed before the check for length is performed. Discovered during testing of arrayio. See message: http://gcc.gnu.org/ml/fortran/2005-10/msg00382.html The following simplified test case shows the problem without using my arrayio patches not yet committed. program read_block character*4, dimension(8) :: abuf = (/"0123","4567","89AB","CDEF", & "0123","4567","89AB","CDEF"/) character*4, dimension(2,4) :: buf character*8 :: a equivalence (buf,abuf) read(buf, '(a8)') a print *, a end program read_block gfortran gives: $ ./a.out 01234567 ifort gives: $ ./a.out 0123 -- Summary: read_block wrong execution order Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: jvdelisle at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24489
[Bug libfortran/24489] read_block wrong execution order
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-10-22 22:58 --- Created an attachment (id=10045) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10045&action=view) Fix for this PR The attached patch fixes this PR. I will commit to mainline as obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24489
[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-22 23:59 --- I don't have time to work on this any more. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
[Bug tree-optimization/14442] [tree-ssa] missed sib if conversion optimization on the tree level (PHI-OPT misses that !(a == 0) is just a != 0)
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-23 00:01 --- And I don't have time for this any more. Maybe After I have laptop fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14442
[Bug middle-end/14840] [tree-ssa] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-23 00:01 --- Not working on this any more. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
[Bug tree-optimization/17506] [4.0/4.1 regression] warning about uninitialized variable points to wrong location
--- Comment #20 from pinskia at gcc dot gnu dot org 2005-10-23 00:02 --- No longer working on this. If someone to take my patch and update it and also update the testsuite, that is ok with me. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
[Bug c/18017] -Winit-self should automatically turn on -Wuninitialized
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-23 00:02 --- No longer working on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18017
[Bug tree-optimization/19505] [4.0/4.1 Regression] java bytecode to native ICE in remove_unreachable_regions
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-10-23 00:03 --- No longer working on this. Sorry, if someone wants to take my patch and update, that is ok with me. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug tree-optimization/19719] missed optimization on boolean operation with boolean arguments
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-23 00:04 --- I am no longer working on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19719
[Bug c/22065] -fdump-tree-original causes static function to emitted with the same name
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-23 00:04 --- No longer working on this, laptop is dead. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22065
[Bug target/23450] local functions should not sign extend results (and arguments) for speed reasons
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-23 00:05 --- I don't have time to work on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23450
[Bug tree-optimization/23603] VRP does not say range for a in a = b == c; is [0,1]
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-23 00:06 --- The patch above is almost correct and I just lost the correct one as my laptop is dead so I am no longer working on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
[Bug libobjc/9751] malloc of strlen, not strlen+1
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-23 00:08 --- No longer working on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9751
[Bug bootstrap/11660] libffi only builds when java is selected as language
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-23 00:08 --- No longer working on this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11660
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #14 from arno at heho dot snv dot jussieu dot fr 2005-10-23 00:21 --- Created an attachment (id=10046) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10046&action=view) CC test file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #15 from arno at heho dot snv dot jussieu dot fr 2005-10-23 00:22 --- Created an attachment (id=10047) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10047&action=view) simple class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug ada/21717] [4.1 regression] Endless stream of exceptions ( c95085a, c95085b and c95086a)
--- Comment #6 from schwab at suse dot de 2005-10-23 00:23 --- No, it is still the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21717
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #16 from arno at heho dot snv dot jussieu dot fr 2005-10-23 00:24 --- Created an attachment (id=10048) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10048&action=view) template for using jnew.java and gc-thread-register.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #17 from arno at heho dot snv dot jussieu dot fr 2005-10-23 00:28 --- I quickly wrote a testcase to illustrate my point (attached jnew.java Makefile gc-thread-register.cc) : Compiling and running gives : ./gc-thread-register Starting first thread ...done Collecting from unknown thread. Abort trap (core dumped) (I know I develop and test on freebsd for which boehm-gc-threading is not Tier-1, but :) Compiling and running with FAKE_GC_CONFIG (set correct include path in Makefile) defined gives : ./gc-thread-register Starting first thread ...done Starting second thread ...done NB, this does not necessarily explain (for me) why JvAttachCurrentThread() fails in some situations (as is the essence of this PR), I just thought that clearing up the interactions between gcj, boehm-gc and thread-lib might help in nearing down the causes. PS, I thought the attachments where just for this note -- arno at heho dot snv dot jussieu dot fr changed: What|Removed |Added CC||arno at heho dot snv dot ||jussieu dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug c/24490] New: gcc / gdb backtrace problem
Environment:
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure : (reconfigured) ./configure
--enable-languages=c,c++,fortran,java,objc --no-create --no-recursion
Thread model: posix
gcc version 4.1.0 20051022 (experimental)
Program:
#include
int main( int argc, char** argv )
{ abort( );
return 0;
}
Compile command:
gcc -O0 -ggdb -o test test.c
When run under 'gdb' then using the 'bt' commands results in
#0 0xe410 in __kernel_vsyscall ()
#1 0x00afa118 in raise () from /lib/libc.so.6
#2 0x00afb888 in abort () from /lib/libc.so.6
#3 0x080483a5 in main (argc=Could not find the frame base for "main".) at
test.c:4
Works correctly with:
gcc -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.1 20050727 (Red Hat 4.0.1-5)
backtrace then gives:
0 0xe410 in __kernel_vsyscall ()
#1 0x00afa118 in raise () from /lib/libc.so.6
#2 0x00afb888 in abort () from /lib/libc.so.6
#3 0x080483a5 in main (argc=Could not find the frame base for "main".) at
test.c:4
--
Summary: gcc / gdb backtrace problem
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kev dot gilbert at cdu dot edu dot au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24490
[Bug ada/24356] Unable to build gnatmake
--- Comment #1 from danglin at gcc dot gnu dot org 2005-10-23 04:48 --- Are U_IS_STUB_OR_CALLX and U_is_shared_pc in libcl.a on 11.23? Do you know if the 11.23 release notes document the observed changes to libcl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
[Bug c++/23992] warning at the time of compiling C++ code using gcc 2.95.3
--- Comment #3 from danglin at gcc dot gnu dot org 2005-10-23 04:56 --- 2.95.3 doesn't support HP-UX 11. This is documented in the installation notes. This problem is fixed in later releases. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23992
[Bug middle-end/24221] ICE in first_insn_after_basic_block_note on HPPA
--- Comment #1 from danglin at gcc dot gnu dot org 2005-10-23 05:15 --- Hmmm, I thought this problem was fixed by 2004-12-04 John David Anglin <[EMAIL PROTECTED]> PR middle-end/18730 * emit-rtl.c (get_first_nonnote_insn, get_last_nonnote_insn): When the first/last insn is a sequence, return the first/last insn of the sequence. Would you please provide preprocessed source and compilation details? -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24221
[Bug other/19165] (Natural) language independent error / warning classification
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-23 06:47 --- There's an Eclipse PR for this, fwiw: https://bugs.eclipse.org/bugs/show_bug.cgi?id=108720 If you look there you can see further motivation -- in particular, the continuation messages that gcc sometimes prints are basically confusing to an IDE. Parsing the translated message seems like a very difficult approach. Consider messages that have printf substitutions in them for instance. Or in the case in the above PR, there is nothing distinguishing about some of the continuation messages. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165
[Bug fortran/24311] Regression: ICE when MERGE is used with character args in a PRINT/WRITE statement
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-23 06:59 --- Subject: Bug 24311 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-23 06:59:18 Modified files: gcc/fortran: trans-expr.c iresolve.c ChangeLog libgfortran/intrinsics: spread_generic.c libgfortran: ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: assign_func_dtcomp_1.f90 merge_char_const.f90 spread_scalar_source.f90 Log message: 2005-10-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18022 * trans-expr.c (gfc_trans_arrayfunc_assign): Return NULL if there is a component ref during an array ref to force use of temporary in assignment. PR fortran/24311 PR fortran/24384 * fortran/iresolve.c (check_charlen_present): New function to add a charlen to the typespec, in the case of constant expressions. (gfc_resolve_merge, gfc_resolve_spread): Call.the above. (gfc_resolve_spread): Make calls to library functions that handle the case of the spread intrinsic with a scalar source. * libgfortran/intrinsics/spread_generic.c (spread_internal _scalar): New function that handles the special case of spread with a scalar source. This has interface functions - (spread_scalar, spread_char_scalar): New functions to interface with the calls specified in gfc_resolve_spread. 2005-10-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/18022 gfortran.dg/assign_func_dtcomp_1.f90: New test. PR fortran/24311 gfortran.dg/merge_char_const.f90: New test. PR fortran/24384 gfortran.dg/spread_scalar_source.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.65&r2=1.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/iresolve.c.diff?cvsroot=gcc&r1=1.42&r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.592&r2=1.593 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/spread_generic.c.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.329&r2=1.330 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_func_dtcomp_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/merge_char_const.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/spread_scalar_source.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6234&r2=1.6235 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24311
