[Bug c/26993] ICE on invalid code with weakref
--- Comment #4 from aoliva at gcc dot gnu dot org 2006-07-18 06:41 --- Subject: Bug 26993 Author: aoliva Date: Tue Jul 18 06:41:13 2006 New Revision: 115545 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115545 Log: PR c/26993 * c-common.c (handle_weakref_attribute): Ignore attribute in the same conditions the alias attribute is ignored. Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26993
[Bug c/26993] ICE on invalid code with weakref
--- Comment #5 from aoliva at gcc dot gnu dot org 2006-07-18 06:53 --- Subject: Bug 26993 Author: aoliva Date: Tue Jul 18 06:52:59 2006 New Revision: 115546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115546 Log: PR c/26993 * c-common.c (handle_weakref_attribute): Ignore attribute in the same conditions the alias attribute is ignored. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-common.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26993
[Bug middle-end/28411] gfortran: Internal error: Illegal instruction
--- Comment #4 from uros at kss-loka dot si 2006-07-18 07:29 --- This is the backtrace for the testcase in comment #3: #1 0x0827ae67 in fold_binary_to_constant (code=TRUNC_MOD_EXPR, type=0x402473f4, op0=0x402d9438, op1=0x0) at ../../gcc-svn/trunk/gcc/fold-const.c:12314 #2 0x08174b25 in constant_multiple_of (type=0x402473f4, top=0x402d9438, bot=0x0) at ../../gcc-svn/trunk/gcc/tree-ssa-loop-ivopts.c:2623 #3 0x081799d1 in get_computation_cost (data=0xb704, use=0x8706e70, cand=0x8707358, address_p=0 '\0', depends_on=0xb5f4) at ../../gcc-svn/trunk/gcc/tree-ssa-loop-ivopts.c:3758 #4 0x0817a364 in determine_use_iv_cost (data=0xb704, use=0x8706e70, cand=0x8707358) at ../../gcc-svn/trunk/gcc/tree-ssa-loop-ivopts.c:3901 #5 0x0817d41e in determine_use_iv_costs (data=0xb704) at ../../gcc-svn/trunk/gcc/tree-ssa-loop-ivopts.c:4128 #6 0x0817f3ac in tree_ssa_iv_optimize_loop (data=0xb704, loop=Variable loop is not available. constant_multiple_of() is calling fold_binary_to_constant() here: if (!zero_p (fold_binary_to_constant (TRUNC_MOD_EXPR, type, top, bot))) return NULL_TREE; As can be seen from backtrace above, bot operand is NULL, and this triggers assert in fold_binary(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28411
[Bug fortran/28416] New: ICE on allocatable codes
While testing the patch for TR15581 I encountered this ICE, which is not strictly related to the patch itself, since I reproduced below with the base compiler. The base compiler should refuse the code, the patched compiler should accept it. [EMAIL PROTECTED] ALLOCATABLE]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20060715/configure --prefix=/usr/local/gcc42 Thread model: posix gcc version 4.2.0 20060715 (experimental) [EMAIL PROTECTED] ALLOCATABLE]$ gfortran -c test2.f90 test2.f90: In function 'foo': test2.f90:1: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:148 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE on allocatable codes Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug fortran/28416] ICE on allocatable codes
--- Comment #1 from sfilippone at uniroma2 dot it 2006-07-18 07:42 --- Created an attachment (id=11909) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11909action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug tree-optimization/28411] gfortran: Internal error: Illegal instruction
--- Comment #5 from uros at kss-loka dot si 2006-07-18 08:06 ---
This error can be tracked down to fold_negate_expr() returning NULL_TREE via
this path:
(a) constant_multiple_of() calls fold_unary_to_constant():
/* If BOT seems to be negative, try dividing by -BOT instead, and negate
the result afterwards. */
if (tree_int_cst_sign_bit (bot))
{
negate = true;
bot = fold_unary_to_constant (NEGATE_EXPR, type, bot);
}
(b) fold_unary_to_constant() calls fold_unary()
(c) fold_unary() calls fold_unary_negate() for NEGATE_EXPR:
case NEGATE_EXPR:
tem = fold_negate_expr (arg0);
if (tem)
return fold_convert (type, tem);
return NULL_TREE;
(d) fold_negate_expr() returns NULL_TREE, because:
case INTEGER_CST:
tem = fold_negate_const (t, type);
if (! TREE_OVERFLOW (tem)
|| TYPE_UNSIGNED (type)
|| ! flag_trapv)
return tem;
break;
...
default:
break;
}
return NULL_TREE;
}
From here, I don't know, what a correct solution would be...
--
uros at kss-loka dot si changed:
What|Removed |Added
CC||uros at kss-loka dot si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28411
[Bug tree-optimization/28411] gfortran: Internal error: Illegal instruction
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-18 08:10 --- (In reply to comment #5) This error can be tracked down to fold_negate_expr() returning NULL_TREE via this path: (a) constant_multiple_of() calls fold_unary_to_constant(): This tells you that constant_multiple_of is not able to handle NULL_TREEs for the return of fold_unary_to_constant which is correct as the negative of 0x8000 will trap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28411
[Bug c/28417] New: suboptimal 'division by constant' optimization
It looks like expmed.c::choose_multiplier(), which is responsible for finding
parameters needed for replacing division by constant with mul+shift, sometimes
fails to find optimal parameters.
One example: A/1577682821 can be calculated by executing A*365384439
(27+32), for any 32-bit unsigned A. However, gcc-4.1.1 and all previous
versions generate much more elaborate code.
The below program demonstrates tis and also two more similar examples. It also
checks that mul+shift works for any unsigned A, by testing all possibe values
of A.
#include stdint.h
#include stdio.h
unsigned v;
void f9188_mul365384439_shift27(unsigned A) { v = A/(unsigned)1577682821; }
void f9188_mul365384439_shift27_prime(unsigned A) { v =
(((uint64_t)A)*(unsigned)365384439) (27+32); }
void f8399_mul2283243215_shift29(unsigned A) { v = A/(unsigned)1009898111; }
void f8399_mul2283243215_shift29_prime(unsigned A) { v =
(((uint64_t)A)*(unsigned)2283243215) (29+32); }
void f8267_mul2482476753_shift30(unsigned A) { v = A/(unsigned)1857695551; }
void f8267_mul2482476753_shift30_prime(unsigned A) { v =
(((uint64_t)A)*(unsigned)2482476753) (30+32); }
/* Generated code is suboptimal (gcc 4.1.1):
void f9188_mul365384439_shift27(unsigned A) { v = A/1577682821; }
f9188_mul365384439_shift27:
pushl %edi
pushl %esi
pushl %ebx
movl16(%esp), %ebx
movl$1551183727, %ecx
movl%ebx, %eax
mull%ecx
subl%edx, %ebx
shrl%ebx
leal(%ebx,%edx), %eax
shrl$30, %eax
movl%eax, v
popl%ebx
popl%esi
popl%edi
ret
void f8399_mul2283243215_shift29(unsigned A) { v = A/1009898111; }
f8399_mul2283243215_shift29:
pushl %edi
pushl %esi
pushl %ebx
movl16(%esp), %ebx
movl$271519133, %ecx
movl%ebx, %eax
mull%ecx
subl%edx, %ebx
shrl%ebx
leal(%ebx,%edx), %eax
shrl$29, %eax
movl%eax, v
popl%ebx
popl%esi
popl%edi
ret
void f8267_mul2482476753_shift30(unsigned A) { v = A/1857695551; }
f8267_mul2482476753_shift30:
pushl %edi
pushl %esi
pushl %ebx
movl16(%esp), %ebx
movl$669986209, %ecx
movl%ebx, %eax
mull%ecx
subl%edx, %ebx
shrl%ebx
leal(%ebx,%edx), %eax
shrl$30, %eax
movl%eax, v
popl%ebx
popl%esi
popl%edi
ret
These operations can be done like this:
f9188_mul365384439_shift27_prime:
movl$365384439, %eax
mull4(%esp)
movl%edx, %eax
shrl$27, %eax
movl%eax, v
ret
f8399_mul2283243215_shift29_prime:
movl$-2011724081, %eax
mull4(%esp)
movl%edx, %eax
shrl$29, %eax
movl%eax, v
ret
f8267_mul2482476753_shift30_prime:
movl$-1812490543, %eax
mull4(%esp)
movl%edx, %eax
shrl$30, %eax
movl%eax, v
ret
(Why there is that silly movl %edx, %eax - that's another good question...)
The verification program is below. Was compiled with -Os
(in order to force gcc to use div insn for a/b - we want to do true
division for the purpose of correctness check!)
and didn't report a failure.
*/
int main()
{
unsigned A=0,u,v;
while(++A) {
(A 0x) || printf(A=%u\r,A);
u = (((uint64_t)A)*(unsigned)365384439) (27+32);
v = A / (unsigned)1577682821;
if(u!=v) { printf(1: A=%u u=%u v=%u\n, A,u,v); return 0; }
u = (((uint64_t)A)*(unsigned)2283243215) (29+32);
v = A / (unsigned)1009898111;
if(u!=v) { printf(2: A=%u u=%u v=%u\n, A,u,v); return 0; }
u = (((uint64_t)A)*(unsigned)2482476753) (30+32);
v =A / (unsigned)1857695551;
if(u!=v) { printf(3: A=%u u=%u v=%u\n, A,u,v); return 0; }
}
puts();
return 0;
}
--
Summary: suboptimal 'division by constant' optimization
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug c/28417] suboptimal 'division by constant' optimization
--- Comment #1 from vda dot linux at googlemail dot com 2006-07-18 08:40
---
I didn't look too close at choose_multiplier(), yet.
If anybody will work upon it in order to make it better,
this is the routine which prints values 'K' and 'bits'
so that
(A*K)bits == A/B
is true for given fixed B and all A's in range [0...max_A].
You may want to add similar code to choose_multiplier().
Mathematical explanation is in the comment.
/*
[below: 'div' is unsigned integer division]
['/' is real division with infinite precision]
[A,B,C... - integers, a,b,c... - reals]
Theory: we want to calculate A div B, fast.
B is const 2 and is not a power of 2.
In fp: A/B = A*(L/B)/L. (If L is a large power of 2,
say 2^32, then it could be done really fast).
Let k := L/B, K := L div B + 1.
Then A/B = A*k/L.
Then this is true:
A div B = A * K div L.
For small enough A: A div B = A * K div L.
Lets find first A for which it is not true.
Lets compare k/L and K/L. K/L is larger by a small value d:
d := K/L - k/L = (L div B + 1) / L - L/B/L =
= (L div B * B + B) / (L*B) - L/(L*B) =
= (L div B * B + B - L) / (L*B)
A*K/L is larger than A*k/L by A*d.
A*k/L is closest to 'overflowing into next integer'
when A = N*B-1. The 'deficit' with such A is exactly 1/B.
If A*d = 1/B, then A*K/L will 'overflow'.
Thus bad_A = 1/B / d = (1/B) * (L*B)/(L div B * B + B - L) =
= L/(L div B * B + B - L). Then you need to 'walk up' to next
A representable as N*B-1: bad_A2 = (bad_A div B) * B + B-1
This is the first A which will have wrong result
(i.e. for which (A*K div L) = (A div B)+1, not (A div B).
Practical use.
Suppose that A and B are 32-bit unsigned integers.
Unfortunately, there exist only two B values in 3..2^32-1 range
for which _any_ 32-bit unsigned A can be fast divided using L=2^32
(because bad_A=2^32 and any A is less than that):
B=641 K=6700417 d=1/2753074036736 bad_A=4294967296 A=unlimited
B=6700417 K=641 d=1/28778071884562432 bad_A=4294967296 A=unlimited
We need to use larger powers of 2 for L if we need to handle
many more B's.
*/
void fastdiv_params(unsigned B, unsigned max_A)
{
unsigned K, d_LB, bits, max_bits;
uint64_t L, KL, mask, bad_A, max_bad_A;
if (!B || ((B-1)B) == 0) { // B is a power of 2
//if(0)
printf(B=%u: power of 2, division by shift\n, B);
return;
}
L = (max_ull/max_unsigned - 1) * B;
bits = 63;
mask = 1ULL 63;
while( !(L mask))
bits--, mask = 1;
L = mask;
while ( (KL = L/B + 1) max_unsigned)
bits--, L = 1;
K = KL;
// There is not much point in multiplying by even number
// and then shifting right. Reduce K L to avoid it:
while (!(K 1) bits 32)
bits--, L = 1, K = L/B + 1;
d_LB = ((L/B) * B + B - L);
bad_A = L / d_LB;
bad_A = (bad_A / B) * B + B-1;
if (bad_A = max_A) {
printf(B=%u,A=%u: no suitable fastdiv params found\n, B,
max_A);
return;
}
max_bits = bits;
max_bad_A = bad_A;
while(1) {
uint64_t last_L = L;
uint64_t last_bad_A = bad_A;
unsigned last_K = K;
bits--;
L = 1;
K = L/B + 1;
d_LB = ((L/B) * B + B - L);
bad_A = L / d_LB;
bad_A = (bad_A / B) * B + B-1;
if (bad_A = max_A || bits 32) {
// new params are bad, report last ones and bail out
//if(0)
printf(B=%u,A=%u: L=%llx(bits=%u) K=%u (bad_A=%llu,
bad_A=%llu at bits=%u)\n,
B, max_A, last_L, bits+1, last_K, last_bad_A,
max_bad_A, max_bits);
return;
}
}
}
--
vda dot linux at googlemail dot com changed:
What|Removed |Added
CC||vda dot linux at googlemail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug fortran/28415] 4.2.0 ICE when using automatic array and -fno-automatic
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-18 08:44 --- Confirmed. Reduced testcase: subroutine bar(n) integer n, x(n) x(1) = 0 end $ gfortran a.f90 -fno-automatic -c a.f90: In function bar: a.f90:2: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3593 The ICE is due to an assert(!TREE_STATIC (decl)). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2006-07-18 08:44:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
[Bug tree-optimization/19505] [4.0/4.1 Regression] java bytecode to native ICE in remove_unreachable_regions
--- Comment #24 from aph at gcc dot gnu dot org 2006-07-18 09:01 --- Subject: Bug 19505 Author: aph Date: Tue Jul 18 09:00:29 2006 New Revision: 115547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115547 Log: 2006-07-18 Andrew Haley [EMAIL PROTECTED] PR tree-optimization/19505 * tree-cfgcleanup.c (tree_forwarder_block_p): If we have an EH edge leaving this block, make sure that the destination of this block has only one predecessor. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug tree-optimization/19505] [4.0 Regression] java bytecode to native ICE in remove_unreachable_regions
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-07-18 09:06 --- Fixed on the 4.1 branch also now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 Regression] java |[4.0 Regression] java |bytecode to native ICE in |bytecode to native ICE in |remove_unreachable_regions |remove_unreachable_regions Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug c/28286] [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-07-18 10:08 --- Subject: Bug 28286 Author: reichelt Date: Tue Jul 18 10:08:22 2006 New Revision: 115548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115548 Log: PR c/28286 * c-pragma.c (handle_pragma_pack): Handle invalid constants. * gcc.dg/pragma-pack-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pragma-pack-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-pragma.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28286
[Bug c/28286] [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-07-18 10:17 --- Subject: Bug 28286 Author: reichelt Date: Tue Jul 18 10:17:15 2006 New Revision: 115549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115549 Log: PR c/28286 * c-pragma.c (handle_pragma_pack): Handle invalid constants. * gcc.dg/pragma-pack-4.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pragma-pack-4.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-pragma.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28286
[Bug c/28286] [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-18 10:19 --- Subject: Bug 28286 Author: reichelt Date: Tue Jul 18 10:19:28 2006 New Revision: 115550 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115550 Log: PR c/28286 * c-pragma.c (handle_pragma_pack): Handle invalid constants. * gcc.dg/pragma-pack-4.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pragma-pack-4.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/c-pragma.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28286
[Bug c/28286] [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-07-18 10:21 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28286
[Bug c/28418] New: [4.0/4.1/4.2 regression] ICE incrementing temporary variable
The following valid code snippet triggers an ICE since GCC 4.0.0
(only with the C frontend):
struct A { int i; };
void foo()
{
((struct A) { 0 }).i += 1;
}
bug.c: In function 'foo':
bug.c:5: internal compiler error: in gimple_add_tmp_var, at gimplify.c:720
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE incrementing temporary
variable
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28418
[Bug c/28418] [4.0/4.1/4.2 regression] ICE incrementing anonymous C99 variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-18 10:33 ---
First off this ((struct A) { 0 }) is not a temporary variable but instead an
anonymous C99 variable.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1/4.2 regression] ICE
|incrementing temporary |incrementing anonymous C99
|variable|variable
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28418
[Bug c/28419] New: [4.1/4.2 regression] ICE using __FUNCTION__ in invalid code
The following invalid code snippet triggers an ICE since GCC 4.1.0 (only with the C frontend): void foo() x; const char* p = __FUNCTION__; bug.c: In function 'foo': bug.c:1: error: expected declaration specifiers before 'x' bug.c:3: error: parameter 'p' is initialized bug.c:0: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] -- Summary: [4.1/4.2 regression] ICE using __FUNCTION__ in invalid code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28419
[Bug c/28418] [4.0/4.1/4.2 regression] ICE incrementing compound literal expression
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-18 10:39 --- Confirmed, we are gimplifying the compound literal expression twice which in turn calls gimple_add_tmp_var twice on the decl. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-18 10:39:24 date|| Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1/4.2 regression] ICE |incrementing anonymous C99 |incrementing compound |variable|literal expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28418
[Bug c/28419] [4.1/4.2 regression] ICE using __FUNCTION__ in invalid code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28419
[Bug c/28419] [4.1/4.2 regression] ICE using __FUNCTION__ in invalid code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28419
[Bug fortran/28416] ICE on allocatable codes
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-18 10:42 --- Confirmed, and not target-specific. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Known to fail||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-07-18 10:42:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug c++/28420] New: [4.0/4.1/4.2 regression] ICE with typeid as template parameter
The following invalid code snippet triggers an ICE since GCC 4.0.0: templateint struct A; int i = sizeof(Atypeid); bug.cc:3: error: `typeid' operator cannot appear in a constant-expression bug.cc:3: error: template argument 1 is invalid *** glibc detected *** double free or corruption (out): 0x009e51c0 *** bug.cc:3: internal compiler error: Aborted Please submit a full bug report, [etc.] -- Summary: [4.0/4.1/4.2 regression] ICE with typeid as template parameter Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28420
[Bug fortran/28335] flush() / write() statement on closed units - error?
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-07-18 10:47 --- Reduced testcase: close(88) flush(88) end You expect the above code to issue a runtime error, but we currently don't. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-18 10:47:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug c++/27961] [4.1/4.2 regression] ICE on invalid template declaration
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-18 10:48 --- Here's a testcase with a slightly different error message: templateint void f()(0); bug.cc:1: error: function 'void f()' is initialized like a variable bug.cc:1: internal compiler error: tree check: expected var_decl, have function_decl in cp_finish_decl, at cp/decl.c:5083 Please submit a full bug report, [etc.] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug c++/28304] [4.0/4.1 regression] ICE looking up invalid member template
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-07-18 10:56 --- Fixed at least on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-18 10:56:47 date|| Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |looking up invalid member |looking up invalid member |template|template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28304
[Bug c++/28291] [4.1 regression] ICE on invalid designated initializer
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-18 10:57 --- Fixed at least on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-18 10:57:58 date|| Summary|[4.1/4.2 regression] ICE on |[4.1 regression] ICE on |invalid designated |invalid designated |initializer |initializer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28291
[Bug c/28417] suboptimal 'division by constant' optimization
--- Comment #2 from vda dot linux at googlemail dot com 2006-07-18 12:06
---
Pseudo-code to help in reading above code:
void fastdiv_params(unsigned B, unsigned max_A)
{
L = (max_unsigned_long_long/max_unsigned - 1) * B;
L = largest_pow2_smaller_or_eq_to(L);
bits = log2(L);
while ((K = L/B + 1) max_unsigned)
bits--, L = 1;
// There is not much point in multiplying by even 'K'
// and then shifting right (dividing by 2*n). Reduce K L to avoid it:
while (!(K 1) bits 32)
bits--, L = 1, K = L/B + 1;
d_LB = ((L/B) * B + B - L);
bad_A = L / d_LB;
bad_A = (bad_A / B) * B + B-1;
if (bad_A = max_A)
bail_out_no_params_exist;
// 'K' and 'bits' params are already determined, can return them...
/* return_params(K,bits); */
// ...but if max_A is smaller then max_unsigned, we can
// optionally use smaller 'K' and 'bits'. Find smallest which
// still work:
max_bits = bits;
max_bad_A = bad_A;
while(1) {
uint64_t last_L = L;
unsigned last_K = K;
bits--;
L = 1;
K = L/B + 1;
d_LB = ((L/B) * B + B - L);
bad_A = L / d_LB;
bad_A = (bad_A / B) * B + B-1;
if (bad_A = max_A || bits 32)
// new params are bad, report last ones and bail out
return_params(last_K,bits+1);
}
}
--
vda dot linux at googlemail dot com changed:
What|Removed |Added
Component|middle-end |c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
[Bug tree-optimization/28410] [4.2 Regression] Wrong aliasing with global var grouping during call clobbering
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-07-18 13:25 --- Testing patch. The bug was in the alias pruning code. We need to handle .GLOBAL_VAR in access_can_touch_variable. A memory reference that uses a call-clobbered memory tag should always be considered to touch .GLOBAL_VAR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28410
[Bug c++/28408] What should be value of complexdouble(1.0,0.0) *= -1?
--- Comment #1 from bangerth at dealii dot org 2006-07-18 13:34 --- Is this related to libstdc++ PR 20758? Or is this unrelated since it apparently isn't in the implementation of libstdc++ but in the optimizers? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
[Bug c++/28300] In-class partial specialization of class accepted
--- Comment #1 from bangerth at dealii dot org 2006-07-18 13:35 --- Confirmed. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-18 13:35:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28300
[Bug c++/28363] [4.0/4.1/4.2 regression] Default template parameter causes compiler segfault
--- Comment #1 from bangerth at dealii dot org 2006-07-18 13:38 --- Confirmed, a regression introduced in 3.4.x. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2006-07-18 13:38:11 date|| Summary|Default template parameter |[4.0/4.1/4.2 regression] |causes compiler segfault|Default template parameter ||causes compiler segfault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28363
[Bug c++/28385] templated function call goes awry
--- Comment #1 from bangerth at dealii dot org 2006-07-18 13:40 --- (In reply to comment #0) Everyone knows that in C, function_name and function_name are generally equivalent-- you can write: func_ptr_type* f = function_name; or func_ptr_type* f = function_name; So it is surprising to me that myFoo(bar); seems to behave differently than: myFoo(bar); The difference is that C++ has references whereas C doesn't. 'bar' has type 'reference to function', whereas 'bar' is 'pointer to function'. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28385
[Bug c++/28385] [4.0/4.1/4.2 regression] templated function call goes awry
--- Comment #2 from bangerth at dealii dot org 2006-07-18 13:51 --- Independent of the previous question, I believe gcc is wrong. There should be two calls to bar(). Confirmed. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Severity|normal |major Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.0.2 4.1.0 Known to work||3.4.6 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2006-07-18 13:51:33 date|| Summary|templated function call goes|[4.0/4.1/4.2 regression] |awry|templated function call goes ||awry Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28385
[Bug c++/28363] [4.0/4.1/4.2 regression] Default template parameter causes compiler segfault
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28363
[Bug c++/28358] ICE on valide template code using -O1 or -O2, but *not* with -O0 or -O3
--- Comment #2 from bangerth at dealii dot org 2006-07-18 14:03 --- Confirmed, though the testcase is huge and the error message atrocious. Someone will have to take the time to reduce something smaller out of this whole boost mess... W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-18 14:03:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
[Bug tree-optimization/28410] [4.2 Regression] Wrong aliasing with global var grouping during call clobbering
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-07-18 14:06 --- Subject: Re: [4.2 Regression] Wrong aliasing with global var grouping during call clobbering dnovillo at gcc dot gnu dot org wrote: --- Comment #3 from dnovillo at gcc dot gnu dot org 2006-07-18 13:25 --- Testing patch. The bug was in the alias pruning code. We need to handle .GLOBAL_VAR in access_can_touch_variable. A memory reference that uses a call-clobbered memory tag should always be considered to touch .GLOBAL_VAR. Yay for random invariants! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28410
[Bug middle-end/28421] New: ICE with SSE code in extract_insn, at recog.c:2020
I get an ICE when I compile at -O1 (and only at -O1).
With the original source only gcc403 ICEs but not gcc401.
With the reduced source gcc401 ICEs too.
Michael Cieslinski
g++403 -O1 -S mb.ii -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.3/configure --prefix=/usr/local/gcc403
--program-suffix=403 --with-arch=opteron --enable-languages=c,c++
Thread model: posix
gcc version 4.0.3
/usr/local/gcc403/libexec/gcc/x86_64-unknown-linux-gnu/4.0.3/cc1plus
-fpreprocessed mb.ii -quiet -dumpbase mb.ii -march=opteron -auxbase mb -O1
-version -o mb.s
GNU C++ version 4.0.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.0.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
mb.ii: In function 'long int __vector__ foo()':
mb.ii:29: error: unrecognizable insn:
(insn 109 30 96 3 (set (reg:V2SI 0 ax)
(const_vector:V2SI [
(const_int -1 [0x])
(const_int -1 [0x])
])) -1 (nil)
(nil))
mb.ii:29: internal compiler error: in extract_insn, at recog.c:2020
mb.ii:
typedef long V2 __attribute__ ((__vector_size__(16)));
typedef int V4 __attribute__ ((__vector_size__(16)));
int bar(V2);
__inline V2 baz(int a, int b)
{
return (V4) {a, b};
}
V2 foo ()
{
V2* G;
int*H;
V2 A;
for (int E; E10; E++)
{
G++;
for (int F; FE; F++)
{
*G = baz(0x0, 0x0);
*H = bar(__builtin_ia32_psrldqi128(A, 8))
| bar(__builtin_ia32_psrldqi128(A, 96));
}
}
}
--
Summary: ICE with SSE code in extract_insn, at recog.c:2020
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
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=28421
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #12 from paul dot richard dot thomas at cea dot fr 2006-07-18 14:35 --- Created an attachment (id=11910) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11910action=view) The latest version of the patch This patch is the last version that I will post until after I return from vacation. As well as allocatable components, it fixes the two issues raised by Salvatore Filippone on the gfortran list. It also includes a test version of move_alloc that runs the following correctly: integer, allocatable :: x(:), y(:), temp(:) character(4), allocatable :: a(:), b(:) allocate (x(2)) allocate (a(2)) x = (/42, 77/) print *, allocated(x), allocated(y) if (allocated (x)) print *, x call move_alloc (x, y) print *, allocated(x), allocated(y) if (allocated (y)) print *, y a = (/abcd, efgh/) print *, allocated(a), allocated(b) if (allocated (a)) print *, a call move_alloc (a, b) print *, allocated(a), allocated(b) if (allocated (b)) print *, b ! Now one of the intended applications of move_alloc; resizing call move_alloc (to = temp, from = y) allocate (y(6)) y(1:2) = temp y(3:) = 99 print *, y end Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/28416] ICE on allocatable codes
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-07-18 14:38 --- The fix, as described on the list, is to be found in the latest patch to PR20541 - the TR15581 story. It includes the corrections to the going-out-of-scope cleanup, as well. I am sorry that I cannot deal with it; I hope that Erik is in a position to do so. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug target/28421] ICE with SSE code in extract_insn, at recog.c:2020
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-18 14:40 --- (reg:V2SI 0 ax) HUH, how can that happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28421
[Bug tree-optimization/19505] [4.0 Regression] java bytecode to native ICE in remove_unreachable_regions
--- Comment #26 from aph at gcc dot gnu dot org 2006-07-18 15:07 --- Subject: Bug 19505 Author: aph Date: Tue Jul 18 15:07:48 2006 New Revision: 115554 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115554 Log: 2006-07-13 Andrew Haley [EMAIL PROTECTED] PR tree-optimization/19505 * tree-cfgcleanup.c (tree_forwarder_block_p): If we have an EH edge leaving this block, make sure that the destination of this block has only one predecessor. Modified: branches/gcj-eclipse/gcc/ChangeLog branches/gcj-eclipse/gcc/tree-cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug java/28090] incorrect implementation of expand_java_arraystore
--- Comment #3 from tromey at gcc dot gnu dot org 2006-07-18 15:12 --- FWIW compiling from bytecode on svn head fails as well. In fact the test case is xfailed in this case. So this doesn't appear to be a regression. Also I think this patch is bogus (but at least it shows the right place to add the fix). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28090
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #7 from jakub at gcc dot gnu dot org 2006-07-18 15:45 --- Re #5, globalize_decl is way too late, the middle-end and especially back-end shouldn't be lied to, there are many nice optimizations which it can do with !TREE_PUBLIC symbols. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug tree-optimization/28411] Illegal instruction error with -ftrapv
--- Comment #7 from langton at gcc dot gnu dot org 2006-07-18 16:30 --- (In reply to comment #4) This is the backtrace for the testcase in comment #3: I didn't post the Linux output for the C testcase, but I was seeing either segmentation faults after a long wait or (occasionally) virtual memory exhausted errors, instead of the explicit fold-const ICE that resulted on an Intel Mac. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28411
[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #15 from anemo at mba dot ocn dot ne dot jp 2006-07-18 16:53 --- (In reply to comment #14) This is because it's an incoming parameter, and as a result, this doesn't look at all like an array access, but just a random pointer access. I have no plans to make the alias analysis algorithm reconstruct array indexes from random pointer arithmetic. I do not think reconstructing array indexes are needed, but is it hard to tell that *(a+0) never be an alias of *(a+1) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
[Bug c++/27495] [4.0/4.1/4.2 regression] ICE using . instead of -
--- Comment #3 from sje at gcc dot gnu dot org 2006-07-18 17:01 --- Subject: Bug 27495 Author: sje Date: Tue Jul 18 17:01:19 2006 New Revision: 115557 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115557 Log: PR c++/27495 * search.c (adjust_result_of_qualified_name_lookup): Change assert to part of if statement. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27495
[Bug c++/27495] [4.0/4.1/4.2 regression] ICE using . instead of -
--- Comment #4 from sje at gcc dot gnu dot org 2006-07-18 17:03 --- Subject: Bug 27495 Author: sje Date: Tue Jul 18 17:03:38 2006 New Revision: 115558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115558 Log: PR c++/27495 * g++.dg/other/pr27495.C: New. Added: trunk/gcc/testsuite/g++.dg/other/pr27495.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27495
[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #16 from dberlin at gcc dot gnu dot org 2006-07-18 17:03 --- Subject: Re: [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer anemo at mba dot ocn dot ne dot jp wrote: --- Comment #15 from anemo at mba dot ocn dot ne dot jp 2006-07-18 16:53 --- (In reply to comment #14) This is because it's an incoming parameter, and as a result, this doesn't look at all like an array access, but just a random pointer access. I have no plans to make the alias analysis algorithm reconstruct array indexes from random pointer arithmetic. I do not think reconstructing array indexes are needed, but is it hard to tell that *(a+0) never be an alias of *(a+1) ? We already do say this when we know the offsets. The point is that without reconstructing the array indexes, we'd have to follow use-def chains for *every single pointer access* on *every single operand update*, in order to attempt to get the offsets and disambiguate them. This is incredibly slow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
[Bug java/28423] New: multianewarray not always evaluated when compiling from bytecode
In this test case (from jakarta-commons-collections) we expect to see an
OutOfMemoryError thrown. This doesn't always happen as it should, but only
when compiling from bytecode. And only with ecj...
public class OutOfMemoryError
{
private static void fail(String msg)
{
System.err.println(msg);
System.exit(1);
}
private static void gc() {
try {
// trigger GC
byte[][] tooLarge = new byte[10][10];
fail(you have too much RAM);
} catch (java.lang.OutOfMemoryError ex) {
System.gc(); // ignore
}
}
public static void main(String[] argv)
{
gc();
}
}
It depends on exactly how the bytecode compiler generates code.
This one fails:
Method name:gc private static Signature: ()void
Attribute Code, length:70, max_stack:2, max_locals:0, code_length:22
0: ldc Integer 10
2: ldc Integer 10
4: multianewarray Class [[B 2
8: pop
This one doesn't fail:
Method name:gc private static Signature: ()void
Attribute Code, length:66, max_stack:2, max_locals:1, code_length:22
0: ldc Integer 10
2: ldc Integer 10
4: multianewarray Class [[B 2
8: astore_0
It seems that the pop instruction in the first version causes the
multianewarray never to be invoked. The oh so clever ecj notices that
tooLarge is never used, so doesn't generate a slot for it.
--
Summary: multianewarray not always evaluated when compiling from
bytecode
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28423
[Bug c++/28304] [4.0/4.1 regression] ICE looking up invalid member template
--- Comment #5 from sje at gcc dot gnu dot org 2006-07-18 17:18 --- Subject: Bug 28304 Author: sje Date: Tue Jul 18 17:18:09 2006 New Revision: 115559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115559 Log: PR c++/28304 * decl2.c (check_classfn): Return NULL_TREE on error. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28304
[Bug c++/28304] [4.0/4.1 regression] ICE looking up invalid member template
--- Comment #6 from sje at gcc dot gnu dot org 2006-07-18 17:21 --- Subject: Bug 28304 Author: sje Date: Tue Jul 18 17:21:25 2006 New Revision: 115560 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115560 Log: PR c++/28304 * g++.dg/other/pr28304.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/pr28304.C Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28304
[Bug java/28423] multianewarray not always evaluated when compiling from bytecode
--- Comment #1 from tromey at gcc dot gnu dot org 2006-07-18 17:21 --- I suspect this was solved on the gcj-eclipse branch by flushing the quick stack in some cases. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28423
[Bug c++/28260] ICE with incompatible friend declaration
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-07-18 17:22 --- Subject: Bug 28260 Author: lmillward Date: Tue Jul 18 17:22:39 2006 New Revision: 115561 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115561 Log: PR c++/28258 * method.c (locate_copy): Check for non_reference returning error_mark_node. PR c++/28260 * decl.c (duplicate_decls): Return error_mark_node on ambiguous declaration. PR c++/28258 * g++/dg/other/error13.C: New test. PR c++/28260 * g++.dg/template/friend44.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/error13.C trunk/gcc/testsuite/g++.dg/template/friend44.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28260
[Bug c++/28258] [4.0/4.1/4.2 regression] ICE with invalid constructor
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-07-18 17:22 --- Subject: Bug 28258 Author: lmillward Date: Tue Jul 18 17:22:39 2006 New Revision: 115561 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115561 Log: PR c++/28258 * method.c (locate_copy): Check for non_reference returning error_mark_node. PR c++/28260 * decl.c (duplicate_decls): Return error_mark_node on ambiguous declaration. PR c++/28258 * g++/dg/other/error13.C: New test. PR c++/28260 * g++.dg/template/friend44.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/error13.C trunk/gcc/testsuite/g++.dg/template/friend44.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28258
[Bug c++/28258] [4.0/4.1 regression] ICE with invalid constructor
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-07-18 17:23 --- Fixed on mainline. Will apply to release branches once testing completes. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with invalid constructor|with invalid constructor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28258
[Bug c++/28260] ICE with incompatible friend declaration
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-07-18 17:24 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28260
[Bug c++/28304] [4.0/4.1 regression] ICE looking up invalid member template
--- Comment #7 from sje at gcc dot gnu dot org 2006-07-18 17:25 --- Subject: Bug 28304 Author: sje Date: Tue Jul 18 17:25:40 2006 New Revision: 115563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115563 Log: PR c++/28304 * decl2.c (check_classfn): Return NULL_TREE on error. * g++.dg/other/pr28304.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/pr28304.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl2.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28304
[Bug tree-optimization/28410] [4.2 Regression] Wrong aliasing with global var grouping during call clobbering
--- Comment #5 from dnovillo at gcc dot gnu dot org 2006-07-18 17:28 --- Subject: Bug 28410 Author: dnovillo Date: Tue Jul 18 17:27:57 2006 New Revision: 115564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115564 Log: PR 28410 * tree-ssa-operands.c (access_can_touch_variable): Update comment. Return true if ALIAS is .GLOBAL_VAR. testsuite/ChangeLog PR 28410 * gcc.dg/tree-ssa/pr28410.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr28410.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-operands.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28410
[Bug tree-optimization/28410] [4.2 Regression] Wrong aliasing with global var grouping during call clobbering
--- Comment #6 from dnovillo at gcc dot gnu dot org 2006-07-18 17:29 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00786.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28410
[Bug c++/28291] [4.1 regression] ICE on invalid designated initializer
--- Comment #6 from sje at gcc dot gnu dot org 2006-07-18 17:46 --- Subject: Bug 28291 Author: sje Date: Tue Jul 18 17:45:46 2006 New Revision: 115565 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115565 Log: PR c++/28291 * decl.c (reshape_init_class): Return error_mark_node on error. * g++.dg/ext/pr28291.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/pr28291.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28291
[Bug c++/28424] New: Missing return statement in template function don't cause compiler error
In template function, g++ compiler does not detect missing return statement:
This part of code causes the problem:
#include iostream
template typename P1
int testFunc(P1 p)
{
}
int main()
{
float f = 0;
std::cout testFunc(f) std::endl;
}
g++ command line:
$ g++ test.cpp
(no output)
Test execution:
$./a.out
1094713344
G++ version:
$ g++ --version
g++ (GCC) 4.0.0 20060507 (prerelease) (Debian 4.0.3-3)
--
Summary: Missing return statement in template function don't
cause compiler error
Product: gcc
Version: 4.0.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doomtr666 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28424
[Bug fortran/25217] Derived type dummy argument having intent(out) attribute
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-09 07:48:40 |2006-07-18 18:28:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25217
[Bug c++/28424] Missing return statement in template function don't cause compiler error
--- Comment #1 from schwab at suse dot de 2006-07-18 18:38 --- A missing return statement is not an error, merely undefined behaviour. Use -Wreturn-type to get a warning and -Werror to turn that into an error. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28424
[Bug fortran/28416] ICE on allocatable codes
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-07-18 18:45 --- (In reply to comment #3) The fix, as described on the list, is to be found in the latest patch to PR20541 - the TR15581 story. It includes the corrections to the going-out-of-scope cleanup, as well. I am sorry that I cannot deal with it; I hope that Erik is in a position to do so. I'll see what I can do about it. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-18 10:42:03 |2006-07-18 18:45:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28416
[Bug fortran/28425] New: Derived type initialization via a derived type is broken
It appears that the initialization of a derived type that includes
a derived type is broken. Consider the following code.
!
! Original version sent by Vivek Rao on 18 Jan 06
! Modified by Steve Kargl to remove IO
!
module foo_mod
implicit none
type :: date_m
integer :: month
end type date_m
type :: file_info
type(date_m) :: date
end type file_info
end module foo_mod
program prog
use foo_mod
implicit none
type(date_m) :: dat
type(file_info) :: xx
dat = date_m(1)
xx = file_info(dat)
if (xx%date%month /= 1) call abort
end program prog
the original tree looks like
MAIN__ ()
{
struct date_m dat;
struct file_info xx;
_gfortran_set_std (70, 127, 0);
{
struct date_m date_m.0;
date_m.0.month = 1;
dat = date_m.0;
}
{
struct file_info file_info.1;
xx = file_info.1;
}
if (xx.date.month != 1)
{
_gfortran_abort ();
}
else
{
(void) 0;
}
}
--
Summary: Derived type initialization via a derived type is broken
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28425
[Bug fortran/28425] Derived type initialization via a derived type is broken
--- Comment #1 from kargl at gcc dot gnu dot org 2006-07-18 18:52 --- The parse tree looks okay to me. ASSIGN MAIN__:dat date_m(1) ASSIGN MAIN__:xx file_info(MAIN__:dat) IF ( MAIN__:xx % date % month 1) CALL _gfortran_abort () ENDIF -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28425
[Bug libgcj/28426] New: libgcj header files installed in wrong location in cross build
libgcj headers are installed in: GCC_PREFIX/include/c++/4.2.0
For a cross build g++ looks in GCC_PREFIX/${target}/include/c++/4.2.0
The result is that (by default) cni include files like gcj/cni.h cannot be
found by g++.
For a native build there is no problem.
--
Summary: libgcj header files installed in wrong location in cross
build
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mipsel-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28426
[Bug libgcj/28426] libgcj header files installed in wrong location in cross build
-- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-18 20:36:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28426
[Bug fortran/25217] Derived type dummy argument having intent(out) attribute
--- Comment #3 from patchapp at dberlin dot org 2006-07-18 20:40 --- Subject: Bug number PR 25217 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00796.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25217
[Bug libgcj/28426] libgcj header files installed in wrong location in cross build
--- Comment #1 from daney at gcc dot gnu dot org 2006-07-18 21:08 --- Proposed fix is here: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00798.html -- daney at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28426
[Bug target/27363] ARM gcc 4.1 optimization bug
--- Comment #11 from pbrook at gcc dot gnu dot org 2006-07-18 21:42 --- I'm working on this. Looks like a CSE bug. -- pbrook at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot |dot org |org Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-18 21:42:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug tree-optimization/19505] [4.0 Regression] java bytecode to native ICE in remove_unreachable_regions
--- Comment #27 from pinskia at gcc dot gnu dot org 2006-07-18 22:59 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug middle-end/28427] New: warning: alignment of '__FUNCTION__' is greater than maximum object file alignment.
This 2006-07-13 Jan Hubicka [EMAIL PROTECTED] * cgraphunit.c (cgraph_varpool_analyze_pending_decls): Call align_variable. has lead to very many warnings of the form ../../gcc/gcc/fortran/array.c:0: warning: alignment of '__FUNCTION__' is greater than maximum object file alignment. Using 16 ../../gcc/gcc/fortran/array.c:1141: warning: alignment of 'current_expand' is greater than maximum object file alignment. Using 16 on mingw32 target and prevents building with -Werror enabled. -- Summary: warning: alignment of '__FUNCTION__' is greater than maximum object file alignment. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28427
[Bug other/23541] All error messages produce segfault
--- Comment #24 from lucier at math dot purdue dot edu 2006-07-19 00:19 --- Well, I just hit the same bug in 4.1.1, so it survived from 4.1.0. I must be one hell of an atypical guy building 4.1.1, my bootstrap on x86-64 RHEL 4.0 didn't work (PR 28066), my 32-bit bootstrap on sparc-sun-solaris2.9 didn't work (PR27823), and now my 64-bit bootstrap fails here. Any chance of this one getting fixed in time for 4.1.2? -- lucier at math dot purdue dot edu changed: What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug c++/28235] [4.0/4.1/4.2 Regression] ICE with static const member as default parameter in template
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-07-19 00:22 --- Subject: Bug 28235 Author: mmitchel Date: Wed Jul 19 00:22:43 2006 New Revision: 115576 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115576 Log: PR c++/28235 * pt.c (tsubst_decl): Handling substitutions into a static data member from within the scope of the tempalte itself. PR c++/28235 * g++.dg/template/static27.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/static27.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28235
[Bug c++/28235] [4.0/4.1 Regression] ICE with static const member as default parameter in template
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-07-19 00:25 --- Fixed in 4.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1 Regression] ICE |with static const member as |with static const member as |default parameter in|default parameter in |template|template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28235
Re: [Bug other/23541] All error messages produce segfault
On Jul 19, 2006, at 9:19 AM, lucier at math dot purdue dot edu wrote: I must be one hell of an atypical guy building 4.1.1, my bootstrap on x86-64 RHEL 4.0 didn't work (PR 28066), Well PR 28066 is not a GCC bug but a bug in an older pre-release of binutils. -- Pinski
[Bug other/23541] All error messages produce segfault
--- Comment #25 from pinskia at physics dot uc dot edu 2006-07-19 00:27 --- Subject: Re: All error messages produce segfault On Jul 19, 2006, at 9:19 AM, lucier at math dot purdue dot edu wrote: I must be one hell of an atypical guy building 4.1.1, my bootstrap on x86-64 RHEL 4.0 didn't work (PR 28066), Well PR 28066 is not a GCC bug but a bug in an older pre-release of binutils. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug c++/28048] [4.0/4.1/4.2 Regression] ICE on accessing member of dependent name
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28048
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-07-19 00:45 --- This is certainly a serious problem. Right now, the C++ front end relies on TREE_PUBLIC in various places to determine whether or not something has external linkage. Instead, we could compute that, by looking at the scope of the entity. In fact, we already have a function (decl_linkage) that computes linkage. That function needs adjusting, in view of Jason's change; instead of checking TREE_PUBLIC, it should check DECL_NAMESPACE_SCOPE_P. And, everything in the C++ front end that cares about linkage needs to change to use DECL_EXTERNAL_LINKAGE_P, rather than checking TREE_PUBLIC. It looks like convert_nontype_argument already does use DECL_EXTERNAL_LINKAGE_P. So, this bug can probably be fixed by simply adjusting decl_linkage as above. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug c++/28409] [4.2 Regression] extern C and anonymous namespace
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-07-19 00:46 --- Yes, extern C should make the function have external linkage in the object file. Namespaces have no impact on extern C functions, except from the point of view of lexical scoping. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28409
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #96 from bkoz at gcc dot gnu dot org 2006-07-19 02:52 --- Created an attachment (id=11912) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11912action=view) viz patch part one Hey Jakub. Here's a way to start in on this. This does two things: 1) adds default visibility attributes to namespace std namespace std::tr1 namespace __gnu_cxx 2) adds hidden visibility attributes to namespace __gnu_internal There are a couple of things I want to do in addition to this, but these can be added in later. (Such as move as much __gnu_internal into anonymous namespaces, consolidate various internal namespaces into anonymous namespaces or __gnu_internal, relocation tuning, consolidation of visibility schemes between libsupc++ and libstdc++). Testing on so_7 with namespace associations is in progress. tested x86/linux tested x86/linux CXXFLAGS=-fvisibility=hidden (fails) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug bootstrap/28428] New: parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
The build log is somewhat jumbled, but bootstrap fails a make -j 8 with stage1/xgcc -Bstage1/ -B/pkgs/gcc-4.1.1/sparc-sun-solaris2.9/bin/ -c -O2 -g -mcpu=ultrasparc -m64 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I/pkgs/gmp-4.1.4/include -I/pkgs/gmp-4.1.4/include-o build/dummy-conditions.o ../../gcc/dummy-conditions.c echo \../../gcc\ tmp-gtyp.h ltf=../../gcc/cp/cp-tree.def ../../gcc/java/java-tree.def ../../gcc/objc/objc-tree.def; for f in $ltf; do \ echo #include \$f\; \ done | sed 's|../../gcc/||' tmp-gencheck.h make[2]: *** No rule to make target `c-typeck.c', needed by `c-typeck.o'. Stop. make[2]: *** Waiting for unfinished jobs echo ; tmp-gtyp.h make[2]: *** Waiting for unfinished jobs /usr/bin/ksh ../../gcc/../move-if-change tmp-optionlist optionlist make[2]: *** Waiting for unfinished jobs -- Summary: parallel make failure: No rule to make target `c- typeck.c', needed by `c-typeck.o'. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28428
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #97 from bkoz at gcc dot gnu dot org 2006-07-19 02:56 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-29 15:32:29 |2006-07-19 02:56:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug bootstrap/28428] parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-19 03:41 --- c-typeck.c is not a generated file so you must have done something wrong in extracting the source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28428
[Bug bootstrap/28428] parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28428
[Bug bootstrap/26377] gcc 4.1.0 RC1 failes to bootstrap
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-07-19 03:44 --- This works for me and many other people. Also no feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
[Bug c/26372] opposite of may_alias attribute
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-19 03:47 --- (In reply to comment #6) Yes, char pointers are special. I'd like a non-special char pointer. Actually it is not the char pointers which are special but access through a character, there is a difference. I often know that a char pointer will never alias non-char data, but can not prove that it obeys all the complicated rules for __restrict. restrict is actually less strict than what you want :). restrict attributed pointers are can still alias other pointers, just not other restrict attributed pointers. For non-char pointers the attribute would be useless unless -fno-strict-aliasing is in effect. Even then it might be useless as -fno-strict-aliasing is huge hammer. Also no feedback on an example in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26372
[Bug middle-end/26640] gcc 4.1.0 fails to bootstrap build on SuSE 10 using gcc 4.0.3
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-19 03:51 --- (In reply to comment #3) Subject: Re: gcc 4.1.0 fails to bootstrap build on SuSE 10 using gcc 4.0.3 What do you mean by static limit? Stack, I had meant to say. Anyways this works for many people including me and there has been no other feedback for 3 months so closing as worksforme. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26640
[Bug bootstrap/24130] 3.4.3 Bootstrap failed on AIX 5.3
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-19 03:52 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24130
[Bug java/20044] Wrong method call semantics (maybe instanceof/invokespecial)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-02-18 00:00:09 |2006-07-19 03:52:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error make[1]: *** [getpwd.o] Error 1
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-19 03:54 --- ../../gcc-4.0.3/libiberty/getpwd.c:77: storage size of `dotstat' isn't known ../../gcc-4.0.3/libiberty/getpwd.c:77: storage size of `pwdstat' isn't known That is a bug in the headers you have installed and not a bug in gcc. Closing as invalid as there has been no feedback in 3 months. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076
[Bug c++/27053] symbol2.c:2102: internal error: Segmentation fault when i try to compile gSOAP in cross compilation
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-19 03:55 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27053
[Bug bootstrap/28429] New: parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
The build log is somewhat jumbled, but bootstrap fails a make -j 8 with stage1/xgcc -Bstage1/ -B/pkgs/gcc-4.1.1/sparc-sun-solaris2.9/bin/ -c -O2 -g -mcpu=ultrasparc -m64 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I/pkgs/gmp-4.1.4/include -I/pkgs/gmp-4.1.4/include-o build/dummy-conditions.o ../../gcc/dummy-conditions.c echo \../../gcc\ tmp-gtyp.h ltf=../../gcc/cp/cp-tree.def ../../gcc/java/java-tree.def ../../gcc/objc/objc-tree.def; for f in $ltf; do \ echo #include \$f\; \ done | sed 's|../../gcc/||' tmp-gencheck.h make[2]: *** No rule to make target `c-typeck.c', needed by `c-typeck.o'. Stop. make[2]: *** Waiting for unfinished jobs echo ; tmp-gtyp.h make[2]: *** Waiting for unfinished jobs /usr/bin/ksh ../../gcc/../move-if-change tmp-optionlist optionlist make[2]: *** Waiting for unfinished jobs -- Summary: parallel make failure: No rule to make target `c- typeck.c', needed by `c-typeck.o'. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28429
[Bug bootstrap/28429] parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
--- Comment #1 from lucier at math dot purdue dot edu 2006-07-19 04:27 --- *** This bug has been marked as a duplicate of 28428 *** -- lucier at math dot purdue dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28429
[Bug bootstrap/28428] parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
--- Comment #2 from lucier at math dot purdue dot edu 2006-07-19 04:27 --- *** Bug 28429 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28428
[Bug bootstrap/28428] parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
--- Comment #3 from lucier at math dot purdue dot edu 2006-07-19 04:28 --- Let's close this one, it may be because the source directory is mounted on an NFS volume. -- lucier at math dot purdue dot edu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28428
[Bug c++/28235] [4.0 Regression] ICE with static const member as default parameter in template
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-07-19 05:09 --- Subject: Bug 28235 Author: mmitchel Date: Wed Jul 19 05:09:00 2006 New Revision: 115577 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115577 Log: PR c++/28235 * pt.c (tsubst_decl): Handling substitutions into a static data member from within the scope of the tempalte itself. PR c++/28235 * g++.dg/template/static27.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/static27.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 Regression] ICE|[4.0 Regression] ICE with |with static const member as |static const member as |default parameter in|default parameter in |template|template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28235
