[Bug bootstrap/52878] [4.8 regression] bootstrap failure: MASK_LONG_DOUBLE_128 redefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-06 CC||ebotcazou at gcc dot ||gnu.org Target Milestone|--- |4.8.0 Summary|sparc64 bootstrap failure: |[4.8 regression] bootstrap |MASK_LONG_DOUBLE_128 |failure: |redefined |MASK_LONG_DOUBLE_128 ||redefined Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-04-06 06:37:07 UTC --- This patch works for Linux/sparc. But it may not work for all sparc targets which don't include long-double-switch.opt. You can easily find this out, just build a cross to sparc-elf.
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression] 'asm' |[4.7/4.8 Regression] 'asm' |operand requires impossible |operand requires impossible |reload in |reload |libffi/src/ia64/ffi.c | Severity|normal |major --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-04-06 06:59:29 UTC --- It is time to do something as GCC 4.7 is quite hampered by this on IA-64.
[Bug rtl-optimization/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-04-06
AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-04-06 09:13:23
UTC ---
Confirmed.
simplify_const_unary_operation tries to simplify:
(zero_extend:DI (const_int 0 [0]))
and trips on assert where:
/* When zero-extending a CONST_INT, we need to know its
original mode. */
There is nothing wrong with the above RTX, so there is no justification to
trigger the ICE. The compiler should simply reject to simplify this RTX.
I am testing following patch:
--cut here--
Index: simplify-rtx.c
===
--- simplify-rtx.c (revision 186182)
+++ simplify-rtx.c (working copy)
@@ -1461,7 +1461,9 @@ simplify_const_unary_operation (enum rtx_code code
case ZERO_EXTEND:
/* When zero-extending a CONST_INT, we need to know its
original mode. */
- gcc_assert (op_mode != VOIDmode);
+ if (op_mode == VOIDmode)
+ return 0;
+
if (op_width == HOST_BITS_PER_WIDE_INT)
{
/* If we were really extending the mode,
@@ -1628,9 +1630,8 @@ simplify_const_unary_operation (enum rtx_code code
break;
case ZERO_EXTEND:
- gcc_assert (op_mode != VOIDmode);
-
- if (op_width HOST_BITS_PER_WIDE_INT)
+ if (op_mode == VOIDmode
+ || op_width HOST_BITS_PER_WIDE_INT)
return 0;
hv = 0;
--cut here--
[Bug rtl-optimization/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883
--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-04-06 09:26:33
UTC ---
Uncovered by 4.8 change to allow immediate operands in *zero_extendsidi2_rex64:
(define_insn *zero_extendsidi2_rex64
[(set (match_operand:DI 0 nonimmediate_operand
=r ,o,?*Ym,?*y,?*Yi,!*x)
(zero_extend:DI
(match_operand:SI 1 x86_64_zext_general_operand
rmZ,0,r ,m ,r ,m*x)))]
TARGET_64BIT
@
mov{l}\t{%1, %k0|%k0, %1}
#
...)
[Bug rtl-optimization/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug rtl-optimization/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-04-06 10:55:59 UTC --- simplify_const_unary_operation tries to simplify: (zero_extend:DI (const_int 0 [0])) and trips on assert where: /* When zero-extending a CONST_INT, we need to know its original mode. */ There is nothing wrong with the above RTX, so there is no justification to trigger the ICE. Just that it makes no sense. Please fix whoever generated it instead.
[Bug rtl-optimization/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2012-04-06 11:18:35 UTC --- (In reply to comment #3) simplify_const_unary_operation tries to simplify: (zero_extend:DI (const_int 0 [0])) and trips on assert where: /* When zero-extending a CONST_INT, we need to know its original mode. */ There is nothing wrong with the above RTX, so there is no justification to trigger the ICE. Just that it makes no sense. Please fix whoever generated it instead. It is allowed in *zero_extendsidi2_rex64, and 0 propagates into the pattern for some corner case. For the affected part, 4.7 generates: .L3: movl$0, %eax# 42*zero_extendsidi2_rex64/1 movlg(,%rax,4), %ebx# 44*movsi_internal/1 jmp .L8 # 60jump while 4.8 (with the above fix) generates: .L3: movl$0, %eax# 42*zero_extendsidi2_rex64/1 movlg(,%rax,4), %ebx# 44*movsi_internal/1 jmp .L8 # 60jump I fail to see why zero_extending a constant should trigger an ICE, while at the same time sign_extending a constant is allowed (please see following lines in both cases).
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Attachment #27103|0 |1 is patch|| Attachment #27103|application/octet-stream|text/plain mime type|| --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-06 11:23:35 UTC --- Comment on attachment 27103 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27103 Patch including testcases - warn and only when necessary on literal overflow. Mark the patch as a patch.
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-06 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-06 11:45:43 UTC --- (In reply to comment #10) I made the warnings on by default. Any opinion on whether I should have made them depend on OPT_Woverflow instead? I guess I thought the warning is slightly different in this case than the case of just a regular numeric literal because the warning might cause the programmer to examine a different type of operator as a solution - say template or raw. Some comments: * Is overflow anything but -1, 0, and 1? If so, could you just make it an enum? This will have the added benefit of not making calls like whatever(...,0,...) in which it is very far from clear what 0 means. With the enum you can use NO_OVERFLOW. It may also save some space with respect to using 'int'. * I don't get the reasoning for not using OPT_Woverflow. It is a warning about overflow of numbers. Adding warnings that cannot be disabled by any option is bad. The warning could be moved to a new different option later if people clamor for it. * Please use warning_at, even if you don't have a better location than input_location. Diagnostic functions without location are DEPRECATED, but nobody has bothered to do a full-conversion of the existing ones (I did with pedwarn, inform and permerror, but there are too many warning/error calls).
[Bug rtl-optimization/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-04-06 12:00:56 UTC --- (In reply to comment #4) It is allowed in *zero_extendsidi2_rex64, and 0 propagates into the pattern for some corner case. For the affected part, 4.7 generates: Oops, this is the correct sequence: .L3: movl$0, %edx# 66*movsi_internal/1 movl%edx, %eax # 42*zero_extendsidi2_rex64/1 movlg(,%rax,4), %ebx# 44*movsi_internal/1 jmp .L8 # 62jump[length = 2]
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-06 12:09:47 UTC --- PPL administrator bagnara was very helpful in investigating this. The PPL code is not actually looping, but simply is taking a very long time to analyze a large input set. The PIP problem has no integer solutions, and this algorithm has a difficult time determining that. bagnara also indicated that GCC is not using ppl_PIP_Problem_is_satisfiable correctly. Following are his comments: I have checked the GCC sources. The problem is that ppl_PIP_Problem_is_satisfiable() and several other functions that involve algorithms of exponential complexity are used unguarded. The right thing to do is to use the deterministic timeout facility of the PPL. See ppl-0.11.2/interfaces/C/tests/weightwatch1.c for an example using the C interface. Moreover, there appears to be a design problem in functions such as /* Checks for integer feasibility: returns true when the powerset polyhedron PS has no integer solutions. */ bool ppl_powerset_is_empty (ppl_Pointset_Powerset_C_Polyhedron_t ps); The output of such a function should be a tristate: (1) there are integer solutions; (2) there are no integer solutions; (3) don't know (it was not possible to decide the question due to time/space limitations). Alternatively, one could change the name and the specification: /* Checks for integer feasibility: returns true when the powerset polyhedron PS has no integer solutions; returns false if PS has integer solutions or the analysis was inconclusive. */ bool ppl_powerset_is_definitely_empty (ppl_Pointset_Powerset_C_Polyhedron_t ps); Concerning the implementation, besides using the deterministic timeout facility of the PPL, you should also use MIP_Problem in addition to PIP_Problem: try the second one with timeout; upon timeout try the first one. For the specific testcase, MIP_Problem immediately answers that there are no integer solutions (it is easy to come up with testcases where MIP_Problem takes a lot of time and PIP_Problem does much better). =
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added CC||dberlin at gcc dot gnu.org, ||grosser at gcc dot gnu.org --- Comment #4 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-06 12:13:50 UTC --- CCing the Graphite maintainers.
[Bug bootstrap/52878] [4.8 regression] bootstrap failure: MASK_LONG_DOUBLE_128 redefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-04-06 12:23:46 UTC --- (In reply to comment #1) Created attachment 27102 [details] A patch This patch works for Linux/sparc. But it may not work for all sparc targets which don't include long-double-switch.opt. This addition: diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h index a1919b4..a04f8ef 100644 --- a/gcc/config/sparc/sparc.h +++ b/gcc/config/sparc/sparc.h @@ -53,6 +53,14 @@ along with GCC; see the file COPYING3. If not see #endif /* IN_LIBGCC2 */ #define TARGET_ARCH64 (! TARGET_ARCH32) +#ifndef TARGET_LONG_DOUBLE_128 +#define TARGET_LONG_DOUBLE_128 0 +#endif + +#ifndef MASK_LONG_DOUBLE_128 +#define MASK_LONG_DOUBLE_128 0 +#endif + /* Code model selection in 64-bit environment. The machine mode used for addresses is 32-bit wide: is also needed.
[Bug rtl-optimization/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot
||gnu.org
--- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-04-06 12:36:06
UTC ---
(In reply to comment #3)
Just that it makes no sense. Please fix whoever generated it instead.
OK, tracing this a bit deeper:
#0 internal_error (gmsgid=0x111f5e0 in %s, at %s:%d) at
../../gcc-svn/trunk/gcc/diagnostic.c:839
#1 0x00e1cda4 in fancy_abort (file=optimized out, line=1464,
function=0xef4380 simplify_const_unary_operation)
at ../../gcc-svn/trunk/gcc/diagnostic.c:899
#2 0x00881783 in simplify_const_unary_operation (code=optimized out,
mode=DImode, op=0x719ad470, op_mode=optimized out)
at ../../gcc-svn/trunk/gcc/simplify-rtx.c:1464
#3 0x0087f4d0 in simplify_unary_operation (code=ZERO_EXTEND,
mode=DImode, op=0x719ad470, op_mode=VOIDmode)
at ../../gcc-svn/trunk/gcc/simplify-rtx.c:579
#4 0x005ec860 in cselib_expand_value_rtx_1 (orig=optimized out,
evd=0x7fffd950, max_depth=optimized out)
at ../../gcc-svn/trunk/gcc/cselib.c:1805
The problem starts at cselib.c, where:
/* If an operand has been simplified into CONST_INT, which doesn't
have a mode and the mode isn't derivable from whole rtx's mode,
try simplify_*_operation first with mode from original's operand
and as a fallback wrap CONST_INT into gen_rtx_CONST. */
We do have specializations for this case:
switch (GET_RTX_CLASS (code))
{
case RTX_UNARY:
if (CONST_INT_P (XEXP (copy, 0))
GET_MODE (XEXP (orig, 0)) != VOIDmode)
{
scopy = simplify_unary_operation (code, mode, XEXP (copy, 0),
GET_MODE (XEXP (orig, 0)));
if (scopy)
return scopy;
}
break;
...
But, since we have VOIDmode operand, we should do as the comment says and wrap
CONST_INT with CONST. However, we directly hit:
scopy = simplify_rtx (copy);
if (scopy)
return scopy;
return copy;
where simplify_rtx just passes problematic RTX to simplify_unary_operation.
Leaving this to RTX experts, since the code does not match the comment.
[Bug debug/52857] DW_OP_GNU_regval_type is generated with INVALID_REGNUM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-04-06 13:05:49 UTC --- For (note 21 8 17 2 (expr_list:REG_DEP_TRUE (concat:SI (reg:SI 5 di) (subreg:SI (plus:DI (reg/f:DI 16 argp) (const_int -20 [0xffec])) 0)) (nil)) NOTE_INSN_CALL_ARG_LOCATION) when (plus:DI (reg/f:DI 16 argp) (const_int -20 [0xffec])) reaches case PLUS: plus: if (is_based_loc (rtl) GET_MODE_SIZE (mode) = DWARF2_ADDR_SIZE GET_MODE_CLASS (mode) == MODE_INT) mem_loc_result = based_loc_descr (XEXP (rtl, 0), INTVAL (XEXP (rtl, 1)), VAR_INIT_STATUS_INITIALIZED); else it fails GET_MODE_SIZE (mode) = DWARF2_ADDR_SIZE since we have ptr_mode = SImode and Pmode == DImode. However, arg_pointer_rtx and frame_pointer_rtx are special cases. They should be allowed even if their mode sizes DWARF2_ADDR_SIZE.
[Bug c++/52596] [4.7/4.8 Regression] [C++11] internal compiler error: in lvalue_kind, at cp/tree.c:153
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52596 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-04-06 13:25:48 UTC --- Author: jason Date: Fri Apr 6 13:25:45 2012 New Revision: 186187 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186187 Log: PR c++/52596 * semantics.c (finish_non_static_data_member): In templates, pass the decl to build_qualified_name. * tree.c (lvalue_kind) [SCOPE_REF]: Handle FIELD_DECL. Added: trunk/gcc/testsuite/g++.dg/template/qualified-id5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/52596] [4.7/4.8 Regression] [C++11] internal compiler error: in lvalue_kind, at cp/tree.c:153
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52596 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2012-04-06 13:26:17 UTC --- Author: jason Date: Fri Apr 6 13:26:14 2012 New Revision: 186188 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186188 Log: PR c++/52596 * tree.c (lvalue_kind): Treat a deferred access control SCOPE_REF as an lvalue. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/qualified-id5.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/tree.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/52596] [4.7/4.8 Regression] [C++11] internal compiler error: in lvalue_kind, at cp/tree.c:153
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52596 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2012-04-06 13:28:41 UTC --- Fixed.
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439
bagnara at cs dot unipr.it changed:
What|Removed |Added
CC||bagnara at cs dot unipr.it
--- Comment #5 from bagnara at cs dot unipr.it 2012-04-06 13:49:57 UTC ---
Here is a sketch (100% untested) of what can be done without intervening on the
specification of the function, that is, without giving up. The original
implementation was inefficient, by the way: if one element of the powerset was
found not to be empty, all the other elements were tested anyway instead of
immediately returning false. Whether it is best to try the MIP solver or the
PIP solver first is something to be determined experimentally.
bool
ppl_powerset_is_empty (ppl_Pointset_Powerset_C_Polyhedron_t ps)
{
ppl_dimension_type d;
ppl_Constraint_System_const_iterator_t first, last;
ppl_Pointset_Powerset_C_Polyhedron_iterator_t it, end;
bool has_integer_solutions = false;
/* FIXME: the following values should be determined experimentally. */
unsigned weight = 2;
unsigned weight_increment = 5000;
unsigned timeouts;
if (ppl_Pointset_Powerset_C_Polyhedron_is_empty (ps))
return true;
while (true)
{
ppl_Pointset_Powerset_C_Polyhedron_space_dimension (ps, d);
ppl_new_Constraint_System_const_iterator (first);
ppl_new_Constraint_System_const_iterator (last);
ppl_new_Pointset_Powerset_C_Polyhedron_iterator (it);
ppl_new_Pointset_Powerset_C_Polyhedron_iterator (end);
timeouts = 0;
for (ppl_Pointset_Powerset_C_Polyhedron_iterator_begin (ps, it),
ppl_Pointset_Powerset_C_Polyhedron_iterator_end (ps, end);
!ppl_Pointset_Powerset_C_Polyhedron_iterator_equal_test (it, end);
ppl_Pointset_Powerset_C_Polyhedron_iterator_increment (it))
{
ppl_const_Polyhedron_t ph;
ppl_const_Constraint_System_t pcs;
ppl_Linear_Expression_t le;
ppl_MIP_Problem_t mip;
int ppl_result;
ppl_Pointset_Powerset_C_Polyhedron_iterator_dereference (it, ph);
ppl_Polyhedron_get_constraints (ph, pcs);
/* Try with the MIP solver first. */
ppl_new_Linear_Expression (le);
ppl_new_MIP_Problem (mip, d, pcs, le,
PPL_OPTIMIZATION_MODE_MAXIMIZATION);
ppl_set_deterministic_timeout (weight);
ppl_result = ppl_MIP_Problem_is_satisfiable (mip);
ppl_reset_deterministic_timeout ();
ppl_delete_MIP_Problem (mip);
if (ppl_result == PPL_TIMEOUT_EXCEPTION)
{
/* Deterministic timeout expired: try with the PIP solver. */
ppl_PIP_Problem_t pip;
ppl_Constraint_System_begin (pcs, first);
ppl_Constraint_System_end (pcs, last);
ppl_new_PIP_Problem_from_constraints (pip, d, first, last, 0,
NULL);
ppl_set_deterministic_timeout (weight);
ppl_result = ppl_PIP_Problem_is_satisfiable (pip);
ppl_reset_deterministic_timeout ();
ppl_delete_PIP_Problem (pip);
if (ppl_result == PPL_TIMEOUT_EXCEPTION)
++timeouts;
else if (ppl_result 0)
{
has_integer_solutions = true;
break;
}
}
else if (ppl_result 0)
{
has_integer_solutions = true;
break;
}
}
ppl_delete_Constraint_System_const_iterator (first);
ppl_delete_Constraint_System_const_iterator (last);
ppl_delete_Pointset_Powerset_C_Polyhedron_iterator (it);
ppl_delete_Pointset_Powerset_C_Polyhedron_iterator (end);
/* If there were no timeouts, then we have the answer. */
if (timeouts == 0)
return !has_integer_solutions;
if (weight = UINT_MAX - weight_increment)
weight += weight_increment;
}
}
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 --- Comment #6 from bagnara at cs dot unipr.it 2012-04-06 14:04:09 UTC --- Created attachment 27104 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27104 Example alternative implementation for ppl_powerset_is_empty ()
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 --- Comment #7 from bagnara at cs dot unipr.it 2012-04-06 14:06:38 UTC --- (In reply to comment #5) Here is a sketch (100% untested) of what can be done without intervening [...] So untested that I forgot to declare to the MIP problem that all variables are integer. I have attached a file (example1.c) where this is corrected.
[Bug middle-end/52886] New: [4.8 Regression] FAIL: gcc.dg/torture/pr36978.c -On (internal compiler error), n=1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52886 Bug #: 52886 Summary: [4.8 Regression] FAIL: gcc.dg/torture/pr36978.c -On (internal compiler error), n=1 and above Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ia...@gcc.gnu.org, rgue...@gcc.gnu.org, wschm...@gcc.gnu.org Target: powerpc*-*-* s390-ibm-linux-gnu Between revisions 186092 (OK, see http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg00234.html) and 186108 (see http://gcc.gnu.org/ml/gcc-testresults/2012-04/msg00277.html), compiling gcc.dg/torture/pr36978.c on powerpc*-*-* and s390-ibm-linux-gnu has stated to give an ICE: FAIL: gcc.dg/torture/pr36978.c -O1 (internal compiler error) FAIL: gcc.dg/torture/pr36978.c -O1 (test for excess errors) FAIL: gcc.dg/torture/pr36978.c -O2 (internal compiler error) FAIL: gcc.dg/torture/pr36978.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr36978.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.dg/torture/pr36978.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/pr36978.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.dg/torture/pr36978.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.dg/torture/pr36978.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.dg/torture/pr36978.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.dg/torture/pr36978.c -O3 -g (internal compiler error) FAIL: gcc.dg/torture/pr36978.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr36978.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/pr36978.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/pr36978.c -O2 -flto (internal compiler error) FAIL: gcc.dg/torture/pr36978.c -O2 -flto (test for excess errors) The ICE is [karma] f90/bug% gcc48 -O1 /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr36978.c /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr36978.c: In function 'foo': /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr36978.c:5:6: error: AUX pointer initialized for edge 3-4 /opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr36978.c:5:6: internal compiler error: verify_ssa failed
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-04-06 14:08:52 UTC --- Thanks for the commit. I'll test the effect of -fno-common on gfortran.
[Bug rtl-optimization/52657] [4.7/4.8 regression] error on asm during GMP build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52657 Jeroen Demeyer jdemeyer at cage dot ugent.be changed: What|Removed |Added CC||jdemeyer at cage dot ||ugent.be --- Comment #3 from Jeroen Demeyer jdemeyer at cage dot ugent.be 2012-04-06 14:18:59 UTC --- While this is marked as duplicate of PR48496, the fix of PR48496 doesn't fix this bug.
[Bug rtl-optimization/52657] [4.7/4.8 regression] error on asm during GMP build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52657 --- Comment #4 from Jeroen Demeyer jdemeyer at cage dot ugent.be 2012-04-06 14:25:09 UTC --- Can this be re-opened please? I still get the error with gcc (GCC) 4.7.1 20120406 (prerelease) PR48496 only provided a work-around for this bug in the libffi code, it didn't actually fix the bug.
[Bug debug/52857] DW_OP_GNU_regval_type is generated with INVALID_REGNUM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-04-06 14:51:55
UTC ---
Another testcase:
[hjl@gnu-mic-2 delta]$ cat testcase.c
void uw_init_context_1 (void *);
void _Unwind_ForcedUnwind (void)
{
uw_init_context_1 (__builtin_dwarf_cfa ());
}
[hjl@gnu-mic-2 delta]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -O2 -g -fPIC -S
-maddress-mode=long testcase.c
testcase.c: In function \u2018_Unwind_ForcedUnwind\u2019:
testcase.c:5:1: internal compiler error: in mem_loc_descriptor, at
dwarf2out.c:11675
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[hjl@gnu-mic-2 delta]$
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #10 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2012-04-06 15:02:51 UTC --- Agreed.
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 --- Comment #9 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2012-04-06 15:02:26 UTC --- Author: mrs Date: Fri Apr 6 15:02:21 2012 New Revision: 186194 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186194 Log: PR testsuite/50722 * gcc.dg/pr49994-3.c: Use -w to squelch non-portable warnings. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr49994-3.c
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 Ed Smith-Rowland 3dw4rd at verizon dot net changed: What|Removed |Added Attachment #27054|0 |1 is obsolete|| Attachment #27103|0 |1 is obsolete|| --- Comment #13 from Ed Smith-Rowland 3dw4rd at verizon dot net 2012-04-06 15:32:39 UTC --- Created attachment 27105 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27105 New patch incorporating recent suggestions. Using warning_at, OPT_Woverflow, etc. Added a new enum for overflow type and used it everywhere. regtested fine on x86_64-linux-gnu.
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Attachment #27105|0 |1 is patch|| Attachment #27105|application/octet-stream|text/plain mime type|| --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-06 15:36:53 UTC --- Comment on attachment 27105 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27105 New patch incorporating recent suggestions. Set type to patch.
[Bug bootstrap/52887] New: Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 Bug #: 52887 Summary: Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results) const) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: sk...@iskunk.org Host: powerpc-ibm-aix5.3.0.0 Target: powerpc-ibm-aix5.3.0.0 Build: powerpc-ibm-aix5.3.0.0 Bootstrapping GCC 4.7.0 on an AIX 5.3 system fails with /tmp/gcc-4.7.0-build/./prev-gcc/g++ -B/tmp/gcc-4.7.0-build/./prev-gcc/ -B/opt/tg/powerpc-ibm-aix5.3.0.0/bin/ -nostdinc++ -B/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs -B/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs -I/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/powerpc-ibm-aix5.3.0.0 -I/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/include -I/home/src/gcc-4.7.0/libstdc++-v3/libsupc++ -L/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs -L/tmp/gcc-4.7.0-build/prev-powerpc-ibm-aix5.3.0.0/libstdc++-v3/libsupc++/.libs -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-bbigtoc -Wl,-bmaxdata:0x4000 -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o default-c.o rs6000-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lmpc -lmpfr -lgmp -L../zlib -lz ld: 0711-317 ERROR: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results) const) ld: 0711-317 ERROR: Undefined symbol: .std::functionbool (std::__regex::_PatternCursor const)::function(std::functionbool (std::__regex::_PatternCursor const) const) ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: error: ld returned 8 exit status gmake[3]: *** [cc1] Error 1 gmake[3]: Leaving directory `/tmp/gcc-4.7.0-build/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/tmp/gcc-4.7.0-build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-4.7.0-build' gmake: *** [bootstrap-lean] Error 2 The build tree was configured with '--prefix=/opt/tg' '--disable-dependency-tracking' '--disable-maintainer-mode' '--program-prefix=tg-' '--disable-shared' '--disable-nls' '--enable-version-specific-runtime-libs' '--with-pic' '--with-mpc=/usr/local' '--with-mpfr=/usr/local' '--with-gmp=/usr/local' 'CC=tg-gcc -mminimal-toc' 'CXX=false' '--enable-languages=c,c++'
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.1 --- Comment #12 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2012-04-06 15:37:57 UTC --- Also fixed in 4.7.1.
[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50722 --- Comment #11 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2012-04-06 15:35:59 UTC --- Author: mrs Date: Fri Apr 6 15:35:52 2012 New Revision: 186197 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186197 Log: PR testsuite/50722 * gcc.dg/pr49994-3.c: Use -w to squelch non-portable warnings. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr49994-3.c
[Bug rtl-optimization/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org
[Bug rtl-optimization/52657] [4.7/4.8 regression] error on asm during GMP build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52657 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-04-06 15:41:20 UTC --- Can this be re-opened please? I still get the error with gcc (GCC) 4.7.1 20120406 (prerelease) PR48496 only provided a work-around for this bug in the libffi code, it didn't actually fix the bug. Sure, but it isn't marked as resolved so a fix will be provided there.
[Bug rtl-optimization/52888] New: Unable to inline function pointer call with inexact signature match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52888
Bug #: 52888
Summary: Unable to inline function pointer call with inexact
signature match
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: msha...@users.sourceforge.net
#include stdio.h
struct A {
template typename T
static inline __attribute__((always_inline))
void Caller (T* pn, void (T::*pm)(void))
{ (pn-*pm)(); }
void Call (int i) {
if (i == 1) Caller(this, A::Func1);
else if (i == 2) Caller(this, A::Func2);
}
inline void Func1 (void){ puts (Func1); }
inline void Func2 (void) noexcept { puts (Func2); }
};
int main (void) { A a; a.Call(1); a.Call(2); return (0); }
-
Compiling with: g++ (GCC) 4.7.0 20120324 (prerelease), x86_64
g++ -O -std=c++11 a.cc
a.cc: In function 'int main()':
a.cc:5:55: error: inlining failed in call to always_inline 'static void
A::Caller(T*, void (T::*)()) [with T = A]': mismatched arguments
a.cc:10:42: error: called from here
a.cc:5:55: error: inlining failed in call to always_inline 'static void
A::Caller(T*, void (T::*)()) [with T = A]': mismatched arguments
a.cc:10:42: error: called from here
-
I'm using always_inline to force the error; without it Caller is not inlined
errorlessly.
The problem occurs when the function pointer has an inexact signature match to
the pointed function. In the above example, Func2 has a noexcept tacked on to
it. In more complex examples involving pointer to function with arguments,
using a typedef of an object in argument list results in this error, while
using the actual object works (typedef A a_t; void good(A); void bad(a_t)).
So the compiler is able to explicitly convert an inexact match like A::Func2
to void(A::*)(void) when instantiating the template, but the inliner is not
able to make the same match even though it should have the same information.
[Bug c/52889] New: incorrect sign of _mm_nmsub_XX intrinsics in fma4intrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52889 Bug #: 52889 Summary: incorrect sign of _mm_nmsub_XX intrinsics in fma4intrin.h Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mathiaspu...@gmx.de Created attachment 27106 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27106 corrected fma4intrin.h include file All _mm_nmsub_xx and _mm256_nmsub_xx intrinsic definitions for FMA4 instructions in the fma4intrin.h header file are incorrect. nmsub(a,b,c) should compute the equivalent of -( a*b - c) = c - a*b. However the fma4intrin.h file maps nmsub(a,b,c) - madd(-(a),b,-(c)) - -a*b - c i.e. the sign in front of the c operand is erroneous. The impact of this bug is, that code which actively uses the _mm_nmsub_xx intrinsics gives incorrect results. The attached fma4intrin.h file has all signs properly corrected and can be used as drop-in replacement for fma4intrin.h in GCC 4.6.2. The bug is also present in 4.6.1. I have not checked correctness of prior GCC version 4.5.x nor newer GCC 4.7. However the fma4intrin.h mapping has changed from 4.5 - 4.6, which might likely have introduced the error. Best regards, Mathias Puetz / Cray Inc.
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654
--- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-06
16:40:42 UTC ---
(In reply to comment #13)
Created attachment 27105 [details]
New patch incorporating recent suggestions.
Using warning_at, OPT_Woverflow, etc.
Added a new enum for overflow type and used it everywhere.
Well, sorry if I am nitpicking, but the code would be clearer if the enum was
declared in real.h, used by real_from_string and everywhere else, so one would
not need to do overflow 0 but overflow == UNDERFLOW or something similar
like UNDERFLOWED. And OT_NONE is not very easy to understand, because I don't
know what OT is the build_ call, I would suggest NO_OVERFLOW. Or perhaps:
real.h:
/* Enumerate the types of overflow that may occur. */
enum overflow_type {
overflow_underflowed = -1,
overflow_none,
overflow_overflowed
};
GCC source code is already hard enough to read. Every little thing helps.
But this is merely a suggestion. You should send your patch to gcc-patches and
wait and see what the maintainers say. I don't have the power to approve (or
reject) patches.
Also, I may be misunderstanding how the current code works and what you are
trying to achieve, but it is strange to me that you parse the number first as a
number and then, if it is indeed converted to a number warn. So why don't just
parse the number as a string, and if it is indeed converted to a number, then
convert the string to a number and warn? That is, in c-lex.c build the userdef
before any interpret_ is called, and store the raw string. Do not try to
interpret it. Then, in cp_parser_userdef_numeric_literal, when you know what
type you are expecting, you can call interpret_* and do all the magic to decide
whether this is actually a number or a string. It seems to me that this will
do the work in one place, instead of moving stuff up and down the parser and
the lexer. Or maybe you already tried this and it didn't work for some reason?
[Bug middle-end/52890] New: Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890
Bug #: 52890
Summary: Revision 185336 causes 10% degradation on cpu2000
benchmark 252.eon
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: berg...@gcc.gnu.org, mjam...@suse.cz
Host: powerpc64-linux
Target: powerpc64-linux
Build: powerpc64-linux
Following testcase extracted from benchmark file mrXZRectangle.cc.
$ cat test.cc
// g++ -m64 -O2 -mcpu=power7 -S test.cc
class ggVector3 {
public:
ggVector3() {e[0] = 1.0; e[1] = e[2] = 0.0; }
ggVector3(double e0, double e1, double e2) {
e[0] = e0; e[1] = e1; e[2] = e2; }
double e[3];
};
class ggONB3 {
public:
ggONB3() { }
ggONB3(const ggVector3 a, const ggVector3 b, const ggVector3 c) {
U = a; V = b; W = c; }
private:
ggVector3 U,V,W;
};
class mrViewingHitRecord {
public:
ggONB3 UVW;
};
void foo(mrViewingHitRecord VHR)
{
VHR.UVW = ggONB3(ggVector3 (1, 0, 0),
ggVector3 (0, 0, -1),
ggVector3 (0, 1, 0));
}
Revision 185335 produces tight sequence of 8-byte stores:
stfd 0,8(3)
stfd 0,16(3)
stfd 0,24(3)
stfd 0,32(3)
...
Revision 185336, with additional check for SLOW_UNALIGNED_ACCESS now causes
path through store_bit_field() which generates a much larger sequence of byte
stores.
stb 8,0(3)
stb 10,1(3)
stb 9,2(3)
stb 9,3(3)
stb 9,4(3)
stb 9,5(3)
...
[Bug tree-optimization/52891] New: ICE in adjust_bool_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52891
Bug #: 52891
Summary: ICE in adjust_bool_pattern
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mer...@savhon.org
I seem to have triggered a bug in the tree vectorizer of GCC as of 20120404.
$ cat file.c
struct S1
{
int intfield;
struct
{
unsigned ufield:10;
} sfield;
};
int func2(short param1, short param2)
{
int **intptr;
if((param1 param2) + **intptr)
while(1);
}
void func1(void)
{
struct S1 foo;
func2(foo.intfield, foo.sfield.ufield);
}
$ ~/gcc/dist/bin/gcc --version
gcc (GCC) 4.8.0 20120404 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ~/gcc/dist/bin/gcc -O2 -ftree-vectorize file.c
Using built-in specs.
COLLECT_GCC=/home/merkil/gcc/dist/bin/gcc
COLLECT_LTO_WRAPPER=/home/merkil/gcc/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../srcdir/configure --prefix=/home/merkil/gcc/dist CFLAGS='
-O2 -pipe' CXXFLAGS=' -O2 -pipe' --enable-languages=c,c++,lto
Thread model: posix
gcc version 4.8.0 20120404 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-ftree-vectorize' '-v' '-mtune=generic'
'-march=x86-64'
/home/merkil/gcc/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1 -quiet -v
file.c -quiet -dumpbase file.c -mtune=generic -march=x86-64 -auxbase file -O2
-version -ftree-vectorize -o /tmp/ccuzSuSy.s
GNU C (GCC) version 4.8.0 20120404 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120404 (experimental), GMP version 5.0.4,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
/home/merkil/gcc/dist/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/merkil/gcc/dist/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
/usr/local/include
/home/merkil/gcc/dist/include
/home/merkil/gcc/dist/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
/usr/include
End of search list.
GNU C (GCC) version 4.8.0 20120404 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120404 (experimental), GMP version 5.0.4,
MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 77c744b2fbaa15d9025679f4b671f18a
file.c: In function 'func1':
file.c:19:6: internal compiler error: in adjust_bool_pattern, at
tree-vect-patterns.c:2301
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Hope that is useful to you :-)
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 --- Comment #16 from Ed Smith-Rowland 3dw4rd at verizon dot net 2012-04-06 17:40:27 UTC --- Thank you for your comments. I was trying to follow the style of enum that I saw in the vicinity of the code I was editing. I was not able to discern a single style. If lower-case is more modern (I like it) then that's good for me. I have no problem moving it to real.h and using it all over either (I think just one return type). I also used the enum in interpret_integer though. Maybe that's not a problem really. Maybe I could go as far as changing cpp_number.overflow to use this enum as well instead of a bool? - no real is not part of libcpp by design it seems. As far as just storing a string and parsing it later you may be right. Up to now it was just convenient to keep the numeric values. I tried to figure out how to run interpret_integer, etc in parser but I got stuck trying to feed cpp_token in parser in the c++ fe when all I could see was cp_token. Is there a way I can get the preprocessor token from the C++ token or is the former stored somewhere? If so I'll do that in a heartbeat. OK, I'll try parse_in-cut_token. I thought about breaking up interpret_ into separate pieces that took strings but that seemed like more trouble than it was worth. Thank you for your comments. Ed
[Bug debug/52857] DW_OP_GNU_regval_type is generated with INVALID_REGNUM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-04/msg00358.htm ||l --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-04-06 17:41:01 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00358.html
[Bug middle-end/52886] [4.8 Regression] FAIL: gcc.dg/torture/pr36978.c -On (internal compiler error), n=1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52886 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-04-06 18:08:59 UTC --- Probably global-except-x86_64-or-whereever-tested, at least cris-elf too.
[Bug fortran/52668] [4.7/4.8 Regression] Incorrect unused warning for USE associating variable in common block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52668 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-04-06 18:31:19 UTC --- Author: tkoenig Date: Fri Apr 6 18:31:11 2012 New Revision: 186199 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186199 Log: 2012-04-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/52668 * module.c: Only mark symbols as use_only if they have been imported via an only list. 2012-04-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/52668 * gfortran.dg/use_only_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_only_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52870] ICE during SLP pattern matching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52870 --- Comment #2 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-04-06 18:31:58 UTC --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00360.html
[Bug c++/52654] [C++11] Warn on overflow in user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654 --- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-06 18:38:51 UTC --- (In reply to comment #16) Thank you for your comments. I was trying to follow the style of enum that I saw in the vicinity of the code I was editing. I was not able to discern a single style. If lower-case is more modern (I like it) then that's good for me. I have no problem moving it Actually, I don't know what is the best style, I just looked at the other enum defined in real.h to real.h and using it all over either (I think just one return type). I also used the enum in interpret_integer though. Maybe that's not a problem really. Maybe I could go as far as changing cpp_number.overflow to use this enum as well instead of a bool? - no real is not part of libcpp by design it seems. Well, libcpp seems not to care about the difference between underflow and overflow, so why bother to modify it? Also real and libcpp are independent, so this seems to me adding a dependence that is not needed. As far as just storing a string and parsing it later you may be right. Up to now it was just convenient to keep the numeric values. I tried to figure out how to run interpret_integer, etc in parser but I got stuck trying to feed cpp_token in parser in the c++ fe when all I could see was cp_token. Is there a way I can get the preprocessor token from the C++ token or is the former stored somewhere? If so I'll do that in a heartbeat. OK, I'll try parse_in-cut_token. Oh, I see the problem now. So I guess that what you did is the most straightforward way then. Unless someone more knowledgeable proposes a nice way to avoid passing this info around. I thought about breaking up interpret_ into separate pieces that took strings but that seemed like more trouble than it was worth. Indeed. I see your point. It would be nice to be able to call these functions from the C++ FE to avoid passing all this info around, and also avoid interpreting the numbers if they are not actually numbers, and avoid checking for user-def literals in CPP. Is parse_in still valid at the moment that cp_parser_userdef_ functions are called? In fact, cpp_interpret_integer only needs a valid cpp_reader, it doesn't use its token argument for anything but the string. Again, I am not maintainer, so it would be nice if some maintainer expressed their opinion.
[Bug c++/52892] New: Function pointer loses constexpr qualification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52892
Bug #: 52892
Summary: Function pointer loses constexpr qualification
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ericmcornel...@gmail.com
The following test case is failing:
#include cstdio
constexpr std::size_t fibonacci(std::size_t val) {
return (val = 2) ? 1 : fibonacci(val - 1) + fibonacci(val - 2);
}
template typename Function
struct Defer {
constexpr Defer(const Function func_) : func(func_) { }
const Function func;
template typename... Args
constexpr auto operator () (const Args... args) - decltype(func(args...)) {
return func(args...);
}
};
template typename Function
constexpr DeferFunction make_deferred(const Function f) {
return DeferFunction(f);
}
int main(int argc, char* argv[]) {
constexpr auto deferred = make_deferred(fibonacci);
static_assert(deferred(25) == 75025, Static fibonacci call failed);
}
src/main.cpp: In function 'int main(int, char**)':
src/main.cpp:151:3: error: non-constant condition for static assertion
src/main.cpp:151:28: in constexpr expansion of
'deferred.DeferFunction::operator(){int}((* 25))'
src/main.cpp:140:24: error: expression 'fibonacci' does not designate a
constexpr function
test.make:129: recipe for target `obj/Debug/main.o' failed
make[1]: *** [obj/Debug/main.o] Error 1
makefile:16: recipe for target `test' failed
make: *** [test] Error 2
Based on my reading of the standard, this should be allowed behavior, and works
as expected with clang 3.1 (152539).
Note that the following behavior also fails similarly:
int main(int argc, char* argv[]) {
constexpr auto deferred = make_deferred(fibonacci);
constexpr auto func = deferred.func;
constexpr auto val = func(25);
}
src/main.cpp: In function 'int main(int, char**)':
src/main.cpp:152:31: error: expression 'fibonacci' does not designate a
constexpr function
Whereas this succeeds:
int main(int argc, char* argv[]) {
constexpr auto func = fibonacci;
static_assert(func(25) == 75025, Static fibonacci call failed);
}
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 --- Comment #8 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-04-06 19:08:09 UTC --- Roberto, I tried your patch, but got the following error: PPL error code -8 PPL C interface error: ppl_set_deterministic_timeout: the PPL Watchdog library is not enabled. I assume this is a configuration feature for PPL that GCC doesn't enable. I wonder if there are portability concerns here. Graphite maintainers, can you please comment? I'm afraid I know practically nothing about Graphite.
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 --- Comment #9 from bagnara at cs dot unipr.it 2012-04-06 19:17:25 UTC --- Pity it is not enabled: it definitely should. Note that the addition of the deterministic timeout facility of the PPL was solicited by the Graphite people. Previously the PPL only supported timeouts based on wall-clock time, which resulted in non-determinism that is unacceptable in GCC.
[Bug fortran/52893] New: [4.7/4.8 Regression] Moving functions out of implied DO loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52893 Bug #: 52893 Summary: [4.7/4.8 Regression] Moving functions out of implied DO loops Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: tkoe...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org The following aborts with -ffrontend-optimize: program test integer, parameter :: N = 4 integer, parameter :: dp=kind(1.d0) real(kind=dp), parameter :: pi=4*atan(1._dp) real(kind=dp), parameter :: eps = 1.e-14_dp real(kind=dp) :: h1(0:N-1), h2(0:N-1) integer i i = 1 h1 = [(cos(2*pi*mod(i*k,N)/N),k=0,N/2), (sin(2*pi*mod(i*k,N)/N),k=1,N/2-1)] h2 = (/ 1._dp, 0._dp, -1._dp, 1._dp /) if (any(abs(h1 - h2) eps)) call abort end program test
[Bug fortran/52893] [4.7/4.8 Regression] Moving functions out of implied DO loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52893 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-06 Ever Confirmed|0 |1
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 David Abdurachmanov david.abdurachmanov at gmail dot com changed: What|Removed |Added CC||david.abdurachmanov at ||gmail dot com --- Comment #4 from David Abdurachmanov david.abdurachmanov at gmail dot com 2012-04-06 19:39:18 UTC --- I can confirm the issue. Run into the problem when re-compiling a project with C++11. Works fine in C++98/03, does not compile in C++11. Both work-arounds suggested in the first comment works.
[Bug c/52880] -Woverride-init emitts unexpected error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52880 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-06 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-06 20:16:05 UTC --- A patch would be welcome. We don't have many people looking at C diagnostic issues, so any help is greatly appreciated.
[Bug middle-end/52890] Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52890 --- Comment #1 from Pat Haugen pthaugen at gcc dot gnu.org 2012-04-06 21:13:04 UTC --- My main question on this is why the MEM_REF has an alignment of 8 (i.e. byte)? Breakpoint 1, expand_assignment (to=0xfffafed2790, from=optimized out, nontemporal=optimized out) at /home/pthaugen/src/gcc/temp3/gcc/gcc/expr.c:4653 4653store_bit_field (mem, GET_MODE_BITSIZE (mode), (gdb) prt to mem_ref 0xfffafed2790 type real_type 0xfffb0057b60 double DF size integer_cst 0xfffafe125e0 constant 64 unit size integer_cst 0xfffafe12600 constant 8 align 8 symtab 0 alias set 2 canonical type 0xfffaff00f18 precision 64 arg 0 ssa_name 0xfffb00e1d60 type reference_type 0xfffb0055f28 type record_type 0xfffb0055d30 mrViewingHitRecord public unsigned DI size integer_cst 0xfffafe125e0 64 unit size integer_cst 0xfffafe12600 8 align 64 symtab 0 alias set 6 canonical type 0xfffb0055f28 visited var parm_decl 0xfffafe41980 VHRdef_stmt GIMPLE_NOP version 1 ptr-info 0xfffafe9af80 arg 1 integer_cst 0xfffafe19b80 type reference_type 0xfffb0055f28 constant 0 test.cc:29:44 (gdb) pr mem (mem:DF (reg/v/f:DI 120 [ VHR ]) [5 MEM[(struct mrViewingHitRecord )VHR_1(D)]+0 S8 A8])
[Bug middle-end/52894] New: [4.5,4.6,4.7,4.8 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52894 Bug #: 52894 Summary: [4.5,4.6,4.7,4.8 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Bootstrap fails with Debian gcc-4.6.3-2 and gcc-4.7.0-2. The failure was most likely caused by r185758 based on backtrace: PR middle-end/52640 * varasm.c: Include pointer-set.h. (pending_assemble_externals_set): New pointer set. (process_pending_assemble_externals): Destroy the pointer set. (assemble_external): See if decl is in pending_assemble_externals_set, and add it to pending_assemble_externals if necessary. (init_varasm_once): Allocate pending_assemble_externals_set. gcc-4.6.3-1 and gcc-4.7.0-1 were ok. The cause of the loop is as yet unclear but it is clearly not associated with the above change. The failure occurs compiling a number of files in stage1. It seems to be associated with the second vector allocation in pointer_set_insert. Triggered with the following options: -fpreprocessed cgraphbuild.i -quiet -dumpbase cgraphbuild.c -auxbase-strip cgraphbuild.o -g -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -version -fkeep-inline-functions -fno-common -o cgraphbuild.s
[Bug middle-end/52894] [4.5,4.6,4.7,4.8 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52894 --- Comment #1 from dave.anglin at bell dot net 2012-04-06 21:27:47 UTC --- .i. -- John David Anglindave.ang...@bell.net
[Bug middle-end/52894] [4.5,4.6,4.7,4.8 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52894 --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2012-04-06 21:41:40 UTC --- Created attachment 27107 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27107 Preprocessed source
[Bug middle-end/52894] [4.5,4.6,4.7,4.8 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52894
--- Comment #3 from John David Anglin danglin at gcc dot gnu.org 2012-04-06
22:43:09 UTC ---
cc1 is stuck in this loop in insert_aux:
while (true)
{
if (slots[n] == p || slots[n] == 0)
return n;
else
{
++n;
if (n == n_slots)
n = 0;
}
}
Fails even when pointer-set.c is compiled at -O0.
[Bug c++/52895] New: [C++0x] ICE in unify, at cp/pt.c:15802
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52895 Bug #: 52895 Summary: [C++0x] ICE in unify, at cp/pt.c:15802 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: taylor.goodh...@gmail.com Possibly related to 44629 or 51530. gcc -v -save-temps --std=c++0x crash.cpp Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.6.1/cc1plus -E -quiet -v -D_GNU_SOURCE crash.cpp -mtune=generic -march=x86-64 -std=c++0x -fpch-preprocess -o crash.ii ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.6.1/include-fixed ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../x86_64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1 /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/backward /usr/lib/gcc/x86_64-redhat-linux/4.6.1/include /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++0x' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.6.1/cc1plus -fpreprocessed crash.ii -quiet -dumpbase crash.cpp -mtune=generic -march=x86-64 -auxbase crash -std=c++0x -version -o crash.s GNU C++ (GCC) version 4.6.1 20110908 (Red Hat 4.6.1-9) (x86_64-redhat-linux) compiled by GNU C version 4.6.1 20110908 (Red Hat 4.6.1-9), GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.3-dev GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.6.1 20110908 (Red Hat 4.6.1-9) (x86_64-redhat-linux) compiled by GNU C version 4.6.1 20110908 (Red Hat 4.6.1-9), GMP version 4.3.2, MPFR version 3.0.0, MPC version 0.8.3-dev GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 49ba4178658a95fb5abf5b1394d9fe7d In file included from /usr/include/boost/assign/list_of.hpp:397:0, from crash.cpp:1: /usr/include/boost/preprocessor/iteration/detail/local.hpp: In member function ‘boost::assign_detail::generic_listT boost::assign_detail::generic_listT::operator()(const U, const U0) [with U = std::pairStruct::State, Struct::State, U0 = std::nullptr_t, T = std::pairstd::pairStruct::State, Struct::State, std::nullptr_t, boost::assign_detail::generic_listT = boost::assign_detail::generic_liststd::pairstd::pairStruct::State, Struct::State, std::nullptr_t ]’: crash.cpp:14:122: instantiated from here /usr/include/boost/preprocessor/iteration/detail/local.hpp:37:93: internal compiler error: in unify, at cp/pt.c:15802 Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccCPPguD.out file, please attach this to your bugreport.
[Bug c++/52895] [C++0x] ICE in unify, at cp/pt.c:15802
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52895 --- Comment #1 from taylor.goodhart at gmail dot com 2012-04-06 23:17:17 UTC --- Created attachment 27108 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27108 CPP file
[Bug c++/52895] [C++0x] ICE in unify, at cp/pt.c:15802
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52895 --- Comment #2 from taylor.goodhart at gmail dot com 2012-04-06 23:19:50 UTC --- Created attachment 27109 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27109 II File I appologize for compressing this. The bug reporting system won't let me post the original due to the size, and I don't have the means to post a URL.
[Bug c/52896] New: internal compiler error: in do_SUBST, at combine.c:447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52896 Bug #: 52896 Summary: internal compiler error: in do_SUBST, at combine.c:447 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: fdarkan...@gmail.com I got this when cross-compiling gcc-3.4.6 for m68k-elf on x86_64 host (gcc-4.7.0). Here's the relevant part of the compilation: /home/guest/buildscripts/m68k-elf/gcc/gcc/xgcc -B/home/guest/buildscripts/m68k-elf/gcc/gcc/ -B/opt/toolchains/m68k-elf-old/m68k-elf/bin/ -B/opt/toolchains/m68k-elf-old/m68k-elf/lib/ -isystem /opt/toolchains/m68k-elf-old/m68k-elf/include -isystem /opt/toolchains/m68k-elf-old/m68k-elf/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/guest/buildscripts/gcc-3.4.6/gcc -I/home/guest/buildscripts/gcc-3.4.6/gcc/. -I/home/guest/buildscripts/gcc-3.4.6/gcc/../include -m68000 -DL_fixdfdi -c /home/guest/buildscripts/gcc-3.4.6/gcc/libgcc2.c -o libgcc/m68000/_fixdfdi.o /home/guest/buildscripts/gcc-3.4.6/gcc/libgcc2.c: In function `__fixdfdi': /home/guest/buildscripts/gcc-3.4.6/gcc/libgcc2.c:1277: internal compiler error: in do_SUBST, at combine.c:447 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Ssidenote: I first cross-compiled installed binutils-2.22.
[Bug middle-end/52894] [4.5,4.6,4.7,4.8 Regression] Stage1 bootstrap fails with gcc-4.6.3: Infinite loop in pointer_set_insert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52894
--- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-04-07
01:40:20 UTC ---
(gdb) p *pset
$54 = {log_slots = 0, n_slots = 512, n_elements = 117, slots = 0x496c990}
(gdb) bt
#0 pointer_set_insert (pset=0x488ef70, p=0x40424300)
at ../../gcc/gcc/pointer-set.c:143
#1 0x0338d004 in assemble_external (decl=0x40424300)
at ../../gcc/gcc/varasm.c:2204
#2 0x00c7ebb0 in output_addr_const (file=0x4862ac0, x=0x4168c030)
at ../../gcc/gcc/final.c:3568
#3 0x03425700 in pa_assemble_integer (x=0x4168c030, size=4, aligned_p=1)
at ../../gcc/gcc/config/pa/pa.c:3192
#4 0x0338df20 in assemble_integer (x=0x4168c030, size=4, align=32, force=1)
at ../../gcc/gcc/varasm.c:2502
#5 0x0342c100 in output_deferred_plabels ()
at ../../gcc/gcc/config/pa/pa.c:5561
#6 0x01dbb10c in compile_file () at ../../gcc/gcc/toplev.c:681
#7 0x01dbfe3c in do_compile () at ../../gcc/gcc/toplev.c:1938
#8 0x01dc02bc in toplev_main (argc=1087218560, argv=0x4056f70)
at ../../gcc/gcc/toplev.c:2014
#9 0x01dc02bc in toplev_main (argc=28, argv=0xfdf02024)
at ../../gcc/gcc/toplev.c:2014
#10 0x00415c48 in main (argc=28, argv=0xfdf02024) at ../../gcc/gcc/main.c:36
The PA backend calls assemble_external via the TARGET_ASM_FILE_END
hook at the end of the compilation (i.e., after pset has been destroyed).
