[Bug middle-end/18820] ACATS c95300[123] and c980002 fail at runtime
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-14 08:04 --- Subject: Bug 18820 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-14 08:03:22 Modified files: gcc: ChangeLog varasm.c gcc/testsuite : ChangeLog gcc/testsuite/ada/acats: norun.lst Added files: gcc/testsuite/gcc.dg: nested-func-2.c Log message: PR middle-end/18820 * varasm.c (initializer_constant_valid_p) ADDR_EXPR: Return zero for nested functions needing a static chain or functions with a non-constant address. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7118r2=2.7119 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gccr1=1.474r2=1.475 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4881r2=1.4882 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/nested-func-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ada/acats/norun.lst.diff?cvsroot=gccr1=1.3r2=1.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18820
[Bug middle-end/18820] ACATS c95300[123] and c980002 fail at runtime
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-14 08:06 --- Patch applied. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18820
[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted
--- Additional Comments From SWElef at post dot sk 2005-01-14 08:24 --- I was a little in a hurry, so I'll add a comment on the test programm now. The reference time of std::list ctor taking range must be linear. Thus it makes sence to have a look at the quotient of the second and third collumn in the output. And that's where you can see the logarithmic behaviour. It is visible even for std::allocator but the pool allocator makes it shine. After giving it some thought I believe that calling the insert_unique/insert_equal function is wrong. I don't think that any hint (position) can help to make the running time linear in distance(first,last). A special function should be writen for this purpose. Why? Are you aware of the fact that insert with hint has amortized *constant* complexity if t is inserted after p? (Table 69) As stated in some thread on std.comp.c++ recently, amortized is allways with respect to something and that part is missing from the standard. The usual interpretation in this case is that if you take an assoc. container in a given state and take the average time of the insertion with hint at every position, it should be a constant (i.e. also independent of size()). It is far from guaranteed to be constant if you make a lot of insertions at the end. The position==end() is special-cased in the insert_unique/insert_equal function with hint and a member function _M_rightmost() is used. [When I tried to make an own version of map I decided not to have the information about the rightmost node and I was able to satisfy all complexity requirements anyway (except those deffective). This influenced my previously expressed opinion.] With the access to the rightmost node in constant time the insertions at the end could actualy be in amortized constant time (amortized wrt. consecutive insertions at the end). This is just a feeling and needs to be proved. Regards, Vladimir Marko -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19422
[Bug target/19357] ICE when long double argument arrives in general register
--- Additional Comments From jbeulich at novell dot com 2005-01-14 08:58 --- Isn't the MEM case moving things in the wrong direction? If so, and since I tried to fix this myself before submitting the bug, simply swapping the operands of emit_move_insn doesn't seem to work (made the compiler die when optimizing for me). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19357
[Bug ada/19419] ACATS CXA4009, CXA4020 - valgrind detects bad code (overlapping memcpy)
--- Additional Comments From baldrick at free dot fr 2005-01-14 08:59 --- Subject: Re: New: ACATS CXA4009, CXA4020 - valgrind detects bad code (overlapping memcpy) Here is a much simplified version: gnatmake -s -g -O2 tt valgrind --tool=memcheck ./tt ==10048== Memcheck, a memory error detector for x86-linux. ==10048== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==10048== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==10048== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==10048== For more details, rerun with: -v ==10048== ==10048== Source and destination overlap in memcpy(0x52BFDE84, 0x52BFDE85, 2) ==10048==at 0x1B906815: memcpy (mac_replace_strmem.c:113) ==10048==by 0x80496F9: ss(short, long, int, double,...) (ss.adb:5) ==10048==by 0x804978C: _ada_tt (tt.adb:9) ==10048==by 0x8049634: main (b~tt.adb:112) ==10048== ==10048== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1) ==10048== malloc/free: in use at exit: 10280 bytes in 2 blocks. ==10048== malloc/free: 2 allocs, 0 frees, 10280 bytes allocated. ==10048== For a detailed leak analysis, rerun with: --leak-check=yes ==10048== For counts of detected errors, rerun with: -v package SS is type Super_String (Length : Positive) is record Data : String (1 .. Length); end record; procedure Slide (Source : in out Super_String); end SS; package body SS is procedure Slide (Source : in out Super_String) is begin Source.Data (1 .. Source.Length - 1) := Source.Data (2 .. Source.Length); end; end SS; with SS; use SS; procedure TT is S : Super_String := ( Length = 3, Data = ABC ); begin Slide (S); end; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19419
[Bug tree-optimization/19401] Trivial loop not unrolled
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-01-14 09:04 --- Other possible patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00796.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19401
cvs snap compilation error
Sorry to bug you here guys, but I have no idea where to ask about it. I have downloaded via cvs current snapshot, and it doesn't compile: config.status: executing default commands make[1]: Entering directory `/home/users/gj/Projects/gcc-4.0/gcc/build-x86_64-unknown-linux-gnu/libiberty' if [ x != x ] [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir make[1]: *** No rule to make target `../include/ansidecl.h', needed by `regex.o'. Stop. make[1]: Leaving directory `/home/users/gj/Projects/gcc-4.0/gcc/build-x86_64-unknown-linux-gnu/libiberty' make: *** [all-build-libiberty] Error 2 configured with: ./configure --prefix=/usr/local/gcc4.0 --with-system-zlib --enable-languages=c,c++ Linux flat41 2.6.11-rc1 #3 SMP Fri Jan 14 00:05:41 CET 2005 x86_64 0 unknown PLD Linux Thanks. -- Vercetti
[Bug c++/19437] New: wrong warning when assigning negative value to int
The following code compiled as C++ (does not happen when compiled as C), issues
a wrong warning:
void test()
{
unsigned int i = 0;
int val = i ? i : -1;
}
$ gcc -c test.cpp
test.cpp: In function `void test()':
test.cpp:4: warning: converting of negative value `-0x1' to `unsigned
int'
My GCC version:
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
I does also happen with MinGW GCC 3.3.3 and 4.0.0 (20040925) and linux GCC 3.2.
--
Summary: wrong warning when assigning negative value to int
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliverst at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19437
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From Woebbeking at web dot de 2005-01-14 09:56 --- Subject: Re: [4.0 Regression] name lookup is broken with friends On Thursday 13 January 2005 15:52, lerdsuwa at gcc dot gnu dot org wrote: So B's ctor uses the global A without the friend declaration and with the friend declaration the local injected A? Sometimes the holy standard confuses me a bit. No. With or without friend declaration, the B's ctor should always pick the global A. This is one weird rule in C++ standard. Now I'm even more confused than before. Who is right, Gaby or lerdsuwa? André -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c/19438] New: Unable to build cross-gcc to target powerpc-eabi
I downloaded and installed cygwin, version of cygwin1.dll is 1.5.12-1. I downloaded gcc-3.4.3 sources, gcc-3.4.3.tar.gz, and unpacked it to /home/gcc-3.4.3 Then I wanted to build a gcc cross-compiler for target powerpc-eabi (mpc5xx) I used this to configure: @ /home/gcc-3.4.3: mkdir obj @ /home/gcc-3.4.3: cd obj @ /home/gcc-3.4.3/obj: ../configure --prefix=/usr/local --with-gnu-as --with-gn u-ld --disable-threads --with-cpu=powerpc --enable-languages=c,c++ --target=pow erpc-ppc-eabi I even tried this: @ /home/gcc-3.4.3/obj: ../configure --prefix=/usr/local --with-gnu-as --with-gn u-ld --disable-threads --with-cpu=powerpc --enable-languages=c,c++ --target=pow erpc-eabi and I issued make: @ /home/gcc-3.4.3/obj: make Then I got this error message (in both configure cases) ... /home/gcc-3.4.3/obj/gcc/xgcc -B/home/gcc-3.4.3/obj/gcc/ -B/usr/local/powerpc-ppc -eabi/bin/ -B/usr/local/powerpc-ppc-eabi/lib/ -isystem /usr/local/powerpc-ppc-ea bi/include -isystem /usr/local/powerpc-ppc-eabi/sys-include -O2 -DIN_GCC -DCROS S_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -W old-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NE EDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I. ./intl -mrelocatable-lib -mno-eabi -mstrict-align -DL_muldi3 -c ../../gcc/libgc c2.c -o libgcc/./_muldi3.o as: unrecognized option `-mppc' make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/home/gcc-3.4.3/obj/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/home/gcc-3.4.3/obj/gcc' make: *** [all-gcc] Error 2 which as gives the following: /usr/bin/as as --version gives the following: @ /home/gcc-3.4.3/obj: as --version GNU assembler 2.15.94 20041229 Copyright 2002 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 `i686-pc-cygwin'. Remark: bill's homepage is down so I couldn't read the crossgcc.faq -- Summary: Unable to build cross-gcc to target powerpc-eabi Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: qty154 at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: powerpc-ppc-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19438
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
-- What|Removed |Added Summary|[4.0 regression] ICE with |[4.0 regression] ICE with |solf-float on m68k |soft-float on m68k http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug c/19438] Unable to build cross-gcc to target powerpc-eabi
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-14 10:29 --- At this point the cross-compiler itself is built. You need a cross-assembler to proceed, i.e you need to have an 'as' with --target=powerpc-eabi and properly declare it when configuring the cross-compiler. See the docs. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19438
[Bug c++/19439] New: Duplicate destructor accepted
The following invalid code snippet is accepted (since at least gcc 2.95.3).
It is rejected when A gets instantiated, but that could be diagnosed at
definition time IMHO.
===
templateint struct A
{
~A() {}
~A() {}
};
===
--
Summary: Duplicate destructor accepted
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19439
[Bug middle-end/19084] [4.0 Regression] ICE: internal consistency failure
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-14 10:50 --- Subject: Bug 19084 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-14 10:50:19 Modified files: gcc: ChangeLog basic-block.h recog.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050111-1.c gcc/testsuite/gcc.dg: 20050111-1.c Log message: PR middle-end/19084 PR rtl-optimization/19348 * recog.c (peephole2_optimize): Do global life update if some peephole decides it doesn't need at least one of its inputs and that change influences liveness at the start of the basic block. * basic-block.h (EXECUTE_IF_AND_COMPL_IN_REG_SET): Needs 2 REGSET arguments instead of 1. * gcc.dg/20050111-1.c: New test. * gcc.c-torture/execute/20050111-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7119r2=2.7120 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/basic-block.h.diff?cvsroot=gccr1=1.233r2=1.234 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/recog.c.diff?cvsroot=gccr1=1.215r2=1.216 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4883r2=1.4884 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050111-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050111-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19084
[Bug rtl-optimization/19348] [4.0 Regression] internal consistency error while compiling linux kernel
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-14 10:50 --- Subject: Bug 19348 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-14 10:50:19 Modified files: gcc: ChangeLog basic-block.h recog.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050111-1.c gcc/testsuite/gcc.dg: 20050111-1.c Log message: PR middle-end/19084 PR rtl-optimization/19348 * recog.c (peephole2_optimize): Do global life update if some peephole decides it doesn't need at least one of its inputs and that change influences liveness at the start of the basic block. * basic-block.h (EXECUTE_IF_AND_COMPL_IN_REG_SET): Needs 2 REGSET arguments instead of 1. * gcc.dg/20050111-1.c: New test. * gcc.c-torture/execute/20050111-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7119r2=2.7120 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/basic-block.h.diff?cvsroot=gccr1=1.233r2=1.234 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/recog.c.diff?cvsroot=gccr1=1.215r2=1.216 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4883r2=1.4884 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050111-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050111-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19348
[Bug c++/19440] New: Invalid destructor declaration in template class accepted
The following IMHO invalid code snippet is accepted
(since at least gcc 2.95.3).
===
templateint struct A
{
~A0();
};
===
--
Summary: Invalid destructor declaration in template class
accepted
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19440
[Bug c++/19441] New: [3.4 regression] ICE with invalid destructor declaration
The following invalid code snippet causes an ICE in gcc 3.4.x:
==
templateint struct A
{
Aint::~A() {}
};
==
bug.cc:3: error: type/value mismatch at argument 1 in template parameter list
for `templateint anonymous struct A'
bug.cc:3: error: expected a constant of type `int', got `int'
bug.cc:3: internal compiler error: in grokdeclarator, at cp/decl.c:6534
Please submit a full bug report, [etc.]
--
Summary: [3.4 regression] ICE with invalid destructor declaration
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19441
[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted
--- Additional Comments From pcarlini at suse dot de 2005-01-14 11:50 --- I was a little in a hurry, so I'll add a comment on the test programm now. The reference time of std::list ctor taking range must be linear. Thus it makes sence to have a look at the quotient of the second and third collumn in the output. And that's where you can see the logarithmic behaviour. It is visible even for std::allocator but the pool allocator makes it shine. Thanks for the clarification. I will definitely adapt your test program for our performance testsuite. ... With the access to the rightmost node in constant time the insertions at the end could actualy be in amortized constant time (amortized wrt. consecutive insertions at the end). This is just a feeling and needs to be proved. Indeed, it works: on my home machine (P4-2400) currently the quotient above grows from about 2.8 to 3.5 during the test. The trivial patch that I'm finishing testing leads to a constant value (~2.4), as expected. This is with the standard allocator, more suited for our testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19422
[Bug ada/18817] ACATS c380004 fails at run time
--- Additional Comments From laurent at guerby dot net 2005-01-14 12:10 --- Note that this test has been deactivated vi testsuite/ada/acats/norun.lst so it doesn't show up in testresults anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18817
[Bug ada/18302] ACATS test c953002 (and others) hangs
--- Additional Comments From laurent at guerby dot net 2005-01-14 12:14 --- Does it still hang? Eric just commited a fix for PR18820 that is likely to have fixed this problem. -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug fortran/19443] New: log10 statement does not work properly in gfortran
The log10 operator in gfortran (cygwin build 20041213) does not work properly if the statement is operated on a variable, but it works fine when operating on a constant. The plain log statement works fine regardless. If the following program is executed, one can observer that log for the two methods generates the same value, but log10 using the different methods produces different results. The 10*log10(tst) appears to generate -Infinity, where it should generate -50. program test implicit none real :: tst tst=1e-5 write(*,*) 10*log(1e-5), 10*log(tst) write(*,*) 10*log10(1e-5), 10*log10(tst) end program test -- Summary: log10 statement does not work properly in gfortran Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mgilbert at airborne dot nrl dot navy dot mil CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug c/19442] inet_ntoa always outputs 0.0.0.0 when built with -maix64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:00 --- *** This bug has been marked as a duplicate of 19428 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19442
[Bug middle-end/19084] [4.0 Regression] ICE: internal consistency failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:01 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19084
[Bug rtl-optimization/19348] [4.0 Regression] internal consistency error while compiling linux kernel
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:01 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19348
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:04 --- This works for me on ppc-darwin, are you sure that is not a bug in cygwin as fortran just calls log10f (which might call log10 if your target does not have the C99 math functions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug target/19009] Loading of FP constants into FP reg via SSE reg
--- Additional Comments From uros at kss-loka dot si 2005-01-14 13:08 --- It looks that the problem with FP compares forcing constant into wrong register part of this bug is solved. However, register allocator can still be confused when a variable is initialized to constant value: grep fldz povray_dump.sse | wc -l 117 grep fld1 povray_dump.sse | wc -l 141 grep pxor povray_dump.387 | wc -l 20 I'll try to provide a small testcase. The testcase (zero.c) attached to this bugreport is fixed, but anyway I suggest that we reopen this bug. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19009
[Bug target/19009] Loading of FP constants into FP reg via SSE reg
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:16 --- (In reply to comment #8) It looks that the problem with FP compares forcing constant into wrong register part of this bug is solved. However, register allocator can still be confused when a variable is initialized to constant value: Can you open a new one with the full testcase, since this is the register allocator being dumb which is usual in GCC. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19009
[Bug c++/19437] wrong warning when assigning negative value to int
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:19 --- The warning is correct. To get a warning in C you have to use -Wconversion. pr19437.c:4: warning: negative integer implicitly converted to unsigned type -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19437
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From mgilbert at airborne dot nrl dot navy dot mil 2005-01-14 13:20 --- I tried the exact same code with g95 on cygwin, and it worked flawlessly. gfortran must have access to the math library because it is able to evaluate log properly, right? How do you suggest that I go about determining whether it is a cygwin bug or gfortran bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug c++/19439] Duplicate destructor accepted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:20 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-14 13:20:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19439
[Bug c++/19440] Invalid destructor declaration in template class accepted
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:20 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-14 13:20:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19440
[Bug java/19444] New: GCJ implementation of java.net.URI misses host support
The implementation in cvs for GCJ's java.net.URI does currently not store the hostname attribute from a URI. It seems as if this variable is just forgotten to be assigned in the URI(String) constructor. The effect of this is that a getHost() method call always returns null because its underlying variable host is never set. -- Summary: GCJ implementation of java.net.URI misses host support Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Fabian dot Groffen at cwi dot nl 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=19444
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14
13:25 ---
Try this c code:
#include math.h
#include stdio.h
int main(void)
{
printf(%f\n, 10*log10(1.0e-5));
return 0;
}
It might also be the bug that isfinite does not work on cygwin which is a
different bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug c++/19441] [3.4 regression] ICE with invalid destructor declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:27 --- Broken: : Search converges between 2003-08-06-trunk (#316) and 2003-08-07-trunk (#317). Fixed on the mainline : Search converges between 2004-09-12-trunk (#538) and 2004-09-14-trunk (#539). -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-14 13:27:09 date|| Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19441
[Bug libgcj/12957] JNI Performance Issues
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:28 --- Fixed on the mainline by: 2005-01-13 Graydon Hoare [EMAIL PROTECTED] * include/jni.h (_Jv_JNIEnv::bottom_locals): New field. * include/jvm.h (_Jv_FreeJNIEnv): Declare. * java/lang/natThread.cc (finalize_native): Call _Jv_FreeJNIEnv. * jni.cc: Reuse bottom frame between calls, avoid clearing frame when no local references are made. -- What|Removed |Added Status|NEW |RESOLVED Component|java|libgcj Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12957
[Bug java/12725] [meta-bug] gcj does not conform to Binary Compatibility specification
-- Bug 12725 depends on bug 12957, which changed state. Bug 12957 Summary: JNI Performance Issues http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12957 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12725
[Bug libgcj/19444] GCJ implementation of java.net.URI misses host support
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:29 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|java|libgcj Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-14 13:29:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19444
[Bug tree-optimization/19431] missed optimization with ifs and deferencing
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-14 13:32:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted
--- Additional Comments From SWElef at post dot sk 2005-01-14 13:33 --- It took me quite a long time to realise that the best performance tests are those where we count the elementary operations. The best way to expose the O(n log n) complexity in non-fixed case is to supply the container with a comparator object that counts the invocations of operator() in some global variable. For an experimental proof that the fixed version is really linear one also needs to count the node manipulations by, say, replacing _Base_ptr with a smart pointer that acts as a plain pointer and counts every action (ctor, dtor, copy, dereference). Regards, Vladimir Marko -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19422
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From mgilbert at airborne dot nrl dot navy dot mil 2005-01-14 13:34 --- That c code above worked properly, and running g95 on my test code works fine also, so I think that pretty much indicates that the issue is with gfortran. and gfortran works fine when i do log10(1e-5), but fails on tst=1e-5; log10(tst). so it partially works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14
13:38 ---
Hmm, try this (if might be that log10f is broken):
#include math.h
#include stdio.h
int main(void)
{
float t = 1.0e-5;
printf(%f\n, 10*log10f(t));
return 0;
}
If this does not link (try -lm), otherwise I don't know where the bug is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From mgilbert at airborne dot nrl dot navy dot mil 2005-01-14 13:42 --- That code works properly also. I'm downloading an older snapshot of cygwin gfortran to see if the bug is in there also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:51 --- Then this might be a dup of bug 19363, if both of those C programs worked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug middle-end/19402] __builtin_powi? still missing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 13:53 --- Confirmed. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-14 13:53:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19402
[Bug target/7525] [ARM/Thumb] long calls stubs only in one code section, cannot branch to them from other section
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-14 13:59 --- Subject: Bug 7525 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-14 13:58:42 Modified files: gcc: ChangeLog gcc/config/arm : arm-protos.h arm.c arm.h arm.md Log message: PR target/7525 * arm.h (struct machine_function): Add call_via field. (thumb_call_via_label): Declare. * arm.c (thumb_call_via_label): New variable. (thumb_call_reg_needed): New variable. (arm_output_function_epilogue): For Thumb code, output any per-function call-indirect trampolines. (thumb_call_via_reg): New function. (arm_file_end): New function. (TARGET_ASM_FILE_END): Call arm_file_end. (aof_file_end): Likewise. * arm-protos.h (thumb_call_via_reg): Declare. * arm.md (call_reg_thumb, call_value_reg_thumb): Call thumb_call_via_reg in normal case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7120r2=2.7121 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm-protos.h.diff?cvsroot=gccr1=1.79r2=1.80 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gccr1=1.426r2=1.427 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.h.diff?cvsroot=gccr1=1.264r2=1.265 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.md.diff?cvsroot=gccr1=1.188r2=1.189 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7525
[Bug target/19424] [4.0 Regression] Error: suffix or operands invalid for `movlps'
--- Additional Comments From uros at gcc dot gnu dot org 2005-01-14 14:13 --- Register constraints are wrong for movv2sf* patterns. movlps can't handle the combination of x/x registers. Uros. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-14 14:13:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19424
[Bug target/7525] [ARM/Thumb] long calls stubs only in one code section, cannot branch to them from other section
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-14 14:17 --- http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00813.html Fixed for the common case, but not for caller super-inteworking. I don't intend to change that case, since that's outside the EABI and I still think the linker should be fixing these types of problems up with linker-generated stubs. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7525
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 14:18 --- Hmm, I cannot reproduce it on 20050113 with a cross from ppc-darwin compiled at -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug c++/19437] wrong warning when assigning negative value to int
--- Additional Comments From oliverst at online dot de 2005-01-14 14:26 --- Ah, OK. Why is there warning at all. -1 is being assigned to an int and not to an unsigned int. Writing it without the ? : operator, the following code should be the same. unsigned int i = 0; int val; if( i ) val = i; else val = -1; So a warning, that an unsigned int is being assigned to an int would make more sense to me. But I don't see how -1 is being assigned to an unsigned int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19437
[Bug libstdc++/19422] assoc. containers: ctor taking range is O(n log n) even if the range is sorted
--- Additional Comments From pcarlini at suse dot de 2005-01-14 14:28 --- Yes, we are already using something similar, elsewhere (e.g., our copy_tracker class). For the present needs, a tweaked version of your test program will do rather well: even with std::allocator, the new numbers are very stable and much improved, both in absolute value and as a trend. I will revisit the issue in the context of 19433, perhaps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19422
[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
-- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2004-10-08 18:44:35 |2005-01-14 14:30:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
[Bug c++/19437] wrong warning when assigning negative value to int
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 14:30 --- int val = i ? i : -1; we convert it to unsigned because it gets promoted to unsigned because i is unsigned and then there is an implicit cast to int. so the type of i ? i : -1 is unsigned and there is an implicit cast to int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19437
[Bug target/13754] [3.4/4.0 regression] ip2k-elf ICE on multiple gotos
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 14:34 --- Suspending as this has been broken for a long time and no movement in fixing this regression. I would proposed this target to be removed since it looks like it is no longer being maintained. -- What|Removed |Added Status|WAITING |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13754
[Bug middle-end/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05
-- What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |middle-end Ever Confirmed||1 GCC build triplet|* | GCC host triplet|* | GCC target triplet|* | Last reconfirmed|-00-00 00:00:00 |2005-01-14 14:34:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From joel at gcc dot gnu dot org 2005-01-14 14:39 --- (In reply to comment #2) Hmm, I cannot reproduce it on 20050113 with a cross from ppc-darwin compiled at -O0. Can you reproduce it at -O2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 14:40 --- (In reply to comment #3) (In reply to comment #2) Hmm, I cannot reproduce it on 20050113 with a cross from ppc-darwin compiled at -O0. Can you reproduce it at -O2? No what I had meant is that cc1 was compiled at -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From joel at gcc dot gnu dot org 2005-01-14 14:45 --- Wierd.. we are on x86-gnu-linux so would be using a totally different host compiler. I am using a gcc 3.4.3 and don't know what Ralf is using. Does it fail when cc1 is compiled at a higher optimization level? Are you saying it looks more like cc1 is being miscompiled on the x86 host? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug libstdc++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 14:45 --- Actually this is not a middle-end after all. The problem is that __throw_bad_alloc is not marked as noreturn as it should be. In the if-part, the function either (a) returns, from the while-loop; or (b) throws. In the else-part, it does return. Yes it throws but since libstdc++ use a function call to throw, well GCC does not know that function can return since it is not marked as noreturn. The patch which caused this warning: 2005-01-05 Benjamin Kosnik [EMAIL PROTECTED] * src/bitmap_allocator.cc: Use __throw_bad_alloc. -- What|Removed |Added CC||bkoz at gcc dot gnu dot org, ||gdr at gcc dot gnu dot org Component|middle-end |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 14:50 --- What options are used to configure gcc, maybe it has something to do with that (what I mean a different default CPU is done). I configured with ../configure --target=m68k-rtems4.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-14 15:15 --- (In reply to comment #6) I on Fedora Core 3 and am using FC3's toolchain. What options are used to configure gcc, maybe it has something to do with that (what I mean a different default CPU is done). I configured with ../configure --target=m68k-rtems4.7 /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -v Using built-in specs. Configured with: ../gcc-4.0.0/configure --prefix=/opt/rtems-4.7 --mandir=/opt/rtems-4.7/man --infodir=/opt/rtems-4.7/info --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=m68k-rtems4.7 --with-gnu-as --with-gnu-ld --with-newlib --verbose --with-system-zlib --disable-nls --enable-version-specific-runtime-libs --enable-threads=rtems --enable-languages=c,c++ Thread model: rtems gcc version 4.0.0 20050112 (experimental) I am building gcc one-tree-style with newlib-CVS merged via symlinks into GCC's source-tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-14 16:06 --- Subject: Re: [4.0 Regression] name lookup is broken with friends Woebbeking at web dot de [EMAIL PROTECTED] writes: | Subject: Re: [4.0 Regression] name lookup is broken with friends | | On Thursday 13 January 2005 15:52, lerdsuwa at gcc dot gnu dot org wrote: | | So B's ctor uses the global A without the friend declaration and with the | friend declaration the local injected A? Sometimes the holy standard | confuses me a bit. | | No. With or without friend declaration, the B's ctor should always pick | the global A. This is one weird rule in C++ standard. | | Now I'm even more confused than before. Who is right, Gaby or lerdsuwa? lerdsuwa is right on all points. Gaby is right on the friend declaration and wrong the fact that the code should not compile. Both lerdsuwa and Gaby agree on what the friend declaration does. The program would compile (as it does in previous versions) but it will not have the same semantics as with previous GCC. The previous behaviour was wrong in the sense that GCC picked the wrong A. When lerdsuwa's patch is applied, your program will be accpeted, but it will not do what you thought it would do. As a tangential note, sometime ago, I requested that a template-parameter be allowed to be a friend (currently forbidden). As a result of that reuest, Mike Miller proposed a wording to amend the current rules and we will have the new friend syntax friend T; where T can be any type-name -- not just an elaborated specifier.. At the moment there is a debate whether that friend-declaration should introduce a new name (current friend-declaration semantics) or just refer to an existing declaration (with error if none exists). John Spicer and I favour the latter semantics. If that semantics get adopted, you could leave out the class from your friend-declaration and the semantics would be such that in all cases the compiler will pick ::A. Which I believe is the least surprising behaviour. This proposal had been discussed at several time by both Core and Evolution groups; and Mike already wrote formal standardese for that. My hope is that the next meeting would promote that formal specification to higher level, either in the working paper or close to. But I guess that does not help you much, now. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug c++/19403] [4.0 Regression] name lookup is broken with friends
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-14 16:10 --- Subject: Re: [4.0 Regression] name lookup is broken with friends pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #2) | Excuse me? | | You are right, but what is werid here is that ICC even in strict mode and Comeau accept the code. My apologies. After close inspection, ICC and Comeau are right in accepting the code, but with semantics different from what GCC used to do (wrong behaviour). | This is invalid code and a dup of bug 14513. Sadly, I was hastly. The code is valid, this is reject-valid. But the behaivour is not the one we used to implement. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
[Bug fortran/19443] log10 statement does not work properly in gfortran
--- Additional Comments From mgilbert at airborne dot nrl dot navy dot mil 2005-01-14 16:51 --- My test code works perfectly with the 20041114 cygwin gfortran and earlier snapshots. I agree, this could be related to #19363 since the dates of working/non-working code are similar. I guess your best bet would be to track down what changes between 20041114 and 20041212 could cause the errors we're seeing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19443
[Bug c++/19445] New: 50 fold compile time increase between gcc-3,4 and gcc-4,0 on included code
$ time g++-snapshot -O -c list1.ii
real0m3.617s
user0m3.515s
sys 0m0.043s
$ time g++-3.4 -O -c list1.ii
real0m0.068s
user0m0.028s
sys 0m0.007s
$ g++-snapshot -v
Using built-in specs.
Configured with: ../src/configure -v --enable-languages=c,c++,java,objc,ada
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --enable-nls
--enable-threads=posix --without-included-gettext --disable-werror
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
i486-linux-gnu
Thread model: posix
gcc version 4.0.0 20050110 (experimental)
$ cat list1.ii
# 1 list1.cpp
# 1 built-in
# 1 command line
# 1 list1.cpp
templateclass T class Pointer
{
typedef PointerT point;
T *ptr;
public:
Pointer() : ptr(0) { }
Pointer(T *x) : ptr(x) { if(ptr) ptr-inc(); }
~Pointer() { if(ptr) ptr-dec(); ptr=0; }
T *operator-() const { return ptr; }
T operator*() const { return *ptr; }
bool null() const { return ptr == 0; }
void exchange(Pointer x)
{ T *t = x.ptr; x.ptr = ptr; ptr = t; }
};
class ListNode
{
public:
mutable int count;
PointerListNode next;
void unhook(PointerListNode *p)
{
while(!(*p).null() (*p)-count == 1)
{
PointerListNode t;
t.exchange((*p)-next);
t.exchange(*p);
}
}
public:
~ListNode()
{
unhook(next);
}
void inc() const
{ ++count; }
void dec() const
{ if(--count = 0) delete this; }
public:
ListNode(const int d)
: count(0), next()
{ }
};
void test(ListNode p)
{
p.unhook(p.next);
}
--
Summary: 50 fold compile time increase between gcc-3,4 and gcc-
4,0 on included code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phil at fsel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19445
[Bug c++/19445] 50 fold compile time increase between gcc-3,4 and gcc-4,0 on included code
--- Additional Comments From phil at fsel dot com 2005-01-14 16:53 --- Created an attachment (id=7959) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7959action=view) .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19445
[Bug c++/19445] 50 fold compile time increase between gcc-3,4 and gcc-4,0 on included code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 17:02 --- Can you check with --disable-checking as checking is turned on by default on the mainline of 4.0.0. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19445
__builtin_constant_p not evalutating to a constant
Hello! There was a similar question to this on the mailing list archives, but I could not find the answer. I would like to combine __builtin_choose_expr with __builtin_constant_p, in something like this: #define SHIFTLEFT(a,b) __builtin_choose_expr(__builtin_constant_p(b), \ ((a) (b)), \ ((a) (MIN(31,MAX(-31,(b) I could use this to determine whether I need special behavoir, because I might be able to assume that constants were never in some bad range of values. Unfortunately, when I try this, I get: file.c:42 error: first argument to __builtin_choose_expr not a constant However, according to the documentation, __builtin_constant_p should return 0 if the compiler cannot prove that the argument expression is a constant. One would expect that 0 is a constant, and that it should always be a valid first argument to __builtin_choose_expr. Am I doing something wrong? Perhaps we could have __builtin_constant_constant_p() that would be a valid constant always? Thanks! Erich -- Why are ``tolerant'' people so intolerant of intolerant people?
[Bug c/19446] New: ICE when building gcc for avr target
When building avr-gcc from the CVS repository (trunk), configured as follows: ../gcc/configure --target=avr --enable-languages=c --disable-nls I get an internal error: /home/degay/avr-gcc-build/gcc/xgcc -B/home/degay/avr-gcc-build/gcc/ -B/usr/local/avr/bin/ -B/usr/local/avr/lib/ -isystem /usr/local/avr/include -isystem /usr/local/avr/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -DL_fixdfdi -c ../../gcc/gcc/libgcc2.c -o libgcc/./_fixdfdi.o ../../gcc/gcc/libgcc2.c: In function '__fixdfdi': ../../gcc/gcc/libgcc2.c:1267: internal compiler error: in find_valid_class, at reload.c:719 -- Summary: ICE when building gcc for avr target Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dgay at intel-research dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: avr-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19446
[Bug c++/19447] New: unknown conversion type character `q' in format
When building today's (2005-01-14) gcc-trunk for different (cross-) targets on FC3, I am seeing many (several 10ths) warnings of this kind: ... gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fno-common -DHAVE_CONFIG_H-I. -Icp -I../../gcc-4.0.0/gcc -I../../gcc-4.0.0/gcc/cp -I../../gcc-4.0.0/gcc/../include -I../../gcc-4.0.0/gcc/../libcpp/include ../../gcc-4.0.0/gcc/cp/call.c -o cp/call.o ../../gcc-4.0.0/gcc/cp/call.c: In function `build_new_op': ../../gcc-4.0.0/gcc/cp/call.c:3765: warning: unknown conversion type character `q' in format ../../gcc-4.0.0/gcc/cp/call.c:3765: warning: too many arguments for format ../../gcc-4.0.0/gcc/cp/call.c: In function `enforce_access': ../../gcc-4.0.0/gcc/cp/call.c:4068: warning: unknown conversion type character `q' in format ../../gcc-4.0.0/gcc/cp/call.c:4068: warning: too many arguments for format ../../gcc-4.0.0/gcc/cp/call.c:4070: warning: unknown conversion type character `q' in format ../../gcc-4.0.0/gcc/cp/call.c:4070: warning: too many arguments for format ../../gcc-4.0.0/gcc/cp/call.c:4072: warning: unknown conversion type character `q' in format ../../gcc-4.0.0/gcc/cp/call.c:4072: warning: too many arguments for format ... In my understanding, this is the native gcc (gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) complaining about GCC-4.0.0 using %q as a format string. I haven't tried, but IMO this probably results into GCC/c++ using non-functional format strings. -- Summary: unknown conversion type character `q' in format Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: 386-redhat-linux-gnu GCC host triplet: i386-redhat-linux-gnu GCC target triplet: *-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19447
[Bug c++/19448] New: Different value representation for bitfield width exceeding its type size.
The gcc compiler information: Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- infodir=/usr/share/info --enable-shared --enable-threads=posix --disable- checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind- exceptions --enable-languages=c,c++,objc,java,f77 --enable-java-awt=gtk -- host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux - -with-cpu=default32 Thread model: posix gcc version 3.4.3 20041125 (Red Hat 3.4.3-6.EL4) In the attached testcase, the bitfield width is bigger than its type size, and the bitfield is initialized with a value greater than 127. When c1.m1 is assigned with different value, the result is different using g++3.4.3 and g++ 4.0.0 compilers: c1.m1=128, g++ 3.4.3's result: 128, g++ 4.0.0's result: -128. c1.m1=400, g++ 3.4.3's result: 144, g++ 4.0.0's result: -112. c1.m1=500, g++ 3.4.3's result: 244, g++ 4.0.0's result: -12. Could you tell me which compiler version gives the correct result, and why? -- Summary: Different value representation for bitfield width exceeding its type size. Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yanliu at ca dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From yanliu at ca dot ibm dot com 2005-01-14 18:21 --- Created an attachment (id=7960) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7960action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug libgcj/18222] [4.0 Regression] libjava bootstrap failure on Tru64 UNIX: CPPFLAGS changed in libltdl
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-01-14 18:25 --- Subject: Re: [4.0 Regression] libjava bootstrap failure on Tru64 UNIX: CPPFLAGS changed in libltdl kcook at gcc dot gnu dot org writes: Could someone please verify that this patch fixes the Alpha bootstrap bug. It does: I've successfully bootstrapped mainline on alpha-dec-osf5.1b with this patch: http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00655.html While there are many C++ execution failures (which seem to be easily fixable), the Java results are quite similar to those from July 2004 (when I last successfully bootstrapped on Tru64 UNIX V5.1B). Thanks alot. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18222
[Bug middle-end/18089] [4.0 regression] Valgrind errors in real.c
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-14 18:35 --- Are you sure this is not just a bug in valgrind? I have verified that with current CVS I get ERROR SUMMARY: 37 errors from 21 contexts (suppressed: 12 from 1) while if I rebuild stage1's combine.o with Roger's patch backed out, link new stage1 cc1, then rebuild stage2's real.o with the new stage1 cc1 and link new stage2 cc1, I get ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1) I did a binary search on real.s and e.g. one of the valgrind errors is triggered by following change in real.s: @@ -6453,8 +6453,8 @@ round_for_format: .p2align 2,,3 .L997: movl(%ebp), %eax + subl$-2147483648, %eax shrl$5, %eax - xorl$67108864, %eax subl$67108864, %eax cmpl%eax, 32(%esp) jge .L979 With the xorl there are no errors, with subl there is one error. But I don't see any functional difference between these two. If I replace 28 occurences of these subl $0x8000, %eax before 5 to xorl $0x400, %eax after 5 (I left out encoders/decoders of non-ieee formats), valgrind stops reporting any errors. So to me this looks like valgrind not handling subl $0x8000, %eax instruction correctly. Do you agree? I used valgrind 2.2.0. -- What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18089
[Bug c++/19447] unknown conversion type character `q' in format
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 18:36 --- Invalid, the warnings were correct for compiling 3.4.x but are not correct when compiling 4.0.0 but you have to compile with 4.0.0 to get correct warnings for this case. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19447
[Bug middle-end/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 18:37 --- *** Bug 19446 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dgay at intel-research dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug c/19446] ICE when building gcc for avr target
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 18:37 --- *** This bug has been marked as a duplicate of 19378 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19446
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 19:01 --- Hmm, are you sure that you are not comparing against gcc for ppc-darwin and gcc for ppc-linux because the default sign-ness of char is different between them. On ppc-darwin, the char is signed by default and for ppc-linux it is unsigned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 19:06 --- I will just have a note here from what the standard say about this issue: in such cases the extra bits are used for padding and do not participate in the value representation of the bit-field (9.6P1) It is implmentation-defined whether a plain (neitther explicitly signed nor unsigned) char, short, int or long bit-field is signed or unsigned. So both are right if we changed the definedness (but I still think you are comparing ppc-darwin vs ppc- linux). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c/19449] New: __builtin_constant_p cannot resolve to const when optimizing
Given the following code:
#define SHIFTLEFT(a,b) __builtin_choose_expr(__builtin_constant_p(b), \
((a) (b)), \
((a) (MIN(31,MAX(-31,(b))
int foo(int a, int b) { return SHIFTLEFT (a, b); }
the compiler will error:
gcc -O4 gcctest.c
gcctest.c: In function `foo':
gcctest.c:5: error: first argument to __builtin_choose_expr not a constant
According to the documentation to __builtin_constant_p, it should resolve
to 0 if the compiler cannot prove that the argument is a constant.
--
Summary: __builtin_constant_p cannot resolve to const when
optimizing
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eplondke at gmail dot com
CC: eplondke at gmail dot com,gcc-bugs at gcc dot gnu dot
org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449
[Bug c++/19450] New: __thread static class members
gcc generates incorrect code for static members in some cases. Consider the
following code:
struct C {
static __thread int x;
static __thread int y;
};
__thread int C::x;
void g() {
int z = C::x;
z = C::y;
}
When this is compiled on an x86 machine with gcc -S, the body of g() is
translated as:
movl%gs:[EMAIL PROTECTED], %eax
movl%eax, -4(%ebp)
movl_ZN1C1yE, %eax
movl%eax, -4(%ebp)
note that C::x is accessed using an offset from the thread pointer, which
is correct. C::y, however, is accessed as if it were an ordinary (not
thread-local) static member, which is incorrect. I have also observed
this problem on ia64 machines, so it seems to be a general issue.
These are similar to the symptoms described in bug 13668, although that was
determined to be a glibc issue. I see no way in which glibc could be
involved here.
Environment:
System: Linux algol.uwaterloo.ca 2.6.8-1-k7 #1 Thu Nov 25 04:13:37 UTC 2004
i686 GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../gcc/configure -v --enable-languages=c,c++
--prefix=/u/rcbilson/software/gcc --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug i486-linux
How-To-Repeat:
Compile the above code fragment using gcc -S.
--
Summary: __thread static class members
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rcbilson at plg dot uwaterloo dot ca
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19450
[Bug c/19449] __builtin_constant_p cannot resolve to const when optimizing
-- What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449
[Bug target/18987] [3.3/3.4 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-14 19:15 --- Subject: Bug 18987 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-01-14 19:15:41 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.c Log message: Patches to fix sibcall unwind info bugs. PR target/18987 * config/ia64/ia64.c (process_set): For alloc insn, only call process_epilogue is !frame_pointer_needed. PR target/13158 * config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on sibcall alloc instruction. (process_set): Handle sibcall alloc instruction. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1051r2=1.16114.2.1052 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.198.2.23r2=1.198.2.24 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug target/13158] [ia64] bad unwind info as a result of sibcall
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-14 19:15 --- Subject: Bug 13158 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-01-14 19:15:41 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.c Log message: Patches to fix sibcall unwind info bugs. PR target/18987 * config/ia64/ia64.c (process_set): For alloc insn, only call process_epilogue is !frame_pointer_needed. PR target/13158 * config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on sibcall alloc instruction. (process_set): Handle sibcall alloc instruction. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1051r2=1.16114.2.1052 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.198.2.23r2=1.198.2.24 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158
[Bug c/19449] __builtin_constant_p cannot resolve to const when optimizing
--- Additional Comments From eplondke at gmail dot com 2005-01-14 19:22 --- Created an attachment (id=7961) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7961action=view) Test case as a file. Test case as a file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449
[Bug c/19449] __builtin_constant_p cannot resolve to const when optimizing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 19:26 --- The problem is the __builtin_constant_p is delayed for evalutation until optimizations are run but __builtin_choose_expr needs an answer right away. What we could do is for when processing the first argument of __builtin_choose_expr, say we are not in a function. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|i686-pc-cygwin | GCC host triplet|i686-pc-cygwin | GCC target triplet|arm-unknown-elf | Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-01-14 19:26:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449
[Bug c++/19450] __thread static class members
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14 19:31 --- It does not work with 20041211 but that is the last gcc which I have access to which has __thread support. -- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19450
[Bug c++/19437] wrong warning when assigning negative value to int
--- Additional Comments From schlie at comcast dot net 2005-01-14 19:40
---
(In reply to comment #3)
int val = i ? i : -1;
we convert it to unsigned because it gets promoted to unsigned because i is
unsigned and then
there is an implicit cast to int. so the type of i ? i : -1 is unsigned and
there is an implicit cast to int.
Then either the semantic definition of the middle-end's w = (x ? y : z) needs
to preserve y : z types,
or it can not be considered equilvelent to if(x){ w = y; w = z;}, it would seem?
which would seem fine, if the middle-end trasformed:
w = (x ? y : z) = w = (x ? (max y z)y : (max y z)z)
internallly, or something like that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19437
[Bug target/13158] [ia64] bad unwind info as a result of sibcall
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-14 19:45 --- Subject: Bug 13158 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-14 19:45:23 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/ia64: ia64.exp sibcall-unwind-1.c sibcall-unwind-2.c Log message: Testcases for sibcall unwind info problems. PR target/13158 * gcc.target/ia64/sibcall-unwind-1.c: New test. PR target/18987 * gcc.target/ia64/sibcall-unwind-2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4885r2=1.4886 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/ia64.exp.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/sibcall-unwind-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/sibcall-unwind-2.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158
[Bug target/18987] [3.3/3.4 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-14 19:45 --- Subject: Bug 18987 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-14 19:45:23 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/ia64: ia64.exp sibcall-unwind-1.c sibcall-unwind-2.c Log message: Testcases for sibcall unwind info problems. PR target/13158 * gcc.target/ia64/sibcall-unwind-1.c: New test. PR target/18987 * gcc.target/ia64/sibcall-unwind-2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4885r2=1.4886 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/ia64.exp.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/sibcall-unwind-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/sibcall-unwind-2.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug c++/19437] wrong warning when assigning negative value to int
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-14
19:50 ---
(In reply to comment #4)
Then either the semantic definition of the middle-end's w = (x ? y : z) needs
to preserve y : z types,
or it can not be considered equilvelent to if(x){ w = y; w = z;}, it would
seem?
The middle-end here has nothing to do with it, this is all C/C++ standard
behavior and nothing else.
look the C standard does not talk about =?: but only the types of ?: and =
separately. unsigned is
higher in the promotion than signed int which is where the warning comes from
and the type of the
whole expression (a?i:j) is unsigned because that the lowest type which both
can be promoted to.
then there is an explicate cast from unsigned to int because we are assigning
to an int.
This again has nothing to do with the middle-end and just the rules in C/C++ of
how to deal with the
different type objects in the ?:.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19437
[Bug target/13158] [ia64] bad unwind info as a result of sibcall
--- Additional Comments From wilson at gcc dot gnu dot org 2005-01-14 19:51 --- Fixed on mainline, gcc-3.4, and gcc-3.3. Testcase added to mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158
[Bug target/18987] [3.3/3.4 regression] [ia64] Extra '.restore sp' in tail call
-- Bug 18987 depends on bug 13158, which changed state. Bug 13158 Summary: [ia64] bad unwind info as a result of sibcall http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug target/18987] [3.3/3.4 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From wilson at gcc dot gnu dot org 2005-01-14 19:52 --- Fixed on mainline, gcc-3.4 branch, and gcc-3.3 branch. Testcase added to mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug fortran/19451] New: Some read and write confusion with a read-only file
$ cat open+write.f90 program main character(len=10) a call system(rm -f asdf.dat; touch asdf.dat; chmod u-w asdf.dat) open(file=asdf.dat,unit=10,err=999,action=read) write(10,*,err=20) Hello, world print *,write to read-only file succeeded call abort 20 continue ! rewind(10) read(10,'(A)',end=30,err=999) a print *,read from empty file succeeded call abort 999 continue print *,error reading from read-only file call abort 30 continue print *,Success! end $ gfortran open+write.f90 $ ./a.out error reading from read-only file Aborted Uncommenting the rewind statement leads to $ ./a.out read from empty file succeeded Aborted $ gfortran -v ; gfortran -dumpmachine Using built-in specs. Configured with: ../gcc-4.0-20050109/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20050109 (experimental) ia64-unknown-linux-gnu -- Summary: Some read and write confusion with a read-only file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19451
[Bug libfortran/19451] Some read and write confusion with a read-only file
-- What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19451
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From yanliu at ca dot ibm dot com 2005-01-14 20:10 --- You are right, I was using linux and darwin two different compilers. In thse two situations, the gcc results are both right. I have another question for you for the same testcase: if initializing the bitfield with 1, and the bitwidth=17. I got two different layouts for the bitfield member with different g++ compilers: Both compilers are ppc-rhat. One is 3.4.3, the other is 3.2.3. Here is the first compiler's info: Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- infodir=/usr/share/info --enable-shared --enable-threads=posix --disable- checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind- exceptions --enable-languages=c,c++,objc,java,f77 --enable-java-awt=gtk -- host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux - -with-cpu=default32 Thread model: posix gcc version 3.4.3 20041125 (Red Hat 3.4.3-6.EL4) Running the testcase, here is what I got: with g++3.2.3, the result is: Dumping array with size of 4 Character 0 is 0 Character 1 is 1 Character 2 is 0 Character 3 is 0 c1.m1=1, With 3.4.3 g++ compiler, the result is: Dumping array with size of 4 Character 0 is 1 Character 1 is 0 Character 2 is 0 Character 3 is 0 c1.m1=1, The Itanium C++ ABI didn't specify how to layout bitfield member if their width exceeds its type. Did you put your least-important bit at the left hand side? Could you tell me your algorithm on the bitfield member layout? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug middle-end/18089] [4.0 regression] Valgrind errors in real.c
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-14 20:20 --- BTW, if I replace all subl$-2147483648, %eax instructions in real.s by: xorl$-2147483648, %eax (note that all such instructions are followed either by shrl, or addl, so any differences in %eflags are ignored), it shuts valgrind up as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18089
[Bug c++/19445] 50 fold compile time increase between gcc-3,4 and gcc-4,0 on included code
--- Additional Comments From phil at fsel dot com 2005-01-14 20:29 --- Subject: Re: 50 fold compile time increase between gcc-3,4 and gcc-4,0 on included code On Fri, Jan 14, 2005 at 05:02:48PM -, pinskia at gcc dot gnu dot org wrote: Can you check with --disable-checking as checking is turned on by default on the mainline of 4.0.0. Not as bad, but still pretty awful: $ /scribble/phil/gcc/install/bin/g++ -v Using built-in specs. Configured with: ../gcc/configure --prefix=/scribble/phil/gcc/install --disable-checking --enable-languages=c++ Thread model: posix gcc version 4.0.0 20050114 (experimental) $ time /scribble/phil/gcc/install/bin/g++ -O -c list1.cpp real0m1.758s user0m1.677s sys 0m0.035s $ time gcc-3.4 -O -c list1.cpp real0m0.101s user0m0.069s sys 0m0.009s cheers, Phil -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19445
[Bug middle-end/18089] [4.0 regression] Valgrind errors in real.c
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-14 20:36
---
To prove this is a valgrind bug and not GCC bug, I wrote a small self-contained
testcase on which valgrind complains:
#define EXP_BITS (32 - 5)
struct real_value
{
unsigned int cl : 2;
unsigned int sign : 1;
unsigned int signalling : 1;
unsigned int canonical : 1;
unsigned int uexp : EXP_BITS;
unsigned long sig[4];
};
#if defined __i386__ defined USE_ASM
#define REAL_EXP(REAL) \
({ int ret; \
__asm (movl (%%eax),%%eax; subl $0x8000,%%eax; shrl $5, %%eax; subl
$0x400,%%eax \
: =a (ret) : a (REAL), m (*(REAL))); \
ret; })
#else
#define REAL_EXP(REAL) \
((int)((REAL)-uexp ^ (unsigned int)(1 (EXP_BITS - 1))) \
- (1 (EXP_BITS - 1)))
#endif
#if __GNUC__ = 3
#define __noinline __attribute ((noinline))
#else
#define __noinline
#endif
int dummy;
void __noinline
bar (void)
{
++dummy;
}
void __noinline
foo (struct real_value *r)
{
if (REAL_EXP (r) = 5)
bar ();
}
int
main (void)
{
struct real_value r;
r.uexp = 0x21;
foo (r);
return 0;
}
Both with -DUSE_ASM and without CVS GCC generates the same assembly and in both
cases valgrind --tool=memcheck /tmp/test fails with:
==31022== Conditional jump or move depends on uninitialised value(s)
==31022==at 0x8048368: foo (test.c:41)
==31022==by 0x80483A4: main (test.c:50)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18089
[Bug java/19444] GCJ implementation of java.net.URI misses host support
--- Additional Comments From konqueror at gmx dot de 2005-01-14 20:50 --- I'm working on it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |konqueror at gmx dot de |dot org | Status|NEW |ASSIGNED Component|libgcj |java http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19444
