[Bug c++/26454] New: problem about GCC STL
I write a file, code as that:
#include
#include
using namespace std;
using namespace __gnu_cxx;
struct str_hash
{
size_t operator()(const string& str) const
{
return __stl_hash_string(str.c_str());
}
};
class A
{
public:
hash_map map_body;
public:
A();
};
int main()
{
return 0;
}
=
I find that can run in Visual Studio.2003,but my linux gcc 3.4.4 can not.
I know Microsoft with P.J.STL is not same as Gcc with SGI STL.
Report as :
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.4/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)
/usr/libexec/gcc/x86_64-redhat-linux/3.4.4/cc1plus -E -quiet -v -D_GNU_SOURCE
tt.cpp -mtune=k8 -o tt.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/include
/usr/include
End of search list.
/usr/libexec/gcc/x86_64-redhat-linux/3.4.4/cc1plus -fpreprocessed tt.ii -quiet
-dumpbase tt.cpp -mtune=k8 -auxbase tt -version -o tt.s
GNU C++ version 3.4.4 20050721 (Red Hat 3.4.4-2) (x86_64-redhat-linux)
compiled by GNU C version 3.4.4 20050721 (Red Hat 3.4.4-2).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_pair.h:
In instantiation of `std::pair':
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_function.h:544:
instantiated from `std::_Select1st >'
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/ext/hashtable.h:258:
instantiated from `__gnu_cxx::hashtable,
std::string, str_hash, std::_Select1st >,
std::equal_to, std::allocator >'
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/ext/hash_map:96:
instantiated from `__gnu_cxx::hash_map, std::allocator >'
tt.cpp:16: instantiated from here
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_pair.h:74:
error: `std::pair<_T1, _T2>::second' has incomplete type
tt.cpp:14: error: forward declaration of `class A'
===
Please help me, thanks a lot!
--
Summary: problem about GCC STL
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cnhome at vip dot sina dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26454
[Bug c++/26454] problem about GCC STL
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-24 10:05 ---
/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../include/c++/3.4.4/bits/stl_pair.h:74:
error: `std::pair<_T1, _T2>::second' has incomplete type
tt.cpp:14: error: forward declaration of `class A'
You cannot use the incomplete (at this point) type 'class A' for
hash_map map_body;
try using a base class here like
class B {};
class A : public B {
...
hash_map map_body;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26454
[Bug c++/26451] I get segmentation fault when executing this input/output program
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-24 10:08 --- Your program is buggy. This bugzilla is not for getting help on writing C programs - try using a debugger and debug yourself. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26451
[Bug c/26449] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invaraint motion
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-02-24 10:13 --- Confirmed. Trying to get a small testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Summary|ICE with -march=pentium4 in |ICE with -march=pentium4 - |matmul_i4.c |ftree-vectorize in ||matmul_i4.c in loop ||invaraint motion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug middle-end/26412] ICE with external arrays using OpenMP
--- Comment #5 from jakub at gcc dot gnu dot org 2006-02-24 10:26 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-22 13:01:10 |2006-02-24 10:26:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26412
[Bug middle-end/26412] ICE with external arrays using OpenMP
--- Comment #6 from jakub at gcc dot gnu dot org 2006-02-24 10:26 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26412
[Bug rtl-optimization/26449] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invaraint motion
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-24 10:29 ---
Testcase: -O1 -ftree-vectorize -march=pentium4
void matmul_i4 (int bbase_yn, int xcount)
{
int x;
int * restrict dest_y;
const int * abase_n;
for (x = 0; x < xcount; x++)
{
dest_y[x] += abase_n[x] * bbase_yn;
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |rtl-optimization
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-02-24 10:29:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug rtl-optimization/26449] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invaraint motion
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-24 10:46 --- "Don't worry, Jim. I'm monitoring the situation. I'm on top of things." -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-24 10:29:02 |2006-02-24 10:46:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug fortran/25395] equivalence to common block array broken
--- Comment #3 from pault at gcc dot gnu dot org 2006-02-24 10:51 --- Subject: Bug 25395 Author: pault Date: Fri Feb 24 10:51:42 2006 New Revision: 111416 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111416 Log: 2006-02-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. 2006-02-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_3.f90 trunk/gcc/testsuite/gfortran.dg/equiv_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/vect-3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25395
[Bug fortran/24519] gfortran slow because of incomplete dependency checking
--- Comment #5 from pault at gcc dot gnu dot org 2006-02-24 10:51 --- Subject: Bug 24519 Author: pault Date: Fri Feb 24 10:51:42 2006 New Revision: 111416 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111416 Log: 2006-02-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. 2006-02-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_3.f90 trunk/gcc/testsuite/gfortran.dg/equiv_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/vect-3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24519
[Bug fortran/25395] equivalence to common block array broken
--- Comment #4 from pault at gcc dot gnu dot org 2006-02-24 10:53 --- Fixed on trunk. As soon as 4.1 is reopened, it will be fixed there too. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25395
[Bug fortran/24519] gfortran slow because of incomplete dependency checking
--- Comment #6 from pault at gcc dot gnu dot org 2006-02-24 10:53 --- Fixed on trunk. As soon as 4.1 is reopened, it will be fixed there too. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24519
[Bug fortran/26440] ICE in expand_copysign, at optabs.c:2930 with using -ff2c
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-24 11:28 ---
gfc_sym_type()
if (gfc_option.flag_f2c
&& sym->attr.function
&& sym->ts.type == BT_REAL
&& sym->ts.kind == gfc_default_real_kind
&& !sym->attr.always_explicit)
{
/* Special case: f2c calling conventions require that (scalar)
default REAL functions return the C type double instead. */
sym->ts.kind = gfc_default_double_kind;
type = gfc_typenode_for_spec (&sym->ts);
sym->ts.kind = gfc_default_real_kind;
}
is asking for trouble. This kind of hack has to be repeated elsewhere, so
we do not miss the type-mismatch between FOO and X.
But the real solution looks like creating the correct kind for the return
type in the first place like if it was written as REAL*8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26440
[Bug c++/26455] New: g++ 3.x ICE on typeid(typeid(*object))
The code below generates an ICE with g++ 3.3 (debian stable),
g++ 3.4 (debian testing):
[pollindd] ~ >g++-3.3 -c ice-typeid.cc
ice-typeid.cc: In function `int bug5(BaseB*)':
ice-typeid.cc:43: internal compiler error: in expand_expr, at expr.c:8833
Please submit a full bug ...
[pollindd] ~ >g++-3.4 -c ice-typeid.cc
ice-typeid.cc: In function `int bug5(BaseB*)':
ice-typeid.cc:43: internal compiler error: in expand_expr_real, at
expr.c:8469
Please submit a full bug report...
It works well with g++ 2.95.4 (debian).
Maybe related to bug #25357.
[pollindd] ~ >g++-3.4 -v
Reading specs from /usr/lib/gcc/i486-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --disable-werror i486-linux
Thread model: posix
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
[pollindd] ~ >g++-3.3 -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.6/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.6 (Debian 1:3.3.6-5)
Code follows. Command line:
g++-3.x -c ice-typeid.cc
Optimisation flag seems to have no impact (same problem with
-O3). Likewise for -Wall. It works on more complicated code (?!)... but it's
hard to see where the fix is introduced.
#include
class BaseB
{
public:
virtual ~BaseB() {}
};
#if BUG == 1
const char* bug1(BaseB const* o)
{
return typeid(typeid(*o)).name();
}
#elif BUG == 2
const std::type_info & bug2(BaseB const* o)
{
return typeid(typeid(*o));
}
#elif BUG == 3
const char* bug3(BaseB * o)
{
return typeid(typeid(*o)).name();
}
#elif BUG == 4
const std::type_info & bug4(BaseB * o)
{
return typeid(typeid(*o));
}
#else
int bug5(BaseB * o)
{
int i;
return (typeid(typeid(*o)) == typeid(i));
}
#endif
--
Summary: g++ 3.x ICE on typeid(typeid(*object))
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: com dot d2 at free dot fr
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26455
[Bug c++/26455] g++ 3.x ICE on typeid(typeid(*object))
--- Comment #1 from com dot d2 at free dot fr 2006-02-24 12:38 --- Created an attachment (id=10907) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10907&action=view) Code leading to ICE Compile it with -DBUG=xyz to activate bug xyz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26455
[Bug c++/26455] g++ 3.x ICE on typeid(typeid(*object))
--- Comment #2 from com dot d2 at free dot fr 2006-02-24 12:40 --- Created an attachment (id=10908) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10908&action=view) Preprocessor output (gcc 3.4.4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26455
[Bug tree-optimization/26443] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1867
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26443
[Bug tree-optimization/26443] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1867
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 13:04 --- Actually this happens after VRP2 which might mean it is a bug for Jeff Law to look into. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26443
[Bug tree-optimization/26443] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1867
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 13:06 --- Confirmed. Though VRP2 is just doing constant propagation at this point. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-24 13:06:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26443
[Bug target/26445] SSE byte-by-byte load instruction fails to compile
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 13:11 --- can you give the full output of gcc -v? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26445
[Bug fortran/26409] [4.2 regression] ICE on Assumed shape nested subroutine
--- Comment #8 from pault at gcc dot gnu dot org 2006-02-24 13:15 --- (In reply to comment #7) > A few binary search steps later: Works with revision 111270, fails with > 111271. > It seems to be related to the patch > First, I am sorry to be a "doubting Thomas" - I finally succeeded in reproducing the problem. Second, I unpatched the above and find that this is indeed the problem. I will try to understand why but I will (i) Post this to the list and (ii) remove it from mainline tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
[Bug fortran/26409] [4.2 regression] ICE on Assumed shape nested subroutine
--- Comment #9 from pault at gcc dot gnu dot org 2006-02-24 13:54 --- Subject: Bug 26409 Author: pault Date: Fri Feb 24 13:54:06 2006 New Revision: 111417 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111417 Log: 2006-02-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26409 * resolve.c (resolve_contained_functions, resolve_types, gfc_resolve): Revert patch of 2006-02-19. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
[Bug fortran/26409] [4.2 regression] ICE on Assumed shape nested subroutine
--- Comment #10 from pault at gcc dot gnu dot org 2006-02-24 14:15 --- First, I am sorry to be a "doubting Thomas" - I finally succeeded in reproducing the problem. Second, I unpatched the above and find that this is indeed the problem. I will try to understand why but: (i) I have posted this to the list and; (ii) removed it from mainline. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
[Bug c/26456] New: OpenMP program deadlocks when executed
OpenMP C programs deadlock immediately after starting when OMP_NUM_THREADS is >
1.
For example, the following simple code just hangs:
#include
main() {
int i;
#pragma omp parallel for private(i)
for (i = 0; i < 100; i++)
printf("Thread = %d.\n", omp_get_thread_num());
}
This occurs on MacOS X 10.4.5 with gcc version:
Using built-in specs.
Target: powerpc-apple-darwin8.4.0
Configured with:
/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_gcc42/work/gcc-4.2-20060204/configure
--prefix=/opt/local --enable-languages=c,c++,java,objc,fortran
--libdir=/opt/local/lib/gcc42 --includedir=/opt/local/include/gcc42
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-dp-4.2 --with-gxx-include-dir=/opt/local/include/gcc42/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --disable-multilib
Thread model: posix
gcc version 4.2.0 20060204 (experimental)
Also it appears that when -fopenmp switch is used, gcc does not automatically
include -lgomp but
this has to be done by hand.
--
Summary: OpenMP program deadlocks when executed
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eloranta at jyu dot fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26456
[Bug libgomp/26456] OpenMP program deadlocks when executed
--- Comment #1 from eloranta at jyu dot fi 2006-02-24 14:23 --- Most likely this is just OS X specific bug. -- eloranta at jyu dot fi changed: What|Removed |Added Component|c |libgomp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26456
[Bug java/21206] gcj seems not to pass the option to ld correctly
--- Comment #13 from Ralf dot Wildenhues at gmx dot de 2006-02-24 14:57 --- (In reply to comment #12) > It appears that the LT stands for libtool. So the first one (LIBICONV) is > supposed to be used for linking if you aren't using libtool, and the second > one > (LTLIBICONV) is used for linking if you are using libtool. Right. You cannot expect to be able to use $LTLIBICONV if you are not using Libtool. > So, yes, this looks OK to me. We could at least get this on mainline even if > we can't fix the release branches yet. That is not ok. Best would probably be if you took LIBICONV and killed all instances of $wl aka $acl_cv_wl from it, and turned all remaining comma into spaces, for good measure. I think. For the former, you could also call AC_LIB_RPATH explicitly and unset or empty $wl for the AM_ICONV call, and restore it afterwards. If you don't need the LIBICONV for other purposes that may involve linking with a compiler driver. Or fix config/lib-link.m4 AC_LIB_RPATH to provide additional variables for use when linking with $LD. Luckily newer Libtool macros don't do that very often anymore, so it may not be worth it. -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21206
[Bug c/26457] New: -fstack-protector leaks the upper bits of RAX
The following code snippet, compiled with -Os -fstack-protector:
#include
int StringChecksum(char *s)
{
char buffer[2048];
int i;
int checksum = 0;
memset(buffer, 0, 2048);
strcpy(buffer, s);
for (i=0; i<2048; i++)
checksum += buffer[i];
return checksum;
}
leads to the following snippet of assembly for the part where gcc puts the
canary value on the stack: (part of the full assembly of the function)
movq%rsp, %rdi
movq%fs:40, %rax
movq%rax, 2056(%rsp)
xorl%eax, %eax
callmemset
the key instruction for this bug is the "xorl %eax, %eax". The intent of that
instruction seems to be to not leak the canary value into the actual function
code; however the canary value is 64 bits and in RAX, while the XOR is only
zeroing the lower 32 bits. For consistency and information security, this XOR
should, I think, clear all of RAX (which is same-cost anyway both in size and
execution)
--
Summary: -fstack-protector leaks the upper bits of RAX
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arjan at linux dot intel dot com
GCC host triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
[Bug libfortran/26423] [4.1/4.2 Regression] Error on binary I/O for large array
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-02-24 15:08 --- Patch submitted: http://gcc.gnu.org/ml/fortran/2006-02/msg00498.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug libgomp/26456] OpenMP program deadlocks when executed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 15:09 --- This is Darwin specific. This is a dup of bug 25978. *** This bug has been marked as a duplicate of 25978 *** -- 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=26456
[Bug libgomp/25978] All libgomp tests timeout on ppc-darwin
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 15:09 --- *** Bug 26456 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||eloranta at jyu dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25978
[Bug libgomp/25978] All libgomp tests timeout on ppc-darwin
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 15:10 --- More information about this issue is at the following thread: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00167.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25978
[Bug target/26457] -fstack-protector leaks the upper bits of RAX
--- Comment #1 from jakub at gcc dot gnu dot org 2006-02-24 15:11 --- To my knowledge xorl %eax, %eax is just a shorter form of xorq %rax, %rax, both clear all 64 bits of %rax. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
[Bug target/26457] -fstack-protector leaks the upper bits of RAX
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 15:12 --- This is an issue of agrument passing really as eax is used to pass 0 to memset though I don't know if this is really an issue or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
[Bug middle-end/26316] [4.2 Regression] loop-invariant miscompiles openmp.c
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-02-24 15:20 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26316
[Bug target/26290] [4.1 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #14 from rakdver at gcc dot gnu dot org 2006-02-24 15:20 --- Ivopts fail to use the complex addressing mode, thus forcing one more biv into inner loop. Since this makes it impossible to allocate registers for the loop, we get another penalty for spilling. Changing the initial value makes us notice that we may perform IV elimination, thus getting rid of the extra register. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-19 09:13:57 |2006-02-24 15:20:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug c++/26458] New: Passing a NULL char* into output stream now breaks the output stream
Prior behavior handled passing a char* with a NULL value into an output stream;
the result was that nothing printed. As of versions 3 and later this behavior
has changed. Perhaps a bug, perhaps a new enforcement.
The result is that the output stream no longer writes anything (to file or
stdout) until the descriptor is closed, and then only the unflushed text up
until the NULL was passed.
Example code:
#include
main() {
char *str = NULL;
cout << "Hello " << str << " there" << endl;
cout << "still dead?" << endl;
}
Resulting output is:
Hello_
No further output is sent. Perhaps, if it is deemed improper to allow a NULL
in a known type being passed to a stream, then a SEG fault might be better than
continue with no indication, except for lack of output.
--
Summary: Passing a NULL char* into output stream now breaks the
output stream
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phil at mitre dot org
GCC build triplet: 2.3.2 20030502 (RedHat linux 2.3.2-53)
GCC host triplet: RedHat linux 2.4.21-37 enterprise
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #1 from pcarlini at suse dot de 2006-02-24 16:53 --- The change is certainly intended and the important point is that is not true that there is no indication of the failure, quite to the contrary the badbit is set. Try changing your test like this: char *str = NULL; cout << "Hello " << str; assert( !cout.good() ); cout.clear(); cout << " there" << endl; assert( cout.good() ); cout << "still dead?" << endl; assert( cout.good() ); -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug fortran/26440] ICE in expand_copysign, at optabs.c:2930 with using -ff2c
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 17:25 --- I want to say this is exactly the same issue as PR 25392, looking at the fact it is the return value which is causing the issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25392 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26440
[Bug middle-end/26439] [4.2 Regression] missing VOPs for complex assignments
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 17:32 --- Actually I could not reproduce this with "4.2.0 20060221"? Is it only with the patch to fix PR 26421? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
[Bug middle-end/26439] [4.2 Regression] missing VOPs for complex assignments
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
[Bug middle-end/26439] [4.2 Regression] missing VOPs for complex assignments
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 17:34 --- Actually this looks like it is x86 specific. Please next time add the target if you think it is x86 specific and also pelase mention this was also using the C++ front-end. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
[Bug middle-end/26439] [4.2 Regression] missing VOPs for complex assignments
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-24 17:36 --- Actually I cannot reproduce this with "4.2.0 20060218" either on x86? What were you doing to reproduce this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
[Bug c/8268] no compile time array index checking
--- Comment #37 from dcb314 at hotmail dot com 2006-02-24 17:38 --- (In reply to comment #33) > Created an attachment (id=10902) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10902&action=view) [edit] > updated patch. > > better patch. I'm going to post that one when regtesting completes. I tried your patch on gcc 4.2 current snapshot and I had to bodge it a bit to get it to compile. After that, it segfaulted during bootstrapping ;-< -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug fortran/26440] ICE in expand_copysign, at optabs.c:2930 with using -ff2c
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-24 17:40 --- Actually looking at the simplified testcase this is a dup of bug 25392. *** This bug has been marked as a duplicate of 25392 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26440
[Bug fortran/25392] ICEs with -ff2c
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 17:40 --- *** Bug 26440 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug fortran/26444] gfortran does not compile cp2k
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-24 17:42 --- I cannot reproduce this with "4.2.0 20060218". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
[Bug middle-end/26439] [4.2 Regression] missing VOPs for complex assignments
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-24 17:46 --- (In reply to comment #6) > Actually I cannot reproduce this with "4.2.0 20060218" either on x86? What > were you doing to reproduce this? Or even the 20th. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
[Bug fortran/26444] gfortran does not compile cp2k
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 17:47 --- I can reproduce this on the 20th though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
[Bug fortran/26444] gfortran does not compile cp2k
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-24 17:48 --- So what this means I could not have caused this as the only patch after my 18th GCC and my 20th GCC is not a patch which I committed that would have caused this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
[Bug fortran/26444] gfortran does not compile cp2k
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-24 17:53 --- Note -O3 enables complete unrolling at the tree level, I think there might be another related bug to this one. I bet it is failing in VRP2 also, just like the other one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
[Bug target/378] [AIX] gcc cannot compile huge c file
--- Comment #8 from ska at resqnet dot com 2006-02-24 17:53 --- Any chances to get it resolved ? This severe bug is a showstopper for using OpenCobol with GCC on AIX platform because all C programs are generated and there are no way to reduce the size of the programs automatically due to nature of Cobol language. -- ska at resqnet dot com changed: What|Removed |Added CC||ska at resqnet dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=378
[Bug fortran/26444] gfortran does not compile cp2k
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-24 17:54 --- (In reply to comment #10) > Note -O3 enables complete unrolling at the tree level, I think there might be > another related bug to this one. I bet it is failing in VRP2 also, just like > the other one. That would be PR 26443 by the way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|ICE with -march=pentium4 - |[4.2 Regression] ICE with - |ftree-vectorize in |march=pentium4 -ftree- |matmul_i4.c in loop |vectorize in matmul_i4.c in |invariant motion|loop invariant motion Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug tree-optimization/26444] [4.2 Regression] gfortran does not compile cp2k
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-24 18:14 --- (In reply to comment #11) > (In reply to comment #10) > > Note -O3 enables complete unrolling at the tree level, I think there might > > be > > another related bug to this one. I bet it is failing in VRP2 also, just > > like > > the other one. > > That would be PR 26443 by the way. And it fails in the same way PR 26443 fails as that it is ICE after VRP2. Here is the "reduced" testcase (there are no complex types in there): MODULE message_passing TYPE mp_perf_type CHARACTER ( LEN = 20 ) :: name REAL :: time END TYPE mp_perf_type INTEGER, PARAMETER :: MAX_PERF = 12 TYPE mp_perf_env_type INTEGER :: ref_count, id_nr TYPE ( mp_perf_type ), DIMENSION ( MAX_PERF ) :: mp_perfs END TYPE mp_perf_env_type CHARACTER ( LEN = 20 ), PARAMETER :: sname ( MAX_PERF ) = & (/"MP_Group", "MP_Bcast", "MP_Allreduce", & "MP_Gather ", "MP_Sync ", "MP_Alltoall ", & "MP_SendRecv ", "MP_ISendRecv", "MP_Wait ", & "MP_comm_split ", "MP_ISend", "MP_IRecv"/) CONTAINS SUBROUTINE mp_perf_env_create(perf_env) TYPE(mp_perf_env_type), POINTER :: perf_env perf_env%id_nr=last_mp_perf_env_id DO i = 1, MAX_PERF perf_env%mp_perfs(i) % name = sname(i) perf_env%mp_perfs(i) % time = 0.0 END DO END SUBROUTINE mp_perf_env_create END MODULE message_passing -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26443 Component|fortran |tree-optimization Keywords||ice-on-valid-code Summary|gfortran does not compile |[4.2 Regression] gfortran |cp2k|does not compile cp2k Target Milestone|--- |4.2.0 Version|4.1.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26444
[Bug libfortran/26423] [4.1/4.2 Regression] Error on binary I/O for large array
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-02-24 18:16 --- Subject: Bug 26423 Author: jvdelisle Date: Fri Feb 24 18:16:25 2006 New Revision: 111420 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111420 Log: 2006-02-24 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26423 * io/unix.c (fd_seek): Revert change from 25949. (fd_read): Same. (fd_write): Same. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug middle-end/26439] [4.2 Regression] missing VOPs for complex assignments
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 18:22 --- Actually never mind I see the issue now but I still say this is a latent bug and not really my bug. And the patch is wrong anyways in general as most of those places really should have been testing something like var_can_have_subvars instead of AGGREGATE_TYPE_P anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26439
[Bug libgomp/26452] Internal compiler error with openmp
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:23 --- Actually this is still a bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26452
[Bug libfortran/26423] [4.1/4.2 Regression] Error on binary I/O for large array
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-02-24 18:23 --- Subject: Bug 26423 Author: jvdelisle Date: Fri Feb 24 18:23:38 2006 New Revision: 111421 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111421 Log: 2006-02-24 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26423 * gfortran.dg/read_many_1.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/read_many_1.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug libgomp/26452] Internal compiler error with openmp
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-24 18:24 --- This is a dup of bug 25952. *** This bug has been marked as a duplicate of 25952 *** -- 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=26452
[Bug c++/25952] -fopenmp causes ICE on valid code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:24 --- *** Bug 26452 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pkambadu at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25952
[Bug c++/26455] g++ 3.x ICE on typeid(typeid(*object))
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 18:30 --- *** This bug has been marked as a duplicate of 26417 *** -- 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=26455
[Bug c++/26417] typeid(typeid(*object)) ICE on g++ 3.x / i686
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:30 --- *** Bug 26455 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||com dot d2 at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26417
[Bug c/26459] New: gcc-4.1.0 RC2 fails to build on certain PowerPC targets
When configuring gcc with: --target=powerpc-unknown-linux-gnuspe --host=powerpc-unknown-linux-gnuspe --enable-e500_double this file will be included: gcc/config/rs6000/e500-double.h which in turn uses the variable rs6000_float_gprs_string which is not defined anywhere. (So the build stops with undefined sysmbol error) This problem can be detected as far as 20060206. Gcc 4.0.2 builds fine with the same configuration options. -- Summary: gcc-4.1.0 RC2 fails to build on certain PowerPC targets Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edmar at freescale dot com GCC build triplet: powerpc-unknown-linux-gnuspe GCC host triplet: powerpc-unknown-linux-gnuspe GCC target triplet: powerpc-unknown-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc-4.1.0 RC2 fails to build on powerpc e500-double targets
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:42 --- It is obvious that it was caused by: 2005-05-05 Aldy Hernandez <[EMAIL PROTECTED]> David Edelsohn <[EMAIL PROTECTED]> * config.gcc: Add .opt magic for the rs6000 ports. . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-unknown-linux-gnuspe| GCC host triplet|powerpc-unknown-linux-gnuspe| GCC target triplet|powerpc-unknown-linux-gnuspe|powerpc-linux-gnuspe Last reconfirmed|-00-00 00:00:00 |2006-02-24 18:42:12 date|| Summary|gcc-4.1.0 RC2 fails to build|[4.1/4.2 Regression] gcc- |on certain PowerPC targets |4.1.0 RC2 fails to build on ||powerpc e500-double targets Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 18:43 --- It also tells us that testing powerpc-linux-gnuspe is not important as it has been broken for over a half of a year. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] gcc- |[4.1/4.2 Regression] gcc |4.1.0 RC2 fails to build on |fails to build on powerpc |powerpc e500-double targets |e500-double targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #2 from phil at mitre dot org 2006-02-24 18:45 --- Subject: RE: Passing a NULL char* into output stream now breaks the output stream Thanks for the quick response. This came up when some old systems were ported from Solaris using gcc-2.9.5 or so and out output files just stopped growing. Took a couple days of detailed debugging to track it down to a low-level string class... In any event, my experience is that developers tend not to assert the status of the stream operators every time they use them, especially output streams. In general, with almost any output descriptor or stream, you use it correctly or not to your peril, subject to core dumps and the like. However, this behavior seems to expect that all developers will do the right thing and always check stream state after each << use (never mind if you string several together). But the reason they got into this state to begin with is because they did something wrong, sending NULL where they shouldn't, so how can you expect, if they did that, that they would bother to check the ostream operator. So my feeling is that the effect of doing this should be one of the following: 1. allow << for NULL of known type by doing nothing; if (NULL) return... 2. seg fault for making an ostream deref a NULL Otherwise, there's great potential that the output stream (the data) will become corrupted, even if you manage to check it state. For example: cout << "hello " << val1 << " is " << val2 << " here today?" << endl; assert(!cout.good()); It's almost impossible to determine, even if you know the state is bad, how much data was successfully sent into the stream before it crapped out. On one level you're doing a nice thing by not crashing the program, but on another it seems unlikely you'll be able to recover the stream, by perhaps filling in missing pieces correctly, so you might as well crash. Thanks again for the response... phil Phil Brown Lead Software Systems Engineer Mitre CAASD [EMAIL PROTECTED] Perception is nine-tenths of the flaw. >-Original Message- >From: pcarlini at suse dot de [mailto:[EMAIL PROTECTED] >Sent: Friday, February 24, 2006 11:53 AM >To: Brown, Phil >Subject: [Bug libstdc++/26458] Passing a NULL char* into >output stream now breaks the output stream > > > >--- Comment #1 from pcarlini at suse dot de 2006-02-24 >16:53 --- >The change is certainly intended and the important point is >that is not true >that there is no indication of the failure, quite to the >contrary the badbit is >set. Try changing your test like this: > > char *str = NULL; > cout << "Hello " << str; > > assert( !cout.good() ); > cout.clear(); > > cout << " there" << endl; > > assert( cout.good() ); > > cout << "still dead?" << endl; > > assert( cout.good() ); > > >-- > >pcarlini at suse dot de changed: > > What|Removed |Added >--- >- > Status|UNCONFIRMED |RESOLVED > Component|c++ |libstdc++ > Resolution||INVALID > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458 > >--- You are receiving this mail because: --- >You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug libgcj/26441] Old libltdl may cause memory leak in Class.forName()
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 18:48 --- Confirmed, had 3.4 was the last import. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-24 18:48:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26441
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #3 from edmar at freescale dot com 2006-02-24 18:49 --- (In reply to comment #2) > It also tells us that testing powerpc-linux-gnuspe is not important as it has > been broken for over a half of a year. > We test all releases, the last one was 4.0.2 and it was OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #3 from phil at mitre dot org 2006-02-24 18:54 --- See comment #2. -- phil at mitre dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-24 18:55 --- I think Paolo forgot to mention this is required by the C++ standard. -- 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=26458
[Bug tree-optimization/26447] verify_flow_info failed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-24 18:59 --- Well this one class file is not enough to reproduce this failure as I get errors: java/util/Comparator.java: In class 'org.eclipse.jdt.internal.compiler.parser.AbstractCommentParser': java/util/Comparator.java: In constructor '(org.eclipse.jdt.internal.compiler.parser.Parser)': java/util/Comparator.java:114: error: cannot find file for class org.eclipse.jdt.internal.compiler.parser.Scanner -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #5 from phil at mitre dot org 2006-02-24 19:00 --- (In reply to comment #4) > I think Paolo forgot to mention this is required by the C++ standard. Well that's different then. I realize that many non-standard things were allowed pre gcc-3.0 and that 3+ was starting to enforce more but I wasn't aware of this particular item being spec'd in the standard. So where do I submit a PR for the standard?!? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-02-24 19:04 --- Edmar -- Does changing: if (rs6000_float_gprs_string == NULL) \ rs6000_float_gprs = 2; too: if (!rs6000_explicit_options.float_gprs) \ rs6000_float_gprs = 2; work? Not just compile, but also generate the code you expect? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #5 from edmar at freescale dot com 2006-02-24 19:10 --- (In reply to comment #4) > Edmar -- > > Does changing: > > if (rs6000_float_gprs_string == NULL) \ > rs6000_float_gprs = 2; > > too: > > if (!rs6000_explicit_options.float_gprs) \ > rs6000_float_gprs = 2; > > work? Not just compile, but also generate the code you expect? > I started a build. This is a very slow target, it will take several hours... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug libmudflap/26442] ICE on valid unreachable code (and no name) when compiling with -fmudflap
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-24 19:13 --- This is ICEing when printing a warning: 1038warning (0, "mudflap cannot track %qs in stub function", 1039 IDENTIFIER_POINTER (DECL_NAME (decl))); DECL_NAME (decl) is NULL as this is a compiler generated decl. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Summary|ICE on valid unreachable|ICE on valid unreachable |code when compiling with - |code (and no name) when |fmudflap|compiling with -fmudflap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26442
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #6 from mark at codesourcery dot com 2006-02-24 19:14 --- Subject: Re: [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets edmar at freescale dot com wrote: > I started a build. This is a very slow target, it will take several hours... If you've got a fast workstation somewhere, you can set it up as a cross-compiler; should take about five minutes to build a cross compiler. But, there's not going to be a release today, so a few hours is not a big deal. I would like to fix this by changing only a known-broken header file, if possible, because that is a known-safe fix. That would allow us to support this target without risking any other platforms, where testing has been performed all along. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug middle-end/24952] ICE: RTL check: expected code 'set' or 'clobber', have 'unspec' in try_combine, at combine.c:2898
--- Comment #2 from sayle at gcc dot gnu dot org 2006-02-24 19:29 --- Subject: Bug 24952 Author: sayle Date: Fri Feb 24 19:29:34 2006 New Revision: 111425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111425 Log: PR middle-end/24952 * combine.c (try_combine): Explicitly check whether GET_CODE is a SET or a CLOBBER, instead on checking that it isn't a USE. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24952
[Bug middle-end/24952] ICE: RTL check: expected code 'set' or 'clobber', have 'unspec' in try_combine, at combine.c:2898
--- Comment #3 from roger at eyesopen dot com 2006-02-24 19:37 --- This has now been fixed on mainline. -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24952
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #23 from jakub at gcc dot gnu dot org 2006-02-24 19:45 --- Created an attachment (id=10909) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10909&action=view) gcc-trunk-pr26208.patch -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #10884|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #24 from jakub at gcc dot gnu dot org 2006-02-24 19:45 --- Created an attachment (id=10910) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10910&action=view) binutils-trunk-pr26208.patch -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #10885|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #25 from jakub at gcc dot gnu dot org 2006-02-24 19:56 --- Updated patches. Unfortunately, it seems even this is not enough as Java (and C++ as well, but there we aren't expecting to throw through signal frames), the personality routine does the same as uw_frame_state_for was doing, i.e. subtract one from ra. That's ok for most frames, unless they are immediately above a signal trampoline. In that case we shouldn't be subtracting one. But returning context->ra - fs->signal_frame in _Unwind_GetIP is a bad idea IMHO, _Unwind_GetIP should show some instruction pointer, context->ra - 1 may very well not be start of any instruction. For e.g. _Unwind_Backtrace we want context->ra as is, not adjusted. So, I'd say we should export a new function from libgcc_s, either something like _Unwind_SignalFrameContext (context) which will return context->signal_frame != 0, or _Unwind_GetIP alternative, _Unwind_GetAdjustedIP (context). In the first case, C++/Java personality routine would use _Unwind_GetIP (context) + (_Unwind_SignalFrameContext (context) ? 0 : -1) instead of the current _Unwind_GetIP (context) - 1, in the latter case it would use _Unwind_GetAdjustedIP (context) instead of _Unwind_GetIP (context) - 1. _Unwind_SignalFrameContext sounds more flexible to me. Richard, what do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #6 from pcarlini at suse dot de 2006-02-24 19:56 --- (In reply to comment #2) > Otherwise, there's great potential that the output stream (the data) > will become corrupted, even if you manage to check it state. By the way, there is no such thing as a "corrupted stream". Either the state is good, or it isn't. If, for some reason, you fear it isn't better checking it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #7 from phil at mitre dot org 2006-02-24 20:40 --- Subject: RE: Passing a NULL char* into output stream now breaks the output stream Agreed, the stream object itself hopfully doesn't get corrupted (bad), but what I was refering to was "the data" itself, not the stream object. That is, in producing an output stream with a particular structure and cadence, it IS possible for it to become corrupted by violating the protocol of that output. In my recent example I was explaining how, even if I asserted ostream state and detected that an error had occurred, I would not be able to determine WHERE the error had occurred. So I could do cout.clear() and go on but, given my example, I wouldn't know which exact << operator failed when strung together. Therefore my output would be in a indeterminent state and I may well be better off if I'd just crashed and been forced to fix the problem. phil Phil Brown Lead Software Systems Engineer Mitre CAASD [EMAIL PROTECTED] Perception is nine-tenths of the flaw. >-Original Message- >From: pcarlini at suse dot de [mailto:[EMAIL PROTECTED] >Sent: Friday, February 24, 2006 2:57 PM >To: Brown, Phil >Subject: [Bug libstdc++/26458] Passing a NULL char* into >output stream now breaks the output stream > > > >--- Comment #6 from pcarlini at suse dot de 2006-02-24 >19:56 --- >(In reply to comment #2) >> Otherwise, there's great potential that the output stream (the data) >> will become corrupted, even if you manage to check it state. > >By the way, there is no such thing as a "corrupted stream". >Either the state is >good, or it isn't. If, for some reason, you fear it isn't >better checking it. > > >-- > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458 > >--- You are receiving this mail because: --- >You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #7 from edmar at freescale dot com 2006-02-24 20:45 ---
Created an attachment (id=10911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10911&action=view)
Input program that causes ICE on gcc-4.1.0 RC2
No deal. I got an ICE now:
[root:/local/edmar/obj_gcc/powerpc-unknown-linux-gnuspe/libiberty]
/local/edmar/obj_gcc/./gcc/xgcc -B/local/edmar/obj_gcc/./gcc/
-B/root/edmar/gcc-4.1-20060206/powerpc-unknown-linux-gnuspe/bin/
-B/root/edmar/gcc-4.1-20060206/powerpc-unknown-linux-gnuspe/lib/ -isystem
/root/edmar/gcc-4.1-20060206/powerpc-unknown-linux-gnuspe/include -isystem
/root/edmar/gcc-4.1-20060206/powerpc-unknown-linux-gnuspe/sys-include -c
-DHAVE_CONFIG_H -O2 -g -O2 -I.
-I../../../src/gcc4_sources/libiberty/../include -W -Wall -pedantic
-Wwrite-strings -Wstrict-prototypes
../../../src/gcc4_sources/libiberty/floatformat.c -o floatformat.o -v
Reading specs from /local/edmar/obj_gcc/./gcc/specs
Target: powerpc-unknown-linux-gnuspe
Configured with: ../src/gcc4_sources/configure
--prefix=/root/edmar/gcc-4.1-20060206 --enable-languages=c,c++,f95
--with-as=/root/edmar/gcc-4.1-20060206/bin/as
--target=powerpc-unknown-linux-gnuspe --host=powerpc-unknown-linux-gnuspe
--enable-e500_double --disable-gdbtk --without-x
Thread model: posix
gcc version 4.1.0 20051026 (experimental)
/local/edmar/obj_gcc/./gcc/cc1 -quiet -v -I.
-I../../../src/gcc4_sources/libiberty/../include -iprefix
/local/edmar/obj_gcc/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.1.0/
-isystem /local/edmar/obj_gcc/./gcc/include -D__unix__ -D__gnu_linux__
-D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix
-Asystem=posix -DHAVE_CONFIG_H -isystem
/root/edmar/gcc-4.1-20060206/powerpc-unknown-linux-gnuspe/include -isystem
/root/edmar/gcc-4.1-20060206/powerpc-unknown-linux-gnuspe/sys-include
../../../src/gcc4_sources/libiberty/floatformat.c -quiet -dumpbase
floatformat.c -auxbase-strip floatformat.o -g -O2 -O2 -W -Wall -pedantic
-Wwrite-strings -Wstrict-prototypes -version -o /tmp/ccl8DAd9.s
ignoring nonexistent directory
"/root/edmar/gcc-4.1-20060206/powerpc-unknown-linux-gnuspe/include"
ignoring nonexistent directory
"/root/edmar/gcc-4.1-20060206/powerpc-unknown-linux-gnuspe/sys-include"
ignoring nonexistent directory
"/local/edmar/obj_gcc/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.1.0/include"
ignoring nonexistent directory
"/local/edmar/obj_gcc/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.1.0/../../../../powerpc-unknown-linux-gnuspe/include"
ignoring nonexistent directory
"/root/edmar/gcc-4.1-20060206/lib/gcc/powerpc-unknown-linux-gnuspe/4.1.0/../../../../powerpc-unknown-linux-gnuspe/include"
#include "..." search starts here:
#include <...> search starts here:
.
../../../src/gcc4_sources/libiberty/../include
/local/edmar/obj_gcc/./gcc/include
/usr/local/include
/root/edmar/gcc-4.1-20060206/include
/root/edmar/gcc-4.1-20060206/lib/gcc/powerpc-unknown-linux-gnuspe/4.1.0/include
/usr/include
End of search list.
GNU C version 4.1.0 20051026 (experimental) (powerpc-unknown-linux-gnuspe)
compiled by GNU C version 2.95.4 20010319 (prerelease/franzo/20011204).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: a377e6d60b64947de4beadd578545a5b
../../../src/gcc4_sources/libiberty/floatformat.c: In function
'floatformat_to_double':
../../../src/gcc4_sources/libiberty/floatformat.c:382: error: unrecognizable
insn:
(insn 349 347 122 12 ../../../src/gcc4_sources/libiberty/floatformat.c:350 (set
(reg:DF 11 11)
(mem/u/c/i:DF (lo_sum:SI (reg:SI 11 11)
(symbol_ref/u:SI ("*.LC5") [flags 0x2])) [12 S8 A64])) -1 (nil)
(nil))
../../../src/gcc4_sources/libiberty/floatformat.c:382: internal compiler error:
in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
--- Comment #4 from steven at gcc dot gnu dot org 2006-02-24 20:48 ---
I'm not sure how to fix this. The debug trace here says it all: We try to
force something into an operand using an optab with a mode for which we have no
handler:
Starting program: /home/steven/devel/build-trunk/gcc/cc1 -m32 -std=c99 -O1
-ftree-vectorize -march=pentium4 t.c
matmul_i4
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
matmul_i4
Breakpoint 3, move_invariant_reg (loop=0xd3f1d0, invno=0) at
loop-invariant.c:1162
1162 op = force_operand (SET_SRC (set), reg);
(gdb) p debug_rtx(inv->insn)
(insn 82 81 143 10 (set (subreg:TI (reg:V4SI 98) 0)
(lshiftrt:TI (subreg:TI (reg:V4SI 71 [ vect_cst_.47 ]) 0)
(const_int 32 [0x20]))) -1 (nil)
(nil))
$36 = void
(gdb) p debug_rtx(set)
(set (subreg:TI (reg:V4SI 98) 0)
(lshiftrt:TI (subreg:TI (reg:V4SI 71 [ vect_cst_.47 ]) 0)
(const_int 32 [0x20])))
$37 = void
(gdb) step
force_operand (value=0x2b009cc0, target=0x2b00e500) at expr.c:5793
5793 rtx subtarget = get_subtarget (target);
(gdb) b 5888
Breakpoint 4 at 0x5ceb64: file expr.c, line 5888.
(gdb) cont
Continuing.
Breakpoint 4, force_operand (value=0x2b009cc0, target=0x2b00e500)
at expr.c:5888
5888 return expand_simple_binop (GET_MODE (value), code, op1, op2,
(gdb) p debug_rtx(op1)
(subreg:TI (reg:V4SI 71 [ vect_cst_.47 ]) 0)
$38 = void
(gdb) p debug_rtx(op2)
(const_int 32 [0x20])
$39 = void
(gdb) p code
$40 = LSHIFTRT
(gdb) step
expand_simple_binop (mode=TImode, code=LSHIFTRT, op0=0x2b009c80,
op1=0x2adf5600, target=0x2b00e500, unsignedp=1,
methods=OPTAB_LIB_WIDEN)
at optabs.c:1154
1154 optab binop = code_to_optab[(int) code];
(gdb) next
1157 return expand_binop (mode, binop, op0, op1, target, unsignedp,
methods);
(gdb) p *binop
$41 = {code = LSHIFTRT, handlers = {{insn_code = CODE_FOR_nothing, libfunc =
0x0}, {
insn_code = CODE_FOR_nothing, libfunc = 0x0}, {insn_code =
CODE_FOR_nothing,
libfunc = 0x0}, {insn_code = CODE_FOR_nothing, libfunc = 0x0}, {
insn_code = CODE_FOR_nothing, libfunc = 0x0}, {insn_code =
CODE_FOR_nothing,
libfunc = 0x0}, {insn_code = CODE_FOR_nothing, libfunc = 0x0}, {
insn_code = CODE_FOR_nothing, libfunc = 0x0}, {insn_code =
CODE_FOR_nothing,
libfunc = 0x0}, {insn_code = CODE_FOR_nothing, libfunc = 0x0}, {
insn_code = CODE_FOR_lshrqi3, libfunc = 0x0}, {insn_code =
CODE_FOR_lshrhi3,
libfunc = 0x0}, {insn_code = CODE_FOR_lshrsi3, libfunc = 0x2af88960},
{
insn_code = CODE_FOR_lshrdi3, libfunc = 0x2af889a0}, {
insn_code = CODE_FOR_nothing, libfunc = 0x0} , {
insn_code = CODE_FOR_lshrv8hi3, libfunc = 0x0}, {insn_code =
CODE_FOR_lshrv4si3,
libfunc = 0x0}, {insn_code = CODE_FOR_lshrv2di3, libfunc = 0x0}, {
insn_code = CODE_FOR_nothing, libfunc = 0x0}, {insn_code =
CODE_FOR_nothing,
libfunc = 0x0}, {insn_code = CODE_FOR_nothing, libfunc = 0x0}, {
insn_code = CODE_FOR_nothing, libfunc = 0x0}, {insn_code =
CODE_FOR_nothing,
libfunc = 0x0}, {insn_code = CODE_FOR_nothing, libfunc = 0x0}, {
insn_code = CODE_FOR_nothing, libfunc = 0x0}, {insn_code =
CODE_FOR_nothing,
libfunc = 0x0}, {insn_code = CODE_FOR_nothing, libfunc = 0x0}}}
(gdb)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug c/26461] New: liveness of thread local references across function calls
I ran into this problem with stock gcc-4.0.2 on Fedora Core 2. The problem
shows when the following code is compiled with -O2: the address of "array"
seems to be cached and reused across calls to function "h". This becomes a
problem when function h saves its execution context in one thread and resumes
in another thread (thus the address of array changes before and after the
call). Is this a feature or a bug? How could I instruct gcc not to reuse thread
local addresses acrosses function calls? Thanks.
__thread int array[1];
int *f()
{
for (;;)
h(array);
return array;
}
--
Summary: liveness of thread local references across function
calls
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yichen dot xie at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
[Bug libfortran/26423] [4.1/4.2 Regression] Error on binary I/O for large array
--- Comment #15 from dir at lanl dot gov 2006-02-24 20:55 --- Hi Jerry, I tried the new version of gfortran with your patches. My real programs now run and all the old test programs worked, but of course I had to try something new. Buffer sizes of 5000 and 1 worked Ok, but I got a failure at buffer size of 1000 - [dir:~/tests/gfortran-D] dir% gfortran -o write26 write26.f [dir:~/tests/gfortran-D] dir% write26 1140854000 Abort [dir:~/tests/gfortran-D] dir% cat write26.f program test dimension idata(1000) idata(1) = -1 idata( 1000) = -2 write(11)idata idata(1) = -2 idata( 1000) = -3 write(11)idata idata(1) = -3 idata( 1000) = -4 write(11)idata idata(1) = -4 idata( 1000) = -5 write(11)idata read(11,end=1000 )idata call abort() 1000 continue backspace 11 backspace 11 backspace 11 read(11,end=1001 )idata if(idata(1).ne. -3.or.idata( 1000).ne. -4)then write(6,*)idata(1),idata( 1000) call abort() endif 1001 continue stop end [dir:~/tests/gfortran-D] 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 20060224 (experimental) [dir:~/tests/gfortran-D] dir% -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug other/26462] New: initializer element is not computable at load time
$ cat const.c
#define B0 (+1.0l/5/1/6)
const double c0 = B0; // initializer element is not computable at load time
const double c0_tab[1] = { B0 }; // initializer element is not constant
#define B1 (+1.0l/5)
const double c1 = B1; // ok.
const double c1_tab[1] = { B1 }; // initializer element is not constant
$ gcc const.c
const.c:3: error: initializer element is not computable at load time
const.c:4: error: initializer element is not constant
const.c:4: error: (near initialization for 'c0_tab[0]')
const.c:9: error: initializer element is not constant
const.c:9: error: (near initialization for 'c1_tab[0]')
gcc-4.1.0-rc1 with long-double-128 patchset.
--
Summary: initializer element is not computable at load time
Product: gcc
Version: 4.1.0
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: ppc-linux
GCC host triplet: ppc-linux
GCC target triplet: ppc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26462
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #8 from pcarlini at suse dot de 2006-02-24 21:03 --- (In reply to comment #7) > . In my recent example I was > explaining how, even if I asserted ostream state and detected that an > error had occurred, I would not be able to determine WHERE the error > had occurred. Indeed, I understand, but this is a general "issue", which has nothing to do with the specific inserter. Any time you "batch" many insertions you loose the ability to do fine grained error checking, by definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug other/26462] initializer element is not computable at load time
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 21:04 --- This is a dup of bug 26374. The problem is that the middle-end does not fold IBM 128bit long double format currently. See PR 19405 for history on why. *** This bug has been marked as a duplicate of 26374 *** -- 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=26462
[Bug middle-end/26374] Compile failure on long double
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-24 21:04 --- *** Bug 26462 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #8 from mark at codesourcery dot com 2006-02-24 21:07 ---
Subject: Re: [4.1/4.2 Regression] gcc fails to build on
powerpc e500-double targets
edmar at freescale dot com wrote:
> --- Comment #7 from edmar at freescale dot com 2006-02-24 20:45 ---
> Created an attachment (id=10911)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10911&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10911&action=view)
> Input program that causes ICE on gcc-4.1.0 RC2
>
> No deal. I got an ICE now:
> (insn 349 347 122 12 ../../../src/gcc4_sources/libiberty/floatformat.c:350
> (set
> (reg:DF 11 11)
> (mem/u/c/i:DF (lo_sum:SI (reg:SI 11 11)
> (symbol_ref/u:SI ("*.LC5") [flags 0x2])) [12 S8 A64])) -1
> (nil)
> (nil))
> ../../../src/gcc4_sources/libiberty/floatformat.c:382: internal compiler
> error:
> in extract_insn, at recog.c:2084
Bummer.
Please attach preprocessed source and configuration options so that we
have a shot at reproducing.
However, I'm afraid that means you're going to be out of luck in GCC
4.1.0; hopefully the problem will be fixed before 4.1.1!
I'd consider a patch for 4.1.0, but only if it's available very
shortly, and is obviously safe from the perspective of other targets; I
do not intend to do an RC3, so we cannot put other targets at risk.
Sorry,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #9 from phil at mitre dot org 2006-02-24 21:14 --- Subject: RE: Passing a NULL char* into output stream now breaks the output stream Yup. But by providing the ability to batch stream inserts, per the standard I presume otherwise it's not much of a stream, then you create the situation where this difficulty exists. That's kinda why I joked about "filing a PR with the standard". If the standard says you can string together inserts, and that a failed insert will "disable" the stream until the error is cleared, but not allowing you to determine where an error occurred seems a failing of the standard. BTW, I thought that GNU was never one to limit themselves to a standard when they could always rise above it and do better. phil Phil Brown Lead Software Systems Engineer Mitre CAASD [EMAIL PROTECTED] Perception is nine-tenths of the flaw. >-Original Message- >From: pcarlini at suse dot de [mailto:[EMAIL PROTECTED] >Sent: Friday, February 24, 2006 4:03 PM >To: Brown, Phil >Subject: [Bug libstdc++/26458] Passing a NULL char* into >output stream now breaks the output stream > > > >--- Comment #8 from pcarlini at suse dot de 2006-02-24 >21:03 --- >(In reply to comment #7) >> . In my recent example I was >> explaining how, even if I asserted ostream state and detected that an >> error had occurred, I would not be able to determine WHERE the error >> had occurred. > >Indeed, I understand, but this is a general "issue", which has >nothing to do >with the specific inserter. Any time you "batch" many >insertions you loose the >ability to do fine grained error checking, by definition. > > >-- > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458 > >--- You are receiving this mail because: --- >You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #9 from edmar at freescale dot com 2006-02-24 21:15 --- (In reply to comment #8) > Subject: Re: [4.1/4.2 Regression] gcc fails to build on > powerpc e500-double targets > > > > Bummer. > > Please attach preprocessed source and configuration options so that we > have a shot at reproducing. > > However, I'm afraid that means you're going to be out of luck in GCC > 4.1.0; hopefully the problem will be fixed before 4.1.1! > > I'd consider a patch for 4.1.0, but only if it's available very > shortly, and is obviously safe from the perspective of other targets; I > do not intend to do an RC3, so we cannot put other targets at risk. > > Sorry, > Mark, On comment #7 I did attach floatformat.i, also the ICE output was done with -v. The config options are visible there. Do you need more info ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-02-24 21:17 --- Subject: Re: [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion > I'm not sure how to fix this. The debug trace here says it all: We try to > force something into an operand using an optab with a mode for which we have > no > handler: I have considered several possibilities; by far the simplest seems to be to either just fail in this case in move_invariant_reg, or try calling emit_move_insn on the original SET_SRC (set) if force_operand returns NULL (http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01009.html may be useful in both cases). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream
--- Comment #10 from pcarlini at suse dot de 2006-02-24 21:22 --- (In reply to comment #9) > ... If the standard says you can > string together inserts, and that a failed insert will "disable" the > stream until the error is cleared, but not allowing you to determine > where an error occurred seems a failing of the standard. I don't, because I cannot see other options, besides a very hard fail, which means application termination. In general, one don't want that. Again, the issue is very, very general, has nothing to do with NULLs. Any time an insertion can fail for some reason (i.e., your hard disk breaks ;) you want fine grained error checking. > BTW, I thought that GNU was never one to limit themselves to a standard > when they could always rise above it and do better. This is simply not true. The standard is tracked very closely, as close as possible. We spend a lot of time on that, because also means participating to the ongoing discussions on the ISO mailing lists. If we really believe something can be done better we try to change the standard itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26458
[Bug c/26461] liveness of thread local references across function calls
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-24 21:32 --- Why do you think this can ever work in general? Also why do you need this to work this way? It seems like you are trying to deal with your own threading system instead of allowing the OS do its work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
[Bug middle-end/26461] liveness of thread local references across function calls
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
[Bug libfortran/26423] [4.1/4.2 Regression] Error on binary I/O for large array
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-02-24 21:40 --- I will have to revert back a bit and see if this too is a regression or something new. (yer killin me man! ;) ) Seriuously, though. We'll take all the testing we can get, even if it is frustrating. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
