[Bug c++/28169] Tertiary operator: object creation and initialization
--- Comment #4 from joseph dot rajesh at gmail dot com 2006-06-27 07:38 --- The intel compiler version 9.1 gave me the following output Base ctor... Derived ctor... Base COPTY ctor... Base COPTY ctor... ~Base called... ~Derived called... ~Base called... Base show called... ~Base called... Thats even stranger!! Compiler User : Intel(R) C++ Compiler for 32-bit applications, Version 9.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28169
[Bug ada/27225] Wide_String slice assignment in nested procedure does not work properly
--- Comment #4 from bauhaus at futureapps dot de 2006-06-27 08:00 --- Works now, using gcc version 4.1.2 20060626 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27225
[Bug testsuite/26614] make check fails during fixincludes testing.
--- Comment #3 from bauhaus at futureapps dot de 2006-06-27 09:18 --- Same here, Fixed: X11/Xmu.h Fixed: Xm/BaseClassI.h Fixed: Xm/Traversal.h Newly fixed header: ia64/sys/getppdp.h There were fixinclude test FAILURES make[2]: *** [check] Error 1 The generated file ./fixincludes/tests/LIST is missing the entry ia64/sys/getppdp.h FWIW, build/fixincludes/tests/inc$ find * -type f |wc -l 88 build/fixincludes/tests/inc$ wc -l ../LIST 82 ../LIST build/fixincludes/tests/res$ find * -type f |wc -l 83 Linux sonnenregen 2.6.12-10-686-smp #1 SMP Mon Jun 12 22:21:12 UTC 2006 i686 GNU/Linux 2x PIII, Ubuntu 5.10 Target: i686-pc-linux-gnu Configured with: ../src/gcc/configure --prefix=/opt/GCC/41x --disable-nls --enable-languages=ada,c,c++,fortran --enable-threads=posix Thread model: posix gcc version 4.1.2 20060626 (prerelease) -- bauhaus at futureapps dot de changed: What|Removed |Added CC||bauhaus at futureapps dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26614
[Bug middle-end/24929] long long shift/mask operations should be better optimized
--- Comment #5 from uros at kss-loka dot si 2006-06-27 10:12 --- (In reply to comment #4) > which may be optimal. movzbl 18(%esp), %eax could be used in this particular case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24929
[Bug ada/28171] ACATS: cd5003h intermitent fail
--- Comment #3 from charlet at gcc dot gnu dot org 2006-06-27 13:02 --- Closing this PR, as this is likely a linux kernel or sh bug, in any case, not a GCC bug. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28171
[Bug libgcj/28178] New: jniEnv->DeleteLocalRef (null) fails
According to Sun documentation NULL is a allowed to call DeleteLocalRef() with a NULL argument. The GCJ jni implementation exits (Aborted) in this case. From: http://java.sun.com/docs/books/jni/html/exceptions.html 6.1.2 A Utility Function Passing NULL to DeleteLocalRef is a no-op, which is an appropriate action if FindClass fails and returns NULL. -- Summary: jniEnv->DeleteLocalRef (null) fails Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hakan dot hjort at gmail dot com GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28178
[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-06-27 14:17 --- I believe that a frontend problem is involved, even if it is only part of the story. This exhibits the same symptoms as Harald's testcase: call foo ( (/( 'a',i=1,2 )/) ) end but this works fine: call foo ( (/'a', 'b'/) ) end Both expand the constructor just fine. However the second makes just one call to resolve_expr and leaves with a value for the string length. The first calls resolve_expr twice and has lost the string length between the first and second calls. I am blowed if I can see where this happens for the moment but I am looking furiously! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28167
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #23 from whaley at cs dot utsa dot edu 2006-06-27 14:20 --- Uros, OK, I made the stupid assumption that the P4 would behave like the P4e, should've known better :) I got access to a Pentium 4 (family=15, model=2), and indeed I can repeat the several surprising things you report: (1) SSE does as well as x87 on this platform (2) The difference between gcc 3 & 4 x87 performance extremely minor (3) The code is amazingly optimal (roughly 95-96% of peak!) The significance of (3) is that it tells us we are not in the bad case where the kernel in question gets such crappy performance that all codes look alike. This performance was so good, that I ran a tester to verify that we were still getting the right answer, and indeed we are :) On this platform, I didn't install the compilers myself, (system had Red Hat 4.0.2-8 and 3.3.6 installed), so I scoped the assembly, and indeed they have the fmul difference that causes problems on the other x87 machines, so it is really true that the Pentium 4 handles either instruction stream almost as well (not sure the 2% is significant; 2% is less than clock resolution, though in my timings anytime there is a difference, gcc 4 always loses). Here is the machine breakdown as measured now: LIKES GCC 4DOESN'T CARELIKES GCC 3 ====== CoreDuoPentium 4 PentiumPRO Pentium III Pentium 4e Pentium D Athlon-64 X2 Opteron The only machine we are missing that I can think of is the K7 (i.e. original Athlon, not Athlon-64). I don't presently have access to a K7, but I can probably find someone on the developer list who could run the test if you like. The other thing that would be of interest is for each machine to chart the % performance lost/gained. Here, though, we want two numbers: % lost on simple benchmark code (which is easy to repeat), and % lost with ATLAS code generator (which compares each compiler's best case out of thousands to each other). I will undertake to get this first (quick to run) number for the machines so we have some quantitative results to look at . . . The ATLAS comparison is probably more important, but takes so long that maybe I'll post it only for the most problematic platforms (i.e., if the arch shows a big drop gcc3 v. gcc4, see if the drop is that big when we ask ATLAS to auto-adapt to gcc4). Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug libgcj/28178] jniEnv->DeleteLocalRef (null) fails
--- Comment #1 from hakan dot hjort at gmail dot com 2006-06-27 14:37 --- Created an attachment (id=11760) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11760&action=view) Testcase FindClass on bad class + DeleteLocalRef Build as gcc delete_null.c -lgcj Should have exit status 0 and print "OK: exception pending". I've tested it successfully using the Sun JVM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28178
[Bug c++/28179] New: No diag for dflt arg on out-of-line tmpl member func def
t.C:
template
struct S {
void dump(char *);
};
template
void S::dump(char *m = 0) {}
void foo() { S<0> s; }
>From the standard:
8.3.6 paragraph 6:
... "Default arguments for a member function of a class template
shall be specified on the initial declaration of the member function within the
class template."
This error is not diagnosed in any version of g++ that I've tried. I request
that g++ implement this diagnostic to help users write standard compliant code.
--
Summary: No diag for dflt arg on out-of-line tmpl member func def
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cbowler at ca dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28179
[Bug c++/28179] No diag for dflt arg on out-of-line tmpl member func def
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-27 14:47 --- *** This bug has been marked as a duplicate of 15339 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28179
[Bug c++/15339] [DR217] Adding default arguments to function templates in redeclartions should be forbidden
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-06-27 14:47 --- *** Bug 28179 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||cbowler at ca dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339
[Bug c/28180] New: TREE_CODE usage error
When I walk through the Basic Blocks, I have the following statement
//this piece of code causes errors
if (TREE_CODE (stmt) == CALL_EXPR){
if ( (TREE_CODE (TREE_OPERAND (TREE_OPERAND (stmt, 0), 0)))
==FUNCTION_DECL)
fprintf(stderr,"Here\n");
}
it gives me the following errors:
/bin/sh ../../gcc-4.1.1/gcc/../move-if-change tmp-macro_list macro_list
macro_list is unchanged
echo timestamp > s-macro_list
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/./gcc/xgcc
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/./gcc/
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/bin/
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/lib/
-isystem
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/include
-isystem
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/sys-include
-O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I.
-I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include
-I../../gcc-4.1.1/gcc/../libcpp/include
-I/export/home/a/yang22/obj-gmp4.2.1/include
-I/export/home/a/yang22/obj-mpfr2.2.0/include -g0 -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-unit-at-a-time -fno-omit-frame-pointer \
-c ../../gcc-4.1.1/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/./gcc/xgcc
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/./gcc/
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/bin/
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/lib/
-isystem
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/include
-isystem
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/sys-include
-O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I.
-I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include
-I../../gcc-4.1.1/gcc/../libcpp/include
-I/export/home/a/yang22/obj-gmp4.2.1/include
-I/export/home/a/yang22/obj-mpfr2.2.0/include -g0 -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-unit-at-a-time -fno-omit-frame-pointer -fPIC \
-c ../../gcc-4.1.1/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFS_O \
-o crtbeginS.o
here
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/./gcc/xgcc
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/./gcc/
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/bin/
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/lib/
-isystem
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/include
-isystem
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/sys-include
-O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I.
-I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include
-I../../gcc-4.1.1/gcc/../libcpp/include
-I/export/home/a/yang22/obj-gmp4.2.1/include
-I/export/home/a/yang22/obj-mpfr2.2.0/include -g0 -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-unit-at-a-time -fno-omit-frame-pointer \
-c ../../gcc-4.1.1/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O \
-o crtbeginT.o
here
here
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/./gcc/xgcc
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/./gcc/
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/bin/
-B/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/lib/
-isystem
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/include
-isystem
/export/home/a/yang22/modifiedgcc411/objgcc4.1.1_withf95/i686-pc-linux-gnu/sys-include
-O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I.
-I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include
-I../../gcc-4.1.1/gcc/../libcpp/include
-I/export/home/a/yang22/obj-gmp4.2.1/include
-I/export/home/a/yang22/obj-mpfr2.2.0/include -g0 -finhibit-size-directive
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss
-fno-unit-at-a-time -fno-omit-frame-pointer \
-c ../../gcc-4.1.1/gcc/crtstuff.c -DCRT_END \
-o crtend.o
../../gcc-4.1.1/gcc/crtstuff.c: In function __do_global_ctors_aux:
../../gcc-4.1.1/gcc/crtstuff.c:515: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://
[Bug c/28180] TREE_CODE usage error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-27 15:02 --- CALL_EXPR is also used for direct and indirect calls. Also this bug data base is not for helping with new old of GCC, just current code in GCC that crashes. You should try to debug what is going wrong. I think you forgot about indirect calls ( I mention this because that is what is in crtstuff.c). -- 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=28180
[Bug libgcj/28178] jniEnv->DeleteLocalRef (null) fails
-- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-27 15:16:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28178
[Bug java/28149] Fail to test GCC on simulation due to libjava build errors.
--- Comment #2 from tromey at gcc dot gnu dot org 2006-06-27 15:30 --- The mprec part of this patch looks fine to me. This should go in Classpath as well as libgcj. The timezone part of this patch looks odd. I would expect that we would need another case in there for "__timezone" -- both a configure check and another #if. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-27 15:30:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28149
[Bug libgcj/28178] jniEnv->DeleteLocalRef (null) fails
--- Comment #2 from tromey at gcc dot gnu dot org 2006-06-27 15:33 --- Subject: Bug 28178 Author: tromey Date: Tue Jun 27 15:33:24 2006 New Revision: 115034 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115034 Log: PR libgcj/28178: * jni.cc (_Jv_JNI_DeleteLocalRef): Ignore null argument. (_Jv_JNI_DeleteGlobalRef): Likewise. * testsuite/libjava.jni/PR28178.java: New file. * testsuite/libjava.jni/PR28178.c: New file. * testsuite/libjava.jni/PR28178.out: New file. Added: trunk/libjava/testsuite/libjava.jni/PR28178.c trunk/libjava/testsuite/libjava.jni/PR28178.java trunk/libjava/testsuite/libjava.jni/PR28178.out Modified: trunk/libjava/ChangeLog trunk/libjava/jni.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28178
[Bug libgcj/28178] jniEnv->DeleteLocalRef (null) fails
--- Comment #3 from tromey at gcc dot gnu dot org 2006-06-27 15:42 --- Subject: Bug 28178 Author: tromey Date: Tue Jun 27 15:42:22 2006 New Revision: 115035 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115035 Log: PR libgcj/28178: * jni.cc (_Jv_JNI_DeleteLocalRef): Ignore null argument. (_Jv_JNI_DeleteGlobalRef): Likewise. * testsuite/libjava.jni/PR28178.java: New file. * testsuite/libjava.jni/PR28178.c: New file. * testsuite/libjava.jni/PR28178.out: New file. Added: branches/gcc-4_1-branch/libjava/testsuite/libjava.jni/PR28178.c - copied unchanged from r115034, trunk/libjava/testsuite/libjava.jni/PR28178.c branches/gcc-4_1-branch/libjava/testsuite/libjava.jni/PR28178.java - copied unchanged from r115034, trunk/libjava/testsuite/libjava.jni/PR28178.java branches/gcc-4_1-branch/libjava/testsuite/libjava.jni/PR28178.out - copied unchanged from r115034, trunk/libjava/testsuite/libjava.jni/PR28178.out Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/jni.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28178
[Bug libgcj/28178] jniEnv->DeleteLocalRef (null) fails
--- Comment #4 from tromey at gcc dot gnu dot org 2006-06-27 15:46 --- I fixed this on the 4.1 branch and the trunk. I'm not planning to backport to the 4.0 branch, but I would approve it if someone wanted to. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28178
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #24 from whaley at cs dot utsa dot edu 2006-06-27 16:44 --- Guys, OK, here is a table summarizing the performance you can see using the mmbench4s.tar.gz. I believe this covers a strong majority of the x86 architectures in use today (there are some specialty processors such as the Pentium-M, Turion, Efficeon, etc. missing, but I don't think they are a big % of the market). In this table, I report the following for each machine and data precision: % Clock: % of clock rate achieved by best compiled version of gemm_atlas.c (rated in mflop). Note, theoretical peak for intel machines is 1 flop/clock, and is 2 flops/clock for AMD, which would correspond to 100% and 200% respectively. gcc4/3 : (gcc 4 x87 performance) / (gcc 3 x87 performance) so < 1 indicates slowdown, > 1 indicates speedup NOTES: (1) Pentium 4 is a model=2, while Pentium 4E is model=3. (2) PPRO, PIII & P4e get bad % clock for double: this is because the static blocking factor in the benchmark (nb=60) exceeds the cache, which makes the gcc 4 #s look better than they are. (3) In general, the % peak achieved by this kernel is large enough that I think it is truly indicative of the computational efficiency of the generated code. double single -- --- MACHINES%CLOCK gcc4/3 %CLOCK gcc4/3 === == == == == PentiumPRO67.50.77 78.50.71 PentiumIII47.60.95 81.40.69 Pentium 4 93.80.92 95.71.00 Pentium4e 72.80.75 80.40.80 Pentium-D 86.70.83 94.10.91 CoreDuo 85.81.01 94.91.11 Athlon-K7137.80.62 139.10.63 Athlon-64 X2 160.00.58 165.50.60 Opteron 164.60.57 164.60.61 The CoreDue numbers above are generated by me on a OS X machine, where I hand-translated Linux assembly to run, since I could not compile stock gccs. I have a request out for results from a guy who has Linux/CoreDue, and when I get those I will update the results if necessary. At that time, I will also post an attachment with all the raw timing runs that I generated the table from. Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug fortran/28174] Corruption of multiple character arrays when passing array sections
--- Comment #2 from pault at gcc dot gnu dot org 2006-06-27 17:47 --- As I said to you in my email, this represents a new problem, which is exposed by the previous fix. I should have noticed that this was happening but, at least it doesn't segfault any more! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28174
[Bug target/25765] gfortran.dg/assign_2.f90 -O0 fails
--- Comment #4 from langton at gcc dot gnu dot org 2006-06-27 20:13 --- The rs6000 patch (attached) does appear to work, at least on assign_2.f90. I'll do a full bootstrap and regression-test, then submit the fix. -- langton at gcc dot gnu dot org changed: What|Removed |Added CC||langton at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |langton at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25765
[Bug target/28181] New: [4.1/4.2 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k
[ Forwarded from http://bugs.debian.org/375522 ]
I get the following ICE with gcc 4.1 and 4.2 on m68k:
928:[EMAIL PROTECTED]: ~] m68k-linux-gnu-gcc -c -O2 mini.c
mini.c: In function âscanâ:
mini.c:48: warning: incompatible implicit declaration of built-in function
âstrlenâ
mini.c:90: warning: assignment makes integer from pointer without a cast
mini.c:94: warning: incompatible implicit declaration of built-in function
âstrlenâ
mini.c:115: warning: initialization from incompatible pointer type
mini.c:122: error: insn does not satisfy its constraints:
(insn 323 57 324 9 (set (reg:QI 8 %a0)
(mem/s:QI (plus:SI (reg/f:SI 14 %a6)
(const_int -128 [0xff80])) [0 name+0 S1 A16])) 41
{*m68k.md:748} (nil)
(nil))
mini.c:122: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
zsh: exit 1 m68k-linux-gnu-gcc -c -O2 mini.c
929:[EMAIL PROTECTED]: ~] m68k-linux-gnu-gcc -c -O1 mini.c
mini.c: In function âscanâ:
mini.c:48: warning: incompatible implicit declaration of built-in function
âstrlenâ
mini.c:90: warning: assignment makes integer from pointer without a cast
mini.c:94: warning: incompatible implicit declaration of built-in function
âstrlenâ
mini.c:115: warning: initialization from incompatible pointer type
930:[EMAIL PROTECTED]: ~]
FWIW, this test case fails with 4.2 but works with 4.1. The original bug was
reported against 4.1 though. I can build a 4.1 and run delta again if this
would be helpful. The original ICE with 4.1 is:
crest% gcc -c -O2 scansbr.i
scansbr.c: In function 'scan':
scansbr.c:369: error: insn does not satisfy its constraints:
(insn 1657 689 1658 81 (set (reg:QI 8 %a0)
(mem/s:QI (plus:SI (reg/f:SI 14 %a6)
(const_int -212 [0xff2c])) [0 name+0 S1 A16])) 33
{*m68k.md:748} (nil)
(nil))
scansbr.c:369: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
--
Summary: [4.1/4.2 regression] ICE in
reload_cse_simplify_operands, at postreload.c:393 on
m68k
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC build triplet: m68k-linux-gnu
GCC target triplet: m68k-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28181
[Bug target/25765] gfortran.dg/assign_2.f90 -O0 fails
--- Comment #5 from langton at gcc dot gnu dot org 2006-06-27 20:15 --- Created an attachment (id=11761) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11761&action=view) Geoffrey Keating's rs6000 patch applied to i386. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25765
[Bug target/28181] [4.0/4.1/4.2 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k
--- Comment #1 from tbm at cyrius dot com 2006-06-27 20:15 ---
Update: 4.0 shows the same problem. 3.4.6 works
crest% gcc-4.0 -c -O2 scansbr.i
scansbr.c: In function 'scan':
scansbr.c:154: warning: pointer targets in passing argument 2 of 'm_getfld'
differ in signedness
scansbr.c:154: warning: pointer targets in passing argument 3 of 'm_getfld'
differ in signedness
scansbr.c:189: warning: pointer targets in passing argument 2 of 'm_getfld'
differ in signedness
scansbr.c:189: warning: pointer targets in passing argument 3 of 'm_getfld'
differ in signedness
scansbr.c:225: warning: pointer targets in passing argument 2 of 'm_getfld'
differ in signedness
scansbr.c:225: warning: pointer targets in passing argument 3 of 'm_getfld'
differ in signedness
scansbr.c:262: warning: pointer targets in passing argument 2 of 'm_getfld'
differ in signedness
scansbr.c:262: warning: pointer targets in passing argument 3 of 'm_getfld'
differ in signedness
scansbr.c:369: error: insn does not satisfy its constraints:
(insn 1692 701 1693 82 (set (reg:QI 8 %a0)
(mem/s:QI (plus:SI (reg/f:SI 14 %a6)
(const_int -212 [0xff2c])) [0 name+0 S1 A16])) 33
{*m68k.md:746} (nil)
(nil))
scansbr.c:369: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
--
tbm at cyrius dot com changed:
What|Removed |Added
Known to fail||4.0.4 4.1.1 4.2.0
Known to work||3.4.6
Summary|[4.1/4.2 regression] ICE in |[4.0/4.1/4.2 regression] ICE
|reload_cse_simplify_operands|in
|, at postreload.c:393 on|reload_cse_simplify_operands
|m68k|, at postreload.c:393 on
||m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28181
[Bug target/28181] [4.0/4.1/4.2 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k
--- Comment #2 from tbm at cyrius dot com 2006-06-27 20:17 --- Created an attachment (id=11762) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11762&action=view) test case for 4.2 reduced testcase, shows the problem with 4.2 only -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28181
[Bug target/28181] [4.0/4.1/4.2 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k
--- Comment #3 from tbm at cyrius dot com 2006-06-27 20:19 --- Created an attachment (id=11763) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11763&action=view) preprocessed source Original preprocessed source, shows the problem with 4.0, 4.1 and 4.2. Works with 3.4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28181
[Bug target/28181] [4.0/4.1/4.2 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k
--- Comment #3 from tbm at cyrius dot com 2006-06-27 20:19 --- Created an attachment (id=11763) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11763&action=view) preprocessed source Original preprocessed source, shows the problem with 4.0, 4.1 and 4.2. Works with 3.4.6. --- Comment #4 from tbm at cyrius dot com 2006-06-27 20:19 --- Created an attachment (id=11764) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11764&action=view) preprocessed source Original preprocessed source, shows the problem with 4.0, 4.1 and 4.2. Works with 3.4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28181
[Bug c++/28182] New: Bad behaviour when missing "typename" keyword.
Sorry if it is ill-built bugreport, this is my first one.
tets3.cpp:
templateclass TT>
struct QQQ{
typedef TT::sss::template OOO plcU;
};
$ g++ --version
g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -v -save-temps test3.cpp
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs --without-x
--enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter
--disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm
--disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization
--enable-libstdcxx-debug : (reconfigured)
Thread model: posix
Ð ÐРµСÐСÐСâСРgcc 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -E -quiet -v -D__CYGWIN32__
-D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api
test3.cpp -mtune=pentiumpro -o test3.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include
/usr/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api
End of search list.
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -fpreprocessed test3.ii -quiet
-dumpbase test3.cpp -mtune=pentiumpro -auxbase test3 -version -o test3.s
GNU C++ version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
(i686-pc-cygwin)
compiled by GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
test3.cpp:3: internal compiler error: in lookup_member, at cp/search.c:1296
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: Bad behaviour when missing "typename" keyword.
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: _vi at list dot ru
GCC host triplet: Windows XP (cygwin)
GCC target triplet: Windows XP (cygwin)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28182
[Bug target/28183] New: [4.0/4.1/4.2 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils
[ forwarded from http://bugs.debian.org/375519 ] We get the following assembler error when compiling the application cln. The error goes away when you drop -fPIC or when you use gcc 3.4. Additionally, the error does not show up with older releases of binutils. While 2.16.91 20060413 produces the error, 2.16.91 20051117 works fine. I'm not sure if this is a bug in binutils but given that gcc 3.4 works I'm filing it as a gcc bug. Andreas, since you're also involved in binutils, I hope you know where to put the blame. ;-) crest% g++-4.1 -fPIC -DPIC -c cl_MI.ii crest% g++-4.1 -fPIC -DPIC -c -O2 cl_MI.ii cl_MI.o: No error /tmp/ccjCp4mS.s: Assembler messages: /tmp/ccjCp4mS.s:18716: FATAL: can't close cl_MI.o : No error crest% g++-4.0 -fPIC -DPIC -c -O2 cl_MI.ii cl_MI.o: No error /tmp/ccreQBwI.s: Assembler messages: /tmp/ccreQBwI.s:19590: FATAL: can't close cl_MI.o : No error crest% g++-3.4 -fPIC -DPIC -c -O2 cl_MI.ii crest% as --version GNU assembler 2.16.91 20060413 Debian GNU/Linux Copyright 2005 Free Software Foundation, Inc. -- Summary: [4.0/4.1/4.2 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: m68k-linux-gnu GCC target triplet: m68k-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
[Bug target/28181] [4.0/4.1/4.2 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k
--- Comment #5 from tbm at cyrius dot com 2006-06-27 21:24 --- Created an attachment (id=11765) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11765&action=view) test case This one fails with gcc 4.1 and 4.2. -- tbm at cyrius dot com changed: What|Removed |Added Attachment #11762|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28181
[Bug target/28183] [4.0/4.1/4.2 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils
--- Comment #1 from tbm at cyrius dot com 2006-06-27 22:08 --- Created an attachment (id=11766) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11766&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
[Bug target/28183] [4.0/4.1/4.2 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils
--- Comment #2 from tbm at cyrius dot com 2006-06-27 22:21 --- What I said about binutils might be wrong. It seems it's not due to a difference in the version, but due to one being native and one being cross. I just upgraded the binutils-m68k on i386 to the same version as that on m68k native and strangely enough the same .s file works on i386 with m68k-as but fails on m68k: native: crest% as test.s a.out: No error test.s: Assembler messages: test.s:18960: FATAL: can't close a.out : No error crest% as --version GNU assembler 2.16.91 20060413 Debian GNU/Linux Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `m68k-linux-gnu'. crest% i386: 1173:[EMAIL PROTECTED]: ~] /usr/local/bin/m68k-linux-gnu-as test.s 1174:[EMAIL PROTECTED]: ~] /usr/local/bin/m68k-linux-gnu-as --version GNU assembler 2.16.91 20060413 Debian GNU/Linux Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `m68k-linux-gnu'. 1175:[EMAIL PROTECTED]: ~] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
[Bug libfortran/28184] New: time intrinsics resolution only one second
While testing the time intrinsics on a Windows machine using the mingw binary from the wiki I noticed the smallest increment of time_and_date, etime, and secnds is 1 second. Should be able to get to milliseconds. -- Summary: time intrinsics resolution only one second Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28184
[Bug fortran/19310] [4.1 Only] unnecessary error for overflowing results
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:37 --- Subject: Bug 19310 Author: jvdelisle Date: Wed Jun 28 05:36:08 2006 New Revision: 115048 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115048 Log: 2006-06-27 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19310 PR fortran/19904 * arith.c (gfc_range_check): Return ARITH_OK if -fno-range-check. Add return of ARITH_NAN, ARITH_UNDERFLOW, and ARITH_OVERFLOW. (gfc_arith_divide): If -fno-range-check allow mpfr to divide by zero. * gfortran.h (gfc_option_t): Add new flag. * invoke.texi: Document new flag. * lang.opt: Add option -frange-check. * options.c (gfc_init_options): Initialize new flag. (gfc_handle_options): Set flag if invoked. * simplify.c (range_check): Add error messages for overflow, underflow, and other errors. * trans-const.c (gfc_conv_mpfr_to_tree): Build NaN and Inf from mpfr result. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/arith.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/invoke.texi branches/gcc-4_1-branch/gcc/fortran/lang.opt branches/gcc-4_1-branch/gcc/fortran/options.c branches/gcc-4_1-branch/gcc/fortran/simplify.c branches/gcc-4_1-branch/gcc/fortran/trans-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19310
[Bug fortran/19904] [4.1 Only] Division by zero leads to error
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:37 --- Subject: Bug 19904 Author: jvdelisle Date: Wed Jun 28 05:36:08 2006 New Revision: 115048 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115048 Log: 2006-06-27 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19310 PR fortran/19904 * arith.c (gfc_range_check): Return ARITH_OK if -fno-range-check. Add return of ARITH_NAN, ARITH_UNDERFLOW, and ARITH_OVERFLOW. (gfc_arith_divide): If -fno-range-check allow mpfr to divide by zero. * gfortran.h (gfc_option_t): Add new flag. * invoke.texi: Document new flag. * lang.opt: Add option -frange-check. * options.c (gfc_init_options): Initialize new flag. (gfc_handle_options): Set flag if invoked. * simplify.c (range_check): Add error messages for overflow, underflow, and other errors. * trans-const.c (gfc_conv_mpfr_to_tree): Build NaN and Inf from mpfr result. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/arith.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/invoke.texi branches/gcc-4_1-branch/gcc/fortran/lang.opt branches/gcc-4_1-branch/gcc/fortran/options.c branches/gcc-4_1-branch/gcc/fortran/simplify.c branches/gcc-4_1-branch/gcc/fortran/trans-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
[Bug fortran/19904] [4.1 Only] Division by zero leads to error
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:40 --- Subject: Bug 19904 Author: jvdelisle Date: Wed Jun 28 05:39:07 2006 New Revision: 115049 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115049 Log: 2006-06-27 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19310 PR fortran/19904 * gfortran.dg/real_const_3.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/real_const_3.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
[Bug fortran/19310] [4.1 Only] unnecessary error for overflowing results
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:40 --- Subject: Bug 19310 Author: jvdelisle Date: Wed Jun 28 05:39:07 2006 New Revision: 115049 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115049 Log: 2006-06-27 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/19310 PR fortran/19904 * gfortran.dg/real_const_3.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/real_const_3.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19310
[Bug fortran/19310] [4.1 Only] unnecessary error for overflowing results
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:45 --- Fixed in 4.1 now. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19310
[Bug libfortran/27704] Incorrect runtime error on multiple OPEN
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:48 --- If anyone else has started on this, let me know. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-28 05:48:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27704
[Bug fortran/19904] [4.1 Only] Division by zero leads to error
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-06-28 05:52 --- Fixed on 4.1 branch now. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19904
