[Bug libgcj/20135] Returning true from LinkedHashMap.removeEldestEntry does not remove entry
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-22 07:51 --- This was fixed a couple of days ago: http://lists.gnu.org/archive/html/classpath/2005-02/msg00085.html -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20135
[Bug libgcj/20136] Endless loop when using a SecurityManager
--- Additional Comments From thhal at mailblocks dot com 2005-02-22 07:46 --- Created an attachment (id=8252) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8252&action=view) Sample that reproduces the problem Use gcj --main foo and run the resulting file. It never exits. Run it with a standard java, it prints "OK, No endless loop" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20136
[Bug libgcj/20135] Returning true from LinkedHashMap.removeEldestEntry does not remove entry
--- Additional Comments From andreast at gcc dot gnu dot org 2005-02-22 07:44 --- forgot the gcc version: gcc version 4.0.0 20050221 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20135
[Bug libgcj/20136] New: Endless loop when using a SecurityManager
Installing a SecurityManager causes subsequent attempts to obtain a ClassLoader to go into an endless loop. -- Summary: Endless loop when using a SecurityManager Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thhal at mailblocks dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20136
[Bug libgcj/20135] Returning true from LinkedHashMap.removeEldestEntry does not remove entry
--- Additional Comments From andreast at gcc dot gnu dot org 2005-02-22 07:42 --- [wolfram:~] andreast% gcj foo.java --main=foo -o foo.exe [wolfram:~] andreast% ./foo.exe OK, Size is 15 [wolfram:~] andreast% gcj -v Using built-in specs. Reading specs from /Volumes/src/gcc/gcc-cvs/testbin/lib/gcc/powerpc-apple-darwin7.8.0/4.0.0/../../../libgcj.spec rename spec lib to liborig Target: powerpc-apple-darwin7.8.0 Configured with: /Volumes/src/gcc/gcc-cvs/gcc/configure --prefix=/Volumes/src/gcc/gcc-cvs/testbin --enable-languages=c,c++,java --enable-java-awt=gtk,xlib --enable-gtk-cairo --disable-checking --enable-libgcj-multifile Just a fyi, it seems to work on cvs 4.0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20135
[Bug libgcj/20135] Returning true from LinkedHashMap.removeEldestEntry does not remove entry
--- Additional Comments From thhal at mailblocks dot com 2005-02-22 07:31 --- Created an attachment (id=8251) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8251&action=view) Code to reproduce the problem Compile using gcj --main foo and run the result. Should print "ERROR, Size is 20". Compile and run using a standard Java, should print "OK, Size is 15". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20135
[Bug tree-optimization/20115] [4.0 Regression] Pure functions are mishandled
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 Known to work||3.3.6 3.4.4 Last reconfirmed|-00-00 00:00:00 |2005-02-22 07:28:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20115
[Bug libgcj/20135] New: Returning true from LinkedHashMap.removeEldestEntry does not remove entry
The LinkedHashMap fails to remove the eldest entry when returning true from the removeEldestEntry method. -- Summary: Returning true from LinkedHashMap.removeEldestEntry does not remove entry Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P1 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thhal at mailblocks dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20135
[Bug c++/20133] [4.0 Regression] internal compiler error: in import_export_decl, at cp/decl2.c:1726
--- Additional Comments From jean-marc dot valin at usherbrooke dot ca 2005-02-22 07:17 --- I changed the code, but I'm now getting unresolved symbols at link: batchflow.o(.gnu.linkonce.t._ZN12batchflowApp10initializeEiPPc+0x5a): In function `batchflowApp::initialize(int, char**)': : undefined reference to `ObjectPool >::stack' and so on for all the lines I changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20133
[Bug AWT/20014] BufferedImage.getGraphics() aborts
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-22 06:27:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20014
[Bug AWT/19880] Frame.setIconImage broken
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19880
[Bug AWT/19880] Frame.setIconImage broken
--- Additional Comments From fitzsim at redhat dot com 2005-02-22 06:26 --- This works for me on mainline. Closing. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Summary|Frame.setIconImage broken |Frame.setIconImage broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19880
[Bug AWT/17952] Windows don't show with window manager that supports _NET_REQUEST_FRAME_EXTENTS
--- Additional Comments From fitzsim at redhat dot com 2005-02-22 06:22 --- Fixed on mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17952
[Bug AWT/17952] Windows don't show with window manager that supports _NET_REQUEST_FRAME_EXTENTS
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22 06:13 --- Subject: Bug 17952 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-22 06:13:05 Modified files: libjava: ChangeLog libjava/gnu/java/awt/peer/gtk: GtkWindowPeer.java libjava/jni/gtk-peer: gnu_java_awt_peer_gtk_GtkToolkit.c gnu_java_awt_peer_gtk_GtkWindowPeer.c gtkpeer.h Log message: 2005-02-22 Thomas Fitzsimmons <[EMAIL PROTECTED]> PR libgcj/17952: * gnu/java/awt/peer/gtk/GtkWindowPeer.java, jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c (getWidth): New method. (getHeight): Likewise. (create): Remove width, height and insets parameters. Move size setup ... (realize_cb): ... here. New function. (connectSignals): Connect realize_cb. (request_frame_extents): Remove FIXME. Move postInsetsChangedEvent lookup ... * jni/gtk-peer/gnu_java_awt_peer_gtk_GtkToolkit.c (gtkInit): ... here. Look up GtkWindowPeer getWidth and getHeight methods. * jni/gtk-peer/gtkpeer.h (postInsetsChangedEventID): Declare jmethodID. (windowGetWidthID): Likewise. (windowGetHeightID): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3373&r2=1.3374 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/awt/peer/gtk/GtkWindowPeer.java.diff?cvsroot=gcc&r1=1.14&r2=1.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkToolkit.c.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c.diff?cvsroot=gcc&r1=1.32&r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/jni/gtk-peer/gtkpeer.h.diff?cvsroot=gcc&r1=1.18&r2=1.19 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17952
[Bug AWT/19842] MouseEvent ignores Button2 and Button3
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19842
[Bug AWT/19842] MouseEvent ignores Button2 and Button3
--- Additional Comments From fitzsim at redhat dot com 2005-02-22 04:54 --- Fixed on mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19842
[Bug AWT/19842] MouseEvent ignores Button2 and Button3
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22 04:50 --- Subject: Bug 19842 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-22 04:50:29 Modified files: libjava: ChangeLog libjava/jni/gtk-peer: gnu_java_awt_peer_gtk_GtkEvents.c Log message: 2005-02-21 Thomas Fitzsimmons <[EMAIL PROTECTED]> PR libgcj/19842 * jni/gtk-peer/gnu_java_awt_peer_gtk_GtkEvents.c (button_to_awt_mods): Return BUTTON masks, not BUTTON_DOWN masks. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3372&r2=1.3373 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkEvents.c.diff?cvsroot=gcc&r1=1.26&r2=1.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19842
[Bug java/8709] class init optimization should check subclasses
-- What|Removed |Added Severity|normal |enhancement Last reconfirmed|2004-08-24 01:13:24 |2005-02-22 04:12:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8709
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 20086, which changed state. Bug 20086 Summary: gfortran print routine has problem with the character 'h' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20086 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug libfortran/20086] gfortran print routine has problem with the character 'h'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 04:02 --- Fixed, thanks for your report (and hopefully the other ones will be looked at very soon). -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20086
[Bug libfortran/20086] gfortran print routine has problem with the character 'h'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22 03:26 --- Subject: Bug 20086 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-22 03:26:26 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : transfer.c Added files: gcc/testsuite/gfortran.dg: pr20086.f90 Log message: 2004-02-21 Bud Davis <[EMAIL PROTECTED]> PR fortran/20086 * io/transfer.c (write_constant_string): accept an 'h' as the start of a hollerith format string. 2005-02-21 Bud Davis <[EMAIL PROTECTED]> PR fortran/20086 * gfortran.dg/pr20086.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5064&r2=1.5065 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr20086.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.161&r2=1.162 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.31&r2=1.32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20086
[Bug c++/11618] Floating point values not reproduced at -O3 with a simple C++ copy constructor.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22 03:13 --- Subject: Bug 11618 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-22 03:13:35 Modified files: libjava: ChangeLog libjava/gcj: method.h libjava/java/io: ObjectInputStream.java ObjectStreamField.java VMObjectStreamClass.java natObjectInputStream.cc natVMObjectStreamClass.cc ObjectOutputStream.java libjava/java/lang/reflect: Field.java natField.cc Log message: 2005-02-21 Bryce McKinlay <[EMAIL PROTECTED]> Merge serialization from GNU Classpath. * gcj/method.h: Add missing #includes. * java/io/ObjectInputStream.java (readClassDescriptor): Check for primitive class IDs on the stream here... (resolveClass): ...not here. * java/io/ObjectStreamField.java: Use VMObjectStream class calls to set fields. * java/io/VMObjectStreamClass.java (setDoubleNative, setFloatNative, setLongNative, setIntNative, setShortNative, setCharNative, setByteNative, setBooleanNative, setObjectNative): New native methods. * java/io/natVMObjectStreamClass.java (setDoubleNative, setFloatNative, setLongNative, setIntNative, setShortNative, setCharNative, setByteNative, setBooleanNative, setObjectNative): Implement them. * java/io/natObjectInputStream.cc (allocateObject): Add new parameters from Classpath's version. Use _Jv_FromReflectedConstructor(). Call the constructor here. (callConstructor): Removed. (getCallersClassLoader): Removed. * java/lang/reflect/Field.java (setByte, setShort, setInt, setLong, setFloat, setDouble, setChar, setBoolean): Add 'checkFinal' parameter to control whether setting final field values is permitted. Call getAddr() with checkFinal parameter instead of setAddr(). * java/lang/reflect/natField.cc (getType): Lookup and resolve field only if not done already. (getAddr): Add checkFinal parameter. Do the final field check only if checkFinal is set. (setAddr): Removed. 2005-02-21 Mark Wielaard <[EMAIL PROTECTED]> # Fixes bug #11957 * java/io/ObjectInputStream.java (resolveClass): Don't check "void" twice. 2005-02-21 Mark Wielaard <[EMAIL PROTECTED]> Fixes bug #11618. * java/io/ObjectInputStream.java (readClassDescriptor): Handle classes without a super class and us ObjectStreamClass.lookupForClassObject(). (resolveClass): Check for primitive types. (lookupClass): Return null when argument is null. 2005-02-21 Jeroen Frijters <[EMAIL PROTECTED]> * java/io/ObjectInputStream.java (readObject): Fix to consume TC_ENDBLOCKDATA after readExternal. 2005-02-21 Jeroen Frijters <[EMAIL PROTECTED]> * java/io/ObjectOutputStream.java (writeObject, callWriteMethod): Replaced reflection with accessing cached info in ObjectStreamClass. (getMethod): Removed. * java/io/ObjectStreamClass.java (findMethod): Added check to make sure the method found has the right modifiers. (cacheMethods): Added writeReplace and writeObject methods. (setFlags): Look at new writeObjectMethod field instead of doing reflection again. (writeReplaceMethod): New field. (writeObjectMethod): New field. 2005-02-21 Guilhem Lavaux <[EMAIL PROTECTED]> Jeroen Frijters <[EMAIL PROTECTED]> * java/io/ObjectInputStream.java (newObject): Changed prototype. Get a constructor reflect object directly. (callConstructor): Removed. (allocateObject): Changed prototype. (readClassDescriptor): Build the constructor reflection directly. (readObject): Invoke newObject using the new prototype. * java/io/ObjectStreamClass.java (firstNonSerializableParent): Removed. (firstNonSerializableParentConstructor): Added. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3371&r2=1.3372 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/method.h.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/ObjectInputStream.java.diff?cvsroot=gcc&r1=1.40&r2=1.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/ObjectStreamField.java.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/VMObjectStreamClass.java.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/natObjectInputStream.cc.diff?cvsroot=gcc&r1=1.8&r2=1.9 http:/
[Bug c++/11957] [3.4 Regression] wrong "warning: statement has no effect"
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22 03:13 --- Subject: Bug 11957 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-22 03:13:35 Modified files: libjava: ChangeLog libjava/gcj: method.h libjava/java/io: ObjectInputStream.java ObjectStreamField.java VMObjectStreamClass.java natObjectInputStream.cc natVMObjectStreamClass.cc ObjectOutputStream.java libjava/java/lang/reflect: Field.java natField.cc Log message: 2005-02-21 Bryce McKinlay <[EMAIL PROTECTED]> Merge serialization from GNU Classpath. * gcj/method.h: Add missing #includes. * java/io/ObjectInputStream.java (readClassDescriptor): Check for primitive class IDs on the stream here... (resolveClass): ...not here. * java/io/ObjectStreamField.java: Use VMObjectStream class calls to set fields. * java/io/VMObjectStreamClass.java (setDoubleNative, setFloatNative, setLongNative, setIntNative, setShortNative, setCharNative, setByteNative, setBooleanNative, setObjectNative): New native methods. * java/io/natVMObjectStreamClass.java (setDoubleNative, setFloatNative, setLongNative, setIntNative, setShortNative, setCharNative, setByteNative, setBooleanNative, setObjectNative): Implement them. * java/io/natObjectInputStream.cc (allocateObject): Add new parameters from Classpath's version. Use _Jv_FromReflectedConstructor(). Call the constructor here. (callConstructor): Removed. (getCallersClassLoader): Removed. * java/lang/reflect/Field.java (setByte, setShort, setInt, setLong, setFloat, setDouble, setChar, setBoolean): Add 'checkFinal' parameter to control whether setting final field values is permitted. Call getAddr() with checkFinal parameter instead of setAddr(). * java/lang/reflect/natField.cc (getType): Lookup and resolve field only if not done already. (getAddr): Add checkFinal parameter. Do the final field check only if checkFinal is set. (setAddr): Removed. 2005-02-21 Mark Wielaard <[EMAIL PROTECTED]> # Fixes bug #11957 * java/io/ObjectInputStream.java (resolveClass): Don't check "void" twice. 2005-02-21 Mark Wielaard <[EMAIL PROTECTED]> Fixes bug #11618. * java/io/ObjectInputStream.java (readClassDescriptor): Handle classes without a super class and us ObjectStreamClass.lookupForClassObject(). (resolveClass): Check for primitive types. (lookupClass): Return null when argument is null. 2005-02-21 Jeroen Frijters <[EMAIL PROTECTED]> * java/io/ObjectInputStream.java (readObject): Fix to consume TC_ENDBLOCKDATA after readExternal. 2005-02-21 Jeroen Frijters <[EMAIL PROTECTED]> * java/io/ObjectOutputStream.java (writeObject, callWriteMethod): Replaced reflection with accessing cached info in ObjectStreamClass. (getMethod): Removed. * java/io/ObjectStreamClass.java (findMethod): Added check to make sure the method found has the right modifiers. (cacheMethods): Added writeReplace and writeObject methods. (setFlags): Look at new writeObjectMethod field instead of doing reflection again. (writeReplaceMethod): New field. (writeObjectMethod): New field. 2005-02-21 Guilhem Lavaux <[EMAIL PROTECTED]> Jeroen Frijters <[EMAIL PROTECTED]> * java/io/ObjectInputStream.java (newObject): Changed prototype. Get a constructor reflect object directly. (callConstructor): Removed. (allocateObject): Changed prototype. (readClassDescriptor): Build the constructor reflection directly. (readObject): Invoke newObject using the new prototype. * java/io/ObjectStreamClass.java (firstNonSerializableParent): Removed. (firstNonSerializableParentConstructor): Added. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3371&r2=1.3372 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/method.h.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/ObjectInputStream.java.diff?cvsroot=gcc&r1=1.40&r2=1.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/ObjectStreamField.java.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/VMObjectStreamClass.java.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/natObjectInputStream.cc.diff?cvsroot=gcc&r1=1.8&r2=1.9 http:/
[Bug tree-optimization/19786] [4.0 Regression] Aliasing optimisation bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 02:32 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From joseph at codesourcery dot com 2005-02-22 02:28 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) On Mon, 21 Feb 2005, geoffk at geoffk dot org wrote: > My suggestion is that this can be simplified as follows: > > - a CPP token is in the input form. An identifier outside cpp is in > 'internal' form. > - DECL_ASSEMBLER_NAME is in 'output' form. > - The 'diagnostic' form is created from the 'internal' form based > solely on the locale, at the time that a diagnostic is printed. Fine. Now, at present the conversions between these forms are trivial. So the audit required is of everywhere there is an assignment / copy / input / output between different forms to ensure that the appropriate conversions are applied instead of a straight copy as at present. For example, all the places printing IDENTIFIER_POINTER (id) with %qs become no longer valid, as IDENTIFIER_POINTER is in the internal form and %qs simply prints a string; %E may print an identifier as such, converting to the output form, but everywhere using %qs or some other output notation other than %E on an identifier needs checking and fixing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug tree-optimization/19786] [4.0 Regression] Aliasing optimisation bug
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22 02:27 --- Subject: Bug 19786 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-22 02:27:37 Modified files: gcc: ChangeLog tree-ssa-alias.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr19786.C Log message: gcc/ChangeLog: PR tree-optimization/19786 * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Add one tag to another's may-alias bitmap when adding to the other's list. gcc/testsuite/ChangeLog: PR tree-optimization/19786 * g++.dg/tree-ssa/pr19786.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7556&r2=2.7557 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gcc&r1=2.69&r2=2.70 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5063&r2=1.5064 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr19786.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From joseph at codesourcery dot com 2005-02-22
02:22 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Mon, 21 Feb 2005, neil at daikokuya dot co dot uk wrote:
> jsm28 at gcc dot gnu dot org wrote:-
>
> > * The greedy algorithm applies for lexing UCNs: for example,
> > a\U000z is three preprocessing tokens {a}{\}{U000z} (and
> > shouldn't get a diagnostic on lexing, presuming macros are defined
> > such that the eventual token sequence is valid).
>
> I'm not sure I agree with this: it would seem to be unnecessary
> extra work; further I suspect the user would benefit from it being
> pointed out he entered an ill-formed UCN rather than something random
> from the front end complaining about an unexpected backslash.
>
> The only case where you wouldn't get a syntax error from the
> front end, or an invalid escape in a literal, is with -E. I'm
> not sure lexing to the letter of the standard is worthwhile in
> this case, as the standard doesn't discuss -E.
>
> If you have an example where a compiled program is acceptable
> with multiple lexing tokens then I would agree with you.
#define a b(
#define b(x) q
int a\U000z );
Greedy lexing is the standard as applied for other token types. I don't
think a difference here makes sense. _cpp_valid_ucn would need changing
so it doesn't give an error for incomplete UCNs in identifiers but instead
returns quietly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From joseph at codesourcery dot com 2005-02-22 02:13 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) On Mon, 21 Feb 2005, zack at codesourcery dot com wrote: > Standing policy is that all cases which provoke undefined behavior > inside the preprocessor, except already-documented GNU extensions, > shall produce hard errors. I am tempted to make a partial exception Which policy (cf. bug 14634) I agree with. However, I don't think there should be any exception made. The standards (C99 and C++03) are implementable as-is. They have oddities; some of these may be suitable for submission as DRs, and if the committees fix them in a TC rather than a major new standard revision then we no longer need implement those oddities, but for now the standard says what it says. The headings in C99 Annex D are except for "Digits" irrelevant to the normative requirements; anything in "Digits" is a UCN for a digit, whether or not it appears elsewhere. (C++03 corrected the typo in C++98 which was noted in C++ DR 131.) The C++ standard's heading "CJK Unified Ideographs" lists ranges which also include various presentations forms such as one of the Hebrew characters previously discussed, but these are genuine ranges of letters clearly deliberately included; just the heading is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug tree-optimization/19952] ICE: tree check: expected class 'declaration', have 'statement' (label_expr) in tree_verify_flow_info, at tree-cfg.c:3709
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-22 01:51 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01283.html Devang, you got the wrong PR number in the name of the testcase and in the ChangeLog entry! -- What|Removed |Added CC|dpatel at gcc dot gnu dot | |org | AssignedTo|unassigned at gcc dot gnu |dpatel at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19952
[Bug libfortran/20037] libfortran: format termination bug in formatted write
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 01:50 --- Confirmed. -- What|Removed |Added BugsThisDependsOn||15332 Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-22 01:50:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20037
[Bug libfortran/20005] reading a single "return" character fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 01:49 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-22 01:49:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20005
[Bug libfortran/20068] Backspace problems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 01:46 --- Confirmed -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-22 01:46:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20068
[Bug c++/14172] g++ should not emit effc++ warnings in system headers
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-11-14 07:13:14 |2005-02-22 01:44:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14172
[Bug c++/17161] failure to diagnose an ill-formed instantiation on a local type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 01:42 --- This has now been fixed: t.cc: In function 'int main()': t.cc:10: error: 'main()::E' uses local type 'main()::E' t.cc:10: error: trying to instantiate 'template void S::foo(T)' -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17161
[Bug libfortran/20131] gfortan - incorrectly reads beyond the end of line.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 01:34 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-22 01:34:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
[Bug rtl-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
01:15 ---
Ok, I see what is going on now.
This is a RTL optimization bug.
The following (in .combine) is being combined:
(insn 37 35 38 4 (set (reg:SI 131)
(lshiftrt:SI (subreg/s/u:SI (reg/v:DI 122 [ x.4 ]) 4)
(const_int 1 [0x1]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:DI 122 [ x.4 ])
(nil)))
(insn 38 37 39 4 (set (reg/v:DI 122 [ x.4 ])
(zero_extend:DI (reg:SI 131))) -1 (insn_list:REG_DEP_TRUE 37 (nil))
(expr_list:REG_DEAD (reg:SI 131)
(nil)))
(insn 39 38 40 4 (set (reg:CC 132)
(compare:CC (reg/v:DI 122 [ x.4 ])
(const_int 0 [0x0]))) -1 (insn_list:REG_DEP_TRUE 38 (nil))
(nil))
Into:
(insn 39 38 40 4 (parallel [
(set (reg:CC 132)
(compare:CC (lshiftrt:DI (reg/v:DI 122 [ x.4 ])
(const_int 1 [0x1]))
(const_int 0 [0x0])))
(set (reg/v:DI 122 [ x.4 ])
(lshiftrt:DI (reg/v:DI 122 [ x.4 ])
(const_int 1 [0x1])))
]) 259 {*lshrdi3_internal3} (nil)
(nil))
Which is wrong, see how we have DI mode here but we have SI mode before so now
we are shifting all
the way which is wrong.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-02-22 01:15:27
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
[Bug rtl-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
00:55 ---
Does this testcase fail for you if so can you run a regression hunter on it for
the real patch:
/* This function gets the wrong answer (63 instead of 31) when compiled
with "-m64 -O1" on powerpc64-linux. */
extern void abort (void);
/* From 176.gcc in SPEC CPU2000. */
int
exact_log2_wide (x)
register unsigned int x;
{
unsigned int x4;
register int log;
if (x == 0) goto L6; else goto L0;
L0:;
if (x != (x & -x)) goto L6; else goto L8;
L17:;
log = 0;
L3:;
log = log + 1;
x4 = x4 >> 1;
if (x4 != 0) goto L3; else goto L18;
L6:;
log = -1;
L18:;
return log;
L8:;
x4 = x >> 1;
if (x4 != 0) goto L17; else goto L19;
L19:;
log = 0;
goto L18;
}
int
main ()
{
if (exact_log2_wide ((int) -2147483648) != 31)
abort ();
return 0;
}
Please use -O1 -fno-tree-dominator-opts as we know this is the most optimial
code anyways.
--
What|Removed |Added
Component|tree-optimization |rtl-optimization
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
[Bug tree-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change
--- Additional Comments From janis at gcc dot gnu dot org 2005-02-22 00:54 --- I'm recovering from a cold and am fading fast, I'll get more information tomorrow. Another piece of information, though, is that the testcase works if the modified test in record_equality also includes "&& (loop_depth_of_name (y) != 0)". (That's meant to be a clue, not a fix.) -- What|Removed |Added Component|rtl-optimization|tree-optimization Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
[Bug rtl-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 00:48 --- This looks like a RTL bug, the 32bit and the 64 bit tree dumps are the same. -- What|Removed |Added Component|tree-optimization |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
[Bug tree-optimization/20134] [4.0 Regression] 176.gcc miscompare with -m64 after DOM change
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Summary|176.gcc miscompare with -m64|[4.0 Regression] 176.gcc |after DOM change|miscompare with -m64 after ||DOM change Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
[Bug c++/20133] [4.0 Regression] internal compiler error: in import_export_decl, at cp/decl2.c:1726
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
00:32 ---
This code is invalid, the correct way is to deal these static variables is like:
template
class ObjectPool {
static int mutex;
};
template<> int ObjectPool::mutex;
which does not ICE.
--
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20133
[Bug c++/20133] [4.0 Regression] internal compiler error: in import_export_decl, at cp/decl2.c:1726
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
00:30 ---
Confirmed reduced to:
template
class ObjectPool {
static int mutex;
};
template int ObjectPool::mutex;
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-02-22 00:30:53
date||
Summary|internal compiler error: in |[4.0 Regression] internal
|import_export_decl, at |compiler error: in
|cp/decl2.c:1726 |import_export_decl, at
||cp/decl2.c:1726
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20133
[Bug tree-optimization/20134] 176.gcc miscompare with -m64 after DOM change
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-22 00:19 --- Subject: Re: New: 176.gcc miscompare with -m64 after DOM change On Tue, 2005-02-22 at 00:12 +, janis at gcc dot gnu dot org wrote: > The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu > with "-m64 -O1" since this patch was added: > > > > 2004-10-23 Daniel Berlin <[EMAIL PROTECTED]> > > > > * tree-ssa-dom.c (record_equality): Use loop depth to determine > which way to record the equality as well. > (loop_depth_of_name): New function. > This can't be the real cause of the problem, however, it must just be exposing the latent bug. It just changes the direction we record the equality, so that we will use one variable instead of another. The code still believes both variables to be equal. In other words, there is something in record_equality that isn't correct, or some pass later on is now doing something wrong as a result. Can you print out the values of x, y, and prev_x we are passing to record_const_or_copy_1 in record_equality before and after the patch, for that function? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
Re: [Bug tree-optimization/20134] New: 176.gcc miscompare with -m64 after DOM change
On Tue, 2005-02-22 at 00:12 +, janis at gcc dot gnu dot org wrote: > The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu > with "-m64 -O1" since this patch was added: > > > > 2004-10-23 Daniel Berlin <[EMAIL PROTECTED]> > > > > * tree-ssa-dom.c (record_equality): Use loop depth to determine > which way to record the equality as well. > (loop_depth_of_name): New function. > This can't be the real cause of the problem, however, it must just be exposing the latent bug. It just changes the direction we record the equality, so that we will use one variable instead of another. The code still believes both variables to be equal. In other words, there is something in record_equality that isn't correct, or some pass later on is now doing something wrong as a result. Can you print out the values of x, y, and prev_x we are passing to record_const_or_copy_1 in record_equality before and after the patch, for that function?
[Bug tree-optimization/20134] 176.gcc miscompare with -m64 after DOM change
--- Additional Comments From janis at gcc dot gnu dot org 2005-02-22 00:13 --- Created an attachment (id=8249) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8249&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
[Bug tree-optimization/20134] New: 176.gcc miscompare with -m64 after DOM change
The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu with "-m64 -O1" since this patch was added: 2004-10-23 Daniel Berlin <[EMAIL PROTECTED]> * tree-ssa-dom.c (record_equality): Use loop depth to determine which way to record the equality as well. (loop_depth_of_name): New function. The failure goes away if the patch is reverted from mainline sources. The miscompare is due to function exact_log2_wide from toplev.c in 176.gcc, which returns 63 instead of 31 for the value -2147483648. I'll attach a testcase with that function. -- Summary: 176.gcc miscompare with -m64 after DOM change Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
[Bug tree-optimization/20132] Pessimization of induction variable and missed hoisting opportunity
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22 00:12 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-22 00:12:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20132
[Bug c++/20133] internal compiler error: in import_export_decl, at cp/decl2.c:1726
--- Additional Comments From jean-marc dot valin at usherbrooke dot ca 2005-02-22 00:10 --- Created an attachment (id=8248) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8248&action=view) Preprocessed source This is the preprocessed source for reproducing the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20133
[Bug c++/20133] New: internal compiler error: in import_export_decl, at cp/decl2.c:1726
I'm getting this ICE with the gcc-4.0-20050213 snapshot. This is a Debian (unstable) machine with a 2.6.10 kernel running on a Pentium M. % g++ -c net_types.cpp net_types.cc:179: internal compiler error: in import_export_decl, at cp/decl2.c:1726 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error: in import_export_decl, at cp/decl2.c:1726 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P1 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jean-marc dot valin at usherbrooke dot ca CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20133
[Bug tree-optimization/20132] New: Pessimization of induction variable and missed hoisting opportunity
Consider:
int
foo (int length, const char *fmt)
{
int i;
for (i = length; i >= 0; i--)
{
switch (fmt[i])
{
case 48:
break;
default:
return 1;
}
}
return 0;
}
I get:
foo (length, fmt)
{
unsigned int D.1180;
unsigned int ivtmp.5;
int D.1146;
:
if (length >= 0) goto ; else goto ;
:;
ivtmp.5 = 0;
:;
D.1180 = (unsigned int) length;
switch (*((const char *) ivtmp.5 + fmt + (const char *) D.1180))
{
case 48: goto ;
default : goto ;
}
:;
D.1146 = 1;
goto ();
:;
ivtmp.5 = ivtmp.5 - 1;
if (ivtmp.5 != D.1180 * 0 + 0) goto ; else goto ;
:;
D.1146 = 0;
:;
return D.1146;
}
The following should be hoisted out of the loop.
D.1180 = (unsigned int) length;
This
D.1180 * 0 + 0
should be folded to
~D.1180
and of course hoisted out of the loop.
The folding part is also mentioned in PR 20130.
RTL optimizers hoist ~D.1180 out of the loop.
Having said all this, the induction variable should be counting down toward 0.
That is, instead of
ivtmp.5 = 0;
:
:
switch (*((const char *) ivtmp.5 + fmt + (const char *) D.1180))
:
:
ivtmp.5 = ivtmp.5 - 1;
if (ivtmp.5 != D.1180 * 0 + 0) goto ; else goto ;
we should be doing
ivtmp.5 = (unsigned int) D.1180;
:
:
switch (*((const char *) ivtmp.5 + fmt))
:
:
ivtmp.5 = ivtmp.5 - 1;
if (ivtmp.5 >= 0) goto ; else goto ;
This way, we don't have to keep D.1180 in the loop.
And we can compare against 0 at the end.
--
Summary: Pessimization of induction variable and missed hoisting
opportunity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19721
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20132
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- What|Removed |Added BugsThisDependsOn||20132 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug c++/19076] Pointer to member function not matched to pointer to member template
--- Additional Comments From pcarlini at suse dot de 2005-02-21 23:50 --- Fixed for 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076
[Bug fortran/20131] New: gfortan - incorrectly reads beyond the end of line.
I finally realized that this is actually the source of most of the data reading problems that I have had. If you look at the hex dump of the file, the first line has extra padding blanks and reads correctly. The second line has no padding and gfortran reads past the end of line and takes data from the third line and prints it. [dir:~/tests/gfortran] dir% gfortran -o fread03 fread03.f [dir:~/tests/gfortran] dir% fread03 < fread03.dat 10 12 STOP 0 [dir:~/tests/gfortran] dir% cat fread03.f program main do 10 j=1,2 read(5,1010) nload,npr2 write(6,1010) nload,npr2 10 continue 1010 format (16i5) stop end [dir:~/tests/gfortran] dir% cat fread03.dat 1 1 2 [dir:~/tests/gfortran] dir% dump -i fread03.dat File name: fread03.dat Block number: 0 Byte number: 0 20 20 20 20 31 20 20 20 20 20 20 20 20 20 20 0a 1 . 0010 20 20 20 20 31 0a 20 20 20 20 32 0a 00 00 00 00 1. 2. EOF encountered. Do you want to continue ? n -- Summary: gfortan - incorrectly reads beyond the end of line. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-apple-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
[Bug c++/6628] cannot typedef const functions
--- Additional Comments From pcarlini at suse dot de 2005-02-21 23:39 --- Fixed for 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6628
[Bug tree-optimization/20130] Fold a * -1 - 1 into ~a;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 23:35 --- Confirmed. PR 15784 is the PR about -a - 1 turning into ~a. -- What|Removed |Added BugsThisDependsOn||15784 Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-21 23:35:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20130
[Bug tree-optimization/20130] Fold a * -1 - 1 into ~a;
-- What|Removed |Added OtherBugsDependingO||19986 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20130
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- What|Removed |Added BugsThisDependsOn||20130 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug tree-optimization/20130] New: Fold a * -1 - 1 into ~a;
Consider
int
foo (int a)
{
return a * -1 - 1;
}
CSE folds a * -1 into -a;
combine folds -a - 1 into ~a;
Obviously, we should do both of these in tree.
--
Summary: Fold a * -1 - 1 into ~a;
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19721
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20130
[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux
--- Additional Comments From wilson at specifixinc dot com 2005-02-21 23:19 --- Subject: Re: gcc.dg/transparent-union-* fail on ia64-hpux giovannibajo at libero dot it wrote: > --- Additional Comments From giovannibajo at libero dot it 2005-02-20 > 13:03 --- > Jim, these are transparent unions, I thought that they were passed using the > convention of the first element in the union. By the way, I probably wasn't clear about this, but I haven't made any attempt to debug or analyze the problem. I'm just trying to point people at the cause of the first error, which was obvious to me just from reading the bug report. And that is MEMBER_TYPE_FORCES_BLK. There may also be other problems here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20094
[Bug rtl-optimization/20129] ICE when compiling glibc-2.3.4/math/s_fmax.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 23:17 --- *** This bug has been marked as a duplicate of 15068 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20129
[Bug rtl-optimization/15068] ICE in elim_reg_cond
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 23:17 --- *** Bug 20129 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||molletts at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15068
[Bug rtl-optimization/20129] ICE when compiling glibc-2.3.4/math/s_fmax.c
-- What|Removed |Added Component|c |rtl-optimization Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20129
[Bug c++/19076] Pointer to member function not matched to pointer to member template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-21 23:12 --- Subject: Bug 19076 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-21 23:12:28 Modified files: gcc/cp : ChangeLog cp-tree.h decl.c decl2.c error.c pt.c tree.c typeck.c Log message: 2005-02-21 Douglas Gregor <[EMAIL PROTECTED]> PR c++/19076 PR c++/6628 * cp-tree.h (cp_apply_type_quals_to_decl): Declared. * decl.c (grokdeclarator): Pedwarn about qualifying a function type. Add qualifiers when declaring a typedef of a function type. Member function pointers pick up the qualifiers of the typedef used to declare them. Don't complain about creating cv-qualified function types. Complain about qualified function typedefs that are used to declare non-static member functions or free functions. Use cp_apply_type_quals_to_decl. (start_preparsed_function): Use cp_apply_type_quals_to_decl. (grokclassfn): Use cp_apply_type_quals_to_decl. * error.c (dump_type_suffix): Print qualifiers for function types. * pt.c (tsubst_decl): Use cp_apply_type_quals_to_decl. (tsubst): When substituting a function type into a member pointer type, pass along the qualifiers. (unify): Unify member pointers to member function pointers. * tree.c (cp_build_qualified_type_real): Function types may be qualified. This includes restrict qualifiers. * typeck.c (cp_apply_type_quals_to_decl): New function to replace use of c_apply_type_quals_to_decl. Drops qualifiers that are being added to function types. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4639&r2=1.4640 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1104&r2=1.1105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1366&r2=1.1367 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.767&r2=1.768 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&r1=1.275&r2=1.276 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.977&r2=1.978 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.426&r2=1.427 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.614&r2=1.615 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076
[Bug c++/6628] cannot typedef const functions
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-21 23:12 --- Subject: Bug 6628 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-21 23:12:28 Modified files: gcc/cp : ChangeLog cp-tree.h decl.c decl2.c error.c pt.c tree.c typeck.c Log message: 2005-02-21 Douglas Gregor <[EMAIL PROTECTED]> PR c++/19076 PR c++/6628 * cp-tree.h (cp_apply_type_quals_to_decl): Declared. * decl.c (grokdeclarator): Pedwarn about qualifying a function type. Add qualifiers when declaring a typedef of a function type. Member function pointers pick up the qualifiers of the typedef used to declare them. Don't complain about creating cv-qualified function types. Complain about qualified function typedefs that are used to declare non-static member functions or free functions. Use cp_apply_type_quals_to_decl. (start_preparsed_function): Use cp_apply_type_quals_to_decl. (grokclassfn): Use cp_apply_type_quals_to_decl. * error.c (dump_type_suffix): Print qualifiers for function types. * pt.c (tsubst_decl): Use cp_apply_type_quals_to_decl. (tsubst): When substituting a function type into a member pointer type, pass along the qualifiers. (unify): Unify member pointers to member function pointers. * tree.c (cp_build_qualified_type_real): Function types may be qualified. This includes restrict qualifiers. * typeck.c (cp_apply_type_quals_to_decl): New function to replace use of c_apply_type_quals_to_decl. Drops qualifiers that are being added to function types. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4639&r2=1.4640 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1104&r2=1.1105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1366&r2=1.1367 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.767&r2=1.768 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&r1=1.275&r2=1.276 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.977&r2=1.978 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.426&r2=1.427 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.614&r2=1.615 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6628
[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux
--- Additional Comments From wilson at specifixinc dot com 2005-02-21 23:11 --- Subject: Re: gcc.dg/transparent-union-* fail on ia64-hpux giovannibajo at libero dot it wrote: > --- Additional Comments From giovannibajo at libero dot it 2005-02-20 > 13:03 --- > Jim, these are transparent unions, I thought that they were passed using the > convention of the first element in the union. Yes, they are. And yes, MEMBER_TYPE_FORCES_BLK is causing the problem. Look at handle_transparent_union_attribute, and note the mode checks it is performing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20094
[Bug c/20129] New: ICE when compiling glibc-2.3.4/math/s_fmax.c
When cross-compiling glibc-2.3.4, gcc bails out with an ICE while attempting to compile math/s_fmax.c: arm-unknown-linux-gnu-gcc ../sysdeps/generic/s_fmax.c -c -std=gnu99 -Os -Wall -Winline -Wstrict-prototypes -Wwrite-strings -march=armv3 -pipe -g0 -O99 -fomit-frame-pointer -D__USE_STRING_INLINES -Wno-uninitialized -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE -D_Mlong_double_=double -I../include -I. -I/home/stephen/build/math -I.. -I../libio -I/home/stephen/build -I../sysdeps/arm/elf -I../linuxthreads/sysdeps/unix/sysv/linux/arm -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/arm -I../sysdeps/unix/sysv/linux/arm -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/arm/fpu -I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -DIS_IN_libm=1-o /home/stephen/build/math/s_fmax.o -MD -MP -MF /home/stephen/build/math/s_fmax.o.dt -MT /home/stephen/build/math/s_fmax.o ../sysdeps/generic/s_fmax.c: In function `__fmax': ../sysdeps/generic/s_fmax.c:28: internal compiler error: in elim_reg_cond, at flow.c:3257 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source (s_fmax.i) follows: # 1 "../sysdeps/generic/s_fmax.c" # 1 "" # 1 "" # 10 "" # 1 "./../include/libc-symbols.h" 1 # 56 "./../include/libc-symbols.h" # 1 "/home/stephen/build/config.h" 1 # 57 "./../include/libc-symbols.h" 2 # 874 "./../include/libc-symbols.h" # 1 "../sysdeps/wordsize-32/symbol-hacks.h" 1 # 875 "./../include/libc-symbols.h" 2 # 11 "" 2 # 1 "../sysdeps/generic/s_fmax.c" # 21 "../sysdeps/generic/s_fmax.c" # 1 "../include/math.h" 1 # 1 "../math/math.h" 1 # 27 "../math/math.h" # 1 "../include/features.h" 1 # 308 "../include/features.h" # 1 "../include/sys/cdefs.h" 1 # 1 "../misc/sys/cdefs.h" 1 # 4 "../include/sys/cdefs.h" 2 extern void __chk_fail (void) __attribute__ ((__noreturn__)); # 309 "../include/features.h" 2 # 331 "../include/features.h" # 1 "../include/gnu/stubs.h" 1 # 332 "../include/features.h" 2 # 28 "../math/math.h" 2 # 1 "../sysdeps/arm/bits/huge_val.h" 1 # 34 "../math/math.h" 2 # 1 "../sysdeps/ieee754/bits/huge_valf.h" 1 # 36 "../math/math.h" 2 # 1 "../sysdeps/generic/bits/huge_vall.h" 1 # 37 "../math/math.h" 2 # 1 "../sysdeps/ieee754/bits/inf.h" 1 # 40 "../math/math.h" 2 # 1 "../sysdeps/ieee754/bits/nan.h" 1 # 43 "../math/math.h" 2 # 1 "../sysdeps/arm/fpu/bits/mathdef.h" 1 # 27 "../sysdeps/arm/fpu/bits/mathdef.h" typedef float float_t; typedef double double_t; # 47 "../math/math.h" 2 # 70 "../math/math.h" # 1 "../include/bits/mathcalls.h" 1 # 1 "../math/bits/mathcalls.h" 1 # 53 "../math/bits/mathcalls.h" extern double acos (double __x) __attribute__ ((__nothrow__)); extern double __acos (double __x) __attribute__ ((__nothrow__)); extern double asin (double __x) __attribute__ ((__nothrow__)); extern double __asin (double __x) __attribute__ ((__nothrow__)); extern double atan (double __x) __attribute__ ((__nothrow__)); extern double __atan (double __x) __attribute__ ((__nothrow__)); extern double atan2 (double __y, double __x) __attribute__ ((__nothrow__)); extern double __atan2 (double __y, double __x) __attribute__ ((__nothrow__)); extern double cos (double __x) __attribute__ ((__nothrow__)); extern double __cos (double __x) __attribute__ ((__nothrow__)); extern double sin (double __x) __attribute__ ((__nothrow__)); extern double __sin (double __x) __attribute__ ((__nothrow__)); extern double tan (double __x) __attribute__ ((__nothrow__)); extern double __tan (double __x) __attribute__ ((__nothrow__)); extern double cosh (double __x) __attribute__ ((__nothrow__)); extern double __cosh (double __x) __attribute__ ((__nothrow__)); extern double sinh (double __x) __attribute__ ((__nothrow__)); extern double __sinh (double __x) __attribute__ ((__nothrow__)); extern double tanh (double __x) __attribute__ ((__nothrow__)); extern double __tanh (double __x) __attribute__ ((__nothrow__)); extern void sincos (double __x, double *__sinx, double *__cosx) __attribute__ ((__nothrow__)); extern void __sincos (double __x, double *__sinx, double *__cosx) __attribute__ ((__nothrow__)); extern double acosh (double __x) __attribute__ ((__nothrow__)); extern double __acosh (double __x) __attribute__ ((__nothrow__)); extern double asinh (double __x) __attribute__ (
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-21
23:00 ---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
jsm28 at gcc dot gnu dot org wrote:-
> * The greedy algorithm applies for lexing UCNs: for example,
> a\U000z is three preprocessing tokens {a}{\}{U000z} (and
> shouldn't get a diagnostic on lexing, presuming macros are defined
> such that the eventual token sequence is valid).
I'm not sure I agree with this: it would seem to be unnecessary
extra work; further I suspect the user would benefit from it being
pointed out he entered an ill-formed UCN rather than something random
from the front end complaining about an unexpected backslash.
The only case where you wouldn't get a syntax error from the
front end, or an invalid escape in a literal, is with -E. I'm
not sure lexing to the letter of the standard is worthwhile in
this case, as the standard doesn't discuss -E.
If you have an example where a compiled program is acceptable
with multiple lexing tokens then I would agree with you.
> * The spelling of UCNs is preserved for the # and ## operators.
This is very hard with CPP's current implementation - it assumes
it can deduce the spelling of an identifier from its hash table
entry. IMO the proper way to fix this to use a different approach
entirely, rather than kludge it in the existing implementation
(which would bloat some common datastructures) but that's some work.
> * I think the only reasonable interpretation of the lexing rules in
> the context of forbidden characters is that first identifiers are
> lexed (allowing any UCNs) then bad characters yield an error (rather
> than stopping the identifier before the bad character and treating it
> as not a UCN).
Agreed - as I say above I don't see why this shouldn't apply for
partial UCNs too, even with -E.
The rest seems reasonable.
Neil.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug other/20128] ice with mudflap + profile generate
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 22:33 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-02-21 22:33:12 date|| Summary|ice on valid code / mudflap |ice with mudflap + profile |+ profile generate |generate http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20128
[Bug other/20128] New: ice on valid code / mudflap + profile generate
# cat tmp.c
int main() { }
# LANG=C gcc -std=gnu9x -O2 -fmudflap -c -lmudflap -fprofile-generate tmp.c
tmp.c: In function '_GLOBAL__I_1_main':
tmp.c:1: internal compiler error: Segmentation fault
# gcc -v
Reading specs from /usr/lib/gcc/i686-pld-linux/4.0.0/specs
Target: i686-pld-linux
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-languages=c,c++,ada --enable-c99 --enable-long-long
--disable-multilib --enable-nls --with-gnu-as --with-gnu-ld
--with-demangler-in-ld --with-system-zlib --with-slibdir=/lib --without-x
--enable-cmath i686-pld-linux
Thread model: posix
gcc version 4.0.0 20050220 (experimental) (PLD Linux)
--
Summary: ice on valid code / mudflap + profile generate
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pld-linux
GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20128
[Bug tree-optimization/20127] wrong code for volatile struct members?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 22:19 --- Hmm, SRA creates new variables and then goes and makes them renamed which seems wrong. -- What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed||1 GCC build triplet|ppc-apple-darwin7.8 | GCC host triplet|ppc-apple-darwin7.8 | GCC target triplet|avr-unknown-unknown | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-02-21 22:19:24 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20127
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21
22:15 ---
Reduced testcase (and shows that this is also a 3.3/3.4/4.0 Regression too):
#include
#include
#include
typedef struct {
struct _object *_ob_next;
struct _object *_ob_prev;
int ob_refcnt;
struct _typeobject *ob_type;
int ob_size;
long ob_shash;
int ob_sstate;
char ob_sval[1];
} strobject;
static int
string_contains(strobject *a, strobject *el)
{
const char *lhs, *rhs, *end;
int size;
size = (((el))->ob_size);
rhs = (((el))->ob_sval);
lhs = (((a))->ob_sval);
if (size == 1)
return memchr(lhs, *rhs, (((a))->ob_size)) != ((void *)0);
end = lhs + a))->ob_size) - size);
while (lhs <= end) {
const char *t = lhs+1;
if (memcmp(lhs, rhs, size) == 0)
return 1;
lhs = t;
}
return 0;
}
int
main(void)
{
char* s1 = "aa";
char* s2 = "aa";
strobject *obj1;
strobject *obj2;
obj1 = calloc(1, sizeof (*obj1) + 64);
obj2 = calloc(1, sizeof (*obj2) + 64);
obj1->ob_size = strlen(s1);
obj2->ob_size = strlen(s2);
memcpy(&obj1->ob_sval[0], s1, obj1->ob_size);
memcpy(&obj2->ob_sval[0], s2, obj2->ob_size);
printf("'%*s' in '%*s' = %d\n",
obj2->ob_size, obj2->ob_sval,
obj1->ob_size, obj1->ob_sval,
string_contains(obj1, obj2));
return 0;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||3.3.3 3.4.0 4.0.0
Known to work||3.2.3
Last reconfirmed|-00-00 00:00:00 |2005-02-21 22:15:27
date||
Summary|Inlined memcmp makes one|[3.3/3.4/4.0 Regression]
|argument null on entry |Inlined memcmp makes one
||argument null on entry
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c/20127] New: wrong code for volatile struct members?
The following code does not treat volatile struct members as volatile,
assuming such declarations are valid; if not would exect a warning:
typedef struct {
volatile int a;
volatile int b;
} s;
int main (void){
s x = {0, 1};
s y = {2, 3};
x = y;
y = x;
return x.a + y.a;
}
generates:
00c6 :
volatile int a;
volatile int b;
} s;
int main (void){
c6: cf ef ldi r28, 0xFF ; 255
c8: d0 e1 ldi r29, 0x10 ; 16
ca: de bf out 0x3e, r29 ; 62
cc: cd bf out 0x3d, r28 ; 61
s x = {0, 1};
s y = {2, 3};
x = y;
y = x;
return x.a + y.a;
}
ce: 84 e0 ldi r24, 0x04 ; 4
d0: 90 e0 ldi r25, 0x00 ; 0
d2: 0c 94 6b 00 jmp 0xd6 <_exit>
--
Summary: wrong code for volatile struct members?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ppc-apple-darwin7.8
GCC host triplet: ppc-apple-darwin7.8
GCC target triplet: avr-unknown-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20127
[Bug target/20126] Inlined memcmp makes one argument null on entry
-- What|Removed |Added Attachment #8247|text/plain |application/octet-stream mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] Inlined memcmp makes one argument null on entry
-- What|Removed |Added Attachment #8246|text/plain |application/octet-stream mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] Inlined memcmp makes one argument null on entry
--- Additional Comments From jkohen at users dot sourceforge dot net 2005-02-21 21:48 --- Created an attachment (id=8247) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8247&action=view) A slightly modified version that does work. I'm sorry if it's irrelevant, but here's a slightly different version that works correctly. I was trying to make the fragment small by removing some duplicate code, but that change makes it work. You can diff this against ptest.i and see the few differences pretty clearly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] Inlined memcmp makes one argument null on entry
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c/20126] Inlined memcmp makes one argument null on entry
--- Additional Comments From jkohen at users dot sourceforge dot net 2005-02-21 21:47 --- Created an attachment (id=8246) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8246&action=view) The program that causes the failure I use Python's data structures, that's the explanation for the weird structures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c/20126] New: Inlined memcmp makes one argument null on entry
Hi, I found out a compiler bug triggered by compiling Python 2.3 with GCC 4.0 "pre5." I've been able to track it down to a small fragment which I'll attach below. The bug is a regression as GCC 3.4.4 20050203 produces a working application. This is the compiler's output and compilation command-line: Using built-in specs. Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada --prefix=/usr --libexecdir=/usr/lib --enable-shared --with-system-zlib --enable-nls --enable-threads=posix --without-included-gettext --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-mpfr x86_64-linux Thread model: posix gcc version 4.0.0 20050125 (experimental) (Debian 4.0-0pre5.0.0.1.gcc4) /usr/lib/gcc/x86_64-linux/4.0.0/cc1 -E -quiet -v ptest.c -mtune=k8 -Wall -Wstrict-prototypes -O3 -fpch-preprocess -o ptest.i ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux/4.0.0/../../../../x86_64-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/x86_64-linux/4.0.0/include /usr/include End of search list. /usr/lib/gcc/x86_64-linux/4.0.0/cc1 -fpreprocessed ptest.i -quiet -dumpbase ptest.c -mtune=k8 -auxbase ptest -O3 -Wall -Wstrict-prototypes -version -o ptest.s GNU C version 4.0.0 20050125 (experimental) (Debian 4.0-0pre5.0.0.1.gcc4) (x86_64-linux) compiled by GNU C version 4.0.0 20050125 (experimental) (Debian 4.0-0pre5.0.0.1.gcc4). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy --64 -o ptest.o ptest.s GNU ensamblador versión 2.15 (x86_64-linux) utilizando BFD versión 2.15 /usr/lib/gcc/x86_64-linux/4.0.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib/ld-linux-x86-64.so.2 -o ptest /usr/lib/gcc/x86_64-linux/4.0.0/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-linux/4.0.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-linux/4.0.0/crtbegin.o -L/usr/lib/gcc/x86_64-linux/4.0.0 -L/usr/lib/gcc/x86_64-linux/4.0.0 -L/usr/lib/gcc/x86_64-linux/4.0.0/../../../../lib64 -L/usr/lib/gcc/x86_64-linux/4.0.0/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 ptest.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux/4.0.0/crtend.o /usr/lib/gcc/x86_64-linux/4.0.0/../../../../lib64/crtn.o In case the information is ambiguous, the compiler is a 64-bit binary generating 64-bit binaries. Please check http://lists.debian.org/debian-amd64/2005/02/msg00505.html for some comments I wrote on the relevant assembly output. -- Summary: Inlined memcmp makes one argument null on entry Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkohen at users dot sourceforge dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug libfortran/20108] incorrect run time error on formatted read
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:44 --- Confirmed with the reduced testcase, G77 does the correct thing also. -- What|Removed |Added OtherBugsDependingO||19292 nThis|| Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:44:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20108
[Bug libfortran/19302] intrinsic_nearest.f90 fails
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-21 21:42 --- Patch installed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19302
[Bug c++/20098] [4.0 Regression] Missed optimization with static const and templates
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:40 --- It was broken sinece at least 20050201. It worked with 20050113. Confirmed, a missed optimization regression. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Priority|P2 |P3 Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:40:51 date|| Summary|Unresolved dependent "static|[4.0 Regression] Missed |const" symbol in template |optimization with static ||const and templates Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20098
[Bug libfortran/19302] intrinsic_nearest.f90 fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-21 21:39 --- Subject: Bug 19302 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-21 21:39:33 Modified files: libgfortran: ChangeLog libgfortran/intrinsics: c99_functions.c Log message: PR libfortran/19302 * intrinsics/c99_functions.c (nextafterf): Special-case infinite numbers. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.160&r2=1.161 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/c99_functions.c.diff?cvsroot=gcc&r1=1.9&r2=1.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19302
[Bug rtl-optimization/20117] [4.0 Regression] duplicated labels in PIC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:38 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|target |rtl-optimization Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:38:06 date|| Summary|[4.0.0 Regression] |[4.0 Regression] duplicated |duplicated labels in PIC|labels in PIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20117
[Bug libfortran/20092] gfortran not correctly padding keyboard or text file input
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:36 --- Confirmed. -- What|Removed |Added OtherBugsDependingO||19292 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:36:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20092
[Bug c++/20028] [3.4 Regression] class and then template class gives an ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:34 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20028
[Bug libfortran/20074] reshape of pointer array segfaults at runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:32 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:32:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20074
[Bug middle-end/20111] real_nan and non-ASCII character sets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:29 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid, rejects- ||valid Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:29:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20111
[Bug c/20110] format checking and non-ASCII character sets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:28 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:28:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20110
[Bug middle-end/20109] printf optimizations and non-ASCII character sets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:28 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-21 21:28:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20109
[Bug c++/20028] [3.4 Regression] class and then template class gives an ICE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-21 21:11 --- Subject: Bug 20028 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-21 21:11:51 Modified files: gcc/cp : ChangeLog class.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: crash34.C Log message: gcc/cp/ChangeLog: PR c++/20028 * class.c (finish_struct): Initialize TYPE_SIZE_UNIT of a template along with TYPE_SIZE. gcc/testsuite/ChangeLog: PR c++/20028 * g++.dg/template/crash34.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.200&r2=1.3892.2.201 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.595.4.9&r2=1.595.4.10 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.363&r2=1.3389.2.364 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/crash34.C.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=20028
[Bug c++/14500] most specialized function template vs. non-template function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 21:08 --- Any news on this? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-04-04 03:00:26 |2005-02-21 21:08:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14500
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From zack at codesourcery dot com 2005-02-21 20:54 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) "geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes: >>> The second half would a pp-number, instead. It is always true that >>> splitting an identifier between characters yields two valid >>> preprocessing tokens. >> >> Joseph has mostly explained this, but I should add that what you get >> if you split, say, "a\u0660b", between the "a" and the backslash is >> two identifiers, the second of which's "initial character is a >> universal character name designating a digit", which violates a >> shall-clause in a semantics paragraph, and therefore provokes >> undefined behavior. (C99 6.4.2.1p3.) > > A shall-clause in a semantics paragraph requires a diagnostic, C99 > 5.1.1.3. Um, no, 5.1.1.3 does not say that. It says a diagnostic is required for a violation of any "syntax rule or constraint"; shall-clauses in semantics paragraphs are neither. Constraints only appear in constraints paragraphs. See 4p2 for the meaning of shall-clauses outside constraints paragraphs. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
Re: Possible C compiler bug
On Feb 21, 2005, at 3:28 PM, Bob Green wrote: I get a segmentation fault when a C program allocates an 8MB array in the subroutine "main()". The specifics are listed below. Any help understanding if this is a bug would be greatly appreciated. No this is not a bug, you are allocating the 8MB on the stack. The stack size on ppc-darwin before 7 is only 512K though the stacksize on ppc-darwin after 7 is 8M, you will still not be able to run the program as there is overhead. You need to either change the stack size limit or allocate it on the heap. -- Pinski
Possible C compiler bug
I get a segmentation fault when a C program allocates
an 8MB array in the subroutine "main()". The
specifics are listed below. Any help understanding
if this is a bug would be greatly appreciated.
Thanks,
Bob
gcc version
===
gcc -v produces:
Reading specs from
/usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1256, based on gcc
version 3.1 20021003 (prerelease)
input file
==
input file called debug.c contains:
main()
{
float a[2048][1024];
}
compiler options
no compiler options were given (command was: gcc
debug.c)
.i file
===
compiling with the -save-temps flag produces the
following .i file:
# 1 "debug.c"
main ( )
{
float a [ 2048 ] [ 1024 ] ;
}
machine and OS
==
Apple PowerBook G4 running Mac OS X Version 10.3.8
Build 7U16
compiler cofiguration
=
used default configuration for Apple Developer's Kit
incorrect output
running a.out produces the following error:
Segmentation fault
__
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From zack at codesourcery dot com 2005-02-21 20:23 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) "geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes: >>> The second half would a pp-number, instead. It is always true that >>> splitting an identifier between characters yields two valid >>> preprocessing tokens. >> >> It would not be a pp-number, as a UCN for a digit is still an >> identifier-nondigit rather than a digit in terms of the syntax and >> pp-numbers can't start with identifiers-nondigits. > > That's a defect in the standard, the tail of an identifier is supposed > to be either an identifier or a pp-number, that's why pp-number exists. Arguably yes. *shrug* You perhaps begin to see why I did not want this feature implemented? Or at least why I want it done with great caution and consideration of all these corner cases? Does your opinion of this particular corner case change in view of C++ not permitting most of the "digit" UCNs in identifiers at all? zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From zack at codesourcery dot com 2005-02-21 20:14 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) "geoffk at geoffk dot org" <[EMAIL PROTECTED]> writes: > Although I agree that these are all (except the below) nice things to > have, I don't think I agree that they are all preconditions to having > any part of an implementation. For instance, an implementation that > said sorry() when using # on an identifier from a UCN would still be > more useful than the complete lack of implementation we have now. In my book, a complete lack of implementation of this particular feature is better than an incomplete one. This is because I see the vast majority of the work required to do a complete implementation as being due-diligence tasks needed to ensure that the feature cannot crash the compiler, cause wrong code generation, or introduce compatibility problems, and as long as someone is going to do all that work, why shouldn't they do the rest of the job as long as they're in there? > The second half would a pp-number, instead. It is always true that > splitting an identifier between characters yields two valid > preprocessing tokens. Joseph has mostly explained this, but I should add that what you get if you split, say, "a\u0660b", between the "a" and the backslash is two identifiers, the second of which's "initial character is a universal character name designating a digit", which violates a shall-clause in a semantics paragraph, and therefore provokes undefined behavior. (C99 6.4.2.1p3.) Standing policy is that all cases which provoke undefined behavior inside the preprocessor, except already-documented GNU extensions, shall produce hard errors. I am tempted to make a partial exception in this case in the interest of better compatibility with C++. Almost all of the UCNs in the "digits" block of C99 annex D are completely excluded from C++98 annex E - so "a\u0660b" for instance is an invalid identifier, and we never get as far as wondering what happens if we split it before the backslash. However, the range 0e50-0e59 is in the "Thai" range of C++98/E, but *both* the "Thai" and the "Digits" ranges of C99/D. It would be sensible, IMO, to resolve the error in C99/D by removing 0e50-0e59 from the "Digits" range, thus permitting those characters to begin identifiers in both C and C++. [Note that currently ucnid.tab takes the opposite position.] zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug libfortran/20125] gfortran - backspace on binary files errors
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 19:49 --- Note backspace does work in some testcases but how many and what the situation I don't know right. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20125
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From joseph at codesourcery dot com 2005-02-21 19:47 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) On Mon, 21 Feb 2005, geoffk at geoffk dot org wrote: > > * These rules apply to identifiers as preprocessing tokens at any > > time, including before concatenation. So it is not the case in C99 > > that splitting an identifier anywhere yields two valid preprocessing > > tokens: the second half could begin with a UCN for a digit and not be > > a valid identifier. (Invalid identifiers in C99 don't require > > diagnostics, but I don't think we want to use this laxity.) > > The second half would a pp-number, instead. It is always true that > splitting an identifier between characters yields two valid > preprocessing tokens. It would not be a pp-number, as a UCN for a digit is still an identifier-nondigit rather than a digit in terms of the syntax and pp-numbers can't start with identifiers-nondigits. > > * All uses of identifiers and DECL_ASSEMBLER_NAME in the compiler > > should be audited to determine what sort of identifier is appropriate > > in each case. > > I don't understand this sentence. What different sorts of identifiers > are there, and how could they be appropriate or not appropriate? Identifiers found in input, with input spelling. (Input includes -D and -U options on the command line - in principle the command line should be interpreted in the user's locale by default just like source files.) UTF-8 (or, I suppose, UTF-EBCDIC) internally encoded identifiers. Identifiers in mangled form in any case where they are mangled for output. Identifiers in diagnostics (possibly including cases where bits of a diagnostic get built up with sprintf), which need converting to the user's locale for display or to be displayed using UCNs. I don't know if collect2 might also need to know something about extended identifiers. The aim is that every datastructure with an identifier should have the encoding (input, internal, output, diagnostic) well-defined and conversions between these should be handled properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug c++/20123] mangled name of typeid doesn't encode cv-qualifer.
--- Additional Comments From yanliu at ca dot ibm dot com 2005-02-21 19:37 --- For function parameters, the cv-qualifers should not be mangled. I suspect GCC treates this typeid as a function, thus ignoring the encoding of cv-qualifers. At least, the C++ ABI is not clear in this aspect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20123
[Bug libfortran/20125] gfortran - backspace on binary files errors
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-21 19:36 --- Confirmed. -- What|Removed |Added OtherBugsDependingO||19292 nThis|| Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-21 19:36:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20125
