[Bug fortran/29373] implicit type declaration and contained function clash
--- Comment #10 from pault at gcc dot gnu dot org 2006-10-14 08:17 --- Fixed in trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug fortran/29407] namelist: overriding the host association does not work (rejects valid code)
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-14 08:18 --- Fixed in trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29407
[Bug fortran/27701] Two routines with the same name cause an interna; error in gfortran
--- Comment #6 from pault at gcc dot gnu dot org 2006-10-14 08:18 --- Fixed in trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27701
[Bug fortran/29232] No warning/error for duplicate construct name
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-14 08:19 --- Fixed in trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29232
[Bug fortran/29364] No error given if using a non-defined type in a type definition
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-14 08:19 --- Fixed in trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29364
[Bug fortran/24398] invalid module file gives weird error
--- Comment #11 from pault at gcc dot gnu dot org 2006-10-14 08:20 --- Fixed in trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
[Bug fortran/29422] ICE with allocatable
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-14 08:20 --- Fixed in trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
[Bug fortran/29428] Error in allocatable component function calls
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-14 08:21 --- Fixed in trunk Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29428
[Bug java/21900] [4.1/4.2 Regression] debugging regression when debugging libgcj
--- Comment #5 from aph at gcc dot gnu dot org 2006-10-14 08:39 --- . -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21900
[Bug java/21900] [4.1/4.2 Regression] debugging regression when debugging libgcj
--- Comment #6 from aph at gcc dot gnu dot org 2006-10-14 08:42 --- I'm closing this bug. It never was reproducible: I think it was just a one-off. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21900
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #10 from franke dot daniel at gmail dot com 2006-10-14 08:46 --- Don't know whether it makes any difference - but if it is the array constructor that crashes because of unequal string lengths within its arguments, why is there no problem with this code? PROGRAM test_constructor CHARACTER(len=32), DIMENSION(1,2) :: a a = reshape((/ one arg, another arg /), (/ 1, 2 /)) END PROGRAM (Also compare with #3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug rtl-optimization/29323] [4.0/4.1 Regression] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-14 09:13 --- Subject: Bug 29323 Author: rguenth Date: Sat Oct 14 09:13:43 2006 New Revision: 117727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117727 Log: 2006-10-14 Richard Guenther [EMAIL PROTECTED] PR rtl-optimization/29323 * except.c (set_nothrow_function_flags): For functions that do not bind local bail out early. * decl.c (finish_function): Set TREE_NOTHROW only for functions that bind local. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug rtl-optimization/29323] [4.0 Regression] set_nothrow_function_flags does invalid analysis on weak functions
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-14 09:14 --- Fixed for 4.1.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 Regression]|[4.0 Regression] |set_nothrow_function_flags |set_nothrow_function_flags |does invalid analysis on|does invalid analysis on |weak functions |weak functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29323
[Bug middle-end/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-14 09:26 --- It's a VRP bug :/ Before VRP we have D.6958_313 = cr_285 * cr_285; D.6959_314 = (size_t) D.6958_313; D.6960_315 = cr_285 + 1; memset (number_287, D.6960_315, D.6959_314); and after we get introduced a spurious, uninitialized cr_2738 D.6958_313 = cr_285 * cr_2738; D.6959_314 = (size_t) D.6958_313; D.6960_315 = cr_285 + 1; memset (number_287, D.6960_315, D.6959_314); this get's generated by cr_2738 = ASSERT_EXPR cr_285, x_1 cr_285; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug middle-end/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-14 10:18 ---
Confirmed. Reduced testcase, -O -ftree-vrp
int solver_set(int);
void solver(int c, int r, char *number)
{
int cr = c*r;
int x, y, x2, y2, n, ret;
for (x = 0; x cr; x++)
for (y = 0; y r; y++)
for (n = 1; n = cr; n++)
;
for (x = 0; x cr; x += r)
for (y = 0; y r; y++)
ret = solver_set(r*cr);
for (y = 0; y cr; y++)
ret = solver_set(cr*cr);
for (x = 0; x cr; x++)
ret = solver_set(cr);
for (n = 1; n = cr; n++)
ret = solver_set(cr*cr);
for (y = 0; y+1 cr; y++)
for (x = 0; x+1 cr; x++)
for (y2 = y+1; y2 cr; y2++)
for (x2 = x+1; x2 cr; x2++)
if (x/r == x2/r y%r == y2%r)
continue;
for (y = 0; y cr; y++)
for (x = 0; x cr; x++) {
for (n = 1; n = cr; n++)
;
__builtin_memset(number, cr+1, cr*cr);
}
}
shows the failure in the t36.vrp1 dump.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-14 10:18:53
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug middle-end/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-10-14 10:40 ---
Much simpler testcase:
void foo(int);
void solver(int cr)
{
int x, y, n;
for (y = 0; y cr; y++)
for (x = 0; x cr; x++) {
for (n = 0; n cr; n++)
;
foo(cr*cr);
}
}
t35.copyprop1:
;; Function solver (solver)
solver (cr)
{
int n;
int y;
int x;
int D.1293;
bb 0:
goto bb 6 (L7);
L2:;
n_11 = n_3 + 1;
# n_3 = PHI 0(4), n_11(1);
L3:;
if (n_3 cr_5) goto L2; else goto L4;
L4:;
D.1293_9 = cr_5 * cr_5;
foo (D.1293_9);
x_10 = x_1 + 1;
# x_1 = PHI 0(6), x_10(3);
L5:;
if (x_1 cr_5) goto L3; else goto L6;
L6:;
y_7 = y_2 + 1;
# y_2 = PHI 0(0), y_7(5);
L7:;
if (y_2 cr_5) goto L5; else goto L8;
L8:;
return;
}
t36.vrp1:
solver (cr)
{
int n;
int y;
int x;
int D.1293;
bb 0:
goto bb 6 (L7);
L2:;
n_11 = n_3 + 1;
# n_3 = PHI 0(4), n_11(1);
L3:;
if (n_3 cr_5) goto L2; else goto L4;
L4:;
D.1293_9 = cr_5 * cr_13;
foo (D.1293_9);
x_10 = x_1 + 1;
# x_1 = PHI 0(6), x_10(3);
L5:;
if (x_1 cr_5) goto L3; else goto L6;
L6:;
y_7 = y_2 + 1;
# y_2 = PHI 0(0), y_7(5);
L7:;
if (y_2 cr_5) goto L5; else goto L8;
L8:;
return;
}
(this smells like a tree sharing issue).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-10-14 10:59 --- PA-RISC GNU/Linux is not a primary platform, so I've marked this P5. However, PA-RISC HP-UX is a primary platform, so if this bug manifests there, please set this back to P3 with an explanatory comment. Present on SPARC/Solaris. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P5 |P3 Last reconfirmed|-00-00 00:00:00 |2006-10-14 10:59:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29111
[Bug middle-end/29111] [4.2 Regression] FAIL: gcc.dg/torture/pr26565.c -O0 execution test
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC build triplet|hppa-unknown-linux-gnu | GCC host triplet|hppa-unknown-linux-gnu | GCC target triplet|hppa-unknown-linux-gnu |hppa-*-*, sparc-*-* Last reconfirmed|2006-10-14 10:59:32 |2006-10-14 11:00:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29111
[Bug middle-end/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-14 11:11
---
If we watch what happens to the multiplication after VRP, we see that it is
possibly an immediate uses problem:
Hardware watchpoint 6: *(union tree_node **) 3082785444
Old value = (union tree_node *) 0xb7c793dc
New value = (union tree_node *) 0xb7c7971c
set_ssa_use_from_ptr (use=0xb7c7a0bc, val=0xb7c7971c)
at /home/richard/src/gcc-4_1-branch/gcc/tree-flow-inline.h:330
330 link_imm_use (use, val);
#0 set_ssa_use_from_ptr (use=0xb7c7a0bc, val=0xb7c7971c)
at /home/richard/src/gcc-4_1-branch/gcc/tree-flow-inline.h:330
#1 0x080d3ed2 in maybe_replace_use (use_p=0xb7c7a0bc)
at /home/richard/src/gcc-4_1-branch/gcc/tree-into-ssa.c:1386
#2 0x080d3d05 in rewrite_update_stmt (walk_data=0xbfaa5f50, bb=0xb7bfa460, si=
{tsi = {ptr = 0xb7bf8f78, container = 0xb7c78018}, bb = 0xb7bfa460})
at /home/richard/src/gcc-4_1-branch/gcc/tree-into-ssa.c:1465
#3 0x080f1573 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa460)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:196
#4 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa410)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#5 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa5f0)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#6 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa4b0)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#7 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa640)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#8 0x080f1616 in walk_dominator_tree (walk_data=0xbfaa5f50, bb=0xb7bfa550)
at /home/richard/src/gcc-4_1-branch/gcc/domwalk.c:212
#9 0x080d42c4 in rewrite_blocks (entry=0xb7bfa550, what=REWRITE_UPDATE,
blocks=0x86ab0d8)
at /home/richard/src/gcc-4_1-branch/gcc/tree-into-ssa.c:1616
#10 0x080d6d10 in update_ssa (update_flags=256)
at /home/richard/src/gcc-4_1-branch/gcc/tree-into-ssa.c:2798
#11 0x08403f38 in insert_range_assertions ()
at /home/richard/src/gcc-4_1-branch/gcc/tree-vrp.c:2960
#12 0x08406ce7 in execute_vrp ()
at /home/richard/src/gcc-4_1-branch/gcc/tree-vrp.c:4176
it changes a few times until finally it settles at the wrong solution.
It get's magically fixed if I disable swapping tree operands in
get_expr_operands () (WTF!?) - so this seems to be an operand-scanner
vs. update_ssa interaction?
Index: tree-ssa-operands.c
===
*** tree-ssa-operands.c (revision 117726)
--- tree-ssa-operands.c (working copy)
*** get_expr_operands (tree stmt, tree *expr
*** 1257,1295
case ASSERT_EXPR:
do_binary:
{
- tree op0 = TREE_OPERAND (expr, 0);
- tree op1 = TREE_OPERAND (expr, 1);
-
- /* If it would be profitable to swap the operands, then do so to
- canonicalize the statement, enabling better optimization.
-
- By placing canonicalization of such expressions here we
- transparently keep statements in canonical form, even
- when the statement is modified. */
- if (tree_swap_operands_p (op0, op1, false))
- {
- /* For relationals we need to swap the operands
- and change the code. */
- if (code == LT_EXPR
- || code == GT_EXPR
- || code == LE_EXPR
- || code == GE_EXPR)
- {
- TREE_SET_CODE (expr, swap_tree_comparison (code));
- swap_tree_operands (stmt,
- TREE_OPERAND (expr, 0),
- TREE_OPERAND (expr, 1));
- }
-
- /* For a commutative operator we can just swap the operands. */
- else if (commutative_tree_code (code))
- {
- swap_tree_operands (stmt,
- TREE_OPERAND (expr, 0),
- TREE_OPERAND (expr, 1));
- }
- }
-
get_expr_operands (stmt, TREE_OPERAND (expr, 0), flags);
get_expr_operands (stmt, TREE_OPERAND (expr, 1), flags);
return;
--- 1257,1262
note this patch seems to be in mainline already!? My archology skills are
not good enough to figure out when it was gone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||amacleod at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug fortran/29447] Getting different answers for DLSODE demo code
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-14 11:13 --- Please send a question of this type to comp.lang.fortran or, indeed, to the gfortran list. We would be happy accept bug reports from you on Bugzilla but not general numerical analysis questions. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29447
[Bug c/29467] New: -ansi -pedantic accepts _Bool without diagnostic
_Bool x; -- Summary: -ansi -pedantic accepts _Bool without diagnostic Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29467
[Bug c/29468] New: off-by-one error for string initialiser warning
[forwarded from http://bugs.debian.org/392880]
$ gcc t.c
t.c:10: warning: initializer-string for array of chars is too long
#include stdio.h
char a[]=a;
char string1[2] = ;
char b[]=b;
char string2[2] = 1;
char c[]=c;
char string3[2] = 12; /* no warning here */
char d[]=d;
char string4[2] = 123;
char e[]=e;
int main()
{
puts(string1);
puts(string2);
puts(string3);
puts(string4);
return 0;
}
--
Summary: off-by-one error for string initialiser warning
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29468
[Bug c/29468] off-by-one error for string initialiser warning
--- Comment #1 from neil at gcc dot gnu dot org 2006-10-14 12:25 --- Not a bug - just 2 elements are initialized, the NUL is dropped. -- neil at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29468
[Bug fortran/29371] Coredump when using -fbounds-check with pointer nullify
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-14 13:10 --- Subject: Bug 29371 Author: pault Date: Sat Oct 14 13:09:56 2006 New Revision: 117732 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117732 Log: 2006-10-14 Paul Thomas [EMAIL PROTECTED] PR fortran/29371 * trans-expr.c (gfc_trans_pointer_assignment): Add the expression for the assignment of null to the data field to se-pre, rather than block. 2006-10-14 Paul Thomas [EMAIL PROTECTED] PR fortran/29371 * gfortran.dg/nullify_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/nullify_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
[Bug fortran/29371] Coredump when using -fbounds-check with pointer nullify
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-14 13:19 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
[Bug fortran/29428] Error in allocatable component function calls
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-14 13:24 --- Fixed in trunk - I'll press the fixed button this time! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29428
[Bug fortran/29394] Invalid derived-type initialization in function
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-14 13:27 --- I have a regtestable fix for this. I just trying to extend it to include non-default initialization of variables. If this does not work soon, I will submit the patch as is. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-08 21:36:30 |2006-10-14 13:27:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29394
[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info
--- Comment #19 from steven at gcc dot gnu dot org 2006-10-14 14:17 ---
Someone should make gdb understand the DW_AT_calling_convention attribute.
This is the bit necessary to make it work for Fortran. I considered stealing a
bit on FUNCTION_DECL to mark it as the main program but it seems to me that
this hard-coded solution should be acceptable as well (but, your thoughts?).
Index: dwarf2out.c
===
--- dwarf2out.c (revision 117672)
+++ dwarf2out.c (working copy)
@@ -11105,11 +11105,18 @@ add_calling_convention_attribute (dw_die
{
enum dwarf_calling_convention value = DW_CC_normal;
- value = targetm.dwarf_calling_convention (type);
+ if (is_fortran ())
+{
+ /* The subroutine named MAIN__ is the main program for Fortran. */
+ const char *subroutine_name = get_AT_string (subr_die, DW_AT_name);
+ if (strcmp (subroutine_name, MAIN__) == 0)
+ value = DW_CC_program;
+}
+ else
+value = targetm.dwarf_calling_convention (type);
- /* Only add the attribute if the backend requests it, and
- is not DW_CC_normal. */
- if (value (value != DW_CC_normal))
+ /* Only add the attribute if it is not DW_CC_normal. */
+ if (value != DW_CC_normal)
add_AT_unsigned (subr_die, DW_AT_calling_convention, value);
}
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1427
[Bug fortran/23280] gfortran does not emit DW_AT_entry_point (dwarf-2) debugging info
--- Comment #2 from steven at gcc dot gnu dot org 2006-10-14 14:19 --- We should actually emit DW_AT_calling_convention for the main program. The DW_AT_entry_point attribute is for alternate entries, which, yes, we should also emit but don't. G77 also never got this right. -- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Summary|gfortran does not emit |gfortran does not emit |DW_AT_entry_point (dwarf-2) |DW_AT_entry_point (dwarf-2) |or N_MAIN (stabs) debugging |debugging info |info| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23280
[Bug fortran/24526] variables from modules not visible in gdb
--- Comment #3 from steven at gcc dot gnu dot org 2006-10-14 14:21 --- There is support for Fortran module variables in DWARF3, see http://dwarf.freestandards.org/Dwarf3.pdf. Unfortunately GDB doesn't seem to support this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24526
[Bug fortran/24527] derived types not displayed correctly with gdb
--- Comment #3 from steven at gcc dot gnu dot org 2006-10-14 14:47 --- The patch in http://sourceware.org/ml/gdb-patches/2005-11/msg00217.html implements this quite nicely AFAICT. I'll try and take care of the rest. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-29 17:58:09 |2006-10-14 14:47:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24527
[Bug middle-end/28545] [4.1 Regression] Wrong code for hoisted multiplication
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-14 10:18:53 |2006-10-14 14:48:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug middle-end/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #11 from patchapp at dberlin dot org 2006-10-14 15:05 --- Subject: Bug number PR28545 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-10/msg00754.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug fortran/19261] continuation character illegal as first non-blank character in statement
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-14 15:06 --- Subject: Bug 19261 Author: jvdelisle Date: Sat Oct 14 15:06:34 2006 New Revision: 117733 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117733 Log: 2006-10-14 Jerry DeLisle [EMAIL PROTECTED] PR fortran/19261 * scanner.c (load_line): Add checks for illegal use of '' and issue warnings. Issue errors with -pedantic. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19261
[Bug middle-end/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-10-14 15:13 --- Actually see http://gcc.gnu.org/ml/gcc-patches/2006-03/txt00090.txt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug fortran/24527] derived types not displayed correctly with gdb
--- Comment #4 from steven at gcc dot gnu dot org 2006-10-14 15:15 --- This works with the patch I mentioned in comment #3. That patch is in the GDB source tree since 2006-02-24, so this is fixed in GDB 6.5. On the GCC side we seem to do the right thing for scalar components. For array components obviously we don't but there is a separate bug about that. So I'm calling this FIXED. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24527
[Bug fortran/19261] continuation character illegal as first non-blank character in statement
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-10-14 15:16 --- Fixed on svn trunk. Note: Could not get a test case to work properly with the dejagnu machinery. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19261
[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-14 15:29 --- Hmm, isn't _Bool in the implemenation keyword space anyways? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29467
[Bug fortran/18769] ICE in gfc_conv_array_initializer with array initialization with transfer
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-10-14 15:38 --- Paul, should this be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug tree-optimization/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-14 16:07 --- I have the correct work around patch which I am testing right now. It is only local to tree-vrp.c also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |pinskia at gcc dot gnu dot |org |org Component|middle-end |tree-optimization GCC build triplet|i486-linux-gnu | GCC host triplet|i486-linux-gnu | GCC target triplet|i486-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug other/29405] GCC should include latest GMP/MPFR sources and always build libgmp.a/libmpfr.a
--- Comment #4 from ghazi at gcc dot gnu dot org 2006-10-14 16:09 --- I think we're converging on not including these libraries in the GCC tree, but rather to require the user to be responsible for getting them. http://gcc.gnu.org/ml/gcc/2006-10/msg00167.html Either way, GCC can always rely on MPFR being available, and I can start using it in the middle-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29405
[Bug tree-optimization/28545] [4.1 Regression] Wrong code for hoisted multiplication
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-14 16:09 --- Created an attachment (id=12428) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12428action=view) patch which I am testing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28545
[Bug other/29405] GCC should include latest GMP/MPFR sources and always build libgmp.a/libmpfr.a
--- Comment #5 from ghazi at gcc dot gnu dot org 2006-10-14 16:10 --- Won't fix. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29405
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #10 from ghazi at gcc dot gnu dot org 2006-10-14 16:12 --- No longer relying on PR29405. Instead we'll force the person building GCC to acquire GMP/MPFR themselves. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|29405 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #11 from ghazi at gcc dot gnu dot org 2006-10-14 16:13 --- Updated patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00757.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2006- |patches/2006- |10/msg00360.html|10/msg00757.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
Re: [Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic
pinskia at gcc dot gnu dot org wrote:- --- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-14 15:29 --- Hmm, isn't _Bool in the implemenation keyword space anyways? It is, so is _Complex, and that is diagnosed. I'm not saying it's a conformance problem, just that it's probably a bug.
[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic
--- Comment #2 from neil at daikokuya dot co dot uk 2006-10-14 16:19 --- Subject: Re: -ansi -pedantic accepts _Bool without diagnostic pinskia at gcc dot gnu dot org wrote:- --- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-14 15:29 --- Hmm, isn't _Bool in the implemenation keyword space anyways? It is, so is _Complex, and that is diagnosed. I'm not saying it's a conformance problem, just that it's probably a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29467
[Bug debug/26881] [4.1 Regression] internal compiler error in dwarf2out_finish
--- Comment #20 from tbm at cyrius dot com 2006-10-14 16:48 --- Jan, do you intend to apply this to 4.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-10-14 17:06 --- Subject: Re: Issues with -Wchar-subscripts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug fortran/18769] ICE in gfc_conv_array_initializer with array initialization with transfer
--- Comment #13 from pault at gcc dot gnu dot org 2006-10-14 17:31 --- Jerry, See comment #10. The 'problem' is to take the gmp/mpfr representations of the values in the constructor expression, write them out to form the source, read then back in binary as the destination, convert the array into gmp/mpfr values and pop the values into a constructor array. It is actually simple enough but tedious; with one thing or another I have not gotten round to it. One of the key points will be to get the numeric representation right, so bits will have to be borrowed from all over (arith.c? trans-xxx.c?) to get the gmp/mpfr to the gfc type+kind's and back again. I was sort of hoping that Steve would take an interest because he is exceeding clued up on such matters. However, he and I both have been busy. *sigh* If you want to be guided you would be very welcome. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug c++/29469] New: error: non-template 'pair' used as template
The following example code compiled fine with 4.1.2 20060901 (Debian 4.1.1-13) but fails with 4.1.2 20061007 (Debian 4.1.1-16). I'm wondering whether this change was intentional and whether there's a good reason for this change (in a stable branch). $ g++-4.1 -c pair.c x.c:32: error: non-template 'pair' used as template x.c:32: note: use 'avm_mapKey, Value, Compare, equal::template pair' to indicate that it is a template -- Summary: error: non-template 'pair' used as template Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/29469] error: non-template 'pair' used as template
--- Comment #1 from tbm at cyrius dot com 2006-10-14 17:37 --- Created an attachment (id=12429) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12429action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/29469] error: non-template 'pair' used as template
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-14 17:48 --- The real question is avm_map dependent inside the nested class? I know there are C++ defect reports asking that question so ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-10-14
17:52 ---
Subject: Re: Issues with -Wchar-subscripts
Sorry about the empty answer.
pinskia at gcc dot gnu dot org writes:
'a' in C is not of the type char but instead int so not warning there
is correct really.
Hmm, yes, it fits the documentation. I guess what I'm asking is for a
change in the warning's spec. array['8-bit char'] is almost certainly
wrong in an iso646-derived charset, since for a portable program the
programmer can't know if the index is positive or negative. I don't
know if enough information is available in C at the time the warning is
given do do that, though.
Also you forgot one thing '%' does not have to match up with the ANSI
character set so it could be negative in signed char which means char
(which could default to signed char) would be different.
No. In a conforming C implementation, the character *which C interprets
as '%'* must have a positive value. Maybe you are thinking of the
opposite case: What its glyph _looks like_ on some display device is out
of scope for the C standard.
In the 7-bit days we had screens with the Norwegian charset NS_4551-1,
but the C compiler (like most of the American-made computer) thought
it received ASCII. Thus we had to write
main() æ printf(Hello, world!Øn); return 0; å
for the ASCII compiler to see
main() { printf(Hello, world!\n); return 0; }
The ANSI Rationale blessed this behavior since it already was
common (and more readable than trigraphs), the example there was
the Yen sign. I can probably dig it up if you are interested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
Re: [Bug c++/29455] Issues with -Wchar-subscripts
On Sat, 2006-10-14 at 17:52 +, h dot b dot furuseth at usit dot uio dot no wrote: Also you forgot one thing '%' does not have to match up with the ANSI character set so it could be negative in signed char which means char (which could default to signed char) would be different. No. In a conforming C implementation, the character *which C interprets as '%'* must have a positive value. Maybe you are thinking of the opposite case: What its glyph _looks like_ on some display device is out of scope for the C standard. But at this point, we are talking about C++ where 'a' is of type char. I have to look at what the C++ standard says about this. -- Pinski
[Bug c++/29455] Issues with -Wchar-subscripts
--- Comment #4 from pinskia at gmail dot com 2006-10-14 18:08 --- Subject: Re: Issues with -Wchar-subscripts On Sat, 2006-10-14 at 17:52 +, h dot b dot furuseth at usit dot uio dot no wrote: Also you forgot one thing '%' does not have to match up with the ANSI character set so it could be negative in signed char which means char (which could default to signed char) would be different. No. In a conforming C implementation, the character *which C interprets as '%'* must have a positive value. Maybe you are thinking of the opposite case: What its glyph _looks like_ on some display device is out of scope for the C standard. But at this point, we are talking about C++ where 'a' is of type char. I have to look at what the C++ standard says about this. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
[Bug c++/29469] [DR 224] error: non-template 'pair' used as template
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-14 18:11 --- (In reply to comment #2) The real question is avm_map dependent inside the nested class? I know there are C++ defect reports asking that question so ... And that is DR 224 which is in WP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/29469] [DR 224] error: non-template 'pair' used as template
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-14 18:15 --- I think this is more complicated than just DR 224. See PR 9634. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/29469] [DR 224] error: non-template 'pair' used as template
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-14 18:25 ---
DR 224 says this is invalid code but GDR has mentioned that DR 224 is broken in
really bad way:
template class T struct B : T
{
void g(void) { B x; x.f(); }
}
struct A
{
void f(void) {}
}
int main(void)
{
BA t;
t.g();
}
The above code would be invalid code with the resulution of DR 224.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
Re: [Bug c++/29469] [DR 224] error: non-template 'pair' used as template
On Sat, 2006-10-14 at 18:25 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-14 18:25 --- DR 224 says this is invalid code Sorry valid code. -- Pinski
[Bug c++/29469] [DR 224] error: non-template 'pair' used as template
--- Comment #6 from pinskia at gmail dot com 2006-10-14 18:26 --- Subject: Re: [DR 224] error: non-template 'pair' used as template On Sat, 2006-10-14 at 18:25 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-14 18:25 --- DR 224 says this is invalid code Sorry valid code. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/9634] [DR224] Injected class name as qualifier should not make the name dependent
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-10-14 18:29 --- GDR, Any news from the committee on this issue? It has been more than 2 years since the orginal message about talking to the committee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9634
[Bug c++/29470] New: Using declaration access semantics change with templates
In the following class template, the protected using declaration causes the
inherited member to become publicly accessible. The code compiles, even though
it shouldn't.
template typename T struct B
{
protected:
T v;
};
template typename T struct D : BT
{
protected:
using BT::v;
};
int main()
{
Dint d;
d.v = 0;
return 0;
}
$ g++ test.cpp
The same code without templates gives the correct behaviour and doesn't
compile.
struct B
{
protected:
int v;
};
struct D : B
{
protected:
using B::v;
};
int main()
{
D d;
d.v = 0;
return 0;
}
$ g++ test.cpp
test.cpp: In function 'int main()':
test.cpp:4: error: 'int B::v' is protected
test.cpp:14: error: within this context
The preprocessed file from the template version is as follows:
# 1 test.cpp
# 1 built-in
# 1 command line
# 1 test.cpp
template typename T struct B
{
protected:
T v;
};
template typename T struct D : BT
{
protected:
using BT::v;
};
int main()
{
Dint d;
d.v = 0;
return 0;
}
--
Summary: Using declaration access semantics change with templates
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spam at david dot osborn dot name
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29470
[Bug c++/29470] [4.1/4.2 Regression] Using declaration access semantics change with templates
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-14 19:02 --- Confirmed, a regression from 4.0.4. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-mingw32 | GCC host triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 | Keywords||accepts-invalid Known to fail||4.1.2 4.2.0 4.1.1 Known to work||4.0.4 Last reconfirmed|-00-00 00:00:00 |2006-10-14 19:02:48 date|| Summary|Using declaration access|[4.1/4.2 Regression] Using |semantics change with |declaration access semantics |templates |change with templates Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29470
[Bug fortran/29471] New: Warn with -std=f95/f2003 when BOZ is used at invalid places
gfortran allows everywhere to use a BOZ. However, there are constrains in Fortran 95 and 2003 on where to use them. - Fortran 95: Only in DATA and only integer - Fortran 2003: Only in DATA or as argument of INT, REAL, DBLE, CMPLX Expected: An ERROR (or WARNING) is shown, when -std=f95/f2003 is used. Fortran 95: R407 boz-literal-constant [...] Constraint: A boz-literal-constant may appear only in a DATA statement.[...] If a data-statement-constant is a boz-literal-constant, the corresponding object shall be of type integer. Fortran 2003: C410 (R411) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, as the actual argument associated with the dummy argument A of the numeric intrinsic functions DBLE, REAL or INT, or as the actual argument associated with the X or Y dummy argument of the intrinsic function CMPLX. -- Summary: Warn with -std=f95/f2003 when BOZ is used at invalid places Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug target/29250] [4.0/4.1 Regression] internal compiler error: in extract_insn, at recog.c:2084
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-14 19:26
---
A C89 testcase:
struct TSparseEntry
{
int feat_index;
double entry;
};
struct TSparse
{
int vec_index;
int num_feat_entries;
struct TSparseEntry* features;
};
void
get_full_feature_matrix(struct TSparse* sparse_feature_matrix, int num_vec)
{
double* fm;
int v, f;
for (v=0; vnum_vec; v++)
{
for (f=0; fsparse_feature_matrix[v].num_feat_entries; f++)
{
long long offs = sparse_feature_matrix[v].vec_index
+ sparse_feature_matrix[v].features[f].feat_index;
fm[offs]= sparse_feature_matrix[v].features[f].entry;
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29250
[Bug fortran/18769] ICE in gfc_conv_array_initializer with array initialization with transfer
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-14 19:37 --- Oh, It was comment 11 that threw me off. Thats why I asked. Let me think about takingthis on before I do so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug fortran/18769] ICE in gfc_conv_array_initializer with array initialization with transfer
--- Comment #15 from pault at gcc dot gnu dot org 2006-10-14 19:58 --- Jerry, I was not entirely serious - if you want to take it on, great, but... it's a pain in the beeehind! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
[Bug target/29472] New: [4.0/4.1/4.2 Regression] in reload, at reload1.c:1081 on m68k with -O2 -fPIC
I get the following ICE on m68k with -O2 -fPIC. It fails with gcc 4.0, 4.1 and 4.2, and works with 3.3/3.4. (sid)115:[EMAIL PROTECTED]: ~] /home/tbm/tmp/gcc/4.1-m68k/gcc/g++ -B/home/tbm/tmp/gcc/4.1-m68k/gcc -O2 -fPIC blender-IK_QSegment.cpp blender-IK_QSegment.cpp: In member function 'bool IK_QSwingSegment::UpdateAngle(const IK_QJacobian, MT_Vector3, bool*)': blender-IK_QSegment.cpp:85: internal compiler error: in reload, at reload1.c:1079 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. zsh: exit 1 /home/tbm/tmp/gcc/4.1-m68k/gcc/g++ -B/home/tbm/tmp/gcc/4.1-m68k/gcc -O2 -fPIC (sid)116:[EMAIL PROTECTED]: ~] /home/tbm/tmp/gcc/4.2-m68k-117734/gcc/g++ -B/home/tbm/tmp/gcc/4.2-m68k-117734/gcc/g++ -O2 -fPIC blender-IK_QSegment.cpp blender-IK_QSegment.cpp: In member function 'bool IK_QSwingSegment::UpdateAngle(const IK_QJacobian, MT_Vector3, bool*)': blender-IK_QSegment.cpp:85: internal compiler error: in reload, at reload1.c:1081 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. zsh: exit 1 /home/tbm/tmp/gcc/4.2-m68k-117734/gcc/g++ -O2 -fPIC blender-IK_QSegment.cpp (sid)117:[EMAIL PROTECTED]: ~] -- Summary: [4.0/4.1/4.2 Regression] in reload, at reload1.c:1081 on m68k with -O2 -fPIC Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: m68k-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
[Bug target/29472] [4.0/4.1/4.2 Regression] in reload, at reload1.c:1081 on m68k with -O2 -fPIC
--- Comment #1 from tbm at cyrius dot com 2006-10-14 21:06 --- Created an attachment (id=12430) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12430action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
[Bug c++/29473] New: -masm=intel combined with -march=athlon64 has some issues.
Here is my test case:
unsigned char Keep4_3Ratio;
unsigned long SMode=0, DSMode=0;
bool CheckTVRatioReq()
{
return(Keep4_3Ratio (DSMode == 1 || SMode == 1));
}
Compiling on an x86-32 compiler with the following:
g++ -march=athlon64 -masm=intel -O3 -fomit-frame-pointer -o test.o -c test.cpp
Causes the compile to fail with:
Assembler messages: Error: expecting string instruction after `rep'
The assembly being:
_Z15CheckTVRatioReqv:
.LFB2:
xor %eax, %eax
cmp BYTE PTR Keep4_3Ratio, 0
je .L4
cmp DWORD PTR DSMode, 1
mov %al, 1
je .L4
xor %eax, %eax
cmp DWORD PTR SMode, 1
sete%al
.L4:
rep ret
rep ret is an invalid instruction.
I've tested with the following 32 bit compilers:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Debian 4.1.1-15)
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.2 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default,qt-default
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.2-1.4.2.0/jre
--enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release
i486-linux-gnu
Thread model: posix
gcc version 4.2.0 20060709 (experimental) (Debian 4.2-20060709-1)
Using built-in specs.
Target: i586-msdosdjgpp
Configured with: ./configure --target=i586-msdosdjgpp --prefix=/usr
--disable-nls --enable-languages=c,c++
--with-headers=/usr/i586-msdosdjgpp/sys-include
Thread model: single
gcc version 4.1.0
Reading specs from /usr/i586-mingw32/lib/gcc/i586-mingw32/3.4.5/specs
Configured with: ../configure --prefix=/usr/i586-mingw32 --with-gcc
--with-gnu-ld --with-gnu-as --target=i586-mingw32 --enable-threads
--disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions
--enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter --enable-hash-synchronization
--disable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw special)
Reading specs from ../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw special)
Using built-in specs.
Target: djgpp
Configured with: /gnu/gcc-4.10/configure djgpp --prefix=/dev/env/DJDIR
--disable-nls --disable-werror
--enable-languages=c,c++,fortran,objc,obj-c++,ada
Thread model: single
gcc version 4.1.0
Interestingly enough, it did not fail when using this version of GCC:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)
Although I suspect if I played with the options more I can get it to fail with
that GCC too.
Now when using the same case with an x86-64 compile and the following options:
g++ -march=athlon64 -masm=intel -o test.o -c test.cpp
I get the following errors:
Assembler messages:
Error: invalid operand for 'movzx' ('(' unexpected)
Error: invalid operand for 'mov' ('(' unexpected)
Error: invalid operand for 'mov' ('(' unexpected)
Assembly being:
_Z15CheckTVRatioReqv:
.LFB2:
push%rbp
.LCFI0:
mov %rbp, %rsp
.LCFI1:
movzx %eax, BYTE PTR Keep4_3Ratio(%rip)
test%al, %al
je .L2
mov %rax, QWORD PTR DSMode(%rip)
cmp %rax, 1
je .L4
mov %rax, QWORD PTR SMode(%rip)
cmp %rax, 1
[Bug c++/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #1 from nachms+gcc at gmail dot com 2006-10-14 21:43 ---
Oh I just realized one statement of mine was ambiguous.
I get cmp bugs instead of mov and I also get the rep ret bug from above
when using GCC 4.1 (but not 4.0).
I mean to say that when using a 64 bit GCC 4.0, I do not get that rep ret bug
even with -O3, but I still get errors such as: Error: invalid operand for
'cmp' ('(' unexpected)
-Nach
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug c++/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #2 from nachms+gcc at gmail dot com 2006-10-14 21:51 --- Oh another thing. If I change return(Keep4_3Ratio (DSMode == 1 || SMode == 1)); to: return((DSMode == 1 || SMode == 1) Keep4_3Ratio); The rep ret problem in the 32 bit compilers go away for some strange reason. However when doing this, the assembly outputted seems very messy and unoptimized to me. -Nach -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug target/15445] spurious dependency-violation warnings
--- Comment #5 from tbm at cyrius dot com 2006-10-14 21:55 --- Created an attachment (id=12431) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12431action=view) testcase [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c gqmpeg-ui2_display.c [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 gqmpeg-ui2_display.c /tmp/ccxbqBMW.s: Assembler messages: /tmp/ccxbqBMW.s:91: Warning: Use of 'adds' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 14 /tmp/ccxbqBMW.s:90: Warning: This is the location of the conflicting usage /tmp/ccxbqBMW.s:95: Warning: Use of 'ld8' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 8 /tmp/ccxbqBMW.s:94: Warning: This is the location of the conflicting usage [EMAIL PROTECTED]:~$ gcc-3.4 -c -O2 gqmpeg-ui2_display.c [EMAIL PROTECTED]:~$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15445
[Bug c++/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #3 from deathlike_2 at hotmail dot com 2006-10-14 21:56 --- I am experiencing the same issue. Compiling under MinGW and DJGPP generates the same error message: Assembler messages: Error: expecting string instruction after `rep' Removing the parameter -O3 or -fomit-frame-pointer won't generate the errors. -O3 can be substituted with -O1 and still generate the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug target/15445] spurious dependency-violation warnings
--- Comment #6 from tbm at cyrius dot com 2006-10-14 22:17 --- Created an attachment (id=12432) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12432action=view) testcase [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c sfront-readmidi.c [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 sfront-readmidi.c /tmp/ccJHp78N.s: Assembler messages: /tmp/ccJHp78N.s:55: Warning: Use of 'mov' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 16 /tmp/ccJHp78N.s:55: Warning: Only the first path encountering the conflict is reported /tmp/ccJHp78N.s:54: Warning: This is the location of the conflicting usage [EMAIL PROTECTED]:~$ gcc-3.4 -c -O2 sfront-readmidi.c [EMAIL PROTECTED]:~$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15445
[Bug target/15445] spurious dependency-violation warnings
--- Comment #7 from tbm at cyrius dot com 2006-10-14 23:29 --- Created an attachment (id=12433) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12433action=view) testcase [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c nethack-cmd.c [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 nethack-cmd.c nethack-cmd.c: In function 'enlightenment': nethack-cmd.c:44: warning: passing argument 1 of 'enlght_combatinc' makes integer from pointer without a cast /tmp/ccS5a0sQ.s: Assembler messages: /tmp/ccS5a0sQ.s:228: Warning: Use of 'addl' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 33 /tmp/ccS5a0sQ.s:228: Warning: Only the first path encountering the conflict is reported /tmp/ccS5a0sQ.s:226: Warning: This is the location of the conflicting usage /tmp/ccS5a0sQ.s:240: Warning: Use of 'ld8.mov' may violate RAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 33 /tmp/ccS5a0sQ.s:239: Warning: This is the location of the conflicting usage /tmp/ccS5a0sQ.s:240: Warning: Use of 'ld8.mov' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 33 /tmp/ccS5a0sQ.s:239: Warning: This is the location of the conflicting usage [EMAIL PROTECTED]:~$ gcc-3.4 -c -O2 nethack-cmd.c In file included from nethack-cmd.c:44: nethack-cmd.c: In function `enlightenment': nethack-cmd.c:25: warning: passing arg 1 of `enlght_combatinc' makes integer from pointer without a cast [EMAIL PROTECTED]:~$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15445
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #10 from kargl at gcc dot gnu dot org 2006-10-15 01:20 --- (In reply to comment #9) I managed to trim it down to: implicit none integer :: n, i character(len=16),parameter :: s = if (s(9:16) == 90123456) then endif if (i 0) then write (i,*) n call foo(0) endif do i = 1, n end do end This trimmed down example is invalid code. The if (i0) statement tries to use before it is defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #11 from kargl at gcc dot gnu dot org 2006-10-15 01:53 --- I can't reproduce this, so drop assign status. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kargl at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug c++/29427] uncallable constructor template should be warned.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29427
[Bug middle-end/29056] gcc.target/powerpc/ppc-negeq0-1.c fails on powerpc64
--- Comment #4 from dje at gcc dot gnu dot org 2006-10-15 02:58 --- The problem is the testcase is written in terms of int. The SUBREGs prevent the combine pattern from being applied. Yes, the testcase fails, but that should be expected as written. Using long and clzl works fine. The bug is the testcase, not the compiler. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-15 02:58:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29056
[Bug c++/2316] g++ fails to overload on language linkage
--- Comment #13 from gcc-bugzilla at kayari dot org 2006-10-15 03:24 --- If this ever gets fixed (which I hope it does) then maybe it should depend on -std=c++98 so this continues to work by default, or it will break a lot of code that incorrectly passes extern C++ functions to e.g. pthread_create and sigaction. That's a lot of code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
Re: [Bug c++/2316] g++ fails to overload on language linkage
On Sun, 2006-10-15 at 03:24 +, gcc-bugzilla at kayari dot org wrote: --- Comment #13 from gcc-bugzilla at kayari dot org 2006-10-15 03:24 --- If this ever gets fixed (which I hope it does) then maybe it should depend on -std=c++98 so this continues to work by default, or it will break a lot of code that incorrectly passes extern C++ functions to e.g. pthread_create and sigaction. That's a lot of code. The problem is -std=c++98 vs no options should not produce different code which can happen as shown in this bug already, that we have wrong code. -- Pinski
[Bug c++/2316] g++ fails to overload on language linkage
--- Comment #14 from pinskia at gmail dot com 2006-10-15 03:29 --- Subject: Re: g++ fails to overload on language linkage On Sun, 2006-10-15 at 03:24 +, gcc-bugzilla at kayari dot org wrote: --- Comment #13 from gcc-bugzilla at kayari dot org 2006-10-15 03:24 --- If this ever gets fixed (which I hope it does) then maybe it should depend on -std=c++98 so this continues to work by default, or it will break a lot of code that incorrectly passes extern C++ functions to e.g. pthread_create and sigaction. That's a lot of code. The problem is -std=c++98 vs no options should not produce different code which can happen as shown in this bug already, that we have wrong code. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug middle-end/29092] [4.0/4.1 Regression] vector int a = (vector int) { 1,1,2,2} is rejected as non constant
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-15 04:04 ---
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00362.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.0.0 4.1.0 4.2.0 |4.0.0 4.1.0
Known to work|3.4.0 |3.4.0 4.2.0
Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] vector
|vector int a = (vector int) |int a = (vector int) {
|{ 1,1,2,2} is rejected as |1,1,2,2} is rejected as non
|non constant|constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29092
