[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-11-06 09:33 --- Subject: Bug 28796 Author: rguenth Date: Mon Nov 6 09:33:16 2006 New Revision: 118517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118517 Log: 2006-11-06 Richard Guenther [EMAIL PROTECTED] Backport from mainline: 2006-10-21 Richard Guenther [EMAIL PROTECTED] PR target/19116 * config/i386/i386.c (override_options): Do not set MASK_IEEE_FP if flag_unsafe_math_optimizations is specified. We have flag_finite_math_only for that. * config/i386/i386.md (sqrtxf2): Do not require TARGET_IEEE_FP or flag_unsafe_math_optimizations. PR middle-end/28796 * simplify-rtx.c (simplify_const_relational_operation): Do not constant-fold ORDERED and UNORDERED for flag_unsafe_math_optimizations but only we do not need to honor NaNs for the given mode. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.c branches/gcc-4_2-branch/gcc/config/i386/i386.md branches/gcc-4_2-branch/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug target/19116] -funsafe-math-optimizations make nan compares equal to one another (-finite-math-only should be doing that)
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-11-06 09:33 --- Subject: Bug 19116 Author: rguenth Date: Mon Nov 6 09:33:16 2006 New Revision: 118517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118517 Log: 2006-11-06 Richard Guenther [EMAIL PROTECTED] Backport from mainline: 2006-10-21 Richard Guenther [EMAIL PROTECTED] PR target/19116 * config/i386/i386.c (override_options): Do not set MASK_IEEE_FP if flag_unsafe_math_optimizations is specified. We have flag_finite_math_only for that. * config/i386/i386.md (sqrtxf2): Do not require TARGET_IEEE_FP or flag_unsafe_math_optimizations. PR middle-end/28796 * simplify-rtx.c (simplify_const_relational_operation): Do not constant-fold ORDERED and UNORDERED for flag_unsafe_math_optimizations but only we do not need to honor NaNs for the given mode. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/i386.c branches/gcc-4_2-branch/gcc/config/i386/i386.md branches/gcc-4_2-branch/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19116
[Bug target/19116] -funsafe-math-optimizations make nan compares equal to one another (-finite-math-only should be doing that)
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-11-06 09:34 --- Fixed for 4.2.0. The RM decided it's not worth the change in behavior during the 4.1/4.0 series (I agree). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19116
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- Comment #7 from irar at il dot ibm dot com 2006-11-06 09:38 --- Janis - thanks a lot for your help! http://gcc.gnu.org/viewcvs?view=revrev=110705 r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006) In r110704 bootstrap passes with and w/o vectorization enabled, and in r110705 boostrap fails in both cases (also without vectorization). The patch 2006-02-08 Jeff Law [EMAIL PROTECTED] PR tree-optimization/26169 * tree-vrp.c (execute_vrp): Perform any queued SSA updates before threading jumps. (http://gcc.gnu.org/viewcvs?view=revrevision=110758) fixes bootstrap without vectorization, but bootstrap with BOOT_CFLAGS=-O2 -g -ftree-vectorize -maltivec still fails. Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||law at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug testsuite/29737] make check fixinclude test FAILURES
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-06 10:43 --- glibc version? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29737
[Bug tree-optimization/29738] New: Missed constant propagation into loops
For the following testcase
int i;
void foo (void);
void bar (void)
{
int j;
i = 0;
for (j = 0; j 1; j++)
if (i)
foo ();
}
we cannot see that foo is never called and so the loop is empty. The problem
is that i is part of the loop evolution and so appears in a PHI node so we
cannot figure out i is zero:
bb 2:
# i_3 = V_MUST_DEF i_2;
i = 0;
# NONLOCAL.6_19 = PHI NONLOCAL.6_9(5), NONLOCAL.6_11(2);
# i_18 = PHI i_7(5), i_3(2);
# j_17 = PHI j_6(5), 0(2);
L0:;
# VUSE i_18;
i.0_5 = i;
if (i.0_5 != 0) goto L1; else goto L2;
L1:;
# i_12 = V_MAY_DEF i_18;
# NONLOCAL.6_13 = V_MAY_DEF NONLOCAL.6_19;
foo ();
# NONLOCAL.6_9 = PHI NONLOCAL.6_19(3), NONLOCAL.6_13(4);
# i_7 = PHI i_18(3), i_12(4);
L2:;
j_6 = j_17 + 1;
if (j_6 = ) goto L0; else goto L4;
I have no idea what optimization could catch this, though ;)
--
Summary: Missed constant propagation into loops
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug libstdc++/29722] Linking with libsupc++.a creates link time undefined references
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-06 11:10:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29722
[Bug libstdc++/29722] Linking with libsupc++.a creates link time undefined references
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-11-06 11:11 --- I'm on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29722
[Bug libstdc++/16006] Conversions of numbers in fi_FI.UTF-8 produces incorrect UTF-8
-- 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|REOPENED|ASSIGNED Last reconfirmed|-00-00 00:00:00 |2006-11-06 11:24:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006
[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)
--- Comment #7 from patchapp at dberlin dot org 2006-11-06 11:40 --- Subject: Bug number PR29122 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-11/msg00305.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29122
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #1 from sebastian dot pop at cri dot ensmp dot fr 2006-11-06
11:48 ---
Subject: Re: Missed constant propagation into loops
I think the problem is that i is a global variable and thus foo is
potentially
considered as modifying i. Have you tried
void foo (void);
void bar (void)
{
int i, j;
i = 0;
for (j = 0; j 1; j++)
if (i)
foo ();
}
This should be a simpler case that either is correctly simplified or I know
what to do for making it work.
For the original problem, why don't we propagate constants in
# i_3 = V_MUST_DEF i_2;
i = 0;
# NONLOCAL.6_19 = PHI NONLOCAL.6_9(5), NONLOCAL.6_11(2);
# i_18 = PHI i_7(5), i_3(2);
i.e. replacing the use of i_3 with just the constant 0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-11-06 11:51 ---
Have you tried
void foo (void);
void bar (void)
{
int i, j;
i = 0;
for (j = 0; j 1; j++)
if (i)
foo ();
}
This would work, obviously.
For the original problem, why don't we propagate constants in
# i_3 = V_MUST_DEF i_2;
i = 0;
# NONLOCAL.6_19 = PHI NONLOCAL.6_9(5), NONLOCAL.6_11(2);
# i_18 = PHI i_7(5), i_3(2);
i.e. replacing the use of i_3 with just the constant 0?
Because i is a virtual operand, not real one.
CCP could probably be taught to handle this case, I will check how difficult
that would be.
--
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|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-11-06 11:51:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #3 from rguenther at suse dot de 2006-11-06 12:04 ---
Subject: Re: Missed constant propagation into
loops
On Mon, 6 Nov 2006, rakdver at gcc dot gnu dot org wrote:
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-11-06 11:51
---
Have you tried
void foo (void);
void bar (void)
{
int i, j;
i = 0;
for (j = 0; j 1; j++)
if (i)
foo ();
}
This would work, obviously.
For the original problem, why don't we propagate constants in
# i_3 = V_MUST_DEF i_2;
i = 0;
# NONLOCAL.6_19 = PHI NONLOCAL.6_9(5), NONLOCAL.6_11(2);
# i_18 = PHI i_7(5), i_3(2);
i.e. replacing the use of i_3 with just the constant 0?
Because i is a virtual operand, not real one.
But that doesn't help that i is loop-carried and so we don't
propagate it to the if () stmt - we use i_18 there. Or am I missing
something?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-06 12:07 --- Btw, store_ccp should catch the propagation to the PHI node, but somehow it doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-06 12:08 ---
Subject: Re: Missed constant propagation into loops
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-11-06 11:51
---
Have you tried
void foo (void);
void bar (void)
{
int i, j;
i = 0;
for (j = 0; j 1; j++)
if (i)
foo ();
}
This would work, obviously.
For the original problem, why don't we propagate constants in
# i_3 = V_MUST_DEF i_2;
i = 0;
# NONLOCAL.6_19 = PHI NONLOCAL.6_9(5), NONLOCAL.6_11(2);
# i_18 = PHI i_7(5), i_3(2);
i.e. replacing the use of i_3 with just the constant 0?
Because i is a virtual operand, not real one.
But that doesn't help that i is loop-carried and so we don't
propagate it to the if () stmt - we use i_18 there. Or am I missing
something?
ccp can handle this for real operands.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-11-06 12:18 ---
But obviously for real operands, foo () won't clobber them. I.e. the following
also could be optimized but is not:
void foo (int *);
void bar (void)
{
int j;
int i;
i = 0;
for (j = 0; j 1; j++)
if (i)
foo (i);
}
foo () will be never executed, so the clobbering of i is not executed,
so we don't need i as PHI arg/result for the loop. This is what I'm looking
for as optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2006-11-06 12:25 --- OK, thanks. I'll try harder to reproduce on x86/Linux. This is getting annoying. I've built a first C++ compiler --with-as --with-ld set to the new binutils, installed it, then built a second C++ compiler using the first one to factor out configure quirks, but to no avail. Benjamin, could you attach your gcc/auto-host.h file from FC6? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-06 12:33 ---
Subject: Re: Missed constant propagation into loops
But obviously for real operands, foo () won't clobber them. I.e. the
following
also could be optimized but is not:
void foo (int *);
void bar (void)
{
int j;
int i;
i = 0;
for (j = 0; j 1; j++)
if (i)
foo (i);
}
foo () will be never executed, so the clobbering of i is not executed,
so we don't need i as PHI arg/result for the loop. This is what I'm looking
for as optimization.
now you have lost me, I have no idea what you are trying to tell. What
I mean is that this is exactly the same case like
void bar (void)
{
int j;
int i;
i = 0;
for (j = 0; j 1; j++)
if (i)
i = 1;
}
Except that in the testcase for the PR, i is not a real operand.
Since we already have some support for virtual operands in ccp, it
should not be too difficult to make it handle this case as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug tree-optimization/29738] Missed constant propagation into loops
--- Comment #8 from rguenther at suse dot de 2006-11-06 12:37 ---
Subject: Re: Missed constant propagation into
loops
On Mon, 6 Nov 2006, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
--- Comment #7 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-06 12:33 ---
Subject: Re: Missed constant propagation into loops
But obviously for real operands, foo () won't clobber them. I.e. the
following
also could be optimized but is not:
void foo (int *);
void bar (void)
{
int j;
int i;
i = 0;
for (j = 0; j 1; j++)
if (i)
foo (i);
}
foo () will be never executed, so the clobbering of i is not executed,
so we don't need i as PHI arg/result for the loop. This is what I'm looking
for as optimization.
now you have lost me, I have no idea what you are trying to tell. What
I mean is that this is exactly the same case like
void bar (void)
{
int j;
int i;
i = 0;
for (j = 0; j 1; j++)
if (i)
i = 1;
}
Except that in the testcase for the PR, i is not a real operand.
Since we already have some support for virtual operands in ccp, it
should not be too difficult to make it handle this case as well.
Ah, I see. You are of course completely right. Now the question is,
why does store_ccp not handle it? (Maybe it is as dis-functional as
store_copyprop was until I fixed it?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29738
[Bug c/29739] New: -Wconversion produces invalid warnings.
Hi guys,
The following snippet of code should not produce a warning as far as I
understand:
int foo(short bar)
{
return bar;
}
int main()
{
short d = 0;
return foo(d);
}
Unfortunately, however, I get this when I try to compile this code:
[EMAIL PROTECTED] ~/src $ gcc -Wconversion -o foo foo.c
foo.c: In function 'main':
foo.c:9: warning: passing argument 1 of 'foo' with different width due to
prototype
[EMAIL PROTECTED] ~/src $
We use -Wconversion to catch assignments of signed values to unsigned variables
like such:
unsigned foo = -1;
Which it catches correctly as expected.
This problem also shows up when using char instead of short (at least, haven't
tested other types). If the type of bar gets changed to int in the parameter
list of foo the warning goes away.
This warning was orriginally noted when using the strtok_r function, which uses
a macro implementation in order to use more optimal variations for certain
cases, the branch that checks for a constant needle of length 1 and then uses a
variation that looks for a single char produces the same warning:
warning: passing argument 2 of '__strtok_r_1c' with different width due to
prototype
--
Summary: -Wconversion produces invalid warnings.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaco at kroon dot co dot za
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=29739
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #1 from schwab at suse dot de 2006-11-06 13:55 --- The warning works as intended. *** This bug has been marked as a duplicate of 6614 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug c/6614] [-Wconversion] incorrect conversion warning for function taking a short
--- Comment #10 from schwab at suse dot de 2006-11-06 13:55 --- *** Bug 29739 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||jaco at kroon dot co dot za http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6614
[Bug tree-optimization/29740] New: [4.1 Regression] ICE in find_or_generate_expression, at tree-ssa-pre.c:1472
Compile with -O2.
double lap_discrete[3][3][3];
void create_laplacian (double **phi, unsigned long *nvox, unsigned *ext)
{
unsigned indx, indy, indz;
for (indz=0; indz*ext; indz++)
for (indy=0; indy*ext; indy++)
for (indx=0; indx*ext; indx++)
*(*phi+(*ext**ext*indz+*ext*indy+indx)) =
lap_discrete[indx][indy][indz];
}
--
Summary: [4.1 Regression] ICE in find_or_generate_expression, at
tree-ssa-pre.c:1472
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29740
[Bug tree-optimization/29740] [4.1 Regression] ICE in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-06 14:58 --- #1 0x008aad40 in find_or_generate_expression (block=0x2b50ce8c4c80, expr=0x2b50ce8d9210, stmts=0x2b50ce8d9ab0) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-pre.c:1468 1468 gcc_assert (UNARY_CLASS_P (genop) (gdb) bt #2 0x008aaf71 in create_expression_by_pieces (block=0x2b50ce8c4c80, expr=0xd0cd10, stmts=0x2b50ce8d9ab0) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-pre.c:1545 #3 0x008ab873 in insert_into_preds_of_block (block=0x2b50ce8c4400, node=0xd147d8, avail=0xd169d0, tmpname=0xa84d8f prephitmp) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-pre.c:1684 #4 0x008abff3 in insert_aux (block=0x2b50ce8c4400) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-pre.c:1883 #5 0x008ac0d8 in insert_aux (block=0x2b50ce8c4c80) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-pre.c:1915 #6 0x008ac0d8 in insert_aux (block=0x2b50ce8c4100) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-pre.c:1915 #7 0x008ac0d8 in insert_aux (block=0x2b50ce8c4000) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-pre.c:1915 #8 0x008ac1a9 in insert () at /space//rguenther/src/svn/gcc-4_1-branch/gcc/tree-ssa-pre.c:1937 (gdb) call debug_tree (genop) ssa_name 0x2b50ce8cc930 type integer_type 0x2b50ce708580 unsigned int sizes-gimplified public unsigned SI size integer_cst 0x2b50ce6f9a50 constant invariant 32 unit size integer_cst 0x2b50ce6f9570 constant invariant 4 align 32 symtab 0 alias set -1 precision 32 min integer_cst 0x2b50ce6f9b40 0 max integer_cst 0x2b50ce6f9b10 4294967295 pointer_to_this pointer_type 0x2b50ce8bf000 var var_decl 0x2b50ce8bf4d0 D.1626 def_stmt modify_expr 0x2b50ce8c3870 version 39 value 0x2b50ce8d9210 gcc_assert (UNARY_CLASS_P (genop) || BINARY_CLASS_P (genop) || COMPARISON_CLASS_P (genop) || REFERENCE_CLASS_P (genop) || TREE_CODE (genop) == CALL_EXPR); (gdb) up (gdb) call debug_generic_expr (expr) VH.25 * VH.30 Created value VH.24 for extD.1610_5 Created value VH.25 for *VH.24 Created value VH.30 for D.1626_39 ... compute_antic required 3 iterations Found partial redundancy for expression VH.25 * VH.30 Skipping insertion of phi for partial redundancy: Looks like an induction variable we obviously don't expect an SSA name here... but why are we value-numbering loads in 4.1 here? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Known to fail||4.1.0 4.1.1 4.1.2 Known to work||4.0.3 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29740
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #14 from hjl at lucon dot org 2006-11-06 15:12 --- I checked gcc 4.3. The same source code, which is miscompiled in gcc from SPEC CPU 2006, is there. It is most likely that gcc 4.3 is also miscompiled and now generating wrong unwind/debug info, if not wrong instructions. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-06 15:12:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-11-06 15:15 --- *** Bug 29740 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug tree-optimization/29740] [4.1 Regression] ICE in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-06 15:15 --- Actually, this is a dup of 28545. *** This bug has been marked as a duplicate of 28545 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29740
[Bug tree-optimization/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-11-06 15:17
---
pinskia: ping! (whole distro-rebuild with that patch ok for
{x86_64,i686,ppc,ppc64,ia64,s390,s390x}-linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug bootstrap/29741] New: Fails to build bootstrap under solaris 10, i386
Bootstrap build fails.
Operating system:
uname -a
SunOS malta.info.bt.co.uk 5.10 Generic_118844-26 i86pc i386 i86pc
pwd
/export/space/applications/install-files/gcc-4.1.1/objdir
Sequence used:
a) Create a temporary object directory
b) ../configure --enable-shared
c) make bootstrap - fails
gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../libiberty/../include -W -Wall
-pedantic -Wwrite-strings -Wstrict-prototypes ../../../libiberty/pex-unix.c -o
pex-unix.o
In file included from /usr/include/sys/signal.h:34,
from /usr/include/signal.h:26,
from ../../../libiberty/pex-unix.c:28:
/usr/include/sys/siginfo.h:259: error: parse error before ctid_t
/usr/include/sys/siginfo.h:292: error: parse error before '}' token
/usr/include/sys/siginfo.h:292: error: ISO C forbids data definition with no
type or storage class
/usr/include/sys/siginfo.h:294: error: parse error before '}' token
/usr/include/sys/siginfo.h:294: error: ISO C forbids data definition with no
type or storage class
/usr/include/sys/siginfo.h:390: error: parse error before ctid_t
/usr/include/sys/siginfo.h:392: error: conflicting types for `__proc'
/usr/include/sys/siginfo.h:261: error: previous declaration of `__proc'
/usr/include/sys/siginfo.h:398: error: conflicting types for `__fault'
/usr/include/sys/siginfo.h:267: error: previous declaration of `__fault'
/usr/include/sys/siginfo.h:404: error: conflicting types for `__file'
/usr/include/sys/siginfo.h:273: error: previous declaration of `__file'
/usr/include/sys/siginfo.h:420: error: conflicting types for `__prof'
/usr/include/sys/siginfo.h:287: error: previous declaration of `__prof'
/usr/include/sys/siginfo.h:424: error: conflicting types for `__rctl'
/usr/include/sys/siginfo.h:291: error: previous declaration of `__rctl'
/usr/include/sys/siginfo.h:426: error: parse error before '}' token
/usr/include/sys/siginfo.h:426: error: ISO C forbids data definition with no
type or storage class
/usr/include/sys/siginfo.h:428: error: parse error before '}' token
/usr/include/sys/siginfo.h:428: error: ISO C forbids data definition with no
type or storage class
/usr/include/sys/siginfo.h:432: error: parse error before k_siginfo_t
/usr/include/sys/siginfo.h:437: error: parse error before '}' token
/usr/include/sys/siginfo.h:437: error: ISO C forbids data definition with no
type or storage class
In file included from /usr/include/signal.h:26,
from ../../../libiberty/pex-unix.c:28:
/usr/include/sys/signal.h:85: error: parse error before siginfo_t
In file included from ../../../libiberty/pex-unix.c:28:
/usr/include/signal.h:111: error: parse error before siginfo_t
/usr/include/signal.h:113: error: parse error before siginfo_t
../../../libiberty/pex-unix.c: In function `pex_wait':
../../../libiberty/pex-unix.c:100: warning: implicit declaration of function
`waitpid'
../../../libiberty/pex-unix.c:103: warning: implicit declaration of function
`wait4'
make[1]: *** [pex-unix.o] Error 1
make[1]: Leaving directory
`/export/space/applications/install-files/gcc-4.1.1/objdir/build-i386-pc-solaris2.10/libiberty'
make: *** [all-build-libiberty] Error 2
config.cache
# This file is a shell script that caches the results of configure
# tests run on this system so they can be shared between configure
# scripts and configure runs. It is not useful on other systems.
# If it contains results you don't want to keep, you may remove or edit it.
#
# By default, configure uses ./config.cache as the cache file,
# creating it if it does not exist already. You can give configure
# the --cache-file=FILE option to use a different cache file; that is
# what configure does when it calls configure scripts in
# subdirectories, so they share the cache.
# Giving --cache-file=/dev/null disables caching, for debugging configure.
# config.status only pays attention to the cache file if you give it the
# --recheck option to rerun configure.
#
ac_cv_prog_AR=${ac_cv_prog_AR='ar'}
ac_cv_prog_AR_FOR_TARGET=${ac_cv_prog_AR_FOR_TARGET='ar'}
ac_cv_prog_AS=${ac_cv_prog_AS='as'}
ac_cv_prog_AS_FOR_TARGET=${ac_cv_prog_AS_FOR_TARGET='as'}
ac_cv_prog_CC=${ac_cv_prog_CC='gcc'}
ac_cv_prog_CC_FOR_TARGET=${ac_cv_prog_CC_FOR_TARGET='cc'}
ac_cv_prog_CXX_FOR_TARGET=${ac_cv_prog_CXX_FOR_TARGET='i386-pc-solaris2.10-c++'}
ac_cv_prog_GCC_FOR_TARGET=${ac_cv_prog_GCC_FOR_TARGET='i386-pc-solaris2.10-gcc'}
ac_cv_prog_GCJ_FOR_TARGET=${ac_cv_prog_GCJ_FOR_TARGET='i386-pc-solaris2.10-gcj'}
ac_cv_prog_LD=${ac_cv_prog_LD='/usr/ccs/bin/ld'}
ac_cv_prog_LD_FOR_TARGET=${ac_cv_prog_LD_FOR_TARGET='ld'}
ac_cv_prog_LEX=${ac_cv_prog_LEX='lex'}
ac_cv_prog_LN_S=${ac_cv_prog_LN_S='ln -s'}
ac_cv_prog_M4=${ac_cv_prog_M4='m4'}
ac_cv_prog_NM=${ac_cv_prog_NM='nm'}
ac_cv_prog_NM_FOR_TARGET=${ac_cv_prog_NM_FOR_TARGET='nm'}
ac_cv_prog_RANLIB=${ac_cv_prog_RANLIB='ranlib'}
ac_cv_prog_RANLIB_FOR_TARGET=${ac_cv_prog_RANLIB_FOR_TARGET='ranlib'}
ac_cv_prog_STRIP=${ac_cv_prog_STRIP='strip'}
Re: [Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
Zdenek, can you revert your patch until we fix this? It might be a month or two before i get back to it. (Yeah, i know it sucks to have to do this, but) On 6 Nov 2006 15:12:30 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: --- Comment #14 from hjl at lucon dot org 2006-11-06 15:12 --- I checked gcc 4.3. The same source code, which is miscompiled in gcc from SPEC CPU 2006, is there. It is most likely that gcc 4.3 is also miscompiled and now generating wrong unwind/debug info, if not wrong instructions. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-06 15:12:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #15 from dberlin at gcc dot gnu dot org 2006-11-06 16:28 --- Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc Zdenek, can you revert your patch until we fix this? It might be a month or two before i get back to it. (Yeah, i know it sucks to have to do this, but) On 6 Nov 2006 15:12:30 -, hjl at lucon dot org [EMAIL PROTECTED] wrote: --- Comment #14 from hjl at lucon dot org 2006-11-06 15:12 --- I checked gcc 4.3. The same source code, which is miscompiled in gcc from SPEC CPU 2006, is there. It is most likely that gcc 4.3 is also miscompiled and now generating wrong unwind/debug info, if not wrong instructions. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-06 15:12:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #2 from lopezibanez at gmail dot com 2006-11-06 16:30 --- (a bit more explanation won't hurt) The GCC documentation says: -Wconversion: Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype. In your program, in the absence of prototype, d would be promoted to int, thus the warning is correct. Wconversion is only useful for translating very old C code to ANSI/ISO C. Since this behaviour is not very useful in the present day, and Wconversion also warns for unsigned i = -1, we are going to move the above behaviour to Wtraditional-conversion and make Wconversion warn for implicit conversions that may change a value. This is planned for GCC 4.3 . For more info, please check http://gcc.gnu.org/wiki/Wcoercion and don't hesitate to contact me. (That wiki page is work in progress, not definitive, actually, it is a bit outdated). Testing and comments are welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #3 from jaco at kroon dot co dot za 2006-11-06 16:46 --- Awesome. That would be a good move. The implicit conversions are very handy for catching certain types of bugs early one, however, the function prototype thing is a pain. Unfortunately I won't be able to assist with testing etc in this regard, but I need to say that I truly appreciate the quick response to my bug reports (both here, and in general). You guys are doing awesome work. Keep it up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug fortran/27701] Two routines with the same name cause an interna; error in gfortran
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 27701 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27701
[Bug fortran/29211] ICE in FORALL character assignment with dependences
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 29211 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29211
[Bug fortran/29232] No warning/error for duplicate construct name
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 29232 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29232
[Bug fortran/29098] allocation of a pointer to a derived type crashes
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 29098 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29098
[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #11 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 29373 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug fortran/29115] ICE in structure constructor for array, ponter component with non-pointer data
--- Comment #6 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 29115 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29115
[Bug fortran/29364] No error given if using a non-defined type in a type definition
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 29364 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29364
[Bug fortran/29407] namelist: overriding the host association does not work (rejects valid code)
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 29407 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29407
[Bug fortran/24398] invalid module file gives weird error
--- Comment #12 from pault at gcc dot gnu dot org 2006-11-06 17:18 --- Subject: Bug 24398 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118522 Log: 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas [EMAIL PROTECTED] PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
[Bug tree-optimization/29680] [4.3 Regression] Misscompilation of spec2006 gcc
--- Comment #16 from hjl at lucon dot org 2006-11-06 17:19 --- I think we should add the testcase when the patch is reverted to prevent it from happening again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
[Bug other/29700] check requires autogen
--- Comment #6 from gin at mo dot msk dot ru 2006-11-06 17:24 --- Subject: Re: check requires autogen `make' performing all tests is not enough to test successfully. The test failures normally result in make error, ignored by `-k' or not. One looks for such error messages in `make' output. Having to sieve out other sorts of errors, those caused by missing `autogen', at least complicates use of tests and automating it in particular. This is why considering `-k' workaround unacceptable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29700
[Bug other/29700] check requires autogen
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-11-06 17:33 --- `make' performing all tests is not enough to test successfully. The test failures normally result in make error, ignored by `-k' or not. The GCC testsuite is DejaGNU-based so it is to be invoked with make -k check. One looks for such error messages in `make' output. Having to sieve out other sorts of errors, those caused by missing `autogen', at least complicates use of tests and automating it in particular. This is why considering `-k' workaround unacceptable. This is not a workaround. See http://gcc.gnu.org/install/test.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29700
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc
--- Comment #8 from law at redhat dot com 2006-11-06 17:37 --- Subject: Re: bootstrap comparision fails with -ftree-vectorize -maltivec on ppc On Mon, 2006-11-06 at 09:39 +, irar at il dot ibm dot com wrote: --- Comment #7 from irar at il dot ibm dot com 2006-11-06 09:38 --- Janis - thanks a lot for your help! http://gcc.gnu.org/viewcvs?view=revrev=110705 r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006) In r110704 bootstrap passes with and w/o vectorization enabled, and in r110705 boostrap fails in both cases (also without vectorization). The patch 2006-02-08 Jeff Law [EMAIL PROTECTED] PR tree-optimization/26169 * tree-vrp.c (execute_vrp): Perform any queued SSA updates before threading jumps. (http://gcc.gnu.org/viewcvs?view=revrevision=110758) fixes bootstrap without vectorization, but bootstrap with BOOT_CFLAGS=-O2 -g -ftree-vectorize -maltivec still fails. Unfortunately I don't have a PPC64 I can use for bootstrap tests. However, the failure you're seeing occurs when the stage1 compiler is compiling crtbegin (or some other file), then send me the appropriate .i file and I will be able to look at it with a cross compiler. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #4 from pepster at users dot sourceforge dot net 2006-11-06 17:45 --- Quick response? you must be joking. I reported this in Opened: 2002-05-09 14:46 against 2.95.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #5 from jaco at kroon dot co dot za 2006-11-06 18:21 --- I'm refering to the response to the bug, not the actual fix. I've had the priviledge of filing bugs against other projects where I forgot about the bug by the time somebody responded (two years down the line). I reckon having an explanation of what is going in in less that 5 hours is good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #6 from pepster at users dot sourceforge dot net 2006-11-06 18:49 --- 4 years to agree there is an issue here. maybe we will have a fix in 2010. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug fortran/29699] ICE in trans-decl.c
--- Comment #3 from pault at gcc dot gnu dot org 2006-11-06 19:14 --- Created an attachment (id=12552) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12552action=view) Patch to fix PR and two further, hidden problems The comments in the testcase tell the story. I need to think about deallocation of allocatable components overnight, before I submit. There is something not quite right there. With this patch, automatic arrays of structures with allocatable components are usable. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29699
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Comment #10 from aldot at gcc dot gnu dot org 2006-11-06 19:14 --- Should there be a default (I currently default to 100) for -ferror-count? I did choose to add one single check into gfc_warning_check, so we don't immediately bail out if the error count did exceed the given limit. Is this enough or is it better to instrument all of the error code to instantaneously bail if the limit is reached? For the testcase, trunk currently ICE like so, fwiw: Error: END DO statement expected at (1) d2ds.f:1718: subroutine stravg 1 Error: Unclassifiable statement at (1) Program received signal SIGSEGV, Segmentation fault. 0x00442fd4 in gfc_match_common () at ../../../src/gcc-4.3/gcc/fortran/match.c:2349 2349 while (tail-common_next) (gdb) bt #0 0x00442fd4 in gfc_match_common () at ../../../src/gcc-4.3/gcc/fortran/match.c:2349 #1 0x0044ecc0 in match_word (str=0xa47600 common, subr=0x442e26 gfc_match_common, old_locus=0x7fd75220) at ../../../src/gcc-4.3/gcc/fortran/parse.c:65 #2 0x0044f164 in decode_statement () at ../../../src/gcc-4.3/gcc/fortran/parse.c:193 #3 0x004502ef in next_fixed () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug target/29206] [4.2/4.3 regression] gcj-dbtool segfaults
--- Comment #6 from drow at gcc dot gnu dot org 2006-11-06 19:33 --- Created an attachment (id=12553) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12553action=view) Potential patch. This hasn't been tested yet; when it has I can add a changelog and post it. That's in progress now. Ranjit's patch to enable prologue analysis on i386 changed the behavior for other SJLJ targets. They used to call the no-op fallback_backtrace from sysdep/generic/backtrace.h; afterwards they called _Unwind_Backtrace. This links for SJLJ, but does not work, and when the trace function is called for _URC_END_OF_STACK, _Unwind_GetIP segfaults. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Comment #11 from aldot at gcc dot gnu dot org 2006-11-06 19:41 --- Mine. Will regtest when i get to a machine with TeX installed. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |aldot at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-06-04 10:18:54 |2006-11-06 19:41:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #7 from lopezibanez at gmail dot com 2006-11-06 19:51 --- I think 4.3 will be released on 2007 or early 2008. Fixing bugs on 4.2 and 4.3 will speed up things, of course. In addition, anyone could take the patches and apply them to their preferred stable version. I think they will apply more or less cleanly to any 4.X version. On the other hand, there is no issue at all in the sense that Wconversion works as documented and it was probably very useful when it was implemented. Now, the desire for a different Wconversion has been acknowledged by GCC developers since a long long time ago and they would have welcomed any implementation the very same day that you opened your bug. Just nobody (not only GCC devs, I mean no person on earth, not even you) had enough free time, resources or interest to implement it or they had higher priorities. Finally, I understand your frustration. I have done the same when I have been frustrated with software. (I may still do it sometimes without being fully aware and I always regret it) But I have learnt that negative comments (such as #6) are pointless, on the contrary, they tend to hurt and offend developers that have put endless nights, tears and blood on it. Even if you are completely right and correct, offending someone before asking for a favour simply doesn't work. -- lopezibanez at gmail dot com changed: What|Removed |Added CC|lopezibanez at gmail dot com| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug target/29714] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #5 from phil dot sidler at attachmate dot com 2006-11-06 20:18
---
Recreated with the following
#include stdint.h
main()
{
uint8_t area = 1;
uint8_t oldval;
uint8_t res;
oldval = area;
res = __sync_val_compare_and_swap(area, oldval, 128);
}
Note that constant values less that 128 in the 3rd parameter work OK.
Casting the 3rd parameter to be unsigned does not work.
Using a temporary variable instead of a constant does work, but only with
optimization turned off.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29714
[Bug target/29714] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-06 20:20 --- I think this has been fixed already, see PR 28924. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29714
[Bug c/29725] (signed char) to (signed int) typecast missbehaves
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-06 20:25 --- *** This bug has been marked as a duplicate of 27639 *** -- 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=29725
[Bug tree-optimization/27639] [4.1 regression] VRP miscompilation of simple loop
--- Comment #32 from pinskia at gcc dot gnu dot org 2006-11-06 20:25 --- *** Bug 29725 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||stian at nixia dot no http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
[Bug target/29714] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-06 20:26 --- (In reply to comment #5) Recreated with the following What exact version of 4.1.2 are you using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29714
[Bug c++/29653] [4.1 Regression] boost/mpl/aux_/has_tag.hpp:20: internal compiler error: Segmentation fault
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-06 20:28 --- (In reply to comment #2) Reducing ... This is still reducing, well I got distracted for a little bit also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29653
[Bug other/29668] [4.3 Regression] make error
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-06 20:29 --- I had meant to close this as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29668
[Bug fortran/29648] Inlining only done for contained procedures
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29648
[Bug target/29714] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #8 from phil dot sidler at attachmate dot com 2006-11-06 20:29 --- I see you're right, this is probably fixed now. This was on cc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29714
[Bug target/29714] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-06 20:31 --- This is a dup of bug 28924 after all and has been fixed already. *** This bug has been marked as a duplicate of 28924 *** -- 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=29714
[Bug target/28924] x86 sync builtins fail for char and short memory operands
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-06 20:31 --- *** Bug 29714 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||phil dot sidler at ||attachmate dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug c/29739] -Wconversion produces invalid warnings.
--- Comment #8 from pepster at users dot sourceforge dot net 2006-11-06 20:34 --- I spent a considerable amount of my personal time on open source projects, so I am not particularily ashamed of not fixing this bug myself (I tried, but gave up after I realized the learnign curve is too steep). I consider gcc to be one of the most important open source projects there is, as it is a prerequiste for most other projects, and greatly appreciate everyone contributing to this monumental project. However, unless the situation has dramatically changed, given the state of gcc code only the most determined non-maintainer would be able to fix bugs/problems. This probably explains my personal dismay regarding the fate of my bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29739
[Bug middle-end/29695] [4.1/4.2/4.3 Regression] Folding breaks (a 0x80) ? 0x80 : 0 for unsigned char or unsigned short a
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-06 20:34 --- 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=29695
[Bug fortran/29712] UBOUND of non-last dimensions of assumed-size array
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-06 20:37 --- This is my fault I think. There was a PR about ubound and assumed-size arrays where we crashed and I changed the code to reject all ubound on them IIRC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29712
[Bug tree-optimization/29710] gnat ICEs on -fprefetch-loop-arrays -O1.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-06 20:38 --- Can you give the backtrace and also attach the sources which crash? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710
[Bug fortran/29713] [4.2 Regression] ICE in gfc_set_constant_character_len decl.c:762
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|ICE [regression, trunk, |[4.2 Regression] ICE in |4.2]: in|gfc_set_constant_character_l |gfc_set_constant_character_l|en decl.c:762 |en decl.c:762 | Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29713
[Bug c++/29704] [4.1 Regression] ICE: default non-type template argument of pointer-to-member type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE: default non-type |[4.1 Regression] ICE: |template argument of|default non-type template |pointer-to-member type |argument of pointer-to- ||member type Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29704
[Bug target/29206] [4.2/4.3 regression] gcj-dbtool segfaults
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-06 21:09 --- Subject: Re: [4.2/4.3 regression] gcj-dbtool segfaults Ranjit's patch to enable prologue analysis on i386 changed the behavior for other SJLJ targets. They used to call the no-op fallback_backtrace from sysdep/generic/backtrace.h; afterwards they called _Unwind_Backtrace. This links for SJLJ, but does not work, and when the trace function is called for _URC_END_OF_STACK, _Unwind_GetIP segfaults. From the PR, I had no idea that debian was still using the SJLJ exception support on this target. I switched to only building and testing with DWARF2 exceptions a long time ago. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug target/29206] [4.2/4.3 regression] gcj-dbtool segfaults
--- Comment #8 from drow at gcc dot gnu dot org 2006-11-06 21:47 --- I'm not sure, but I think that our hppa port hasn't switched over yet. As for ARM, I'm not sure what to do to fix the issue. ARM old ABI is stuck with SJLJ. And the EABI can't implement _Unwind_Backtrace either. I have been speaking with someone at ARM about the ABI implications of this, on and off, but I don't have a lot of hope for it working out without a GNU extension. -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug target/29714] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #10 from phil dot sidler at attachmate dot com 2006-11-06 21:58 --- fyi, does work OK at gcc (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) cheers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29714
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #29 from bkoz at gcc dot gnu dot org 2006-11-06 22:03 --- Created an attachment (id=12555) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12555action=view) auto-host.h file from FC6 gcc build directory Here you go Eric. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #30 from bkoz at gcc dot gnu dot org 2006-11-06 22:05 --- Since this is also new hardware for me, I'll try a couple of other things to try and isolate. Note that gcc-4_2-branch is working perfectly for me, so I have switched over to that for work as a temporary measure so I can get things done. This makes me think that it's not a distro-specific issue, or a hardware specific issue, or a binutils specific issue, but most likely a gcc-specific issue. Things I'll try tomorrow: 1) disabling PCH 2) the usual PIE/SELinux disabling switcheroos -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug fortran/29744] New: [Regression] Type renaming crashes gfortran with excessive memory usage
Hi, the code sample from PR 19362 crashes for me after eating all main memory. I checked that a copy of gfortran from 20060710 still works, while the copy from 20060904 and all later versions crash. The problems appears to be related to the renaming of the derived type from the included module. Maybe it's some infinite recursion? (For testers: I suggest to set a suitable ulimit, e.g. ulimit -v 5 before calling gfortran on this example to avoid thrashing). -- Summary: [Regression] Type renaming crashes gfortran with excessive memory usage Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29744
[Bug target/29206] [4.2/4.3 regression] gcj-dbtool segfaults
--- Comment #9 from debian-gcc at lists dot debian dot org 2006-11-06 22:14 --- hppa is supposed to use dwarf2 based exceptions in Debian; at least that's what the libgcc soversion (4) suggests; explicitely configuring with --enable-sjlj-exceptions would configure tu build libgcc with soversion 3. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2006-11-06 22:14 --- Here you go Eric. Thanks. Why are COMDAT groups disabled in your compiler? /* Define 0/1 if your assembler and linker support COMDAT groups. */ #ifndef USED_FOR_TARGET -#define HAVE_COMDAT_GROUP 0 +#define HAVE_COMDAT_GROUP 1 #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug fortran/29630] Unclassifiable statement with vector subscripts in initialization
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-11-06 22:19 --- Subject: Bug 29630 Author: eedelman Date: Mon Nov 6 22:18:54 2006 New Revision: 118528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118528 Log: fortran/ 2006-11-06 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-06 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. * gfortran.dg/initialization_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29630
[Bug fortran/29679] Inability to get shapes correct in initializations
--- Comment #1 from eedelman at gcc dot gnu dot org 2006-11-06 22:19 --- Subject: Bug 29679 Author: eedelman Date: Mon Nov 6 22:18:54 2006 New Revision: 118528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118528 Log: fortran/ 2006-11-06 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * expr.c (find_array_section): Support vector subscripts. Don't add sizes for dimen_type == DIMEN_ELEMENT to the shape array. testsuite/ 2006-11-06 Erik Edelmann [EMAIL PROTECTED] PR fortran/29630 PR fortran/29679 * gfortran.dg/initialization_2.f90: Test PRs 29630 and 29679 too. * gfortran.dg/initialization_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/initialization_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29679
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #17 from kreckel at ginac dot de 2006-11-06 22:23 ---
(In reply to comment #15)
Maybe scheduling would have the same issue. The fact that the result of the
division is not used is a red herring, though. Of course, the assumption is
that it's actually used.
For the record: Andrew was right and above statement is wrong. The standard
explicitly mandates that unused code must not be removed unless the compiler
can determine that it cannot raise an exception flag [F.8.1]:
: Concern about side effects may inhibit code motion and removal of seemingly
: useless code. For example, in
: #include fenv.h
: #pragma STDC FENV_ACCESS ON
: void f(double x)
: {
: /* ... */
: for (i = 0; i n; i++) x + 1;
: /* ... */
: }
: x + 1 might raise floating-point exceptions, so cannot be removed. And since
: the loop body might not execute (maybe 0 ³ n), x + 1 cannot be moved out of
: the loop. (Of course these optimizations are valid if the implementation can
: rule out the nettlesome cases.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug target/29721] Wrong code when compiling libjava/verify.cc at -O2
--- Comment #4 from daney at gcc dot gnu dot org 2006-11-06 22:31 --- OK, looks like GCC may be allowed to emit the relocations out of order. I am looking into the possiblility that gas can be fixed so that the relocaitons are emitted in the proper order even if their position in the code is out of order. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29721
'configure' of gcc-4.1.1 apparently does not check for presence of 'autogen'
Hello, I am building gcc-4.1.1 in the framework of my project (see signature). Basically, 'gcc' is built according to configure make make check make install (I build everything locally, no root privileges are needed, directory per lib/app) scheme. Because of the scheme I expect all the steps to be successful if 'configure' is successful, which it is in my case. One of the first things during 'make check' is calling 'autogen': 1 make[1]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1' 2 make[2]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fastjar' 3 make[2]: Nothing to be done for `check'. 4 make[2]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fastjar' 5 make[2]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fixincludes' 6 autogen -T /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1.src/fixincludes/check.tpl /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1.src/fixincludes/inclhack.def . 'autogen' was not installed on my system, so make check failed. I expected 'configure' to check existence of all needed prerequisites - apparently, it's not the case with 'autogen'. Thanks, Sergei. Applications From Scratch: http://appsfromscratch.berlios.de/ Sponsored Link Free Uniden 5.8GHz Phone System with Packet8 Internet Phone Service http://www.getpacket8.net/yahoo2
[Bug c++/29745] New: fold_offsetof_1
hello, I ported an app on x86_64 and I isolate the class who's make a compiler
break down.
bug.C:47: internal compiler error: in fold_offsetof_1, at c-common.c:5998
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
the command line is:
g++ -c -I/usr/X11/include -o bug.o bug.C
g++ -v
Using built-in specs.
Target: x86_64-slackware-linux
Configured with: ../gcc-4.1.1/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
gcc version 4.1.1
//
// bug.h
//
// g++ -c -I/usr/X11/include -o bug.o bug.C
#ifndef _BUG_H_
#define _BUG_H_
#include X11/Intrinsic.h
typedef char * HelpNode;
class MLXHelp {
protected:
static Pixel highlightPixel;
static XtResource mlxHelpResources[];
static Pixel htPixel;
public:
MLXHelp(char *filename = NULL, Widget parent = NULL, HelpNode *hn = NULL);
virtual ~MLXHelp();
};
#endif
// --
// bug.C
// --
#include bug.h
#include X11/StringDefs.h
XtResource MLXHelp::mlxHelpResources [] = {
{
hypertextColor, hypertextColor, XtRPixel, sizeof(Pixel),
XtOffsetOf(::MLXHelp, htPixel), XtRString, (XtPointer)steelblue4
},
{
charHighlightColor, charHighlightColor, XtRPixel, sizeof(Pixel),
XtOffsetOf(::MLXHelp, highlightPixel), XtRString, (XtPointer)red
}
};
MLXHelp::MLXHelp(char *filename, Widget wg, HelpNode *hn)
}
MLXHelp::~MLXHelp()
{
}
--
Summary: fold_offsetof_1
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lepinat at free dot fr
GCC host triplet: linux 2.6.18.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29745
[Bug c++/27601] [4.0/4.1/4.2 Regression] ICE (in fold_offsetof_1, at c-common.c:5998) on strange offsetof
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-11-06 23:08 --- *** Bug 29745 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||lepinat at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601
[Bug c++/29745] fold_offsetof_1
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-06 23:08 --- *** This bug has been marked as a duplicate of 27601 *** -- 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=29745
[Bug tree-optimization/29439] [4.2/4.3 regression] ICE in fold-const.c:1385 with -O1 -fwrapv -ftree-vrp
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-06 23:25 --- Subject: Bug 29439 Author: pinskia Date: Mon Nov 6 23:25:19 2006 New Revision: 118530 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118530 Log: 2006-11-06 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/29439 * tree-vrp.c (vrp_int_const_binop): Use the correct tree when checking for overflow. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug tree-optimization/29439] [4.2 regression] ICE in fold-const.c:1385 with -O1 -fwrapv -ftree-vrp
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-06 23:25 --- Fixed on the mainline, will fix later on the 4.2 branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 regression] ICE in|[4.2 regression] ICE in |fold-const.c:1385 with -O1 -|fold-const.c:1385 with -O1 - |fwrapv -ftree-vrp |fwrapv -ftree-vrp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #32 from bkoz at gcc dot gnu dot org 2006-11-06 23:50 --- Dunno. However, this bit is the same for gcc and gcc-4_2-branch on my system. There are, however, other differences between the gcc and gcc-4_2-branch files: %diff gcc/auto-host.h ../gcc-4_2-branch/gcc/auto-host.h *** gcc/auto-host.h 2006-11-06 09:23:47.0 +0100 --- ../gcc-4_2-branch/gcc/auto-host.h 2006-11-05 12:00:38.0 +0100 *** *** 204,216 #endif - /* Define if your assembler supports the subtraction of symbols in different -sections. */ - #ifndef USED_FOR_TARGET - #define HAVE_AS_IX86_DIFF_SECT_DELTA 1 - #endif - - /* Define if your assembler supports the ffreep mnemonic. */ #ifndef USED_FOR_TARGET #define HAVE_AS_IX86_FFREEP 1 --- 204,209 *** *** 241,264 #endif - /* Define if your assembler supports mffgpr and mftgpr. */ - #ifndef USED_FOR_TARGET - /* #undef HAVE_AS_MFPGPR */ - #endif - - /* Define if your assembler supports the -no-mul-bug-abort option. */ #ifndef USED_FOR_TARGET /* #undef HAVE_AS_NO_MUL_BUG_ABORT_OPTION */ #endif - /* Define if the assembler understands -mno-shared. */ - #ifndef USED_FOR_TARGET - /* #undef HAVE_AS_NO_SHARED */ - #endif - - /* Define if your assembler supports offsetable %lo(). */ #ifndef USED_FOR_TARGET /* #undef HAVE_AS_OFFSETABLE_LO10 */ --- 234,245 *** *** 903,915 /* Define if your linker supports --eh-frame-hdr option. */ #define HAVE_LD_EH_FRAME_HDR 1 - /* Define if your linker supports garbage collection of sections in presence -of EH frames. */ - #ifndef USED_FOR_TARGET - #define HAVE_LD_EH_GC_SECTIONS 1 - #endif - - /* Define if your PowerPC64 linker only needs function descriptor syms. */ #ifndef USED_FOR_TARGET /* #undef HAVE_LD_NO_DOT_SYMS */ --- 884,889 *** *** 1280,1286 /* Define to PREFIX/include if cpp should also search that directory. */ #ifndef USED_FOR_TARGET ! #define PREFIX_INCLUDE_DIR /mnt/share/bld/H-x86-gcc/include #endif --- 1254,1260 /* Define to PREFIX/include if cpp should also search that directory. */ #ifndef USED_FOR_TARGET ! #define PREFIX_INCLUDE_DIR /mnt/share/bld/H-x86-gcc-4_2-branch/include #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #33 from ebotcazou at gcc dot gnu dot org 2006-11-07 00:04 --- Dunno. However, this bit is the same for gcc and gcc-4_2-branch on my system. Weird. COMDAT groups are not supposed to be disabled on Linux I think. Dave, are they also disabled on yours? If so, what compiler do you use to compile your binutils? There are, however, other differences between the gcc and gcc-4_2-branch files: Right, but the only significant difference with my compiler is the disabling of COMDAT groups on yours. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug c++/29729] [4.0/4.1/4.2/4.3 regression] ICE with template class in template function
--- Comment #1 from bangerth at dealii dot org 2006-11-07 01:04 --- Why exactly is this invalid again? 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=29729
[Bug c++/29729] [4.0/4.1/4.2/4.3 regression] ICE with template class in template function
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-07 01:10 --- (In reply to comment #1) Why exactly is this invalid again? Because local types cannot be templates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29729
[Bug other/29639] [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test
--- Comment #34 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-07 02:08 --- Subject: Re: [4.3 regression] ext/bitmap_allocator/check_allocate_max_size.cc execution test Weird. COMDAT groups are not supposed to be disabled on Linux I think. Dave, are they also disabled on yours? If so, what compiler do you use to No. compile your binutils? In on case I used 4.1.1 and the other 3.3.4. Both exhibit the same behavior. From the debugging that I did, it looked as if there's a problem with the LSDA data. This causes the encoding error. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
[Bug target/29746] New: gcc fails to bootstrap on sh4-*-linux-gnu
The bootstrap on sh4-unknown-linux-gnu fails during stage2 with
../../TMP/trunk/gcc/ifcvt.c: In function 'noce_try_store_flag_constants':
../../TMP/trunk/gcc/ifcvt.c:1036: error: insn does not satisfy its constraints:
(insn 871 901 872 42 ../../TMP/trunk/gcc/ifcvt.c:977 (set (reg:SI 147 t)
(eq:SI (reg:SI 1 r1)
(const_int 1 [0x1]))) 1 {cmpeqsi_t} (nil)
(nil))
../../TMP/trunk/gcc/ifcvt.c:1036: internal compiler error: in
copyprop_hardreg_forward_1, at regrename.c:1614
--
Summary: gcc fails to bootstrap on sh4-*-linux-gnu
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC build triplet: sh4-*-linux-gnu
GCC host triplet: sh4-*-linux-gnu
GCC target triplet: sh4-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #1 from kkojima at gcc dot gnu dot org 2006-11-07 02:35 --- Created an attachment (id=12556) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12556action=view) a reduced test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug bootstrap/29747] New: No debug symbols when compiling stage2 compiler with -O2 -g
About the host compiler:
MacBookPro15:~/Developer/Compiler/gcc-head drew$ gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /Users/drew/Developer/Compiler/gcc-head/configure
--target=i686-apple-darwin8 --host=i686-apple-darwin8
--build=i686-apple-darwin8 --prefix=/usr/local/ada-4.2 --disable-libssp
--with-arch=pentium-m --with-tune=prescott --enable-languages=c,ada
Thread model: posix
gcc version 4.2.0 20060409 (experimental)
Configure command:
MacBookPro15:~/Developer/Compiler/gcc-head drew$ contrib/gcc_build -c
'--enable-checking=release --prefix=/usr/local/ada-4.3 --with-arch=nocona
--with-tune=generic --host=i686-apple-darwin8 --target=i686-apple-darwin8
--build=i686-apple-darwin8 --with-gmp=/opt/local --with-mpfr=/opt/local
--enable-languages=c,ada' -d $PWD -o $PWD/build update build test
Information from config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.59. Invocation command line was
$ /Users/drew/Developer/Compiler/gcc-head/intl/configure
--cache-file=./config.cache --build=i686-apple-darwin8
--host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-checking=release
--prefix=/usr/local/ada-4.3 --with-arch=nocona --with-tune=generic
--with-gmp=/opt/local --with-mpfr=/opt/local --enable-languages=c,ada
--program-transform-name=s,y,y,
--srcdir=/Users/drew/Developer/Compiler/gcc-head/intl --with-build-libsubdir=.
--enable-werror-always
## - ##
## Platform. ##
## - ##
hostname = MacBookPro15.local
uname -m = i386
uname -r = 8.8.1
uname -s = Darwin
uname -v = Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006;
root:xnu-792.13.8.obj~1/RELEASE_I386
/usr/bin/uname -p = i386
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = Mach kernel version:
Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006;
root:xnu-792.13.8.obj~1/RELEASE_I386
Kernel configured for up to 2 processors.
2 processors are physically available.
2 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1
Primary memory available: 1.00 gigabytes
Default processor set: 81 tasks, 255 threads, 2 processors
Load average: 3.45, Mach factor: 0.31
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
Information about the failure:
configure:2092: /Users/drew/Developer/Compiler/gcc-head/build/./prev-gcc/xgcc
-B/Users/drew/Developer/Compiler/gcc-head/build/./prev-gcc/
-B/usr/local/ada-4.3/i686-apple-darwin8/bin/ -V /dev/null 5
xgcc: '-V' must come at the start of the command line
configure:2095: $? = 1
configure:2118: checking for C compiler default output file name
configure:2121: /Users/drew/Developer/Compiler/gcc-head/build/./prev-gcc/xgcc
-B/Users/drew/Developer/Compiler/gcc-head/build/./prev-gcc/
-B/usr/local/ada-4.3/i686-apple-darwin8/bin/ -O2 -g -fomit-frame-pointer
conftest.c 5
ERROR: No debug map or DWARF data was found to link.configure:2124: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2163: error: C compiler cannot create executables
See `config.log' for more details.
--
Summary: No debug symbols when compiling stage2 compiler with -O2
-g
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: awreynolds at mac dot com
GCC build triplet: i686-apple-darwin8
GCC host triplet: i686-apple-darwin8
GCC target triplet: i686-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29747
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #2 from kkojima at gcc dot gnu dot org 2006-11-07 02:37 ---
I've attached a reduced test case which fails also on the cross compiler
with -O2:
foo.c:69: error: insn does not satisfy its constraints:
(insn 232 235 233 9 (set (reg:SI 147 t)
(eq:SI (reg:SI 8 r8 [orig:169 diff ] [169])
(const_int 1 [0x1]))) 1 {cmpeqsi_t} (nil)
(nil))
The .greg dump for it has a cbranchdi4_i insn
(jump_insn:HI 61 222 155 8 (parallel [
(set (pc)
(if_then_else (eq (reg/v:DI 8 r8 [orig:169 diff ] [169])
(reg:DI 1 r1))
(label_ref:SI 82)
(pc)))
(clobber (scratch:SI))
(clobber (reg:SI 147 t))
]) 6 {cbranchdi4_i} (nil)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)))
which is transformed to insns
(insn 232 235 233 9 (set (reg:SI 147 t)
(eq:SI (reg:SI 8 r8 [orig:169 diff ] [169])
(const_int 1 [0x1]))) 1 {cmpeqsi_t} (nil)
(nil))
(jump_insn 233 232 237 9 (set (pc)
(if_then_else (ne (reg:SI 147 t)
(const_int 0 [0x0]))
(label_ref 82)
(pc))) 207 {branch_true} (nil)
(expr_list:REG_BR_PROB (const_int 1 [0x2710])
(nil)))
at .flow2. With the change of cbranchdi4_i insn_and_split like as
--- ORIG/trunk/gcc/config/sh/sh.md 2006-11-05 10:02:45.0 +0900
+++ LOCAL/trunk/gcc/config/sh/sh.md 2006-11-07 09:45:27.0 +0900
@@ -713,7 +713,7 @@
(define_insn_and_split cbranchdi4_i
[(set (pc)
(if_then_else (match_operator 0 comparison_operator
- [(match_operand:DI 1 arith_operand r,r)
+ [(match_operand:DI 1 arith_operand r,z)
(match_operand:DI 2 arith_operand rN,i)])
(label_ref (match_operand 3 ))
(pc)))
the reduced test case doesn't fail but the original ifcvt.c fails
with -O2:
../../TMP/trunk/gcc/ifcvt.c:1036: error: unable to find a register to spill in
class 'R0_REGS'
../../TMP/trunk/gcc/ifcvt.c:1036: error: this is the insn:
(jump_insn:HI 324 339 655 42 ../../TMP/trunk/gcc/ifcvt.c:977 (parallel [
(set (pc)
(if_then_else (eq (reg/v:DI 172 [ diff ])
(const_int 1 [0x1]))
(label_ref:SI 345)
(pc)))
(clobber (scratch:SI))
(clobber (reg:SI 147 t))
]) 6 {cbranchdi4_i} (nil)
(expr_list:REG_UNUSED (reg:SI 147 t)
(expr_list:REG_UNUSED (scratch:SI)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)
../../TMP/trunk/gcc/ifcvt.c:1036: internal compiler error: in spill_failure, at
reload1.c:1938
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
[Bug bootstrap/29747] No debug symbols when compiling stage2 compiler with -O2 -g
--- Comment #1 from awreynolds at mac dot com 2006-11-07 02:38 --- Created an attachment (id=12557) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12557action=view) intl/config.log Stage 2 configure of intl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29747
[Bug target/29746] gcc fails to bootstrap on sh4-*-linux-gnu
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-11-07 02:39 --- Created an attachment (id=12558) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12558action=view) a reduced test case for the spill failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29746
