[Bug target/26398] Wrong code generated with SPE-Extensions on PowerPC
--- Comment #2 from christian dot metzler at bmw-carit dot de 2006-02-22
08:11 ---
Simple test case:
int main(int argc, char **argv) {
float t;
char u;
t = 1.0;
u = ( ( t0.0)?-1:((t0.0)?1:0));
return (int)u;
}
Compiles e.g. on i386 and returns 1. Compiled with given C-Flags and executed
on a MPC5553 it stores 0 in u. Debugged with a Lauterbach Debugger over JTAG.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26398
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #17 from jakub at gcc dot gnu dot org 2006-02-22 08:11 --- The nop before the signal trampoline is needed for similar reason, but one signal frame lower. A normal signal frame lower in the stack will contain the exact address of the start of the trampoline (or in unusual cases another signal frame will contain some address within the trampoline's range if a thread has been signalled while executing the few trampoline instructions). That's not what is being addressed in this PR, FDE for the trampoline simply can start 1 (or more) bytes before the trampoline and there is a limited number of trampolines (the dynamically created ones are always handled by MD_FALLBACK_FRAME_STATE_FOR). This PR is about PC stored in the signal frame and used when handling the bottommost frame above the signal frame. As for PPC vDSO, if you have a spare register slot in the 0 .. DWARF_FRAME_REGISTERS range, you can certainly try to do the same as the S flag is doing. In MD_FALLBACK_FRAME_STATE_FOR it is doable (e.g. s390/linux-unwind.h was doing that, although just for 2 selected signals, which wasn't good enough, as e.g. all async signals need to be handled the same). Doing it in vDSO's .eh_frame might be far more difficult, remember that DW_CFA_expression returns address where a register is stored and there is no DW_CFA_expression_value that would be able to compute arbitrary register values and leave it on unwinder implementation to find a memory slot into which to store the value during unwinding. I don't think there are any means to store some value into certain address in .eh_frame either, so you'd need to modify kernel to store both PC and PC+1 into the sigcontext at handle_signal time and the .eh_frame to use it. Doable, but it doesn't buy you anything over just adding S flags. In both cases were are trouble with libjava when using kernels since vDSO was added till either S flag is added to the vDSO .eh_frame, or the above described ugliness is implemented in the kernel. In libjava/include/*-signal.h we need to know how will signal frame unwinding work. On most architectures we know that - MD_FALLBACK_FRAME_STATE_FOR is used and we control both M_F_F_S_F and *-signal.h in the same tree. On some architectures it is under glibc or kernel control (i386, alpha), but *-signal.h can override it, force use of M_F_F_S_F or provide its own unwind info. But on ppc it used to be M_F_F_S_F, but since November it is in kernel's hands and libjava cannot override. As the S flag doesn't affect older libgcc's, the only thing that will not work is GCC (libgcc+libgcj particularly) after (if) these patches make it in with kernel between November and now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug tree-optimization/26400] Missed jump threading on the tree level
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-22 09:55 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-22 09:55:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26400
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #18 from uweigand at gcc dot gnu dot org 2006-02-22 09:57 --- (In reply to comment #17) (e.g. s390/linux-unwind.h was doing that, although just for 2 selected signals, which wasn't good enough, as e.g. all async signals need to be handled the same). We've actually taken quite a bit of care to ensure that the position of the PC on s390 can be understood deterministically in all cases. The synchronous signals come in two flavours: - SIGSEGV and SIGBUS: here the PC points back to the instruction that we attempted and failed to execute -- returning from the signal handler would by default re-execute the failed instruction - SIGILL, SIGFPE, and SIGTRAP: here the PC points after the instruction that caused the signal condition to be raised -- returning from the signal handler would by default simply continue after that instruction For all asynchronous signals, the PC points to the first instruction we have not executed yet -- returning from the signal handler thus continues execution with that instruction. So you *need* to handle signals differently depending on what signal it is -- I'm not sure I understand why you want to remove that. What we currently have definitely works correctly for all synchronous signals on s390. As for asynchronous signals, I guess it depends on what you want to see happen here -- I'm not sure what it means to throw an exception from within an asynchronous signal handler. For unwinding purposes, I guess I can see why you would want the next instruction to show up in the backtrace, so I wouldn't mind changing the if (signal == SIGBUS || signal == SIGSEGV) to if (signal != SIGILL signal != SIGFPE signal != SIGTRAP) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-22 10:05 --- Interesting. a_3 is not single use, so we shouldn't do this. Investigating. -- rguenth 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=26406
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #17 from uros at kss-loka dot si 2006-02-22 10:15 --- Works OK with gcc-4.2 and -Os -msse -fomit-frame-pointer. -- uros at kss-loka dot si changed: What|Removed |Added CC||uros at kss-loka dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug other/26208] Serious problem with unwinding through signal frames
--- Comment #19 from jakub at gcc dot gnu dot org 2006-02-22 10:25 --- Sure, if you want to do that for s390, s390/linux-unwind.h can still do if (!signo || (*signo != 4 *signo != 5 *signo != 8)) fs-signal_frame = 1; (I think !signo - fs-signal_frame = 1; is better default, there are far more signals that have PC before insn and assuming PC before insn even when PC is after insn is less severe problem). The important thing now is only if this needs to be expressible in .eh_frame or not. Richard thinks it does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
[Bug c/26412] New: Problem with OpenMP / C
The following code causes gcc to crash when openmp is enabled:
bug2.c:
/*
* This program triggers an openmp bug in gcc 4.2:
Using built-in specs.
Target: powerpc-apple-darwin8.4.0
Configured with: /opt/local/var/db/dports/build/_opt_local_var_db_dports_sour
ces_rsync.rsync.darwinports.org_dpupdate_dports_lang_gcc42/work/gcc-4.2-20060
204/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-i
nclude-dir=/opt/local/include/gcc42/c++/ --with-gmp=/opt/local --with-mpfr=/o
pt/local --disable-multilib
Thread model: posix
gcc version 4.2.0 20060204 (experimental)
*
*
* To compile:
*
* gcc -fopenmp -c bug2.c
*
* The resulting error message is:
*
bug2.c: In function 'test':
bug2.c:34: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
*
* The program compiles without the -fopenmp flag.
*
* The system is MacOS X 10.4.5.
*
* Note: the program does nothing useful (it just for demonstrating the problem)
*
*/
extern double table_h[];
extern int dft_model;
void test() {
int ri;
double ph;
#pragma omp parallel for private(ri)
for (ri = 0; ri 100; ri++) {
ph = table_h[dft_model];
}
}
bug2.i:
# 1 bug2.c
# 1 built-in
# 1 command line
# 1 bug2.c
# 26 bug2.c
extern double table_h[];
extern int dft_model;
void test() {
int ri;
double ph;
#pragma omp parallel for private(ri)
for (ri = 0; ri 100; ri++) {
ph = table_h[dft_model];
}
}
--
Summary: Problem with OpenMP / C
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
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=26412
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-22 10:32 --- find_equivalent_equality_comparison through simplify_cond, forward_propagate_into_cond does this. I have a patch which restricts forwprop to using single-use names. Though I wonder if this is appropriate and we rather should teach VRP to infer range information for D.2354_2 from a_3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug target/26408] incorrect handling of x86 H registers in inline asm
--- Comment #2 from schwab at suse dot de 2006-02-22 10:40 --- You need to use %h2. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail|2.95 3.2 3.3.3 3.4.0 4.0.0 | |4.1.0 4.2.0 | Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26408
[Bug gcov/profile/26399] -fprofile-use fails with unnamed namespaces in 4.1.0 prerelease
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-22 11:30 --- Providing -frandom-seed=0 is a workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26399
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #18 from roger dot larsson at norran dot net 2006-02-22 11:31 --- (In reply to comment #16) raising severity because this bug makes -Os almost useless on modern x86. With gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) my testcase works but not Serge Belyshevs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug target/26415] New: [4.2 regression] m68k-linux bootstrap error during stage2
trunk 20060218, on m68k-linux: Matthias /build/buildd/gcc-snapshot-20060218/build/./prev-gcc/xgcc -B/build/buildd/gcc-snapshot-20060218/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/m68k-linux-gnu/bin/ -c -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber../../src/gcc/tree-ssa-reassoc.c -o tree-ssa-reassoc.o /tmp/ccQSa8G6.s: Assembler messages: /tmp/ccQSa8G6.s:3389: Error: value out of range /tmp/ccQSa8G6.s:3389: Error: value of 1488 too large for field of 1 bytes at 10891 make[5]: *** [tree-ssa-reassoc.o] Error 1 make[5]: Leaving directory `/build/buildd/gcc-snapshot-20060218/build/gcc' make[4]: *** [all-stage2-gcc] Error 2 make[4]: Leaving directory `/build/buildd/gcc-snapshot-20060218/build' make[3]: *** [stage2-bubble] Error 2 make[3]: Leaving directory `/build/buildd/gcc-snapshot-20060218/build' make[2]: *** [bootstrap] Error 2 -- Summary: [4.2 regression] m68k-linux bootstrap error during stage2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: m68k-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26415
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-22 12:47 ---
Of course we have the other case where we _have_ to propagate to optimize away
the test (gcc.dg/tree-ssa/20030807-2.c):
foo(int n)
{
int *space = (int *)__builtin_alloca (n);
if (space == 0)
abort ();
else
bar (space);
}
where there is a 2nd use of space:
foo (n)
{
int * space;
void * D.1899;
long unsigned int D.1898;
bb 2:
D.1898_2 = (long unsigned int) n_1;
D.1899_3 = __builtin_alloca (D.1898_2);
space_4 = (int *) D.1899_3;
if (space_4 == 0B) goto L0; else goto L1;
L0:;
abort ();
L1:;
bar (space_4);
return;
}
So I think extending VRP is the only way to get both testcases optimized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-02-22 12:49 --- Created an attachment (id=10891) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10891action=view) patch restricting forwprop Patch that apart from regressing gcc.dg/tree-ssa/20030807-2.c bootstrapped and tested ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug target/26415] [4.2 regression] m68k-linux bootstrap error during stage2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||assemble-failure, build Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26415
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-22 12:58 --- (In reply to comment #6) Patch that apart from regressing gcc.dg/tree-ssa/20030807-2.c bootstrapped and tested ok. There is no regressions here as this test is already failing before your patch, see PR 26344. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug middle-end/26412] Problem with OpenMP / C
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 13:01 --- Confirmed, backtrace: #0 0x00105ff4 in omp_add_variable (ctx=0x429008e0, decl=0x41edae70, flags=5) at /Users/pinskia/src/gcc/local/gcc/gcc/gimplify.c:4271 #1 0x00105fc0 in omp_add_variable (ctx=0x429008e0, decl=0x41edae70, flags=5) at /Users/pinskia/src/gcc/local/gcc/gcc/gimplify.c:4253 #2 0x001065fc in omp_notice_variable (ctx=0x578630, decl=0x429008e0, in_code=108 'l') at /Users/pinskia/src/gcc/local/gcc/gcc/gimplify.c:4390 #3 0x001064dc in omp_notice_variable (ctx=0x578630, decl=0x429008e0, in_code=108 'l') at /Users/pinskia/src/gcc/local/gcc/gcc/gimplify.c:4411 #4 0x00106704 in gimplify_var_or_parm_decl (expr_p=0x5) at /Users/pinskia/src/gcc/local/gcc/gcc/gimplify.c:1599 #5 0x001148d4 in gimplify_compound_lval (expr_p=0x41ee0440, pre_p=0xb0cc, post_p=0xb0d0, fallback=fb_rvalue) at /Users/pinskia/src/gcc/local/gcc/gcc/gimplify.c:1660 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code, openmp Last reconfirmed|-00-00 00:00:00 |2006-02-22 13:01:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26412
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #8 from patchapp at dberlin dot org 2006-02-22 13:10 --- Subject: Bug number PR26406 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01754.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug c++/26417] New: typeid(typeid(*object)) ICE on g++ 3.x / i686
The code below generates a compiler ICE with g++ 3.3 (debian stable),
g++ 3.4 (debian testing):
[pollindd] ~ g++-3.3 -c ice-typeid.cc
1036
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
1037
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.
Environment:
System: Linux pollindd 2.6.15.2-adeos #2 PREEMPT Wed Feb 15 12:00:00 CET
2006 i686 GNU/Linux
Architecture: i686
host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
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
How-To-Repeat:
Initial source code (5 bugs included: play with -DBUG=x option to
activate them):
#include typeinfo
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
Output from g++ 3.3 -E :
# 1 ice-typeid.cc
# 1 built-in
# 1 command line
# 1 ice-typeid.cc
# 1 /usr/include/c++/3.3/typeinfo 1 3
# 38 /usr/include/c++/3.3/typeinfo 3
# 1 /usr/include/c++/3.3/exception 1 3
# 40 /usr/include/c++/3.3/exception 3
extern C++ {
namespace std
{
# 52 /usr/include/c++/3.3/exception 3
class exception
{
public:
exception() throw() { }
virtual ~exception() throw();
virtual const char* what() const throw();
};
class bad_exception : public exception
{
public:
bad_exception() throw() { }
virtual ~bad_exception() throw();
};
typedef void (*terminate_handler) ();
typedef void (*unexpected_handler) ();
terminate_handler set_terminate(terminate_handler) throw();
void terminate() __attribute__ ((__noreturn__));
unexpected_handler set_unexpected(unexpected_handler) throw();
void unexpected() __attribute__ ((__noreturn__));
# 100 /usr/include/c++/3.3/exception 3
bool uncaught_exception() throw();
}
namespace __gnu_cxx
{
# 113 /usr/include/c++/3.3/exception 3
void __verbose_terminate_handler ();
}
}
# 39 /usr/include/c++/3.3/typeinfo 2 3
extern C++ {
namespace __cxxabiv1
{
class __class_type_info;
}
# 55 /usr/include/c++/3.3/typeinfo 3
namespace std
{
class type_info
{
public:
virtual ~type_info();
private:
type_info operator=(const type_info);
type_info(const type_info);
protected:
const char *__name;
protected:
explicit type_info(const char *__n): __name(__n) { }
public:
const char* name() const
{ return __name; }
# 101 /usr/include/c++/3.3/typeinfo 3
bool before(const type_info __arg) const
{ return __name __arg.__name; }
bool operator==(const type_info __arg) const
{ return __name == __arg.__name; }
bool operator!=(const type_info __arg) const
{ return !operator==(__arg); }
public:
virtual bool __is_pointer_p() const;
virtual bool __is_function_p() const;
virtual bool __do_catch(const type_info *__thr_type, void **__thr_obj,
unsigned __outer) const;
virtual bool __do_upcast(const __cxxabiv1::__class_type_info *__target,
void **__obj_ptr) const;
};
class bad_cast : public exception
{
public:
bad_cast() throw() { }
virtual ~bad_cast() throw();
};
class bad_typeid : public exception
{
public:
bad_typeid () throw() { }
virtual ~bad_typeid() throw();
};
}
}
# 3 ice-typeid.cc 2
class BaseB
{
public:
virtual ~BaseB() {}
};
# 40 ice-typeid.cc
int bug5(BaseB * o)
{
int i;
return (typeid(typeid(*o)) == typeid(i));
}
Output from g++ 3.4 -E :
# 1 ice-typeid.cc
# 1 built-in
# 1 command line
# 1 ice-typeid.cc
# 1 /usr/include/c++/3.4/typeinfo 1 3
# 38 /usr/include/c++/3.4/typeinfo 3
# 1 /usr/include/c++/3.4/exception 1 3
# 40 /usr/include/c++/3.4/exception 3
extern C++ {
namespace std
{
# 52 /usr/include/c++/3.4/exception 3
[Bug c++/26418] New: App with assignment to *(ptr + member_returning_zero()) segfaults
/*
This code segfaults when executed on gcc 4.01 on i586/linux (mandriva 2006)
Works fine on gcc 3.x - couldn't find a newer version to test it on.
PS I couldn't find anything in your bug writing guidelines what to put in
host triplet etc...
gcc -v:
Using built-in specs.
Target: i586-mandriva-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib --mandir=/usr$
Thread model: posix
gcc version 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)
*/
typedef unsigned int uint;
char* dummy;
struct Array {
char** ptr;
void push(char* i) { *(ptr+alloc()) = i; }
uint alloc() {
ptr = dummy;
return 0;
}
};
int main()
{
Array test;
char* arg = fred;
test.push(arg);
// can you please check check *test.ptr == arg, as that was what led
// me to finding the bug wasn't
}
--
Summary: App with assignment to *(ptr + member_returning_zero())
segfaults
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fuchsia dot groan at virgin dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26418
[Bug c++/26418] App with assignment to *(ptr + member_returning_zero()) segfaults
--- Comment #1 from fuchsia dot groan at virgin dot net 2006-02-22 13:41 --- No compile options just g++ test.cpp generates faulty code -- fuchsia dot groan at virgin dot net changed: What|Removed |Added CC||fuchsia dot groan at virgin ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26418
[Bug middle-end/26412] Problem with OpenMP / C
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 13:59 --- Also confirmed on x86_64-linux-gnu with the same backtrace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26412
[Bug c++/26418] App with assignment to *(ptr + member_returning_zero()) segfaults
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 14:04 --- ptr+alloc() The C and the C++ standard does not say which of ptr and alloc() is evaluated first so GCC is producing code which evaluates ptr before calling alloc which is ok for C and C++. *** 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=26418
[Bug c/11751] wrong evaluation order of an expression
--- Comment #59 from pinskia at gcc dot gnu dot org 2006-02-22 14:04 --- *** Bug 26418 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fuchsia dot groan at virgin ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug target/25218] [4.0 Regression] ICE : in compensate_edge, at reg-stack.c:2795
--- Comment #9 from jv244 at cam dot ac dot uk 2006-02-22 14:08 --- Added Jan Hubicka, since he seems the original author of the code that fails (hope I get it right this time) and might have an idea on how to fix this in time for 4.0.3 -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC|nathan at codesourcery dot |hubicka at gcc dot gnu dot |com |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25218
[Bug c++/26417] typeid(typeid(*object)) ICE on g++ 3.x / i686
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 14:09 --- Yes this is a dup of bug 25357. *** This bug has been marked as a duplicate of 25357 *** -- 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=26417
[Bug c++/25357] [3.4/4.0 Regression] ICE in typeid
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-22 14:09 --- *** Bug 26417 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||david dot decotigny at poly ||dot in2p3 dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25357
[Bug c++/26417] typeid(typeid(*object)) ICE on g++ 3.x / i686
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 14:10 --- The reason why I say it is a dup is because it works in 4.1.0 and the mainline just fine and 4.0.3 gave the same ICE for both of the bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26417
[Bug other/26419] New: -ftree-vectorizer-verbose=n documentation is terse
The documentation for -ftree-vectorizer-verbose doesn't give the slightest hints on useful values for n: -ftree-vectorizer-verbose=n This option controls the amount of debugging output the vectorizer prints. This information is written to standard error, unless -fdump-tree-all or -fdump-tree-vect is specified, in which case it is output to the usual dump listing file, .vect. -- Summary: -ftree-vectorizer-verbose=n documentation is terse Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26419
[Bug middle-end/26412] ICE with external arrays using OpenMP
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-02-22 14:18
---
Even shorter testcase:
==
extern int table[];
void foo()
{
#pragma omp parallel
table[0];
}
==
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Summary|Problem with OpenMP / C |ICE with external arrays
||using OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26412
[Bug tree-optimization/26419] -ftree-vectorizer-verbose=n documentation is terse
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 14:19 --- Confirmed. -- 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-22 14:19:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26419
[Bug tree-optimization/26420] New: -ftree-vectorizer-verbose=1 prints unvectorized loops information
tramp3d-v4.cpp:3740: note: vectorized 0 loops in function. tramp3d-v4.cpp:3740: note: vectorized 0 loops in function. tramp3d-v4.cpp:50941: note: vectorized 0 loops in function. tramp3d-v4.cpp:3740: note: vectorized 0 loops in function. tramp3d-v4.cpp:3740: note: vectorized 0 loops in function. etc. if (vect_print_dump_info (REPORT_VECTORIZED_LOOPS)) fprintf (vect_dump, vectorized %u loops in function.\n, num_vectorized_loops); here we should check if num_vectorized_loops is 0 or verbosity level includes REPORT_UNVECTORIZED_LOOPS. Though even in this case the note does not provide any useful information. -- Summary: -ftree-vectorizer-verbose=1 prints unvectorized loops information Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26420
[Bug c/26407] ICE
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 14:27 --- This works for me, at both -O2 and -O0. Please report a new bug if you can give more information and don't put the preprocessed source in the gccbug. Attach it after the fact. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26407
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 14:31 --- I have seen a bug like this before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug c/26411] -Wstrict-aliasing does not enable analysis
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-22 14:32 --- (In reply to comment #2) Still, it would be lots better if warning options simply enabled the necessary analysis. It is very hard to do so as the warnings are based on the information gathered from -fstrict-aliasing. Since this is documented unlike the orginal bug suggested, I am going to close this as invalid. -- 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=26411
[Bug tree-optimization/26420] -ftree-vectorizer-verbose=1 prints unvectorized loops information
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 14:34 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-22 14:34:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26420
[Bug c/26407] ICE
--- Comment #2 from rootkit85 at yahoo dot it 2006-02-22 14:40 --- I have broken RAM. Sorry for complaining gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26407
[Bug c/26171] #pragma omp threadprivate requires -funit-at-a-time
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-02-22 15:10
---
Confirmed.
Even shorter testcase:
==
int i=0;
#pragma omp threadprivate (i)
void foo()
{
i=0;
}
==
--
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||monitored
Last reconfirmed|-00-00 00:00:00 |2006-02-22 15:10:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26171
[Bug other/25914] strsignal.c:558: warning: comparison between signed and unsigned
--- Comment #5 from danglin at gcc dot gnu dot org 2006-02-22 15:22 --- The libiberty version is documented as unsigned and has been this way for many years. The Open Group has a strawman proposal which may be submitted to the Austin Group for addition to POSIX in its next release. It uses a signed int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25914
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #9 from law at redhat dot com 2006-02-22 15:24 --- Subject: Re: Fowardprop does harm for VRP to figure out if a point is non zero On Wed, 2006-02-22 at 10:32 +, rguenth at gcc dot gnu dot org wrote: --- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-22 10:32 --- find_equivalent_equality_comparison through simplify_cond, forward_propagate_into_cond does this. I have a patch which restricts forwprop to using single-use names. Though I wonder if this is appropriate and we rather should teach VRP to infer range information for D.2354_2 from a_3. Please don't. I'm already aware of this issue and looking at a better solution. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug tree-optimization/26421] New: tree-ssa-alias.c:find_used_portions considers foo(var) use all elements of var
The function in question should ignore ADDR_EXPRs that appear inside CALL_EXPR
parameter lists so that we, for
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
void foo(void)
{
Foo a;
a.i = 1;
bar(a);
}
do not create SFTs for all elements of a, but only for the first. This
will reduce clobbers at call sites from
bb 2:
# SFT.2_2 = V_MUST_DEF SFT.2_1;
a.i = 1;
# SFT.0_5 = V_MAY_DEF SFT.0_3;
# SFT.1_6 = V_MAY_DEF SFT.1_4;
# SFT.2_7 = V_MAY_DEF SFT.2_2;
bar (a);
to
bb 2:
# SFT.2_2 = V_MUST_DEF SFT.2_1;
a.i = 1;
# SFT.2_7 = V_MAY_DEF SFT.2_2;
bar (a);
it especially would reduce the amounts of SFTs we generate for gfortran
struct st_parm, which usually only gets a few fields written to and then
it's address is passed to a function.
--
Summary: tree-ssa-alias.c:find_used_portions considers foo(var)
use all elements of var
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: memory-hog, compile-time-hog, alias
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26421
[Bug tree-optimization/26421] tree-ssa-alias.c:find_used_portions considers foo(var) use all elements of var
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 16:02 ---
Really for this example:
For this case V_MAY_DEF's are dead anyways at least for the other SFT's besides
the one for a.i.
Try thinking what about:
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
void bar1(Foo);
void foo(void)
{
Foo a;
a.i = 1;
bar(a);
bar1(a);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26421
[Bug target/26408] incorrect handling of x86 H registers in inline asm
--- Comment #3 from sabre at nondot dot org 2006-02-22 16:11 --- Fair enough. Shouldn't this be diagnosed with an error though? -Chris -- sabre at nondot dot org changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26408
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #10 from law at redhat dot com 2006-02-22 16:22 --- Subject: Re: Fowardprop does harm for VRP to figure out if a point is non zero On Wed, 2006-02-22 at 12:47 +, rguenth at gcc dot gnu dot org wrote: A little history... DOM was pretty clever in that it had the ability to backwards propagate some non-null ranges. That code was written to make DOM's non-null tracking relatively immune to things like comparison simplification. It was quick, simple and relatively effective. We *really* don't want to do that in VRP. First it violates a fundamental principle designed to ensure VRP terminates. Namely that we don't move backward in the lattice. ie, we don't allow VR_VARYING - VR_RANGE/VR_ANTI_RANGE state transitions. I briefly toyed with the idea of doing the backward range propagation after all the forward propagation was done, but before substitution/simplifications. There's a handful of implementation issues with this approach and it will likely result in a measurable compile-time hit due to the extra ASSERT_EXPRs. It's something I'm still pondering, but it's not my favored solution ATM. What I'm seriously looking at and still evaluating is delaying the forwprop pass. For the initial stuff I looked at it seems like a *much* better solution -- not only does it allow VRP to catch more of the non-null stuff, but it seems to help forwprop and the following DOM pass as well. I'll be returning to this once we've reached closure on the Ada regressions. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug tree-optimization/26421] tree-ssa-alias.c:find_used_portions considers foo(var) use all elements of var
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-22 16:23 --- I get bb 2: # SFT.0D.1534_2 = V_MUST_DEF SFT.0D.1534_1; aD.1532.iD.1521 = 1; # SFT.0D.1534_3 = V_MAY_DEF SFT.0D.1534_2; bar (aD.1532); # SFT.0D.1534_4 = V_MAY_DEF SFT.0D.1534_3; bar2 (aD.1532); for this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26421
[Bug libstdc++/26132] tr1/hashtable: rehash not implemented
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26132
[Bug target/25603] [4.1 Regression]: Miscompiled FORTRAN program
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-02-22 16:30 --- As this is a wrong-code regression for 4.1 (albeit on ia64-linux), Mark should re-consider the priority and maybe allow this patch in. And the patch submitter should have asked for that in the first place (and can now ask for it please). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
[Bug libfortran/26423] New: Error on binary I/O for large array
Absoft fortran shows the correct answer - gfortran has a problems with writing and reading a large arrays (If I set the array size to 800, it works Ok.) - [dranta:~/tests/gfortran-D] dir% f90 -o testio7 testio7.f [dranta:~/tests/gfortran-D] dir% testio7 1.00 -1.00 2.00 -2.00 3.00 -3.00 4.00 -4.00 5.00 -5.00 [dranta:~/tests/gfortran-D] dir% gfortran -o testio7 testio7.f [dranta:~/tests/gfortran-D] dir% testio7 1.00 -1.00 1.00 -1.00 1.00 -1.00 1.00 -1.00 1.00 -1.00 [dranta:~/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 20060222 (experimental) [dranta:~/tests/gfortran-D] dir% cat testio7.f program test implicit real*8 (a-h,o-z) dimension a(8476) istoh=8476 do 10 j=1,5 a(1)=j a(istoh)=-j write(2)a 10 continue rewind 2 do 20 i=1,5 read(2)a write(6,*)a(1),a(istoh) 20 continue stop end -- Summary: Error on binary I/O for large array Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran 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=26423
[Bug libstdc++/26424] New: tr1/unordered vs 64-bit machines
The number of buckets is currently limited to ~2^32 (see X::primes). This is a serious issue: for correctness, rehash(n) for n 2^32 should throw and do nothing, in order not to violate the post-conditions in Table 21. We have various options: as suggested by Howard off-line, we could well compute at run-time prime-numbers. Otherwise, mid-term, if we cannot extend the maximum number of bucket we have to add throws to the rehashing functions. -- Summary: tr1/unordered vs 64-bit machines Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26424
[Bug target/25603] [4.1 Regression]: Miscompiled FORTRAN program
--- Comment #19 from hjl at gcc dot gnu dot org 2006-02-22 16:59 --- Subject: Bug 25603 Author: hjl Date: Wed Feb 22 16:59:45 2006 New Revision: 111365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111365 Log: 2006-02-22 H.J. Lu [EMAIL PROTECTED] PR target/25603 * gfortran.dg/pr25603.f: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr25603.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
[Bug target/25603] [4.1 Regression]: Miscompiled FORTRAN program
--- Comment #20 from hjl at lucon dot org 2006-02-22 17:04 --- I don't want to see this patch hold up 4.1.0 release. I will ask it be applied to the 4.1 branch when it is open. But it is Mark's call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
[Bug c/26425] New: ice on valid C code with flag -Os
I just tried to compile a recent Linux kernel with a recent GNU C++ compiler version 4.2 snapshot 20060218. The compiler snapshot said /home/dcb/gnu/42-20060218/results/bin/gcc -g -O3 -Wall -Wp,-MD,security/keys/.keyring.o.d -nostdinc -isystem /home/dcb/gnu/42-20060218/results/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -Os -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -march=k8 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wdeclaration-after-statement -Wno-pointer-sign-DKBUILD_BASENAME=keyring -DKBUILD_MODNAME=keyring -c -o security/keys/.tmp_keyring.o security/keys/keyring.c In file included from include/asm/smp.h:22, from include/linux/smp.h:19, from include/linux/sched.h:26, from include/linux/module.h:10, from security/keys/keyring.c:12: include/asm/apic.h: In function 'apic_write_atomic': include/asm/apic.h:47: warning: value computed is not used security/keys/keyring.c: In function 'keyring_clear_rcu_disposal': security/keys/keyring.c:970: internal compiler error: in set_value_range, at tree-vrp.c:150 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. -Os flag required. -- Summary: ice on valid C code with flag -Os Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86+64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
[Bug libstdc++/26132] tr1/hashtable: rehash not implemented
--- Comment #1 from paolo at gcc dot gnu dot org 2006-02-22 17:06 --- Subject: Bug 26132 Author: paolo Date: Wed Feb 22 17:05:58 2006 New Revision: 111366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111366 Log: 2006-02-22 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/26132 * include/tr1/hashtable (hashtable::rehash): Define. * testsuite/tr1/6_containers/unordered/hashtable/26132.cc: New. * include/tr1/hashtable: Trivial formatting and stylistic fixes. * testsuite/tr1/headers.cc: remove tr1/hashtable, not a tr1 header, only an implementation detail. Added: trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/hashtable/26132.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/hashtable trunk/libstdc++-v3/testsuite/tr1/headers.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26132
[Bug c/26425] ice on valid C code with flag -Os
--- Comment #1 from dcb314 at hotmail dot com 2006-02-22 17:06 --- Created an attachment (id=10892) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10892action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
[Bug libstdc++/26424] tr1/unordered vs 64-bit machines
--- Comment #1 from falk at debian dot org 2006-02-22 17:11 --- Just curious: is the assumption of prime-size buckets hardwired in the TR? Otherwise, the obvious alternative would be to use power-of-two sizes, which are much faster in access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26424
[Bug libstdc++/26142] global debug namespace clashes everywhere
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-02-22 17:17 --- This is now fixed to my satisfaction. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26142
[Bug c++/26291] [3.4/4.0/4.1/4.2 regression] Invalid ellipsis in operator not diagnosed
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-02-22 17:22 --- Subject: Bug 26291 Author: reichelt Date: Wed Feb 22 17:22:08 2006 New Revision: 111367 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111367 Log: PR c++/26291 * decl.c (grok_op_properties): Check for ellipsis in arguments of operators. * g++.dg/other/ellipsis1.C: New test. * g++.dg/parse/operator4.C: Adjust error marker. Added: trunk/gcc/testsuite/g++.dg/other/ellipsis1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/operator4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26291
[Bug libstdc++/26424] tr1/unordered vs 64-bit machines
--- Comment #2 from pcarlini at suse dot de 2006-02-22 17:23 --- (In reply to comment #1) Just curious: is the assumption of prime-size buckets hardwired in the TR? Otherwise, the obvious alternative would be to use power-of-two sizes, which are much faster in access. Yes. Really, I have yet to study the issue in detail (Knuth...), I'm going to do that. For sure TR1 doesn't mandate a specific policy, but we have got a default policy, prime_rehash_policy, which is definitely well known and used elsewhere, it would be nice to fix it, to begin with ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26424
[Bug libstdc++/25815] [4.1 regression] libstdc++ testsuite: ext/pb_assoc/example/erase_if.cc execution test
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-02-22 17:26 --- HP, I also don't know what is going on here, but it seems unlikely that the libstdc++ code is to blame, just because there's been no change to this part of libstdc++ in quite a while. One thing you could check, if you have various compilers for cris around, is to try to compile newer libstdc++ sources with a known good cris compiler. That would at least let you know where things are problematic, without digging too far into this. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
[Bug tree-optimization/26425] ice on valid C code with flag -Os
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 17:34 --- Reducing (which means I can reproduce this ICE). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
[Bug c++/26291] [3.4/4.0/4.1 regression] Invalid ellipsis in operator not diagnosed
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-02-22 17:35 --- Fixed on mainline. Waiting for the 4.1 branch to reopen. Testing on the 4.0 and 3.4 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1/4.2 regression]|[3.4/4.0/4.1 regression] |Invalid ellipsis in operator|Invalid ellipsis in operator |not diagnosed |not diagnosed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26291
[Bug tree-optimization/26425] [4.2 Regression] ice on valid C code with flag -Os
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 17:55 --- It is ICEing in the last VRP. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org Severity|normal |critical Summary|ice on valid C code with|[4.2 Regression] ice on |flag -Os|valid C code with flag -Os Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
[Bug tree-optimization/26425] [4.2 Regression] ice on valid C code with flag -Os
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-22 17:59 ---
Reduced testcase:
struct keyring_list {
struct key *keys[0];
};
void keyring_destroy(struct keyring_list *keyring, unsigned short a)
{
int loop;
for (loop = a - 1; loop = 0; loop--)
key_put(keyring-keys[loop]);
}
--
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-22 17:59:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
[Bug libstdc++/26424] tr1/unordered vs 64-bit machines
--- Comment #3 from pcarlini at suse dot de 2006-02-22 18:01 --- ... something considered obvious in the literature is that the size policy goes together with the range-hashing function: e.g., an exponential size-policy would not work well together with our default modulo range-hashing function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26424
[Bug tree-optimization/26425] [4.2 Regression] ice on valid C code with flag -Os
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07 --- Hmm, for some reason the Type's TYPE_MAX_VALUE is null. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
[Bug libfortran/26423] Error on binary I/O for large array
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 18:10 --- Hmm, this worked in 4.0.3 at least on x86_64-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug libfortran/26423] Error on binary I/O for large array
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 18:11 --- But not with 4.2.0 on x86_64-linux so confirmed. -- 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-22 18:11:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug tree-optimization/26425] [4.2 Regression] ice on valid C code with flag -Os
--- Comment #6 from law at redhat dot com 2006-02-22 18:18 --- Subject: Re: [4.2 Regression] ice on valid C code with flag -Os On Wed, 2006-02-22 at 18:07 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07 --- Hmm, for some reason the Type's TYPE_MAX_VALUE is null. I've never seen that before..Definitely odd. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
[Bug c++/26426] New: Type layout bug
Consider:
struct A { virtual ~A(); }; // 4
struct B { virtual ~B(); }; // 4
struct X : virtual public A,
virtual public B { // 8
};
struct Y : virtual public B { // 4
virtual ~Y();
};
struct Z : virtual public X, public Y { // 8
Z();
};
Z::Z() {}
In this example, the DECL_SIZE_UNIT of Z is 8 bytes. Here, the FIELD_DECL
corresponding to it's Y superclass has an offset of 0 bytes and size 4 bytes.
The FIELD_DECL for the X superclass has an offset of 4 bytes and and a size of
8 bytes, which means that the end of the object is 12 bytes, despite the fact
that Z has a DECL_SIZE_UNIT of 8 bytes.
-Chris
--
Summary: Type layout bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26426
[Bug libstdc++/26142] global debug namespace clashes everywhere
--- Comment #9 from mueller at gcc dot gnu dot org 2006-02-22 18:53 --- Yes, thanks. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26142
[Bug target/26389] Darwin does not support -fsection-anchors
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 18:57 --- I am working on this again. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-22 18:57:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26389
[Bug target/26427] New: Regressions with -fsection-anchors with zero sized structs
Testcase:
struct a {};
static const int d = 1;
static const struct a b = {};
static const int c = 1;
int f(const int *, const struct a *, const int*, const int*);
int g(void)
{
return f(c, b, d, c);
}
int f(const int *b, const struct a *c, const int *d, const int *e)
{
return *b == *d;
}
int main(void)
{
if (!g())
__builtin_abort();
}
-
What is happening is that the size for b is being calcuated wrong in the anchor
code, I don't know how to fix this yet.
--
Summary: Regressions with -fsection-anchors with zero sized
structs
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
BugsThisDependsOn: 26389
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug target/26427] Regressions with -fsection-anchors with zero sized structs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 19:00 --- This causes a lot of the gfortran testsuite to fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug target/26389] Darwin does not support -fsection-anchors
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 19:19 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01774.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|26427 | nThis|| URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg01774.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26389
[Bug c++/26428] New: Buged FLoat Numbers in GCC
When using g++ as a compiler and my program is trying to substract to floats that have the same ending digits, after comma, or even when the digits are not even or odd at the same time the returned number is buged! For example: 105.8 - 108.5 === 2.67 583.4 - 1583.4 === 1000.099976 The same problem might exists in gcc. Check It! Geoge Delaportas Dimitris Vlachos -- Summary: Buged FLoat Numbers in GCC Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: g dot delaportas at gmail dot com GCC target triplet: GCC / G++ 3.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 20:24 --- And why do you think this is a bug? Floating point is not the same as math as you would do on paper. Also where is the testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #2 from g dot delaportas at gmail dot com 2006-02-22 20:29 --- It is abdolutely true and well known that 1583.5-583.4=1000.1 Its defenate. Simple mathematics Its not my problem if u have problems with maths! Try your calculators and pleas do not reply stupid thing! CRITICAL BUG - George Delaportas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 20:31 --- (In reply to comment #2) It is abdolutely true and well known that 1583.5-583.4=1000.1 Who said that 1000.1 can be repesented exactly in the computer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #4 from g dot delaportas at gmail dot com 2006-02-22 20:34 --- (In reply to comment #3) (In reply to comment #2) It is abdolutely true and well known that 1583.5-583.4=1000.1 Who said that 1000.1 can be repesented exactly in the computer? okso explain to me why this can not be wrong and why it should not happen. All my other calculators amd PCs are wrong and gcc is OK? For God shake.please! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 20:44 --- Well the caculator is using higher precission (maybe even unlimited) floating point than what your testcase would look like. Again where is the testcase? Also you should go read some papers about floating point in computers. Like: http://portal.acm.org/citation.cfm?id=103163 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #6 from g dot delaportas at gmail dot com 2006-02-22 20:46 --- (In reply to comment #5) Well the caculator is using higher precission (maybe even unlimited) floating point than what your testcase would look like. Again where is the testcase? Also you should go read some papers about floating point in computers. Like: http://portal.acm.org/citation.cfm?id=103163 TEST CASE Now Please Assign Values To The GPins (Values:Binary,Integer,Float) Please Set Min And Max Values (Example:5.5,20.6) GPin 1 Choice (Min,Max):105.8,108.8 ELA OOOPA:3.00 GPin 2 Choice (Min,Max):105.8,108.5 ELA OOOPA:2.67 GPin 3 Choice (Min,Max):583.4,1583.4 ELA OOOPA:1000.00 GPin 4 Choice (Min,Max):583.4,1583.5 ELA OOOPA:1000.099976 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-22 20:48 --- (In reply to comment #6) TEST CASE I mean some source code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug libfortran/26423] Error on binary I/O for large array
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-02-22 20:50 --- Confirmed on i686-linux (trunk) too: $ cat testio.f integer :: a(8476) a(1) = 1 write(2) a a(1) = 2 write(2) a rewind 2 read(2) a write(*,*) a(1) read(2) a write(*,*) a(1) end $ g77 testio.f ./a.out 1 2 $ gfortran testio.f ./a.out 1 1 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2006-02-22 18:11:37 |2006-02-22 20:50:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-22 20:50 --- User doesn't understand number representations in computers. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #9 from g dot delaportas at gmail dot com 2006-02-22 20:53 --- (In reply to comment #7) (In reply to comment #6) TEST CASE I mean some source code. Oh the source code is rather simple float Val1,Val2,Val3; Val1=1583.5; Val2=583.4; Val3=Val2-Val1; printf(Value:%f\n,Val3); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-02-22 20:55 --- So I suppose VRP cannot see backwards for i_2 = j_1; if (i_2 == 0) return j_1; ? (of course copyprop would clean this up, but suppose for a moment this gets to VRP) If it can see that i_1 is zero at the point of the return statement then we can teach VRP to take a_1 = (T *)x_1; simply as copy, canonicalizing all pointer types to (void*) for the sake of VRP (which would also avoid generating extra permanent integer constants with various types in the pool). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #10 from g dot delaportas at gmail dot com 2006-02-22 20:56 --- If u don't understand that this is not right then u have a big problem in mathematics cause bc,xcalc or whatever and all the other compilers i have tested in other operating systems returned the actual and right values am i crazy? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug tree-optimization/26429] New: Call clobbering cannot tell different stack locals with same type apart
For
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
void foo(void)
{
{
Foo a;
bar(a);
}
{
Foo b;
bar(b);
}
}
we have in the alias1 dump:
foo ()
{
struct Foo b;
struct Foo a;
bb 2:
# a_3 = V_MAY_DEF a_1;
# b_4 = V_MAY_DEF b_2;
bar (a);
# a_5 = V_MAY_DEF a_3;
# b_6 = V_MAY_DEF b_4;
bar (b);
return;
}
The testcase is actually modeled after what the fortran frontend produces
for I/O operations, it adds one instance of Foo per I/O call, and the clobbers
keep building up. Now consider having SFTs for the _huge_ fortran st_parm
structure...
--
Summary: Call clobbering cannot tell different stack locals with
same type apart
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, memory-hog, compile-time-hog, alias
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26429
[Bug c++/26430] New: Buged FLoat Numbers in GCC
When using g++ as a compiler and my program is trying to substract to floats that have the same ending digits, after comma, or even when the digits are not even or odd at the same time the returned number is buged! For example: 105.8 - 108.5 === 2.67 1583.5- 583.4 === 1000.099976 The same problem might exists in gcc. Check It! Geoge Delaportas Dimitris Vlachos -- Summary: Buged FLoat Numbers in GCC Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: g dot delaportas at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26430
[Bug c++/26431] New: Buged FLoat Numbers in GCC
When using g++ as a compiler and my program is trying to substract to floats that have the same ending digits, after comma, or even when the digits are not even or odd at the same time the returned number is buged! For example: 105.8 - 108.5 === 2.67 1583.5- 583.4 === 1000.099976 The same problem might exists in gcc. Check It! Geoge Delaportas Dimitris Vlachos -- Summary: Buged FLoat Numbers in GCC Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: g dot delaportas at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26431
[Bug c++/26430] Buged FLoat Numbers in GCC
--- Comment #1 from pcarlini at suse dot de 2006-02-22 21:15 --- *** This bug has been marked as a duplicate of 26428 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26430
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #11 from pcarlini at suse dot de 2006-02-22 21:15 --- *** Bug 26430 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26431] Buged FLoat Numbers in GCC
--- Comment #2 from pcarlini at suse dot de 2006-02-22 21:16 --- *** This bug has been marked as a duplicate of 26428 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26431
[Bug c++/26428] Buged FLoat Numbers in GCC
--- Comment #12 from pcarlini at suse dot de 2006-02-22 21:16 --- *** Bug 26431 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
[Bug c++/26431] Buged FLoat Numbers in GCC
--- Comment #1 from g dot delaportas at gmail dot com 2006-02-22 21:15 --- There is no EXCUSES for higher or lower bitsthe numbers are WRONG and this should be fixed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26431
[Bug tree-optimization/26425] [4.2 Regression] ice on valid C code with flag -Os
--- Comment #7 from law at redhat dot com 2006-02-22 21:30 --- Subject: Re: [4.2 Regression] ice on valid C code with flag -Os On Wed, 2006-02-22 at 18:07 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07 --- Hmm, for some reason the Type's TYPE_MAX_VALUE is null. Ah, this can happen for a VLA. Another latent bug exposed by the VRP bits Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
[Bug c/26432] New: ppc32 kernel miscompiled
our current kernel does does boot ok on G4 systems (PowerMac, Pegasos2), but it locksup early (before the atyfb init) on a G3 ibook, no idea where exactly. gcc33 hammer as shipped with SLES9 works ok, gcc-4_0-branch works ok, gcc-4_1-branch does not boot. cant test gcc-mainline because make does not like the configure result. it does appearently also depend on the used kernel .config and/or the used patches. kernel compiled with gcc-4_1-branch did boot ok with a plain 2.6.16-rc4. right now I have a tree that shows the bug. Details later. -- Summary: ppc32 kernel miscompiled Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: olh at suse dot de GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26432
[Bug tree-optimization/26421] tree-ssa-alias.c:find_used_portions considers foo(var) use all elements of var
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-22 21:32 --- Patch posted, but now stdarg-5.c ICEs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg01781.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26421
[Bug tree-optimization/26406] Fowardprop does harm for VRP to figure out if a point is non zero
--- Comment #12 from law at redhat dot com 2006-02-22 21:45 --- Subject: Re: Fowardprop does harm for VRP to figure out if a point is non zero On Wed, 2006-02-22 at 20:55 +, rguenth at gcc dot gnu dot org wrote: --- Comment #11 from rguenth at gcc dot gnu dot org 2006-02-22 20:55 --- So I suppose VRP cannot see backwards for i_2 = j_1; if (i_2 == 0) return j_1; ? (of course copyprop would clean this up, but suppose for a moment this gets to VRP) Nope, it can't. It's not just the lack of backwards propagation, but also the fact that i is unused in the subgraphs after the conditional, so VRP won't record any information for either i or j in this kind of example. Fixing VRP to gather data for i in this example would result in a pretty significant compile-time hit. I'll note this was one of the reasons why we moved copyprop to run immediately before VRP -- copies in the IL were hiding a nontrivial number of detectable and useful ranges. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26406
