[Bug middle-end/58096] [4.9 Regression] gcc.dg/tree-ssa/attr-alias.c fails with r201439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096 Yufeng Zhang changed: What|Removed |Added CC||yufeng at gcc dot gnu.org --- Comment #3 from Yufeng Zhang --- The test case also failed on ARM and AArch64
[Bug lto/58298] [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58298
Yufeng Zhang changed:
What|Removed |Added
CC||yufeng at gcc dot gnu.org
--- Comment #3 from Yufeng Zhang ---
I briefly saw the issue on aarch64 and arm, but I think it has been fixed by
the following commit:
commit 8d4e699477b53778f0e933cb77d71e28a1e70536
Author: hubicka
Date: Mon Sep 2 14:45:06 2013 +
* lto.c (mentions_vars_p_field_decl, lto_fixup_prevailing_decls):
DECL_FIELD_OFFSET can contain an reference to variable.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@202174
138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/gcc/lto/ChangeLog b/gcc/lto/ChangeLog
index cf31c21..fe8e463 100644
--- a/gcc/lto/ChangeLog
+++ b/gcc/lto/ChangeLog
@@ -1,5 +1,10 @@
2013-08-31 Jan Hubicka
+ * lto.c (mentions_vars_p_field_decl, lto_fixup_prevailing_decls):
+ DECL_FIELD_OFFSET can contain an reference to variable.
+
+2013-08-31 Jan Hubicka
+
* lto.c (tree_with_vars): Turn into vector.
(MAYBE_REMEMBER_WITH_VARS): Change to...
(CHECK_VAR): ... this one.
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 1d1350b..0cea778 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1389,7 +1389,7 @@ mentions_vars_p_field_decl (tree t)
{
if (mentions_vars_p_decl_common (t))
return true;
- CHECK_NO_VAR (DECL_FIELD_OFFSET (t));
+ CHECK_VAR (DECL_FIELD_OFFSET (t));
CHECK_NO_VAR (DECL_BIT_FIELD_TYPE (t));
CHECK_NO_VAR (DECL_QUALIFIER (t));
CHECK_NO_VAR (DECL_FIELD_BIT_OFFSET (t));
@@ -3207,7 +3207,7 @@ lto_fixup_prevailing_decls (tree t)
LTO_SET_PREVAIL (DECL_FUNCTION_PERSONALITY (t));
if (CODE_CONTAINS_STRUCT (code, TS_FIELD_DECL))
{
- LTO_NO_PREVAIL (DECL_FIELD_OFFSET (t));
+ LTO_SET_PREVAIL (DECL_FIELD_OFFSET (t));
LTO_NO_PREVAIL (DECL_BIT_FIELD_TYPE (t));
LTO_NO_PREVAIL (DECL_QUALIFIER (t));
LTO_NO_PREVAIL (DECL_FIELD_BIT_OFFSET (t));
[Bug target/51001] redundant address re-computations on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51001 Yufeng Zhang changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-31 CC||yufeng at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Yufeng Zhang --- I can confirm that the similar issue exists using the trunk compiler with -O2 -mcpu=cortex-a15 foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mov r3, #53248 mvn r2, #85 mov r1, r3 strbr2, [r3, #2755] .L3: ldrbr3, [r1, #2754] @ zero_extendqisi2 mov r2, #53248 tst r3, #128 beq .L3 mvn r3, #68 mov r1, r2 strbr3, [r2, #2755] .L5: ldrbr3, [r1, #2754] @ zero_extendqisi2 tst r3, #128 beq .L5 bx lr The -fdump-tree-optimized dump looks OK.
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 Yufeng Zhang changed: What|Removed |Added CC||yufeng at gcc dot gnu.org --- Comment #7 from Yufeng Zhang --- What is the current status?
[Bug target/59843] ICE with return of generic vector on aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 --- Comment #3 from Yufeng Zhang --- This issue is related to the handling of vector of one double in the AArch64 backend. We don't have a corresponding type defined in ACLE (ARM C Language Extension) the spec and backend is not able to handle it properly this moment.
[Bug target/59843] ICE with return of generic vector on aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 Yufeng Zhang changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|yufeng at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Yufeng Zhang --- Remove myself from assignee; I'm not working on it this moment.
[Bug target/60825] New: [AArch64] int64x1_t, uint64x1_t and float64x1_t are not treated as vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825
Bug ID: 60825
Summary: [AArch64] int64x1_t, uint64x1_t and float64x1_t are
not treated as vector types
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yufeng at gcc dot gnu.org
int64x1_t, uint64x1_t and float64x1_t in AArch64 arm_neon.h shall be vector
types. However currently they are treated as different names for the
corresponding C/C++ types: int64_t, uint64_t and double in the GCC AArch64
backend.
Function parameters of such types shall be passed in NEON SIMD registers and
the names of C++ functions with parameters of any of those types shall be
mangled properly.
The following test cases demonstrate the issue:
test.c
/* Parameter passing issue */
#include "arm_neon.h"
int64x1_t ;
uint64x1_t ;
float64x1_t ;
void (int64x1_t);
void (uint64x1_t);
void (float64x1_t);
void test (void)
{
();
();
();
}
CUT
'', '' and '' shall be passed in register 'd0', however '' and
'' are currently passed in 'x0' instead. '' is correctly passed in
'd0', but only by chance, as parameters of double are passed in FP registers
which overlay with SIMD registers.
test.cpp
/* C++ name mangling issue */
#include "arm_neon.h"
void (int64x1_t )
{}
void (uint64x1_t )
{}
void (float64x1_t )
{}
CUT
Instead of the following expected mangled names:
_Z411__Int64x1_t
_Z412__Uint64x1_t
_Z413__Float64x1_t
the function names are currently mangled to
_Z4l
_Z4m
_Z4d
[Bug target/60825] [AArch64] int64x1_t, uint64x1_t and float64x1_t are not treated as vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825 Yufeng Zhang changed: What|Removed |Added Target||aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-11 Target Milestone|--- |4.9.1 Ever confirmed|0 |1
[Bug target/60825] [AArch64] int64x1_t, uint64x1_t and float64x1_t are not treated as vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825 Yufeng Zhang changed: What|Removed |Added Status|NEW |ASSIGNED Version|4.9.0 |4.8.0 Assignee|unassigned at gcc dot gnu.org |yufeng at gcc dot gnu.org
[Bug target/60825] [AArch64] int64x1_t, uint64x1_t and float64x1_t are not treated as vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60825 --- Comment #2 from Yufeng Zhang --- Apart from the parameter passing and C++ name mangling issues, there is also an issue w.r.t. the implicit conversion between the scalar types and their vector-type peers. For intrinsics code to be portable, conversion between neon intrinsics vector types and the scalar types should be done via the corresponding vcreat and vget_lane intrinsics. Currently, arm_neon.h has the following typedefs: typedef int64_t int64x1_t; typedef double float64x1_t; typedef uint64_t uint64x1_t; which have unfortunately allowed variables of e.g. type int64_t and type int64x1_t, to be interoperable. User code replying on this mistake may encounter compilation errors after the fix.
[Bug target/61031] [4.10 Regression] ICE building libjava (verify_flow_info failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61031 Yufeng Zhang changed: What|Removed |Added CC||yufeng at gcc dot gnu.org --- Comment #2 from Yufeng Zhang --- The failure seems a bit random; it is fine in my local environment with r210436 (trunk 20140514), but after I applied a patch in order to do the bootstrapping test on aarch64, I got the exactly same error.
[Bug target/61483] New: [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483
Bug ID: 61483
Summary: [AArch64] builtin va_start incorrectly initializes the
field of va_list for incoming unnamed arguments on the
stack
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yufeng at gcc dot gnu.org
The following code is mis-compiled by gcc, when targeting aarch64. The issue is
that the second variadic argument to callee_b0f, which is of type long long, is
not retrieved correctly inside the callee.
--- CODE ---
#include
#include
struct float_float_t { float a, b; } float_float = {1.2, 2.2};
union float_int_t {
float b8;
int b5;
} float_int = {4983.80};
long long correct = 12683143434LL;
long long callee_b0f(float f1, float f2, float f3, float f4,
float f5, float f6, float f7, struct float_float_t ff,
int i1, int i2, int i3, int i4,
int i5, int i6, int i7,
...) {
va_list ap;
va_start(ap, i7);
va_arg(ap, union float_int_t);
long long var = va_arg(ap, long long);
va_end(ap);
return var;
}
int main()
{
long long check = callee_b0f(1.0, 2.0, 3.0, 4.0,
5.0, 6.0, 7.0, float_float,
9, 10, 11, 12,
13, 14, 15,
float_int, correct);
printf("%lld\n%lld\n", correct, check);
return 0;
}
--- CUT ---
Expected output:
12683143434
12683143434
Actual output:
12683143434
0
I have checked that this bug is present since 4.8.0 (day one of the aarch64
port).
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483 Yufeng Zhang changed: What|Removed |Added Target||aarch64 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-06-12 Assignee|unassigned at gcc dot gnu.org |yufeng at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483 Yufeng Zhang changed: What|Removed |Added Target Milestone|--- |4.9.1 Known to fail||4.8.0, 4.9.0
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483 --- Comment #1 from Yufeng Zhang --- Author: yufeng Date: Tue Jun 17 09:39:22 2014 New Revision: 211733 URL: https://gcc.gnu.org/viewcvs?rev=211733&root=gcc&view=rev Log: gcc/ PR target/61483 * config/aarch64/aarch64.c (aarch64_layout_arg): Add new local variable 'size'; calculate 'size' right in the front; use 'size' to compute 'nregs' (when 'allocate_ncrn != 0') and pcum->aapcs_stack_words. gcc/testsuite/ PR target/61483 * gcc.target/aarch64/aapcs64/type-def.h (struct hfa_fx2_t): New type. * gcc.target/aarch64/aapcs64/va_arg-13.c: New test. * gcc.target/aarch64/aapcs64/va_arg-14.c: Ditto. * gcc.target/aarch64/aapcs64/va_arg-15.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/type-def.h
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483
--- Comment #2 from Yufeng Zhang ---
Author: yufeng
Date: Tue Jun 17 13:50:50 2014
New Revision: 211739
URL: https://gcc.gnu.org/viewcvs?rev=211739&root=gcc&view=rev
Log:
gcc/
PR target/61483
* config/aarch64/aarch64.c (aarch64_layout_arg): Add new local
variable 'size'; calculate 'size' right in the front; use
'size' to compute 'nregs' (when 'allocate_ncrn != 0') and
pcum->aapcs_stack_words.
gcc/testsuite/
PR target/61483
* gcc.target/aarch64/aapcs64/type-def.h (struct hfa_fx2_t): New type.
* gcc.target/aarch64/aapcs64/va_arg-13.c: New test.
* gcc.target/aarch64/aapcs64/va_arg-14.c: Ditto.
* gcc.target/aarch64/aapcs64/va_arg-15.c: Ditto.
Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c
Modified:
branches/gcc-4_9-branch/ (props changed)
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/type-def.h
branches/gcc-4_9-branch/libjava/classpath/ (props changed)
Propchange: branches/gcc-4_9-branch/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_9-branch/libjava/classpath/
('svn:mergeinfo' modified)
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483
--- Comment #3 from Yufeng Zhang ---
Author: yufeng
Date: Tue Jun 17 14:15:03 2014
New Revision: 211741
URL: https://gcc.gnu.org/viewcvs?rev=211741&root=gcc&view=rev
Log:
gcc/
PR target/61483
* config/aarch64/aarch64.c (aarch64_layout_arg): Add new local
variable 'size'; calculate 'size' right in the front; use
'size' to compute 'nregs' (when 'allocate_ncrn != 0') and
pcum->aapcs_stack_words.
gcc/testsuite/
PR target/61483
* gcc.target/aarch64/aapcs64/type-def.h (struct hfa_fx2_t): New type.
* gcc.target/aarch64/aapcs64/va_arg-13.c: New test.
* gcc.target/aarch64/aapcs64/va_arg-14.c: Ditto.
* gcc.target/aarch64/aapcs64/va_arg-15.c: Ditto.
Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-13.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-14.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c
- copied unchanged from r211733,
trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/va_arg-15.c
Modified:
branches/gcc-4_8-branch/ (props changed)
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/aarch64/aarch64.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/aapcs64/type-def.h
branches/gcc-4_8-branch/libjava/classpath/ (props changed)
Propchange: branches/gcc-4_8-branch/
('svn:mergeinfo' modified)
Propchange: branches/gcc-4_8-branch/libjava/classpath/
('svn:mergeinfo' modified)
[Bug target/61483] [AArch64] builtin va_start incorrectly initializes the field of va_list for incoming unnamed arguments on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61483 Yufeng Zhang changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.9.1 |4.8.4 --- Comment #4 from Yufeng Zhang --- Have fixed the issue in trunk 211733, and backport to 4.9 and 4.8 branches (211739 and 211741).
[Bug target/59843] ICE with return of generic vector on aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 Yufeng Zhang changed: What|Removed |Added Target|aarch64-linux |aarch64-linux aarch64-elf Status|NEW |ASSIGNED CC||yufeng at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |yufeng at gcc dot gnu.org --- Comment #2 from Yufeng Zhang --- Confirmed and assigned to myself. test.c: In function 'foo': test.c:6:3: internal compiler error: in emit_move_insn, at expr.c:3610 return r; ^ 0x63bbb0 emit_move_insn(rtx_def*, rtx_def*) gcc/gcc/expr.c:3610 0x63e1a2 emit_group_load_1 gcc/gcc/expr.c:1750 0x63e5e9 emit_group_load(rtx_def*, rtx_def*, tree_node*, int) gcc/gcc/expr.c:1846 0x587c27 expand_value_return gcc/gcc/cfgexpand.c:3036 0x58ade6 expand_return gcc/gcc/cfgexpand.c:3114 0x58ade6 expand_gimple_stmt_1 gcc/gcc/cfgexpand.c:3187 0x58ade6 expand_gimple_stmt gcc/gcc/cfgexpand.c:3309 0x58c024 expand_gimple_basic_block gcc/gcc/cfgexpand.c:5149 0x590536 gimple_expand_cfg gcc/gcc/cfgexpand.c:5715 0x590536 execute gcc/gcc/cfgexpand.c:5935 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799 Yufeng Zhang changed: What|Removed |Added Status|NEW |ASSIGNED CC||yufeng at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |michael.hudson at linaro dot org
[Bug middle-end/48493] New: [ICE] in expand_expr_addr_expr_1, at expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493
Summary: [ICE] in expand_expr_addr_expr_1, at expr.c
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yuf...@gcc.gnu.org
CC: ja...@gcc.gnu.org, ram...@gcc.gnu.org
The arm gcc fails in compiling the following reproducible code:
-- CODE --
typedef long long T __attribute__((may_alias, aligned (1)));
struct S
{
_Complex float d __attribute__((aligned (8)));
};
void bar (struct S);
void
f1 (T x)
{
struct S s;
*(T *) ((char *) &s.d + 1) = x;
bar (s);
}
-- CUT --
The following error message will be given when the above code is compiled with
options -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon -O1
(-O1 itself should be enough to reproduce the problem):
repro.c: In function 'f1':
repro.c:14:30: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:6922
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The test is derived from the regression test case gcc.dg/pr48335-2.c which was
added in r171855 (http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00047.html) on 1st
April. However, the compiler before the commit, and even the 4.6.1 compiler,
fails in the same way. FYI. the commit is a patch for bug 48335, in which the
'arm' target was not tested according to bug 48335, comment #6:
> Created attachment 23818 [details]
> gcc46-pr48335.patch
>
> Updated patch, all the new tests now compile, on
> i386/x86_64/ppc/ppc64/s390/s390x.
[Bug middle-end/48335] [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335 Yufeng Zhang changed: What|Removed |Added CC||yufeng at gcc dot gnu.org --- Comment #10 from Yufeng Zhang 2011-04-07 13:30:04 UTC --- (In reply to comment #6) > Created attachment 23818 [details] > gcc46-pr48335.patch > > Updated patch, all the new tests now compile, on > i386/x86_64/ppc/ppc64/s390/s390x. Hi Jakub, The test gcc.dg/pr48335-2.c unfortunately fails in the arm-eabi testing with an ICE: gcc.dg/pr48335-2.c: In function 'f1': gcc.dg/pr48335-2.c:19:30: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6922 I've raised the bug 48493 for this. I'm not sure how it is related with this bugzilla as the compiler before your commit fails on the test as well. Cheers, Yufeng
[Bug c++/46003] cond5.C fails for ARM EABI tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003 Yufeng Zhang changed: What|Removed |Added Status|NEW |ASSIGNED CC||yufeng at gcc dot gnu.org AssignedTo|unassigned at gcc dot |yufeng at gcc dot gnu.org |gnu.org | --- Comment #5 from Yufeng Zhang 2011-06-03 10:48:29 UTC --- (In reply to comment #4) > Test g++.dg/template/cond5.C started failing for arm-none-linux-gnueabi with > this patch: > > r132158 | aoliva | 2008-02-06 20:31:43 + (Wed, 06 Feb 2008) | 10 lines > > gcc/cp/ChangeLog: > PR c++/35056 > * tree.c: Include tree-flow.h. > (build_target_expr): Check type compatibility. The type checking introduced by this commit to build_target_expr is indeed where the ICE occurs, i.e. the assertion failure. The added type-checking exposes the problem. Jason Merrill has suggested updating build_conditional_expr to "have a template case that just determines the appropriate type and then builds up a COND_EXPR with that type from the unconverted operands, like we do for calls in finish_call_expr" (http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00164.html) I've been distracted by other work, but will come back to this very soon.
[Bug c++/46003] cond5.C fails for ARM EABI tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003 Yufeng Zhang changed: What|Removed |Added CC|yufeng.zhang at arm dot com | --- Comment #8 from Yufeng Zhang 2011-06-09 17:15:14 UTC --- (In reply to comment #6) > Shouldn't this be fixed by the commit of PR c++/49134 ? (In reply to comment #7) > Test g++.dg/template/cond5.C starts passing for arm-none-linux-gnueabi with > r174682, the fix for PR49134 mentioned in comment 6. Thanks for pointing out the related bug fix. The test case g++.dg/template/cond5.C indeed starts 'passing' now, as the fix for PR c++/49134 has essentially loosened the same checking where assertion had blown up. I'll spend some more time looking into the underlying issue and put more information here later. If it turns out to be necessary, I'll close this bugzilla and open a new one for it.
