[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-29 08:01 --- I thought if we know that we are looking at the loop header copy condition that we _know_ that the loop runs at least once, so we can avoid trying to prove that again using fold. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug tree-optimization/26667] Inlining always_inline functions causes further inlining that reduces function size to fail
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-29 08:05 --- I'm unable to produce a testcase where we "regress" from 4.0 or earlier, so closing as fixed in 4.2.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.1.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26667
[Bug target/26879] LibJava not compile under alpha
--- Comment #3 from zerocool at modemsoft dot it 2006-03-29 08:17 --- Premising that I have unloaded the last available snapshots on the site and that is: gcc-4.2-20060325.tar.bz2,gcc-4.1-20060324.tar.bz2,gcc-4.0-20060323.tar.bz2 Well i make two test yesterday with this result : First report with gcc-4.2-20060325.tar.bz2(using the same option of up and without patches : ../../../../../gcc-4.2-20060325/libjava/classpath/gnu/CORBA/CDR/gnuRuntime.java:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. ../../../../../gcc-4.2-20060325/libjava/classpath/gnu/CORBA/DynAn/gnuDynValueBox.java:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [lists/gnu-CORBA-CDR.stamp] Error 1 make[5]: *** Waiting for unfinished jobs make[5]: *** [lists/gnu-CORBA-DynAn.stamp] Error 1 Second report with gcc-4.0-20060323.tar.bz2(using the same option of up and without patches : ../../gcc-4.0-20060323/libjava/external/sax -d /gcc-85576838fabc7583ebcbc70479ee4e79/gcc.build.lnx/alpha-alphaslack-linux/libjava \ -MD -MF gnu/awt.deps @gnu/awt.list ../../../gcc-4.0-20060323/libjava/gnu/awt/LightweightRedirector.java:0: internal compiler error: Segmentation fault Please submit a full bug report,with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [gnu/awt.stamp]Error 1 make[2]: *** Waiting for unfinished jobs Now i try with snapshot of gcc41 and later i tell you the result. Waiting always news or well a patches for correct the problem. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-03-29 09:01 --- Subject: Re: Number of iterations not know for simple loop > I thought if we know that we are looking at the loop header copy condition > that > we _know_ that the loop runs at least once, so we can avoid trying to prove > that again using fold. How? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug c++/26913] New: ICE with -fopenmp and -O2
I get a ICE in g++ for the following code when compiled with -fopenmp and -O2:
#include
int foo()
{
int x1;
#pragma omp parallel
{
for (int i = 0; i < 5; ++i) {
std::string xxx;
}
}
return 0;
}
Note that this is not exactly bug 26823, since the function name where the ICE
occurs is not printed. I tried to replace std::string with something else, but
then the ICE disappears. This is with svn from yesterday: g++-4.2 (GCC) 4.2.0
20060328 (experimental)
--
Summary: ICE with -fopenmp and -O2
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Georg dot Baum at post dot rwth-aachen dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26913
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-03-29 09:11 --- Subject: Re: Number of iterations not know for simple loop > > I thought if we know that we are looking at the loop header copy condition > > that > > we _know_ that the loop runs at least once, so we can avoid trying to prove > > that again using fold. > > How? Sorry for the dumb question, I now understand what you mean. Let me think about this for a moment, please. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug c++/26912] [4.0/4.1/4.2 Regression] friend const member function specialization fails to compile
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 09:32 ---
Confirmed.
struct Foo {
template int func() ;
};
class Bar {
friend int Foo::func() const ; // line 6
};
is also invalidly accepted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||accepts-invalid, rejects-
||valid
Known to fail||3.3.5 4.0.3 4.1.0 4.2.0
Known to work||3.4.6
Last reconfirmed|-00-00 00:00:00 |2006-03-29 09:32:16
date||
Summary|friend const member function|[4.0/4.1/4.2 Regression]
|specialization fails to |friend const member function
|compile |specialization fails to
||compile
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26912
[Bug target/26879] LibJava not compile under alpha
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-03-29 10:06 --- It would be difficult for those of us without alpha-linux boxes to track this problem down. If you're willing, you can try to track the failure to a certain bit yourself. Let's stick with the GCC 4.2 snapshot as that's the latest and is likely to already contain many useful fixes. Looking at your build log, try to reproduce the failure yourself on the command line. That is, copy-paste the command-line compiling "gnuRuntime.java" and run it with your working directory set to the $BUILD_DIR/$TARGET/libjava folder, where $BUILD_DIR is the folder in which you are building GCC and $TARGET is the target you're building for (alpha-alphaslack-linux). Once you're able to reproduce this failure on the command-line, get a recent version of GDB and get the "debugx" and "debug" scripts from: http://gcc.gnu.org/ml/gcc/2004-03/msg01195.html Now run "debugx jc1 ", where "" was the entire command noted earlier that causes the failure. Within GDB, type "run" and when the segmentation fault occurs, type "list" and then "backtrace". This should give some useful information. More information can be found here: http://gcc.gnu.org/wiki/DebuggingGCC Good luck! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug other/26914] New: missed optimization / lack of conditional moves
flags: -O2 -ffast-math -march=i686 -fomit-frame-pointer
double signum_dbl_gcc( double x )
{
if ( x < 0.0 )
return -1.0;
if ( x > 0.0 )
return 1.0;
return 0.0;
}
.LC1: .long 3212836864
signum_dbl_gcc:
fldz
fldl4(%esp)
fcomip %st(1), %st
jb .L11
fld1
fcmovbe %st(1), %st
fstp%st(1)
ret
.L11: fstp%st(0)
flds.LC1
ret
int signum_int_gcc( int x )
{
if ( x < 0 )
return -1;
if ( x > 0 )
return 1;
return 0;
}
signum_int_gcc:
cmpl$0, 4(%esp)
movl$-1, %eax
jl .L15
setne %al
movzbl %al, %eax
.L15: ret
custom version without branches.
double signum_user_dbl( double x )
{
asm volatile
(
"fld1 \n\t"
"fchs \n\t"
"fld1 \n\t"
"fldz \n\t"
"fucomi %%st(3) \n\t"
"fcmovnbe %%st(2), %%st(0)\n\t"
"fcmovb %%st(1), %%st(0)\n\t"
"fstp %%st(1) \n\t"
"fstp %%st(1) \n\t"
"fstp %%st(1) \n\t"
: "=t" (x)
: "0" (x)
);
return x;
}
int signum_user_int( int x )
{
int retval;
asm volatile
(
"xor%%al, %%al \n\t"
"mov$-1, %%cl \n\t"
"mov$1, %%dl\n\t"
"cmp$0, %1 \n\t"
"cmovl %%ecx, %%eax\n\t"
"cmovg %%edx, %%eax\n\t"
"movsx %%al, %%eax \n\t"
: "=a" (retval)
: "m" (x)
);
return retval;
}
--
Summary: missed optimization / lack of conditional moves
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: i686-pld-linux
GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26914
[Bug target/26879] LibJava not compile under alpha
--- Comment #5 from zerocool at modemsoft dot it 2006-03-29 10:30 --- (In reply to comment #4) OK now i try this and after i tell you the resul, hoping in the lucky :-) Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug other/26915] New: missed optimization / returning -1.0
double minus1() { return -1.0; }
.LC0:.long 3212836864
minus1: flds.LC0
ret
for -Os gcc should use `fld1;fchs'.
--
Summary: missed optimization / returning -1.0
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: i686-pld-linux
GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26915
[Bug c++/26916] New: [4.1/4.2 Regression] template/overloaded function lookup
It seems that template function overloading/argument dependent lookup now
depends on declaration order. If this is right or not I don't know yet, but it
changed without notice. consider this small piece of code:
#include
#include
#include
template void add_field(T const & value) {
static int counter;
std::cout << "template \n";
if (++counter < 5) {// avoid crash!!
std::stringstream tmp;
tmp << value;
add_field(tmp.str());
} else {
std::cout << "would crash here \n";
}
}
// put this before the template and get desired behaviour
void add_field(std::string const &value) {
std::cout << "overload\n";
}
int main () {
add_field ( "value");
return 0;
}
on g++ < 4.1.0 (tested with 3.2.3, 3.3.2, 3.4.3 and 4.0.2) this program prints:
template
overload
while on 4.1.0 it prints
/a.out
template
template
template
template
template
template
would crash here
Changing the order of the two functions restores the old behaviour, but I'd say
this is a regression.
--
Summary: [4.1/4.2 Regression] template/overloaded function lookup
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Michael dot Teske at swissrisk dot com
GCC host triplet: i386-redhat-linux/sparc-sun-solaris2.8
GCC target triplet: i386-redhat-linux/sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26916
[Bug c++/26917] New: [4.0/4.1/4.2 regression] ICE with -frepo on invalid code
Compiling a valid C++ file with -frepo and then editing the file introducing bugs and then recompiling the file causes trouble: For example: Create the file "bug.cc" with the contents === int i; === Compile this file with "g++ -frepo -c bug.cc". Then change the file to === int ; === and recompile it with the same command. With mainline I get: bug.cc:1: error: declaration does not declare anything bug.cc:1: fatal error: error writing to /tmp/ccp9FkBp.s: Bad file descriptor compilation terminated. With the 4.1 branch I get: bug.cc:1: error: declaration does not declare anything g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. [etc.] With the 4.0 branch I get: bug.cc:1: error: declaration does not declare anything *** glibc detected *** malloc(): memory corruption: 0x2b106010 *** bug.cc:1: internal compiler error: Aborted Please submit a full bug report, [etc.] With GCC 3.4.6 everything works fine, though. Deleting the *.rpo file before recompiling solves the problem. -- Summary: [4.0/4.1/4.2 regression] ICE with -frepo on invalid code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26917
[Bug c++/26919] New: ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
The following piece of code causes an ICE at ipa-inline.c:106 as soon as
optimization is turned on. I can reproduce it using BOOST 1.32.0 and 1.33.1. It
used to work previously (at least as of GCC 3.4.3).
#include
#include
#include "boost/lambda/lambda.hpp"
#include "boost/lambda/bind.hpp"
struct Device {
Device();
static std::list* allDevices_;
voidinit();
static void initAll();
};
void
Device::initAll()
{
std::for_each( allDevices_->begin(), allDevices_->end(),
boost::lambda::bind( &Device::init, boost::lambda::_1 ) );
}
--
Summary: ICE in cgraph_estimate_size_after_inlining caused by
boost::lambda
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kreckel at ginac dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug fortran/26920] New: Cannot build using static libraries
When I try to build a program using static libraries, I get errors - [dranta:~/tests] dir% gfortran -o print print.f [dranta:~/tests] dir% gfortran -o print print.f -Wl,-static /usr/bin/ld: only one of -static or -dynamic can be specified [dranta:~/tests] dir% gfortran -static -o print print.f /usr/bin/ld: can't locate file for: -lcrt0.o collect2: ld returned 1 exit status [dranta:~/tests] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.5.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060328 (experimental) [dranta:~/tests] dir% -- Summary: Cannot build using static libraries Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26920
[Bug rtl-optimization/15187] Inefficient if optimization with -O2 -ffast-math
--- Comment #12 from uros at kss-loka dot si 2006-03-29 14:08 --- (In reply to comment #11) > it looks like 4.1.1 and 4.2.0 still produce unoptimal code. > test: pushl %ebp > movl%esp, %ebp > fldl8(%ebp) > fldz > fcomip %st(1), %st > jae .L2 > popl%ebp > fcos > ret > > .L2:popl%ebp > fsin > ret No, this code is optimal. Please compare the code above to the code in description, where fcos is calculated even if x <= 0.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15187
[Bug c++/26919] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 14:13 --- Can you attach preprocessed source please? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug c++/26916] [4.0/4.1/4.2 Regression] template/overloaded function lookup
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-29 14:19 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.3 4.1.0 4.2.0 Known to work||3.4.6 4.0.2 Last reconfirmed|-00-00 00:00:00 |2006-03-29 14:19:02 date|| Summary|[4.1/4.2 Regression]|[4.0/4.1/4.2 Regression] |template/overloaded function|template/overloaded function |lookup |lookup Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26916
[Bug c/26921] New: long long bit fields are passed to variadic functions as longs
When compiled under Linux, at least, gcc 3.2.3 appears to pass a long long bit
field to a variadic function as a long. In particular, if you say "printf
("%lld", s.a)", where s.a is a long long bit field, s.a appears to only pass a
long.
The resulting assembly reads (for a 3 bit long long field):
movbfoo, %al
sall$5, %eax
movb%al, %cl
sarb$5, %cl
movsbl %cl,%eax
cltd
pushl %eax
pushl $.LC0
callprintf
I do not believe this is correct behavior for gcc.
With -Wall, the above example generates a warning about the operation:
a.c: In function `main':
a.c:10: warning: long long int format, different type arg (arg 2)
I see similar behavior on gcc 4.0.0 on a Macintosh, but that's based on the
output produced by the executible, since I cannot read it's assembly.
Compiled using: gcc -Wall -v --save-temps a.c
--
Summary: long long bit fields are passed to variadic functions as
longs
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla at hburch dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
[Bug c/26921] long long bit fields are passed to variadic functions as longs
--- Comment #1 from bugzilla at hburch dot com 2006-03-29 14:54 --- Created an attachment (id=11150) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11150&action=view) Bundle for Linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
[Bug c/26921] long long bit fields are passed to variadic functions as longs
--- Comment #2 from bugzilla at hburch dot com 2006-03-29 14:54 --- Created an attachment (id=11151) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11151&action=view) Bundle for Mac OS X -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
[Bug c/26921] long long bit fields are passed to variadic functions as longs
--- Comment #3 from bugzilla at hburch dot com 2006-03-29 14:59 ---
#include
struct s {
long long int a : 33;
};
struct s foo = {0};
int main(void) {
printf ("%lld\n", foo.a);
return 0;
}
produces the following output using "gcc -Wall -o a a.c" for same system as Mac
OS X Bundle (gcc 4.0.0):
gcc -Wall -o a a.c
a.c: In function 'main':
a.c:10: warning: format '%lld' expects type 'long long int', but argument 2 has
type 'long long int'
Attached here because almost assuredly related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 15:12 --- The first time we lay out the type, we have the fields reversed. See parse.y:java_reorder_fields. I don't know why this happens. (We construct the field list in reverse order, presumably for efficiency. What is unclear is why the type can be laid out before the fields are correctly ordered.) In any case, on ppc32, the ordering of fields matters, because the class One can be packed more efficiently if 'b' comes first. Then what happens is that when we lay out Two$Three, the initial size of One is used to lay out the super class field. This field's size is not recomputed the second time we lay out Two$Three, yielding the incorrect result. One possible fix would be to reset the field sizes when we null out TYPE_SIZE in java_reorder_fields (and perhaps elsewhere). A better fix might be to remove the need for reordering fields. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit
--- Comment #9 from pbrook at gcc dot gnu dot org 2006-03-29 15:21 --- Subject: Bug 23623 Author: pbrook Date: Wed Mar 29 15:21:13 2006 New Revision: 112493 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112493 Log: 2006-03-29 Paul Brook <[EMAIL PROTECTED]> PR middle-end/23623 * targhooks.c (default_narrow_bitfield): New fuction. * targhooks.h (default_narrow_bitfield): add prototype. * target.h (gcc_target): Add narrow_volatile_bitfield. * target-def.h (TARGET_NARROW_VOLATILE_BITFIELD): Define. * stor-layout.c (get_best_mode): Use targetm.narrow_volatile_bitfield. * doc/tm.texi: Document TARGET_NARROW_VOLATILE_BITFIELDS. * config/arm/arm.c (TARGET_NARROW_VOLATILE_BITFIELD): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/doc/tm.texi trunk/gcc/stor-layout.c trunk/gcc/target-def.h trunk/gcc/target.h trunk/gcc/targhooks.c trunk/gcc/targhooks.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623
[Bug c++/26922] New: Compile/link failure with -frepo and g++ 4.1
Executable fails to compile with -frepo using g++ 4.1 g++ (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I'll attach the source code. The error is: main.o: In function `void std::__adjust_heap<__gnu_cxx::__normal_iterator > >, int, X*, XCompare>(__gnu_cxx::__normal_iterator > >, int, int, X*, XCompare)':main.cpp:(.text+0xfe): undefined reference to `void std::__push_heap<__gnu_cxx::__normal_iterator > >, int, X*, XCompare>(__gnu_cxx::__normal_iterator > >, int, int, X*, XCompare)' main.o: In function `void std::__introsort_loop<__gnu_cxx::__normal_iterator > >, int>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, int)':main.cpp:(.text+0x1ea): undefined reference to `__gnu_cxx::__normal_iterator > > std::__unguarded_partition<__gnu_cxx::__normal_iterator > >, X*>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, X*)' main.o: In function `void std::__introsort_loop<__gnu_cxx::__normal_iterator > >, int>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, int)':main.cpp:(.text+0x3f4): undefined reference to `__gnu_cxx::__normal_iterator > > std::__unguarded_partition<__gnu_cxx::__normal_iterator > >, X>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, X)' main.o: In function `void std::__final_insertion_sort<__gnu_cxx::__normal_iterator > > >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >)':main.cpp:(.text+0x4b5): undefined reference to `void std::__insertion_sort<__gnu_cxx::__normal_iterator > > >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >)' main.o: In function `void std::__adjust_heap<__gnu_cxx::__normal_iterator > >, int, X*, std::binary_negate >(__gnu_cxx::__normal_iterator > >, int, int, X*, std::binary_negate)':main.cpp:(.text+0x5d6): undefined reference to `void std::__push_heap<__gnu_cxx::__normal_iterator > >, int, X*, std::binary_negate >(__gnu_cxx::__normal_iterator > >, int, int, X*, std::binary_negate)' main.o: In function `void std::__introsort_loop<__gnu_cxx::__normal_iterator > >, int, XCompare>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, int, XCompare)':main.cpp:(.text+0xc80): undefined reference to `__gnu_cxx::__normal_iterator > > std::__unguarded_partition<__gnu_cxx::__normal_iterator > >, X*, XCompare>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, X*, XCompare)' main.o: In function `void std::__introsort_loop<__gnu_cxx::__normal_iterator > >, int, std::binary_negate >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, int, std::binary_negate)':main.cpp:(.text+0x1004): undefined reference to `__gnu_cxx::__normal_iterator > > std::__unguarded_partition<__gnu_cxx::__normal_iterator > >, X*, std::binary_negate >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, X*, std::binary_negate)' main.o: In function `void std::__introsort_loop<__gnu_cxx::__normal_iterator > >, int>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, int)':main.cpp:(.text+0x23f): undefined reference to `void std::partial_sort<__gnu_cxx::__normal_iterator > > >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >)' main.o: In function `void std::__introsort_loop<__gnu_cxx::__normal_iterator > >, int>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, int)':main.cpp:(.text+0x44f): undefined reference to `void std::partial_sort<__gnu_cxx::__normal_iterator > > >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >)' main.o: In function `void std::__final_insertion_sort<__gnu_cxx::__normal_iterator > > >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >)':main.cpp:(.text+0x53a): undefined reference to `void std::__insertion_sort<__gnu_cxx::__normal_iterator > > >(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >)' collect2: ld returned 1 exit status make: *** [ex31] Error 1 And no, I don't have a "vanilla" gcc 4.1 to test with. -- Summary: Compile/link failure with -frepo and g++ 4.1 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rankincj at yahoo dot com GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26922
[Bug c++/26919] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #2 from kreckel at ginac dot de 2006-03-29 15:36 --- Created an attachment (id=11152) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11152&action=view) program causing ICE preprocessed with -P -E I now see that this is not vanilla boost 1.33.1 but one which contains an enhanced tuple which can accomodate up to 32 elements. Anyway, the attached preprocessed file compiles fine with older versions of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug c++/26922] Compile/link failure with -frepo and g++ 4.1
--- Comment #1 from rankincj at yahoo dot com 2006-03-29 15:36 --- Created an attachment (id=11153) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11153&action=view) Source code to demonstrate -frepo failure. My host machine is a i686-pc-linux-gnu machine; g++-3.4.4 compiles this just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26922
[Bug c++/26913] ICE with -fopenmp and -O2
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-03-29 15:44
---
Confirmed.
Reduced testcase (compile with "g++ -fopenmp"):
===
struct A
{
~A() throw();
};
void foo(A);
A bar() throw();
void baz()
{
#pragma omp parallel
{ A a; foo(bar()); }
}
===
PR26913.cc: In function 'void _Z3bazv.omp_fn.0(void*)':
PR26913.cc:12: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Although this is a plain segfault in contrast to PR26823, I think the
two are related, since both have to do with exception handling:
If you get gid of "throw()" in the testcase above, the code compiles fine.
And the ICE in PR26823 happens in add_stmt_to_eh_region_fn.
While reducing to testcase above, I also came across error messages like
in PR26084/PR26076 (vector VEC(eh_region,base) index domain) - the
predecessors of PR26823.
Looks like we some major problem with exception handling here.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code,
||monitored, openmp
Last reconfirmed|-00-00 00:00:00 |2006-03-29 15:44:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26913
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-29 15:45 --- Created an attachment (id=11154) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11154&action=view) patch I have a simple patch for # iterations analysis to check whether either cond1 follows from cond2 or !cond1 follows from cond2. Patch is untested but fixes the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug c++/26919] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-29 16:05 --- Reducing. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-29 16:32 --- Subject: Bug 26390 Author: tromey Date: Wed Mar 29 16:31:53 2006 New Revision: 112499 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112499 Log: gcc/java PR java/26390: * parse.y (find_most_specific_methods_list): Added 'class' argument. (lookup_method_invoke): Updated. libjava PR java/26390: * testsuite/libjava.lang/pr26390.out: New file. * testsuite/libjava.lang/pr26390.java: New file. * sources.am, Makefile.in: Rebuilt. * scripts/makemake.tcl: Compile gnu/java/awt/peer/swing. Added: trunk/libjava/testsuite/libjava.lang/pr26390.java trunk/libjava/testsuite/libjava.lang/pr26390.out Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/parse.y trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/scripts/makemake.tcl trunk/libjava/sources.am -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug c/26923] New: byte swap incorrect
A peace of my code uses the two next macros (SWAP and InvSwap) to swap bytes,
it worked for a long time under gcc-3.3 but not under gcc-4.0.3
under gcc-3.3:
InvWord(0xABCD) = 0xCDAB
under gcc-4-0.3:
InvWord(0xABCD) = 0xCD00
FILE STARTS HERE ##
#define SWAP(x,y) (x)^=(y)^=(x)^=(y)
#define InvWord(x) SWAP(*((char *)(&(x))),*((char *)(&(x))+1))
int main()
{
unsigned short data_length;
data_length = 0xABCD;
InvWord(data_length);
return 0;
}
FILE ENDS HERE ###
I've also tried to use __bswap_16 but id did nothing :(
thanks in advance
--
Summary: byte swap incorrect
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: behloul dot younes at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26923
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-29 16:36 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug libgcj/26910] re-merging java.util.zip
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-29 16:44 --- Note that we need more mauve tests in this area before fixing the problem. The current tests don't catch the bug(s). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26910
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
-- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-31 03:16:33 |2006-03-29 16:52:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug c++/26919] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-29 17:03 --- Created an attachment (id=11155) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11155&action=view) Smaller testcase Will continue reducing if nobody beats me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug testsuite/20567] dg-options in gcc.c-torture
--- Comment #4 from janis at gcc dot gnu dot org 2006-03-29 17:12 --- The gfortran torture tests also need to support dg- options, starting with dg-final to allow cleaning up module files from the testsuite temporary directory. -- janis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-09 12:55:10 |2006-03-29 17:12:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567
[Bug tree-optimization/26859] [4.2 Regression] ICE Segmentation Fault
--- Comment #10 from spop at gcc dot gnu dot org 2006-03-29 17:20 --- Subject: Bug 26859 Author: spop Date: Wed Mar 29 17:20:24 2006 New Revision: 112502 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112502 Log: PR tree-optimization/26859 * tree-ssa-loop-niter.c (infer_loop_bounds_from_undefined): Avoid division by zero. (convert_step): Remove TREE_OVERFLOW and TREE_CONSTANT_OVERFLOW flags for the step after fold_convert. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug libstdc++/26733] move semantics vs. debug mode
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-29 17:40 --- Excellent job Paolo! Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit
--- Comment #10 from pbrook at gcc dot gnu dot org 2006-03-29 17:44 --- Should be fixed now. -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623
[Bug libgcj/9250] runtime should only use non-visible locks
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-29 17:52 --- I now agree with comment #4. I don't think this is a bug. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9250
[Bug libgcj/11780] Method.invoke() is slow
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-29 18:12 --- Things look even worse with svn head (4.2 atm)... either with gij or precompiled, the test case shows invocations about an order of magnitude slower than the JDK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11780
[Bug libgcj/9250] runtime should only use non-visible locks
--- Comment #6 from mark at gcc dot gnu dot org 2006-03-29 18:14 --- TYhis bug is now closed but I wanted to add the following link for the archives. A couple of these denial of service attacks by taking locks were in the examples of Sascha's GNU Classpath Security talk at Fosdem 2004: http://www.brawer.ch/articles/classpathSecurity/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9250
[Bug libstdc++/26926] New: double vs. long double libmath export confusion
While working on the long double 128 bits with Jakub, it was pointed out that some of the libmath work in libstdc++ is incorrect. In particular, platforms like ppc32 are doing some bogus exports. Mostly, this is because on certain platforms, sizeof(double) == sizeof(long double) and so, there is no need or desire for an underlying "C" math library call that works on long double. And there is certainly no need for a libstdc++ wrapper function that takes the existing double version, adds and l, and then casts the long double to double, and calls the double function. It's too late to fix this stuff up for so.6, but for so.7 we should correct the problem. Here's the pathology: baseline_symbols containing: FUNC:acosl@@GLIBCXX_3.4.3 FUNC:asinl@@GLIBCXX_3.4.3 FUNC:atan2l@@GLIBCXX_3.4 FUNC:atanl@@GLIBCXX_3.4.3 FUNC:ceill@@GLIBCXX_3.4.3 FUNC:coshl@@GLIBCXX_3.4 FUNC:cosl@@GLIBCXX_3.4 FUNC:expl@@GLIBCXX_3.4 FUNC:floorl@@GLIBCXX_3.4.3 FUNC:fmodl@@GLIBCXX_3.4.3 FUNC:frexpl@@GLIBCXX_3.4.3 FUNC:hypotl@@GLIBCXX_3.4 FUNC:ldexpl@@GLIBCXX_3.4.3 FUNC:log10l@@GLIBCXX_3.4 FUNC:logl@@GLIBCXX_3.4 FUNC:modfl@@GLIBCXX_3.4.3 FUNC:powl@@GLIBCXX_3.4 FUNC:sinhl@@GLIBCXX_3.4 FUNC:sinl@@GLIBCXX_3.4 FUNC:sqrtl@@GLIBCXX_3.4 FUNC:tanhl@@GLIBCXX_3.4 FUNC:tanl@@GLIBCXX_3.4 >From the looks of things, this means: %find . -type f -name baseline_symbols.txt | xargs grep acosl ./powerpc64-linux-gnu/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 ./powerpc64-linux-gnu/32/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 ./hppa-linux-gnu/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 ./alpha-linux-gnu/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 ./s390x-linux-gnu/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 ./mips-linux-gnu/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 ./powerpc-linux-gnu/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 ./sparc-linux-gnu/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 ./s390-linux-gnu/baseline_symbols.txt:FUNC:acosl@@GLIBCXX_3.4.3 -- Summary: double vs. long double libmath export confusion Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org GCC host triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26926
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #3 from quanah at stanford dot edu 2006-03-29 18:45 --- Actually, the problem has nothing to do with using /bin/sh, because I get the same failure using /bin/ksh, too: /bin/ksh ../../../../gcc-4.1.0/libgfortran/mk-srk-inc.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/ -B/usr/pubsw/sparc-sun-solaris2.9/bin/ -B/usr/pubsw/sparc-sun-solaris2.9/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.9/include -isystem /usr/pubsw/sparc-sun-solaris2.9/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > selected_real_kind.inc || rm selected_real_kind.inc /bin/ksh ../../../../gcc-4.1.0/libgfortran/mk-kinds-h.sh '/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/gfortran -B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/./gcc/ -B/usr/pubsw/sparc-sun-solaris2.9/bin/ -B/usr/pubsw/sparc-sun-solaris2.9/lib/ -isystem /usr/pubsw/sparc-sun-solaris2.9/include -isystem /usr/pubsw/sparc-sun-solaris2.9/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > kinds.h || rm kinds.h ../../../../gcc-4.1.0/libgfortran/mk-kinds-h.sh: Unknown type grep '^#' < kinds.h > kinds.inc /bin/ksh: kinds.h: cannot open make[3]: *** [kinds.inc] Error 1 make[3]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59/sparc-sun-solaris2.9/libgfortran' make[2]: *** [all-target-libgfortran] Error 2 make[2]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59' make[1]: *** [all] Error 2 make[1]: Leaving directory `/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_59' make: *** [bootstrap] Error 2 -- quanah at stanford dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug c/26923] byte swap incorrect
--- Comment #1 from pluto at agmk dot net 2006-03-29 18:51 --- It's not a gcc bug. The code relies on the results of intermediate subexpressions. According to Stroustrup, The C++ Programming Language, section 6.2.2, "The order of evaluation of subexpressions within an expression is undefined." You should use sequence points e.g.: a ^= b, b ^= a, a ^= b; This is a dup of PR11751 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26923
[Bug c/26927] New: math function log2 bug
Most likely this bug was reported before; but I couldn't seem to find it in
this database. So, just in case. The bug is with gcc 3.3.5; I know 3.4.4 works
fine.
=== test
#include
#include
int main() {
int g_size = 8;
int dim;
double dd;
dd = log2(g_size);
dim = (pow(2, (int)dd) >= g_size)?(int)dd : (int)dd + 1;
printf("log2(%d) = %.1f pow(2, (int)%d) >= %d = %d\n", g_size, dd,
(int)dd, g_size, (pow(2, (int)dd) >= g_size));
return 0;
}
compile & run
> gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs
Configured with:
/scratch/portage/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.5
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/info
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include/g++-v3
--host=i686-pc-linux-gnu --disable-altivec --disable-nls --enable-__cxa_atexit
--enable-clocale=gnu --with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--enable-java-awt=gtk --enable-languages=c,c++,f77,java
Thread model: posix
gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)
> gcc -lm test_math.c
> ./a.out
log2(8) = 1075199136.0 pow(2, (int)1075199136) >= 8 = 1
--
Summary: math function log2 bug
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bxin33 at gmail dot com
GCC build triplet: PIII + Gentoo Linux 2.6.11 + GCC 3.3.5
GCC host triplet: PIII + Gentoo Linux 2.6.11 + GCC 3.3.5
GCC target triplet: PIII + Gentoo Linux 2.6.11 + GCC 3.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26927
[Bug libgcj/11780] Method.invoke() is slow
--- Comment #7 from mckinlay at redhat dot com 2006-03-29 18:59 --- With a public call, as in the current test case, it is "only" about 2.5X slower than HotSpot for me: $ ./a.out public call: 499 ms private call: 7344 ms $ java RefTest3 public call: 182 ms private call: 808 ms Private calls show a larger difference due to the requirement for an accessibility check, which involves stack inspection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11780
[Bug libgcj/11780] Method.invoke() is slow
--- Comment #8 from mckinlay at redhat dot com 2006-03-29 19:00 --- Created an attachment (id=11156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11156&action=view) Test Case New version of the test case, which tests both public and private method invocation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11780
[Bug c++/26916] [4.0/4.1/4.2 Regression] template/overloaded function lookup
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-29 19:15 --- This is correct behavior. The template is the only thing the first template sees when it calls add_field as there are no dependent arguments. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26916
[Bug regression/26928] New: ICE in in bsi_last, at tree-flow-inline.h:760 on valid code with -march=i686.
gcc-4.2.0-20060323 / rev.112317
$ testcase:
void test(double x) { if (x > 0.0); }
$ ./xgcc -B. bug.c -c -m32 -march=i686
bug.c: In function 'test':
bug.c:7: internal compiler error: in bsi_last, at tree-flow-inline.h:760
it works with 4.1.1.
--
Summary: ICE in in bsi_last, at tree-flow-inline.h:760 on valid
code with -march=i686.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26928
[Bug other/26915] missed optimization / returning -1.0
--- Comment #1 from pluto at agmk dot net 2006-03-29 19:23 --- ...and the current 4.2.0 ICEs on this testcase: $ ./xgcc -B. 26915.c -m32 -march=i686 26915.c: In function ‘minus1’: 26915.c:1: error: bb_for_stmt (stmt) is set to a wrong basic block 26915.c:1: error: bb_for_stmt (stmt) is set to a wrong basic block 26915.c:1: internal compiler error: verify_stmts failed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26915
[Bug c/26921] long long bit fields are passed to variadic functions as longs
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-29 19:25 --- The warning mess has been corrected: t.c: In function 'main': t.c:10: warning: format '%lld' expects type 'long long int', but argument 2 has type 'long long int:33' This is not a bug, GCC is correct in warning. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26921
[Bug c/26923] byte swap incorrect
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-29 19:26 --- *** This bug has been marked as a duplicate of 11751 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26923
[Bug c/11751] wrong evaluation order of an expression
--- Comment #66 from pinskia at gcc dot gnu dot org 2006-03-29 19:26 --- *** Bug 26923 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||behloul dot younes at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug fortran/20935] failed assertion for maxloc(n, mask=.true.)
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-03-29 19:29 --- Fixed on 4.1. Closing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20935
[Bug fortran/20935] failed assertion for maxloc(n, mask=.true.)
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-03-29 19:30 --- Really closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20935
[Bug libfortran/25378] [Fortran 2003] maxloc for all-false mask
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-03-29 19:31 --- Fixed on 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25378
[Bug c/26927] math function log2 bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-29 19:34 --- t.c:9: warning: implicit declaration of function 'log2' t.c:9: warning: incompatible implicit declaration of built-in function 'log2' Please next time use -W -Wall before reporting a bug report as requested by: http://gcc.gnu.org/bugs.html. Use -std=gnu99 to "fix" the problem. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26927
[Bug regression/26928] ICE in in bsi_last, at tree-flow-inline.h:760 on valid code with -march=i686.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-29 19:35 --- It also works with "4.2.0 20060321". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26928
[Bug tree-optimization/26919] [4.1/4.2 regression] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-29 19:37 --- Confirmed. The testcase still involves long template parameter lists, but that seems to be part of the problem: I removed some of them, but then the testcase compiles. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-03-29 19:37:36 date|| Summary|ICE in |[4.1/4.2 regression] ICE in |cgraph_estimate_size_after_i|cgraph_estimate_size_after_i |nlining caused by |nlining caused by |boost::lambda |boost::lambda Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug tree-optimization/26919] [4.1/4.2 regression] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-03-29 19:38 --- Created an attachment (id=11157) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11157&action=view) Reduced testcase Reduced testcase. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Attachment #11152|0 |1 is obsolete|| Attachment #11155|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug tree-optimization/26919] [4.1/4.2 regression] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-03-29 19:39 --- Btw, the testcase crashes when compiles with "g++ -O": PR26919.cc:119: internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106 Please submit a full bug report, [etc.] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug bootstrap/26901] ../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1: fatal error: unknown encoding: 'roman8'
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-29 19:43 --- There are 2 parts to this bug. First, there's no reason to build tools.zip in the gcj build (yet). Second, upstream classpath should pass an explicit -encoding when invoking the java compiler. I'm working on these. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-29 19:43:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26901
[Bug bootstrap/26901] ../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1: fatal error: unknown encoding: 'roman8'
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-29 19:53 --- Subject: Re: ../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1: fatal error > There are 2 parts to this bug. > > First, there's no reason to build tools.zip in the gcj build (yet). > > Second, upstream classpath should pass an explicit -encoding when > invoking the java compiler. Thanks. I changed Makefile.am in classpath to provide UTF-8 encoding in gcj commands and everything now builds. However, libjava on hpux isn't quite ready for prime time. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26901
[Bug libgcj/26139] provide gorbd and gtnameserv executables
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-29 20:22 --- In order to do this we should avoid building tools.zip and instead directly build executables. (If we need a java archive for some reason, it should be a jar, anyway.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26139
[Bug bootstrap/26901] ../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1: fatal error: unknown encoding: 'roman8'
--- Comment #3 from cvs-commit at developer dot classpath dot org 2006-03-29 20:28 --- Subject: Bug 26901 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey <[EMAIL PROTECTED]>06/03/29 20:24:37 Modified files: . : ChangeLog examples : Makefile.am tools : Makefile.am Log message: PR gcc/26901: * tools/Makefile.am (JCOMPILER): Added encoding options. * examples/Makefile.am (JCOMPILER): Added encoding options. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6942&tr2=1.6943&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/examples/Makefile.am.diff?tr1=1.10&tr2=1.11&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/tools/Makefile.am.diff?tr1=1.7&tr2=1.8&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26901
[Bug middle-end/23411] [data deps] Distance on outer loops for self output deps
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29 20:39 --- Fixed by the recent changes. -- sebastian dot pop at cri dot ensmp dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23411
[Bug middle-end/23412] [data deps] Overflow problem in Omega
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29 20:40 --- Fixed on autovect. -- sebastian dot pop at cri dot ensmp dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23412
[Bug middle-end/23413] [data deps] Overflow problem in Omega
--- Comment #2 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29 20:42 --- Fixed on autovect. -- sebastian dot pop at cri dot ensmp dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23413
[Bug c++/26922] Compile/link failure with -frepo and g++ 4.1
--- Comment #2 from rankincj at yahoo dot com 2006-03-29 21:10 --- The sample code works OK with the following compilers: $ g++ -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux Thread model: posix gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) $ g++ -v Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /usr/src/gcc-3.4.4/configure --prefix=/usr --enable-languages=c,c++ --enable-version-specific-runtime-libs --enable-threads=posix --with-gnu-binutils --with-system-zlib --enable-shared --enable-nls Thread model: posix gcc version 3.4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26922
[Bug c/26933] New: Volatile member in struct member accessed/written implicitly
This actually occurs on 3.3.3 and 4.0.3 (haven't tried others).
When a structure contains a 32 bit int, and because of alignement, it is not
located on a 64 bit boundary *and* (apparently) the compiler aligns a bitfield
int on the first fullword, operations on that bitfield implicitly access the
volatile member.
For exemple, the following structure is affected :
struct foo
{
long long A;
int B:1;
volatile int C;
};
In this case, storing into foo.b triggers a load and a store from foo.C.
The following code sample demonstrates that :
struct _test1
{
long long A;
int B:1;
volatile int C;
};
unsigned int foo(struct _test1 *data)
{
data->B=1;
return data->C;
}
Generating assembler output with "gcc -m64 foo.c -S" shows the following for
function "foo" (comments are my own)
ld 9,112(31) * Get "data"
ld 11,8(9) * get data->B 64 bit value - including data->C
li 0,-1 * Set
rldicr 0,0,0,0 * The Right
or 0,11,0 * Bit and
std 0,8(9) * Store 64 bit value Including data->C
ld 9,112(31) * get data again
lwz 0,12(9) * get C for return
If data->C is altered somewhere else (thread for exemple) or if read or writing
C has a side affect (I/O area) then although the code has never explicitly
accessed or stored data in the code, the program will implictly access or store
in that field - thus defeating the purpose of the 'volatile' type specifier.
Note that this occurs EVEN without optimization.
This problem may or may not affect other 64 bit platforms (this depends whether
it is insns generation related or backend related or both).
*Possible Workaround*
If feasable - align serializable 32 bit ints manually to ensure 64 bit
alignement.
Note that I also have a 'working' program that demonstrates the volatile
variable being altered without being accessed explicitly... I can provide it if
necessary.
--Ivan
--
Summary: Volatile member in struct member accessed/written
implicitly
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivan at vmfacility dot fr
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26933
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-03-29 21:14 --- > Actually, the problem has nothing to do with using /bin/sh, because I get the > same failure using /bin/ksh, too: OK, but given that you're the first who reports that kind of problems, we're pretty much in the dark for the time being so we have to try the strictly adhere to the proven guidelines. It looks like the Fortran compiler doesn't work at all on your systems. Are you sure the shared GMP/MFPR libraries are in your LD_LIBRARY_PATH? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug c++/5247] Memory eating infinite loop on default parameter in constructor which is reference to class
--- Comment #14 from bsdfan3 at users dot sourceforge dot net 2006-03-29 21:14 --- GCC 3.4.4 on Cygwin actually breaks. The .ii file looks normal, however, it seems to be segfaulting...I'll try the testcase with mainline shortly. $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5247
[Bug c/26933] Volatile member in struct member accessed/written implicitly
--- Comment #1 from ivan at vmfacility dot fr 2006-03-29 21:18 --- Created an attachment (id=11158) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11158&action=view) Runnable program demonstrating the problem This program, once compiled for powerpc64 and run on powerpc64 demonstrates a volatile field being implicitly accessed/changed by the explicit change of a neighbouring value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26933
[Bug bootstrap/26901] ../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1: fatal error: unknown encoding: 'roman8'
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-29 21:33 --- Subject: Bug 26901 Author: tromey Date: Wed Mar 29 21:33:08 2006 New Revision: 112510 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112510 Log: PR gcc/26901: * Makefile.in: Rebuilt. * Makefile.am (SUBDIRS): Remove 'tools'. (DIST_SUBDIRS): Likewise. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/Makefile.am trunk/libjava/classpath/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26901
[Bug bootstrap/26901] ../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1: fatal error: unknown encoding: 'roman8'
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-29 21:42 --- Fix checked in, please give it a try. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26901
[Bug bootstrap/26829] broken classpath install (missed tools.zip), zip or fastjar not found
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 21:45 --- This was fixed by the patch for PR 26901. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26829
[Bug bootstrap/26901] ../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/AbstractMethodGenerator.java:1: fatal error: unknown encoding: 'roman8'
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-29 21:48 --- Really mark as fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26901
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #5 from quanah at stanford dot edu 2006-03-29 21:49 --- Yep. That's how f951 was getting linked to gmp. I'm going to make gmp only be static, however, and see if that changes things. I'm going to have to defer further work on both these bugs until next week. I had a very narrow window of opportunity for upgrading gcc for the campus (spring break), and now I have to back out all the gcc bits I've done so that I can release other software to the campus that needs updating. Next week I'll be able to start poking at gcc again. --Quanah -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug fortran/26889] libfortran build fails
--- Comment #28 from quanah at stanford dot edu 2006-03-29 22:12 --- Created an attachment (id=11160) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11160&action=view) selected_int_kind.inc Here's the selected_int_kind.inc file generated on Solaris 8 with gcc 4.0.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug tree-optimization/26859] [4.2 Regression] ICE Segmentation Fault
--- Comment #11 from malitzke at metronets dot com 2006-03-29 22:24 --- Maybe I should keep my mouth shut. However, gcc-4.2.0 2006329 again compiles pari-2.1.7 OK. 2nd However, pari-2.2.12.beta uses a different approch, which does not give any problems with various gcc-4.2.0. At least the problem surfaced in PR26859 seems pretty infrequent and is now _apparently_ solved. Regards -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26859
[Bug java/20044] Wrong method call semantics (maybe instanceof/invokespecial)
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-29 22:39 --- I tried this today with svn head. The test program still prints 'false' no matter how I run it: gij, compiled, or compiled with the BC ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
[Bug target/26935] New: powerpc undefined machine-specific-constraint
build/genpeep ../../gcc-4.2.0/gcc/config/rs6000/rs6000.md \ insn-conditions.md > tmp-peep.c ../../gcc-4.2.0/gcc/config/rs6000/altivec.md:173: error: undefined machine-specific constraint at this point: "W" ../../gcc-4.2.0/gcc/config/rs6000/altivec.md:173: note: in operand 1 ..previous 2 lines repeated 3 times more make[3]: *** [s-output] Error 1 renamed altivec.md and did svn update. compared equal. -- Summary: powerpc undefined machine-specific-constraint Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: powerpc-slackware-linux-gnu GCC host triplet: powerpc-slackware-linux-gnu GCC target triplet: powerpc-slackware-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
[Bug target/26935] [4.2 Regression] powerpc undefined machine-specific-constraint
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org GCC build triplet|powerpc-slackware-linux-gnu |powerpc-*-* GCC host triplet|powerpc-slackware-linux-gnu |powerpc-*-* GCC target triplet|powerpc-slackware-linux-gnu |powerpc-*-* Keywords||build Summary|powerpc undefined machine- |[4.2 Regression] powerpc |specific-constraint |undefined machine-specific- ||constraint Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
[Bug target/26935] [4.2 Regression] powerpc undefined machine-specific-constraint
--- Comment #1 from dje at gcc dot gnu dot org 2006-03-29 23:15 --- in progress -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
[Bug c++/26922] Compile/link failure with -frepo and g++ 4.1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-29 23:22 --- Can you try a GCC which was released by the FSF and not a redhat modified one? If it works there, please report this to Redhat. Note this should have been reported first to redhat and not here since you are using a redhat based compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26922
[Bug c++/26922] Compile/link failure with -frepo and g++ 4.1
--- Comment #4 from rankincj at yahoo dot com 2006-03-29 23:44 --- Subject: Re: Compile/link failure with -frepo and g++ 4.1 --- pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > Can you try a GCC which was released by the FSF and not a redhat modified one? > If it works there, please report this to Redhat. Note this should have been > reported first to redhat and not here since you are using a redhat based > compiler. Yes, I thought you'd say that, but my platform compiler is this RedHat-modified thing and I don't have a machine with a "vanilla" version of 4.1 available. However, you *do* have my very small, self-contained example program, because I attached it to the report. Can't you please just try and compile that on a i686-pc-linux-gnu machine? (I hear that such machines are very common. In fact you're possibly sitting in front of one right now.) If it works then I can tell RedHat that they've broken g++, but if it doesn't work then the bug report remains valid and you'll want to examine it more closely anyway. Thanks, Chris ___ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26922
[Bug target/26935] [4.2 Regression] powerpc undefined machine-specific-constraint
--- Comment #2 from malitzke at metronets dot com 2006-03-30 00:57 --- Maybe it is helpful to see how genpeep was built" Using built-in specs. Target: powerpc-slackware-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/usr --with-slibdir=/usr/lib/gcc/4.1.1 --infodir=/usr/share/gcc-4.1.1 --datadir=/usr/share/gcc-4.1.1 --mandir=/usr/share/gcc-4.1.1 --enable-version-specific-runtime-libs --program-suffix=-4.1.1 --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --disable-multilib --disable-nls --disable-werror --with-gnu-ld --host=powerpc-slackware-linux-gnu --target=powerpc-slackware-linux-gnu --build=powerpc-slackware-linux-gnu --enable-languages=c,c++,fortran,java --with-cpu=7450 --enable-clocale=gnu Thread model: posix gcc version 4.1.1 20060329 (prerelease) /usr/libexec/gcc/powerpc-slackware-linux-gnu/4.1.1/collect2 --eh-frame-hdr -V -Qy -m elf32ppclinux -dynamic-linker /lib/ld.so.1 -o build/genpeep /usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1/../../../crt1.o /usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1/../../../crti.o /usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1/crtbegin.o -L/usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1 -L/usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1 -L/usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1/../../.. build/genpeep.o build/rtl.o build/read-rtl.o build/ggc-none.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../build-powerpc-slackware-linux-gnu/libiberty/libiberty.a -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1/crtsavres.o /usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1/crtend.o /usr/lib/gcc/powerpc-slackware-linux-gnu/4.1.1/../../../crtn.o GNU ld version 2.17 20060307 Supported emulations: elf32ppclinux elf32ppc elf32ppcsim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
[Bug c++/26114] [4.2 Regression] g++.dg/init/ctor4.C and g++.old-deja/g++.jason/overload34.C and g++.old-deja/g++.mike/p11110.C fails
--- Comment #7 from janis at gcc dot gnu dot org 2006-03-30 01:06 --- The patch that Lee checked in removed checks for extra_warnings before the calls to warnings with OPT_Wextra in typeck.c and class.c. If those checks are restored then the five test cases listed in this PR and in 26115 pass. There's still a bug that Lee's code exposed, but putting the conditions back will let the tests pass again. Sorry, I don't have a fully-tested patch and am about to be out of touch for over a week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26114
[Bug target/26935] [4.2 Regression] powerpc undefined machine-specific-constraint
--- Comment #3 from malitzke at metronets dot com 2006-03-30 01:07 --- Using an older version of gcc-4.2.0 gave essentially the same error message as in the original description. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
[Bug c++/26115] [4.2 Regression] bogus warning for g++.dg/parse/register1.C
--- Comment #6 from janis at gcc dot gnu dot org 2006-03-30 01:07 --- The patch that Lee checked in removed checks for extra_warnings before the calls to warnings with OPT_Wextra in typeck.c and class.c. If those checks are restored then the five test cases listed in this PR and in 26114 pass. There's still a bug that Lee's code exposed, but putting the conditions back will let the tests pass again. Sorry, I don't have a fully-tested patch and am about to be out of touch for over a week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26115
[Bug target/26935] [4.2 Regression] powerpc undefined machine-specific-constraint
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-30 01:10 --- I just was able to build this without any troubles ;). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
[Bug c++/22494] C++ front-end produces mis-match types in EQ_EXPR (array deconstructor)
--- Comment #1 from sayle at gcc dot gnu dot org 2006-03-30 01:35 --- Subject: Bug 22494 Author: sayle Date: Thu Mar 30 01:35:22 2006 New Revision: 112529 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112529 Log: PR c++/22494 * init.c (build_vec_delete_1): Convert BASE pointer's type to the base pointer type to avoid a type mismatch in the EQ_EXPR. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22494
[Bug target/26935] [4.2 Regression] powerpc undefined machine-specific-constraint
--- Comment #5 from malitzke at metronets dot com 2006-03-30 03:48 --- I just did an svn update and there is an rs6000/constraints.md updated. So, let us keep our fingers crossed while I do new bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
[Bug target/26935] [4.2 Regression] powerpc undefined machine-specific-constraint
--- Comment #6 from malitzke at metronets dot com 2006-03-30 03:54 --- Yep, it just passed that stage and seems to be well on its way. Thanks, you do the paperwork. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26935
[Bug fortran/26889] libfortran build fails
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2006-03-30 06:20 --- > Here's the selected_int_kind.inc file generated on Solaris 8 with gcc 4.0.3. Thanks. Victory, at last something obviously broken. :-) The file reads: integer, parameter :: c = 0 type (int_info), parameter :: int_infos(c) = (/ & while it should read: integer, parameter :: c = 4 type (int_info), parameter :: int_infos(c) = (/ & int_info (1, range(0_1)), & int_info (2, range(0_2)), & int_info (4, range(0_4)), & int_info (8, range(0_8)) /) so again the Fortran compiler either doesn't work or is not correctly invoked. In the $objdir/sparc-sun-solaris2.8/libgfortran directory, delete the file (selected_int_kind.inc) and type 'gmake selected_int_kind.inc'. You should see something like: /bin/ksh /home/eric/svn/gcc-4_0-branch/libgfortran/mk-sik-inc.sh '/opt/build/eric/gcc-4_0-branch/gcc/gfortran -B/opt/build/eric/gcc-4_0-branch/gcc/ -B/opt/build/eric/local/gcc-4_0-branch/sparc-sun-solaris2.8/bin/ -B/opt/build/eric/local/gcc-4_0-branch/sparc-sun-solaris2.8/lib/ -isystem /opt/build/eric/local/gcc-4_0-branch/sparc-sun-solaris2.8/include -isystem /opt/build/eric/local/gcc-4_0-branch/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring-g -O2' > selected_int_kind.inc Could you try to re-play the script mk-sik-inc.sh by hand and find out when things start to go awry? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
[Bug tree-optimization/26796] [4.2 Regression] ACATS ICE c34002a c52005 spurious storage_error
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-30 06:39 --- Jeff, please put PR numbers in your ChangeLog entries, thanks. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|law at gcc dot gnu dot org | Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26796
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #30 from mckinlay at redhat dot com 2006-03-30 07:00 --- Created an attachment (id=11161) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11161&action=view) patch implementing GC_register_my_thread Here's a patch that fixes this by adding functions to the GC that allow thread registration directly from JNI_AttachCurrentThread. Aside from being fragile, solutions that rely on intercepting pthread_create are problematic because the GC will attempt to suspend other non-Java threads (see rh bug 180637 for an example) This patch has been tested sucessfully with openoffice.org. -- mckinlay at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mckinlay at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug bootstrap/26936] New: fix-header segfault with glibc-2.4 header
On bootstrapping, fix-header segfaults while processing /usr/include/bits/stdio-ldbl.h which is from glibc-2.4. This problem does not appear on i386-linux host because 'use_fixproto' is set to 'no' in gcc/config.gcc. Reduced problematic header contents: f() Reproduce: cd /gcc make stmp-fixproto cd build echo 'f()' >f.h ./fix-header bits/f.h f.h bits/f.h Segmentation fault -- Summary: fix-header segfault with glibc-2.4 header Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sugioka at itonet dot co dot jp GCC host triplet: sh4-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
