[Bug tree-optimization/28952] [4.2 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-06 06:07 --- Subject: Bug 28952 Author: pinskia Date: Wed Sep 6 06:06:55 2006 New Revision: 116716 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116716 Log: 2006-09-05 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/28952 * tree-vect-transform.c (vectorizable_condition): Move the check for the type after the check for simple condition. 2006-09-05 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/28952 * gcc.dg/vect/pr28952.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr28952.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug tree-optimization/28952] [4.1 regression] tree check: expected class 'expression', have 'exceptional' (ssa_name) in vectorizable_condition, at tree-vect-transform.c:2122
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-06 06:08 --- Fixed on the mainline, this is a latent bug on the 4.1 branch which was not there in 4.0 so I will also apply it to the 4.1 branch after a week or so. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 regression] tree check:|[4.1 regression] tree check: |expected class 'expression',|expected class 'expression', |have 'exceptional' |have 'exceptional' |(ssa_name) in |(ssa_name) in |vectorizable_condition, at |vectorizable_condition, at |tree-vect-transform.c:2122 |tree-vect-transform.c:2122 Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28952
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-06 06:13 --- Subject: Bug 28937 Author: pinskia Date: Wed Sep 6 06:13:22 2006 New Revision: 116717 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116717 Log: 2006-09-05 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/28937 * tree-flow.h (tree_ssa_unswitch_loops): Return unsigned int. (canonicalize_induction_variables): Likewise. (tree_unroll_loops_completely): Likewise. (tree_ssa_prefetch_arrays): Likewise. (remove_empty_loops): Likewise. * tree-ssa-loop-unswitch.c (tree_ssa_unswitch_loops): Return TODO_cleanup_cfg instead of directly calling cleanup_tree_cfg_loop. * tree-ssa-loop-ivcanon.c (canonicalize_induction_variables): Likewise. (tree_unroll_loops_completely): Likewise. (remove_empty_loops): Likewise. * tree-ssa-loop-prefetch.c (tree_ssa_prefetch_arrays): Likewise. * tree-ssa-loop.c (tree_ssa_loop_unswitch): Use the return value of tree_ssa_unswitch_loops. (tree_ssa_loop_ivcanon): Use the return value of canonicalize_induction_variables. (tree_ssa_empty_loop): Use the return value of remove_empty_loops. (tree_complete_unroll): Use the return value of tree_unroll_loops_completely. (tree_ssa_loop_prefetch): Use the return value of tree_ssa_prefetch_arrays. * passes.c (execute_todo): Before Cleanup CFG, set updating_used_alone and after cleanup CFG, call recalculate_used_alone. 2006-09-05 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/28937 * g++.dg/opt/unroll2.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/unroll2.C Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-loop-ivcanon.c trunk/gcc/tree-ssa-loop-prefetch.c trunk/gcc/tree-ssa-loop-unswitch.c trunk/gcc/tree-ssa-loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28937
[Bug tree-optimization/28937] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-06 06:14 --- 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=28937
[Bug target/28764] [4.2 Regression] libjava build failure on sh4
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-09-06 06:14 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-06 06:30 ---
And here is a testcase which is reproducible without the vectorizer:
int t[4];
__attribute__((vector_size(16))) int f(void)
{
__attribute__((vector_size(16))) int t1 = {(int)t[0], (int)t[1], (int)t[2],
(int)t[3]};
return t1;
}
That testcase above shows more problems than I actually want to touch right
now.
Here was my fix for the x86 crash (but it does not fix the powerpc-linux with
-maltivec crash):
Index: tree.c
===
--- tree.c (revision 116689)
+++ tree.c (working copy)
@@ -969,9 +969,11 @@ build_vector (tree type, tree vals)
for (link = vals; link; link = TREE_CHAIN (link))
{
tree value = TREE_VALUE (link);
-
- over1 |= TREE_OVERFLOW (value);
- over2 |= TREE_CONSTANT_OVERFLOW (value);
+ if (CONSTANT_CLASS_P (value))
+ {
+ over1 |= TREE_OVERFLOW (value);
+ over2 |= TREE_CONSTANT_OVERFLOW (value);
+ }
}
TREE_OVERFLOW (v) = over1;
Index: expmed.c
===
--- expmed.c(revision 116689)
+++ expmed.c(working copy)
@@ -4945,6 +4945,9 @@ make_tree (tree type, rtx x)
switch (GET_CODE (x))
{
+case CONST:
+ return make_tree (type, XEXP (x, 0));
+
case CONST_INT:
{
HOST_WIDE_INT hi = 0;
@@ -4979,6 +4982,7 @@ make_tree (tree type, rtx x)
int i, units;
rtx elt;
tree t = NULL_TREE;
+ tree type1 = TREE_TYPE (type);
units = CONST_VECTOR_NUNITS (x);
@@ -4986,7 +4990,7 @@ make_tree (tree type, rtx x)
for (i = units - 1; i = 0; --i)
{
elt = CONST_VECTOR_ELT (x, i);
- t = tree_cons (NULL_TREE, make_tree (type, elt), t);
+ t = tree_cons (NULL_TREE, make_tree (type1, elt), t);
}
return build_vector (type, t);
@@ -5044,6 +5048,14 @@ make_tree (tree type, rtx x)
GET_CODE (x) == ZERO_EXTEND);
return fold_convert (type, make_tree (t, XEXP (x, 0)));
+case SYMBOL_REF:
+ if (SYMBOL_REF_DECL (x))
+ {
+ tree pointer;
+ t = SYMBOL_REF_DECL (x);
+ pointer = build_pointer_type (TREE_TYPE (t));
+ return fold_convert (type, fold_build1 (ADDR_EXPR, pointer, t));
+ }
default:
t = build_decl (VAR_DECL, NULL_TREE, type);
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-06 06:33 --- Note I think the PPC-linux-gnu crash is actually caused by: 2006-06-20 Roger Sayle [EMAIL PROTECTED] * expr.c (expand_expr_real_1) VECTOR_CST: For vector constants with integer modes, attempt to directly construct an integer constant. But I have not checked but the backtrace is: (gdb) #8 0x085cda79 in copy_constant (exp=0xb7d40cd8) at ../../gcc/varasm.c:2742 2742ce-value = copy_constant (value); (gdb) #9 0x085ce18b in build_constant_desc (exp=0xb7d40cd8) at ../../gcc/varasm.c:2815 2815 desc-value = copy_constant (exp); (gdb) #10 0x085ce4be in output_constant_def (exp=0xb7d40cd8, defer=1) at ../../gcc/varasm.c:2885 2885 desc = build_constant_desc (exp); (gdb) #11 0x0834d3f4 in expand_expr_constant (exp=0xb7d40cd8, defer=1, modifier=EXPAND_NORMAL) at ../../gcc/expr.c:6433 6433 mem = output_constant_def (exp, defer); (gdb) up #12 0x0835084f in expand_expr_real_1 (exp=0xb7d40cd8, target=0xb7d2b954, tmode=V4SImode, modifier=EXPAND_NORMAL, alt_rtl=0xbf977bf8) at ../../gcc/expr.c:7119 7119 rtx constructor = expand_expr_constant (exp, 1, modifier); (gdb) #13 0x0834df9d in expand_expr_real (exp=0xb7d40cd8, target=0xb7d2b954, tmode=V4SImode, modifier=EXPAND_NORMAL, alt_rtl=0xbf977bf8) at ../../gcc/expr.c:6706 6706 ret = expand_expr_real_1 (exp, target, tmode, modifier, alt_rtl); (gdb) #14 0x08340493 in store_expr (exp=0xb7d40cd8, target=0xb7d2b954, call_param_p=0) at ../../gcc/expr.c:4370 4370 temp = expand_expr_real (exp, target, GET_MODE (target), (gdb) #15 0x0833f7dc in expand_assignment (to=0xb7d37660, from=0xb7d40cd8) at ../../gcc/expr.c:4249 4249 result = store_expr (from, to_rtx, 0); (gdb) And then we go into an infinite loop calling copy_constant on a decl. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot org GCC target triplet|x86-64-linux| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-06 06:36 --- (In reply to comment #2) This problem is recorded in a different place, we ignore bigger alignment for stack variables currently. I don't have the number off hand either but I know it has been filed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #9 from thomas at reactsoft dot com 2006-09-06 06:46 --- (In reply to comment #8) (In reply to comment #2) This problem is recorded in a different place, we ignore bigger alignment for stack variables currently. I don't have the number off hand either but I know it has been filed. Thanks. Before I posted the problem I already looked for the bug, this report came very close (I believed) to what the problem could be. I'll see if I can find the correct bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement
--- Comment #5 from thomas at reactsoft dot com 2006-09-06 07:14 ---
(In reply to comment #3)
Actually this is just a missed diagnostic. The compiler cannot align the
stack
variables where the alignment is greater than stack alignment that the
compiler
can give for the stack.
The least GCC could and should do then is warn about it...
If the code is not very complex, the alignment appears to work, though. But as
soon as the code becomes complex, GCC screwes the alignment and even
accesses variables that don't even exist (I'll go into detail later).
Basically code like this is affected (this is *NOT* a test case, I'm going to
post a test case as soon as I get it to work):
typedef struct _somestruct {
int a;
};
static void checkstruct (volatile struct _somestruct *palignedvar)
{
if ((size_t)palignedvar 0xF)
printf(structure misaligned!\n);
}
void somefunc(int a, int b, int c) {
__attribute__((aligned (16))) volatile struct _somestruct alignedvar;
while (1)
{
/* [other code] */
if (a) {
if (c) {
/* [other code] */
alignedvar.a = c;
checkstruct(alignedvar);
} else {
/* [other code] */
break;
}
} else {
if (b) {
/* [other code] */
alignedvar.a = a;
checkstruct(alignedvar);
} else {
if (c) {
break;
} else {
/* [other code] */
alignedvar.a = a;
checkstruct(alignedvar);
}
}
}
/* [other code] */
}
}
I analyzed the generated assembly code. GCC reserves an area big enough to hold
the structure plus padding, so it can align the structure dynamically at
runtime. It stores a pointer to the reserved area and a pointer to the
structure within the area. As long as the code is simple, GCC uses the pointer
to the structure to access the data. However, if the code is complex enough,
GCC mistakenly uses the pointer to the reserved area - which of course is
sometimes not properly aligned. As a result, also the data of the structure
members are read/write incorrectly.
the stack is organized like this (the order may not match as showed in this
abstracted example):
struct {
void *reserved_area; /* this is the pointer GCC sometimes accidently
grabs */
void *aligned_structure; /* this is the pointer GCC should always grab */
char reserved[sizeof(structure) + sizeof(padding)];
};
I encountered this bug with -O3, I don't know if GCC also generates broken code
without optimizations. I tried to create a simple test case that triggers the
problem, but I failed. I'm going to do that in the next few days.
--
thomas at reactsoft dot com changed:
What|Removed |Added
CC||thomas at reactsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
[Bug c++/18410] GCC does not warn about hidden methods
--- Comment #3 from tvainika at gmail dot com 2006-09-06 07:31 --- This same bug still applies to g++-4.0 (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) and g++-4.1 (GCC) 4.1.2 20060814 (prerelease) (Debian 4.1.1-11) -- tvainika at gmail dot com changed: What|Removed |Added CC||tvainika at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18410
[Bug middle-end/28958] Compiling vpnc with GCC 4.1 and anything other than -O0 causes failure to connect
--- Comment #9 from william dot grant at ubuntu dot com dot au 2006-09-06 07:43 --- I've changed both those references, and have attached a new package to the Ubuntu bug report for the reporter to test. I'll report back with results that the tester has. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28958
[Bug fortran/28959] New: ICE on derived type with host association
THe attached code produces the ICE. [EMAIL PROTECTED] TEMP]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gcc42 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0 20060905 (experimental) [EMAIL PROTECTED] TEMP]$ gfortran -c bug-fold.f90 bug-fold.f90: In function 'inner_sub': bug-fold.f90:54: internal compiler error: in fold_convert, at fold-const.c:2098 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE on derived type with host association Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
[Bug fortran/28959] ICE on derived type with host association
--- Comment #1 from sfilippone at uniroma2 dot it 2006-09-06 09:45 --- Created an attachment (id=12195) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12195action=view) TEst case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
[Bug fortran/28959] ICE on derived type with host association
--- Comment #2 from sfilippone at uniroma2 dot it 2006-09-06 10:00 --- The patch proposed in http://gcc.gnu.org/ml/fortran/2006-09/msg00020.html seems to work for me, both in the reduced test case and in my original applicatin code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
[Bug c++/28960] New: optimized bug with ia32 sse
[EMAIL PROTECTED] tmp]# cat a.cpp
#include xmmintrin.h
#include stdio.h
__m128 mm;
void test ( const __m128 vm, float r )
{
mm = _mm_add_ps( mm, _mm_set_ps( 0.0f, r, r, r) );
float vm0, vm1, vm2;
_mm_store_ss( vm0, vm );
_mm_store_ss( vm1, _mm_shuffle_ps( vm, vm, 1 ) );
_mm_store_ss( vm2, _mm_shuffle_ps( vm, vm, 2 ) );
_mm_store_ss( vm2, _mm_shuffle_ps( vm, vm, 2 ) );
printf(In TEST: %f %f %f\n, vm0, vm1, vm2 );
}
int main()
{
__m128 vm = _mm_set_ps( 4.0f, 3.0f, 2.0f, 1.0f );
float vm0, vm1, vm2;
_mm_store_ss( vm0, vm );
_mm_store_ss( vm1, _mm_shuffle_ps( vm, vm, 1 ) );
_mm_store_ss( vm2, _mm_shuffle_ps( vm, vm, 2 ) );
printf(Before TEST: %f %f %f\n, vm0, vm1, vm2 );
test(vm, 0.5f);
_mm_store_ss( vm0, vm );
_mm_store_ss( vm1, _mm_shuffle_ps( vm, vm, 1 ) );
_mm_store_ss( vm2, _mm_shuffle_ps( vm, vm, 2 ) );
printf(After TEST: %f %f %f\n, vm0, vm1, vm2 );
return 0;
}
[EMAIL PROTECTED] tmp]# g++ -Wall -O3 -msse a.cpp; ./a.out
Before TEST: 1.00 2.00 3.00
In TEST: nan nan nan
After TEST: 1.00 2.00 3.00
[EMAIL PROTECTED] tmp]# g++ -Wall -O2 -msse a.cpp; ./a.out
Before TEST: 1.00 2.00 3.00
In TEST: nan nan nan
After TEST: 1.00 2.00 3.00
[EMAIL PROTECTED] tmp]# g++ -Wall -O1 -msse a.cpp; ./a.out
Before TEST: 1.00 2.00 3.00
In TEST: nan nan nan
After TEST: 1.00 2.00 3.00
[EMAIL PROTECTED] tmp]# g++ -Wall -O0 -msse a.cpp; ./a.out
Before TEST: 1.00 2.00 3.00
In TEST: 1.00 2.00 3.00
After TEST: 1.00 2.00 3.00
[EMAIL PROTECTED] tmp]#
[EMAIL PROTECTED] tmp]# uname -a
Linux localhost.localdomain 2.6.17-1.2139_FC5smp #1 SMP Fri Jun 23 13:12:06 EDT
2006 i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] tmp]# gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking
=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,
fortran,ada --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
[EMAIL PROTECTED] tmp]#
gcc3 is OK
--
Summary: optimized bug with ia32 sse
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zengpan at goldhuman dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28960
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #9 from uros at kss-loka dot si 2006-09-06 11:33 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00162.html implements missing i386.md RTL patterns. This is i386 target-specific fix for this bug. The patch was bootstrapped on i686-pc-linux-gnu and x86_64-pc-linux-gnu, regtested for c,c++ and fortran. -- uros at kss-loka dot si changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2006- |patches/2006- |09/msg00137.html|09/msg00162.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug libstdc++/28961] New: Macro definitions needed by gcc/gthr.h are missing from libstdc++ build
When attempting to build an armeb-linux cross compiler on a RH Enterprise Linux
3.0 system, libstdc++ is not being built in a thread-safe manner. Here is the
configure command line:
configure --cache-file=./config.cache --host=armeb-linux
--build=i686-pc-linux-gnu --enable-multilib --with-cross-host=i686-pc-linux-gnu
--prefix=snip --with-local-prefix=snip --with-headers=snip
--with-libs=snip --disable-nls --enable-threads=posix --enable-symvers=gnu
--enable-__cxa_atexit --enable-languages=c,c++ --enable-shared
--enable-long-long --with-cpu=arm9tdmi --enable-cxx-flags=-mcpu=arm9tdmi
--with-float=soft --with-gcc-version-trigger=snip
--program-transform-name=s,^,armeb-linux-,;
--srcdir=../../../../gcc-3.4.3/libstdc++-v3 --with-target-subdir=armeb-linux
--enable-threads=posix is passed in, and looking at config.log, I see that it's
appearing to be honored correctly, since glibcxx_thread_h is being set to
gthr-posix.h. When I go into the build target directory
(prefix/armeb-linux/libstdc++-v3/include/bits), I can see that gthr-default.h
is indeed copied from gthr-posix.h Thus, it would appeard that gthr-default.h
is correct. With that said, the real problem appears to be in the use of
gthr.h (which originates from
prefix/armeb-linux/libstdc++-v3/include/armeb-linus/bits/gthr.h, which is
copied from build source/gcc/gthr.h).
In gthr.h, there is a list of conditional includes:
/* Check first for thread specific defines. */
#if _GLIBCXX__PTHREADS
#include bits/gthr-posix.h
#elif _GLIBCXX__DCE_THREADS
#include bits/gthr-dce.h
#elif _GLIBCXX__SOLARIS_THREADS
#include bits/gthr-solaris.h
/* Include GTHREAD_FILE if one is defined. */
#elif defined(_GLIBCXX_HAVE_GTHR_DEFAULT)
#if __GXX_WEAK__
#ifndef _GLIBCXX_GTHREAD_USE_WEAK
#define _GLIBCXX_GTHREAD_USE_WEAK 1
#endif
#endif
#include bits/gthr-default.h
/* Fallback to single thread definitions. */
#else
#include bits/gthr-single.h
#endif
I would expect, on my system, to either have -D_GLIBCXX__PTHREADS or
-D_GLIBCXX_HAVE_GTHR_DEFAULT. I see neither. I do see
_GLIBCXX_HAVE_GTHR_DEFAULT defined in c++config.h, though. Unfortunately,
gthr.h does not include c++config.h, so it does now see that there is a
gthr-default.h header available to include. The result is that files that
include gthr.h are not guaranteed to pull in the proper thread support
routines. I first ran into this problem with the file atomicity.cc
(prefix/armeb-linux/libstdc++-v3/src/atomicity.cc). This file contains a
couple of default atomic oparerations: __exchange_and_add and __atomic_add:
#include bits/atomicity.h
#include bits/concurrence.h
namespace __gnu_internal
{
__glibcxx_mutex_define_initialized(atomic_mutex);
} // namespace __gnu_internal
namespace __gnu_cxx
{
_Atomic_word
__attribute__ ((__unused__))
__exchange_and_add(volatile _Atomic_word* __mem, int __val)
{
__glibcxx_mutex_lock(__gnu_internal::atomic_mutex);
_Atomic_word __result;
__result = *__mem;
*__mem += __val;
__glibcxx_mutex_unlock(__gnu_internal::atomic_mutex);
return __result;
}
void
__attribute__ ((__unused__))
__atomic_add(volatile _Atomic_word* __mem, int __val)
{ __exchange_and_add(__mem, __val); }
} // namespace __gnu_cxx
The exchange and add routine is absurdly simple in that it creates a critical
section around the add to ensure that it's an atomic operation. In theory, the
include of bits/concurrence.h should pull in the definitions of
__glibcxx_mutex_lock and __glibcxx_mutex_unlock. This is unforutanately not
the case. The file
prefix/armeb-linux/libstdc++-v3/include/bits/concurrence.h includes
bits/gthr.h. But... c++config.h is not included anywhere. Also, the compile
line for atomicity.cc does not have any of the necessary gthr.h macros defined,
either:
prefix/gcc/xgcc -shared-libgcc -Bprefix/gcc/ -nostdinc++
-Lprefix/armeb-linux/libstdc++-v3/src
-Lprefix/armeb-linux/libstdc++-v3/src/.libs
-Bprefix/armeb-linux/armeb-linux/bin/ -Bprefix/armeb-linux/armeb-linux/lib/
-isystem install dir/armeb-linux/armeb-linux/include -isystem install
dir/armeb-linux/armeb-linux/sys-include
-Iprefix/armeb-linux/libstdc++-v3/include/armeb-linux
-Iprefix/armeb-linux/libstdc++-v3/include -Isource
dir/libstdc++-v3/libsupc++ -O2 -g -O2 -g -O2 -D_GNU_SOURCE
-fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-mcpu=arm9tdmi -c atomicity.cc -o atomicity.o
The result of this is that atomicity.o is built without any thread safety.
This means that operations such as the reference count inrement and decrement
in std::string are not safe.
Thanks
-Seth Moore
--
Summary: Macro definitions needed by gcc/gthr.h are missing from
libstdc++ build
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
[Bug libstdc++/28961] Macro definitions needed by gcc/gthr.h are missing from libstdc++ build
--- Comment #1 from sethmoore at gmail dot com 2006-09-06 12:54 --- Created an attachment (id=12196) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12196action=view) Test case that exhibits unsafe exchange_and_add. Using this test code, we are able to consistently create a heap corruption problem that results from the string reference count becoming corrupted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28961
[Bug target/28960] optimized bug with ia32 sse
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28960
[Bug bootstrap/28326] [4.1 regression] profiledbootstrap will produce an ICE with -mtune=power3 -mcpu=power3 in BOOT_CFLAGS
--- Comment #4 from markus at unixforces dot net 2006-09-06 13:02 --- any news about this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28326
[Bug bootstrap/28962] New: [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
cd /TMP/build-gcc-svn20060906-powerpc64 /TMP/gcc-svn20060906/configure --target=powerpc64-linux --prefix=/usr/local/DIR/gcc-powerpc64-svn20060906 --enable-languages=c --with-as=/usr/local/bin/powerpc64-linux-as --with-ld=/usr/local/bin/powerpc64-linux-ld --disable-shared --enable-threads=single --disable-multilib make results in: -- snip -- ... make[2]: Leaving directory `/TMP/build-gcc-svn20060906-powerpc64/gcc' Checking multilib configuration for libmudflap... mkdir -p -- powerpc64-linux/libmudflap Configuring in powerpc64-linux/libmudflap configure: creating cache ./config.cache checking build system type... i686-pc-linux-gnu checking host system type... powerpc64-unknown-linux-gnu checking target system type... powerpc64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for powerpc64-linux-strip... powerpc64-linux-strip checking for --enable-version-specific-runtime-libs... no checking whether to enable maintainer-specific portions of Makefiles... no checking for powerpc64-linux-gcc... /TMP/build-gcc-svn20060906-powerpc64/./gcc/x gcc -B/TMP/build-gcc-svn20060906-powerpc64/./gcc/ -B/usr/local/DIR/gcc-powerpc64 -svn20060906/powerpc64-linux/bin/ -B/usr/local/DIR/gcc-powerpc64-svn20060906/pow erpc64-linux/lib/ -isystem /usr/local/DIR/gcc-powerpc64-svn20060906/powerpc64-li nux/include -isystem /usr/local/DIR/gcc-powerpc64-svn20060906/powerpc64-linux/sy s-include checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libmudflap] Error 1 make[1]: Leaving directory `/TMP/build-gcc-svn20060906-powerpc64' make: *** [all] Error 2 -- snip -- I can workaround this issue with --disable-libmudflap --disable-libssp. -- Summary: [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu (and several others) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #1 from bunk at stusta dot de 2006-09-06 14:13 --- Created an attachment (id=12197) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12197action=view) configure log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #2 from bunk at stusta dot de 2006-09-06 14:13 --- Created an attachment (id=12198) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12198action=view) make log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #3 from bunk at stusta dot de 2006-09-06 14:15 --- Created an attachment (id=12199) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12199action=view) powerpc64-linux/libmudflap/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #4 from bunk at stusta dot de 2006-09-06 14:19 --- Note: checking host system type... powerpc64-unknown-linux-gnu is obviously wrong -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug target/28960] [4.0/4.1 Regression] optimized bug with ia32 sse
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-06 14:23 --- Confirmed. With -mfpmath=sse I get Before TEST: 1.00 2.00 3.00 In TEST: nan 2.00 3.00 After TEST: 1.00 2.00 3.00 with -mfpmath=sse,387 Before TEST: 1.00 2.00 3.00 In TEST: 1.00 2.00 nan After TEST: 1.00 2.00 3.00 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||i?86-*-* Keywords||wrong-code Known to fail||4.0.3 4.1.1 4.1.2 Known to work||3.4.6 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-06 14:23:10 date|| Summary|optimized bug with ia32 sse |[4.0/4.1 Regression] ||optimized bug with ia32 sse Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28960
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
--- Comment #10 from hjl at lucon dot org 2006-09-06 14:26 --- The proposed patch will slow down Core and Core 2 by 70-100% in some testcases due to partial flag register stall. I have a followup patch to implement TARGET_PARTIAL_FLAG_REG_STALL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug objc/28963] New: Compiler crash caused by @class definition for superclass
gcc -v output:
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=i586-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
The following code produces a compiler seg fault:
==
@class aSuperClass;
@interface aClass : aSuperClass
{}
@end
@implementation aClass
@end
===
If the @class line is omitted then the compiler does not crash and an error
message is (correctly) printed about the undefined superclass.
Admittedly the code is wrong, but so is the crash!
--
Summary: Compiler crash caused by @class definition for
superclass
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richard dot hutchinson at asa dot co dot uk
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28963
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #11 from roger at eyesopen dot com 2006-09-06 15:27 --- Hmm, yep I guess it was caused my change, most probably this part of it: * tree.c (build_constructor_single): Mark a CONSTRUCTOR as constant, if all of its elements/components are constant. (build_constructor_from_list): Likewise. It looks like someplace is changing the contents of this CONSTRUCTOR to a VAR_DECL t.0, but not reseting the TREE_CONSTANT flag. Hence on PPC we end up with a bogus constant constructor during RTL expansion!? Scalar replacement perhaps?? Grr. I'll investigate. Sorry for the inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #12 from roger at eyesopen dot com 2006-09-06 15:36 ---
Here's the .102t.final_cleanup
;; Function f (f)
f ()
{
int D.1524;
int D.1522;
int D.1520;
int t.0;
bb 2:
t.0 = (int) t;
D.1520 = (int) t[1];
D.1522 = (int) t[2];
D.1524 = (int) t[3];
return {t.0, D.1520, D.1522, D.1524};
}
The CONSTRUCTOR in the return incorrectly has the TREE_CONSTANT flag set.
So the problem is somewhere in tree-ssa. One workaround/improvement might
be for out-of-ssa to reconstitute the constructor back to a constant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug middle-end/28964] New: partition_stack_vars uses unstable sort
position_stack_vars sorts stack_vars_sorted in a manner that makes the order of stack vars with equal size undefined, thus making the compiler output host dependent. -- Summary: partition_stack_vars uses unstable sort Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28964
[Bug rtl-optimization/28925] problem with zero_extract during gcse
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-09-06 16:04 --- Confirmed according to the RTL logs. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-06 16:04:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28925
[Bug libgomp/28046] libgomp test pr27337.C fails intermittently
--- Comment #1 from janis at gcc dot gnu dot org 2006-09-06 16:27 --- This test still fails intermittently. Would someone who understands OpenMP directives please take a close look at the test to see if it's valid? If not, this seems like a serious problem. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28046
Re: [Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
On Wed, 2006-09-06 at 14:19 +, bunk at stusta dot de wrote: --- Comment #4 from bunk at stusta dot de 2006-09-06 14:19 --- Note: checking host system type... powerpc64-unknown-linux-gnu is obviously wrong No it is not. -- Pinski
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #5 from pinskia at physics dot uc dot edu 2006-09-06 16:28 --- Subject: Re: [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails On Wed, 2006-09-06 at 14:19 +, bunk at stusta dot de wrote: --- Comment #4 from bunk at stusta dot de 2006-09-06 14:19 --- Note: checking host system type... powerpc64-unknown-linux-gnu is obviously wrong No it is not. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] building a cross compiler with --disable-multilib fails
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-06 16:32 --- /usr/local/DIR/gcc-powerpc64-svn20060906/powerpc64-linux/sys-include -O2 -g -O2 conftest.c 5 /usr/local/bin/powerpc64-linux-ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status That means you don't have binutils/glibc installed correctly. And this is not a regression anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.3 4.1.1 4.2.0 | Known to work|3.4.6 | Summary|[4.0/4.1/4.2 regression]|building a cross compiler |building a cross compiler |with --disable-multilib |with --disable-multilib |fails |fails | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug c++/28718] Call to -lgcc added prior to user libraries
--- Comment #6 from bjoern dot m dot haase at web dot de 2006-09-06 16:51 --- To clear up the issues. 1.) libgcc provides a fp emulation based on compiled c functions that is to my very best knowledge untested for avr and extremely inefficient. 2.) avr-libc provides fp emulation that is hand-tuned assembly and on a less restrictive license than GPL. IIRC, the person who wrote them is no longer active in the field. 3.) the functions supplied by avr-libc are as basic as single float add 3, single float multiply 3, single float convert to integer 2 ... 4.) the hand-tuned assembly routines should really replace the libgcc ones, but that's not easily feasible. Partly due to licensing issues (modified free bsd for avr-libc), partly because it is very very difficult for us developers to get code integrated into mainline gcc. 5.) the externally supplied functions in libm need the hand-tuned assembly versions in order to operate properly and will failed with the untested libgcc variants. 5.) There is only one single libc and libm implementation available for avr that cooperates with gcc: avr-libc. The suggestion of Joerg Wunsch is, thus, in line with the needs of gcc users for the avr target. Bjoern. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718
[Bug c++/26696] [4.0/4.1/4.2 Regression] ICE with statement forming unused static member function reference
--- Comment #6 from jason at gcc dot gnu dot org 2006-09-06 17:06 --- Subject: Bug 26696 Author: jason Date: Wed Sep 6 17:06:00 2006 New Revision: 116724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116724 Log: PR c++/26696 * cvt.c (convert_to_void): Replace a subexpression with no side effects with void_zero_node. * tree.c (is_overloaded_fn): Look through COMPONENT_REF. (get_first_fn): Ditto. * decl.c (grokdeclarator): No need to look through COMPONENT_REF. Added: trunk/gcc/testsuite/g++.dg/warn/noeffect8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/cp/decl.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/g++.dg/other/component1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26696
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #2 from pcarlini at suse dot de 2006-09-06 17:11 --- I think this difference is ultimately due to the existenxce of a separate *_O0 version of tree_lower_complex, in tree-complex.c. Rth added it (as part of fixing 20610), I believe the generic version is right (-0), and I'm hoping he wants to have a look to this issue... -- pcarlini at suse dot de changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #3 from pcarlini at suse dot de 2006-09-06 17:11 --- I think we can confirm it. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-06 17:11:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug rtl-optimization/28965] New: distribute_notes fails to change REG_DEAD into REG_UNUSED notes for global registers
When placing a REG_DEAD note for a global register, distribute_notes no longer checks if the register is set in the same insn. -- Summary: distribute_notes fails to change REG_DEAD into REG_UNUSED notes for global registers Product: gcc Version: 4.1.1 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28965
[Bug rtl-optimization/28965] distribute_notes fails to change REG_DEAD into REG_UNUSED notes for global registers
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-09-06 17:18 --- Created an attachment (id=12200) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12200action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28965
[Bug bootstrap/28962] building a cross compiler with --disable-multilib fails
--- Comment #7 from bunk at stusta dot de 2006-09-06 17:22 --- I don't have a glibc for this target. But this might be where my problems are coming from: I am able to compile gcc 4.1.1 for at about a dozen targets without having any libc for these targets present. And the resulting compilers work fine for my purposes (cross-compiling Linux kernels). But the configure options I had to figure out for doing this seem to indicate that this is a working but not documented setup. It seems sending a bug report for part of this wasn't the right solution. Is there a good reason why gcc can't officially support being built without a libc by either figuring out that there's no libc itself or by offering some kind of --i-do-not-have-a-libc option to configure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #4 from pcarlini at suse dot de 2006-09-06 18:43 --- But this issue should be recategorized, is about lowering and optimization of complex numbers, maybe Andrew can help about that? -- pcarlini at suse dot de changed: What|Removed |Added CC||pinskia at physics dot uc ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug target/28966] New: -maltivec -m32 causes the stack to be saved and restored even though there is no need for it
Testcase:
int f(void)
{
return 0;
}
This produces with -maltivec -O2:
f:
stwu 1,-16(1)
li 3,0
addi 1,1,16
blr
With just -O2, we get:
f:
li 3,0
blr
--
Summary: -maltivec -m32 causes the stack to be saved and restored
even though there is no need for it
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28966
[Bug c++/27371] [4.1/4.2 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))
--- Comment #4 from jason at gcc dot gnu dot org 2006-09-06 18:47 --- This is also complicated by PR 16269; we don't manage the lifetime of temporaries, so we don't know whether an initialized temporary is used again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-06 18:50 --- There are most likely a couple of different issues here. A front-end one with (1.0+0.0i)*(-1) being expanded incorrectly, there is a bug about a case like that too, see PR 24581. There might even be a libstdc++ one too all depending on how the complex class is implemented. I have not looked into libstdc++ to check yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #6 from pluto at agmk dot net 2006-09-06 19:18 --- (In reply to comment #2) I think this difference is ultimately due to the existenxce of a separate *_O0 version of tree_lower_complex, in tree-complex.c. Rth added it (as part of fixing 20610), I believe the generic version is right (-0), and I'm hoping he wants to have a look to this issue... mathematically (x+yi)u = xu+yui. we have x=1, y=0, u=-1, so the result is -1+(0*-1)i. so, how c++ define the 0*-1 ? -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #7 from pcarlini at suse dot de 2006-09-06 20:23 ---
Both the front-ends deal with 0 * -1 in the same way, the result is -0 (just
try). Anyway, the issue is crazy, a reduced pure C testcase (in principle
identical to what the complexdouble class does) behaves exactly the other way
'round about -O0 vs -O1:
#include stdio.h
int main()
{
double __complex__ z;
__real__ z = 1.0;
__imag__ z = 0.0;
z *= -1.0;
printf(%e\n, __imag__(z));
}
I can't believe that both 0 and -0 are correct...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-06 20:27 --- (In reply to comment #7) Both the front-ends deal with 0 * -1 in the same way, the result is -0 (just try). Anyway, the issue is crazy, a reduced pure C testcase (in principle identical to what the complexdouble class does) behaves exactly the other way 'round about -O0 vs -O1: This is PR 24581 after all then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/16269] g++ doesn't reuse stack space
--- Comment #3 from jason at gcc dot gnu dot org 2006-09-06 20:56 ---
This isn't only a problem in C++. In this C testcase:
struct A
{
int i[42];
};
struct A f();
int main()
{
f();
f();
f();
}
we allocate 3 'struct A' temporaries.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16269
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #9 from pcarlini at suse dot de 2006-09-06 20:59 --- (In reply to comment #8) This is PR 24581 after all then. I don't know, I'm afraid there is even more to it :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #21 from jason at gcc dot gnu dot org 2006-09-06 21:39 --- I expect that indeed, the test case Kenner mentioned as motivation for the call to mark_temp_addr_taken doesn't need it any more because of gimplification. Any temporary that needs to live longer than a single gimple statement will be represented in the gimple. So as he said, we should be able to do away with a lot of the temporary management code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug c++/28967] New: ld 4.1.1 runs EXTREMLY slow compared to 4.0
When I build our application on Fedora Core 5 using gcc/ld the main library of our (quite large) application links in about 10s on an older 1.7GHz Pentium 4/Xeon system. When I build the same app on my new PCs that have gcc 4.1.1 on them, compiling is much faster, but linking is appallingly slow, about 2:30 for the same binary. Factoring 3x speed difference in hardware, this is around 18x slower!!! I have seen at least one other report of extremely slow linking: http://www.gatago.com/gnu/g++/help/19351814.html I looked at the suggestions above: 1. this is local linking, on the local filesystem 2. I did top and ld is consuming 100% cpu throughout. This happens on two separate modern PCs that have had Fedora 5 + yum update (to gcc 4.1.1) done on them. Any help in trying to diagnose this is welcome. Note that every other operation I can think of on these PCs is very fast -- it is only this one operation, ld, that is extremely slow. -- Summary: ld 4.1.1 runs EXTREMLY slow compared to 4.0 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: baisa at brad-aisa dot com GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28967
[Bug c++/28967] ld 4.1.1 runs EXTREMLY slow compared to 4.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-06 22:26 --- Can you give the output of ld --version on both machines. GCC does not really control ld but another project, binutils, does. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28967
[Bug middle-end/28967] ld 4.1.1 runs EXTREMLY slow compared to 4.0
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-06 22:26 --- Also you should have reported this to Redhat first since it was their versions of gcc/binutils you are using. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28967
[Bug target/28968] New: gcc/config/i386/winnt-stubs.c is not linked in - build fails
When configuring gcc-{4.1.0,4.1.1} as
$ CC=gcc-4.1 ../gcc-4.1.1/configure --target=i586-pc-interix3 \
--enable-languages=c \
--enable-threads=no \
--with-stabs \
--enable-nls \
--disable-shared \
--disable-libssp \
--with-gnu-as \
--with-gnu-ld
the subsequent
$ make
fails with the following linker error:
gcc/config/i386/winnt.c:
symbols i386_pe_type_dllexport_p and i386_pe_type_dllimport_p are undefined!
Modifying winnt.c to
#include winnt-stubs.c
works around the problem.
--
Summary: gcc/config/i386/winnt-stubs.c is not linked in - build
fails
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mkoeppe at gmx dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i586-pc-interix3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28968
[Bug target/28968] gcc/config/i386/winnt-stubs.c is not linked in - build fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-06 23:08 --- That is the incorrect fix. The correct fix is to copy from t-cygming to t-interix: winnt.o: $(srcdir)/config/i386/winnt.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h $(TREE_H) flags.h \ $(TM_P_H) toplev.h $(HASHTAB_H) $(GGC_H) $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ $(srcdir)/config/i386/winnt.c winnt-cxx.o: $(srcdir)/config/i386/winnt-cxx.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h $(TREE_H) flags.h \ $(TM_P_H) toplev.h $(HASHTAB_H) $(GGC_H) $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ $(srcdir)/config/i386/winnt-cxx.c winnt-stubs.o: $(srcdir)/config/i386/winnt-stubs.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \ $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h $(TREE_H) flags.h \ $(TM_P_H) toplev.h $(HASHTAB_H) $(GGC_H) $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ $(srcdir)/config/i386/winnt-stubs.c And also copy from mingw32's entry in config.gcc to interix3's entry: extra_objs=winnt.o winnt-stubs.o cxx_target_objs=winnt-cxx.o -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28968
[Bug target/28968] gcc/config/i386/winnt-stubs.c is not linked in - build fails
-- 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-09-06 23:08:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28968
[Bug target/28968] gcc/config/i386/winnt-stubs.c is not linked in - build fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-06 23:10 --- And the other question is how did you get passed PR 15212? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||15212 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28968
[Bug target/28968] gcc/config/i386/winnt-stubs.c is not linked in - build fails
--- Comment #3 from mkoeppe at gmx dot de 2006-09-06 23:29 --- (In reply to comment #2) And the other question is how did you get passed PR 15212? Don't know if it's really related! I didn't encounter it, but I built a cross compiler and used only make and not make bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28968
[Bug c++/28514] [4.2 Regression] libstdc++ vs. anonymous namespaces
--- Comment #10 from jason at redhat dot com 2006-09-07 00:14 --- Subject: Re: [4.2 Regression] libstdc++ vs. anonymous namespaces bkoz at gcc dot gnu dot org wrote: This is precisely one reason why anonymous namespaces are useful. It provides a very viceral way to sanity check an API. Make sure that the private parts really are private, say. Yes, but there's a difference between private and internal. This is especially problematic for templates; if you give template instantiations internal linkage, we can't share them between translation units anymore and you get code bloat. Do you really want a copy of the list of primes from the hashtable policy code in each translation unit that uses it? It seems to me that Rope_constants, _Private in tr1/random and the hashtable policy stuff were in special namespaces just to avoid name lookup pollution. If you really want them also to be unique to each translation unit you could insert an anonymous namespace inside the preexisting namespace and not have to mess with name lookup at all. I thought after my earlier comments you would put Rope_constants back, but now that I actually look at what you checked in I see that you just added explicit global scope to the uses. That kind of cluttering up of the global namespace seems like a mistake to me; _Tag isn't a very unique name. Changing _Private to an anonymous namespace has the same problem, except it's only cluttering up tr1 instead of the global namespace. In both cases inserting an anonymous namespace inside the named namespace seems both better and less work. Please, let's leave rope out of it. You reported a problem compiling rope, it's hard to respond without talking about rope. I think that there are good reasons to use anonymous namespaces in headers, even if you disagree with these designs personally. Please elaborate. Why do you want _Tag, _Select, X::primes, etc. to be unique to each translation unit? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28514
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #10 from pcarlini at suse dot de 2006-09-07 00:44 --- I'm re-reading the various floating-point standards and Annexes and I think this issue may turn out to be a not-a-bug. Whether those standards make sense it's another matter ;) So, what I'm reading: C99, F.8.2 says that 0 * x and 0.0 are equivalent, i.e., tranforming 0 * x to 0.0 is allowed (insofar x is not a NaN, -0, or infinite). Therefore, it seems, the optimizers of a C / C++ compiler conforming to IEC 60559 (~ IEC 559) are allowed to do that replacement at any moment and discard the info about the signedness of x. As submitter maintains - correctly, in my opinion - when the same compiler implements complex functions sensitive to the signedness of zero, like in C99, G, for example, and supposedly compatible with the same IEC 60559, how that signedness info is kept or moved around should be a serious concern... In general, I'm under the impression, that signed zero has been invented to cope with specific discontinuities of specific functions and to improve the consistency of floating point computations involving infinities (interesting discussion, as usual, in Goldberg, 2.2.3), not as something which in every case is kept conceptually distinct from 0 during a computation: as a matter of fact, in such standards 0 and -0 compare equal... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #12 from mmitchel at gcc dot gnu dot org 2006-09-07 01:04 --- Subject: Bug 28886 Author: mmitchel Date: Thu Sep 7 01:04:07 2006 New Revision: 116736 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116736 Log: PR c++/28903 * pt.c (tsubst): Use fold_non_dependent_expr to fold array dimensions. PR c++/28886 * pt.c (unify): Avoid unnecessary calls to fold_build2 for array dimensions. Added: trunk/gcc/testsuite/g++.dg/ext/vla3.C trunk/gcc/testsuite/g++.dg/template/array16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug c++/28903] [4.2 Regression] Rejects VLA in template class's member with using
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-09-07 01:04 --- Subject: Bug 28903 Author: mmitchel Date: Thu Sep 7 01:04:07 2006 New Revision: 116736 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116736 Log: PR c++/28903 * pt.c (tsubst): Use fold_non_dependent_expr to fold array dimensions. PR c++/28886 * pt.c (unify): Avoid unnecessary calls to fold_build2 for array dimensions. Added: trunk/gcc/testsuite/g++.dg/ext/vla3.C trunk/gcc/testsuite/g++.dg/template/array16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28903
[Bug c++/28903] [4.2 Regression] Rejects VLA in template class's member with using
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-09-07 01:09 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28903
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-09-07 01:10 --- Fixed in 4.2.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug target/26015] [4.1/4.2 Regression] ICE during bootstrap for vax architecture
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-09-07 01:12 --- VAX is not a primary or secondary platform. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug c++/27371] [4.1/4.2 Regression] Does not warn about unused function result (__attribute__((warn_unused_result)))
--- Comment #5 from jason at gcc dot gnu dot org 2006-09-07 01:13 --- Subject: Bug 27371 Author: jason Date: Thu Sep 7 01:12:00 2006 New Revision: 116737 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116737 Log: PR c++/27371 * tree-inline.c (copy_result_decl_to_var): New fn. (declare_return_variable): Use it. Call declare_inline_vars here. (expand_call_inline): Not here. * cp/cvt.c (convert_to_void): Strip useless TARGET_EXPR. * cp/cp-tree.h (TARGET_EXPR_IMPLICIT_P): New macro. * cp/tree.c (build_cplus_new): Set it. Added: trunk/gcc/testsuite/g++.dg/warn/unused-result1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cvt.c trunk/gcc/cp/tree.c trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27371
[Bug target/26504] [4.1/4.2 Regression] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-09-07 01:13 --- AVR is not a primary or secondary platform. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug middle-end/27986] [4.0/4.1/4.2 Regression] jump to middle of loop on entry with using old version of an variable
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
[Bug c/28504] [4.0/4.1/4.2 regression] ICE with variable sized array
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28504
[Bug rtl-optimization/28940] [4.1/4.2 Regression] address selection does not work correctly
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
[Bug target/28946] [4.0/4.1/4.2 Regression] assembler shifts set the flag ZF, no need to re-test to zero
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28946
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #11 from joseph at codesourcery dot com 2006-09-07 01:23 --- Subject: Re: What should be value of complexdouble(1.0,0.0) *= -1? On Thu, 7 Sep 2006, pcarlini at suse dot de wrote: I'm re-reading the various floating-point standards and Annexes and I think this issue may turn out to be a not-a-bug. Whether those standards make sense it's another matter ;) So, what I'm reading: C99, F.8.2 says that 0 * x and 0.0 are equivalent, i.e., tranforming 0 * x to 0.0 is allowed (insofar x is not a NaN, -0, or infinite). Therefore, it seems, the optimizers of a C / C++ F.8 is *illustrative* of transformations that are *not* permitted. It doesn't permit anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #12 from pcarlini at suse dot de 2006-09-07 01:33 --- (In reply to comment #11) F.8 is *illustrative* of transformations that are *not* permitted. It doesn't permit anything. Where do you read that in F.8.2 ?!? I read: 0 * x - 0.0The expressions 0 * x and 0.0 are not equivalent if x is NaN, infinite, or -0 Where do you read that in all the other cases (e.g., when x is a normal number) 0 * x and 0.0 are not equivalent?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #13 from pcarlini at suse dot de 2006-09-07 01:51 --- And, by the way, it's also generally untrue that F8 is only illustrative of not permitted transformations. For example, a few lines above: 1 * x and x / 1 - x The expressions 1 * x, x / 1 and x are equivalent (on IEC 60559 machines, among others) Also, there is a general statement about that in F.8/1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #14 from joseph at codesourcery dot com 2006-09-07 01:52 --- Subject: Re: What should be value of complexdouble(1.0,0.0) *= -1? On Thu, 7 Sep 2006, pcarlini at suse dot de wrote: F.8 is *illustrative* of transformations that are *not* permitted. It doesn't permit anything. Where do you read that in F.8.2 ?!? I read: 0 * x - 0.0The expressions 0 * x and 0.0 are not equivalent if x is NaN, infinite, or -0 Where do you read that in all the other cases (e.g., when x is a normal number) 0 * x and 0.0 are not equivalent?!? Those are *examples* of when they are not equivalent. It so happens that they are not an exhaustive list of examples, since 0 * -finite is -0 as well. As examples, they are informative not normative. The examples are listed in F.8.2 as a warning to implementors of what not to do. The normative requirements in F.3 apply regardless; F.8.2 gives some transformations that are not valid because implementing them would cause the implementation to fail to implement F.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #15 from joseph at codesourcery dot com 2006-09-07 01:57 --- Subject: Re: What should be value of complexdouble(1.0,0.0) *= -1? On Thu, 7 Sep 2006, pcarlini at suse dot de wrote: And, by the way, it's also generally untrue that F8 is only illustrative of not permitted transformations. For example, a few lines above: 1 * x and x / 1 - x The expressions 1 * x, x / 1 and x are equivalent (on IEC 60559 machines, among others) Such statements also are informative, not normative. The normative requirements come from F.3 (the operations shall be the IEC 60559 operations) and IEC 60559. A transformation is permitted iff it conforms to the normative requirements under the as-if rule of 5.1.2.3. F.8.2 gives hints, but they are just hints; you can make a transformation iff you can show that it does not change the semantics required by 5.1.2.3, F.3 and the other normative requirements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #16 from pcarlini at suse dot de 2006-09-07 02:04 --- (In reply to comment #15) Such statements also are informative, not normative. The normative requirements come from F.3 (the operations shall be the IEC 60559 operations) and IEC 60559. If you have IEC 60559 at hand, and it explicitely says, as normative, that 0 * -finite = -0 then, I agree that this is a bug. However, I have yet to understand why F.8.2, in particular the positive statements, can be considered only illustrative, when the entire F is normative and there are no indications of that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #17 from bangerth at math dot tamu dot edu 2006-09-07 02:29 --- Subject: Re: What should be value of complexdouble(1.0,0.0) *= -1? If you have IEC 60559 at hand, and it explicitely says, as normative, that 0 * -finite = -0 then, I agree that this is a bug. However, I have yet to understand why F.8.2, in particular the positive statements, can be considered only illustrative, when the entire F is normative and there are no indications of that. It is true that Appendix F has normative in the section title, but F.8 starts out with This section identifies code transformations that might subvert IEC 60559-specified behavior, and others that do not. I read that as this section is illustrative. I pretty much read F.8.2 as a list of things to watch out for. The right hand side of the table appears to me to be cases of where for example the transformation on the left is not valid, but I don't think it is meant as an exhaustive list of these cases. W. - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #18 from pcarlini at suse dot de 2006-09-07 02:47 --- (In reply to comment #17) It is true that Appendix F has normative in the section title, but F.8 starts out with ... in any case, the IEC 60559 entry in C99status reads Broken ;) ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug testsuite/28969] New: FAIL: gcc.dg/nrv3.c scan-tree-dump-times return slot optimization 2
Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .2/objdir/gcc/ /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/nrv3.c -O -fdum p-tree-optimized -fno-show-column -S -o nrv3.s(timeout = 300) PASS: gcc.dg/nrv3.c (test for excess errors) FAIL: gcc.dg/nrv3.c scan-tree-dump-times return slot optimization 2 -- Summary: FAIL: gcc.dg/nrv3.c scan-tree-dump-times return slot optimization 2 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* (32-bit) GCC host triplet: hppa*-*-* (32-bit) GCC target triplet: hppa*-*-* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28969
[Bug middle-end/28862] [4.0/4.1/4.2 Regression] attribute ((aligned)) ignored on vector variables
--- Comment #10 from patchapp at dberlin dot org 2006-09-07 03:30 --- Subject: Bug number PR middle-end/28862 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-09/msg00204.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
[Bug rtl-optimization/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-09-07 04:24 --- Subject: Bug 27883 Author: pinskia Date: Thu Sep 7 04:24:24 2006 New Revision: 116739 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116739 Log: 2006-09-06 James E Wilson [EMAIL PROTECTED] PR rtl-opt/27883 * flow.c (update_life_info): If UPDATE_LIFE_LOCAL and PROP_DEATH_NOTES then call count_or_remove_death_notes. 2006-09-06 Andrew Pinski [EMAIL PROTECTED] PR rtl-opt/27883 * g++.dg/opt/copysign-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/copysign-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/flow.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug rtl-optimization/27883] [4.0/4.1 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-09-07 04:24 --- Fixed at least on the mainline now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.1.0 4.2.0 |4.0.0 4.1.0 Known to work|3.4.0 |3.4.0 4.2.0 Summary|[4.0/4.1/4.2 regression] in |[4.0/4.1 regression] in |schedule_insns, at sched- |schedule_insns, at sched- |rgn.c:3038 on mips |rgn.c:3038 on mips http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug middle-end/28970] New: Wrong code for simple loop test case
We generate bad code for the following test case using the latest 4.1 compiler.
It compiles and runs fine using 4.2. It also compiles and runs fine with my
3.3.3 system compiler. I've tested this on both x86_64 and ppc64 systems, and
the test case fails for both when compiled as a 32-bit app and passes when
compiled as a 64-bit app.
#include stdio.h
int tar (int i)
{
printf(expected = %d, actual = %d\n, 36863, i);
return -1;
}
void bug(int q, int bcount)
{
int j = 0;
int outgo = 0;
while(j != -1)
{
outgo++;
if (outgo q-1)
outgo = q-1;
j = tar (outgo*bcount);
}
}
int main(void)
{
bug(5, 36863);
return 0;
}
[EMAIL PROTECTED]:~ gcc-4.1.2 -O2 bug01.c
[EMAIL PROTECTED]:~ ./a.out
expected = 36863, actual = 184315
--
Summary: Wrong code for simple loop test case
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bergner at vnet dot ibm dot com
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28970
[Bug middle-end/28970] [4.1 Regression] Wrong code for simple loop test case
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-07 05:01 --- Confirmed, this is a loop.c bug which is why it is not in 4.2.0 at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc64-linux | GCC host triplet|powerpc64-linux | GCC target triplet|powerpc64-linux |powerpc-linux, i686-linux- ||gnu Keywords||wrong-code Known to fail||4.1.0 4.1.1 4.1.2 Known to work||4.0.0 Last reconfirmed|-00-00 00:00:00 |2006-09-07 05:01:38 date|| Summary|Wrong code for simple loop |[4.1 Regression] Wrong code |test case |for simple loop test case Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28970
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #8 from bergner at vnet dot ibm dot com 2006-09-07 05:14 --- Ok, this also passed regression tests on powerpc64-linux (32-bit and 64-bit testsuite runs) for c, c++, fortran, objc, obj-c++ and java. Does the attached patch look reasonable to everyone? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c/27702] the trampoline code of nested functions depends on executable stacks
--- Comment #4 from hollis at penguinppc dot org 2006-09-07 05:22 --- Andrew, could you elaborate on the FC5 kernel bug and the rules that are always used? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27702
Federal provincial funds available
gcc-bugs@gcc.gnu.org CSDGIF.GIF Description: Binary data
