[Bug c++/70229] New: error: constexpr constructor does not have empty body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70229
Bug ID: 70229
Summary: error: constexpr constructor does not have empty body
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
Target Milestone: ---
$ cat x.cpp
#define _CONST_FUN constexpr
template
class duration
{ // represents a time duration
public:
typedef duration<_Rep, _Period> _Myt;
typedef _Rep rep;
typedef _Period period;
template
_CONST_FUN duration(int xx)
{ // construct from a duration
typedef int test;
static_assert(0 == 0,
"period not an instance of std::ratio");
}
};
$ ./xgcc -c -std=c++11 x.cpp -B.
x.cpp: In constructor ‘duration<_Rep, _Period>::duration(int)’:
x.cpp:21:3: error: constexpr constructor does not have empty body
}
|
^
$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
Thread model: posix
gcc version 6.0.0 20160314 (experimental) (GCC)
[Bug c++/70229] error: constexpr constructor does not have empty body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70229 --- Comment #1 from baoshan --- The error is triggered by the typedef clause, but it is valid according standard C++11 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf: ... — either its function-body shall be = default, or the compound-statement of its function-body shall contain only — null statements, — static_assert-declarations — typedef declarations and alias-declarations that do not define classes or enumerations, ...
[Bug c++/70567] internal compiler error: in retrieve_specialization, at cp/pt.c:1020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70567 --- Comment #1 from baoshan --- This issue is seen from 4.8 to 5.0.
[Bug c++/70567] New: internal compiler error: in retrieve_specialization, at cp/pt.c:1020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70567
Bug ID: 70567
Summary: internal compiler error: in retrieve_specialization,
at cp/pt.c:1020
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
Target Milestone: ---
1. cat y.C:
template < class > struct allocator_traits;
template < class > class allocator;
template < class _Ty > struct allocator_traits >
{
typedef _Ty value_type;
typedef value_type *pointer;
template < class _Other > using rebind_traits =
allocator_traits < allocator < _Other > >;
};
int test()
{
allocator_traits >::rebind_traits::pointer pt;
}
2. ./xgcc -std=c++11 -S -B. y.c
y.C: In substitution of 'template using rebind_traits =
allocator_traits > [with _Other = int]':
y.C:12:58: required from here
y.C:8:46: internal compiler error: in retrieve_specialization, at cp/pt.c:1020
allocator_traits < allocator < _Other > >;
^
[Bug rtl-optimization/61494] -fsignaling-nans not taken into account for x - 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61494 baoshan changed: What|Removed |Added CC||pangbw at gmail dot com --- Comment #2 from baoshan --- Looking at the function simplify_binary_operation_1, I can see "!HONOR_SNANS (mode)" has been added in a few places to prevent the incorrect transformation, I believe to fix the issue we just add it to other places it should be there. But the question is which place should we add this predication? For case 1: "X - 0" to "X" we may say it is needed, but what about case 2: "(X&C1)|C2" to "X|C2"? The quiet NaN would be generated but not in the original location; if we think it is not needed I will think for the case 1 it is also not needed because I believe the signaling 'X' would be used later and the quite NaN would be generated eventually. If we think for both of cases the predication is necessary, I would think(suggest) every transformation in this function should be prohibited if HONOR_SNANS (mode) is true.
[Bug target/61298] redundant compare instructions for powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #2 from baoshan ---
It shows the problem in unsigned_reg_p():rtlanal.c:
bool
unsigned_reg_p (rtx op)
{
if (REG_P (op)
&& REG_EXPR (op)
&& TYPE_UNSIGNED (TREE_TYPE (REG_EXPR (op
return true;
if (GET_CODE (op) == SUBREG
&& SUBREG_PROMOTED_UNSIGNED_P (op))
return true;
return false;
}
Without -m64, the first clause would return with true.
With option -m64, the 'op' comes with this formal:
(subreg:SI (reg/v:DI 126 [ c1+-7 ]) 4)
The two clauses here both return with false.
Is it legal to think the whole SUBREG expression is unsigned if the inner
EXPRESSION is unsigned? Or can I fix it with this clause?
if (GET_CODE (op) == SUBREG) return unsigned_reg_p(XEXP(op,0));
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #18 from baoshan ---
I see this issue on 5.2.0 too:
cat test.c
unsigned baz[6];
void test(unsigned *bar, unsigned n) {
unsigned i, j;
if (n > 6) {
n = 6;
}
for (i = 1; i < n; i++) {
for (j = i - 1; j > 0; j--) {
bar[j - 1] = baz[j - 1];
}
}
}
bpg@ala-bpg-lx1$./cross/bin/arm-linux-gnueabi-gcc -c -Wall -O3 test.c
test.c: In function ‘test’:
test.c:9:32: warning: array subscript is above array bounds [-Warray-bounds]
bar[j - 1] = baz[j - 1];
^
test.c:9:32: warning: array subscript is above array bounds [-Warray-bounds]
bpg@ala-bpg-lx1$./cross/bin/arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=./cross/bin/arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/net/ala-rsu-lx1/ala-rsu-lx11/bpg/SHARE/GCC520/X_520/cross/libexec/gcc/arm-linux-gnueabi/5.2.0/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../gcc-5.2.0/configure
--prefix=/net/ala-rsu-lx1/ala-rsu-lx11/bpg/SHARE/GCC520/X_520/cross
--target=arm-linux-gnueabi --enable-languages=c,c++ --d\
isable-multilib
Thread model: posix
gcc version 5.2.0 (GCC)
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #19 from baoshan ---
I did a little investigation to the code:
The warning occurs because tree_int_cst_lt (up_bound, up_sub) is true here:
else if (TREE_CODE (up_sub) == INTEGER_CST
&& (ignore_off_by_one
? (tree_int_cst_lt (up_bound, up_sub)
&& !tree_int_cst_equal (up_bound_p1, up_sub))
: (tree_int_cst_lt (up_bound, up_sub)
|| tree_int_cst_equal (up_bound_p1, up_sub
{
if (dump_file && (dump_flags & TDF_DETAILS))
{
fprintf (dump_file, "Array bound warning for ");
dump_generic_expr (MSG_NOTE, TDF_SLIM, ref);
fprintf (dump_file, "\n");
}
warning_at (location, OPT_Warray_bounds,
=>"array subscript is above array bounds");
TREE_NO_WARNING (ref) = 1;
}
I dumped the tree up_bound and up_sub:
(gdb) p debug_tree(up_bound)
constant 5>
p debug_tree(up_sub)
constant 4294967291>
We can see the value of up_sub is represented as unsigned int value 4294967291
which is really weird to me, it suppose to be a int value -5 here.
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #21 from baoshan --- (In reply to Manuel López-Ibáñez from comment #20) > (In reply to baoshan from comment #19) > > We can see the value of up_sub is represented as unsigned int value > > 4294967291 which is really weird to me, it suppose to be a int value -5 > > here. > > All counters are unsigned. You can see what code looks like to GCC at > exactly that moment by using -fdump-tree-all-all-lineno and looking for that > line in test.c.079t.vrp1. > > ;; basic block 10, loop depth 1, count 0, freq 1430, maybe hot > ;; Invalid sum of incoming frequencies 1226, should be 1430 > ;;prev block 9, next block 11, flags: (NEW, REACHABLE) > ;;pred: 9 [85.7%] (TRUE_VALUE,EXECUTABLE) > ;; starting at line 9 > [test.c:9:13] # RANGE [4294967291, 4294967295] > _51 = i_2 + 4294967290; > [test.c:9:10] # RANGE [4294967291, 4294967295] NONZERO 4294967295 > _52 = (long unsigned intD.10) _51; > [test.c:9:10] # RANGE [17179869164, 17179869180] NONZERO 17179869180 > _53 = _52 * 4; > [test.c:9:10] # PT = nonlocal > _54 = bar_12(D) + _53; > [test.c:9:23] # VUSE <.MEM_48> > _55 = [test.c:9:23] bazD.1755[_51]; > [test.c:9:18] # .MEM_56 = VDEF <.MEM_48> > [test.c:9:10] *_54 = _55; > [test.c:9:13] # RANGE [4294967290, 4294967294] > _59 = i_2 + 4294967289; > [test.c:9:10] # RANGE [4294967290, 4294967294] NONZERO 4294967295 > _60 = (long unsigned intD.10) _59; > [test.c:9:10] # RANGE [17179869160, 17179869176] NONZERO 17179869180 > _61 = _60 * 4; > [test.c:9:10] # PT = nonlocal > _62 = bar_12(D) + _61; > [test.c:9:23] # VUSE <.MEM_56> > _63 = [test.c:9:23] bazD.1755[_59]; > [test.c:9:18] # .MEM_64 = VDEF <.MEM_56> > [test.c:9:10] *_62 = _63; > ;;succ: 11 [100.0%] (FALLTHRU,EXECUTABLE) > > It seems GCC at some moment unrolls the loop and creates such block with > those ranges. Probably, the block is unreachable, but it would be better to > not create it in the first place. Finding out where and why it is created > would help to figure out a fix. Don't you think the range value is strange? how it is possible the range value is so big according the code?
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #23 from baoshan --- (In reply to Manuel López-Ibáñez from comment #22) > (In reply to baoshan from comment #21) > > Don't you think the range value is strange? how it is possible the range > > value is so big according the code? > > j = i - 1 is actually j = i + 4294967295 because of unsigned. > > Thus the problematic ranges: > >[test.c:9:13] # RANGE [4294967291, 4294967295] >_51 = i_2 + 4294967290; > > are actually: > >[test.c:9:13] # RANGE [-5, -1] >_51 = i_2 - 6; > > but this code should have not been generated. Those ranges do seem > suspicious. Finding out how that block ends up with those ranges would be > helpful. You probably need to debug vrp or (using -fopt-info) the point > where gcc gives: > > test.c:7:3: note: loop turned into non-loop; it never loops. > test.c:7:3: note: loop with 5 iterations completely unrolled I have seen two places that would convert "A-1" to "A+(-1)", and due the type is unsigned int, it would be converted to "A+4294967295". This looks not right to me. The two places are: 1. fold-const.c:10626 /* A - B -> A + (-B) if B is easily negatable. */ if (negate_expr_p (arg1) && !TYPE_OVERFLOW_SANITIZED (type) && ((FLOAT_TYPE_P (type) /* Avoid this transformation if B is a positive REAL_CST. */ && (TREE_CODE (arg1) != REAL_CST || REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1 || INTEGRAL_TYPE_P (type))) => return fold_build2_loc (loc, PLUS_EXPR, type, fold_convert_loc (loc, type, arg0), fold_convert_loc (loc, type, negate_expr (arg1))); 2. c-common.c:4574 if (resultcode == MINUS_EXPR) intop = fold_build1_loc (loc, NEGATE_EXPR, sizetype, intop);
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #25 from baoshan --- (In reply to Andrew Pinski from comment #24) > (In reply to baoshan from comment #23) > > I have seen two places that would convert "A-1" to "A+(-1)", and due the > > type is unsigned int, it would be converted to "A+4294967295". This looks > > not right to me. > > Why wrapping is well defined for unsigned types so adding 4294967295 is the > same as subtracting by 1. What is wrapping? and where it is defined? I don't know this part and I like to learn it. Thanks.
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #27 from baoshan --- > It seems GCC at some moment unrolls the loop and creates such block with > those ranges. Probably, the block is unreachable, but it would be better to > not create it in the first place. Finding out where and why it is created > would help to figure out a fix. At pass "cunrolli", it would unroll the loops according the estimated iterate times. The problem is at this time it use array ref(infer_loop_bounds_from_ref) to infer the iterate times which is not accurate. The inaccurate iterate times result the extra blocks. I am not sure which way to go at this point. Should we add value range propagation in/before "cunrolli" so we can get the accurate iterate times? or We just disable the warning being reported at "vrp" pass?
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #29 from baoshan --- > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5 > times + 1). Why is this estimate wrong? The max value of n is 6, so the max value of i is 5 as "i < n", then the max value of j is 4 as "j = i - 1" which means the max iterate times is 4.
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #31 from baoshan --- (In reply to Manuel López-Ibáñez from comment #30) > (In reply to baoshan from comment #29) > > > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5 > > > times + 1). Why is this estimate wrong? > > > > The max value of n is 6, so the max value of i is 5 as "i < n", then the max > > value of j is 4 as "j = i - 1" which means the max iterate times is 4. > > True! Well, that reinforces my point that something is very wrong in the > estimation. What is it? At the pass "cunrolli", it infers the iterative times by checking the array's boundary, as we have "unsigned baz[6];", it would think the max value of iterative times is 6.
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 --- Comment #32 from baoshan --- (In reply to Manuel López-Ibáñez from comment #30) > (In reply to baoshan from comment #29) > > > However, it is clear that _14 = baz[_9] is executed only 5 times (not 5 > > > times + 1). Why is this estimate wrong? > > > > The max value of n is 6, so the max value of i is 5 as "i < n", then the max > > value of j is 4 as "j = i - 1" which means the max iterate times is 4. > > True! Well, that reinforces my point that something is very wrong in the > estimation. What is it? And I think it is not wrong, it's just inaccurate, and it is not making any wrong result in running time. Can you point me how to proceed?
[Bug rtl-optimization/67750] New: undefined local label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67750
Bug ID: 67750
Summary: undefined local label
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
Target Milestone: ---
Steps to reproduce:
1. cat 1.c
typedef unsigned int size_t;
typedef struct y4m_input y4m_input;
typedef void (*y4m_convert_func)(y4m_input *_y4m,
unsigned char *_dst, unsigned char *_src);
typedef enum vpx_img_fmt {
VPX_IMG_FMT_NONE,
VPX_IMG_FMT_RGB24,
VPX_IMG_FMT_RGB32,
VPX_IMG_FMT_RGB565,
VPX_IMG_FMT_RGB555,
VPX_IMG_FMT_UYVY,
VPX_IMG_FMT_YUY2,
VPX_IMG_FMT_YVYU,
VPX_IMG_FMT_BGR24,
VPX_IMG_FMT_RGB32_LE,
VPX_IMG_FMT_ARGB,
VPX_IMG_FMT_ARGB_LE,
VPX_IMG_FMT_RGB565_LE,
VPX_IMG_FMT_RGB555_LE,
VPX_IMG_FMT_YV12 = 0x100 | 0x200 | 1,
VPX_IMG_FMT_I420 = 0x100 | 2,
VPX_IMG_FMT_VPXYV12 = 0x100 | 0x200 | 3,
VPX_IMG_FMT_VPXI420 = 0x100 | 4,
VPX_IMG_FMT_I422 = 0x100 | 5,
VPX_IMG_FMT_I444 = 0x100 | 6,
VPX_IMG_FMT_444A = 0x100 | 0x400 | 7
} vpx_img_fmt_t;
struct y4m_input {
int pic_w;
int pic_h;
int fps_n;
int fps_d;
int par_n;
int par_d;
char interlace;
int src_c_dec_h;
int src_c_dec_v;
int dst_c_dec_h;
int dst_c_dec_v;
char chroma_type[16];
size_t dst_buf_sz;
size_t dst_buf_read_sz;
size_t aux_buf_sz;
size_t aux_buf_read_sz;
y4m_convert_func convert;
unsigned char *dst_buf;
unsigned char *aux_buf;
enum vpx_img_fmt vpx_fmt;
int vpx_bps;
};
void y4m_convert_mono_420jpeg(y4m_input *_y4m, unsigned char *_dst,
unsigned char *_aux) {
int c_sz;
_dst += _y4m->pic_w * _y4m->pic_h;
c_sz = ((_y4m->pic_w + _y4m->dst_c_dec_h - 1) / _y4m->dst_c_dec_h) *
((_y4m->pic_h + _y4m->dst_c_dec_v - 1) / _y4m->dst_c_dec_v);
memset(_dst, 128, c_sz * 2);
}
2. ./xgcc -m32 -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double -O2 -pipe -g
-fno-omit-frame-pointer -fvisibility=default -fstack-protector-all
-D_FORTIFY_SOURCE=2 -v -O3 -fPIC -Wall -Wdeclaration-after-statement
-Wdisabled-optimization -Wpointer-arith -Wtype-limits -Wcast-qual -Wvla
-Wimplicit-function-declaration -Wuninitialized -Wunused-variable
-Wunused-but-set-variable -Wno-unused-function -S 1.c -o 1.s
3. In 1.s we can see the local label "LCL0" is referenced in several places but
not defined in anywhere.
./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc-abc-linuxeabispe
Configured with: ../gcc-4.9.1/configure --build=x86_64-pc-linux
--host=x86_64-pc-linux --target=powerpc-abc-linuxeabispe
--with-glibc-version=2.5
Thread model: posix
gcc version 4.9.1 (GCC)
[Bug rtl-optimization/67750] undefined local label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67750 --- Comment #1 from baoshan --- I think the problem is at shrink wrap optimization, and I also verified the problem would disappear with option "-fno-shrink-wrap".
[Bug target/67750] undefined local label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67750 --- Comment #3 from baoshan --- (In reply to Andrew Pinski from comment #2) > Can you try 5.x? With the test case this issue can not be reproduced. But I still think the same problem is also existed in 5.x， it works by coincidence: In 4.9.0, the code(pseudo) is like this: set r0, LCL0 ... set r0, rx ... debug_insn var X (... r0) The pass "shrink wrap" would move "set r0, rx" after the debug instruction which eventually make GCC think the "r0" defined in "set r0, LCL0" is used by the debug instruction. But in 5.x, the two 'set' instructions don't use the same register, so even the "set r0, rx" also has been moved after debug instruction, it would result the undefined local label issue.
[Bug target/67750] undefined local label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67750 --- Comment #4 from baoshan --- > the "set r0, rx" also has been moved after debug instruction, it would > result the undefined local label issue. Sorry, it should be "It would NOT result the undefined local label issue."
[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 baoshan changed: What|Removed |Added CC||pangbw at gmail dot com --- Comment #9 from baoshan --- (In reply to Jakub Jelinek from comment #6) >> I.e. not perform it at all if !MAY_HAVE_DEBUG_INSNS, and use D There are some regression test cases would check if the generated RTL are same with or without debug option enabled(like gcc.dg/pr45055.c), so if we perform optimization depend on if there is debug instructions, these test cases would fail. Will GCC community accept such patch with these regressions? I have a fix that could fix this issue but with regression on pr45055.c, so far I am hesitate if I can post it for review.
[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
--- Comment #10 from baoshan ---
This is my fix for this issue, any comment is welcome.
---
10 gcc/function.c |5 +++--
11 1 files changed, 3 insertions(+), 2 deletions(-)
12
13 diff --git a/gcc/function.c b/gcc/function.c
14 index 1a8682b..a9df397 100644
15 --- a/gcc/function.c
16 +++ b/gcc/function.c
17 @@ -5561,8 +5561,9 @@ prepare_shrink_wrap (basic_block entry_block)
18 CLEAR_HARD_REG_SET (uses);
19 CLEAR_HARD_REG_SET (defs);
20 FOR_BB_INSNS_REVERSE_SAFE (entry_block, insn, curr)
21 -if (NONDEBUG_INSN_P (insn)
22 - && !move_insn_for_shrink_wrap (entry_block, insn, uses, defs))
23 +if (INSN_P(insn) &&
24 + (DEBUG_INSN_P (insn)
25 +|| !move_insn_for_shrink_wrap (entry_block, insn, uses, defs)))
26 {
27 /* Add all defined registers to DEFs. */
28 for (ref = DF_INSN_DEFS (insn); *ref; ref++)
[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 --- Comment #12 from baoshan --- (In reply to Andrew Pinski from comment #11) > I suspect this was fixed for GCC 6 with the patch that fixed bug 67789 > (which is the more correct patch). I think they are two different issues. 67789 is duplicate label defined, this is undefined label.
[Bug libgcc/59412] __fixunsdfDI triggers wrong inexact exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59412 --- Comment #2 from baoshan --- Why this has been unconfirmed for so long time? Can someone tell us if this is a bug in libgcc2.c or not? Thanks.
[Bug libgcc/59412] __fixunsdfDI triggers wrong inexact exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59412 --- Comment #4 from baoshan --- (In reply to jos...@codesourcery.com from comment #3) > It's a bug in libgcc2.c for the subset of targets for which this code gets > used (note 64-bit targets will generally be using it for TImode not > DImode) *and* which have hardware exceptions. It's part of the general > large group of bugs relating to code generation / transformations not > consistently accounting for exceptions / rounding modes. Hi Joseph, Thanks for the quick response. Do you know if there is fix for this issue? Thanks, Baoshan
[Bug rtl-optimization/64532] New: [5 regression on ARM]internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532
Bug ID: 64532
Summary: [5 regression on ARM]internal compiler error: Max.
number of generated reload insns per insn is achieved
(90)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
I know this ICE has been reported many times, but I still want to report it
again because I am not sure if my case is same as other reported cases.
Steps to reproduce:
1. cat y.i
__attribute__((noinline)) float s32_to_f32_imm1(int x)
{
float y;
__asm__ ("vcvt.f32.s32 %0, %1, #1" : "=w"(y) : "0"(x));
return y;
}
2. ./xgcc y.i -B. -mfloat-abi=hard -mfpu=neon -O2
y.i: In function ‘s32_to_f32_imm1’:
y.i:6:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)
}
^
0x973325 lra_constraints(bool)
../../../gcc/gcc/lra-constraints.c:4306
0x95f689 lra(_IO_FILE*)
This is the GCC used by me:
./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-linux-gnueabi
Configured with: ../../gcc/configure --target=arm-linux-gnueabi
Thread model: posix
gcc version 5.0.0 20150107 (experimental) (GCC)
[Bug rtl-optimization/64532] [5 regression on ARM]internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #1 from baoshan ---
One observation is that without "-mfloat-abi=hard -mfpu=neon", I will get
this:
./xgcc y.i -B. -O2
y.i: In function ‘s32_to_f32_imm1’:
y.i:4:3: error: inconsistent operand constraints in an ‘asm’
__asm__ ("vcvt.f32.s32 %0, %1, #1" : "=w"(y) : "0"(x));
[Bug rtl-optimization/64532] [5 regression on ARM]internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532 --- Comment #4 from baoshan --- Can someone help to 'confirm' this bug?
[Bug rtl-optimization/64532] [4.9, 5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532 --- Comment #6 from baoshan --- After several days study to the code, I turn to feel the code is wrong. It seems we should use "=t" instead of "=w" for 'y' because single float register is expected here for "vcvt.f32.s32". From the document, "w" just means VFP floating-point register but not distinguishing single, double or quad float register: https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints The constraint letter 't' is not documented in the GCC doc, this is a issue.
[Bug target/64532] [4.9/5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532 --- Comment #10 from baoshan --- I have a second thought: As the 'y' is declared as float, should GCC infer the register is a single float register even the constraint is 'w' ?
[Bug testsuite/64911] New: FAIL: gcc.c-torture/execute/builtins/strchr.c compilation, -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64911 Bug ID: 64911 Summary: FAIL: gcc.c-torture/execute/builtins/strchr.c compilation, -O0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pangbw at gmail dot com In one of my environment, I will get the multiple definition error for this test case. In another one of my environment, I will not get the error. After checking the code in linker I think this is a flaw in linker and this is a bug in the test case as we should always report multiple definition as an error when a function(strchr) is defined in two places(libc.a and this test case).
[Bug other/63492] bconfig.h or config.h for gencondmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492 --- Comment #4 from baoshan --- This bug was filed by mistake, please help to close it.
[Bug other/63492] New: bconfig.h or config.h for gencondmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492 Bug ID: 63492 Summary: bconfig.h or config.h for gencondmd.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pangbw at gmail dot com I know config.h is for program running on host machine, bconfig.h is for program running on build machine, but for gencondmd.c the case is special, it is evaluating the macros would be defined on host instead of build machine, so I think config.h should be used for gencondmd.c.
[Bug other/63492] bconfig.h or config.h for gencondmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492 --- Comment #1 from baoshan --- CCing Mark who approved the born of genconditions.c, it seems the author Zack is busy on his study on colleague.
[Bug target/61298] redundant compare instructions for powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298
--- Comment #4 from baoshan ---
(In reply to Peter Bergner from comment #3)
>> I can say that unsigned_reg_p() probably doesn't catch every case
>> where we're doing an unsigned compare and force it to use non
> signed compare. Since you have a subreg, have you looked at
> how SUBREG_PROMOTED_UNSIGNED_P is set? Is that supposed to be
> set for your case?
Yes, SUBREG_PROMOTED_UNSIGNED_P is supposed to be set for this case, it has
been set originally, but the setting is lost while doing mode converting in
function convert_modes():expr.c, do you think the following code is good enough
to fix this issue?
rtx
convert_modes (enum machine_mode mode, enum machine_mode oldmode, rtx x, int
unsignedp)
{
rtx temp;
/* If FROM is a SUBREG that indicates that we have already done at least
the required extension, strip it. */
if (GET_CODE (x) == SUBREG && SUBREG_PROMOTED_VAR_P (x)
&& GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))) >= GET_MODE_SIZE (mode)
&& SUBREG_PROMOTED_UNSIGNED_P (x) == unsignedp) {
x = gen_lowpart (mode, SUBREG_REG (x));
if(GET_CODE (x) == SUBREG) {
SUBREG_PROMOTED_VAR_P (x) = 1;
SUBREG_PROMOTED_UNSIGNED_SET (x, unsignedp);
}
}
.
.
.
[Bug target/61622] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622 baoshan changed: What|Removed |Added CC||pangbw at gmail dot com --- Comment #2 from baoshan --- (In reply to roland from comment #1) > Created attachment 33013 [details] > test case preprocessed source > > I had to gzip the file to make bugzilla accept it. What command line have you used to see this issue?
[Bug target/61622] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622 --- Comment #4 from baoshan --- This should be a duplication to Bug 57431.
[Bug c++/61674] The destructor of a simple class is removed by optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61674 baoshan changed: What|Removed |Added CC||pangbw at gmail dot com --- Comment #5 from baoshan --- (In reply to Alex Finch from comment #4) > I should add that this problem was not observed in gcc 4.4.7 and earlier. Can you explain why you think it is a bug? Sometimes the code has been optimized away just because it is not useful for the program running correctly.
[Bug preprocessor/62086] New: A bug with option -fextended-identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086
Bug ID: 62086
Summary: A bug with option -fextended-identifiers
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
For this simple code, it would compile without -fextended-identifiers but fail
with it:
$cat ~/x.c
int main()
{
#if 0
int \u00A8\u00AA\u00AD\u00AF\u00B2\u00B5 = 7;
#endif
}
$ gcc -c ~/x.c
$ gcc -c -fextended-identifiers ~/x.c
x.c: In function ‘main’:
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: error: universal character \u00A8 is not valid in an identifier
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: error: universal character \u00AD is not valid in an identifier
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: error: universal character \u00AF is not valid in an identifier
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
x.c:4:7: error: universal character \u00B2 is not valid in an identifier
x.c:4:7: warning: universal character names are only valid in C++ and C99
[enabled by default]
[Bug preprocessor/62086] A bug with option -fextended-identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086 --- Comment #2 from baoshan --- Are you sure \u00A8\u00AA\u00AD\u00AF\u00B2\u00B5 is invalid for C++ standard? or it is just invalid for GCC now? I extracted this code from a C++ test suite, and I think it should be valid for C++11.
[Bug preprocessor/62086] A bug with option -fextended-identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086 baoshan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from baoshan --- Yes, there would be no issue if compiling it with g++ and -std=c++03 or -std=c++11. I have set it to invalid.
[Bug c++/62145] New: match rulers in overload functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62145
Bug ID: 62145
Summary: match rulers in overload functions
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
For this small program, G++ and clang++ don't agree with each other:
1. cat x2.c
#include
char f(...) { return '\1'; };
int f(void*) { return 999; }
constexpr int t2(int n) { return sizeof f(n*0); }
int main()
{
char b[ t2(0) ];
printf("sizeof b is %d\n", sizeof(b));
return 0;
}
2.
$ g++ -std=c++0x x2.cpp
$ ./a.out
sizeof b is 4
$ clang++ -std=c++11 x2.cpp
$ ./a.out
sizeof b is 1
It shows G++ is calling f(void*), but clang++ is calling f(...). which one is
right?
[Bug c++/62145] match rulers in overload functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62145 baoshan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from baoshan --- (In reply to Andrew Pinski from comment #1) > I think clang due to n*0 is not a NULL POINTER constant expression. This is > like PR 59704. Thanks for letting me know it, I agree it is the same problem as PR 59704. *** This bug has been marked as a duplicate of bug 59704 ***
[Bug c++/59704] Wrong overload chosen, compiler errornously thinks non-constant zero expression is implicitly castable to null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59704 baoshan changed: What|Removed |Added CC||pangbw at gmail dot com --- Comment #1 from baoshan --- *** Bug 62145 has been marked as a duplicate of this bug. ***
[Bug c++/62189] New: Different result between 4.6 and 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62189
Bug ID: 62189
Summary: Different result between 4.6 and 4.9.1
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
For this program, I get different result for G++ 4.6.3 and G++ 4.9.1, and I
have a C++ test suite which thinks 4.6.3 is right:
#include
#include
int (*pfb_)() = nullptr;
int main()
{
std::function< int() > e (pfb_);
std::cout << !!e << std::endl;
return 0;
}
For 4.6.3 the output is 1 but for 4.9.1 the output is 0.
[Bug c++/62196] New: running time segment fault with valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62196
Bug ID: 62196
Summary: running time segment fault with valarray
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
The code would segment fault at running time, I see the same result with G++
4.6.3(which comes with Ubuntu 12.04) and 4.9.1:
#include
#include
int main(int argc, char *argv[])
{
const char vl[] = {"abcdefghijklmnopqrstuvwxyz"};
const char vu[] = {"ABCDEFGHIJKLMNOPQRSTUVWXYZ"};
const std::valarray v0(vl, 27), vm6(vu, 6);
const bool vb[] = {false, false, true, true, false, true};
const std::valarray vmask(vb, 6);
std::valarray x = v0;
for(int i = 0; i < x.size(); i++)
std::cout << x[i];
std::cout << std::endl;
x[vmask] = vm6;
for(int i = 0; i < x.size(); i++)
std::cout << x[i];
std::cout << std::endl;
return 0;
}
The command line is just simply as:
g++ -std=c++0x x.cpp
[Bug rtl-optimization/48826] ICE in dwarf2out_var_location, at dwarf2out.c:22013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #10 from baoshan ---
The code is broken in the latest code because beside NOTE instruction there
could be BARRIER too, for instance the RTX list I am seeing:
(call_insn 32 35 33 (parallel [
(set (reg:SI 2 $2)
(call (mem:SI (reg:SI 25 $25 [198]) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 31 $31))
(clobber (reg:SI 28 $28))
]) min.c:20 603 {call_value_split}
(nil)
(expr_list (use (reg:SI 79 $fakec))
(expr_list (use (reg:SI 28 $28))
(expr_list:SI (use (reg:SI 5 $5))
(expr_list:SI (use (reg:SI 4 $4))
(nil))
(insn 33 32 34 (set (reg:SI 28 $28)
(mem/c:SI (plus:SI (reg/f:SI 29 $sp)
(const_int 16 [0x10])) [0 S4 A32])) min.c:20 288
{*movsi_internal}
(nil))
(barrier 34 33 18)
(barrier 18 34 30)
(note 30 18 21 (expr_list:REG_DEP_TRUE (concat:SI (pc)
(unspec:SI [
(reg:SI 28 $28)
(const:SI (unspec:SI [
(symbol_ref:SI ("signal") [flags 0x41]
)
] 227))
(reg:SI 79 $fakec)
] UNSPEC_LOAD_CALL))
(expr_list:REG_DEP_TRUE (concat:SI (reg:SI 5 $5)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (concat:SI (reg:SI 4 $4)
(const_int 2 [0x2]))
(nil NOTE_INSN_CALL_ARG_LOCATION)
(note 21 30 0 NOTE_INSN_DELETED)
[Bug rtl-optimization/48826] ICE in dwarf2out_var_location, at dwarf2out.c:22013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826
--- Comment #11 from baoshan ---
And I don't thing it is the best place to fix this bug in function try_split().
Why not fix it at where the ICE occurs? It is just the wrong expectation from
function dwarf2out_var_location(). Why not just look forward further if the
'prev'is not what we want? I like to add this code before gcc_assert() to fix
this issue:
while(prev && !CALL_P(prev) && !(GET_CODE (PATTERN (prev)) == SEQUENCE
&& CALL_P (XVECEXP (PATTERN (prev), 0, 0{
gcc_assert(NONJUMP_INSN_P (prev));
prev = prev_real_insn (prev);
}
[Bug c/63234] New: arm used label is removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234 Bug ID: 63234 Summary: arm used label is removed Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pangbw at gmail dot com
[Bug target/63234] arm used label is removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
baoshan changed:
What|Removed |Added
Version|4.9.1 |4.9.0
--- Comment #2 from baoshan ---
1. configure & build gcc
$ PATH_TO_SRC/configure --enable-languages=c --target=arm-linux-eabi
--enable-tls
$ make
2. cat m.c
typedef struct _GHashTable GHashTable;
typedef struct _DNSCacheEntry DNSCacheEntry;
typedef struct _DNSCacheKey DNSCacheKey;
struct _DNSCacheKey
{
};
struct _DNSCacheEntry
{
DNSCacheEntry *prev, *next;
DNSCacheKey key;
};
struct __tls_variables
{
GHashTable *cache;
DNSCacheEntry persist_first;
DNSCacheEntry persist_last;
}
;
static __thread struct __tls_variables __tls;
dns_cache_cleanup_persistent_hosts (void)
{
while ((__tls.persist_first).next != &(__tls.persist_last))
{
g_hash_table_remove ((__tls.cache), &(__tls.persist_first).next->key);
}
}
3. cc1 -O1 -fPIC m.c -o m.s
4. cat m.s
In the output you can see there is one line at the end of file:
.word .LANCHOR0(tlsldm) + (. - .LPIC3 - 8)
But the lable .LPIC3 is not existed in the file.
[Bug target/63234] arm used label is removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234 --- Comment #5 from baoshan --- I dig it deeper yesterday, and I believe this change makes the 5.0 works fine: https://github.com/gcc-mirror/gcc/commit/9b59e2174ee59dd3aa55c7c3342daa2a6bc23fba
[Bug rtl-optimization/63348] New: regression gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 Bug ID: 63348 Summary: regression gcc.dg/pr43670.c fail on MIPS Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pangbw at gmail dot com 1. Build GCC: $ configure --enable-languages=c --target=mips-linux --with-as=PATH_TO_MIPS_AS (--with-as is needed to set TARGET_CPU_DEFAULT with MASK_EXPLICIT_RELOCS in tm.h) $ make 2. Compile $ ./xgcc -O -fcompare-debug pr43670.c -I. -c xgcc: error: pr43670.c: -fcompare-debug failure (length)
[Bug rtl-optimization/63348] regression gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 --- Comment #1 from baoshan --- I believe this regression is introduced by the code for cleanup_barriers() in jump.c of patch https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02164.html: The call insn was followed by a barrier insn, the try_split() would emit another barrier insn after call insn for this case( I don't know why, please let me know the reason); after applying that patch and with option "-g" there would be a note instruction between the call and barrier insns which result no barrier insn is emitted by try_split().
[Bug rtl-optimization/63348] [5 Regression] gcc.dg/pr43670.c fail on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 --- Comment #6 from baoshan --- (In reply to Uroš Bizjak from comment #5) > (In reply to baoshan from comment #1) > > I believe this regression is introduced by the code for cleanup_barriers() > > in jump.c of patch https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02164.html: > > > > The call insn was followed by a barrier insn, the try_split() would emit > > another barrier insn after call insn for this case( I don't know why, please > > let me know the reason); after applying that patch and with option "-g" > > there would be a note instruction between the call and barrier insns which > > result no barrier insn is emitted by try_split(). > > Can you please try the patch at [1]? > > [1] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02180.html It fixes the issue, Thanks for your quick action.
[Bug c/106818] New: code is genereated differently with or without 'extern'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106818 Bug ID: 106818 Summary: code is genereated differently with or without 'extern' Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pangbw at gmail dot com Target Milestone: --- Just wondering why GCC would generate such different code: https://godbolt.org/z/ncE5sWYe8
[Bug c/106818] code is genereated differently with or without 'extern'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106818 --- Comment #1 from baoshan --- With 'extern', four 'sb' are ued to store value into "p->i"; while without 'extern', only one 'sw' is used.
[Bug middle-end/106818] code is genereated differently with or without 'extern'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106818
--- Comment #5 from baoshan ---
Per Andrew's request:
For GCC built for RISC-V,
With the following code:
struct sss_t {
int i;
int j;
} sss;
extern char array[sizeof(struct sss_t )];
void foo()
{
struct sss_t *p = (struct sss_t *)array;
p->i = 10;
}
The following asm is generated:
foo():
lui a5,%hi(array)
li a4,10
sb a4,%lo(array)(a5)
sb zero,%lo(array+1)(a5)
sb zero,%lo(array+2)(a5)
sb zero,%lo(array+3)(a5)
ret
sss:
.zero 8
While if remove the 'extern' from the C code, the following asm is generated:
foo():
lui a5,%hi(array)
li a4,10
sw a4,%lo(array)(a5)
ret
array:
.zero 8
sss:
.zero 8
[Bug middle-end/106818] code is genereated differently with or without 'extern'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106818 --- Comment #6 from baoshan --- > really of unknown alignment then sharing the lui might not work. Can you elaborate why shareing the lui might not work?
