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
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 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70567
--- Comment #1 from baoshan ---
This issue is seen from 4.8 to 5.0.
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 < cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61494
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #18 from
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
?
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 su
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?
>
>
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
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 wh
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
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 wron
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 wron
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
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".
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
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."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #9 from
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/functi
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
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.
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) *
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532
--- Comment #4 from baoshan ---
Can someone help to 'confirm' this bug?
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"
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' ?
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
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.
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
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622
--- Comment #4 from baoshan ---
This should be a duplication to Bug 57431.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61674
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #5 from
: 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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086
baoshan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62145
baoshan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59704
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #1 from
++
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
++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #10 from
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 fo
: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
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. conf
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
-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
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()
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-pat
ty: 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
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.
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 *)ar
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?
57 matches
Mail list logo
