[Bug c++/34950] [4.2/4.3 Regression] ICE in svn boost math toolkit
--- Comment #12 from bangerth at dealii dot org 2008-02-12 08:17 ---
The following variant of the testcase in comment #8 is definitely
valid but produces an ICE:
-
template class T = int struct policy {
typedef int unnecessary;
};
template class Policy struct A {
typedef int type;
typedef typename Policy::unnecessary unused;
};
template class T struct S {
typedef int type;
typedef typename AT::type unused;
};
template class, class T typename ST::type foo();
template class Spolicy ::type foo();
template typename T int def(T);
const int i = def(fooint);
---
tmp/g /home/bangerth/bin/x86/bin/c++ -c x.cc
x.cc: In instantiation of 'AT':
x.cc:12: instantiated from 'ST'
x.cc:19: instantiated from here
x.cc:7: internal compiler error: in dependent_type_p, at cp/pt.c:15553
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This is a regression introduced in gcc3.4.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Known to fail|4.2.3 4.3.0 |4.2.3 4.3.0 3.4.6
Known to work||2.95.3 3.3.6
Last reconfirmed|2008-01-24 15:52:12 |2008-02-12 08:17:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34950
[Bug c++/35117] Vectorization on power PC
--- Comment #30 from eyal at geomage dot com 2008-02-12 08:43 --- Hi, Thanks a lot for the input about a potential memory bottle-neck. I indeed was under the impression that once I got the loop vectorized, I'd immidiatly see a performance boost. I would appriciate, however, a further explaination about this issue. After all, this is a very simple test case. I still dont understand why the hugh diffference when I run: time ./TestNoVec 92200 8 89720 1000 real0m23.549s time ./TestVec 92200 8 89720 1000 real0m22.845s and when I run: [EMAIL PROTECTED]:~ time ./mnovec 40 1 29720 1000 real0m24.493s user0m24.483s sys 0m0.007s [EMAIL PROTECTED]:~ time ./mvec 40 1 29720 1000 real0m10.777s user0m10.771s sys 0m0.005s I cant see from the code how those parameter diff effect the performance so much. I'd appriciate your assistance again. thanks eyal -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35117
[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-02-12 08:45 --- The failure mode is as follows: IVOPTS decices to turn the iteration on the value of A (variable in the code) to an iteration on its address. But there is a cast in the middle a.0_4 = (system__aux_dec__TsaB) a_3(D); D.249_5 = i_131 + a.0_4; so create_iv invokes force_gimple_operand on ADDR_EXPRNOP_EXPRSSA_NAME, which is passed to gnat_gimplify_expr. The latter creates the temporary A.36 and it is never marked for renaming. I think that the problem is in create_iv: it should make sure that the SSA form is preserved, for example by invoking force_gimple_operand_bsi instead of force_gimple_operand like some functions in tree-ssa-loop-ivopts.c. But maybe the problem is the discrepancy between force_gimple_operand and force_gimple_operand_bsi: why does the latter preserve the SSA form and not the former? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-02-12 08:25 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-02-08 22:39:21 |2008-02-12 08:25:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-02-12 09:08
---
But maybe the problem is the discrepancy between force_gimple_operand and
force_gimple_operand_bsi: why does the latter preserve the SSA form and not
the former?
This would fix the problem:
Index: gimplify.c
===
--- gimplify.c (revision 132243)
+++ gimplify.c (working copy)
@@ -6629,6 +6629,14 @@ force_gimple_operand (tree expr, tree *s
pop_gimplify_context (NULL);
+ if (*stmts gimple_in_ssa_p (cfun))
+{
+ tree_stmt_iterator tsi;
+
+ for (tsi = tsi_start (*stmts); !tsi_end_p (tsi); tsi_next (tsi))
+ mark_symbols_for_renaming (tsi_stmt (tsi));
+}
+
return expr;
}
@@ -6648,14 +6656,6 @@ force_gimple_operand_bsi (block_stmt_ite
expr = force_gimple_operand (expr, stmts, simple_p, var);
if (stmts)
{
- if (gimple_in_ssa_p (cfun))
- {
- tree_stmt_iterator tsi;
-
- for (tsi = tsi_start (stmts); !tsi_end_p (tsi); tsi_next (tsi))
- mark_symbols_for_renaming (tsi_stmt (tsi));
- }
-
if (before)
bsi_insert_before (bsi, stmts, m);
else
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
--- Comment #10 from manu at gcc dot gnu dot org 2008-02-12 09:28 --- Old unsupported GCC version, three years since last confirmed, sco... close? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm
--- Comment #7 from jakub at gcc dot gnu dot org 2008-02-12 09:46 ---
I suspect a reload bug, what asmcons is just unnecessary, not wrong.
Reload shouldn't ever reload different asm output registers into the same
hard registers.
That said, following patch serves as a workaround as well as improvement in
asmcons:
--- function.c.jj2 2008-02-11 14:48:12.0 +0100
+++ function.c 2008-02-12 10:16:10.0 +0100
@@ -1,6 +1,6 @@
/* Expands front end tree to back end RTL for GCC.
Copyright (C) 1987, 1988, 1989, 1991, 1992, 1993, 1994, 1995, 1996, 1997,
- 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007
+ 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
Free Software Foundation, Inc.
This file is part of GCC.
@@ -5683,8 +5683,10 @@ match_asm_constraints_1 (rtx insn, rtx *
rtx op = SET_SRC (p_sets[0]);
int ninputs = ASM_OPERANDS_INPUT_LENGTH (op);
rtvec inputs = ASM_OPERANDS_INPUT_VEC (op);
+ bool *output_matched = alloca (noutputs * sizeof (bool));
- for (i = 0; i ninputs; i++)
+ memset (output_matched, 0, noutputs * sizeof (bool));
+ for (i = ninputs - 1; i = 0; i--)
{
rtx input, output, insns;
const char *constraint = ASM_OPERANDS_INPUT_CONSTRAINT (op, i);
@@ -5713,6 +5715,20 @@ match_asm_constraints_1 (rtx insn, rtx *
if (j != ninputs)
continue;
+ /* Avoid changing the same input several times. For
+asm ( : =mr (out1), =mr (out2) : 0 (in), 1 (in));
+only change in once (to out1), rather than changing it
+first to out1 and afterwards to out2. */
+ if (i ninputs - 1)
+ {
+ for (j = 0; j noutputs; j++)
+ if (output_matched[j] input == SET_DEST (p_sets[j]))
+ break;
+ if (j != noutputs)
+ continue;
+ }
+ output_matched[match] = true;
+
start_sequence ();
emit_move_insn (output, input);
insns = get_insns ();
If the same pseudo is used in multiple inputs, where they have different
matching output registers, asmcons replaces first time the original input
pseudo to first matching output, then first matching output to second matching
output, etc., each time adding new SET in front of the ASM_OPERANDS. But the
second and following replacements don't buy us anything.
For testing I've also modified the patched match_asm_constraints_1 to iterate
from ninputs - 1 down to 0 rather than from 0 up to ninputs - 1 to make the
replacements on this testcase more similar to what was produced without the
patch.
*.asmcons difference between vanilla gcc and gcc patched with above patch plus
iterating downwards is:
@@ -45,16 +41,10 @@ Dataflow summary:
(insn:HI 6 3 25 2 M.i:10 (set (reg:DI 65)
(const_int 0 [0x0])) 89 {*movdi_1_rex64} (nil))
-(insn 25 6 26 2 M.i:10 (set (reg/v:DI 60 [ d0 ])
+(insn 25 6 9 2 M.i:10 (set (reg/v:DI 58 [ d2 ])
(reg:DI 65)) -1 (nil))
-(insn 26 25 27 2 M.i:10 (set (reg/v:DI 59 [ d1 ])
-(reg/v:DI 60 [ d0 ])) -1 (nil))
-
-(insn 27 26 9 2 M.i:10 (set (reg/v:DI 58 [ d2 ])
-(reg/v:DI 59 [ d1 ])) -1 (nil))
-
-(insn:HI 9 27 28 2 M.i:10 (parallel [
+(insn:HI 9 25 26 2 M.i:10 (parallel [
(set (reg/v:DI 60 [ d0 ])
(asm_operands:DI (movl $7, %k0; movl $8, %k1; movl $9, %k2)
(=r) 0 [
(reg/v:DI 58 [ d2 ])
@@ -94,16 +84,10 @@ Dataflow summary:
(expr_list:REG_UNUSED (reg:QI 17 flags)
(nil
-(insn 28 9 29 2 M.i:12 (set (reg/v:DI 63 [ c0 ])
+(insn 26 9 13 2 M.i:12 (set (reg/v:DI 61 [ c2 ])
(reg:DI 65)) -1 (nil))
-(insn 29 28 30 2 M.i:12 (set (reg/v:DI 62 [ c1 ])
-(reg/v:DI 63 [ c0 ])) -1 (nil))
-
-(insn 30 29 13 2 M.i:12 (set (reg/v:DI 61 [ c2 ])
-(reg/v:DI 62 [ c1 ])) -1 (nil))
-
-(insn:HI 13 30 14 2 M.i:12 (parallel [
+(insn:HI 13 26 14 2 M.i:12 (parallel [
(set (reg/v:DI 63 [ c0 ])
(asm_operands:DI (movq %3, %0; movq %4, %1; movq %5, %2)
(=r) 0 [
(reg/v:DI 61 [ c2 ])
i.e. just the extra 2 moves in front of each of the asms. With vanilla gcc
reload uses the same register for d0/d1, but without the extra 4 moves it works
properly.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||uweigand at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
[Bug middle-end/29673] no -fdump-tree-inlined output
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-12 10:09 --- Confirmed. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-12 10:09:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29673
[Bug c++/35117] Vectorization on power PC
--- Comment #31 from victork at gcc dot gnu dot org 2008-02-12 10:51 --- I would appriciate, however, a further explaination about this issue. The explanation has to deal with CPU architecture and is not related to compilers. In case of cache miss the memory load and store take tens of cpu cycles instead of few cycles in case of cache hit. When we run: time ./mvec 40 1 29720 1000 The program perform 40 iterations of outer loop and 29720 iterations in internal loop. The internal loop performs 3 load accesses and one store access per iteration. Starting from second iteration of outer loop, all 29720 elements of arrays pSum, pSum1 and pVec1 will be placed into cache and from this point all accesses will be cache hits. (I assume that data cache is big enough to contain all 29720*3 elements). Lets look at the slow run: % time ./TestVec 92200 8 89720 1000 Here the program perform (89720-8) iterations in internal loop, so in order to have cache hits most of the time we need the cache to be at least 89712*3 in size. Lets consider what will happen if cache size is only half of required amount. After completion of first iteration of the outer loop, the cache will be filled with second half of data from arrays. At start of second iteration of outer loop, all elements from first half will be evicted from the cache as most caches use LRU policy to choose evicted elements. Considering that PPC970 is out-of-order, multiple-issue architecture we can guess why CPU have enough time to perform arithmetic operations even in scalar manner without adding any overhead relatively to vectorized version of internal loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35117
[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8
--- Comment #13 from dominiq at lps dot ens dot fr 2008-02-12 10:54 --- The problem of conversion shows up even without -fdefault-integer-8 along with bound problems as shown by the following code: integer, parameter :: ik=4 type :: struct integer(4), allocatable :: ib(:) end type struct integer, parameter :: from=-1, to=2 integer(ik), allocatable :: ia(:) type(struct) :: x allocate(ia(from:to)) print *, 'bounds, full array ', lbound(ia), ubound(ia) print *, 'bounds, full implicit section', lbound(ia(:)), ubound(ia(:)) print *, 'bounds, full explicit section', lbound(ia(from:to)), ubound(ia(from:to)) print *, 'derived type, ik=', ik x=struct(ia) print *, 'bounds, full array ', lbound(x%ib), ubound(x%ib) x=struct(ia(:)) print *, 'bounds, full implicit section', lbound(x%ib), ubound(x%ib) x=struct(ia(from:to)) print *, 'bounds, full explicit section', lbound(x%ib), ubound(x%ib) deallocate(ia) end with ik = 4, the ouput is: bounds, full array -1 2 bounds, full implicit section 1 4 bounds, full explicit section 1 4 derived type, ik= 4 bounds, full array -1 2 bounds, full implicit section -1 2-- should not it be 1 4 as above? bounds, full explicit section 1 4 with ik = 8: ... derived type, ik= 8 bounds, full array 1 4--- should not it be -1 2 as for ik = 4? bounds, full implicit section 1 4 bounds, full explicit section 1 4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers with unified trees
--- Comment #21 from Rudolf dot Leitgeb at gmx dot at 2008-02-12 18:27 --- This bug has come to surface again ... again I have to use --disable-libssp when compiling gcc for the avr target, this time with gcc 4.2.3. Is ssp essential for avr that it keeps creeping in ? BTW: I use a separately compiled binutils package, so no unified tree here ... -- Rudolf dot Leitgeb at gmx dot at changed: What|Removed |Added CC||Rudolf dot Leitgeb at gmx ||dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-02-12 20:50 --- Subject: Bug 35136 Author: ebotcazou Date: Tue Feb 12 20:49:21 2008 New Revision: 132267 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132267 Log: PR middle-end/35136 * gimplify.c (force_gimple_operand_bsi): Move SSA renaming code from here to... (force_gimple_operand): ...here. Added: trunk/gcc/testsuite/gnat.dg/loop_address.adb Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
[Bug other/33549] makeinfo drops hyphens from srcdir path
--- Comment #3 from skunk at iskunk dot org 2008-02-12 20:46 --- (In reply to comment #2) I think it's a bug in makeinfo that it does this, and should be fixed there. That was my first thought as well, but consider that the conversion from -- to - (and --- to --) makes sense from a typographic standpoint. A -- is used to indicate an en-dash, which in Info is rendered as a plain hyphen, whereas a --- is an em-dash, rendered as --. Changing the Makeinfo behavior would affect the appearance of the final text. Consider other cases, too: what if the srcdir path contains a @? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33549
[Bug target/35090] [4.3 regression] libjava testsuite failures on hppa-linux
--- Comment #3 from debian-gcc at lists dot debian dot org 2008-02-12 21:31 --- Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080202-1' --with-bugurl=file:///usr/share/doc/gcj-4.3/README.Bugs --enable-languages=c,c++,java --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-java-awt=gtk --enable-gtk-cairo --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.3-1.5.0.0/jre --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libmudflap --disable-libssp --enable-checking=release --build=hppa-linux-gnu --host=hppa-linux-gnu --target=hppa-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35090
[Bug tree-optimization/35171] [4.3 Regression] ICE in vect_recog_dot_prod_pattern
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-12 21:30 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35171
[Bug tree-optimization/35171] [4.3 Regression] ICE in vect_recog_dot_prod_pattern
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-12 21:30 --- Subject: Bug 35171 Author: rguenth Date: Tue Feb 12 21:29:39 2008 New Revision: 132270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132270 Log: 2008-02-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/35171 * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Deal with default defs. * gcc.c-torture/compile/pr35171.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr35171.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35171
[Bug middle-end/35163] [4.1/4.2 Regression] folding comparison loses cast
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-12 21:30 --- Fixed on the trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|2.95.4 |2.95.4 4.3.0 Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] folding |folding comparison loses|comparison loses cast |cast| Target Milestone|4.3.0 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163
[Bug middle-end/35163] [4.1/4.2/4.3 Regression] folding comparison loses cast
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-12 21:27 --- Subject: Bug 35163 Author: rguenth Date: Tue Feb 12 21:26:49 2008 New Revision: 132269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132269 Log: 2008-02-12 Richard Guenther [EMAIL PROTECTED] PR middle-end/35163 * fold-const.c (fold_widened_comparison): Use get_unwidened in value-preserving mode. Disallow final truncation. * gcc.c-torture/execute/pr35163.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr35163.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #13 from geoffk at geoffk dot org 2008-02-12 22:43 --- Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785 On 12/02/2008, at 7:46 AM, hjl dot tools at gmail dot com wrote: --- Comment #10 from hjl dot tools at gmail dot com 2008-02-12 15:46 --- (In reply to comment #3) Reproducible even with x86_64-linux - i686-darwin9 cross, at -Os as well as -O2 -mno-accumulate-outgoing-args. The difference between i686- linux and i686-darwin9 that matters here is that darwin defines STACK_BOUNDARY to 128, while linux to 4. I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is hardware related, not ABI related. They should set PREFERRED_STACK_BOUNDARY instead, which is set to 128 already. On stack alignment branch, we introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs. If you do not align the stack at a 128-bit boundary, your program will crash. The hardware that it is related to is SSE2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug other/33549] makeinfo drops hyphens from srcdir path
--- Comment #4 from joseph at codesourcery dot com 2008-02-12 22:56 ---
Subject: Re: makeinfo drops hyphens from srcdir path
On Tue, 12 Feb 2008, skunk at iskunk dot org wrote:
That was my first thought as well, but consider that the conversion from --
to - (and --- to --) makes sense from a typographic standpoint. A --
is
used to indicate an en-dash, which in Info is rendered as a plain hyphen,
whereas a --- is an em-dash, rendered as --. Changing the Makeinfo
behavior
would affect the appearance of the final text.
The Texinfo manual specifies that the @include path is taken literally
apart from expanding @value references. The typographical conversions
need to be done at some later stage of makeinfo processing, not when the
@set or @value or @include are processed.
Consider other cases, too: what if the srcdir path contains a @?
In Texinfo language terms, the documentation implies that any @, other
than in @value{var} constructs, is taken literally in @include.
In GCC or Autoconf terms, I don't think srcdir containing @ is supported.
Directory names need to consist entirely of safe characters; -- should
be a safe sequence, @ probably isn't (because of Autoconf use if nothing
else), characters such as :%$ that are significant to the shell or make
definitely aren't safe. (Some patches have gone into the latest git
Autoconf to improve safety with funny characters, but even when GCC moves
to a newer Autoconf I don't think there's much use supporting them in
building GCC.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33549
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #10 from lennox at cs dot columbia dot edu 2008-02-12 22:46 --- The right answer is probably to declare the system header functions inline when __GNUC_STDC_INLINE__, otherwise extern inline; or equivalently to declare them extern inline __attribute__((__gnu_inline__)). You then need to provide an out-of-line definition in the appropriate system library, e.g. libgcc for the mmintrin functions. Note that even if you declare the function with __attribute__((__always_inline__)), there are uses that require a non-inlined version of the function, e.g. pointer-to-function. This is the main reason why it's not practical for fixincludes to do this transformation on system headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-12 22:45 ---
Reduced testcase without include:
typedef unsigned int size_t;
templatetypename _Iterator, typename _Container class __normal_iterator {
public:
const _Iterator base() const;
};
templatetypename _BI1, typename _BI2 inline
void copy_backward(_BI1 __first, _BI1 __last, _BI2 __result) {
while (__first != __last) *--__result = *--__last;
}
templatetypename _Tp struct _Vector_base {
struct _Vector_impl { _Tp* _M_finish; };
_Vector_impl _M_impl;
};
templatetypename _Tp class vector : protected _Vector_base_Tp {
typedef vector_Tp vector_type;
typedef _Tp * pointer;
typedef _Tp reference;
typedef __normal_iteratorpointer, vector_type iterator;
typedef size_t size_type;
public:
iterator end();
void resize(size_type __new_size) { insert(end(), __new_size); }
reference operator[](size_type __n);
void insert(iterator __position, size_type __n)
{
pointer __old_finish(this-_M_impl._M_finish);
copy_backward(__position.base(), __old_finish - __n, __old_finish);
}
};
struct A {
virtual ~A ();
void incRef ();
void decRef ();
};
struct C : public A {
static C *alloc ();
};
template class T struct B {
B () : ptr (T::alloc ()) { }
B (T *a_ptr) : ptr (a_ptr) { }
~B () { decRef (); }
B operator= (const BT a) { if (a.get () != this-get ()) { decRef ();
incRef (); } }
templateclass U operator BU () const { return BU (ptr); }
T* operator- () const { }
T* get () const { return ptr; }
void decRef () const { if (ptr != 0) ptr-decRef (); }
void incRef () const { if (ptr != 0) ptr-incRef (); }
T *ptr;
};
struct D : public C {
template class T inline void foo (const BT x) { d.resize (1); d[0] = x;
}
vectorB C d;
};
struct E : public C {
static E *alloc ();
};
struct F : public D {
static F *alloc ();
};
void foo (vectorBD x) {
for (int i = 0; i 2; ++i)
{
BF l;
BE m;
l-foo (m);
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-02-12 22:45:45
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #14 from hjl dot tools at gmail dot com 2008-02-12 23:45 --- (In reply to comment #13) I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is hardware related, not ABI related. They should set PREFERRED_STACK_BOUNDARY instead, which is set to 128 already. On stack alignment branch, we introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs. If you do not align the stack at a 128-bit boundary, your program will crash. The hardware that it is related to is SSE2. Stack alignment is controlled by PREFERRED_STACK_BOUNDARY. When it is set to 128, gcc will generate codes aligned at 128bit. STACK_BOUNDARY is more or less natural hardware stack boundary, which should be the size of pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug c/35175] ICE: instantiate_virtual_regs_in_insn, at function.c:1564
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-13 00:28 --- (In reply to comment #0) This could be a dupe. Please add me on and close this one if it is. When a bug is marked as a dup, it will add you automatically to the CC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35175
[Bug c/35175] New: ICE: instantiate_virtual_regs_in_insn, at function.c:1564
This could be a dupe. Please add me on and close this one if it is. powerpc-rtems4.9-gcc (GCC) 4.3.0 20080209 (experimental) [trunk revision 132202] XFAIL: gcc.dg/vect/vect-63.c scan-tree-dump-times vect vectorized 1 loops 1 Executing on host: /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/ /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c -ftree-vectorize -fno-vect-cost-model -maltivec -mcpu=970 -O2 -fdump-tree-vect-details -DSTACK_SIZE=2048 -fno-show-column -S -B/home/joel/work-gnat/svn/bsp-install/powerpc-rtems4.9/psim/lib/ -specs bsp_specs -qrtems -mcpu=603e -o vect-64.s(timeout = 300) /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c: In function 'main1': /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:76: error: unrecognizable insn: (insn 105 312 106 5 /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:23 (parallel [ (set (reg:V4SI 215 [ vect_cst_.59 ]) (reg:V4SI 293)) (unspec [ (const_int 0 [0x0]) ] 196) ]) -1 (nil)) /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-64.c:76: internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1564 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 -- Summary: ICE: instantiate_virtual_regs_in_insn, at function.c:1564 Product: gcc Version: 4.3.0 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: powerpc-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35175
[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-02-13 00:27 --- *** Bug 35175 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
[Bug c/35174] New: ICE: segmentation fault bf64-1.c
Executing on host: /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/ /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/bf64-1.c gcc_tg.o -w -O1 -DSTACK_SIZE=2048 -fno-show-column -B/home/joel/work-gnat/svn/bsp-install/powerpc-rtems4.9/psim/lib/ -specs bsp_specs -qrtems -mcpu=603e /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/rtems_gcc_main.o -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/testsuite/gcc/bf64-1.x1(timeout = 300) /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/bf64-1.c: In function 'main': /home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/bf64-1.c:40: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE: segmentation fault bf64-1.c Product: gcc Version: 4.3.0 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: powerpc-rtems4.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35174
[Bug target/34393] ICE: in extract_insn, at recog.c:1990
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-13 00:20 --- Also fails on powerpc-rtems powerpc-rtems4.9-gcc (GCC) 4.3.0 20080209 (experimental) [trunk revision 132202] -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34393
[Bug libstdc++/35176] SIGXFSZ in filebuf
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-13 03:15 --- getrlimit and setrlimit are outside of standard C/C++, they are part of POSIX. So it might be best to ask the POSIX guys. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #12 from lennox at cs dot columbia dot edu 2008-02-13 04:35 --- Created an attachment (id=15134) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15134action=view) test program using pointers to functions from emmintrin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug c++/34824] [4.1/4.2/4.3 Regression] ICE with explicit copy constructor
--- Comment #9 from jason at gcc dot gnu dot org 2008-02-13 04:06 --- Subject: Bug 34824 Author: jason Date: Wed Feb 13 04:06:03 2008 New Revision: 132282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132282 Log: PR c++/34824 * call.c (convert_like_real): Pass LOOKUP_ONLYCONVERTING to build_temp if we're doing conversions to call a user-defined conversion function. Added: trunk/gcc/testsuite/g++.dg/overload/copy1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34824
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #13 from lennox at cs dot columbia dot edu 2008-02-13 04:38 --- Linking when the functions can't be inlined would be the only gotcha, but that would mean that the new attachment (func-pointer-sse.c) would regress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-02-12 22:45:45 |2008-02-13 04:06:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug c++/34824] [4.1/4.2 Regression] ICE with explicit copy constructor
--- Comment #10 from jason at gcc dot gnu dot org 2008-02-13 05:00 --- Fixed for 4.3.0. Bugs on invalid code don't seem worth backporting. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|3.3.6 4.1.3 4.3.0 |3.3.6 4.1.3 Known to work|2.95.4 |2.95.4 4.3.0 Resolution||FIXED Summary|[4.1/4.2/4.3 Regression] ICE|[4.1/4.2 Regression] ICE |with explicit copy |with explicit copy |constructor |constructor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34824
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2008-02-13 04:05 --- Subject: Re: [4.3 regression] Unable to coalesce ab SSA_NAMEs Actually it is the call to rewrite_into_loop_closed_ssa inserting these PHIs. I don't know if it actually makes sense to speak of loop-closed SSA form if we deal with abnormal SSA names - Zdenek? Some pieces of the scev analysis assume lcSSA for all gimple_reg SSA names, regardless of whether they appear in abnormal phi nodes or not. The phi nodes created by lcSSA conversion should always be eliminable, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug c++/34824] [4.1/4.2/4.3 Regression] ICE with explicit copy constructor
-- 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|NEW |ASSIGNED Last reconfirmed|2008-01-17 12:26:53 |2008-02-13 03:56:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34824
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #11 from mrs at apple dot com 2008-02-13 02:59 ---
Ok, how about:
#ifdef __GNUC_STDC_INLINE__
#define __EXTERN_INLINE __inline __attribute__((always_inline))
#else
#define __EXTERN_INLINE extern __inline __attribute__((always_inline))
#endif
__EXTERN_INLINE void foo() ;
__EXTERN_INLINE void foo() {
__asm (nop);
}
void bar1() {
foo();
}
I think that will work... See any gotchas (other than linking when it can't be
inlined)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug libstdc++/35176] New: SIGXFSZ in filebuf
When compiled with gcc 4.1.2 the program below dies with SIGXFSZ on Linux.
I don't think the standard allows filebuf to report errors using signals
(since it describes file I/O in terms of C stdio), nor does a signal seem
desirable in C++.
$ cat u.cpp g++ u.cpp ./a.out || echo $?
#include fstream
#include sys/resource.h
int main ()
{
rlimit rl;
getrlimit (RLIMIT_FSIZE, rl);
rl.rlim_cur = 32;
setrlimit (RLIMIT_FSIZE, rl);
std::filebuf fb;
if (0 == fb.open (testfile.text, std::ios::out))
return -1;
for (rlim_t i = 0; i != rl.rlim_cur + 1; ++i)
fb.sputc ('*');
}
File size limit exceeded
153
--
Summary: SIGXFSZ in filebuf
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers with unified trees
-- eric dot weddington at atmel dot com changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug c++/34950] [4.2/4.3 Regression] ICE in svn boost math toolkit
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-02-12 23:13 --- Ok, so based on comment #12 this is ice-on-valid-code, and that testcase works for me with 4.0 and 4.1 which produce: g++-4.1 -S t.ii t.ii: In instantiation of AT: t.ii:12: instantiated from ST t.ii:19: instantiated from here t.ii:7: error: no type named unnecessary in T with 3.4 it ICEs with g++-3.4 -S t.ii t.ii: In instantiation of `AT': t.ii:12: instantiated from `ST' t.ii:19: instantiated from here t.ii:7: internal compiler error: in lookup_member, at cp/search.c:1300 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.4/README.Bugs. while 3.3 and 2.95 accept it. No idea if we have a PR for 4.1 and the rejects-valid. Janis, can you hunt at where we started to go from the error with 4.1 to the ICE we now see? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Status|WAITING |NEW Keywords||ice-on-valid-code Known to fail|4.2.3 4.3.0 3.4.6 |4.2.3 4.3.0 Last reconfirmed|2008-02-12 08:17:03 |2008-02-12 23:13:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34950
[Bug libstdc++/35173] trivial long - int implicit conversions
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-12 22:38 --- Please, try with the new -Wconversion (http://gcc.gnu.org/wiki/NewWconversion), it shouldn't warn for values that fit (without changing sign) into the target type. Nevertheless, perhaps it may be interesting to make Wconversion warn about some particular conversions in a special way. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35173
[Bug fortran/35009] error on valid with -std=f95 (character arrays in format tags)
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-02-13 05:41 --- I have tried FX fix and it does the trick. I am regression testing. FX if you can't get to it for 4.4, let me know and i will commit for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
[Bug objc++/34193] [4.3 regression] FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors)
--- Comment #7 from ghazi at gcc dot gnu dot org 2008-02-12 21:44 --- Subject: Bug 34193 Author: ghazi Date: Tue Feb 12 21:44:15 2008 New Revision: 132273 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132273 Log: PR objc++/34193 * obj-c++.dg/gnu-runtime-2.mm: Fix signature of function main(). Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/obj-c++.dg/gnu-runtime-2.mm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34193
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #8 from lennox at cs dot columbia dot edu 2008-02-12 21:37 --- The attachment (inline-test-sse.c) on this PR is the gnu89 version of the problem. On MacOS X 10.5.2 (Apple gcc 5465), which has the same code as mainline FSF GCC, it prints: inline-test-sse.c: In function 'vect_add': inline-test-sse.c:5: warning: '_mm_add_epi8' is static but used in inline function 'vect_add' which is not static -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #9 from mrs at apple dot com 2008-02-12 22:04 --- Ah, I see now, you're right, that doesn't work. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-12 22:03 --- Actually it is the call to rewrite_into_loop_closed_ssa inserting these PHIs. I don't know if it actually makes sense to speak of loop-closed SSA form if we deal with abnormal SSA names - Zdenek? -- 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=35164
[Bug objc++/34193] [4.3 regression] FAIL: obj-c++.dg/gnu-runtime-2.mm (test for excess errors)
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-02-12 21:32 --- Subject: Bug 34193 Author: ghazi Date: Tue Feb 12 21:31:21 2008 New Revision: 132271 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132271 Log: PR objc++/34193 * obj-c++.dg/gnu-runtime-2.mm: Fix signature of function main(). Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/obj-c++.dg/gnu-runtime-2.mm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34193
[Bug rtl-optimization/15482] can't find a register in class `GENERAL_REGS' while reloading `asm'
--- Comment #5 from ubizjak at gmail dot com 2008-02-12 21:11 --- (In reply to comment #4) I see the same problem at any level of optimization I have tried on i686-apple-darwin9 for the test case gcc.target/i386/asm-3.c: [ibook-dhum] f90/bug% /opt/gcc/gcc4.3w/bin/gcc -O0 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/asm-3.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/asm-3.c: In function 'main': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/asm-3.c:19: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/asm-3.c:19: error: 'asm' operand has impossible constraints The failure was present for rev. 130218 (see http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00861.html). This test can't run on 32bit x86 PIC targets due to register starvation. dg-skip-if directive was fixed to include all PIC targets with !nonpic target selector. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15482
[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-02-13 05:48 --- Thomas, I am going to work on this a bit. Let me know if you have already done so. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-26 16:23:08 |2008-02-13 05:48:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34974
[Bug target/34141] gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9
--- Comment #7 from dominiq at lps dot ens dot fr 2008-02-12 20:18 --- Fixed in OSX 10.5.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
[Bug other/35148] make pdf has missing file in 4.3-20080208
--- Comment #9 from joseph at codesourcery dot com 2008-02-12 20:15 --- Subject: Re: make pdf has missing file in 4.3-20080208 On Sun, 10 Feb 2008, Ralf dot Wildenhues at gmx dot de wrote: Thanks. Please note that I don't have write access yet (so if you want to make sure it gets in please consider applying it). Write access requests should be processed quickly, may be worth pinging. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35148
[Bug other/33549] makeinfo drops hyphens from srcdir path
--- Comment #2 from joseph at codesourcery dot com 2008-02-12 20:11 --- Subject: Re: makeinfo drops hyphens from srcdir path I think it's a bug in makeinfo that it does this, and should be fixed there. In any case, patches to this code need testing with dvi or pdf output (which needs the latest 4.2 branch or trunk sources to have a recent enough texinfo.tex, and may need configuring with an absolute path at present). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33549
[Bug fortran/35161] Bind(C): Procedures with different interface and same C binding label
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-02-12 20:05 --- *** Bug 35172 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||francois dot jacq at irsn ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35161
[Bug libstdc++/35173] trivial long - int implicit conversions
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-12 19:59 --- I think -Wshorten-64-to-32 is bogus here. The values don't lose any information, please fix your warning. Also you might want to try -Wconversion in 4.3.0 and try again. -- 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=35173
[Bug middle-end/35163] [4.1/4.2/4.3 Regression] folding comparison loses cast
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-12 19:59 --- get_unwidened behaves as documented: If FOR_TYPE is nonzero, we return a value which, if converted to type FOR_TYPE, would be equivalent to converting OP to type FOR_TYPE. thus indeed, (signed char)(int)(unsigned short)-41sc == -41sc. But the bug instead is that fold specifies FOR_TYPE, where it rather should not specify it and convert the result to shorter_type if and only if this conversion is not a truncation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163
[Bug other/33549] makeinfo drops hyphens from srcdir path
--- Comment #1 from skunk at iskunk dot org 2008-02-12 19:57 ---
Created an attachment (id=15133)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15133action=view)
Patch against 4.2.3
Proposed fix. Set the srcdir variable using @verb{}, to prevent interpretation
of special character sequences (i.e. --) in the path.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33549
[Bug libstdc++/35173] New: trivial long - int implicit conversions
We have a warning -Wshorten-64-to-32 to catch porting to 64-bit machines which warning when a 64 bit value is converted implicitly to a 32 bit value. It causes: /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:379: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:380: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:430: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:431: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:481: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:482: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:532: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:533: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:583: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:584: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:634: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:635: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:685: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:686: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:736: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:737: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:787: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:788: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:838: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:839: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:889: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:890: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:940: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:941: warning: implicit conversion shortens 64-bit value into a 32-bit value In file included from /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/locale:44, from t5.cc:3: /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/bits/locale_classes.h:105: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/bits/locale_classes.h:106: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/bits/locale_classes.h:107: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/bits/locale_classes.h:108: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/bits/locale_classes.h:109: warning: implicit conversion shortens 64-bit value into a 32-bit value /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/bits/locale_classes.h:110: warning: implicit conversion shortens 64-bit value into a 32-bit value In file included from /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/bits/locale_facets.h:49, from /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/locale:45, from t5.cc:3: /tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/bits/ios_base.h:57: warning: implicit conversion shortens 64-bit value into a 32-bit value
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #15 from geoffk at geoffk dot org 2008-02-13 05:54 --- Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785 STACK_BOUNDARY is more or less natural hardware stack boundary, which should be the size of pointer. That is not what is documented and if you are proposing a change, I do not see how your proposal is useful. The distinguishing property of STACK_BOUNDARY is that the compiler is allowed to rely on the stack being aligned by it. There is no notion of hardware or pointer or natural involved; either the stack is always aligned on call boundaries or it is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug fortran/35172] wrong error reporting
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-12 19:41 --- I don't know but I think the error is correct thing to do here. Someone will have to look into the Fortran 2003 standard to make sure this is the correct thing to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35172
[Bug c++/29048] [4.0/4.1/4.2/4.3 Regression] `x' is private error duplicated when scope specified
--- Comment #6 from jason at gcc dot gnu dot org 2008-02-12 19:26 --- Subject: Bug 29048 Author: jason Date: Tue Feb 12 19:25:28 2008 New Revision: 132265 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132265 Log: PR c++/29048 * semantics.c (finish_qualified_id_expr): Avoid duplicate access check here, too. Added: trunk/gcc/testsuite/g++.dg/lookup/duperr1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29048
[Bug c++/29048] [4.0/4.1/4.2/4.3 Regression] `x' is private error duplicated when scope specified
--- Comment #7 from jason at gcc dot gnu dot org 2008-02-12 19:28 --- Fixed for 4.3.0, not worth fixing on earlier release branches. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29048
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers with unified trees
--- Comment #22 from eric dot weddington at atmel dot com 2008-02-12 19:38 --- Created an attachment (id=15132) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15132action=view) Patch to disable libssp for AVR target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug middle-end/35163] [4.1/4.2/4.3 Regression] folding comparison loses cast
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to fail||3.3.6 Known to work||2.95.4 Summary|folding comparison loses|[4.1/4.2/4.3 Regression] |cast|folding comparison loses ||cast Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163
[Bug fortran/35172] New: wrong error reporting
Problem mentioned by A. Markus with a valid interface corresponding to several different FORTRAN signatures for a single C routine. Unfortunately, gfortran reports an error. I think that this behavior is too strong : a warning would be enough to point out a possible programming mistake. Here this is not a mistake : the C signature really corresponds to these different Fortran signatures ! void xxx(float *y); module test interface xxx subroutine xxx_1( y ) bind( c, name = xxx ) use iso_c_binding real(c_float), intent(inout) :: y end subroutine subroutine xxx_2( y ) bind( c, name = xxx ) use iso_c_binding real(c_float), intent(inout), dimension(*) :: y end subroutine end interface end module -- Summary: wrong error reporting Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: francois dot jacq at irsn dot fr GCC build triplet: 4.3.0 20080102 GCC host triplet: i386-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35172
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #12 from hjl dot tools at gmail dot com 2008-02-12 18:52 --- (In reply to comment #11) (In reply to comment #10) I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is hardware related, not ABI related. They should set PREFERRED_STACK_BOUNDARY instead, which is set to 128 already. On stack alignment branch, we introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs. Also, STACK_BOUNDARY is somehow connected to PARM_BOUNDARY: -- Macro: STACK_BOUNDARY Define this macro to the minimum alignment enforced by hardware for the stack pointer on this machine. The definition is a C expression for the desired alignment (measured in bits). This value is used as a default if `PREFERRED_STACK_BOUNDARY' is not defined. On most machines, this should be the same as `PARM_BOUNDARY'. If PARM_BOUNDARY is set to 128, va-arg-25.c tests OK for all optimizations with -m32 -msse2 additional flags. That is not a surprise. But changing PARM_BOUNDARY may change ABI on Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #11 from ubizjak at gmail dot com 2008-02-12 18:46 --- (In reply to comment #10) I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is hardware related, not ABI related. They should set PREFERRED_STACK_BOUNDARY instead, which is set to 128 already. On stack alignment branch, we introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs. Also, STACK_BOUNDARY is somehow connected to PARM_BOUNDARY: -- Macro: STACK_BOUNDARY Define this macro to the minimum alignment enforced by hardware for the stack pointer on this machine. The definition is a C expression for the desired alignment (measured in bits). This value is used as a default if `PREFERRED_STACK_BOUNDARY' is not defined. On most machines, this should be the same as `PARM_BOUNDARY'. If PARM_BOUNDARY is set to 128, va-arg-25.c tests OK for all optimizations with -m32 -msse2 additional flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug c++/35144] [4.3 regression] ICE in generate_element_copy
--- Comment #6 from jakub at gcc dot gnu dot org 2008-02-12 18:38 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35144
[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm
--- Comment #9 from jakub at gcc dot gnu dot org 2008-02-12 18:38 --- Workaround applied, though there is still some, pressumably local-alloc.c, bug lurking around. Downgrading to P2, as this is no longer critical. To reproduce revert the r132263 commit. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
[Bug c++/35144] [4.3 regression] ICE in generate_element_copy
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-12 18:35 --- Subject: Bug 35144 Author: jakub Date: Tue Feb 12 18:35:05 2008 New Revision: 132264 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132264 Log: PR c++/35144 * tree-sra.c (sra_build_assignment): fold_convert SRC if copying non-compatible pointers. (generate_element_copy): If SRC and DST are RECORD_TYPEs with different FIELD_DECLs, try harder by comparing field offsets, sizes and types. * g++.dg/tree-ssa/pr35144.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr35144.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35144
[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm
--- Comment #8 from jakub at gcc dot gnu dot org 2008-02-12 18:32 --- Subject: Bug 35160 Author: jakub Date: Tue Feb 12 18:31:53 2008 New Revision: 132263 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132263 Log: PR inline-asm/35160 * function.c (match_asm_constraints_1): Don't replace the same input multiple times. * gcc.target/i386/pr35160.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr35160.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #7 from mrs at apple dot com 2008-02-12 18:01 --- Testcase for comment #6? I believe we tested every case and it works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug c/35175] ICE: instantiate_virtual_regs_in_insn, at function.c:1564
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-13 00:27 --- *** This bug has been marked as a duplicate of 34930 *** -- 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=35175
[Bug c++/35138] [4.3 Regression] g++ rejects valid code
--- Comment #7 from jakub at gcc dot gnu dot org 2008-02-12 20:14 --- Posted 3 alternative patches: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00410.html http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00418.html http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00422.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-02-08 16:11:14 |2008-02-12 20:14:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35138
[Bug fortran/35172] wrong error reporting
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-02-12 20:05 --- *** This bug has been marked as a duplicate of 35161 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35172
[Bug target/35135] unable to find a register to spill in class �GENERAL_REGS� with global registers
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-12 17:27 --- That's still twice as many global regs as register starved i386 can realistically handle. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35135
[Bug c++/29048] [4.0/4.1/4.2/4.3 Regression] `x' is private error duplicated when scope specified
--- Comment #5 from jason at gcc dot gnu dot org 2008-02-12 17:27 --- Subject: Bug 29048 Author: jason Date: Tue Feb 12 17:26:34 2008 New Revision: 132261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132261 Log: PR c++/29048 * semantics.c (finish_qualified_id_expr): Avoid duplicate access check here, too. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29048
[Bug target/35135] unable to find a register to spill in class �GENERAL_REGS� with global registers
--- Comment #4 from mueller at gcc dot gnu dot org 2008-02-12 17:18 ---
new testcase:
-O2 -fno-gcse -fomit-frame-pointer
=== Cut ===
__extension__ typedef unsigned long long int uint64_t;
typedef unsigned int target_ulong;
register struct CPUX86State *env asm (ebp);
register target_ulong T0 asm (ebx);
register target_ulong T1 asm (esi);
register target_ulong T2 asm (edi);
typedef union
{
uint64_t _q[2];
}
XMMReg;
typedef struct CPUX86State
{
XMMReg xmm_regs[8];
}
CPUX86State;
save_raw_fp_state (CPUX86State * env, char * ptr)
{
int i, fpus, fptag, nb_xmm_regs;
char *addr;
nb_xmm_regs = 8 0;
addr = ptr + 0xa0;
for (i = 0; i nb_xmm_regs; i++)
{
env-xmm_regs[i]._q[0] = *(uint64_t *) (addr);
addr += 16;
}
}
=== Cut ===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35135
[Bug middle-end/35163] folding comparison loses cast
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-12 17:07 --- I'll have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-02-11 10:44:42 |2008-02-12 17:07:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35163
[Bug tree-optimization/35171] [4.3 Regression] ICE in vect_recog_dot_prod_pattern
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-12 17:06 --- I'll have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-02-12 17:05:58 |2008-02-12 17:06:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35171
[Bug tree-optimization/35171] [4.3 Regression] ICE in vect_recog_dot_prod_pattern
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-12 17:05 --- Confirmed. 250 stmt_vinfo = vinfo_for_stmt (stmt); 251 gcc_assert (stmt_vinfo); (gdb) call debug_generic_expr (stmt) (void) 0 we run into a default def here. 4.2 works because we don't enable the vectorizer there. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet||x86_64-*-*, i?86-*-* Keywords||ice-on-valid-code Known to work||4.2.3 Last reconfirmed|-00-00 00:00:00 |2008-02-12 17:05:58 date|| Summary|ICE in |[4.3 Regression] ICE in |vect_recog_dot_prod_pattern |vect_recog_dot_prod_pattern Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35171
[Bug fortran/35009] error on valid with -std=f95 (character arrays in format tags)
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-02-13 06:09 --- The patch causes several regressions. hollerith.f90 for example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
[Bug target/34393] ICE: in extract_insn, at recog.c:1990
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||02/msg00437.html Status|NEW |ASSIGNED Last reconfirmed|2007-12-19 02:14:56 |2008-02-13 06:27:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34393
[Bug target/34141] gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-02-13 03:48 --- Can this be closed then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-02-12 20:53 --- Thanks for reporting the problem. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
[Bug target/35135] unable to find a register to spill in class �GENERAL_REGS� with global registers
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-12 18:48 ---
The new testcase works for me with older releases (-O2 is enough), but 2.95.4
fails as well. The difference from 4.2 to 4.3 is that 4.2 uses two induction
variables, while 4.3 uses one. After lreg 4.2 has
(insn 21 19 22 3 (set (reg:DI 68)
(mem:DI (plus:SI (plus:SI (reg:SI 64 [ ivtmp.44 ])
(reg/v/f:SI 67 [ ptr ]))
(const_int 160 [0xa0])) [0 S8 A64])) 80 {*movdi_2} (nil)
(expr_list:REG_EQUIV (mem:DI (plus:SI (plus:SI (reg:SI 64 [ ivtmp.44 ])
(reg/v/f:SI 67 [ ptr ]))
(const_int 160 [0xa0])) [0 S8 A64])
(nil)))
(insn 22 21 23 3 (set (mem/s/j:DI (reg/f:SI 63 [ ivtmp.51 ]) [0 variable._q+0
S8 A8])
(reg:DI 68)) 80 {*movdi_2} (insn_list:REG_DEP_TRUE 21 (nil))
(expr_list:REG_DEAD (reg:DI 68)
(nil)))
(insn 23 22 24 3 (parallel [
(set (reg:SI 64 [ ivtmp.44 ])
(plus:SI (reg:SI 64 [ ivtmp.44 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) 216 {*addsi_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 24 23 26 3 (parallel [
(set (reg/f:SI 63 [ ivtmp.51 ])
(plus:SI (reg/f:SI 63 [ ivtmp.51 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) 216 {*addsi_1} (nil)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
...
while 4.3 ends up with
(insn 14 13 15 3 t.c:25 (set (reg:DI 67)
(mem:DI (plus:SI (plus:SI (reg/v/f:SI 66 [ ptr ])
(reg:SI 63 [ ivtmp.15 ]))
(const_int 160 [0xa0])) [0 S8 A64])) 88 {*movdi_2}
(expr_list:REG_EQUIV (mem:DI (plus:SI (plus:SI (reg/v/f:SI 66 [ ptr ])
(reg:SI 63 [ ivtmp.15 ]))
(const_int 160 [0xa0])) [0 S8 A64])
(nil)))
(insn 15 14 16 3 t.c:25 (set (mem/s/j:DI (plus:SI (reg/v/f:SI 65 [ env ])
(reg:SI 63 [ ivtmp.15 ])) [0 variable._q+0 S8 A8])
(reg:DI 67)) 88 {*movdi_2} (expr_list:REG_DEAD (reg:DI 67)
(nil)))
(insn 16 15 18 3 t.c:25 (parallel [
(set (reg:SI 63 [ ivtmp.15 ])
(plus:SI (reg:SI 63 [ ivtmp.15 ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) 249 {*addsi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
Or before expand for 4.2:
bb 2:
ivtmp.51 = (unsigned int) env-xmm_regs[0]._q[0];
ivtmp.44 = 0;
L0:;
MEM[index: ivtmp.51] = MEM[base: ptr, index: ivtmp.44, offset: 160];
ivtmp.44 = ivtmp.44 + 16;
ivtmp.51 = ivtmp.51 + 16;
if (ivtmp.44 != 128) goto L0; else goto L2;
L2:;
return;
while 4.3 starts with:
bb 2:
ivtmp.15 = 0;
bb 3:
MEM[base: env, index: ivtmp.15] = MEM[base: ptr, index: ivtmp.15, offset:
160];
ivtmp.15 = ivtmp.15 + 16;
if (ivtmp.15 != 128)
goto bb 3;
else
goto bb 4;
bb 4:
return;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35135
[Bug c++/34774] [4.1/4.2/4.3 Regression] templates, enumerations, overflow, ice
-- 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|NEW |ASSIGNED Last reconfirmed|2008-01-14 01:01:39 |2008-02-13 06:08:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34774
[Bug target/35135] unable to find a register to spill in class �GENERAL_REGS� with global registers
--- Comment #3 from mueller at gcc dot gnu dot org 2008-02-12 16:31 --- the original code uses -fomit-frame-pointer -fno-gcse -O2. I can verify that -O3 fixes the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35135
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #16 from hjl dot tools at gmail dot com 2008-02-13 06:41 --- (In reply to comment #15) Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785 STACK_BOUNDARY is more or less natural hardware stack boundary, which should be the size of pointer. That is not what is documented and if you are proposing a change, I do not see how your proposal is useful. The distinguishing property of STACK_BOUNDARY is that the compiler is allowed to rely on the stack being aligned by it. There is no notion of hardware or pointer or natural involved; either the stack is always aligned on call boundaries or it is not. Here is our proposal: http://gcc.gnu.org/ml/gcc/2007-12/msg00567.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #13 from jakub at gcc dot gnu dot org 2008-02-12 16:26 --- Subject: Bug 34862 Author: jakub Date: Tue Feb 12 16:25:47 2008 New Revision: 132257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132257 Log: PR c++/34862 * init.c (build_new_1): Don't create placement_expr before constructing alloc_call. Verify that the pointer is passed by value to operator new. * g++.dg/init/new27.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/new27.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-02-13 06:43 --- Something is wrong. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #10 from hjl dot tools at gmail dot com 2008-02-12 15:46 --- (In reply to comment #3) Reproducible even with x86_64-linux - i686-darwin9 cross, at -Os as well as -O2 -mno-accumulate-outgoing-args. The difference between i686-linux and i686-darwin9 that matters here is that darwin defines STACK_BOUNDARY to 128, while linux to 4. I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is hardware related, not ABI related. They should set PREFERRED_STACK_BOUNDARY instead, which is set to 128 already. On stack alignment branch, we introduced a new macro, ABI_STACK_BOUNDARY, to handle different ABIs. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #9 from ubizjak at gmail dot com 2008-02-12 15:11 --- By disabling asserts, we can compare -O2 call frame for va-arg-25.c test vs. what would -Os call frame look like: gcc -O2 -fomit-frame-pointer: main: subl$76, %esp movdqa .LC0, %xmm0 movl$2, 32(%esp) movdqa %xmm0, 48(%esp) movl$1, (%esp) movdqa .LC1, %xmm0 movdqa %xmm0, 16(%esp) callfoo vs. gcc -Os (aka -mno-accumulate-outgoing-args) -fomit-frame-pointer: main: subl$28, %esp movaps .LC0, %xmm0 movaps %xmm0, (%esp) pushl $2 movaps .LC1, %xmm0 subl$16, %esp movaps %xmm0, (%esp) pushl $1 callfoo ... So, at the call, we have -O2 stack: +76 +72 +68 +64 +60 .LC0 +56 .LC0 +52 .LC0 +48 .LC0 +44 pad +40 pad +36 pad +32 $2 +28 .LC1 +24 .LC1 +20 .LC1 +16 .LC1 +12 pad +8pad +4pad esp $1 -- For -Os stack gets misaligned after pushl $2. It looks that gcc should decrease stack for additional 12 bytes before $2 is pushed, so the stack is consistent with -O2. For i686-linux-*, we generate correct sequence for -Os: main: leal4(%esp), %ecx andl$-16, %esp pushl -4(%ecx) pushl %ecx subl$36, %esp movaps .LC0, %xmm0 movaps %xmm0, 12(%esp) pushl $2 movaps .LC1, %xmm0 subl$28, %esp movaps %xmm0, 12(%esp) pushl $1 callfoo ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug debug/35065] [4.3 Regression] infinite loop while compiling VLC media player in vt_find_locations
--- Comment #6 from rguenther at suse dot de 2008-02-12 15:03 --- Subject: Re: [4.3 Regression] infinite loop while compiling VLC media player in vt_find_locations On Tue, 12 Feb 2008, zadeck at naturalbridge dot com wrote: --- Comment #5 from zadeck at naturalbridge dot com 2008-02-12 14:56 --- Richi, I looked at this code once but I really do not know this code at all and really do not want to learn it. It will take a fair amount of time to try to figure out what the underlying dataflow problem is and then figure out how to modify it so that it is strictly monotonic (i.e. guaranteed to converge). However, given that this is just improving debugging information, it should be possible to just hack a count of the number of iterations and just stop after 20, i.e the way that flow used to do it. If this is a blocker, this is what I would do to get the release out of the door. Matz has analyzed this bug already and a fix is in his mind. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35065
[Bug c/35171] New: ICE in vect_recog_dot_prod_pattern
test.c:
...
int f(int a, int b, short c, int d, short e) {
int i;
for (i = 1; i = 2 ; i++) {
c -= 4;
a = c;
d = d + (b?b:e);
}
return a + d;
}
...
...
$ cc1 -O3 test.c
...
test.c: In function 'f':
test.c:1: internal compiler error: in vect_recog_dot_prod_pattern, at
tree-vect-patterns.c:251
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
...
--
Summary: ICE in vect_recog_dot_prod_pattern
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Tom dot de dot Vries at Nxp dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35171
[Bug other/25035] [4.1/4.2 regression] libssp causes a failure with cross compilers with unified trees
--- Comment #23 from eric dot weddington at atmel dot com 2008-02-12 19:43 --- Since 4.x, libssp has had to be disabled for the AVR. Libssp is not required for building the AVR. I've been meaning to reopen this bug report for a while. Patch for disabling libssp for the AVR target is attached. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #14 from jakub at gcc dot gnu dot org 2008-02-12 16:27 --- Fixed. For 4.4 we should nuke CHANGE_DYNAMIC_TYPE_EXPR. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug debug/35065] [4.3 Regression] infinite loop while compiling VLC media player in vt_find_locations
--- Comment #8 from matz at gcc dot gnu dot org 2008-02-12 16:06 --- Actually the code in var-tracking.c does handle the situation that a reg contains multiple decls. Or better it tries to. If there weren't an obvious bug in clobber_variable_part(). With that fixed the looping doesn't occur anymore, as the OUT set now doesn't depend on the order of IN anymore, as it should be: @@ -2595,6 +2655,8 @@ clobber_variable_part (dataflow_set *set pool_free (attrs_pool, anode); *anextp = anext; } + else + anextp = anode-next; } } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35065
[Bug c/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions
--- Comment #6 from lennox at cs dot columbia dot edu 2008-02-12 15:49 --- (In reply to comment #4) The problem occurs equally with gnu89 extern inline functions as with c99 inline functions (as seen in the initial bug report), so using static inline when !__GNUC_STDC_INLINE__ still leaves the problem. -- lennox at cs dot columbia dot edu changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
[Bug debug/35065] [4.3 Regression] infinite loop while compiling VLC media player in vt_find_locations
--- Comment #7 from matz at gcc dot gnu dot org 2008-02-12 15:36 --- The immediate problem is that the solution iterates between two orders. On my machine (i686) it all happen around basic block 231. The even iterations (after 128 iterations) the var-track info for bb 231 starts with: Basic block 231: IN: Stack adjustment: 0 Reg 0: i+0 i_cycle+0 Reg 1: i+0 the odd iterations it's: Basic block 231: IN: Stack adjustment: 0 Reg 0: i_cycle+0 i+0 Reg 1: i+0 so the problem is in the hardreg-expr association. One time hardreg 0 contains i_cycle and i, the other time it contains i and i_cycle. That's of course completely equivalent, but leads to subtle differences in the the OUT set (for some yet unknown reason, I think probably _there_ the actual problem lies). The cause for these different IN sets is that the reg0 info isn't the join (i.e. intersection) but the union of information from the predecessors. Predecessor A has reg0: i in OUT, predecessor B has reg0: i_cycle in OUT. (Note: reg0 never contains both i and i_cycle in any OUT set). The code in vt_find_locations() does a _union_ of the information of the predecessors, i.e. it joins not only the common parts of the info but also the differences. The joining happens via linked lists, hence it is inherently dependend on the order the elements are seen. This and the problem that equivalent but differently ordered INs lead to different OUT sets, together with the fact that 231 is a loop basic block (i.e. feeds itself), leads to the oscillation. The fix I had in mind is to perhaps stabilize all this by not unioning but intersecting the predecessors OUT sets. This actually makes more sense, as surely if reg0 contain i at the end on block A, and i_cycle at the end of block B, it clearly has indeterminate value at the join point of both blocks, except if i and i_cycle somehow are equivalent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35065
[Bug debug/35065] [4.3 Regression] infinite loop while compiling VLC media player in vt_find_locations
--- Comment #5 from zadeck at naturalbridge dot com 2008-02-12 14:56 --- Richi, I looked at this code once but I really do not know this code at all and really do not want to learn it. It will take a fair amount of time to try to figure out what the underlying dataflow problem is and then figure out how to modify it so that it is strictly monotonic (i.e. guaranteed to converge). However, given that this is just improving debugging information, it should be possible to just hack a count of the number of iterations and just stop after 20, i.e the way that flow used to do it. If this is a blocker, this is what I would do to get the release out of the door. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35065
