[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-01-28 08:09 --- Correction: upper and lower @@ -1041,6 +1042,12 @@ find_array_element (gfc_constructor *con goto depart; } + /* Make sure we are dealing with constants. */ + if (ar-as-upper[i]-expr_type != EXPR_CONSTANT + || + ar-as-lower[i]-expr_type != EXPR_CONSTANT) + goto depart; + mpz_sub (delta, e-value.integer, ar-as-lower[i]-value.integer); mpz_mul (delta, delta, span); mpz_add (offset, offset, delta); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
[Bug middle-end/34969] [4.3 regression] ICE with -fipa-cp -ffast-math
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-25 10:06:25 |2008-01-28 08:23:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34969
[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-01-28 08:02
---
Found the problem. We are trying to treat an EXPR_FUNCTION as if its an
EXPR_CONSTANT. I doubt the compilation is correct for any platform. Segfault
occurs here at 1053. I tried using gfc_simplify_expr with no luck.
1053 mpz_add (tmp, tmp, ar-as-upper[i]-value.integer);
(gdb) p *ar-as-upper[i]
$1 = {expr_type = EXPR_FUNCTION, ts = {type = BT_UNKNOWN, kind = 0,
derived = 0x0, cl = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN}, rank = 0, shape = 0x0, symtree = 0x10aa91d0,
ref = 0x0, where = {nextc = 0x10ad61af len(HEX1)) = [(1,i=1,len(HEX1))],
lb = 0x10ad6170}, inline_noncopying_intrinsic = 0, is_boz = 0,
con_by_offset = 0x0, representation = {length = 0, string = 0x0}, value = {
logical = 0, integer = {{_mp_alloc = 0, _mp_size = 279614288,
_mp_d = 0x0}}, real = {{_mpfr_prec = 279614288, _mpfr_sign = 0,
_mpfr_exp = 0, _mpfr_d = 0x0}}, complex = {r = {{
_mpfr_prec = 279614288, _mpfr_sign = 0, _mpfr_exp = 0,
_mpfr_d = 0x0}}, i = {{_mpfr_prec = 0, _mpfr_sign = 0,
_mpfr_exp = 0, _mpfr_d = 0x0}}}, op = {
operator = GFC_INTRINSIC_BEGIN, uop = 0x0, op1 = 0x0, op2 = 0x0},
function = {actual = 0x10aa9350, name = 0x0, isym = 0x0, esym = 0x0},
character = {length = 0, string = 0x0}, constructor = 0x10aa9350}}
(gdb)
I am testing this patch:
@@ -1041,6 +1042,12 @@ find_array_element (gfc_constructor *con
goto depart;
}
+ /* Make sure we are dealing with constants. */
+ if (ar-as-upper[i]-expr_type != EXPR_CONSTANT
+ ||
+ ar-as-upper[i]-expr_type != EXPR_CONSTANT)
+ goto depart;
+
mpz_sub (delta, e-value.integer, ar-as-lower[i]-value.integer);
mpz_mul (delta, delta, span);
mpz_add (offset, offset, delta);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-01-28 08:44 --- With this test program derived from the original test case and the patch, gfortran compiles but does not get the results right: module abuse_mod implicit none integer i character(8), parameter :: HEX1 = '40490FDB' integer(1), parameter :: MSKa1(len(HEX1)) = (/(i,i=1,len(HEX1))/) integer(1), parameter :: ARR1(len(HEX1)) = (/( MSKa1(i), i=1,len(HEX1) )/) end module abuse_mod program test use abuse_mod print *, MSKa1 print *, ARR1 end program test ]$ gfc parameter_array_init_3.f90 $ ./a.out 12345678 11111111 $ ifort parameter_array_init_3.f90 $ ./a.out 12345678 12345678 Without the patch gfortran gives correct results on x86-64 and segfaults on compilation on ppc64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #14 from dominiq at lps dot ens dot fr 2008-01-28 09:20 --- At rev. 131891, the test gives the same ICE on ppc/Intel Darwin9, 32 and 64 modes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug target/34995] [4.3 regression] MIPS16 ICE in gcc.c-torture/compile/pr34856.c
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-28 09:16 --- Working on a patch. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2008-01-28 09:16:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34995
[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-28 09:09 --- Without the patch gfortran gives correct results on x86-64 and segfaults on compilation on ppc64. Without the patch, gfortran compiles gfortran.dg/parameter_array_init_3.f90 and gives the correct results for the code in comment #8 on ppc/intel Darwin9 in both 32 and 64 bit modes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
[Bug target/34995] New: [4.3 regression] MIPS16 ICE in gcc.c-torture/compile/pr34856.c
When compiled with -O3 -mips16 -EL -mabi=o64 -funroll-loops,
gcc.c-torture/compile/pr34856.c ICEs with:
pr34856.c:16: error: insn does not satisfy its constraints:
(insn 47 44 278 2
/scratch/richard/gcc/HEAD/gcc/gcc/testsuite/gcc.c-torture/compile/pr34856.c:12
(set (reg:DI 2 $2)
(zero_extend:DI (mem/u/c/i:SI (symbol_ref/u:SI (*$LC1) [flags 0x2])
[4 S4 A32]))) 141 {zero_extendsidi2} (expr_list:REG_EQUIV (zero_extend:DI
(const:SI (plus:SI (symbol_ref:SI (g) [flags 0x40] var_decl 0x2b7ad7741280
g)
(const_int 32 [0x20]
(nil)))
pr34856.c:16: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:395
While the mode of the failure itself is not new, this particular
testcase compiles fine with 4.2.
--
Summary: [4.3 regression] MIPS16 ICE in gcc.c-
torture/compile/pr34856.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC target triplet: mipsisa64-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34995
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-28 10:06 --- Hm, isn't it even 'correct' to propagate a DECL_NO_TBAA_P pointer into uses of a non-DECL_NO_TBAA_P pointer? Of course this shouldn't happen, as then the IL would be wrong. I suppose we can even enforce this via verifying that such copies do not exist (for 4.4). Otherwise I think the patch should go in 4.3, too. Thanks. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug target/34995] [4.3 Regression] MIPS16 ICE in gcc.c-torture/compile/pr34856.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.3 regression] MIPS16 ICE |[4.3 Regression] MIPS16 ICE |in gcc.c- |in gcc.c- |torture/compile/pr34856.c |torture/compile/pr34856.c Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34995
[Bug middle-end/34969] [4.3 regression] ICE with -fipa-cp -ffast-math
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-28 09:52 ---
Fix:
2008-01-28 Jakub Jelinek [EMAIL PROTECTED]
PR middle-end/34969
* tree-inline.c (fold_marked_statements): Update resp. remove
cgraph edges if a call statement has been folded.
* cgraphunit.c (verify_cgraph_node): Set cfun to this_cfun for
debug_generic_stmt calls, reset it back afterwards.
* gcc.dg/pr34969.c: New test.
--- gcc/tree-inline.c.jj2008-01-22 15:03:23.0 +0100
+++ gcc/tree-inline.c 2008-01-28 10:43:17.0 +0100
@@ -2936,9 +2936,48 @@ fold_marked_statements (int first, struc
if (pointer_set_contains (statements, bsi_stmt (bsi)))
{
tree old_stmt = bsi_stmt (bsi);
+ tree old_call = get_call_expr_in (old_stmt);
+
if (fold_stmt (bsi_stmt_ptr (bsi)))
{
update_stmt (bsi_stmt (bsi));
+ if (old_call)
+ {
+ /* Update or remove corresponding cgraph edge if
something changed. */
+ tree new_stmt = bsi_stmt (bsi);
+ tree new_call = get_call_expr_in (new_stmt);
+ struct cgraph_node *node = cgraph_node (cfun-decl);
+
+ if (old_call != new_call)
+ {
+ struct cgraph_edge *e = cgraph_edge (node, old_stmt);
+ struct cgraph_edge *ne = NULL;
+ tree new_decl;
+
+ if (e)
+ {
+ if (new_call)
+ {
+ new_decl = get_callee_fndecl (new_call);
+ if (new_decl)
+ {
+ ne = cgraph_create_edge (node,
cgraph_node (new_decl),
+ new_stmt,
e-count, e-frequency,
+ e-loop_nest);
+ ne-inline_failed = e-inline_failed;
+ }
+ }
+ cgraph_remove_edge (e);
+ }
+ }
+ else if (old_stmt != new_stmt)
+ {
+ struct cgraph_edge *e = cgraph_edge (node, old_stmt);
+
+ if (e)
+ cgraph_set_call_stmt (e, new_stmt);
+ }
+ }
if (maybe_clean_or_replace_eh_stmt (old_stmt, bsi_stmt
(bsi)))
tree_purge_dead_eh_edges (BASIC_BLOCK (first));
}
--- gcc/cgraphunit.c.jj 2008-01-28 09:30:03.0 +0100
+++ gcc/cgraphunit.c2008-01-28 09:31:03.0 +0100
@@ -658,6 +658,7 @@ verify_cgraph_node (struct cgraph_node *
struct cgraph_edge *e;
struct cgraph_node *main_clone;
struct function *this_cfun = DECL_STRUCT_FUNCTION (node-decl);
+ struct function *saved_cfun = cfun;
basic_block this_block;
block_stmt_iterator bsi;
bool error_found = false;
@@ -666,6 +667,8 @@ verify_cgraph_node (struct cgraph_node *
return;
timevar_push (TV_CGRAPH_VERIFY);
+ /* debug_generic_stmt needs correct cfun */
+ set_cfun (this_cfun);
for (e = node-callees; e; e = e-next_callee)
if (e-aux)
{
@@ -808,6 +811,7 @@ verify_cgraph_node (struct cgraph_node *
dump_cgraph_node (stderr, node);
internal_error (verify_cgraph_node failed);
}
+ set_cfun (saved_cfun);
timevar_pop (TV_CGRAPH_VERIFY);
}
--- gcc/testsuite/gcc.dg/pr34969.c.jj 2008-01-28 10:45:55.0 +0100
+++ gcc/testsuite/gcc.dg/pr34969.c 2008-01-28 10:45:29.0 +0100
@@ -0,0 +1,15 @@
+/* PR middle-end/34969 */
+/* { dg-do compile } */
+/* { dg-options -O -fipa-cp -ffast-math } */
+
+double
+foo (double x)
+{
+ return x * x;
+}
+
+double
+bar (void)
+{
+ return foo (0);
+}
If any call is folded during ipa-cp, we IMHO have to update cgraph edges,
otherwise cgraph verification afterwards can't succeed. Honza, does this make
sense or should it be done elsewhere? Haven't bootstrapped/regtested this yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34969
[Bug c/34993] [4.1/4.2/4.3 regression] ICE with attribute for array with unknown bound
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-28 09:56 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-01-28 09:56:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34993
[Bug middle-end/34992] compiler produces wrong code when optimizing
--- Comment #8 from roebel at ircam dot fr 2008-01-28 10:00 ---
For completeness :
I now use this function that was proposed in
PR 323. It seems to solve my issue. Thanks for the pointer!
inline
void set_math_double_precision() {
fpu_control_t fpu_control ;
_FPU_GETCW(fpu_control);
fpu_control = (fpu_control ~_FPU_EXTENDED) | _FPU_DOUBLE;
_FPU_SETCW(fpu_control);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34992
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #9 from jakub at gcc dot gnu dot org 2008-01-28 10:25 --- Ian, the testcase would be new16.C after removing CHANGE_DYNAMIC_TYPE_EXPR stuff (to fix this PR). Or do you propose to keep CHANGE_DYNAMIC_TYPE_EXPR in 4.3 (which looks redundant with PR33407) and just hack it up to avoid doing it if operator new second argument is a reference to pointer rather than a pointer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug middle-end/34973] Wno-strict-aliasing is not working
--- Comment #9 from manu at gcc dot gnu dot org 2008-01-28 10:45 --- Christoph, we need a testcase to be able to reproduce the bug, otherwise, we cannot fix it. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34973
[Bug middle-end/34973] Wno-strict-aliasing is not working
--- Comment #10 from manu at gcc dot gnu dot org 2008-01-28 10:51 --- (In reply to comment #8) (In reply to comment #6) But shouldn't -Wno-strict-aliasing suppress the warning? Yes if you actually have -Wno-strict-aliasing after -Wall. Andrew, note that this is not longer true in 4.2.3 and 4.3. -Wall won't override -Wno-strict-aliasing and it won't override -Wstrict-aliasing=2 (and the same for -Wstrict-overflow variants) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34973
[Bug middle-end/34969] [4.3 regression] ICE with -fipa-cp -ffast-math
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-28 11:11 --- I suppose a simpler fix for 4.3 would be to not fold call stmts here. Otherwise moving the cgraph adjustment to a helper function in cgraph.c would look nicer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34969
[Bug fortran/34975] [4.3 Regression] Bogus error with USEing modules
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-28 11:09 --- Created an attachment (id=15033) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15033action=view) [edit] A patch for this regression I have just put this on to bootstrap and regtest whilst I sleep. Since it changes nothing in the basic mechanism I believe that it will be OK. In fact, I already tested gfortran.dg/use*.f90 I had to change the gfc_undo_symbols part of the patch as gfc_undo_symbols changed completely on the trunk. (Error recovery for COMMON [by Daniel Franke]) Fixing that, it bootstrapped and regtested (-m32/-m64 incl. gomp) successfully on x86-64-linux. I also re-build Quantum ESPRESSO (which was failing before), CP2K, Fleur, Exciting, Octopus, and Abinit successfully. And I've run the Unicomp Fortran 90 Test Suite (Lite) with no new failures. (The current failures seem to be test suit bugs.) Thanks for digging and for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34975
[Bug target/34856] [4.2/4.3 Regression] ICE with some constant vectors
--- Comment #26 from ubizjak at gmail dot com 2008-01-28 12:04 --- *** Bug 34995 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
[Bug target/34995] [4.3 Regression] MIPS16 ICE in gcc.c-torture/compile/pr34856.c
--- Comment #2 from ubizjak at gmail dot com 2008-01-28 12:04 --- *** This bug has been marked as a duplicate of 34856 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34995
[Bug fortran/34975] [4.3 Regression] Bogus error with USEing modules
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-28 12:25 --- My tests have not been as exhaustive as the Tobias' ones, but the patch worked as advertised without regression on ppc/intel Darwin9, 32 and 64 bit modes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34975
[Bug middle-end/34969] [4.3 regression] ICE with -fipa-cp -ffast-math
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-28 12:39 --- No, I mean providing something like cgraph_update_edges_for_call_stmt (tree old, tree new); or alternatively cgraph_remove_edge_from_call_stmt () and cgraph_add_edge_from_call_stmt () and call those two unconditionally. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34969
[Bug middle-end/34969] [4.3 regression] ICE with -fipa-cp -ffast-math
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-28 12:34 --- Not folding CALL_EXPRs would introduce a regression on g++.dg/opt/devirt1.C, after all fold_marked_statements has been added exactly to fix that regression: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00165.html Regarding the helper function, do you mean a wrapper around fold_stmt which will do the cgraph edge updates? As fold_stmt can change the whole stmt, the helper function needs to know the old as well as new statement to do the updates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34969
[Bug rtl-optimization/34998] [4.3 Regression] gcc.c-torture/execute/20040709-1.c fails for -EL -mips16 -O3
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-28 14:40 --- Testing a patch. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2008-01-28 14:40:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34998
[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-28 14:33 --- The polyhedron test aermod.f90 fails with: aermod.f90: In function 'wake_dfsn2': aermod.f90:37741: error: unrecognizable insn: (insn 574 3142 575 38 (parallel [ (set (reg:V4SF 188 [ vect_cst_.30783 ]) (reg:V4SF 1847)) (unspec [ (const_int 0 [0x0]) ] 196) ]) -1 (nil)) aermod.f90:37741: internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1564 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I think it is the same bug. Has it a chance to be fixed for 4.3.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
[Bug c++/28560] [4.1/4.2 regression] Trouble with __attribute__ in template parameter
--- Comment #6 from jason at gcc dot gnu dot org 2008-01-28 15:38 --- Not going to bother fixing on other branches. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.1.3 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28560
[Bug rtl-optimization/34998] [4.3 Regression] gcc.c-torture/execute/20040709-1.c fails for -EL -mips16 -O3
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34998
[Bug rtl-optimization/34999] New: Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn
I run built-in-setjmp.c testcase (taken from gcc.c-torture/execute dir); first with -fprofile-generate -freorder-blocks-and-partition and then with -fprofile-use -freorder-blocks-and-partition under x86_64 and ppc64-linux with r131883 mainline and I get the ICE: vn/build/build/spu/gcc/gcc/testsuite/gcc/built-in-setjmp.c -fprofile-use -freorder-blocks-and-partition ../gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c: In function âmainâ: ../gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:39: internal compiler error: in add_labels_and_missing_jumps, at bb-reorder.c:1304 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The code for fixing up fallthru edges that cross between hot and cold sections is in add_labels_and_missing_jumps () and fix_up_fall_thru_edges () functions. The first function deals with fallthru edges with single successor and the later deals with fallthru edges with more than one successor. It seems that the cause to this fail is because both of the functions do not take into account the fact that a basic-block with a crossing edge can end with a call insn. I am working to fix that. -- Summary: Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
[Bug fortran/34997] New: Common vendor extension: Support symbol names containing $
This seems to be a common vendor extension. Example: REAL*4 PLT$C_HOUSTPIX INTEGER PLT$C_COMMAND PARAMETER (PLT$B_OPC=0) common /abc$def/ PLT$C_HOUSTPIX, PLT$C_COMMAND end This compiles using NAG f95 (with the warning Extension: Name contains $ character) and with ifort, sunf95, openf95. With -stand f95 also ifort warns (Invalid use of $ character in identifier). While gfortran rejects it completely (syntax error). -- Summary: Common vendor extension: Support symbol names containing $ Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34997
[Bug c++/33959] [4.1 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
--- Comment #13 from jason at gcc dot gnu dot org 2008-01-28 16:28 --- Subject: Bug 33959 Author: jason Date: Mon Jan 28 16:27:17 2008 New Revision: 131907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131907 Log: PR c++/27177 * class.c (build_base_path): Fix previous change. PR c++/27177 * class.c (build_base_path): Don't mess with virtual access if skip_evaluation. * call.c (standard_conversion): Don't check whether source type is complete. PR c++/33959 * pt.c (tsubst_aggr_type): Make sure our context is complete. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/call.c branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug c++/33959] [4.1 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
--- Comment #14 from jason at gcc dot gnu dot org 2008-01-28 16:28 --- Fixed in all open branches. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug c++/27177] [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #29 from jason at gcc dot gnu dot org 2008-01-28 16:19 --- Subject: Bug 27177 Author: jason Date: Mon Jan 28 16:18:56 2008 New Revision: 131905 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131905 Log: PR c++/27177 * class.c (build_base_path): Fix previous change. PR c++/27177 * class.c (build_base_path): Don't mess with virtual access if skip_evaluation. * call.c (standard_conversion): Don't check whether source type is complete. Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/cp/class.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn
--- Comment #1 from eres at il dot ibm dot com 2008-01-28 15:22 --- Created an attachment (id=15037) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15037action=view) the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
[Bug c++/27177] [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #30 from jason at gcc dot gnu dot org 2008-01-28 16:28 --- Subject: Bug 27177 Author: jason Date: Mon Jan 28 16:27:17 2008 New Revision: 131907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131907 Log: PR c++/27177 * class.c (build_base_path): Fix previous change. PR c++/27177 * class.c (build_base_path): Don't mess with virtual access if skip_evaluation. * call.c (standard_conversion): Don't check whether source type is complete. PR c++/33959 * pt.c (tsubst_aggr_type): Make sure our context is complete. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/call.c branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug fortran/34997] Common vendor extension: Support symbol names containing $
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-28 17:09 ---
Thanks for the pointer. I think we need in general to update some of the error
message to point to the relevant option. (For the most common, namely
-fno-range-check we do so already; for -std=f* related ones we partially do
(Fortran 2003, Extension:) though I think not consistently -std=legacy.)
For $ I think the following should be OK for 4.4.0.
Index: match.c
===
--- match.c (Revision 131899)
+++ match.c (Arbeitskopie)
@@ -519,6 +519,13 @@ gfc_match_name (char *buffer)
}
while (ISALNUM (c) || c == '_' || (gfc_option.flag_dollar_ok c == '$'));
+ if (c == '$' !gfc_option.flag_dollar_ok)
+{
+ gfc_error (Invalid '$' character at %C. Use -fdollar-ok to accept it);
+ return MATCH_ERROR;
+}
+
+
buffer[i] = '\0';
gfc_current_locus = old_loc;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34997
[Bug fortran/34997] Common vendor extension: Support symbol names containing $
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-28 17:30 --- Invalid code should be diagnosed. Since this particular case even has a flag to accept the invalid code, the hard error is fine IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34997
[Bug fortran/31463] gfortran prints no warning message when an unset return value is an array
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-01-28 14:45 --- Confirmed. Interestingly: $ cat pr31463.f90 FUNCTION test() RESULT(f) REAL :: f ! removed DIMENSION statement END FUNCTION test $ gfortran-svn -g -Wall -c pr31463.f90 pr31463.f90:1.25: FUNCTION test() RESULT(f) 1 Warning: Unused variable 'f' declared at (1) pr31463.f90: In function 'test': pr31463.f90:1: warning: Function return value not set pr31463.f90:1: warning: control reaches end of non-void function $ gfortran-svn -v gcc version 4.3.0 20080125 (experimental) However, the last three lines are issued from the middle-end. On general agreement, we don't want this to happen. I think, an additional attribute, e.g. 'is_function_result' should be added to the symbol (if not otherwise flagged yet). Then, trans_decl.c (generate_local_decl) could check for this flag, issue a warning and set TREE_NO_WARNING to gag the middle-end. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Last reconfirmed|2007-04-18 06:51:53 |2008-01-28 14:45:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31463
[Bug rtl-optimization/34998] New: [4.3 Regression] gcc.c-torture/execute/20040709-1.c fails for -EL -mips16 -O3
gcc.c-torture/execute/20040709-1.c fails for -EL -mips16 -O3 with: 20040709-1.c:93: internal compiler error: in insert_save, at caller-save.c:745 This is due to the new subreg liveness checking. We have a bb with: A: call ... B: set of (subreg:HI (reg:SI foo)) ... C: use of (reg:SI foo) and no other references to (reg:SI foo) in the function. We allocate FOO a call-clobbered register, and wrongly think that it is still live at A. This is because global.c:build_insn_chain tracks the liveness of each byte of FOO separately, and wrongly thinks that the B leaves the upper two bytes live. (SUBREG lvalues clobber the whole word span, not just the byte span.) -- Summary: [4.3 Regression] gcc.c-torture/execute/20040709-1.c fails for -EL -mips16 -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rsandifo at gcc dot gnu dot org GCC target triplet: mipsisa64-elfoabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34998
[Bug fortran/34997] Common vendor extension: Support symbol names containing $
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-28 16:34 --- See also http://gcc.gnu.org/ml/fortran/2007-01/msg00060.html specifically the PS ... -fdollar-ok there. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34997
[Bug target/34995] [4.3 Regression] MIPS16 ICE in gcc.c-torture/compile/pr34856.c
--- Comment #3 from rsandifo at gcc dot gnu dot org 2008-01-28 13:43 --- This isn't the same thing as PR34856. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34995
[Bug target/31535] ICE on attempt to put SPE vector variables in SDA
--- Comment #2 from froydnj at gcc dot gnu dot org 2008-01-28 18:32 --- Subject: Bug 31535 Author: froydnj Date: Mon Jan 28 18:31:19 2008 New Revision: 131914 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131914 Log: gcc/ PR 31535 * config/rs6000/rs6000.c (small_data_operand): Vectors and floats are not legitimate small data references on SPE targets. gcc/testsuite/ PR 31535 * gcc.target/powerpc/spe-small-data-1.c: New test. * gcc.target/powerpc/spe-small-data-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/spe-small-data-1.c trunk/gcc/testsuite/gcc.target/powerpc/spe-small-data-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31535
[Bug c++/35000] New: #include sometimes fails in namespaces
When including a system header in a namespace followed by another system header
seems to prevent declarations being recognized in the headers or some such.
Even happens when the headers are both the same.
Example code:
#ifndef APP_H
#define APP_H
namespace win
{
#include string
}
#include iostream
#endif
--
Summary: #include sometimes fails in namespaces
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mw268 at bath dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35000
[Bug libfortran/34980] [4.3 Regression] Segfault in shape given a scalar
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-01-28 19:03 --- Subject: Bug 34980 Author: tkoenig Date: Mon Jan 28 19:02:47 2008 New Revision: 131915 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131915 Log: 2008-01-27 Thomas Koenig [EMAIL PROTECTED] PR libfortran/34980 * m4/shape.m4: If return array is empty, return early. * generated/shape_i4.c: Regenerated. * generated/shape_i8.c: Regenerated. * generated/shape_i16.c: Regenerated. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/generated/shape_i16.c trunk/libgfortran/generated/shape_i4.c trunk/libgfortran/generated/shape_i8.c trunk/libgfortran/m4/shape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34980
[Bug libfortran/34980] [4.3 Regression] Segfault in shape given a scalar
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-28 17:26 --- Subject: Bug 34980 Author: burnus Date: Mon Jan 28 17:25:55 2008 New Revision: 131913 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131913 Log: 2008-01-28 Tobias Burnus [EMAIL PROTECTED] PR libfortran/34980 * simplify.c (gfc_simplify_shape): Simplify rank zero arrays. 2008-01-28 Thomas Koenig [EMAIL PROTECTED] PR libfortran/34980 * gfortran.dg/shape_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/shape_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34980
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #11 from ian at gcc dot gnu dot org 2008-01-28 19:44 --- Subject: Bug 34862 Author: ian Date: Mon Jan 28 19:43:51 2008 New Revision: 131916 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131916 Log: PR c++/34862 PR c++/33407 * tree-ssa-copyrename.c (copy_rename_partition_coalesce): Don't coalesce pointers if they have different DECL_NO_TBAA_P values. * tree-ssa-copy.c (may_propagate_copy): Don't propagate copies between variables with different DECL_NO_TBAA_P values. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-copy.c trunk/gcc/tree-ssa-copyrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #18 from aldot at gcc dot gnu dot org 2008-01-28 17:59 --- Created an attachment (id=15038) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15038action=view) use conditional $(BUILD_INFO) variable for prerequs of info and install-info targets Use the variable $(BUILD_INFO) to decide whether or not info-pages are to be installed. This follows mark's comment #8 above but does not yet remove the testing of $(BUILD_INFO) in gcc/*/Make-lang.in . A tested patch which removes these now superfluous checks will follow. Michael's treelang-noinfo.patch looks inappropriate (there is no 'install-' target AFAICS, so install would fail never the less), so i consider the approval nil, sorry. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Attachment #11419|0 |1 is obsolete|| Attachment #11494|0 |1 is obsolete|| Attachment #14730|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug middle-end/34969] [4.3 regression] ICE with -fipa-cp -ffast-math
--- Comment #6 from hubicka at ucw dot cz 2008-01-28 20:51 --- Subject: Re: [4.3 regression] ICE with -fipa-cp -ffast-math No, I mean providing something like cgraph_update_edges_for_call_stmt (tree old, tree new); or alternatively cgraph_remove_edge_from_call_stmt () and cgraph_add_edge_from_call_stmt () and call those two unconditionally. My stragegy so far was to rebuild cgraph edges from scratch when needed (that is something possibly changed). We can probably handle that via function local TODO flag here too. Updating the edges across multiple passes is kind of sliperly, since we would need to tie cgraph a lot more with gimple, pretty much as we do for CFG. This seems too much pie in the sky project with current organization of trees and folders, I hope that with tuples we will have a lot closer correspondence in between actual statements and calls here. Since we need to have edges up to date across inliner, I guess the patch is fine (as would be addint the TODO flag). Thanks for looking into it! Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34969
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #20 from aldot at gcc dot gnu dot org 2008-01-28 20:43 --- (In reply to comment #19) In your patch, why does install-info still need doc and installdirs dependencies when BUILD_INFO is not set? If those things still need to happen, shouldn't they be dependencies of some other target? Logically, if BUILD_INFO is not set, then install-info should be a no-op. I kept them due to precaution but ultimately they shouldn't be needed for install-info itself, yes. Will test how this works out with MAKEINFO=/bin/false and an old makeinfo before i attach a complete patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug fortran/35003] New: spurious warning using -Wconversion, a do loop, and 8 byte integers
Part of original report:
I have recently had the chance to compile some code using -Wconversion and a
loop that may iterate more than 2.2 billion times. There is a compiler warning
of this sort which I cannot resolve:
nell:~/work/bit barnes$ gfortran -Wconversion -o t.x testcase.f
testcase.f:7.16:
do i=1_8,n
1
Warning: Conversion from INTEGER(4) to INTEGER(8) at (1)
---
program testcase
implicit none
integer(8) i,n
n=1_8
do i=1_8,n
enddo
end
---
The only variables in the testcase are 8-byte integers, yet I get that
conversion warning. I skimmed the gfortran bugzilla and did not notice
anything similar. If the loop is executed 2.2 billion times (n=2 200 000
000_8), it does run each instance, so I know the do loop is not being truncated
at the limit of a 4-byte integer.
---
nell:~/work/bit barnes$ gfortran -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: ../gcc-4.2.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.2
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-arch=nocona
--with-tune=generic --host=i686-apple-darwin8 --with-gmp=/sw
--with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.2.2
Part of reply from Tobias Burnus (he asked me to file a bug report):
The problem is that the iterator step variable is INTEGER(4) [implicitly added
1_4 (gfc_int_expr (1);)]:
do i = 1_8, n, 1_4
Something like the following should work:
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 131912)
+++ gcc/fortran/match.c (working copy)
@@ -958,6 +965,8 @@ gfc_match_iterator (gfc_iterator *iter,
if (gfc_match_char (',') != MATCH_YES)
{
e3 = gfc_int_expr (1);
+ if (var-ts.type == BT_INTEGER)
+ e3-ts.kind = var-ts.kind;
goto done;
}
--
Summary: spurious warning using -Wconversion, a do loop, and 8
byte integers
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bcbarnes at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35003
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #10 from ian at airs dot com 2008-01-28 18:12 --- I'm not proposing to remove CHANGE_DYNAMIC_TYPE_EXPR from 4.3 at this point. We have some experience with it in, and I don't think we should take it out. I haven't looked at the actual bug here yet, I was responding to your point in comment #3, where I think you found a theoretical possibility which could break the patch for PR 33407. -- ian at airs dot com changed: What|Removed |Added CC|ian at gcc dot gnu dot org |ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #19 from mmitchel at gcc dot gnu dot org 2008-01-28 18:12 --- In your patch, why does install-info still need doc and installdirs dependencies when BUILD_INFO is not set? If those things still need to happen, shouldn't they be dependencies of some other target? Logically, if BUILD_INFO is not set, then install-info should be a no-op. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-28 18:09 ---
I think the size is simply calculated as:
ubound[n] + 1 - lbound[n];
which means:
5+1-8 = -2
At some point the variable is regarded as unsigned which means (for 8 byte
variables): 18446744073709551614, which is not unexpected to be too large. (I'm
ignoring here the byte-size of complex(4) and the other dimensions).
The actual size is of cause 0 as the shape is 2 0 2 2.
I think we have several places where a zero-sized array makes problems (cf.
e.g. PR34980 for SHAPE). For this PR one probably needs to fix
gfc_trans_create_temp_array, where size is calculated as follows:
size = 1;
for (n = 0; n rank; n++)
{
stride[n] = size
delta = ubound[n] + 1 - lbound[n];
size = size * delta;
}
size = size * sizeof(element);
But maybe also something else.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2008-01-28 18:09:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
--- Comment #15 from dgregor at gcc dot gnu dot org 2008-01-28 21:35 --- Thanks everyone; I can reproduce this on i686-pc-linux-gnu. Patch in the works. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2008-01-16 13:40:59 |2008-01-28 21:35:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug libfortran/34980] [4.3 Regression] Segfault in shape given a scalar
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-28 17:39 --- The commit fixed the SHAPE(scalar) problem in the front end. For the library to do: a) The following should print 1 0 but it prints 1 -8: integer :: i,j, a(10,10),res(2) j = 1 i = 10 res = shape(a(1:1,i:j:1)) print *, res res = shape(a(1:1,j:i:-1)) print *, res end b) The following should be diagnosed with -fbounds-check. NAG -C=all prints: Rank 1 of array operand has extent 2 instead of 0 integer :: i,j, a(10,10),res(2) j = 1 i = 10 res = [42, 24 ] res(2:j) = shape(a(1:1,i:j)) print *, res end I do not know whether one should check this also without -fbounds-check. I think it is not needed; however, the other compilers seem to have such a check as they print 42 24 (i.e. res is not modified) whereas gfortran prints 42 1. As it is invalid, both choices are OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34980
[Bug c++/34996] New: Base class of explicitly instantiated class doesn't get instantiated
test.h:
struct Base
{
virtual int getX() const=0;
};
template typename ThisType class Derived1: public Base
{
protected:
static const int X;
public:
virtual int getX() const{ return X; }
};
templateint id class Derived2 : public Derived1Derived2id {};
test.cpp:
#include test.h
templatetypename U const int Derived1U::X = 0;
template class Derived21;
// template class Derived1Base, Derived2::StaticImpl1 ; //that shouldn't be
necessary
main.cpp:
#include test.h
int main()
{
Base r = *new Derived2 1 ();
};
g++ main.cpp test.cpp
/tmp/ccyQeFe1.o: In function `Derived1Derived21 ::getX() const':
main.cpp:(.text._ZNK8Derived1I8Derived2ILi1EEE4getXEv[Derived1Derived21
::getX() const]+0x4): undefined reference to `Derived1Derived21 ::X'
collect2: ld returned 1 exit status
gcc doesn't to instantiate Derived1Base, Derived2::StaticImpl1 - the
Base class of the explicitly instantiated Derived21
some curiosities:
1. outlining getX() into test.cpp makes it work
2. using g++ test.cpp main.cpp (just reversing the order of the files on the
cmd line) works(!), but compiling each file individually and then linking it
breaks.
I can recognise this behaviour with 3.4.6, 4.1.2, 4.2.2 and 4.3 (snapshot from
20080125)
--
Summary: Base class of explicitly instantiated class doesn't get
instantiated
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34996
[Bug c++/32029] [4.1/4.2/4.3 regression] ICE on instantiation of template parameter
--- Comment #7 from jason at gcc dot gnu dot org 2008-01-28 16:33 --- The version with class is also valid. 14.6p5: A qualified name used as the name in a mem-initializer-id, a base-specifier, or an elaborated-type-specifier is implicitly assumed to name a type, without the use of the typename keyword. Fixed by the patch for 33959. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32029
[Bug translation/35002] Incorrect spelling of hottest
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-28 21:47 --- Confirmed. Also wrong: gcc/ipa-struct-reorg.c:sum_counts (d_str str, gcov_type *hotest) gcc/ipa-struct-reorg.c: if (str-count *hotest) gcc/ipa-struct-reorg.c:*hotest = str-count; gcc/ipa-struct-reorg.c: gcov_type hotest = 0; gcc/ipa-struct-reorg.c:sum_counts (str, hotest); gcc/ipa-struct-reorg.c:if (str-count * 100 (hotest * STRUCT_REORG_COLD_STRUCT_RATIO)) gcc/params.def:/* The threshold ratio between current and hotest structure counts. gcc/params.def: calculated by profiling, to the hotest structure count gcc/params.def: The threshold ratio between current and hotest structure counts, -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org Severity|trivial |normal Status|UNCONFIRMED |NEW Component|c |translation Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-28 21:47:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35002
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #12 from ian at airs dot com 2008-01-28 21:52 --- Created an attachment (id=15039) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15039action=view) Possible patch Here is a very ugly patch which appears to fix the problem in mainline. I haven't tested it, though. Any opinions? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug c++/34913] [4.1/4.2 Regression] ICE vector in template
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-01-28 21:52 --- This is fixed on the trunk. Marking it as such... -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34913
[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type
--- Comment #15 from ian at gcc dot gnu dot org 2008-01-28 19:44 --- Subject: Bug 33407 Author: ian Date: Mon Jan 28 19:43:51 2008 New Revision: 131916 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131916 Log: PR c++/34862 PR c++/33407 * tree-ssa-copyrename.c (copy_rename_partition_coalesce): Don't coalesce pointers if they have different DECL_NO_TBAA_P values. * tree-ssa-copy.c (may_propagate_copy): Don't propagate copies between variables with different DECL_NO_TBAA_P values. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-copy.c trunk/gcc/tree-ssa-copyrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
[Bug c++/34055] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-01-28 22:05 --- Darn! Mine again. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2007-12-20 21:02:29 |2008-01-28 22:05:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34055
[Bug c++/34961] [4.3 Regression] ICE with invalid use of parameter pack in attribute
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-25 09:53:35 |2008-01-28 21:40:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34961
[Bug c++/34919] [4.3 Regression] ICE with invalid use of parameter pack
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-01-28 21:58 --- Yep, we should be diagnosing but this error but we aren't. I'm on it. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-22 10:56:51 |2008-01-28 21:58:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34919
[Bug libfortran/34980] [4.3 Regression] Segfault in shape given a scalar
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-01-28 19:07 --- Fixed on trunk. Closing (so we're one regression down). (In reply to comment #7) The commit fixed the SHAPE(scalar) problem in the front end. a) The following should print 1 0 but it prints 1 -8: integer :: i,j, a(10,10),res(2) j = 1 i = 10 res = shape(a(1:1,i:j:1)) print *, res res = shape(a(1:1,j:i:-1)) print *, res end Now tracked as PR 35001. b) The following should be diagnosed with -fbounds-check. NAG -C=all prints: Rank 1 of array operand has extent 2 instead of 0 integer :: i,j, a(10,10),res(2) j = 1 i = 10 res = [42, 24 ] res(2:j) = shape(a(1:1,i:j)) print *, res end Noted in PR 34670. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34980
[Bug libfortran/35001] shape for negative sizes
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-28 19:08:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35001
[Bug target/34995] [4.3 Regression] MIPS16 ICE in gcc.c-torture/compile/pr34856.c
-- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2008-01-28 09:16:56 |2008-01-28 13:43:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34995
[Bug c++/34487] [4.1/4.2/4.3 regression] ICE using class instead of typename
--- Comment #4 from jason at gcc dot gnu dot org 2008-01-28 16:34 --- As explained in 32029, this code is valid. Fixed by the patch for 33959. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34487
[Bug c++/34892] [4.3 regression] ICE with ellipsis in default template argument
--- Comment #1 from dgregor at gcc dot gnu dot org 2008-01-28 21:59 --- Confirmed. This is mine. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-21 10:10:51 |2008-01-28 21:59:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34892
[Bug c/35002] New: Incorrect spelling of hottest
In gcc/params.def there is a message The threshold ratio between current and hotest structure counts Unless I'm mistaken, the correct spelling is hottest. -- Summary: Incorrect spelling of hottest Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35002
[Bug libstdc++/35000] #include sometimes fails in namespaces
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-28 19:02 --- This is working as designed. Why are you doing #include inside a namespace anyways? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35000
[Bug debug/31510] [4.3 Regression] FAIL: libgomp.fortran/threadprivate[23].f90 -O3 -g
--- Comment #5 from danglin at gcc dot gnu dot org 2008-01-28 22:19 --- This was introduced by the addition of generic TLS support. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Component|libgomp |debug Summary|FAIL: |[4.3 Regression] FAIL: |libgomp.fortran/threadprivat|libgomp.fortran/threadprivat |e[23].f90 -O3 -g |e[23].f90 -O3 -g http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31510
[Bug libfortran/35001] New: shape for negative sizes
From PR 34980, comment#7 by Tobias Burnus: a) The following should print 1 0 but it prints 1 -8: integer :: i,j, a(10,10),res(2) j = 1 i = 10 res = shape(a(1:1,i:j:1)) print *, res res = shape(a(1:1,j:i:-1)) print *, res end Not a regression. -- Summary: shape for negative sizes Product: gcc Version: unknown Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35001
[Bug target/34412] ICE in extract_insn, at recog.c:1990
--- Comment #7 from aesok at gcc dot gnu dot org 2008-01-28 22:49 --- Fixed in HEAD (4.3) -- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34412
[Bug c++/34913] [4.1/4.2 Regression] ICE vector in template
--- Comment #9 from jason at gcc dot gnu dot org 2008-01-28 22:01 --- changed target milestone. -- jason at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.3 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34913
[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #19 from dorit at gcc dot gnu dot org 2008-01-28 13:20 --- Fixed? In a way, yes. The problem is avoided by generating too conservative code. AFAIU, a better solution may be expected in 4.4 from the stack alignment branch. In any case this segfault PR can be closed, and instead a missed optimization PR could be opened. -- dorit at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
[Bug c++/34606] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-28 22:08 --- This one's mine. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-16 21:50:58 |2008-01-28 22:08:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34606
[Bug target/34412] ICE in extract_insn, at recog.c:1990
--- Comment #6 from aesok at gcc dot gnu dot org 2008-01-28 22:40 --- Subject: Bug 34412 Author: aesok Date: Mon Jan 28 22:39:11 2008 New Revision: 131923 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131923 Log: PR target/34412 * config/avr/avr.c (expand_prologue): Use correct QI mode frame pointer for tiny stack. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34412
[Bug fortran/34997] Common vendor extension: Support symbol names containing $
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-28 17:21 --- I always wonder if a hard error is really necessary for such cases? would not a warning be sufficient? I think there is a flag to change warnings to errors if necessary (-Werror?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34997
[Bug c++/34219] gcc doesn't accept const members of variadic templates as const (regression)
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-28 23:40 --- There are some problems with the example code. For example, the expression maxT, Params does not expand the parameter pack Params. The compiler should have warned you about this, both in this case and in the static_assert case. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Keywords|rejects-valid |error-recovery, ice-on- ||invalid-code Summary|gcc doesn't accept const|gcc doesn't accept const |members of variadic |members of variadic |templates as const |templates as const ||(regression) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34219
[Bug tree-optimization/35006] [4.3 Regression] Segfault in remove_unused_locals
--- Comment #2 from tbm at cyrius dot com 2008-01-29 00:18 --- Created an attachment (id=15042) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15042action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35006
[Bug tree-optimization/35006] [4.3 Regression] Segfault in remove_unused_locals
--- Comment #1 from tbm at cyrius dot com 2008-01-29 00:17 --- Program received signal SIGSEGV, Segmentation fault. remove_unused_locals () at gcc/tree-ssa-live.c:587 587 var_ann (t)-used = false; (gdb) where #0 remove_unused_locals () at gcc/tree-ssa-live.c:587 #1 0x006453ad in execute_function_todo (data=value optimized out) at gcc/passes.c:918 #2 0x0064512f in execute_todo (flags=3984896320) at gcc/passes.c:993 #3 0x0064564f in execute_one_pass (pass=0xf63820) at gcc/passes.c:1144 #4 0x006457bc in execute_pass_list (pass=0xf63820) at gcc/passes.c:1175 #5 0x00720c36 in tree_rest_of_compilation (fndecl=0x2afeed7ca270) at gcc/tree-optimize.c:404 #6 0x008ce002 in cgraph_expand_function (node=0x2afeed820500) at gcc/cgraphunit.c:1153 #7 0x008d0328 in cgraph_optimize () at gcc/cgraphunit.c:1216 #8 0x00414d7e in c_write_global_declarations () at gcc/c-decl.c:8079 #9 0x006c1a9e in toplev_main (argc=value optimized out, argv=value optimized out) at gcc/toplev.c:1055 #10 0x2afeed34b1c4 in __libc_start_main () from /lib/libc.so.6 #11 0x004043d9 in _start () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35006
[Bug tree-optimization/35006] New: [4.3 Regression] Segfault in remove_unused_locals
With trunk: (sid)4409:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -O3 ~/grub2-cmdline.i /home/tbm/src/grub2-1.95+20080128/normal/cmdline.c: In function 'grub_cmdline_get': /home/tbm/src/grub2-1.95+20080128/normal/cmdline.c:216: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 Regression] Segfault in remove_unused_locals Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35006
[Bug middle-end/35004] Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers
--- Comment #2 from michael dot meissner at amd dot com 2008-01-29 00:10 --- Created an attachment (id=15041) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15041action=view) Traceback for 35005 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
[Bug c++/35004] New: Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers
If I add 4 more tree codes to tree.def, it causes a segmentation violation in building libstdc++ pre-compiled header files. Here is the patch to add 4 more tree codes: --- gcc/tree.def.~1~2007-11-01 11:59:47.0 -0400 +++ gcc/tree.def2008-01-28 16:01:36.0 -0500 @@ -682,6 +682,13 @@ DEFTREECODE (RSHIFT_EXPR, rshift_expr, DEFTREECODE (LROTATE_EXPR, lrotate_expr, tcc_binary, 2) DEFTREECODE (RROTATE_EXPR, rrotate_expr, tcc_binary, 2) +/* Vector/vector shifts, where both arguments are vector types. This is only + used during the expansion of shifts and rotates. */ +DEFTREECODE (VLSHIFT_EXPR, vlshift_expr, tcc_binary, 2) +DEFTREECODE (VRSHIFT_EXPR, vrshift_expr, tcc_binary, 2) +DEFTREECODE (VLROTATE_EXPR, vlrotate_expr, tcc_binary, 2) +DEFTREECODE (VRROTATE_EXPR, vrrotate_expr, tcc_binary, 2) + /* Bitwise operations. Operands have same mode as result. */ DEFTREECODE (BIT_IOR_EXPR, bit_ior_expr, tcc_binary, 2) DEFTREECODE (BIT_XOR_EXPR, bit_xor_expr, tcc_binary, 2) Here is the file that segfaults: /data/fsf-build/bulldozer-gcc-test/./gcc/xgcc -shared-libgcc -B/data/fsf-build/bulldozer-gcc-test/./gcc -nostdinc++ -L/data/fsf-build/bulldozer-gcc-test/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/data/fsf-build/bulldozer-gcc-test/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/proj/gcc/fsf-install/bulldozer-gcc-test/x86_64-unknown-linux-gnu/bin/ -B/proj/gcc/fsf-install/bulldozer-gcc-test/x86_64-unknown-linux-gnu/lib/ -isystem /proj/gcc/fsf-install/bulldozer-gcc-test/x86_64-unknown-linux-gnu/include -isystem /proj/gcc/fsf-install/bulldozer-gcc-test/x86_64-unknown-linux-gnu/sys-include -Winvalid-pch -x c++-header -g -O2 -D_GNU_SOURCE -I/data/fsf-build/bulldozer-gcc-test/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/data/fsf-build/bulldozer-gcc-test/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/proj/gcc/fsf-src/bulldozer-gcc-test/libstdc++-v3/libsupc++ -O0 -g /proj/gcc/fsf-src/bulldozer-gcc-test/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O0g.gch In file included from /data/fsf-build/bulldozer-gcc-test/x86_64-unknown-linux-gnu/libstdc++-v3/include/valarray:539, from /proj/gcc/fsf-src/bulldozer-gcc-test/libstdc++-v3/include/precompiled/stdc++.h:96: /data/fsf-build/bulldozer-gcc-test/x86_64-unknown-linux-gnu/libstdc++-v3/include/valarray: In instantiation of std::valarraylong unsigned int: /data/fsf-build/bulldozer-gcc-test/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/valarray_after.h:59: instantiated from here /data/fsf-build/bulldozer-gcc-test/x86_64-unknown-linux-gnu/libstdc++-v3/include/valarray:117: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- Summary: Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot meissner at amd 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=35004
[Bug c++/35004] Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers
--- Comment #1 from michael dot meissner at amd dot com 2008-01-29 00:04 --- Created an attachment (id=15040) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15040action=view) Preprocessed file from the build of the libstdc++ pre-compiled headers File is bzip2'ed -9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
[Bug testsuite/35005] New: New testcase execute/20071211-1.c assumes 32 bit integers
The new testcase execute/20071211-1.c assumes 32 bit integers and fails on machines with 16 bit integers. -- Summary: New testcase execute/20071211-1.c assumes 32 bit integers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pmarques at grupopie dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35005
[Bug c++/35004] Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-29 00:15 --- I think this is the same as PR 34397 really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |c++ Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
[Bug middle-end/16187] ARRAY_REF should be used for pointers also
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-01-29 00:17 --- I think this is basically fixed with the pointer plus work I did. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16187
[Bug middle-end/16187] ARRAY_REF should be used for pointers also
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-01-29 00:19 --- With the trunk we get: return *(data + (long unsigned int) j * 4); Which is much better. The cast is still needed though. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16187
[Bug tree-optimization/35006] [4.3 Regression] Segfault in remove_unused_locals
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35006
[Bug c++/35004] Adding 4 more tree codes causes a crash in building libstdc++ pre-compiled headers
--- Comment #4 from michael dot meissner at amd dot com 2008-01-29 00:39 --- Created an attachment (id=15043) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15043action=view) Proposed patch to fix the problem The problem is cp/cp-tree.h stores the tree_code in 8 bits, but the tree code now overflows. The patch expands the tree code to 16 bits, and removes 8 unused bits to keep the padding the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35004
[Bug tree-optimization/35006] [4.3 Regression] Segfault in remove_unused_locals
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-29 00:48 ---
Here is a reduced testcase:
typedef unsigned long grub_uint64_t;
typedef grub_uint64_t grub_size_t;
grub_cmdline_get (
unsigned max_len,
int echo_char
)
{
unsigned xpos, ypos, ystart;
grub_size_t lpos, llen;
char buf[max_len];
void cl_print (int pos, int c)
{
char *p;
for (p = buf + pos; *p; p++)
{
if (xpos++ 78)
grub_putchar ('\n');
grub_putchar (*p);
}
}
void cl_delete (unsigned len)
{
cl_set_pos ();
cl_print (lpos, ' ');
grub_memmove ();
cl_print (lpos, echo_char);
cl_set_pos ();
}
cl_delete (llen);
grub_size_t n = lpos;
cl_delete (n);
}
CUT
Adding -fdump-tree-all, the ICE goes away.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target triplet||x86_64-*-*
Last reconfirmed|-00-00 00:00:00 |2008-01-29 00:48:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35006
[Bug c++/35007] New: [4.3 Regression] Firefox fails to build with affentry.cpp:94: error: ISO C++ forbids subscripting non-lvalue array
This is a very latent regression at most introduced under 48 hours. I will attach preprocessed file. -- Summary: [4.3 Regression] Firefox fails to build with affentry.cpp:94: error: ISO C++ forbids subscripting non-lvalue array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
[Bug c++/35007] [4.3 Regression] Firefox fails to build with affentry.cpp:94: error: ISO C++ forbids subscripting non-lvalue array
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-29 01:04 --- Created an attachment (id=15044) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15044action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
[Bug c++/35007] [4.3 Regression] Firefox fails to build with affentry.cpp:94: error: ISO C++ forbids subscripting non-lvalue array
--- Comment #3 from ismail at pardus dot org dot tr 2008-01-29 01:07 --- Compilation line is : c++ -o affentry.o -c -I../../../../dist/include/system_wrappers -include ../../../../config/gcc_hidden.h -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES -DOSTYPE=\Linux2.6.18\ -DOSARCH=Linux -I. -I. -I../../../../dist/include/xpcom -I../../../../dist/include/string -I../../../../dist/include/uconv -I../../../../dist/include/unicharutil -I../../../../dist/include/spellchecker -I../../../../dist/include/xulapp -I../../../../dist/include -I../../../../dist/include/hunspell -I/usr/include/nspr -I../../../../dist/sdk/include-fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -pedantic -mtune=native -march=i686 -O2 -pipe -fomit-frame-pointer -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -mtune=native -march=i686 -O2 -pipe -fomit-frame-pointer -fno-strict-aliasing -DMOZILLA_CLIENT -include ../../../../mozilla-config.h -Wp,-MD,.deps/affentry.pp affentry.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
[Bug c/34720] ICE in real_to_decimal, at real.c:1656
--- Comment #7 from roger at eyesopen dot com 2008-01-29 01:12 --- I'm also seeing this same failure with make profiledbootstrap on x86_64-unknown-linux-gnu. A make bootstrap on the same machine completes and regression tests fine (14 unexpected failures in gcc). I suspect that the miscompilation is either non-deterministic or is caused by an optimization that only triggers on some targets and/or with additional profile information. Perhaps we should regression hunt for the change that broke things. It might not be anything to do with real.c or decimal floating point. -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc64-unknown-linux-gnu |*64-unknown-linux-gnu GCC host triplet|powerpc64-unknown-linux-gnu |*64-unknown-linux-gnu GCC target triplet|powerpc64-unknown-linux-gnu |*64-unknown-linux-gnu Last reconfirmed|-00-00 00:00:00 |2008-01-29 01:12:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34720
[Bug fortran/31463] [patch] inconsistent warnings if function return value is not set
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-01-29 01:26 --- Mine. For patch, see URL above. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/fortra ||n/2008-01/msg00355.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2008-01-28 14:45:55 |2008-01-29 01:26:18 date|| Summary|gfortran prints no warning |[patch] inconsistent |message when an unset return|warnings if function return |value is an array |value is not set Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31463
[Bug c++/35007] [4.3 Regression] Firefox fails to build with affentry.cpp:94: error: ISO C++ forbids subscripting non-lvalue array
--- Comment #2 from ismail at pardus dot org dot tr 2008-01-29 01:06 --- Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib --libexecdir=/usr/lib --includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++ --disable-libgcj --disable-multilib --disable-nls --disable-werror --disable-mudflap --disable-libmudflap --enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit --enable-languages=c,c++,fortran,objc --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-shared --enable-ssp --disable-libssp --enable-threads=posix --without-included-gettext --without-system-libunwind --with-system-zlib --with-cpu=generic --with-pkgversion='Pardus Linux' --with-bugurl=http://bugs.pardus.org.tr Thread model: posix gcc version 4.3.0 20080128 [trunk revision 131899] (Pardus Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
[Bug c++/35007] [4.3 Regression] Firefox fails to build with affentry.cpp:94: error: ISO C++ forbids subscripting non-lvalue array
--- Comment #5 from ismail at pardus dot org dot tr 2008-01-29 02:11 --- Yes it works if you revert c++/27177 fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
[Bug c++/35007] [4.3 Regression] Firefox fails to build with affentry.cpp:94: error: ISO C++ forbids subscripting non-lvalue array
--- Comment #4 from pcarlini at suse dot de 2008-01-29 02:05 ---
This is a reduced snippet (-pedantic). I suspect the problem may have to do
with the fix for c++/27177, let's CC Jason...
struct AffEntry
{
union {
char base[256];
} conds;
};
struct PfxEntry
: public AffEntry
{
PfxEntry()
{
sizeof(conds.base[0]);
}
};
--
pcarlini at suse dot de changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-01-29 02:05:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
