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?
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
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.
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=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=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
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=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)
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
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
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=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."
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,
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
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
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
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
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
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
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
baoshan changed:
What|Removed |Added
CC||pangbw at gmail dot com
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492
--- Comment #4 from baoshan pangbw at gmail dot com ---
This bug was filed by mistake, please help to close it.
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=64532
--- Comment #10 from baoshan pangbw at gmail dot com ---
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' ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532
--- Comment #6 from baoshan pangbw at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64532
--- Comment #4 from baoshan pangbw at gmail dot com ---
Can someone help to 'confirm' this bug?
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 pangbw at gmail dot com changed:
What|Removed |Added
CC||pangbw at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492
--- Comment #1 from baoshan pangbw at gmail dot com ---
CCing Mark who approved the born of genconditions.c, it seems the author Zack
is busy on his study on colleague.
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=63348
--- Comment #6 from baoshan pangbw at gmail dot com ---
(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
-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 pangbw at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
--- Comment #5 from baoshan pangbw at gmail dot com ---
I dig it deeper yesterday, and I believe this change makes the 5.0 works fine:
https://github.com/gcc-mirror/gcc/commit/9b59e2174ee59dd3aa55c7c3342daa2a6bc23fba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63234
baoshan pangbw at gmail dot com changed:
What|Removed |Added
Version|4.9.1 |4.9.0
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826
baoshan pangbw at gmail dot com changed:
What|Removed |Added
CC||pangbw at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826
--- Comment #11 from baoshan pangbw at gmail dot com ---
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
: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
++
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 functional
++
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 iostream
#include valarray
int main(int argc, char *argv[])
{
const
++
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 stdio.h
char f(...) { return '\1'; };
int f(void*) { return 999; }
constexpr int t2(int n) { return sizeof f(n*0); }
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62145
baoshan pangbw at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59704
baoshan pangbw at gmail dot com changed:
What|Removed |Added
CC||pangbw at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086
--- Comment #2 from baoshan pangbw at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62086
baoshan pangbw at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
: 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=61674
baoshan pangbw at gmail dot com changed:
What|Removed |Added
CC||pangbw at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622
--- Comment #4 from baoshan pangbw at gmail dot com ---
This should be a duplication to Bug 57431.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622
baoshan pangbw at gmail dot com changed:
What|Removed |Added
CC||pangbw at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298
--- Comment #4 from baoshan pangbw at gmail dot com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298
baoshan pangbw at gmail dot com changed:
What|Removed |Added
CC||pangbw at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61494
baoshan pangbw at gmail dot com changed:
What|Removed |Added
CC||pangbw at gmail dot com
57 matches
Mail list logo
