[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #4 from ubizjak at gmail dot com 2007-10-17 07:08 --- Patch in testing. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-10-16 20:02:50 |2007-10-17 07:08:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug fortran/33760] Bind(C): Using C_PTR as structure constructor gives an ICE
--- Comment #3 from burnus at gcc dot gnu dot org 2007-10-17 06:57 --- FIXED on the trunk (4.3.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33760
[Bug fortran/33760] Bind(C): Using C_PTR as structure constructor gives an ICE
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-17 06:57 --- Subject: Bug 33760 Author: burnus Date: Wed Oct 17 06:57:06 2007 New Revision: 129402 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129402 Log: 2007-10-17 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/33760 * symbol.c (gen_special_c_interop_ptr): Remove code to create constructor for c_null_ptr and c_null_funptr with value of 0. * expr.c (check_init_expr): Prevent check on constructors for iso_c_binding derived types. * resolve.c (resolve_structure_cons): Verify that the user isn't trying to invoke a structure constructor for one of the iso_c_binding derived types. 2007-10-17 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/33760 * gfortran.dg/c_ptr_tests_13.f03: New test case. Added: trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_13.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33760
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #5 from uros at gcc dot gnu dot org 2007-10-17 08:25 --- Subject: Bug 32961 Author: uros Date: Wed Oct 17 08:25:15 2007 New Revision: 129403 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129403 Log: PR target/32961 * config/i386/i386.c (ix86_expand_builtin) [IX86_BUILTIN_PSLLWI128, IX86_BUILTIN_PSLLDI128, BUILTIN_PSLLQI128, IX86_BUILTIN_PSRAWI128, IX86_BUILTIN_PSRADI128, IX86_BUILTIN_PSRLWI128, IX86_BUILTIN_PSRLDI128, IX86_BUILTIN_PSRLQI128]: Do not require immediate shift value. config/i386/emmintrin.h (_mm_slli_epi16, _mm_slli_epi32, _mm_slli_epi64, _mm_srai_epi16, _mm_srai_epi32, _mm_srli_epi16, _mm_srli_epi32, _mm_srli_epi64): Remove 'const' from count argument. Remove macros for !__OPTIMIZE__ case. testsuite/ChangeLog: PR target/32961 * gcc.target/i386/pr32961.c: New testcase. * gcc.target/i386/sse-13.c: Remove __builtin_ia32_psllwi128, __builtin_ia32_psrlqi128, __builtin_ia32_psrlwi128, __builtin_ia32_psrldi128, __builtin_ia32_psrawi128, __builtin_ia32_psradi128, __builtin_ia32_psllqi128 and __builtin_ia32_pslldi128 defines. Added: trunk/gcc/testsuite/gcc.target/i386/pr32961.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/emmintrin.h trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/sse-12.c trunk/gcc/testsuite/gcc.target/i386/sse-13.c trunk/gcc/testsuite/gcc.target/i386/sse-14.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug middle-end/33794] Wrong code w/ -m32 -ffast-math -march=opteron
--- Comment #2 from ubizjak at gmail dot com 2007-10-17 09:10 --- (In reply to comment #1) Since this is using -ffast-math, i suspect this is not a bug. By adding a print before the condition (line 6372), it looks that something goes seriously wrong: gfortran -O2: cpu time to define wand geometries/inductances = 0.003 cpu time to define res-q coil geometry/inductances = 0.004 inductance = -4.96596104015761125E-003 inductance = -5.80817784327351903E-003 ... gfortran -O2 -ffast-math: cpu time to define wand geometries/inductances = 0.003 cpu time to define res-q coil geometry/inductances = 0.003 inductance = -3.2565300518352496 bad mutual inductance between quad1 and the wand transmit coil, abort. computed mutual inductance = -3.2565300518352496 The difference is 3 orders of magnitude! I will run a bisection to isolate the change that introduced this failure. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-17 09:10:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #3 from ubizjak at gmail dot com 2007-10-17 09:11 --- Confirmed with plain -O2 -ffast-math on i686-pc-linux-gnu. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|Wrong code w/ -m32 -ffast- |[4.3 regression] Wrong code |math -march=opteron |w/ -ffast-math http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug web/32965] missing documentation for -ftree-dse
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32965
[Bug c/33798] tree-dse / -ftree-dse behavior not documented
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-17 09:14 --- *** This bug has been marked as a duplicate of 32965 *** -- 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=33798
[Bug web/32965] missing documentation for -ftree-dse
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-17 09:14 --- *** Bug 33798 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||metallurge at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32965
[Bug fortran/33097] Function decl trees without proper argument list
--- Comment #8 from asl at math dot spbu dot ru 2007-10-17 10:17 --- (In reply to comment #3) Confirmed. The same thing is true for external procedures, like: program test real x external x print *, x(2) end program test real function x(i) integer i x = i + 1 end function x This isn't so bad, because decl for x is emitted as vararg function and thus tree is not bogus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #4 from ubizjak at gmail dot com 2007-10-17 10:23 --- Bisection points to r129350: http://gcc.gnu.org/viewcvs?view=revrevision=129350 PR tree-optimization/33619 * tree-ssa-ter.c (is_replaceable_p): Return false for all calls. * gcc.dg/pr33619.c: New test. -- ubizjak at gmail dot com changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-17 10:39 --- And really that patch should not change anything really since it just means TER does not cross function call boundaries now (and not just accross over non pure/const function calls). Can you at least give the final_clean for the file which is missed compiled for both before and after the patch? Since I doubt TER is doing something wrong. -- 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=33794
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #7 from pranav dot bhandarkar at gmail dot com 2007-10-17
10:49 ---
Created an attachment (id=14362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14362action=view)
Reduced Testcase. Small Code, huge datastructure.
In the attached testcase due to an ivopts modification, while
rewriting the uses (rewrite_uses) the compiler crashes in tree-ssa-operands.c
because the memory required for the virtual operands of the modified stmt is
much greater than the thresholds controlled by OP_SIZE_{1,2,3} in
tree-ssa-operands.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #8 from pranav dot bhandarkar at gmail dot com 2007-10-17 10:50 --- Adding Andrew here. -- pranav dot bhandarkar at gmail dot com changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-17 11:02 --- Also what happens if you use -ffloat-store ? Even though it might be 3 orders of magnitude, this could be still the same issue as PR 323 (errors multiply in some cases). Also note -ffloat-store disables TER for floating point types. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #3 from zadeck at naturalbridge dot com 2007-10-17 11:25 --- Subject: Re: valgrind error with -O2 for linux kernel code bergner at gcc dot gnu dot org wrote: --- Comment #2 from bergner at gcc dot gnu dot org 2007-10-17 04:46 --- Although valgrind is correct that we are doing an uninitialized read, the code is actually working as designed and is correct. When we allocate a sparseset, we only need to set set-members to 0 to clear the set. The arrays set-sparse[] and set-dense[] are not and do not need to be initialized. To test a value n for membership in set, it needs to statisfy two properties: set-sparse[n] set-members and set-dense[set-sparse[n]] == n The uninitialized read occurs when n is not (and never has been) a member of set. In this case, set-sparse[n] will be uninitialized and could be any value. If set-sparse[n] happens to be = set-members, we luckily (but correctly) return that n is not a member of the set. If the uninitialized set-sparse[n] is set-members, we continue on to verify that set-dense[set-sparse[n]] == n. This test cannot be true since all set-dense[i] entries for i set-members are initialized and n is not a member of the set. So yes we do some uninitialized accesses to the sparse array, but that's ok. It's also a benefit of sparseset, given that we don't have to memset/clear the whole sparseset data structure before using it, so it's fast. peter, i think that this is clever and nice but it is not going to fly. people will be running valgrind and this will hit them over and over again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug c++/5645] gcc warns that pure virtual class not explicitly initialized
--- Comment #4 from manu at gcc dot gnu dot org 2007-10-17 11:26 --- Does this patch makes any sense? This needs testcases (suggestions for extra testcases are welcome), Changelog, bootstrap + testing and proper submission. --- init.c 2007-09-20 15:13:00.0 +0100 +++ init.c.fixed2007-10-17 12:20:24.0 +0100 @@ -684,10 +684,11 @@ emit_mem_initializers (tree mem_inits) /* If these initializations are taking place in a copy constructor, the base class should probably be explicitly -initialized. */ +initialized unless it is nearly empty. */ if (extra_warnings !arguments DECL_COPY_CONSTRUCTOR_P (current_function_decl) - TYPE_NEEDS_CONSTRUCTING (BINFO_TYPE (subobject))) + TYPE_NEEDS_CONSTRUCTING (BINFO_TYPE (subobject)) + !CLASSTYPE_NEARLY_EMPTY_P (BINFO_TYPE (subobject)) warning (OPT_Wextra, %Jbase class %q#T should be explicitly initialized in the copy constructor, current_function_decl, BINFO_TYPE (subobject)); -- manu at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-12-11 21:53:55 |2007-10-17 11:26:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5645
[Bug c++/33799] New: Return value's destructor not executed when a local variable's destructor throws
In C++, if a local variable's destructor throws after the return value object
has been created, the return value object is never destroyed!
G++ uses the allowed C++ return value optimisation and creates a return value
object directly without copying it. This is probably one source of the bug.
This bug manifests in all versions of g++ (3.2.3 - 4.2.2) I happened to have on
my machine, it also shows on both i686 and x86_64 architectures. It seems that
throwing destructors are rare enough so that this bug has gone unnoticed for
really long... :)
Test case:
etest.cc --
#include iostream
#include ostream
using namespace std;
class X
{
public:
X(bool throws) : throws_(throws)
{
cerr X::X() ( throws_ ) endl;
}
X(const X x) : throws_(x.throws_)
{
cerr X::X(const X) ( throws_ ) endl;
}
~X()
{
cerr X::~X() ( throws_ ) endl;
if (throws_) { throw 1; }
}
private:
bool throws_;
};
X f()
{
X x(true);
return X(false);
}
int main()
{
try
{
f();
}
catch (...)
{
cerr Catch! endl;
}
}
-- end of etest.cc ---
pulu:/home/bitti/tmp/t g++ etest.cc
pulu:/home/bitti/tmp/t ./a.out
X::X() (1)
X::X() (0)
X::~X() (1)
Catch!
--
Summary: Return value's destructor not executed when a local
variable's destructor throws
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bitti at iki dot fi
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=33799
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #8 from ubizjak at gmail dot com 2007-10-17 11:40 --- (In reply to comment #6) Also what happens if you use -ffloat-store ? -O2 -ffast-math -ffloat-store works OK... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #7 from ubizjak at gmail dot com 2007-10-17 11:38 --- (In reply to comment #5) There are (many!) changes of type: - D.6241 = __builtin_sqrt (receive_coil_1.self_ind * transmit_coil.self_ind); - coil_coil_mutuals[0] = coil_coil_mutuals[0] / D.6241; + coil_coil_mutuals[0] = coil_coil_mutuals[0] / __builtin_sqrt (receive_coil_1 where (-) represents failed run and (+) successful run, produced with Jakub's patch removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-10-17 11:46 --- I think what is happening is that coil_coil_mutuals[0] / D.6241 is being expanded as coil_coil_mutuals[0] * (1/D.6241) which is not bad, just inconstaint. I think we need to look into this more but I doubt there is anything you can fix here. This is just the way stuff works with -ffast-math and x87. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-17 12:03 --- As a data point, EDG based icpc behaves the same. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws
--- Comment #2 from bitti at iki dot fi 2007-10-17 12:21 --- I also tried on other compilers. Sun's compiler (CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25) shows the same bug as Gcc. Microsoft Visual Studio 2005 works ok and destroys both objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #10 from ubizjak at gmail dot com 2007-10-17 12:28 --- (In reply to comment #9) I don't want to claim excess precision problems here. I was trying to debug self_ind_cir_coil procedure, as it looks that the problem is in calculation of self_r output. The input to this procedure is always the same: 2.99989E-002 3.6E-003 16.666 1.25663706143591729E-006 but for -O2 -ffast-math -ffloat-store, self_l is returned as self_l 3.66008420600437631E-002 and for -O2 -ffast-math, self_l is returned as (wrong): self_l 8.51113565610957021E-008 I don't see why the code in between would produce such wildly different result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-17 12:36 --- (In reply to comment #3) You're right. The assignment even produces the temporary for the lhs index that it should. Now why on earth does this happen in 64bit mode an not in 32bit?? Sometimes, the difference between 32 and 64 bit is that gfortran generates conversions for subscripts from int4 to int8 in the 64-bit case, while it uses the int4 directly in the 32 bit case; an expression can then be an EXPR_FUNCTION in one case (__convert_i4_i8, or something like that) and an EXPR_CONST or EXPR_ARRAY in the other case; this difference then makes us take different code paths. I've seen it happen for a recent PR, though I can't remember which. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33749
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #11 from ubizjak at gmail dot com 2007-10-17 12:39 --- The problem is somewhere around line 212 in induct.f90. Adding some debug code at the end of the function: ... !evaluate self-inductance ! self_l = (mu * turns**2 * l**2 * 2.0_longreal * r)/3.0_longreal * (((tan(alpha)**2-1.0_longreal)*elliptice+elliptick)/sin(alpha) - tan(alpha)**2) ! print *,input, mu, turns, l, r, alpha, elliptice, elliptick print *,result, self_l end subroutine self_ind_cir_coil we obtain: -O2 -ffast-math input 1.25663706143591729E-006 16.666 3.6E-003 2.99989E-002 1.5208379310729538 1.00484582819708894.3853871539549072 result 8.51113565610956888E-008 -O2 -ffast-math -ffloat-store: input 1.25663706143591729E-006 16.666 3.6E-003 2.99989E-002 1.5208379310729538 1.00484582819708894.3853871539548939 result 2.13170362012935939E-002 So, for the same input parameters, the equation above returns the result that differs in 3 orders of magnitude. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug target/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #12 from ubizjak at gmail dot com 2007-10-17 13:57 --- Well, the problem here is that swap insn is not emitted before x87 fptan. It is actually my fault (UNSPEC_TAN handling is a bit wrong), the problem is only exposed by Jakub's patch. So, mine. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|WAITING |ASSIGNED Component|middle-end |target GCC target triplet||i686-pc-linux-gnu Last reconfirmed|2007-10-17 09:10:16 |2007-10-17 13:57:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #4 from bergner at gcc dot gnu dot org 2007-10-17 14:21 ---
People using valgrind already have to deal with false positives and actual
uninitialized uses (like this one) that are harmless. If you look at your
valgrind install, you'll see that there are several error suppression files
installed with valgrind:
[EMAIL PROTECTED]:~/gcc/bugs rpm -ql valgrind | grep '.supp$'
/usr/lib64/valgrind/default.supp
/usr/lib64/valgrind/glibc-2.2.supp
/usr/lib64/valgrind/glibc-2.3.supp
/usr/lib64/valgrind/glibc-2.4.supp
/usr/lib64/valgrind/glibc-2.5.supp
/usr/lib64/valgrind/xfree-3.supp
/usr/lib64/valgrind/xfree-4.supp
To suppress this particular error/warning, you just need to create another
suppression file for this error with the contents below and pass
--suppressions=/path/to/sparseset.supp to valgrind and all should be well.
[EMAIL PROTECTED]:~/gcc/bugs cat sparseset.supp
{
SparseSet-Cond-0
Memcheck:Cond
fun:global_conflicts
fun:rest_of_handle_global_alloc
fun:execute_one_pass
fun:execute_pass_list
fun:execute_pass_list
fun:tree_rest_of_compilation
fun:cgraph_expand_function
fun:cgraph_optimize
fun:c_write_global_declarations
fun:toplev_main
fun:main
}
{
SparseSet-Value4-0
Memcheck:Value4
fun:global_conflicts
fun:rest_of_handle_global_alloc
fun:execute_one_pass
fun:execute_pass_list
fun:execute_pass_list
fun:tree_rest_of_compilation
fun:cgraph_expand_function
fun:cgraph_optimize
fun:c_write_global_declarations
fun:toplev_main
fun:main
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug target/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #13 from ubizjak at gmail dot com 2007-10-17 14:31 --- Proposed patch in testing: Index: reg-stack.c === --- reg-stack.c (revision 129402) +++ reg-stack.c (working copy) @@ -1085,11 +1085,13 @@ special case with i387 UNSPEC_TAN, where destination is live (an argument to fptan) but inherent load of 1.0 is modelled as a load from a constant. */ - if (! (GET_CODE (pat) == PARALLEL - XVECLEN (pat, 0) == 2 - GET_CODE (XVECEXP (pat, 0, 1)) == SET - GET_CODE (SET_SRC (XVECEXP (pat, 0, 1))) == UNSPEC - XINT (SET_SRC (XVECEXP (pat, 0, 1)), 1) == UNSPEC_TAN)) + if (GET_CODE (pat) == PARALLEL + XVECLEN (pat, 0) == 2 + GET_CODE (XVECEXP (pat, 0, 1)) == SET + GET_CODE (SET_SRC (XVECEXP (pat, 0, 1))) == UNSPEC + XINT (SET_SRC (XVECEXP (pat, 0, 1)), 1) == UNSPEC_TAN) + emit_swap_insn (insn, regstack, dest); + else gcc_assert (get_hard_regnum (regstack, dest) FIRST_STACK_REG); gcc_assert (regstack-top REG_STACK_SIZE); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug target/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #14 from uros at gcc dot gnu dot org 2007-10-17 15:22 --- Subject: Bug 33794 Author: uros Date: Wed Oct 17 15:22:23 2007 New Revision: 129406 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129406 Log: PR middle-end/33794 * reg-stack.c (move_for_stack_reg): Swap input argument of UNSPEC_TAN insn to the top of the stack. Modified: trunk/gcc/ChangeLog trunk/gcc/reg-stack.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
--- Comment #5 from tbm at cyrius dot com 2007-10-17 15:39 --- (In reply to comment #3) Adding Honza to cc: in the hope he can help since he fixed PR30509. Honza: do you think you could take a look at this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug middle-end/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-10-17 15:47 --- Adding Zdenek, also familiar with the dominance code. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug c++/33800] ICE-on-valid (segfault) on x86-64
--- Comment #1 from lloyd at randombit dot net 2007-10-17 16:06 --- Created an attachment (id=14363) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14363action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33800
[Bug middle-end/31947] [4.2 Regression] ICE in calc_dfs_tree, at dominance.c:374
--- Comment #7 from rakdver at gcc dot gnu dot org 2007-10-17 16:07 --- (In reply to comment #0) I'm getting the following ICE with gcc 4.2.0 RC3. It compiles fine with gcc 4.1 and 4.3 20070515. (sid)23889:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2 freehdl-vital_timing.cc freehdl-vital_timing.cc: In function 'array_typelong int delay(const array_typelong int)': freehdl-vital_timing.cc:38: internal compiler error: in calc_dfs_tree, at dominance.c:374 Please submit a full bug report, with preprocessed source if appropriate. (sid)23890:[EMAIL PROTECTED]: ~] g++-4.1 -c -O2 freehdl-vital_timing.cc (sid)23891:[EMAIL PROTECTED]: ~] This ICE happens when there are unreachable blocks in cfg when calculate_dominance_info is called. Adding delete_unreachable_blocks before calculate_dominance_info in tree-vrp.c:identify_jump_threads fixes this ICE (I need to check whether this does not cause other problems, though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31947
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #11 from pthaugen at gcc dot gnu dot org 2007-10-17 16:14 --- Created an attachment (id=14364) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14364action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #12 from pthaugen at gcc dot gnu dot org 2007-10-17 16:18 --- And now some comments to go with the prior attatchment... This checkin is causing a 75% degradation on leslie3d for PowerPC. As HJ observed earlier, it depends on a second function accessing some of the global data. Generated code for simple copy loop in EXTRAPI(), compiled with -O2. revision 126325: .p2align 4,,15 .L3: lfd 0,0(11) #* ivtmp.71, tmp198 add 11,11,6 # ivtmp.71, ivtmp.71, ivtmp.77 stfd 0,0(9) #* ivtmp.76, tmp198 add 9,9,5# ivtmp.76, ivtmp.76, ivtmp.73 bdnz .L3 # revision 126326: .p2align 4,,15 .L6: lwz 10,12(27)# variable.stride, prephitmp.66 lwz 3,12(28) # variable.stride, prephitmp.56 .L3: mullw 10,10,12 # tmp141, prephitmp.66, i lwz 9,36(30) # variable.stride, variable.stride lwz 0,36(31) # variable.stride, variable.stride lwz 8,4(30) # uav.offset, uav.offset lwz 11,4(31) # qav.offset, qav.offset lwz 6,24(30) # variable.stride, variable.stride lwz 7,24(31) # variable.stride, variable.stride lwz 4,0(30) # uav.data, uav.data lwz 5,0(31) # qav.data, qav.data mullw 3,3,12 # tmp160, prephitmp.56, i slwi 9,9,1 # tmp142, variable.stride, slwi 0,0,1 # tmp161, variable.stride, add 9,9,8# tmp143, tmp142, uav.offset add 0,0,11 # tmp162, tmp161, qav.offset add 9,9,6# tmp145, tmp143, variable.stride add 0,0,7# tmp164, tmp162, variable.stride add 9,9,10 # tmp147, tmp145, tmp141 add 0,0,3# tmp166, tmp164, tmp160 slwi 9,9,3 # tmp148, tmp147, slwi 0,0,3 # tmp167, tmp166, addi 12,12,1 # i, i, lfdx 0,5,0 #* qav.data, tmp169 cmpw 7,12,29 # imax.3, tmp170, i stfdx 0,9,4 #* uav.data, tmp169 bne 7,.L6# -- pthaugen at gcc dot gnu dot org changed: What|Removed |Added CC||pthaugen at gcc dot gnu dot ||org, bergner at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug c++/33800] New: ICE-on-valid (segfault) on x86-64
$ g++-4.3-20070907 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907 --enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt Thread model: posix gcc version 4.3.0 20070907 (experimental) (GCC) $ g++-4.3-20070907 -fpic -O1 -c seed.i -o seed.o src/seed.cpp: In member function virtual void Botan::SEED::enc(const Botan::byte*, Botan::byte*) const: src/seed.cpp:52: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Results with other flags: -fpic: OK -fPIC: OK -O1: FAIL -O2: OK -O1 -fpic: FAIL -O1 -fPIC: FAIL -O2 -fpic: FAIL -O2 -fPIC: FAIL -- Summary: ICE-on-valid (segfault) on x86-64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lloyd at randombit dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33800
[Bug fortran/33097] Function decl trees without proper argument list
--- Comment #9 from asl at math dot spbu dot ru 2007-10-17 16:45 --- (In reply to comment #3) Two decls are generated for function x, the first one (inside MAIN__) doesn't have a proper argument list while the second one is OK. When I try to make gfortran emit only one decl per externally-visible function, it's currently choking on this. After some thinking on this example, it seems, I found some solution. My previous approach cannot be completed because of the presence of optional arguments. And even having some valid call, we cannot construct valid decl from this (or we will need some additional logic, which will complete such decls). The idea itself is pretty simple: why don't turn external functions/intrinsics into varargs function (in C/C++ sense). In this case trees won't became bogus anymore, however, having call to varargs function can (in theory) disable some optimization performed on it. Attached patch works fine for me. Any comments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug fortran/33097] Function decl trees without proper argument list
--- Comment #10 from asl at math dot spbu dot ru 2007-10-17 16:46 --- Created an attachment (id=14365) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14365action=view) Patch to mark external decls to be varargs -- asl at math dot spbu dot ru changed: What|Removed |Added Attachment #14069|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug c++/33800] ICE-on-valid (segfault) on x86-64
--- Comment #2 from lloyd at randombit dot net 2007-10-17 16:48 ---
Backtrace (command line args for cc1plus chosen by stracing g++)
$ gdb /home/jack/opt/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus
Using host libthread_db library /lib64/libthread_db.so.1.
(gdb) run -fpreprocessed seed.i -quiet -dumpbase seed.i -mtune=generic
-auxbase-strip seed.o -O1 -fpic -o /tmp/whatever.o
Starting program:
/home/jack/opt/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus
-fpreprocessed seed.i -quiet -dumpbase seed.i -mtune=generic -auxbase-strip
seed.o -O1 -fpic -o /tmp/whatever.o
Program received signal SIGSEGV, Segmentation fault.
0x007a94f5 in reload_as_needed (live_known=1) at
../../gcc-4.3-20070907/gcc/reload1.c:4161
4161 if (p != insn INSN_P (p)
(gdb) backtrace
#0 0x007a94f5 in reload_as_needed (live_known=1) at
../../gcc-4.3-20070907/gcc/reload1.c:4161
#1 0x007acb61 in reload (first=0x2b0f45955680, global=1) at
../../gcc-4.3-20070907/gcc/reload1.c:1146
#2 0x00b39c96 in rest_of_handle_global_alloc () at
../../gcc-4.3-20070907/gcc/global.c:683
#3 0x00761961 in execute_one_pass (pass=0x1001b60) at
../../gcc-4.3-20070907/gcc/passes.c:1115
#4 0x00761b40 in execute_pass_list (pass=0x1001b60) at
../../gcc-4.3-20070907/gcc/passes.c:1168
#5 0x00761b55 in execute_pass_list (pass=0xffd5a0) at
../../gcc-4.3-20070907/gcc/passes.c:1169
#6 0x0083de10 in tree_rest_of_compilation (fndecl=0x2b0f457c8400) at
../../gcc-4.3-20070907/gcc/tree-optimize.c:404
#7 0x009acb80 in cgraph_expand_function (node=0x2b0f45810700) at
../../gcc-4.3-20070907/gcc/cgraphunit.c:1077
#8 0x009aee20 in cgraph_optimize () at
../../gcc-4.3-20070907/gcc/cgraphunit.c:1146
#9 0x004aafed in cp_write_global_declarations () at
../../gcc-4.3-20070907/gcc/cp/decl2.c:3302
#10 0x007e48b7 in toplev_main (argc=Variable argc is not available.
) at ../../gcc-4.3-20070907/gcc/toplev.c:1058
#11 0x003a3d61c784 in __libc_start_main () from /lib64/libc.so.6
#12 0x00403d79 in _start ()
#13 0x7fb66e48 in ?? ()
#14 0x in ?? ()
(gdb) print p
$1 = 0x0
(gdb) print insn
$2 = 0x2b0f459890f0
(gdb) print *insn
$3 = {code = INSN, mode = VOIDmode, jump = 0, call = 0, unchanging = 0, volatil
= 0, in_struct = 0, used = 0, frame_related = 0, return_val = 0, u = {fld =
{{rt_int = 15, rt_uint = 15, rt_str = 0xafafafaf000f Address
0xafafafaf000f out of bounds,
rt_rtx = 0xafafafaf000f, rt_rtvec = 0xafafafaf000f, rt_type =
HImode, rt_addr_diff_vec_flags = {min_align = 15, base_after_vec = 0,
min_after_vec = 0, max_after_vec = 0, min_after_base = 0, max_after_base = 0,
offset_unsigned = 0, scale = 0},
rt_cselib = 0xafafafaf000f, rt_bit = 0xafafafaf000f, rt_tree =
0xafafafaf000f, rt_bb = 0xafafafaf000f, rt_mem = 0xafafafaf000f,
rt_reg = 0xafafafaf000f, rt_constant = 0xafafafaf000f}}, hwint =
{-5787213829993660401},
block_sym = {fld = {{rt_int = 15, rt_uint = 15, rt_str = 0xafafafaf000f
Address 0xafafafaf000f out of bounds, rt_rtx = 0xafafafaf000f,
rt_rtvec = 0xafafafaf000f, rt_type = HImode, rt_addr_diff_vec_flags =
{min_align = 15,
base_after_vec = 0, min_after_vec = 0, max_after_vec = 0,
min_after_base = 0, max_after_base = 0, offset_unsigned = 0, scale = 0},
rt_cselib = 0xafafafaf000f, rt_bit = 0xafafafaf000f, rt_tree =
0xafafafaf000f, rt_bb = 0xafafafaf000f,
rt_mem = 0xafafafaf000f, rt_reg = 0xafafafaf000f, rt_constant
= 0xafafafaf000f}, {rt_int = 1167626240, rt_uint = 1167626240, rt_str =
0x2b0f45989000 \005, rt_rtx = 0x2b0f45989000, rt_rtvec = 0x2b0f45989000,
rt_type = 1167626240,
rt_addr_diff_vec_flags = {min_align = 0, base_after_vec = 0,
min_after_vec = 0, max_after_vec = 0, min_after_base = 0, max_after_base = 1,
offset_unsigned = 0, scale = 152}, rt_cselib = 0x2b0f45989000, rt_bit =
0x2b0f45989000, rt_tree = 0x2b0f45989000,
rt_bb = 0x2b0f45989000, rt_mem = 0x2b0f45989000, rt_reg =
0x2b0f45989000, rt_constant = 0x2b0f45989000}, {rt_int = 1157078704, rt_uint =
1157078704, rt_str = 0x2b0f44f79eb0 \005, rt_rtx = 0x2b0f44f79eb0, rt_rtvec =
0x2b0f44f79eb0,
rt_type = 1157078704, rt_addr_diff_vec_flags = {min_align = 176,
base_after_vec = 0, min_after_vec = 1, max_after_vec = 1, min_after_base = 1,
max_after_base = 1, offset_unsigned = 0, scale = 247}, rt_cselib =
0x2b0f44f79eb0, rt_bit = 0x2b0f44f79eb0,
rt_tree = 0x2b0f44f79eb0, rt_bb = 0x2b0f44f79eb0, rt_mem =
0x2b0f44f79eb0, rt_reg = 0x2b0f44f79eb0, rt_constant = 0x2b0f44f79eb0}}, block
= 0x2b0f45948900, offset = -5787213829993660410}, rv = {cl = 3, decimal = 1,
sign = 1, signalling = 0,
canonical = 0, uexp = 0, sig = {47344592130048, 47344581582512,
47344591866112}}, fv = {data = {low = 12659530243715891215, high =
47344592130048}, mode = 1157078704}}}
--
lloyd at
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-10-17 16:59 --- Can someone explain this may_alias behavior: so we have in the IR: # VUSE SFT.30_53 D.892_19 = qav.data; D.893_20 = (real8[0:] *) D.892_19; in may_alias we get a constraint of: D.892_19 = qav D.893_20 = D.892_19 Isn't this wrong? D. 892_19 shouldn't just point to anywhere? Inside the loop we get: # VUSE imax_33, SFT.11_34, SFT.12_35, SFT.13_36, SFT.14_37, SFT.15_38, SFT.16_39, SFT.17_40, SFT.18_41, SFT.19_42, SFT.20_43, SFT.21_44, SFT.22_45, SFT.23_46, SFT.24_47, SFT.25_48, SFT.26_49, SFT.27_50, SFT.28_51, SFT.29_52, SFT.30_53, SMT.35_54 D.903_30 = (*D.893_20)[D.902_29]; Which obviously shows that the vops are wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug fortran/33097] Function decl trees without proper argument list
--- Comment #11 from asl at math dot spbu dot ru 2007-10-17 17:00 --- Also, some chunk of code in function type creation (gfc_get_function_type() is in question) looks suspicious to me. Let me explain on terms of C (I don't know Fortran at all :) ) Consider we have two function decls: int foo1(); struct some_fat_struct foo2(); Both are varargs functions, but return type for the second will be lowered to void, so, after some lowering they in general should look like: int foo(...); void foo2(struct some_fat_struct *retval, ...); The problem with gfortran is that function, which result is passed by reference (determined with help of gfc_return_by_reference() call inside gfc_get_function_type()) won't be varargs, so inside gfortran FE we'll end with something like: void foo2(some_fat_struct *ptr); but: int foo(...); This looks pretty unlogical to me. Was it intentional? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws
--- Comment #3 from jason at gcc dot gnu dot org 2007-10-17 17:07 --- Similar to Bug 15764. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-17 17:07:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
[Bug target/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #15 from uros at gcc dot gnu dot org 2007-10-17 17:10 --- Subject: Bug 33794 Author: uros Date: Wed Oct 17 17:09:58 2007 New Revision: 129410 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129410 Log: PR middle-end/33794 * gfortran.dg/pr33794.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr33794.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #16 from ubizjak at gmail dot com 2007-10-17 17:11 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|target |middle-end Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug fortran/33097] Function decl trees without proper argument list
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-10-17 17:14 --- (In reply to comment #11) void foo2(some_fat_struct *ptr); but: int foo(...); This looks pretty unlogical to me. Was it intentional? Yes, I think that's intentional. Why is it unlogical? Also, have you looked at how character variables are handled? (appending string length in the arg list) That's a surprising calling convention for people coming from C... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug fortran/33097] Function decl trees without proper argument list
--- Comment #13 from asl at math dot spbu dot ru 2007-10-17 17:27 --- (In reply to comment #12) (In reply to comment #11) void foo2(some_fat_struct *ptr); but: int foo(...); This looks pretty unlogical to me. Was it intentional? Yes, I think that's intentional. Why is it unlogical? Because return type dictates, whether there is ellipsis or not. I think, that both functions should be varargs, no? Also, have you looked at how character variables are handled? (appending string length in the arg list) That's a surprising calling convention for people coming from C... Yes, I saw this. It's pretty clear, not surprising :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug c++/33801] New: Missing warning
For this kind of code:
struct cont
{
typedef const int const_reference;
};
templatetypename C
struct iter
{
void
f(const typename C::const_reference value)
{ }
};
int main()
{
itercont it;
it.f(5);
}
we do not emit any warning for the 'const' in the signature of f. We simply
ignore it. The EDG front-end does.
--
Summary: Missing warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33801
[Bug c++/33801] Missing warning
-- pcarlini at suse dot de changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33801
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-10-17 17:41 --- Subject: Re: [4.3 Regression] Revision 126326 causes 12% slowdown On 17 Oct 2007 16:59:25 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #13 from pinskia at gcc dot gnu dot org 2007-10-17 16:59 --- Can someone explain this may_alias behavior: so we have in the IR: # VUSE SFT.30_53 D.892_19 = qav.data; D.893_20 = (real8[0:] *) D.892_19; in may_alias we get a constraint of: D.892_19 = qav D.893_20 = D.892_19 Isn't this wrong? D. 892_19 shouldn't just point to anywhere? qav should have a constraint somewhere that says qav = ANYTHING You won't directly see D.892_19 = ANYTHING -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug c++/33802] New: g++ says `z' is used uninitialized but this is not true
For the attached testcase, g++ gives a warning saying `z' is used
uninitialized in this function (_is_ used uninitialized, not _may be_ used
uninitialized)
in the statement marked with (***) below. However, `z' is indeed
initialized by the mul() function template, which takes the first
argument by (non-const) reference:
template typename To_Policy, typename From1_Policy, typename From2_Policy,
typename Type
inline Result
add_mul_int(Type to, const Type x, const Type y, Rounding_Dir dir) {
Type z;
Result r = mulTo_Policy, From1_Policy, From2_Policy(z, x, y, dir);
switch (r) {
case V_NEG_OVERFLOW:
case V_LT:
if (to = 0) {
to = z; (***)
return r;
}
To reproduce:
$ bunzip2 bug.cc.bz2
$ md5sum bug.cc
bb3e86d1d865d1b661dd86da3456c909 bug.cc
$ g++ -Wall -O2 -c bug.cc
bug.cc: In function void
Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_NumberT,
P, const Parma_Polyhedra_Library::Checked_NumberT, P, const
Parma_Polyhedra_Library::Checked_NumberT, P) [with T = long int, Policy =
Parma_Polyhedra_Library::Checked_Number_Default_Policy]:
bug.cc:37941: warning: z is used uninitialized in this function
$ g++ -v
Using built-in specs.
Target: x86_64-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 --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
$
The file bug.cc.t28.ssa is 944683 bytes once compressed: I will attach it if
required.
--
Summary: g++ says `z' is used uninitialized but this is not true
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #1 from bagnara at cs dot unipr dot it 2007-10-17 18:40 --- Created an attachment (id=14366) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14366action=view) (Big) testcase that allows to reproduce -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-17 18:46 --- I doubt this is not an incorrect warning. -- 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=33802
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #5 from wilson at specifix dot com 2007-10-17 20:53 --- Subject: Re: valgrind error with -O2 for linux kernel code bergner at gcc dot gnu dot org wrote: --- Comment #2 from bergner at gcc dot gnu dot org 2007-10-17 04:46 --- Although valgrind is correct that we are doing an uninitialized read, the code is actually working as designed and is correct. A comment in the code mentioning that the uninit reads are intentional would be useful. Otherwise, you will keep getting this same question, and have to keep answering it. Also, it might be a good idea to make sure that the sparse field is marked as volatile, to ensure that reads are never optimized away. As the gcc optimizer gets better, e.g. LTO and aggressive inlining, it might be possible to end up with a case where gcc can prove that it has an uninit read of this field and optimize it away. This will result in a use of an uninit register. On IA-64, an uninit register may have the NaT (Not a Thing) bit set which is used for speculation. Hence use of an uninit register may cause an unexpected speculation failure, which will cause a program to crash. We can avoid this chain of events by making this a volatile field, which will make it impossible for gcc to optimize away reads from this field, even if uninitialized. It also serves as a clue to other people reading the code that this field is special. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug c/33803] New: ICE during build of DES
Multiple versions of gcc give an ICE when compiling the attached preprocessed version of the FreeBSD des.c. The following is produced by gcc 4.2.2 $ h8300-rtems4.9-gcc -O2 -c des1.c des1.c: In function 'des_init': des1.c:4246: internal compiler error: in tree_low_cst, at tree.c:4554 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE during build of DES Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: h8300*-*-rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33803
[Bug c/33803] ICE during build of DES
--- Comment #1 from joel at gcc dot gnu dot org 2007-10-17 21:07 --- Created an attachment (id=14367) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14367action=view) preprocessed code to generate problem This is the preprocessed version of the file used to generate the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33803
[Bug tree-optimization/33804] New: ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
[EMAIL PROTECTED]:/tmp% gcc -c -O2 129.c [EMAIL PROTECTED]:/tmp% gcc -c -O2 -ftree-vectorize 129.c 129.c: In function 'add_bytes_c': 129.c:1: internal compiler error: in vect_transform_stmt, at tree-vect-transform.c:6131 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in vect_transform_stmt, at tree-vect- transform.c:6131 with -ftree-vectorize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
[Bug middle-end/33803] ICE during build of DES
--- Comment #2 from joel at gcc dot gnu dot org 2007-10-17 21:12 --- I have tried this code with the following gcc versions: WORKS 3.2.3: -O2 FAILS 4.1.1: -O2 FAILS 4.2.1: -O2 FAILS 4.2.2: -O2 WORKS 4.2.1: -O0 WORKS 4.2.2: -O0 WORKS 4.1.1: -O0 This is a regression from the 3.x compiler and an optimization bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33803
[Bug tree-optimization/32921] [4.3 Regression] Revision 126326 causes 12% slowdown
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-17 21:21 --- comment #12 hints at that this is really the same problem as PR32624 (which basically says aliasing is fucked up and non-deterministic). -- rguenth 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=32921
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-17 21:23 --- I doubt this is not an incorrect warning. what? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #6 from geoffk at gcc dot gnu dot org 2007-10-17 21:28 --- Shouldn't you have to use _mm_sll_epi32(s, _mm_cvtsi32_si128 (c)) instead? Or does the 'i' in 'slli' stand for 'int' not 'immediate'? I thought that the list of _mm_sl* intrinsics in the assembly reference guide (Intel doc 253667, http://www.intel.com/design/processor/manuals/253667.pdf, page 4-172 and 4-173) were supposed to match up one-for-one with the instructions forms (on page 4-170). The assembly reference also says that _mm_slli_epi32 generates a single instruction, as it is listed in table C-1. On the other hand, icc's documentation, http://download.intel.com/support/performancetools/c/linux/v9/intref_cls.pdf, on page 137, says for _mm_slli_si128, 'imm must be an immediate', but doesn't say that for _mm_slli_epi32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #7 from hjl at lucon dot org 2007-10-17 21:48 ---
Icc generates:
#include xmmintrin.h
__m128i
foo (__m128i a, int n )
{
a = _mm_slli_epi32( a, n );
return a;
}
[EMAIL PROTECTED] tmp]$ /opt/intel/cce/10.0/bin/icc -c x.c
[EMAIL PROTECTED] tmp]$ objdump -d x.o
x.o: file format elf64-x86-64
Disassembly of section .text:
foo:
0: 66 0f 6e cf movd %edi,%xmm1
4: 66 0f f2 c1 pslld %xmm1,%xmm0
8: c3 retq
9: 90 nop
a: 90 nop
b: 90 nop
[EMAIL PROTECTED] tmp]$
BTW, _mm_slli_si128 maps to pslldq and it only takes imm as shift count.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-10-17 22:32 --- I've been thinking about MINVAL((/NaN,NaN/)), ie minval of an array containing only NaNs, over and over again, and it's a tough choice. Here's what compilers currently output for MINVAL and MAXVAL: Intel: Inf, -Inf Sun: -NaN, -NaN (yes, that's a negative NaN; don't ask) g95: Huge, -Huge gfortran: Huge, -Huge portland: NaN, -Huge MIPSpro: Inf, NaN IBM: Huge, -Huge So: we can take portland and MIPSpro out, they lack consistency; Intel goes for infinities, and I don't see how they can justify this in any way, so let's take them out also. The only two options worth considering are NaN (as Sun does) and Huge (as Intel and g95 do). Both have pros and cons. The main pro for NaN is that it ensures that MAXVAL((/x,x/)) is always equal to MAX(x,x), even when x is a NaN. The main pro for Huge is that it is more consistent with the way NaN are ignored: for all other purposes, NaNs in the array are handled as if the mask for that element was .false., so why single out the only NaNs case? Since different compilers already give different answers for this problem, I guess we can pick the solution we're most comfortable with. Unless people feel strongly against it, I'd like to go with Huge, because 1. I'm more convinced by arguments in favour of it, and 2. it's probably easier/faster/more efficient to implement, because it doesn't need yet another special case. Opinions welcome. (What a long rant.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug c++/33805] New: Static member of the class should be able to depend on classes size
I got this error and this made me thinking.
First example produces an error:
m.C:2: error: invalid application of 'sizeof' to incomplete type 'B'
But the second one doesn't.
Why if I take sizeof() of the current class when instantiating the object it's
an error and if I pass the type to the class A as a template parameter this
isn't an error. And class A can do with it's template parameter all it wants
and this is ok.
I think first example should compile w/out errors since static object doesn't
even change the size of B, so it shouldn't matter what it is.
this code produces an error
templateint i struct A { };
struct B { static Asizeof(B) a; };
this code compiles w/out errors
templatetypename O struct A { };
struct B { static AB a; };
--
Summary: Static member of the class should be able to depend on
classes size
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33805
[Bug middle-end/33806] New: [regression 4.3] gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on Darwin
At revision 129402, gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on Darwin: [karma] darwin_buildw/gcc% gfc -m64 -O3 -fcray-pointer ../../_gcc-clean/gcc/testsuite/gfortran.dg/cray_pointers_2.f90 ../../_gcc-clean/gcc/testsuite/gfortran.dg/cray_pointers_2.f90: In function 'ptr12': ../../_gcc-clean/gcc/testsuite/gfortran.dg/cray_pointers_2.f90:3360: internal compiler error: in change_address_1, at emit-rtl.c:1888 It worked at revision 129382. -- Summary: [regression 4.3] gfortran.dg/cray_pointers_2.f90 give an ICE at -O3 -m64 on Darwin Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33806
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2007-10-17 23:49 --- Well this is just one little opinion: There is no way that it is realistic to get a valid number out of a NaN or a group of NaNs. It can only be NaN. It's like a place from which there is no return. Maybe we should define a new type called Useless so that people understand what a NaN is. :) Returning anything else would mask that the array was all NaNs and give a false sense that all is OK, when its not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug driver/33577] Compile failing for xpdf 3.02
--- Comment #5 from cabanasg at metro dot net 2007-10-17 23:51 --- I upgraded my gcc and g++ compilers to version 4.0.0. Tried to install xpdf-3.02 again, the ./configure part goes well, but the make or gmake faile with the following error message: (Any help will be greatly appreciated) ld: 0711-317 ERROR: Undefined symbol: vtable for __cxxabiv1::__class_type_info ld: 0711-317 ERROR: Undefined symbol: vtable for __cxxabiv1::__si_class_type_info ld: 0711-317 ERROR: Undefined symbol: .SplashFontEngine::SplashFontEngine(int, int) ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: 1254-004 The error code from the last command is 1. -- cabanasg at metro dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33577
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2007-10-18 00:18 --- Ok for hypot, and that may make sense knowing the nature of the function. Minval is not a complex or transcendental function. I should not write in loose general terms. So maybe approach the question differently. Which element in an array of NaNs is the smallest one and what is its value? If I pick any one element, its value is NaN. It does not matter which one I select, its value always comes out NaN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #23 from kargl at gcc dot gnu dot org 2007-10-17 23:57 --- (In reply to comment #22) Well this is just one little opinion: There is no way that it is realistic to get a valid number out of a NaN or a group of NaNs. It can only be NaN. Read the hypot man page. hypot(infinity, v) = hypot(v, infinity) = +infinity for all v, including NaN. So one can get a non-NaN when an NaN is involved in a computation. For the task at hand, I think gfortran should be compatible with either g95 or Intel, and because g95 and gfortran already agree the decision is moot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #20 from dje at gcc dot gnu dot org 2007-10-18 00:48 --- Yes, effectively -blazy, because of AIX's loader semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug driver/33577] Compile failing for xpdf 3.02
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-18 00:56 --- with the following error message: (Any help will be greatly appreciated) ld: 0711-317 ERROR: Undefined symbol: vtable for __cxxabiv1::__class_type_info Yes you are not linking with the correct libstdc++ or not linking with it at all. Link with g++ and not gcc directly. -- 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=33577
[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements
--- Comment #5 from pault at gcc dot gnu dot org 2007-10-18 04:26 --- (In reply to comment #4) (In reply to comment #3) You're right. The assignment even produces the temporary for the lhs index that it should. Now why on earth does this happen in 64bit mode an not in 32bit?? Sometimes, the difference between 32 and 64 bit is that gfortran generates conversions for subscripts from int4 to int8 in the 64-bit case, while it uses the int4 directly in the 32 bit case; an expression can then be an EXPR_FUNCTION in one case (__convert_i4_i8, or something like that) and an EXPR_CONST or EXPR_ARRAY in the other case; this difference then makes us take different code paths. I've seen it happen for a recent PR, though I can't remember which. FX, Yes, I just beat you to it http://gcc.gnu.org/ml/fortran/2007-10/msg00207.html :) I'll try to post the patch tomorrow. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-10-12 15:18:17 |2007-10-18 04:26:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33749
[Bug target/32961] [4.2/4.3 Regression]: Gcc has different requirements for x86 shift xmm intrinsics
--- Comment #8 from geoffk at gcc dot gnu dot org 2007-10-18 04:53 --- (In reply to comment #7) Icc generates: 0: 66 0f 6e cf movd %edi,%xmm1 4: 66 0f f2 c1 pslld %xmm1,%xmm0 Right, that's what icc's documentation would suggest. But that documentation seems inconsistent with the assembly reference guide. It may be that the assembly reference guide is the one that's wrong, or that icc intentionally extends it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
--- Comment #1 from ubizjak at gmail dot com 2007-10-18 05:26 --- Testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
