[Bug c++/41187] g++.dg/debug/dwarf2/namespace-1.C failed on Linux/ia64
--- Comment #7 from dodji at gcc dot gnu dot org 2009-08-30 07:26 --- Subject: Bug 41187 Author: dodji Date: Sun Aug 30 07:26:29 2009 New Revision: 151223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151223 Log: Fix c++/41187 gcc/testsuite/ChangeLog: PR c++/41187 * g++.dg/debug/dwarf2/namespace-1.C: Use a loosier regexp to take ia64 assembly comments syntax in account. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/namespace-1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41187
[Bug c++/41187] g++.dg/debug/dwarf2/namespace-1.C failed on Linux/ia64
--- Comment #8 from dodji at gcc dot gnu dot org 2009-08-30 07:44 --- Fixed in trunk. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41187
[Bug fortran/37425] Fortran 2003: GENERIC bindings as operators
--- Comment #5 from domob at gcc dot gnu dot org 2009-08-30 08:26 --- Subject: Bug 37425 Author: domob Date: Sun Aug 30 08:26:38 2009 New Revision: 151224 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151224 Log: 2009-08-30 Daniel Kraft PR fortran/37425 * dump-parse-tree.c (show_typebound_proc): Renamed from `show_typebound' and accept gfc_typebound_proc and name instead of the symtree, needed for intrinsic operator output. (show_typebound_symtree): New method calling `show_typebound_proc'. (show_f2k_derived): Output type-bound operators also. (show_symbol): Moved output of `Procedure bindings:' label to `show_f2k_derived'. * gfortran.texi (Fortran 2003 status): Mention support of array-constructors with explicit type specification, type-bound procedures/operators, type extension, ABSTRACT types and DEFERRED. Link to Fortran 2003 wiki page. (Fortran 2008 status): Fix typo. Link to Fortran 2008 wiki page. * gfc-internals.texi (Type-bound Procedures): Document the new members/attributes of gfc_expr.value.compcall used for type-bound operators. (Type-bound Operators): New section documenting their internals. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfc-internals.texi trunk/gcc/fortran/gfortran.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425
[Bug middle-end/39832] [4.4/4.5 Regression] program built by x86_64-pc-mingw32-g++ run crash, maybe for _Unwind_SjLj_Unregister or __dyn_tls_dtor
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-08-30 08:27 --- (In reply to comment #7) > x86_64-pc-mingw32 is not a primary or secondary platform, moving to P4. > Please restore to P3 if this also appears on i686-mingw32 or another > primary or secondary platform. > Could you please re-test your failure. It seems to be a duplicate of PR/41184. It is fix on trunk and on 4.4.x branch. Cheers, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39832
[Bug fortran/37425] Fortran 2003: GENERIC bindings as operators
--- Comment #6 from domob at gcc dot gnu dot org 2009-08-30 08:30 --- This is fully implemented now (except some side-issues which have their own PRs, like PR 41177 and PR 41178), closing. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425
[Bug other/38920] dw2 exceptions don't work.
--- Comment #11 from ktietz at gcc dot gnu dot org 2009-08-30 08:33 --- (In reply to comment #8) > (In reply to comment #7) > > AFAICT DW2 unwind has never worked on x86_64-mingw32, which is why Kai made > > sjlj the default EH model for that target. > > http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00273.html > > ok, with sjlj and shared libgcc exceptions seem to work across dlls. > This is right, that dw2 exception handling doesn't work for x64. As the x86 is absolutely incompatible to the x64 exception handling, there is the support of SEH2 unwind-data to be added. I begun already with support on gas to generate the pdata/xdata data by pseudo-opcodes. I plan to support this feature for 4.6.x (and maybe a 4.5.x). So for now, just sjlj exception handling is possible for x64 windows. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug driver/39356] assembler isn't called
--- Comment #17 from ktietz at gcc dot gnu dot org 2009-08-30 08:35 --- (In reply to comment #16) > (In reply to comment #15) > > Is there a chance that we get this fixed soon? > > > > Rainer > > > > Well, I would like to fix this. Better now then later. But I couldn't find the > real reason for this issue. The patch above solved the problem on 4.4.0 branch > some time ago, but now it seems to be a different issue. But AFAICT is is > related to chkstk/alloca here. > > Cheers, > Kai > Could you please test if issue still exist for trunk and current 4.4 branch. It could be a duplicate of PR/41184. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug c++/41153] ICE in building Qt4 src/core
--- Comment #3 from t7 at gmail dot com 2009-08-30 09:43 --- Only encountered with c++ code. -- t7 at gmail dot com changed: What|Removed |Added GCC build triplet||i686-linux GCC host triplet|x86_64 |x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41153
[Bug fortran/39626] Fortran 2008: Implement BLOCK construct
--- Comment #2 from domob at gcc dot gnu dot org 2009-08-30 10:00 --- I'm not sure it needs really that much changes... After all, the semantics can probably be simulated completely via replacing the BLOCK-constructs with contained procedures that are called where the BLOCK originally was? That's of course not a nice implementation and I do not think we should actually do this, but I believe that there needs not be that much change -- I'll work on this and try to find out a good way. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-04-03 16:43:38 |2009-08-30 10:00:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39626
[Bug regression/41188] New: move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
This bug was discovered while adapting MSP430 port for GCC 4.x and is
persistent at least in both GCC 4.2.4 and 4.3.4.
This description consists of a problem description, a detailed reason analysis
pointing out exact GCC functions, and a proposed solution.
---
1. Problem
Compiling the following code for MSP430 (16-bit RISC) with maximum optimization
(-O2) causes an "internal error int redirect_branch_edge()" failure:
-
for (volatile long t = 0; t < 1024; t++) ;
-
The problem is related to the "cbranchsi" instruction, that clobbers one of
compared registers. Here is a quote from MD file:
-
(define_insn "*cbranchsi_others"
[(parallel [(set (pc)
(if_then_else (match_operator:SI 1 "inequality_operator"
[(match_operand:SI 2 "register_operand" "r")
(match_operand:SI 3 "general_operand" "rmi")])
(label_ref (match_operand 0 "" ""))
(pc)))
(clobber (match_dup 2))])] ;<== Attention! clobber (match_dup) !!!
-
2. Reason
2.1 The "*cbranchsi_others" INSN clobbers one of its arguments [clobber
(match_dup 2)]. During loop optimization, the source register (operand 2) gets
changed, while the register reference in CLOBBER attribute does not. After such
change, instruction is no longer recognizable according to machine decsription,
and the compilation fails.
2.2 The move_invariant_reg() function in loop-invariant.c performs register
renaming based on "register use lists". When the "cbranchsi_others" instruction
gets scanned for register uses, the CLOBBER use does not get recorded, and
thus, does not get changed later, resulting in an erroneous INSN pattern:
- Before move_invariant_reg() (insn_invalid_p(insn) = 0)
-
(parallel [
(set (pc)
(if_then_else (ge:SI (reg:SI 30)
(reg:SI 24 [ j.1 ]))
(label_ref:HI 34)
(pc)))
(clobber:SI (reg:SI 30))
])
- After move_invariant_reg() (insn_invalid_p(insn) = 0)
-
(parallel [
(set (pc)
(if_then_else (ge:SI (reg:SI31) <= CHANGED 30 to 31
(reg:SI 24 [ j.1 ]))
(label_ref:HI 34)
(pc)))
(clobber:SI (reg:SI 30)) <=== NOT CHANGED 30 TO 31
])
-
Obviously, the modification makes the instruction invalid, as it uses and
clobbers different registers, and thus, no existing INSN pattern matches it.
2.3 The "register use lists" are built using the record_uses() function in
loop-invariant.c based on DF use records. The record_uses() function considers
DF_INSN_USES() and DF_INSN_EQ_USES() lists (only DF_INSN_USES in gcc 4.2.4).
CLOBBERed registers are put into DF_INSN_DEFS() list, that is not considered in
record_uses(). That way, a CLOBBER attribute remains unchanged, when used
registers are renamed.
2.4 The df_defs_record() function in df-scan.c places both SET and CLOBBER
references into DF_INSN_DEFS() list:
if (code == SET || code == CLOBBER)
{
//...
df_def_record_1 (collection_rec, x, bb, insn, clobber_flags);
}
2.5 Summary. Invariant moving optimization in loop-invariant.c disrupts INSN
patterns that USE and CLOBBER the same register, making them invalid.
-
3. Proposed solution.
3.1. For my needs, I have patched loop-invariant.c by adding the following
function to explicitly record all CLOBBER references from INSN that match USE
references:
static void record_clobber_uses_workaround(rtx insn, struct invariant *inv,
struct df_ref *use)
{
rtx pat = PATTERN(insn);
if (GET_CODE(pat) == PARALLEL)
{
int len = XVECLEN(pat, 0);
int idx = 0;
for (idx = 0; idx < len; idx++)
{
rtx subexp = XVECEXP(pat, 0, idx);
if (GET_CODE(subexp) == CLOBBER)
{
if (XEXP (subexp, 0) == *DF_REF_REAL_LOC (use))
record_use (inv->def, &XEXP (subexp,
0), DF_REF_INSN (use));
}
}
}
}
The record_uses() function got patched accordingly:
if (inv)
+ {
record_use (inv->def, DF_REF_REAL_LOC (use), DF_REF_INSN (use));
+ record_clobber_uses_workaround(insn, inv, use);
+ }
3.2. I would recommend re-analyzing the more common case, when a single
instruction uses and defines the same register, and decide, whether loop
optimizations in loop-invariant.c should move such register. The bug does not
seem to affect most architectures, however, specific INSN patterns, as
described above, do trigger it. Maybe, a common function returning the list of
all "match_dup"-ed references for a given INSN and an operand to detect such
cases in a uniform way.
--
Summary: move_inva
[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #1 from shcherbakov at daad-alumni dot de 2009-08-30 10:10 --- A misprint in the description: After move_invariant_reg() the insn_invalid_p(insn) returns 1 meaning that the INSN is no longer valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188
[Bug regression/41189] New: move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
This bug was discovered while adapting MSP430 port for GCC 4.x and is
persistent at least in both GCC 4.2.4 and 4.3.4.
This description consists of a problem description, a detailed reason analysis
pointing out exact GCC functions, and a proposed solution.
---
1. Problem
Compiling the following code for MSP430 (16-bit RISC) with maximum optimization
(-O2) causes an "internal error int redirect_branch_edge()" failure:
-
for (volatile long t = 0; t < 1024; t++) ;
-
The problem is related to the "cbranchsi" instruction, that clobbers one of
compared registers. Here is a quote from MD file:
-
(define_insn "*cbranchsi_others"
[(parallel [(set (pc)
(if_then_else (match_operator:SI 1 "inequality_operator"
[(match_operand:SI 2 "register_operand" "r")
(match_operand:SI 3 "general_operand" "rmi")])
(label_ref (match_operand 0 "" ""))
(pc)))
(clobber (match_dup 2))])] ;<== Attention! clobber (match_dup) !!!
-
2. Reason
2.1 The "*cbranchsi_others" INSN clobbers one of its arguments [clobber
(match_dup 2)]. During loop optimization, the source register (operand 2) gets
changed, while the register reference in CLOBBER attribute does not. After such
change, instruction is no longer recognizable according to machine decsription,
and the compilation fails.
2.2 The move_invariant_reg() function in loop-invariant.c performs register
renaming based on "register use lists". When the "cbranchsi_others" instruction
gets scanned for register uses, the CLOBBER use does not get recorded, and
thus, does not get changed later, resulting in an erroneous INSN pattern:
- Before move_invariant_reg() (insn_invalid_p(insn) = 0)
-
(parallel [
(set (pc)
(if_then_else (ge:SI (reg:SI 30)
(reg:SI 24 [ j.1 ]))
(label_ref:HI 34)
(pc)))
(clobber:SI (reg:SI 30))
])
- After move_invariant_reg() (insn_invalid_p(insn) = 0)
-
(parallel [
(set (pc)
(if_then_else (ge:SI (reg:SI31) <= CHANGED 30 to 31
(reg:SI 24 [ j.1 ]))
(label_ref:HI 34)
(pc)))
(clobber:SI (reg:SI 30)) <=== NOT CHANGED 30 TO 31
])
-
Obviously, the modification makes the instruction invalid, as it uses and
clobbers different registers, and thus, no existing INSN pattern matches it.
2.3 The "register use lists" are built using the record_uses() function in
loop-invariant.c based on DF use records. The record_uses() function considers
DF_INSN_USES() and DF_INSN_EQ_USES() lists (only DF_INSN_USES in gcc 4.2.4).
CLOBBERed registers are put into DF_INSN_DEFS() list, that is not considered in
record_uses(). That way, a CLOBBER attribute remains unchanged, when used
registers are renamed.
2.4 The df_defs_record() function in df-scan.c places both SET and CLOBBER
references into DF_INSN_DEFS() list:
if (code == SET || code == CLOBBER)
{
//...
df_def_record_1 (collection_rec, x, bb, insn, clobber_flags);
}
2.5 Summary. Invariant moving optimization in loop-invariant.c disrupts INSN
patterns that USE and CLOBBER the same register, making them invalid.
-
3. Proposed solution.
3.1. For my needs, I have patched loop-invariant.c by adding the following
function to explicitly record all CLOBBER references from INSN that match USE
references:
static void record_clobber_uses_workaround(rtx insn, struct invariant *inv,
struct df_ref *use)
{
rtx pat = PATTERN(insn);
if (GET_CODE(pat) == PARALLEL)
{
int len = XVECLEN(pat, 0);
int idx = 0;
for (idx = 0; idx < len; idx++)
{
rtx subexp = XVECEXP(pat, 0, idx);
if (GET_CODE(subexp) == CLOBBER)
{
if (XEXP (subexp, 0) == *DF_REF_REAL_LOC (use))
record_use (inv->def, &XEXP (subexp,
0), DF_REF_INSN (use));
}
}
}
}
The record_uses() function got patched accordingly:
if (inv)
+ {
record_use (inv->def, DF_REF_REAL_LOC (use), DF_REF_INSN (use));
+ record_clobber_uses_workaround(insn, inv, use);
+ }
3.2. I would recommend re-analyzing the more common case, when a single
instruction uses and defines the same register, and decide, whether loop
optimizations in loop-invariant.c should move such register. The bug does not
seem to affect most architectures, however, specific INSN patterns, as
described above, do trigger it. Maybe, a common function returning the list of
all "match_dup"-ed references for a given INSN and an operand to detect such
cases in a uniform way.
--
Summary: move_inva
[Bug regression/41190] New: move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
This bug was discovered while adapting MSP430 port for GCC 4.x and is
persistent at least in both GCC 4.2.4 and 4.3.4.
This description consists of a problem description, a detailed reason analysis
pointing out exact GCC functions, and a proposed solution.
---
1. Problem
Compiling the following code for MSP430 (16-bit RISC) with maximum optimization
(-O2) causes an "internal error int redirect_branch_edge()" failure:
-
for (volatile long t = 0; t < 1024; t++) ;
-
The problem is related to the "cbranchsi" instruction, that clobbers one of
compared registers. Here is a quote from MD file:
-
(define_insn "*cbranchsi_others"
[(parallel [(set (pc)
(if_then_else (match_operator:SI 1 "inequality_operator"
[(match_operand:SI 2 "register_operand" "r")
(match_operand:SI 3 "general_operand" "rmi")])
(label_ref (match_operand 0 "" ""))
(pc)))
(clobber (match_dup 2))])] ;<== Attention! clobber (match_dup) !!!
-
2. Reason
2.1 The "*cbranchsi_others" INSN clobbers one of its arguments [clobber
(match_dup 2)]. During loop optimization, the source register (operand 2) gets
changed, while the register reference in CLOBBER attribute does not. After such
change, instruction is no longer recognizable according to machine decsription,
and the compilation fails.
2.2 The move_invariant_reg() function in loop-invariant.c performs register
renaming based on "register use lists". When the "cbranchsi_others" instruction
gets scanned for register uses, the CLOBBER use does not get recorded, and
thus, does not get changed later, resulting in an erroneous INSN pattern:
- Before move_invariant_reg() (insn_invalid_p(insn) = 0)
-
(parallel [
(set (pc)
(if_then_else (ge:SI (reg:SI 30)
(reg:SI 24 [ j.1 ]))
(label_ref:HI 34)
(pc)))
(clobber:SI (reg:SI 30))
])
- After move_invariant_reg() (insn_invalid_p(insn) = 0)
-
(parallel [
(set (pc)
(if_then_else (ge:SI (reg:SI31) <= CHANGED 30 to 31
(reg:SI 24 [ j.1 ]))
(label_ref:HI 34)
(pc)))
(clobber:SI (reg:SI 30)) <=== NOT CHANGED 30 TO 31
])
-
Obviously, the modification makes the instruction invalid, as it uses and
clobbers different registers, and thus, no existing INSN pattern matches it.
2.3 The "register use lists" are built using the record_uses() function in
loop-invariant.c based on DF use records. The record_uses() function considers
DF_INSN_USES() and DF_INSN_EQ_USES() lists (only DF_INSN_USES in gcc 4.2.4).
CLOBBERed registers are put into DF_INSN_DEFS() list, that is not considered in
record_uses(). That way, a CLOBBER attribute remains unchanged, when used
registers are renamed.
2.4 The df_defs_record() function in df-scan.c places both SET and CLOBBER
references into DF_INSN_DEFS() list:
if (code == SET || code == CLOBBER)
{
//...
df_def_record_1 (collection_rec, x, bb, insn, clobber_flags);
}
2.5 Summary. Invariant moving optimization in loop-invariant.c disrupts INSN
patterns that USE and CLOBBER the same register, making them invalid.
-
3. Proposed solution.
3.1. For my needs, I have patched loop-invariant.c by adding the following
function to explicitly record all CLOBBER references from INSN that match USE
references:
static void record_clobber_uses_workaround(rtx insn, struct invariant *inv,
struct df_ref *use)
{
rtx pat = PATTERN(insn);
if (GET_CODE(pat) == PARALLEL)
{
int len = XVECLEN(pat, 0);
int idx = 0;
for (idx = 0; idx < len; idx++)
{
rtx subexp = XVECEXP(pat, 0, idx);
if (GET_CODE(subexp) == CLOBBER)
{
if (XEXP (subexp, 0) == *DF_REF_REAL_LOC (use))
record_use (inv->def, &XEXP (subexp,
0), DF_REF_INSN (use));
}
}
}
}
The record_uses() function got patched accordingly:
if (inv)
+ {
record_use (inv->def, DF_REF_REAL_LOC (use), DF_REF_INSN (use));
+ record_clobber_uses_workaround(insn, inv, use);
+ }
3.2. I would recommend re-analyzing the more common case, when a single
instruction uses and defines the same register, and decide, whether loop
optimizations in loop-invariant.c should move such register. The bug does not
seem to affect most architectures, however, specific INSN patterns, as
described above, do trigger it. Maybe, a common function returning the list of
all "match_dup"-ed references for a given INSN and an operand to detect such
cases in a uniform way.
--
Summary: move_inva
[Bug regression/41191] New: move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
This bug was discovered while adapting MSP430 port for GCC 4.x and is
persistent at least in both GCC 4.2.4 and 4.3.4.
This description consists of a problem description, a detailed reason analysis
pointing out exact GCC functions, and a proposed solution.
---
1. Problem
Compiling the following code for MSP430 (16-bit RISC) with maximum optimization
(-O2) causes an "internal error int redirect_branch_edge()" failure:
-
for (volatile long t = 0; t < 1024; t++) ;
-
The problem is related to the "cbranchsi" instruction, that clobbers one of
compared registers. Here is a quote from MD file:
-
(define_insn "*cbranchsi_others"
[(parallel [(set (pc)
(if_then_else (match_operator:SI 1 "inequality_operator"
[(match_operand:SI 2 "register_operand" "r")
(match_operand:SI 3 "general_operand" "rmi")])
(label_ref (match_operand 0 "" ""))
(pc)))
(clobber (match_dup 2))])] ;<== Attention! clobber (match_dup) !!!
-
2. Reason
2.1 The "*cbranchsi_others" INSN clobbers one of its arguments [clobber
(match_dup 2)]. During loop optimization, the source register (operand 2) gets
changed, while the register reference in CLOBBER attribute does not. After such
change, instruction is no longer recognizable according to machine decsription,
and the compilation fails.
2.2 The move_invariant_reg() function in loop-invariant.c performs register
renaming based on "register use lists". When the "cbranchsi_others" instruction
gets scanned for register uses, the CLOBBER use does not get recorded, and
thus, does not get changed later, resulting in an erroneous INSN pattern:
- Before move_invariant_reg() (insn_invalid_p(insn) = 0)
-
(parallel [
(set (pc)
(if_then_else (ge:SI (reg:SI 30)
(reg:SI 24 [ j.1 ]))
(label_ref:HI 34)
(pc)))
(clobber:SI (reg:SI 30))
])
- After move_invariant_reg() (insn_invalid_p(insn) = 0)
-
(parallel [
(set (pc)
(if_then_else (ge:SI (reg:SI31) <= CHANGED 30 to 31
(reg:SI 24 [ j.1 ]))
(label_ref:HI 34)
(pc)))
(clobber:SI (reg:SI 30)) <=== NOT CHANGED 30 TO 31
])
-
Obviously, the modification makes the instruction invalid, as it uses and
clobbers different registers, and thus, no existing INSN pattern matches it.
2.3 The "register use lists" are built using the record_uses() function in
loop-invariant.c based on DF use records. The record_uses() function considers
DF_INSN_USES() and DF_INSN_EQ_USES() lists (only DF_INSN_USES in gcc 4.2.4).
CLOBBERed registers are put into DF_INSN_DEFS() list, that is not considered in
record_uses(). That way, a CLOBBER attribute remains unchanged, when used
registers are renamed.
2.4 The df_defs_record() function in df-scan.c places both SET and CLOBBER
references into DF_INSN_DEFS() list:
if (code == SET || code == CLOBBER)
{
//...
df_def_record_1 (collection_rec, x, bb, insn, clobber_flags);
}
2.5 Summary. Invariant moving optimization in loop-invariant.c disrupts INSN
patterns that USE and CLOBBER the same register, making them invalid.
-
3. Proposed solution.
3.1. For my needs, I have patched loop-invariant.c by adding the following
function to explicitly record all CLOBBER references from INSN that match USE
references:
static void record_clobber_uses_workaround(rtx insn, struct invariant *inv,
struct df_ref *use)
{
rtx pat = PATTERN(insn);
if (GET_CODE(pat) == PARALLEL)
{
int len = XVECLEN(pat, 0);
int idx = 0;
for (idx = 0; idx < len; idx++)
{
rtx subexp = XVECEXP(pat, 0, idx);
if (GET_CODE(subexp) == CLOBBER)
{
if (XEXP (subexp, 0) == *DF_REF_REAL_LOC (use))
record_use (inv->def, &XEXP (subexp,
0), DF_REF_INSN (use));
}
}
}
}
The record_uses() function got patched accordingly:
if (inv)
+ {
record_use (inv->def, DF_REF_REAL_LOC (use), DF_REF_INSN (use));
+ record_clobber_uses_workaround(insn, inv, use);
+ }
3.2. I would recommend re-analyzing the more common case, when a single
instruction uses and defines the same register, and decide, whether loop
optimizations in loop-invariant.c should move such register. The bug does not
seem to affect most architectures, however, specific INSN patterns, as
described above, do trigger it. Maybe, a common function returning the list of
all "match_dup"-ed references for a given INSN and an operand to detect such
cases in a uniform way.
--
Summary: move_inva
[Bug rtl-optimization/41191] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #1 from shcherbakov at daad-alumni dot de 2009-08-30 10:13 --- *** This bug has been marked as a duplicate of 41188 *** -- shcherbakov at daad-alumni dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41191
[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #2 from shcherbakov at daad-alumni dot de 2009-08-30 10:13 --- *** Bug 41191 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188
[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #3 from shcherbakov at daad-alumni dot de 2009-08-30 10:14 --- *** Bug 41190 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188
[Bug rtl-optimization/41190] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #1 from shcherbakov at daad-alumni dot de 2009-08-30 10:14 --- *** This bug has been marked as a duplicate of 41188 *** -- shcherbakov at daad-alumni dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41190
[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #4 from shcherbakov at daad-alumni dot de 2009-08-30 10:14 --- *** Bug 41189 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188
[Bug regression/41189] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #1 from shcherbakov at daad-alumni dot de 2009-08-30 10:14 --- *** This bug has been marked as a duplicate of 41188 *** -- shcherbakov at daad-alumni dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41189
[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #20 from rguenther at suse dot de 2009-08-30 11:25 --- Subject: Re: FAIL: ext/pb_ds/regression/hash_data_map_rand.cc On Sat, 29 Aug 2009, ubizjak at gmail dot com wrote: > --- Comment #19 from ubizjak at gmail dot com 2009-08-29 19:52 --- > Sigh, the patch doesn't fix alpha failure :( It also doensn't fix reliably the failure on i?86. Is your alpha failure on lto branch or on trunk? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug tree-optimization/41186] VN doesn't look through non-aliasing by offset memcpy
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-30 11:52 --- Subject: Bug 41186 Author: rguenth Date: Sun Aug 30 11:52:13 2009 New Revision: 151226 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151226 Log: 2009-08-30 Richard Guenther PR tree-optimization/41186 * tree-ssa-alias.c (ptr_deref_may_alias_ref_p): Remove. (ao_ref_init_from_ptr_and_size): New function. (ref_maybe_used_by_call_p_1): Be more precise tracking used ranges for builtin functions. (ref_maybe_used_by_call_p): Adjust. (call_may_clobber_ref_p_1): Be more precise tracking clobbered ranges for builtin functions. * tree-ssa-alias.h (ao_ref_init_from_ptr_and_size): Declare. * g++.dg/torture/pr41186.C: New testcase. * g++.dg/tree-ssa/pr41186.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/torture/pr41186.C trunk/gcc/testsuite/g++.dg/tree-ssa/pr41186.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41186
[Bug middle-end/39832] [4.4/4.5 Regression] program built by x86_64-pc-mingw32-g++ run crash, maybe for _Unwind_SjLj_Unregister or __dyn_tls_dtor
--- Comment #9 from drangon dot mail at gmail dot com 2009-08-30 13:53 --- yes, the issue should be fixed, wxWidgets works fine now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39832
[Bug ada/41122] libada multilib string parsing error
--- Comment #5 from bonzini at gnu dot org 2009-08-30 14:26 --- Subject: Bug 41122 Author: bonzini Date: Sun Aug 30 14:26:37 2009 New Revision: 151227 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151227 Log: 2009-08-30 Paolo Bonzini PR ada/41122 * configure.ac: Add AC_PROG_AWK. Remove useless duplicate call to AC_PROG_CC. * configure: Regenerate. * Makefile.in: Substitute AWK. Modified: trunk/libada/ChangeLog trunk/libada/Makefile.in trunk/libada/configure trunk/libada/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
[Bug ada/41122] libada multilib string parsing error
--- Comment #6 from bonzini at gnu dot org 2009-08-30 14:35 --- committed to trunk, 4.4 will follow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41122
[Bug fortran/41192] New: NAMELIST input with just a comment ("&NAME ! comment \") fails
If just a comment is in the NAMELIST input the READ fails
VERSION:
gfortran -dumpversion
GNU Fortran (GCC) 4.3.2 20080827 (beta) 2
Copyright (C) 2008 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
EXECUTION:
./bugA
===> FOR:
&CMD
I= 1,
J= 2,
K= 3, /
===> FOR: I=10 , J=20 K=30 ! change all three values
&CMD
I= 10,
J= 20,
K= 30, /
===> FOR:
&CMD
I= 10,
J= 20,
K= 30, /
===> FOR: ! change no values
E-R-R-O-R: PROCESSING COMMAND LINE, IOSTAT=5010
Cannot match namelist object name change
&CMD
I= 10,
J= 20,
K= 30, /
CODE:
cat bugA.f90
program cmdline
! comment by itself causes error in gfortran
call process(' ')
call process('I=10 , J=20 K=30 ! change all three values')
call process(' ')
call process('! change no values') ! CAUSES ERROR IN GFORTRAN, NOT G95
end program cmdline
!===
!()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()
!===
subroutine process(string)
implicit none
character(len=*) :: string
character(len=132) :: lines(3)
character(len=255) :: message
INTEGER :: I=1,J=2,K=3
integer ios
NAMELIST /CMD/ I,J,K
save cmd
lines(1)='&cmd'
lines(2)=string
lines(3)='/'
WRITE(*,'(80(''=''))')
write(*,*)'===> FOR: ',string(:len_trim(string))
READ(lines,NML=CMD,IOSTAT=ios,IOMSG=message)
if(ios.ne.0)then
write(*,*)'E-R-R-O-R: PROCESSING COMMAND LINE, IOSTAT=',IOS
write(*,*)message
endif
write(*,NML=CMD)
return
end subroutine process
!===
!()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()()
!===
--
Summary: NAMELIST input with just a comment ("&NAME ! comment \")
fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: urbanjost at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug c/40977] Problem with code like this: res = ((uint64_t)resh << 32) | resl;
--- Comment #2 from ami_stuff at o2 dot pl 2009-08-30 16:57 --- With -m68060 -O1 -fomit-frame-pointer: GCC 4.1.2/GCC 4.2.5: #NO_APP .text .even .globl _MUL64 _MUL64: movm.l #0x3e00,-(sp) move.l 28(sp),a1 move.l 24(sp),a0 #APP | Inlined umul_ppmm move.l a0,d0 move.l a1,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d6 add.l d1,d0 move.l d0,d5 #NO_APP tst.l a0 jbge L2 sub.l a1,d5 L2: tst.l a1 jbge L4 sub.l a0,d5 L4: move.l d5,d0 clr.l d1 or.l d6,d1 movm.l (sp)+,#0x7c rts GCC 4.3.2: #NO_APP .text .even .globl _MUL64 _MUL64: movem.l #16128,-(sp) move.l 32(sp),d5 move.l 28(sp),a0 #APP ;# 45 "test5.c" 1 | Inlined umul_ppmm move.l a0,d0 move.l d5,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d7 add.l d1,d0 move.l d0,a1 #NO_APP tst.l a0 jge L2 sub.l d5,a1 L2: tst.l d5 jge L3 sub.l a0,a1 L3: move.l a1,d1 clr.l d2 or.l d7,d2 move.l d1,d0 move.l d2,d1 movem.l (sp)+,#252 rts GCC 4.4.2: #NO_APP .text .even .globl _MUL64 _MUL64: movem.l #16128,-(sp) move.l 32(sp),a0 move.l 28(sp),a1 #APP ;# 45 "test5.c" 1 | Inlined umul_ppmm move.l a1,d0 move.l a0,d1 move.l d0,d2 swapd0 move.l d1,d3 swapd1 move.w d2,d4 mulud3,d4 mulud1,d2 mulud0,d3 mulud0,d1 move.l d4,d0 eor.w d0,d0 swapd0 add.l d0,d2 add.l d3,d2 jcc 1f add.l #65536,d1 1: swapd2 moveq #0,d0 move.w d2,d0 move.w d4,d2 move.l d2,d6 add.l d1,d0 move.l d0,d5 #NO_APP tst.l a1 jge L2 sub.l a0,d5 L2: tst.l a0 jge L3 sub.l a1,d5 L3: move.l d5,d0 clr.l d1 move.l d0,d2 move.l d1,d3 or.l d6,d3 move.l d2,d6 move.l d3,d7 move.l d2,d0 move.l d7,d1 movem.l (sp)+,#252 rts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-08-30 17:34 ---
(In reply to comment #2)
> (In reply to comment #1)
> > These were added by HJ. Either we need to fixinclude stdlib.h or not define
> > these based on a configure test (I guess the former is more robust if
> > ia32intrin.h defines these only if they are not already defined).
> >
>
> fixinclude sounds a good idea, but I don't know how to do it. Or
> I can change ia32inintrin.h by not defining them for mingw.
>
I would vote for guarding the lrotl, lrotr by checks, if they aren't defined
already.
There is an other issue about ia32intrin.h and mingw targets, but I assume,
that it is true for other i386 and x86_64 targets, too. There are the functions
__crc32b, __crc32w, and __crt32d, which are in general just available for a
target that has SSE4.1 enabled (-mcrc). But the inlines aren't guarded and so
the builtins __builtin_ia32_crc32qi (etc) don't have prototypes and so g++ will
throw errors.
The following sample shows the issue pretty well.
t.cc:
#include
int main()
{
return 0;
}
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails
--- Comment #2 from kargl at gcc dot gnu dot org 2009-08-30 17:48 --- (In reply to comment #1) > Thanks for report , I will fix this. > It's not broken. -- steve -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2009-08-30 17:58 ---
Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \") fails
On Sun, Aug 30, 2009 at 05:48:15PM -, kargl at gcc dot gnu dot org wrote:
>
>
> --- Comment #2 from kargl at gcc dot gnu dot org 2009-08-30 17:48 ---
> (In reply to comment #1)
> > Thanks for report , I will fix this.
> >
>
> It's not broken.
>
Here's my analysis, which could be wrong.
>From the Fortran 2003 standard;
10.10.1 Namelist input
Input for a namelist input statement consists of
(1) Optional blanks and namelist comments,
(2) The character & followed immediately by the namelist-group-name
as specified in the NAMELIST statement,
(3) One or more blanks,
(4) A sequence of zero or more name-value subsequences separated
by value separators, and
(5) A slash to terminate the namelist input.
10.10.1.6Namelist Comments
Except within a character literal constant, a "!" character after a
value separator or in the first nonblank position of a namelist input
record initiates a comment.
In Section 10.9, one finds
A value separator is
(1) A comma optionally preceded by one or more contiguous blanks
and optionally followed by one or more contiguous blanks, unless
the decimal edit mode is COMMA, in which case a semicolon is
used in place of the comma,
(2) A slash optionally preceded by one or more contiguous blanks
and optionally followed by one or more contiguous blanks, or
(3) One or more contiguous blanks between two nonblank values or
following the last nonblank value, where a nonblank value is
a constant, an r *c form, or an r * form.
The namelist that appears to be causing an error in gfortran is
&cmd
! change no values
/
The comment does not follow a value separator, so it comes down to
"or in the first nonblank position of a namelist input record initiates
a comment". Now, going back to 10.10.1, the first nonblank position
in a namelist input record would need to come before the &. That is,
the namelist should be
! change no values
&cmd
/
This modification to the program suggests that my reading of the
Standard may be correct (although I have been known to get it wrong).
program cmdline
call process(' ', .false.)
call process('I=10 , J=20 K=30 ! change all three values', .false.)
call process(' ', .false.)
call process('! change no values', .true.) ! CAUSES ERROR IN GFORTRAN, NOT
G95
contains
subroutine process(string, invert)
implicit none
logical :: invert
character(len=*) :: string
character(len=132), save :: lines(3)
character(len=255) :: message
INTEGER :: I=1,J=2,K=3
integer ios
NAMELIST /CMD/ I,J,K
save cmd
if (invert .eqv. .true.) then
lines(2)='&cmd'
lines(1)=string
lines(3)='/'
else
lines(1)='&cmd'
lines(2)=string
lines(3)='/'
end if
READ(lines,NML=CMD,IOSTAT=ios,IOMSG=message)
if(ios.ne.0)then
write(*,*)'E-R-R-O-R: PROCESSING COMMAND LINE, IOSTAT=',IOS
write(*,*)message
endif
write(*,NML=CMD)
end subroutine process
end program cmdline
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-08-30 18:15 --- Strictly speaking, Steve, I think you are correct. I have not finished my review of the standard. This is the first time I have seen namelist used like this for command line input. I suspect because it allows one to try many variations easily it will be a useful quick test tool. The embedded comment seems natural and in our code base we have a comment asking, should we allow '!' as a separator as an extension. We have thought about this issue before. I am going to give it some thinking time before doing anything here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-08-30 17:32
---
Thanks for report , I will fix this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-08-30 17:32:10
date||
Summary|NAMELIST input with just a |NAMELIST input with just a
|comment ("&NAME ! comment |comment ("&NAME ! comment
|\") fails |\") fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug middle-end/41193] New: slow compilation with graphite
after the fix for PR40965, I retested trunk on CP2K. There is one particularly slow compile, for the attached testcase, which goes w/o -fgraphite : 8s w -fgraphite : 371s -ftime-report points at: Graphite loop transforms: 364.61 (98%) usr 0.96 (91%) sys 365.55 (98%) wall full compile line gfortran -fgraphite -c -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ftime-report tmp.f90 with gfortran -v Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ Thread model: posix gcc version 4.5.0 20090830 (experimental) [trunk revision 151229] (GCC) COLLECT_GCC_OPTIONS='-c' '-O2' '-ffast-math' '-funroll-loops' '-ftree-vectorize' '-v' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 tmp.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase tmp.f90 -auxbase tmp -O2 -version -ffast-math -funroll-loops -ftree-vectorize -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/cch50n1i.s GNU Fortran (GCC) version 4.5.0 20090830 (experimental) [trunk revision 151229] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036], GMP version 4.2.2, MPFR version 2.3.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.5.0 20090830 (experimental) [trunk revision 151229] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036], GMP version 4.2.2, MPFR version 2.3.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-c' '-O2' '-ffast-math' '-funroll-loops' '-ftree-vectorize' '-v' as -V -Qy -o tmp.o /tmp/cch50n1i.s GNU assembler version 2.18.50 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1 COMPILER_PATH=/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/:/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/:/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/:/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/:/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/:/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-c' '-O2' '-ffast-math' '-funroll-loops' '-ftree-vectorize' '-v' -- Summary: slow compilation with graphite Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41193
[Bug middle-end/41193] slow compilation with graphite
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-30 18:38 --- Created an attachment (id=18451) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18451&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41193
[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2009-08-30 18:54 ---
Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \") fails
On Sun, Aug 30, 2009 at 06:15:07PM -, jvdelisle at gcc dot gnu dot org
wrote:
>
> Strictly speaking, Steve, I think you are correct.
>
> I have not finished my review of the standard. This is the first time I have
> seen namelist used like this for command line input. I suspect because it
> allows one to try many variations easily it will be a useful quick test tool.
> The embedded comment seems natural and in our code base we have a comment
> asking, should we allow '!' as a separator as an extension. We have thought
> about this issue before.
>
> I am going to give it some thinking time before doing anything here.
>
Allowing a comment within a namelist to be the only entity on
a line seems to be a logical extension to add. But, to claim
that gfortran has an error seems to be erroneous. This extension
should probably issue a warning with -std=f95 or f2003.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug c++/41194] New: __attribute__ ((__gnu_inline__)) yields x86_64-unknown-linux-gnu when compiled with -O0, but not with -O1
Error messages: /tmp/ccgtrVyI.o: In function `Color': /home/chromium/chromium/src/third_party/WebKit/WebCore/platform/ColorData.gperf:254: undefined reference to `findColor(char const*, unsigned int)' /home/chromium/chromium/src/third_party/WebKit/WebCore/platform/ColorData.gperf:254: undefined reference to `findColor(char const*, unsigned int)' collect2: ld returned 1 exit status Command line: g++ -O0 -g Color-stripped.ii Compiler build configuration: ../configure --prefix=/usr --enable-shared \ --enable-languages=c,c++,fortran,objc,obj-c++ \ --enable-threads=posix --mandir=/usr/share/man \ --infodir=/usr/share/info \ --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib \ --libexecdir=/usr/lib --enable-clocale=gnu \ --disable-libstdcxx-pch \ --with-tune=generic The symbols resolve correctly if compiled with "-O1" or if "__attribute__ ((__gnu_inline__))" is removed from function definition. -- Summary: __attribute__ ((__gnu_inline__)) yields x86_64-unknown- linux-gnu when compiled with -O0, but not with -O1 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hdasch at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41194
[Bug c++/41194] __attribute__ ((__gnu_inline__)) yields x86_64-unknown-linux-gnu when compiled with -O0, but not with -O1
--- Comment #1 from hdasch at gmail dot com 2009-08-30 20:25 --- Created an attachment (id=18452) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18452&action=view) Preprocessed test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41194
[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails
--- Comment #6 from urbanjost at comcast dot net 2009-08-31 00:07 ---
Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \") fails
Because of 10.11.3.3-4 I believe (1) of 10.10.1 is intended to mean
"throughout" and not "preceding"; and that
10.10.1 (2) through (5) should then be read as serially defining a NAMELIST
group object. I believe that lines
before &NAME do not have to conform to NAMELIST format at all; and that
anything after the / is ignored, so
it could LOOK like a comment but does not have to. Because of 10.11.3.3 I
think this should be legal:
Anything I like, whatsoever
! something that LOOKS like a comment but is not
&CMD! a comment
! another comment
! and another
/ !whatever, which happens to look like a comment
That is, nothing counts until the line with "^[ *]&NAME" or after "/"
(using regexp syntax) and that anything
beginning with an exclamation not in a string literal is ignored up to and
except for the EOL. So the above
would be completely equivalent to
&CMD
/
I think 10.10.1 item (1) is misleading because the rest of the list defines
a NAMELIST group's allowable content
in order; but that the extraneous blanks are intended to be ignored
throughout except in string constants. I also think
strings MUST be quoted on input; and the gfortran behavior for
C=NAME
when C refers to a character variable is acting suspicously.
PS: Combining NAMELIST with GET_COMMAND_ARGUMENTS makes for a REALLY
flexible command line
parser
(http://home.comcast.net/~urbanjost/CLONE/KRACKEN/namelist/index.html). The
page is a work in
progress; I was trying to show how a single program could use NAMELIST
to have a consistent syntax for
command line arguments, a configuration file, interactive parameter
input, and file-based input; it is very promising
because of it's simplicity and consistency, but I've hit quirks
between compilers that has made me suddenly far more
careful in my reading of the f2003 standard's sections on NAMELIST;
and I'm convinced this not a request for an
extension -- but I've been wrong before too.
!!10.11.3.3Namelist group object list items
!!
!! 1 The name-value subsequences are evaluated serially, in left-to-right
order. A namelist group object designator
!!may appear in more than one name-value sequence.
!!
!! 2 When the name in the input record represents an array variable or a
variable of derived type, the effect is as
!!if the variable represented were expanded into a sequence of scalar
list items, in the same way that formatted
!!input/output list items are expanded (9.6.3). Each input value
following the equals shall then be acceptable to
!!format specifications for the type of the list item in the
corresponding position in the expanded sequence, except
!!as noted in this subclause. The number of values following the equals
shall not exceed the number of list items
!!in the expanded sequence, but may be less; in the latter case, the
effect is as if sufficient null values had been
!!appended to match any remaining list items in the expanded sequence.
!!
!! NOTE 10.35
!! For example, if the name in the input record is the name of an
integer array of size 100, at most 100 values,
!! each of which is either a digit string or a null value, may
follow the equals; these values would then be
!! assigned to the elements of the array in array element order.
!!
!! 3 A slash encountered as a value separator during the execution of a
namelist input statement causes termination
!!of execution of that input statement after transference of the
previous value. If there are additional items in the
!!namelist group object being transferred, the effect is as if null
values had been supplied for them.
!!
!! 4 A namelist comment may appear after any value separator except a slash.
A namelist comment is also permitted
!!to start in the first nonblank position of an input record except
within a character literal constant.
!!
!! 5 Successive namelist records are read by namelist input until a slash is
encountered; the remainder of the record
!!is ignored and need not follow the rules for namelist input values.
- Original Message -
From: "sgk at troutmask dot apl dot washington dot edu"
To:
Sent: Sunday, August 30, 2009 1:58 PM
Subject: [Bug fortran/41192] NAMELIST input with just a comment ("&NAME !
comment \") fails
>
>
> --- Comment #3 from sgk at troutmask dot apl dot washington dot edu
> 2009-08-30 17:58 ---
> Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \")
> fails
>
> On Sun, Aug 30, 2009 at 05:48:15PM -, kargl at gcc dot gnu dot org
> wrote:
>>
>>
>> --- Comment #2 from kargl at gcc dot gnu dot org 2009-08-30
>> 17:48 ---
>> (In reply to comment #1)
>> > Thanks for report , I will fix this.
>> >
>>
>> It's not broken.
>>
>
> Here's my analysis, which coul
[Bug c/41128] ld: cannot find -luser32 problem
--- Comment #2 from justineuro at yahoo dot com 2009-08-31 00:09 --- (In reply to comment #1) > This is a bug in your installation of GCC and cygwin. Thanks for the reply. I have since re-installed and subsequently got an "undefined reference to _winm...@16' error". It turns out I had to add the -shared option, i.e., use the command line "gcc -shared -o file.exe file.c". I got this solution from url: http://forums.sun.com/thread.jspa?threadID=5305805&messageID=10359759. All is fine now. Again thanks! Justine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41128
[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2009-08-31 00:30 ---
Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \") fails
On Mon, Aug 31, 2009 at 12:07:34AM -, urbanjost at comcast dot net wrote:
>
>
> --- Comment #6 from urbanjost at comcast dot net 2009-08-31 00:07 ---
> Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \") fails
>
> Because of 10.11.3.3-4
There isn't a Section 10.11.3.3 in the Final Committee Draft
of the Fortran 2003 standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails
--- Comment #8 from urbanjost at comcast dot net 2009-08-31 01:12 ---
Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \") fails
Oops. That was 2008;
ISO/IEC SC22/WG5/N1723 CD 1539-1 08-007r2:2008/03/11; even though the
statements still appear in it
that you referenced in the 2003 final draft.
- Original Message -
From: "sgk at troutmask dot apl dot washington dot edu"
To:
Sent: Sunday, August 30, 2009 8:30 PM
Subject: [Bug fortran/41192] NAMELIST input with just a comment ("&NAME !
comment \") fails
>
>
> --- Comment #7 from sgk at troutmask dot apl dot washington dot edu
> 2009-08-31 00:30 ---
> Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \")
> fails
>
> On Mon, Aug 31, 2009 at 12:07:34AM -, urbanjost at comcast dot net
> wrote:
>>
>>
>> --- Comment #6 from urbanjost at comcast dot net 2009-08-31
>> 00:07 ---
>> Subject: Re: NAMELIST input with just a comment ("&NAME ! comment \")
>> fails
>>
>> Because of 10.11.3.3-4
>
> There isn't a Section 10.11.3.3 in the Final Committee Draft
> of the Fortran 2003 standard.
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug c/41128] ld: cannot find -luser32 problem
--- Comment #3 from justineuro at yahoo dot com 2009-08-31 01:16 --- (In reply to comment #2) > (In reply to comment #1) > > This is a bug in your installation of GCC and cygwin. > Thanks for the reply. I have since re-installed and subsequently got an > "undefined reference to _winm...@16' error". It turns out I had to add the > -shared option, i.e., use the command line "gcc -shared -o file.exe file.c". > I > got this solution from url: > http://forums.sun.com/thread.jspa?threadID=5305805&messageID=10359759. All is > fine now. Again thanks! > > Justine Make sure you use the option -shared and ***NOT*** -share. The -share option when used in a windows command prompt shell in my machine ERASES the existing *.exe files of the same name!!! However, it does give a message to the effect that -share is not a valid option. ---Justine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41128
[Bug middle-end/30789] complex folding inexact
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-08-31 03:05 --- Patch for remaining issues posted here: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01614.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug c++/41195] New: floating point optimization
A simple sequence of floating point calculations gives different results on optimized builds and unoptimized builds. I have seen some bug reports, but this one is different as the error is reproduced only when the floating point calculation in question is called from a library. If i create a simple main method with the calculation in question, the error is not reproducible. I have a simple test case, how can i send it? -- Summary: floating point optimization Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mehta at roguewave dot com GCC host triplet: RHAS 5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41195
[Bug c++/41195] floating point optimization
--- Comment #1 from mehta at roguewave dot com 2009-08-31 03:55 --- Created an attachment (id=18453) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18453&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41195
[Bug regression/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #5 from steven at gcc dot gnu dot org 2009-08-31 06:20 --- See http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01291.html -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-31 06:20:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188
[Bug c++/41195] floating point optimization
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-08-31 06:21 --- I think this is a duplicate of bug 323. What target are you using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41195
[Bug libstdc++/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #21 from ubizjak at gmail dot com 2009-08-31 06:52 --- (In reply to comment #20) > > Sigh, the patch doesn't fix alpha failure :( > > It also doensn't fix reliably the failure on i?86. Is your alpha > failure on lto branch or on trunk? It is on the trunk. However, I have started debugging this, and the problem is that the pointer to LSDA structure gets corrupted and test aborts when parsing LSDA header with parse_lsda_header. The actual abort is triggered in read_encoded_value_with_base. Exception data points to _ZN10__gnu_pbds6detail15gp_ht_map_data_INS_4test10basic_typeES3_NS2_4hashESt8equal_toIS3_EN9__gnu_cxx15throw_allocatorIS3_EELb0ENS2_27direct_mod_range_hashing_t_IS9_EENS2_21quadratic_probe_fn_t_IS3_S9_EENS_27hash_standard_resize_policyINS2_25hash_prime_size_policy_t_ENS2_33hash_load_check_resize_trigger_t_IS9_Lm1ELm8ELm1ELm2ELb1EEELb1EmEEEC2ERKSJ_ aka: __gnu_pbds::detail::gp_ht_map_data_<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::test::hash, std::equal_to<__gnu_pbds::test::basic_type>, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, false, __gnu_pbds::test::direct_mod_range_hashing_t_<__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::test::quadratic_probe_fn_t_<__gnu_pbds::test::basic_type, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::hash_standard_resize_policy<__gnu_pbds::test::hash_prime_size_policy_t_, __gnu_pbds::test::hash_load_check_resize_trigger_t_<__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, 1ul, 8ul, 1ul, 2ul, true>, true, unsigned long> >::gp_ht_map_data_(__gnu_pbds::detail::gp_ht_map_data_<__gnu_pbds::test::basic_type, __gnu_pbds::test::basic_type, __gnu_pbds::test::hash, std::equal_to<__gnu_pbds::test::basic_type>, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, false, __gnu_pbds::test::direct_mod_range_hashing_t_<__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::test::quadratic_probe_fn_t_<__gnu_pbds::test::basic_type, __gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type> >, __gnu_pbds::hash_standard_resize_policy<__gnu_pbds::test::hash_prime_size_policy_t_, __gnu_pbds::test::hash_load_check_resize_trigger_t_<__gnu_cxx::throw_allocator<__gnu_pbds::test::basic_type>, 1ul, 8ul, 1ul, 2ul, true>, true, unsigned long> > const&) Defined in: file /home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/gp_hash_table_map_/constructor_destructor_fn_imps.hpp, line 144. (2 locations) Return address points just after the call to: 12000f9e8: d3 da 5f d3 bsr ra,120006538 <_ZN9__gnu_cxx16probability_base19throw_conditionallyEv+0x8> > 12000f9ec: 00 00 fe 2f unop 12000f9f0: 00 00 fe 2f unop This is hard to debug, since this is conditional exception, and the condition that triggers this exception depends on a random value. I have checked that it is not LSDA data that gets corrupted, but the pointer to LSDA data: failed: 0x1201bb405 objdump --section=.gcc_except_table -s hash_data_map_rand.test 1201bb3f4 ff9b2d01 23a80148 c40400f0 0208b404 ..-.#..H >1201bb404 01880308 e00301d8 0304c404 009c0414 1201bb414 e80400e0 0404 0100 1201bb424 ff9b2101 17ac0208 d80401d8 0308fc03 ..!. 1201bb434 05940404 a80400d0 0438 7f00 .8.. 1201bb444 7f7d ff9b4901 41d4015c .}I.A..\ correct: 0x1201bb3f4 1201bb3e4 0001 08240848 005c0400 .$.H.\.. >1201bb3f4 ff9b2d01 23a80148 c40400f0 0208b404 ..-.#..H 1201bb404 01880308 e00301d8 0304c404 009c0414 1201bb414 e80400e0 0404 0100 1201bb424 ff9b2101 17ac0208 d80401d8 0308fc03 ..!. 1201bb434 05940404 a80400d0 0438 7f00 .8.. So, the pointer to LSDA is off by 0x11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
