[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From stevenb at suse dot de 2005-03-06 09:30 --- Subject: Re: [meta-bug] optimizations that CSE still catches On Sunday 06 March 2005 06:59, law at redhat dot com wrote: Ah. Yes. What did it look like in the tree dumps? Unless one of the expanders is creating the negation I would think this would be pretty easy to catch in fold-const.c This is PR20130. We don't fold -1*x to -x, ie. we never fold the MULT_EXPR to a NEGATE_EXPR. PR20130 has a patch. expand_mult? Sigh. That's been in the back of my mind for a couple years now -- it's probably one of the largest RTL expanders which needs to have a lot of its functionality moved into trees. That'd be nice. In this case, Roger found out that for DImode negative constants it completely bypasses expand_mult_const. Fixing that would help for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug c++/20340] New: __always_inline__ fails on templetized function for no reason
Compiling code below (g++ -O5 -c) fails with the error message below.
This is the major source of performance loss since it leaves silly functions
like this called zillions of times w/out inlining.
Any workaround ?
Yuri
code
templatetypename T __attribute__ ((__always_inline__)) T f(const T j) { return
(j); }
int x(int j) {
int r;
r = f(j);
return (r);
}
error message
i.C:2: sorry, unimplemented: inlining failed in call to 'T f(T) [with T = int]':
function not inlinable
i.C:6: sorry, unimplemented: called from here
--
Summary: __always_inline__ fails on templetized function for no
reason
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20340
[Bug c++/20341] New: [4.0?/4.1 Regression] Segfualt on valid C++ code (breaks Boost)
The attached preprocessed source triggers a segfault in 4.1 (and probably also 4.0) which totally breaks Boost.Serialization and other libraries. -- Summary: [4.0?/4.1 Regression] Segfualt on valid C++ code (breaks Boost) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: giovannibajo at libero dot it CC: gcc-bugs at gcc dot gnu dot org,mw_adtrap at yahoo dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20341
[Bug c++/20341] [4.0?/4.1 Regression] Segfualt on valid C++ code (breaks Boost)
--- Additional Comments From giovannibajo at libero dot it 2005-03-06 10:05 --- Created an attachment (id=8341) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8341action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20341
[Bug rtl-optimization/20342] New: [4.0/4.1 regression] ICE in spill_failure, at reload1.c:1872
--
/* { dg-do assemble { target x86_64-*-* } } */
/* { dg-options -O2 } */
typedef int vec __attribute__ ((vector_size (8)));
void foo (int j, vec r)
{
unsigned short *dst;
while (j--)
*dst = (unsigned long long) __builtin_ia32_por (r, (vec) 0LL);
}
--
gcc -S -O2 fbmmx1.c
fbmmx1.c: In function foo:
fbmmx1.c:14: error: unable to find a register to spill in class GENERAL_REGS
fbmmx1.c:14: error: this is the insn:
(insn:HI 31 27 33 2 (set (subreg:V2SI (reg:DI 1 dx [orig:72 D.1471 ] [72]) 0)
(reg:V2SI 29 mm0 [74])) 920 {*movv2si_internal_rex64} (nil)
(nil))
fbmmx1.c:14: internal compiler error: in spill_failure, at reload1.c:1872
--
Summary: [4.0/4.1 regression] ICE in spill_failure, at
reload1.c:1872
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20342
[Bug rtl-optimization/20342] [4.0/4.1 regression] ICE in spill_failure, at reload1.c:1872
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-03-06 10:15 --- similar program, but with -typedef int vec __attribute__ ((vector_size (8))); +typedef int vec __attribute__ ((mode(DI))); compiles fine with 3.4.4. -- What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.4 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20342
[Bug c++/20340] __always_inline__ fails on templetized function for no reason
--- Additional Comments From yuri at tsoft dot com 2005-03-06 10:45 --- actually this one is fixed in 4.0, problem though is that 4.0 isn't usable yet -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20340
[Bug c++/20343] New: __always_inline__ fails on STL templetized function
Another example of failed inlining, now also existent in 4.0 as of 2005-02-13:
When I tried to compile with -O5 -Dinline=__attribute__\(\(__always_inline__\)\)
I get the error message below.
Interestingly there's no inline word here, it must have been taken from some
global declaration ?
--- code from include/c++/4.0.0/bits/ostream.tcc ---
templatetypename _CharT, typename _Traits
basic_ostream_CharT, _Traits
basic_ostream_CharT, _Traits::
operator(__ostream_type (*__pf)(__ostream_type))
{
...
--- error message ---
xxx.h|39| sorry, unimplemented: called from here
--
Summary: __always_inline__ fails on STL templetized function
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug c++/20343] __always_inline__ fails on STL templetized function
--- Additional Comments From pcarlini at suse dot de 2005-03-06 11:39 --- I think this can be closed as duplicate of tree-optimization/3713. See also libstdc++/14078 for explanations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug c++/20343] __always_inline__ fails on STL templatized function
-- What|Removed |Added Summary|__always_inline__ fails on |__always_inline__ fails on |STL templetized function|STL templatized function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug ada/20344] New: [4.0/4.1 regression] gnat1: error: unrecognized command line option -fRTS=/tmp/rts
$ gnatmake --RTS=/tmp/rts test1.adb gcc -c --RTS=/tmp/rts test1.adb gnat1: error: unrecognized command line option -fRTS=/tmp/rts Note: This works for 4.0.0-20041123 and fails for 4.0.0-20041129 and newer. -- Summary: [4.0/4.1 regression] gnat1: error: unrecognized command line option -fRTS=/tmp/rts Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: berndtrog at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20344
[Bug ada/20344] [4.0/4.1 regression] gnat1: error: unrecognized command line option -fRTS=/tmp/rts
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-06 11:54 --- Confirmed, worked only by accident. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-06 11:54:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20344
[Bug ada/20344] [4.0/4.1 regression] gnat1: error: unrecognized command line option -fRTS=/tmp/rts
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-06 11:55 --- It should be fixed by the next push from AdaCore. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20344
[Bug ada/20344] [4.0/4.1 regression] gnat1: error: unrecognized command line option -fRTS=/tmp/rts
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-06 11:56 --- The change comes from: 2004-11-28 Matt Kraai [EMAIL PROTECTED] PR diagnostic/17594 * opts.c (find_opt): Require that the input match a switch exactly or that the switch take a joined option to be interpreted as a match for another language. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20344
[Bug c++/20345] New: Warning on forward declaration of class with __dllexport__
Forward-declaring a class with a __dllexport__ or __dllimport__
attribute elicits the warning
type attributes are honored only at type definition
even when the same attribute is repeated on the class definition.
Until recently, this usage was accepted with no diagnostic. An
option to inhibit this warning with '-Wall -Wextra' would be welcome,
at least on the ms windows platform (on other platforms, and for
other attributes, this usage may be uncommon or nonexistent).
Unlike the other cases considered in this patch:
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01004.html
here, the meaning is clear; the warning diagnoses only redundancy,
which the 'native' compiler for ms windows documents as permissible:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_using_dllimport_and_dllexport_in_c.2b2b.asp
| You can declare C++ classes with the dllimport or dllexport attribute.
Building a recent cvs snapshot of wxWidgets yields 33673 instances
of this warning with MinGW gcc-3.4.2, but only five other warnings.
One of that library's maintainers states that they added the
redundant declarations throughout because gcc-3.3 required them in
some cases.
How to reproduce:
C:/tmp[0]$cat export_fwd_decl.cpp
class __attribute__((__dllexport__)) E;
class __attribute__((__dllimport__)) I;
class __attribute__((__dllexport__)) E {};
class __attribute__((__dllimport__)) I {};
C:/tmp[0]$/MinGW/bin/g++ -v -save-temps -Wall -Wextra -c export_fwd_decl.cpp
Reading specs from /MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
/MinGW/bin/../libexec/gcc/mingw32/3.4.2/cc1plus.exe -E -quiet -v -iprefix \MinG
W\bin\../lib/gcc/mingw32/3.4.2/ export_fwd_decl.cpp -Wall -Wextra -o export_fwd_
decl.ii
ignoring nonexistent directory /MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../
mingw32/include
ignoring nonexistent directory /mingw/lib/gcc/mingw32/3.4.2/../../../../mingw32
/include
#include ... search starts here:
#include ... search starts here:
/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2
/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/mingw32
/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/backward
/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include
/MinGW/bin/../lib/gcc/mingw32/3.4.2/include
/mingw/lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2
/mingw/lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/mingw32
/mingw/lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/backward
/mingw/lib/gcc/mingw32/3.4.2/../../../../include
/mingw/include
/mingw/lib/gcc/mingw32/3.4.2/include
/mingw/include
End of search list.
/MinGW/bin/../libexec/gcc/mingw32/3.4.2/cc1plus.exe -fpreprocessed export_fwd_d
ecl.ii -quiet -dumpbase export_fwd_decl.cpp -auxbase export_fwd_decl -Wall -Wext
ra -version -o export_fwd_decl.s
GNU C++ version 3.4.2 (mingw-special) (mingw32)
compiled by GNU C version 3.4.2 (mingw-special).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130943
export_fwd_decl.cpp:1: warning: type attributes are honored only at type definit
ion
export_fwd_decl.cpp:2: warning: type attributes are honored only at type definit
ion
/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/bin/as.exe -o export_fw
d_decl.o export_fwd_decl.s
C:/tmp[0]$cat export_fwd_decl.i*
# 1 export_fwd_decl.cpp
# 1 built-in
# 1 command line
# 1 export_fwd_decl.cpp
class __attribute__((__dllexport__)) E;
class __attribute__((__dllimport__)) I;
class __attribute__((__dllexport__)) E {};
class __attribute__((__dllimport__)) I {};
--
Summary: Warning on forward declaration of class with
__dllexport__
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chicares at cox dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20345
[Bug rtl-optimization/20342] [4.0/4.1 regression] ICE in spill_failure, at reload1.c:1872
--- Additional Comments From giovannibajo at libero dot it 2005-03-06 12:13 --- this might be a fallout of rth's cleanups. -- What|Removed |Added CC||rth at gcc dot gnu dot org Version|4.1.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20342
[Bug c++/20346] New: valid code fails: include of #define inside extern C
~/gcc4build/bin/g++ -v -c t1.cc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0-20050220/configure --prefix=/home/joseph/gcc4build --enable-languages=c,c++ Thread model: posix gcc version 4.0.0 20050220 (experimental) /home/joseph/gcc4build/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -quiet -v -D_GNU_SOURCE t1.cc -quiet -dumpbase t1.cc -mtune=pentiumpro -auxbase t1 -version -o /tmp/ccRZG0ew.s ignoring nonexistent directory /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0 /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward /usr/local/include /home/joseph/gcc4build/include /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/include /usr/include End of search list. GNU C++ version 4.0.0 20050220 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 3.4.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 t1.cc:5: error: expected initializer before const Compilation exited abnormally with code 1 at Mon Mar 7 01:12:06 -- Summary: valid code fails: include of #define inside extern C Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pepster at users dot sourceforge dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: 4.0.0 20050220 (experimental) GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20346
[Bug c++/20346] valid code fails: include of #define inside extern C
--- Additional Comments From pepster at users dot sourceforge dot net 2005-03-06 12:18 --- Created an attachment (id=8342) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8342action=view) source for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20346
[Bug c++/20346] valid code fails: include of #define inside extern C
--- Additional Comments From pepster at users dot sourceforge dot net 2005-03-06 12:18 --- Created an attachment (id=8343) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8343action=view) source for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20346
[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux
--- Additional Comments From christian dot joensson at gmail dot com 2005-03-06 12:30 --- Laurent Guerby suggested I use this in the gcc/ada/Makefile.in: ifeq ($(strip $(filter-out sparc% linux%,$(arch) $(osys))),) LIBGNAT_TARGET_PAIRS = \ a-intnam.adsa-intnam-linux.ads \ s-inmaop.adbs-inmaop-posix.adb \ s-intman.adbs-intman-posix.adb \ s-osinte.adbs-osinte-posix.adb \ s-osinte.adss-osinte-linux.ads \ s-osprim.adbs-osprim-posix.adb \ s-taprop.adbs-taprop-linux.adb \ s-taspri.adss-taspri-linux.ads \ s-tpopsp.adbs-tpopsp-posix-foreign.adb \ s-parame.adbs-parame-linux.adb \ system.adssystem-linux-sparc.ads TOOLS_TARGET_PAIRS = \ mlib-tgt.adbmlib-tgt-linux.adb \ indepsw.adbindepsw-linux.adb THREADSLIB = -lpthread GNATLIB_SHARED = gnatlib-shared-dual GMEM_LIB = gmemlib PREFIX_OBJS = $(PREFIX_REAL_OBJS) LIBRARY_VERSION := $(LIB_VERSION) endif I also would like to have sparc64 in like this... Looking at the section that starts with ifeq ($(strip $(filter-out sparc sun solaris%,$(targ))),) I see quite a few things I'd like to see also ifeq ($(strip $(filter-out fsu FSU,$(THREAD_KIND))),) ifeq ($(strip $(filter-out pthread PTHREAD,$(THREAD_KIND))),) (or something similar, nptl maybe?) ifeq ($(strip $(filter-out m64,$(THREAD_KIND))),) (definately this too) Furthermore, as per Laurent's suggestion, the Tick in the first two attachments should rather be Tick : constant := 0.000_001; instead of Tick : constant := 0.01; Last, there's a line length error, line 8 in both attachments is two chars too long -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035
[Bug c++/20346] valid code fails: include of #define inside extern C
--- Additional Comments From schwab at suse dot de 2005-03-06 12:30 --- This is invalid code, uint is not defined as a type. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet| 4.0.0 20050220 |4.0.0 20050220 |(experimental) |(experimental) Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20346
[Bug c++/20347] New: Long paths in error messages
This is a request for simplification of error messages, not a bug report.
Consider the following incorrect program, which generates an error
from inside the STL :
--
#include algorithm
struct A {};
A a[10];
int main() {
std::find(a, a+10, a[1]);
return 0;
}
--
The error message is :
--
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:
In function '_RandomAccessIterator std::find(_RandomAccessIterator,
_RandomAccessIterator, const _Tp, std::random_access_iterator_tag) [with
_RandomAccessIterator = A*, _Tp = A]':
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:315:
instantiated from '_InputIterator std::find(_InputIterator, _InputIterator,
const _Tp) [with _InputIterator = A*, _Tp = A]'
long_error_message.C:7: instantiated from here
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:207:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:211:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:215:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:219:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:227:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:231:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:235:
error: no match for 'operator==' in '* __first == __val'
---
Notice the useless substring lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../.
So my request is : would it be possible to simplify these paths
in disgnostic messages ?
--
Summary: Long paths in error messages
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20347
[Bug rtl-optimization/20342] [4.0/4.1 regression] ICE in spill_failure, at reload1.c:1872
-- What|Removed |Added Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20342
[Bug c++/20346] valid code fails: include of #define inside extern C
--- Additional Comments From pepster at users dot sourceforge dot net 2005-03-06 13:05 --- Sorry. Ignore. Reporting real bug soon ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20346
[Bug preprocessor/20348] New: File not included when file with same name is included before
Source submitted as attachment ~/gcc4build/bin/gcc -v -I. -Iinc1 -E t1.cc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0-20050220/configure --prefix=/home/joseph/gcc4build --enable-languages=c,c++ Thread model: posix gcc version 4.0.0 20050220 (experimental) /home/joseph/gcc4build/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -E -quiet -v -I. -Iinc1 -D_GNU_SOURCE t1.cc -mtune=pentiumpro ignoring nonexistent directory /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: . inc1 /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0 /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward /usr/local/include /home/joseph/gcc4build/include /home/joseph/gcc4build/lib/gcc/i686-pc-linux-gnu/4.0.0/include /usr/include End of search list. # 1 t1.cc # 1 built-in # 1 command line # 1 t1.cc # 1 inc1/h2.h 1 # 1 inc1/h1.h 1 # 1 inc1/h2.h 2 # 2 t1.cc 2 # 1 inc1/h1.h 1 # 5 t1.cc 2 Compilation finished at Mon Mar 7 02:06:36 -- Summary: File not included when file with same name is included before Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pepster at users dot sourceforge dot net CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20348
[Bug preprocessor/20348] File not included when file with same name is included before
--- Additional Comments From pepster at users dot sourceforge dot net 2005-03-06 13:09 --- Created an attachment (id=8344) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8344action=view) setup for recreating bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20348
[Bug other/18675] 6 * local variables set but never used
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-06 13:22 --- Kazu, you've been fixing a lot of this sort of thing lately, are any of the problems mentioned in this PR still present? -- What|Removed |Added CC||kazu at cs dot umass dot ||edu, jsm28 at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18675
[Bug other/18675] 6 * local variables set but never used
--- Additional Comments From kazu at cs dot umass dot edu 2005-03-06 14:15 --- cfg.c(821): remark #593: variable num_bb_notes was set but never used Confirmed this in cfghooks.c:verify_flow_info on mainline. loop-unswitch.c(326): remark #593: variable src was set but never used Confirmed this in loop-unswitch.c:unswitch_loop on mainline. cfgrtl.c(1870): remark #593: variable last_bb_seen was set but never used Confirmed this cfgrtl.c:rtl_verify_flow_info_1 on mainline. cse.c(207): remark #593: variable max_reg was set but never used I removed this a while ago. expr.c(7414): remark #593: variable quo was set but never used This is gone on mainline. function.c(7936): remark #593: variable i was set but never used I cannot find this on mainline. Probably gone. I'll take care of these. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18675
[Bug target/20342] [4.0/4.1 regression] ICE in spill_failure, at reload1.c:1872
-- What|Removed |Added Component|rtl-optimization|target Keywords||ssemmx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20342
[Bug c++/20340] __always_inline__ fails on templetized function for no reason
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:10 --- *** This bug has been marked as a duplicate of 14950 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20340
[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:10 --- *** Bug 20340 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:12 --- There is no preprocessed source here or even a source? Could you read http://gcc.gnu.org/bugs.html and attach the needed information? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug c++/20186] [4.0/4.1 regression] ICE with static_cast and type dependent variable (templates)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:17 --- *** Bug 20341 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20186
[Bug c++/20341] [4.0?/4.1 Regression] Segfualt on valid C++ code (breaks Boost)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:17 --- Reduces to PR 20186's reduction. Also looks to be the same preprocessed source. *** This bug has been marked as a duplicate of 20186 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20341
[Bug c++/20347] Long paths in error messages
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:26 --- Just a note that this is actually the include patch which is embeded into gcc so there is a reason for ../ ../ because there could be symbolic links involved. -- What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20347
[Bug preprocessor/20348] [4.0/4.1 Regression] File not included when file with same name is included before
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:34 --- Confirmed. There is some caching going wrong here. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-03-06 15:34:10 date|| Summary|File not included when file |[4.0/4.1 Regression] File |with same name is included |not included when file with |before |same name is included before Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20348
[Bug rtl-optimization/17752] Hot/cold basic block partitioning optimization has problems
-- What|Removed |Added Last reconfirmed|2004-09-30 17:42:47 |2005-03-06 15:37:17 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17752
[Bug libstdc++/16371] libstdc++ fails for crosses
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:40 --- No feedback in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371
[Bug libstdc++/16651] [3.4/4.0 Regression] cross from powerpc-darwin to i686-darwin fails
-- Bug 16651 depends on bug 16371, which changed state. Bug 16371 Summary: libstdc++ fails for crosses http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371 What|Old Value |New Value Status|NEW |WAITING Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16651
[Bug other/16838] libiberty link test vs. GCC_NO_EXECUTABLES problem during sun cross
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 15:40 --- No feedback in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16838
[Bug ada/17701] Can't crosscompile ada to armv5tel
--- Additional Comments From nick at sqrt dot co dot uk 2005-03-06 15:51 --- This is a longstanding bug that still occurs for the 4.0 branch. For ARM change: Integer'Min (2, Standard'Maximum_Alignment); to: Integer'Min (4, Standard'Maximum_Alignment); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17701
[Bug treelang/20326] treelang does install the backend as a driver
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-06 16:02 --- Subject: Bug 20326 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-06 16:02:41 Modified files: gcc/treelang : ChangeLog Make-lang.in Added files: gcc/treelang : spec.c Log message: 2005-03-06 James A. Morrison [EMAIL PROTECTED] PR other/20326 * Make-lang.in (gtreelang, treelang/spec.o): New targets. * spec.c: New file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/treelang/spec.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/treelang/ChangeLog.diff?cvsroot=gccr1=1.114r2=1.115 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/treelang/Make-lang.in.diff?cvsroot=gccr1=1.51r2=1.52 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20326
[Bug ada/17701] Can't crosscompile ada to armv5tel
--- Additional Comments From laurent at guerby dot net 2005-03-06 16:21 --- On possible solution for your target is to add in your target ada/Makefile.in LIBGNAT_TARGET_PAIRS = \ ... s-auxdec.adss-auxdec-arm.ads \ ... And commit s-auxdec-arm.ads with your change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17701
[Bug treelang/20326] treelang does install the backend as a driver
--- Additional Comments From phython at gcc dot gnu dot org 2005-03-06 16:34 --- Fixed, in mainline, I'll backport this later. -- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20326
[Bug fortran/20335] ICE with attached Fortran source
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-06 16:37 --- Does this happen with an up-to-date gfortran? I've just fixed the UBOUND intrinsic a few days ago. I'm also adding Steve to CC because he confirmed the bug, and I'm sure he has an up-to-date compiler lying around. -- What|Removed |Added CC||tobi at gcc dot gnu dot org, ||kargl at gcc dot gnu dot org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20335
[Bug fortran/20335] ICE with attached Fortran source
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-06 16:39 --- Oh, forgot to say: I'm not seeing any problems with an up-to-date compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20335
[Bug fortran/20335] ICE with attached Fortran source
--- Additional Comments From phillip dot m dot jordan at gmail dot com 2005-03-06 16:45 --- I'm downloading gfortran-4.0-20050305 right now, will report back when it's downloaded and built. (will take a few hours, sorry) Thanks for looking at the problem. ~phil -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20335
[Bug c++/19311] [3.4/4.0 Regression] ICE in resolve_overloaded_unification
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-06 16:59 --- Subject: Bug 19311 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-03-06 16:59:19 Modified files: gcc/cp : ChangeLog init.c pt.c typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: non-dependent11.C Log message: PR c++/19311 * init.c (build_offset_ref): Don't build non-dependent SCOPE_REF. * pt.c (build_non_dependent_expr): Don't build NON_DEPENDENT_EXPR for OFFSET_TYPE. * typeck.c (build_x_unary_op): Don't build non-dependent SCOPE_REF. Also set PTRMEM_OK_P for NON_DEPENDENT_EXPR. (build_unary_op): Handle building ADDR_EXPR of OFFSET_REF inside template. * g++.dg/template/non-dependent11.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.203r2=1.3892.2.204 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.356.2.15r2=1.356.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.816.2.51r2=1.816.2.52 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.519.2.22r2=1.519.2.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.368r2=1.3389.2.369 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent11.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
[Bug fortran/20335] ICE with attached Fortran source
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-03-06 17:00 --- Subject: Re: ICE with attached Fortran source On Sun, Mar 06, 2005 at 04:37:26PM -, tobi at gcc dot gnu dot org wrote: --- Additional Comments From tobi at gcc dot gnu dot org 2005-03-06 16:37 --- Does this happen with an up-to-date gfortran? I've just fixed the UBOUND intrinsic a few days ago. I'm also adding Steve to CC because he confirmed the bug, and I'm sure he has an up-to-date compiler lying around. It is indeed fixed, here. I must have tested the code with an older version of gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20335
[Bug c++/19311] [3.4/4.0 Regression] ICE in resolve_overloaded_unification
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-06 17:12 --- Subject: Bug 19311 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-06 17:12:12 Modified files: gcc/cp : ChangeLog init.c pt.c typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: non-dependent11.C Log message: PR c++/19311 * init.c (build_offset_ref): Don't build non-dependent SCOPE_REF. * pt.c (build_non_dependent_expr): Don't build NON_DEPENDENT_EXPR for OFFSET_TYPE. * typeck.c (build_x_unary_op): Don't build non-dependent SCOPE_REF. Also set PTRMEM_OK_P for NON_DEPENDENT_EXPR. (build_unary_op): Handle building ADDR_EXPR of OFFSET_REF inside template. * g++.dg/template/non-dependent11.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.4648.2.3r2=1.4648.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.412r2=1.412.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.978r2=1.978.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.616r2=1.616.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.19r2=1.5084.2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/non-dependent11.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
[Bug c++/19311] [3.4/4.0 Regression] ICE in resolve_overloaded_unification
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-06 17:16 --- Fixed in 3.4 and 4.0 branches. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-06 18:02
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
Alexandre Oliva wrote:
+case TARGET_EXPR:
+ {
+ tree r = tsubst_copy (t, args, complain, in_decl);
+
+ TREE_TYPE (r) = RECUR (TREE_TYPE (t));
+ TARGET_EXPR_SLOT (r) = RECUR (TARGET_EXPR_SLOT (t));
+ TARGET_EXPR_INITIAL (r) = RECUR (TARGET_EXPR_INITIAL (t));
+ TARGET_EXPR_CLEANUP (r) = RECUR (TARGET_EXPR_CLEANUP (t));
+
+ if (TREE_TYPE (TARGET_EXPR_SLOT (t))
+ == TREE_TYPE (TARGET_EXPR_INITIAL (t)))
+ TREE_TYPE (TARGET_EXPR_SLOT (r)) =
+ TREE_TYPE (TARGET_EXPR_INITIAL (r));
+
+ if (TREE_TYPE (t) == TREE_TYPE (TARGET_EXPR_SLOT (t)))
+ TREE_TYPE (r) = TREE_TYPE (TARGET_EXPR_SLOT (r));
+
+ return r;
This doesn't look quite right. First, we're trying to get rid of
tsubst_copy; we should not add new calls. You should do the RECURs
here, and then build up the new node. And, the manipulations of
TREE_TYPE don't make sense: (a) using == to compare types is almost
always wrong, and (b) the RECURs should already maintain the invariant
you're trying to maintain.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From yuri at tsoft dot com 2005-03-06 18:10 ---
Sorry about this, this appears to be more complex to reporduce than I thought.
Compile the following with the options:
-O5 -Dinline=__attribute__\(\(__always_inline__\)\)
to see the error message.
(gcc 4.0 cvs updeted on 2005-02-13 and compiled with default options)
What's strange is that error is only generated when both vector and cout
endl; parts are there
Yuri
--- code ---
#include iostream
#include vector
using namespace std;
int main() {
vectorint v;
v.resize(100);
v[10] = atoi(5);
cout endl;
return (10);
}
-- error ---
/usr/local/gcc-4.0-20050213/lib/gcc/i386-unknown-freebsd5.3/4.0.0/../../../../include/c++/4.0.0/bits/ostream.tcc:67:
sorry,unimplemented: inlining failed in call to 'std::basic_ostream_CharT,
_Traits std::basic_ostream_CharT,
_Traits::operator(std::basic_ostream_CharT, _Traits
(*)(std::basic_ostream_CharT, _Traits)) [with _CharT = char, _Traits =
std::char_traitschar]': function not inlinable
m.C:9: sorry, unimplemented: called from here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 18:16 --- Actually this is not a bug. You need to define inline as inline __attribute__((always_inline)). -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug fortran/18525] ICE on valid code in gfc_get_symbol_decl()
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-06 18:10 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-03/msg00091.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-02-16 03:45:17 |2005-03-06 18:10:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18525
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From pcarlini at suse dot de 2005-03-06 18:18 --- In anyone paying attention to my comment #1 ? This is a *known issue*, basically we cannot inline currently pointers to functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 18:21 --- (In reply to comment #5) In anyone paying attention to my comment #1 ? This is a *known issue*, basically we cannot inline currently pointers to functions. Yes but his definition of inline is incorrect as inline in C++ also changes the linkage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug fortran/20335] ICE with attached Fortran source
--- Additional Comments From phillip dot m dot jordan at gmail dot com 2005-03-06 18:33 --- Just tested with the 20050305 snapshot, and it works perfectly. Thanks! ~phil -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20335
[Bug fortran/20335] ICE with attached Fortran source
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20335
[Bug target/19336] HPPA64 does not support TImode
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-06 18:49 --- The tests have now been changed not to try to use TImode if __hppa__. However, support for TImode would still make sense as a feature on HPPA64 (in which case titype-1.c and uninit-C.c should be changed back). Retitling bug as a request for this feature. -- What|Removed |Added CC||jsm28 at gcc dot gnu dot org Summary|FAIL: gcc.dg/titype-1.c |HPPA64 does not support ||TImode http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19336
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From yuri at tsoft dot com 2005-03-06 19:37 --- You need to define inline as inline __attribute__((always_inline)) Did this, same error message. In my project I NEED to specify explicitely inlining of the functions. Including STL since vector::operator[] or similar is being called zillion times even when very aggressive gcc inlining options are set. Regular inlining decisions are not enough for me since I see performance gains with any new inline of functio in the performance path. I understand this causes code explosion -- it's ok w/in the current limits. So to solve the problem with vector::operator[] and similar I use __attribute__((always_inline)) but it fails. How can I solve the problem than ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug libgcj/20155] [4.0 Regression] libgcj build fails with execvp: /bin/sh: Argument list too long
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-06 19:48 --- Subject: Bug 20155 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-06 19:48:18 Modified files: libjava: ChangeLog Makefile.am Makefile.in Log message: PR libgcj/20155 * Makefile.am (libgcj0_convenience.la): Revert last change. * Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3397r2=1.3398 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.am.diff?cvsroot=gccr1=1.456r2=1.457 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.in.diff?cvsroot=gccr1=1.487r2=1.488 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From pcarlini at suse dot de 2005-03-06 19:49 --- The error message that you are seeing is triggered by 'std::endl', a manipulator in standard terms, that cannot currently inlined. I have trouble believing that the performance bottleneck of your application is 'std::endl'... Just change it for '\n' and flush only when really needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug libgcj/20155] [4.0/4.1 Regression] libgcj build fails with execvp: /bin/sh: Argument list too long
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 19:50 --- The patch had to be reverted. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.0 Regression] libgcj |[4.0/4.1 Regression] libgcj |build fails with execvp: |build fails with execvp: |/bin/sh: Argument list too |/bin/sh: Argument list too |long |long http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155
[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR
-- Bug 17574 depends on bug 20155, which changed state. Bug 20155 Summary: [4.0/4.1 Regression] libgcj build fails with execvp: /bin/sh: Argument list too long http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17574
[Bug tree-optimization/17671] PHI-OPT is not smart enough
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 19:52 --- Patch for 4.1.0 was posted here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00548.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17671
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From law at redhat dot com 2005-03-06 19:56 --- Subject: Re: [meta-bug] optimizations that CSE still catches On Sun, 2005-03-06 at 09:30 +, stevenb at suse dot de wrote: --- Additional Comments From stevenb at suse dot de 2005-03-06 09:30 --- Subject: Re: [meta-bug] optimizations that CSE still catches On Sunday 06 March 2005 06:59, law at redhat dot com wrote: Ah. Yes. What did it look like in the tree dumps? Unless one of the expanders is creating the negation I would think this would be pretty easy to catch in fold-const.c This is PR20130. We don't fold -1*x to -x, ie. we never fold the MULT_EXPR to a NEGATE_EXPR. PR20130 has a patch. Ok. That should be pretty easy to fix. expand_mult? Sigh. That's been in the back of my mind for a couple years now -- it's probably one of the largest RTL expanders which needs to have a lot of its functionality moved into trees. That'd be nice. In this case, Roger found out that for DImode negative constants it completely bypasses expand_mult_const. Fixing that would help for now. expand_mult, expand_divmod and the switch expanders are the biggies IMHO. One of the tricks with the mult and divmod expanders is precisely when should we expand them into their component operations. We clearly don't want to do it at the very start or the very end of hte SSA path, but somewhere in the middle. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug libgcj/20155] [4.0/4.1 Regression] libgcj build fails with execvp: /bin/sh: Argument list too long
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-06 20:15 --- Subject: Bug 20155 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-06 20:15:23 Modified files: libjava: ChangeLog Makefile.am Makefile.in Log message: PR libgcj/20155 * Makefile.am (libgcj0_convenience.la): Revert last change. * Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3391.2.2r2=1.3391.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.am.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.455.2.1r2=1.455.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.485.2.1r2=1.485.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155
[Bug other/20349] New: [multilib] libjava(32) doesn't build.
(...) make[5]: Entering directory `/home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/amd64-pld-linux/32/libjava' depbase=`echo prims.lo | sed 's|[^/]*$|.deps/|;s|\.lo$||'`; \ if /bin/sh ./libtool --mode=compile /home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/gcc/xgcc -shared-libgcc -B/home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/gcc/ -nostdinc++ -L/home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/amd64-pld-linux/32/libstdc++-v3/src -L/home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/amd64-pld-linux/32/libstdc++-v3/src/.libs -B/usr/amd64-pld-linux/bin/ -B/usr/amd64-pld-linux/lib/ -isystem /usr/amd64-pld-linux/include -isystem /usr/amd64-pld-linux/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../libjava -I./include -I./gcj -I../../../../libjava -Iinclude -I../../../../libjava/include -I../../../../libjava/../boehm-gc/include -I../boehm-gc/include -I../../../../libjava/libltdl -I../../../../libjava/libltdl -I../../../../libjava/.././libjava/../gcc -I../../../../libjava/../zlib -I../../../../libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr\ -DLIBDIR=\/usr/lib64\ -DBOOT_CLASS_PATH=\/usr/share/java/libgcj-4.0.0.jar\ -DJAVA_EXT_DIRS=\/usr/share/java/ext\ -O2 -D_GNU_SOURCE -m32 -MT prims.lo -MD -MP -MF $depbase.Tpo -c -o prims.lo ../../../../libjava/prims.cc; \ then mv -f $depbase.Tpo $depbase.Plo; else rm -f $depbase.Tpo; exit 1; fi mkdir .libs /home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/gcc/xgcc -shared-libgcc -B/home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/gcc/ -nostdinc++ -L/home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/amd64-pld-linux/32/libstdc++-v3/src -L/home/users/pluto/rpm/BUILD/gcc-4.0-20050305/obj-amd64-pld-linux/amd64-pld-linux/32/libstdc++-v3/src/.libs -B/usr/amd64-pld-linux/bin/ -B/usr/amd64-pld-linux/lib/ -isystem /usr/amd64-pld-linux/include -isystem /usr/amd64-pld-linux/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../libjava -I./include -I./gcj -I../../../../libjava -Iinclude -I../../../../libjava/include -I../../../../libjava/../boehm-gc/include -I../boehm-gc/include -I../../../../libjava/libltdl -I../../../../libjava/libltdl -I../../../../libjava/.././libjava/../gcc -I../../../../libjava/../zlib -I../../../../libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr\ -DLIBDIR=\/usr/lib64\ -DBOOT_CLASS_PATH=\/usr/share/java/libgcj-4.0.0.jar\ -DJAVA_EXT_DIRS=\/usr/share/java/ext\ -O2 -D_GNU_SOURCE -m32 -MT prims.lo -MD -MP -MF .deps/prims.Tpo -c ../../../../libjava/prims.cc -fPIC -DPIC -o .libs/prims.o ../../../../libjava/java/lang/Object.h:23: warning: 'struct _JvObjectPrefix' has virtual functions but non-virtual destructor ../../../../libjava/java/lang/Object.h:42: warning: 'class java::lang::Object' has virtual functions but non-virtual destructor ../../../../libjava/gcj/array.h:19: warning: 'class __JArray' has virtual functions but non-virtual destructor ../../../../libjava/gcj/array.h: In instantiation of 'JArrayjchar': ../../../../libjava/gcj/array.h:90: instantiated from here ../../../../libjava/gcj/array.h:42: warning: 'class JArrayjchar' has virtual functions but non-virtual destructor ../../../../libjava/gcj/array.h: In instantiation of 'JArrayjboolean': ../../../../libjava/gcj/array.h:96: instantiated from here ../../../../libjava/gcj/array.h:42: warning: 'class JArrayjboolean' has virtual functions but non-virtual destructor ../../../../libjava/gcj/array.h: In instantiation of 'JArrayjbyte': ../../../../libjava/gcj/array.h:102: instantiated from here ../../../../libjava/gcj/array.h:42: warning: 'class JArrayjbyte' has virtual functions but non-virtual destructor ../../../../libjava/gcj/array.h: In instantiation of 'JArrayjshort': ../../../../libjava/gcj/array.h:108: instantiated from here ../../../../libjava/gcj/array.h:42: warning: 'class JArrayjshort' has virtual functions but non-virtual destructor ../../../../libjava/gcj/array.h: In instantiation of 'JArrayjint': ../../../../libjava/gcj/array.h:114: instantiated from here ../../../../libjava/gcj/array.h:42: warning: 'class JArrayjint' has virtual functions but non-virtual destructor ../../../../libjava/gcj/array.h: In instantiation of 'JArrayjlong': ../../../../libjava/gcj/array.h:120: instantiated from here ../../../../libjava/gcj/array.h:42: warning: 'class JArrayjlong' has virtual functions but non-virtual destructor ../../../../libjava/gcj/array.h: In instantiation of
[Bug other/20349] [multilib] libjava(32) doesn't build.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 20:23 --- Can you try again? I think this was caused by the patch for PR 20155 which had to be reverted. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20349
[Bug tree-optimization/20130] Fold a * -1 - 1 into ~a;
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |phython at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-02-21 23:35:04 |2005-03-06 21:16:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20130
[Bug ada/4945] Rewriting '-gant' as '-gnat' is failing
--- Additional Comments From bangerth at dealii dot org 2005-03-06 21:37 --- I think the whole idea of second-guessing what a user might have meant when he misspelled an option is debatable. I personally am of the opinion that this should yield an error or a warning, but that we shouldn't attempt to figure out what she might have meant instead. But that's only by 2 cents... W. -- What|Removed |Added Summary|Rewriting '-gant' as '-gnat'|Rewriting '-gant' as '-gnat' |is failings |is failing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4945
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-06 21:50 --- Subject: Bug 20288 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-06 21:50:37 Modified files: gcc: ChangeLog gcc/config/avr : avr.c avr.md Log message: PR target/20288 * config/avr/avr.c (print_operand): Add 'p' and 'r'. (out_movhi_r_mr): Read low byte of volatile MEM first. (out_movhi_mr_r): Write high byte of volatile MEM first. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7691r2=2.7692 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gccr1=1.129r2=1.130 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.md.diff?cvsroot=gccr1=1.49r2=1.50 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-06 22:14 --- Just to give people an idea of how close we are to optimizing well enough that the calls to fold_rtx in CSE are almost all no-ops, here are some numbers taken over all cc1-i files on amd64: Number of times fold_rtx is called: 13882333 Number of times it returns something other than the incoming rtx x: 70001 Number of times fold_rtx is called by other functions than itself: 9323647 Number of times it returns something other than x: 8526 A few rtxes that fold_rtx handles: Loads from constant pool: Trying to fold rtx: (float_extend:DF (mem/u/i:SF (symbol_ref/u:DI (*.LC0) [flags 0x2]) [2 S4 A32])) Trying to fold rtx: (mem/u/i:SF (symbol_ref/u:DI (*.LC0) [flags 0x2]) [2 S4 A32]) Trying to fold rtx: (symbol_ref/u:DI (*.LC0) [flags 0x2]) Returning X unchanged. Returning new rtx: (const_double:SF 1.0e+0 [0x0.8p+1]) Returning new rtx: (const_double:DF 1.0e+0 [0x0.8p+1]) Folded jumps: Trying to fold rtx: (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0x0])) (label_ref 73) (pc)) Trying to fold rtx: (pc) Returning X unchanged. Trying to fold rtx: (eq (reg:CCZ 17 flags) (const_int 0 [0x0])) Trying to fold rtx: (reg:SI 66 [ D.10402 ]) Returning X unchanged. Trying to fold rtx: (const_int 4 [0x4]) Returning X unchanged. Returning new rtx: (const_int 1 [0x1]) Returning new rtx: (label_ref 73) Apparently an equivalent expression with lower cost: Trying to fold rtx: (plus:QI (subreg:QI (reg:SI 251) 0) (subreg:QI (reg:SI 251) 0)) Trying to fold rtx: (subreg:QI (reg:SI 251) 0) Trying to fold rtx: (reg:SI 251) Returning X unchanged. Returning X unchanged. Trying to fold rtx: (subreg:QI (reg:SI 251) 0) Trying to fold rtx: (reg:SI 251) Returning X unchanged. Returning X unchanged. Returning new rtx: (ashift:QI (subreg:QI (reg:SI 251) 0) (const_int 1 [0x1])) Likewise: Trying to fold rtx: (mult:DI (reg:DI 63 [ variable.comb_vect.length ]) (const_int 4 [0x4])) Returning new rtx: (ashift:DI (reg:DI 63 [ variable.comb_vect.length ]) (const_int 2 [0x2])) It'd be interesting to find out how many of these things combine and later CSE passes would catch (or miss), and the tree-cleanup-branch compares. I will look at the latter first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug c++/20350] New: 4.0 and higher: ICE
/usr/local/gcc-cvs-4.1/libexec/gcc/i686-redhat-linux/4.1.0/cc1plus -fpreprocessed threading.ii -quiet -dumpbase threading.cc -mtune=pentiumpro -auxbase-strip .libs/libcwd_r_la-threading.o -g -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings -Werror -version -fno-exceptions -fno-exceptions -fPIC -o threading.s GNU C++ version 4.1.0 20050306 (experimental) (i686-redhat-linux) compiled by GNU C version 4.1.0 20050306 (experimental). GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113285 ../libcwd/threading.cc:704: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. threading.ii.bz2 is attached. -- Summary: 4.0 and higher: ICE Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlo at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-redhat-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug c++/20350] 4.0 and higher: ICE
--- Additional Comments From carlo at gcc dot gnu dot org 2005-03-06 22:33 --- Created an attachment (id=8345) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8345action=view) bzip2-ed preprocessed source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug java/20351] New: compilation with a redundant jar fails, if output file specified
This specifies a sub-bug of 18212. The test-case is simple, not the severity!
Given are 2 independet(!) and (almost) empty classes: A1 and A2. A1 has the
main() method. A1 is in jar J1, A2 in jar J2.
The bug: Compiling the jar J1 by giving the output file by -o fails, when
compiled with J2.
failing:
gcj -o foo --classpath=J2.jar:. --main=A1 J1.jar J2.jar
gcj -o foo --classpath=J2.jar:J1.jar --main=A1 J1.jar J2.jar
working:
gcj -o foo --main=A1 J1.jar J2.jar
gcj -o foo --classpath=J2.jar:. --main=A1 J1.jar
gcj -o foo --main=A1 J1.jar
gcj --classpath=J2.jar:. --main=A1 J1.jar J2.jar
gcj --classpath=J2.jar:. --main=A1 J1.jar
gcj --main=A1 J1.jar J2.jar
gcj --main=A1 J1.jar
When failing, it reports:
java/awt/Component.java: In class `java.awt.Component':
java/awt/Component.java: In method `java.awt.Component.eventTypeEnabled(int)':
java/awt/Component.java:4127: error: expected type 'int' but stack contains
'void'
java/awt/Component.java:4127: error: verification error at PC=311
java/awt/Component.java:4127: error: types could not be merged
ObjectInputStream.java: In class `java.io.ObjectInputStream$3':
ObjectInputStream.java: In method
`java.io.ObjectInputStream$3.getField(java.lang.String,java.lang.Class)':
ObjectInputStream.java:1257: error: verification error at PC=45
ObjectInputStream.java:1257: error: loading local variable 6 which has unknown
type
java/lang/Class.java:0: confused by earlier errors, bailing out
The source codes:
1) A1.java
public class A1 {
public static void main(String args[]) {
}
}
2) A2.java:
public class A2 {
}
--
Summary: compilation with a redundant jar fails, if output file
specified
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bojan at antonovic dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351
[Bug java/20351] compilation with a redundant jar fails, if output file specified
--- Additional Comments From bojan at antonovic dot com 2005-03-06 22:43 --- Created an attachment (id=8346) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8346action=view) jar with class A1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351
[Bug java/20351] compilation with a redundant jar fails, if output file specified
--- Additional Comments From bojan at antonovic dot com 2005-03-06 22:44 --- Created an attachment (id=8347) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8347action=view) jar with class A2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351
[Bug java/20351] compilation with a redundant jar fails, if output file specified
-- What|Removed |Added OtherBugsDependingO||18212 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351
[Bug libstdc++/20352] New: FAIL: 26_numerics/complex/pow.cc execution test
Executing on host: /xxx/gnu/gcc-3.3/objdir/gcc/g++ -shared-libgcc -B/xxx/gnu/gcc -3.3/objdir/gcc/ -nostdinc++ -L/xxx/gnu/gcc-3.3/objdir/hppa1.1-hp-hpux10.20/libs tdc++-v3/src -L/xxx/gnu/gcc-3.3/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/src/.li bs -B/opt/gnu/gcc/gcc-4.0.0/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.0.0/h ppa1.1-hp-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.0.0/hppa1.1-hp-hpux10.20/in clude -isystem /opt/gnu/gcc/gcc-4.0.0/hppa1.1-hp-hpux10.20/sys-include -g -O2 -D _GLIBCXX_ASSERT -fmessage-length=0 -DLOCALEDIR=/xxx/gnu/gcc-3.3/objdir/hppa1.1- hp-hpux10.20/libstdc++-v3/po/share/locale -nostdinc++ -I/xxx/gnu/gcc-3.3/objdir /hppa1.1-hp-hpux10.20/libstdc++-v3/include/hppa1.1-hp-hpux10.20 -I/xxx/gnu/gcc-3 .3/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/include -I/xxx/gnu/gcc-3.3/gcc/libst dc++-v3/libsupc++ -I/xxx/gnu/gcc-3.3/gcc/libstdc++-v3/include/backward -I/xxx/gn u/gcc-3.3/gcc/libstdc++-v3/testsuite /xxx/gnu/gcc-3.3/gcc/libstdc++-v3/testsuite /26_numerics/complex/pow.cc-include bits/stdc++.h -L/xxx/gnu/gcc-3.3/objdir /hppa1.1-hp-hpux10.20/./libstdc++-v3/testsuite -lv3test -lm -o ./pow.exe(t imeout = 600) PASS: 26_numerics/complex/pow.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/xxx/gnu/gcc-3.3/objdir/gcc:/xxx/gnu/gcc-3.3/objdir/ hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs::/xxx/gnu/gcc-3.3/objdir/gcc:/xxx/ gnu/gcc-3.3/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs Assertion failed: pow(z, 1.0/3.0) == 0.0, file /xxx/gnu/gcc-3.3/gcc/libstdc++-v3 /testsuite/26_numerics/complex/pow.cc, line 13 FAIL: 26_numerics/complex/pow.cc execution test We seem to have a NAN returned from the call to _ZSt3powIdESt7complexIT_ERKS2_RKS1_: 0xfd7c main+68: b,l 0xfb88 _ZSt3powIdESt7complexIT_ERKS2_RKS1_,rp 0xfd80 main+72: fstd fr23,-8(sr0,r3) 0xfd84 main+76: fldd 0(sr0,r4),fr22 0xfd88 main+80: fcmp,dbl,!= fr22,fr0, Breakpoint 1, 0xfd88 in main () (gdb) info reg fr22 fr22(single precision) NaN(0x74) fr22(double precision) NaN(0x4) -- Summary: FAIL: 26_numerics/complex/pow.cc execution test Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
[Bug java/20351] compilation with a redundant jar fails, if output file specified
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 22:52 --- Compiling two jars at the same time is known to be broken. -- What|Removed |Added Severity|critical|normal Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351
[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test
--- Additional Comments From danglin at gcc dot gnu dot org 2005-03-06 22:52 --- This fail also occurs on 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
[Bug middle-end/20249] [4.0/4.1 Regression] ICE with -fprofile-arcs on ppc
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-03-06 23:05 --- This seems to be a cse problem. The code looks like (set (reg:si 124) (reg:si 5)) ... (set (reg:si 5) (reg:si 124)) ... (set (reg:di 119) (reg:di 5)) ... (set (reg:di 3) (reg:di 119)) cse propagates the value of reg:si 5 to the last insn (set (reg:di 3) (reg:si 5)) Which is incorrect since the hard reg is accessed in a different mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20249
[Bug c++/20350] 4.0 and higher: ICE
--- Additional Comments From carlo at gcc dot gnu dot org 2005-03-06 23:20 --- Created an attachment (id=8348) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8348action=view) Same, but without PCH. Sorry, the previous one was compiled with pch. This one is without PCH. -- What|Removed |Added Attachment #8345 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug libfortran/19568] incorrect formatted read
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-06 23:34 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00566.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
[Bug libfortran/20131] gfortan - incorrectly reads beyond the end of line.
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-06 23:34 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00566.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
[Bug c/20353] New: GCC incorrectly issues calls to sinf, cosf
When optimizing, GCC converts calls to cos() and sin() (and probably others,
these were the ones I saw) into calls to cosf() and sinf() when cos() and sin()
are called with a float argument. The problem with this is that neither
libgcc nor uClibc provide cosf and sinf! The bug can be worked around by
passing -fno-builtin-cos and -fno-builtin-sin.
The trivial code:
extern double cos(double);
float do_cos(float f)
{ return cos(f); }
Produces this assembly code output:
.file test.c
.text
.align 2
.global do_cos
.type do_cos, %function
do_cos:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
b cosf
.size do_cos, .-do_cos
.ident GCC: (GNU) 3.4.2
When run as arm-linux-gcc -S -O2 test.c
Output of arm-linux-gcc -v:
Reading specs from
/home/jonathan/workspace/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir/bin-ccache/../lib/gcc/arm-linux-uclibc/3.4.2/specs
Configured with:
/home/jonathan/workspace/gumstix/gumstix-buildroot/toolchain_build_arm_nofpu/gcc-3.4.2/configure
--prefix=/home/jonathan/workspace/gumstix/gumstix-buildroot/build_arm_nofpu/staging_dir
--build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc
--enable-languages=c,c++ --enable-shared --disable-__cxa_atexit
--enable-target-optspace --with-gnu-ld --disable-nls --with-float=soft
--enable-sjlj-exceptions
Thread model: posix
gcc version 3.4.2
--
Summary: GCC incorrectly issues calls to sinf, cosf
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jbrandmeyer at earthlink dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: arm-linux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20353
[Bug c++/20350] [4.0/4.1 Regression] extern template and struct initializer and specification for a static variable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06
23:49 ---
Confirmed, reduced testcase:
struct a { int i, j; };
template int i struct mutex_tct { static a S_mutex; };
template int i a mutex_tcti::S_mutex = {0,1};
template extern a mutex_tct0::S_mutex;
template a mutex_tct0::S_mutex = {0,1};
void g() { mutex_tct0::S_mutex.i = 0; }
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|normal |critical
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-03-06 23:49:41
date||
Summary|4.0 and higher: ICE |[4.0/4.1 Regression] extern
||template and struct
||initializer and
||specification for a static
||variable
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug c++/20350] [4.0/4.1 Regression] extern template and struct initializer and specification for a static variable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 23:51 --- It worked with 4.0.0 20041124 so it is semi new. -- What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug target/20353] uclibc does not provide C99 math functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 23:54 --- Note Linux defaults to being glibc which implies that it has C99 math functions, really uclibc really should have a different configure file if it does not have C99 functions. Well technicially it should provide them anyways as they are required by the C99 standard. -- What|Removed |Added Severity|normal |minor Component|c |target Summary|GCC incorrectly issues calls|uclibc does not provide C99 |to sinf, cosf |math functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20353
[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test
--- Additional Comments From pcarlini at suse dot de 2005-03-06 23:55 --- The implementation of complex::pow can be definitely improved, and will, as soon as Roger's work on signbit goes in, still, this issue seems limited to some very specific, old version of hpux, pre release 11, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
[Bug target/20288] AVR assignment of a value through a 16 bit pointer generates out of order code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 23:55 --- Fixed so closing. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
[Bug c++/20350] [4.0/4.1 Regression] extern template and struct initializer and specification for a static variable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-06 23:58 --- This even works with 4.0.0 20050113 but fails with 4.0.0 20050201 more prove that this is very recent regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-03-07 00:06 --- Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test The implementation of complex::pow can be definitely improved, and will, as soon as Roger's work on signbit goes in, still, this issue seems limited to some very specific, old version of hpux, pre release 11, right? Yes, this test doesn't fail on hpux 11. This probably implies a hpux 10 math library issue. I see the following math routines are called log, atan2, exp, cos and sin in that order. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test
--- Additional Comments From pcarlini at suse dot de 2005-03-07 00:14 --- Yes, this test doesn't fail on hpux 11. This probably implies a hpux 10 math library issue. I see the following math routines are called log, atan2, exp, cos and sin in that order. Indeed, I was thinking the very same thing. I would check first whether log(x) == -inf for x == 0+. Then, whether exp(-inf) == 0+. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
[Bug target/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-03-07 00:20 --- I've traced what's going on: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00525.html It includes a patch for comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20331
[Bug java/18212] nativ compilation with multiple jars fails / gives internal compiler error
--- Additional Comments From bojan at antonovic dot com 2005-03-07 00:59 --- The part of the bug that produces the ICE (bus error) can be reproduced by extracting and compiling all classes from a single jar. Unzip all classes from SMOOD.jar by unzip -l SMOOD.jar and then compile with gcj -o smood.exe --main=smood.Main smood/Main.class smood/*/*.class smood/*/*/*.class smood/*/*/*/*.class gives smood/Main.class:0: internal compiler error: Bus error This ICE is not yet reproducable with other jars or with less files. However, because bug 18212 can be splitted to bug 20351 and an other possible new one, it can be soon removed as duplicate of two known bugs, as soon the one for the ICE is found. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18212
[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-03-07 01:31 --- Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test We have log(x) == -inf for x == 0+. The exp call is returning 0+ but the argument isn't -inf. It's -5.9923104495410517e+307. -inf is -1.7976931348623157e+308. Sorry, log(x) == -HUGE_VALUE for x == 0+, not -INFINITY. This is also the documented behavior for hpux11. The HP log function doesn't set ERANGE when x is 0. SUSV2 also specifies -HUGE_VALE and that ERANGE may be set. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test
--- Additional Comments From pcarlini at suse dot de 2005-03-07 01:32 --- We have log(x) == -inf for x == 0+. The exp call is returning 0+ but the argument isn't -inf. It's -5.9923104495410517e+307. -inf is -1.7976931348623157e+308. Interesting. Therefore, 1/3*(-inf) instead of giving the very same -inf, as should happen in IEEE, gives 1/3*(-1.79769..e+308)! Still, this cannot explain the NaN, because, then, the involved exp can only be slighlty bigger than zero... The only other tricky bit of the computation seems atan2(0.0, 0.0) which should be also zero, of course. Then those two zeros (the latter mult be 1/3) are passed to complex::polar which only computes sin and cos, always defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
