Re: A working GIMPLE simple IPA case to run?
On 2/17/21 5:21 AM, Shuai Wang via Gcc wrote: Could anyone shed some light on this? Thank you very much! Hello. I would recommend looking at any of the existing passes: $ git grep SIMPLE_IPA_PASS ... One reasonable example can be gcc/tree-profile.c. Cheers, Martin
using undeclared function returning bool results in wrong return value
I run into a problem that I'm not sure whether it's a bug in my program (most
likely) or something wrong with GCC (highly unlikely, I know, hence why I
haven't sent this to gcc-bugs). The problem is using a function that returns a
bool, defined in another source file without a declaration, and the program
compiled with -O. In my test, function foo1 returns true while it should be
returning false.
Here are the files and repro:
/* main.c */
#include
#include
#include
bool foo2(int);
void main(void) {
assert(!foo2(0));
assert(!foo1(0));
}
/* foo.c */
#include
bool foo1(int n) {
return n == 1 || n == 2 || n == 4;
}
bool foo2(int n) {
return foo1(n);
}
# gcc --version
gcc (Debian 8.3.0-6) 8.3.0
# gcc main.c foo.c -O
In file included from main.c:3:
main.c: In function 'main':
main.c:9:10: warning: implicit declaration of function 'foo1'; did you mean
'foo2'? [-Wimplicit-function-declaration]
assert(!foo1(0));
^~~~
# ./a.out
a.out: main.c:9: main: Assertion `!foo1(0)' failed.
Aborted
I get the same behavior if I use char instead of bool.
The problem goes away if:
1. I declare foo1 in main.c (just like I do for foo2), or
2. compile w/o -O, or
3. use n == 3 instead of n == 4 in the return statement, or
4. use short or int instead of bool/char.
Am I causing undefined behavior because I'm not declaring foo1?
Please CC me in your response, I'm not subscribed to this list.
Re: using undeclared function returning bool results in wrong return value
On 2/17/21 2:05 PM, Thanos Makatos via Gcc wrote:
I run into a problem that I'm not sure whether it's a bug in my program (most
likely) or something wrong with GCC (highly unlikely, I know, hence why I
haven't sent this to gcc-bugs). The problem is using a function that returns a
bool, defined in another source file without a declaration, and the program
compiled with -O. In my test, function foo1 returns true while it should be
returning false.
Here are the files and repro:
/* main.c */
#include
#include
#include
bool foo2(int);
void main(void) {
assert(!foo2(0));
assert(!foo1(0));
}
/* foo.c */
#include
bool foo1(int n) {
return n == 1 || n == 2 || n == 4;
}
bool foo2(int n) {
return foo1(n);
}
# gcc --version
gcc (Debian 8.3.0-6) 8.3.0
# gcc main.c foo.c -O
In file included from main.c:3:
main.c: In function 'main':
main.c:9:10: warning: implicit declaration of function 'foo1'; did you mean
'foo2'? [-Wimplicit-function-declaration]
assert(!foo1(0));
^~~~
# ./a.out
a.out: main.c:9: main: Assertion `!foo1(0)' failed.
Aborted
I get the same behavior if I use char instead of bool.
The problem goes away if:
1. I declare foo1 in main.c (just like I do for foo2), or
2. compile w/o -O, or
3. use n == 3 instead of n == 4 in the return statement, or
4. use short or int instead of bool/char.
Am I causing undefined behavior because I'm not declaring foo1?
Yes.
Implicit function declarations are assumed to return int so defining
one that doesn't match is undefined. If the function is defined to
return a smaller type the value may be passed in only a part of
a register (with the remaining bits left unchanged) and the caller
will be looking at the whole thing.
Martin
Please CC me in your response, I'm not subscribed to this list.
Re: using undeclared function returning bool results in wrong return value
On Wed, 17 Feb 2021, 21:12 Thanos Makatos via Gcc, wrote: > I run into a problem that I'm not sure whether it's a bug in my program > (most likely) or something wrong with GCC (highly unlikely, I know, hence > why I haven't sent this to gcc-bugs). This is the wrong list, please use gcc-help for questions like this. The problem is using a function that returns a bool, defined in another > source file without a declaration, and the program compiled with -O. In my > test, function foo1 returns true while it should be returning false. > As Martin explained, the compiler assumes that an implicitly-declared function returns an int. Your function initializes a single byte with its return value and the caller reads 4 bytes, including 3 bytes of uninitialized garbage. If that garbage happens to contains any non-zero bits, you get a non-zero int and converting that to bool yields true. Declare your functions. Don't ignore warnings.
Performing inter-procedural dataflow analysis
Hello,
I am doing interprocedural dataflow analysis and countered the following
issue. Suppose I have an GIMPLE IR code as follows, which is after the
"simdclone" pass while before my own SIMPLE IPA pass:
foo (int a, int b)
{
int c;
int d;
int D.2425;
int _5;
:
* c_4 = a_2(D) + b_3(D); *
* _5 = c_4;*
As you can see, while propagating certain dataflow facts among local
variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly somehow
"link" function parameter "a" (or "b") with its first local usage "a_2(D)"
or "b_3(D)".
So my question is, when traversing the GIMPLE statements and encounter SSA
variables like "a_2(D)" or "b_3(D)", how do I know they originate from
parameter "a" and "b"?
Thank you!
Best,
Shuai
Re: Performing inter-procedural dataflow analysis
By saying a_2(D) originated from parameter "a", what I mean is that I
obtain the tree pointer of "a" given the tree pointer of a_2(D). Is that
possible? I can somehow image to first get the string name of these
variables and do a clumsy (?) comparison. But that seems not very handy...
Thank you!
On Thu, Feb 18, 2021 at 11:09 AM Shuai Wang wrote:
> Hello,
>
> I am doing interprocedural dataflow analysis and countered the following
> issue. Suppose I have an GIMPLE IR code as follows, which is after the
> "simdclone" pass while before my own SIMPLE IPA pass:
>
>
> foo (int a, int b)
> {
> int c;
> int d;
> int D.2425;
> int _5;
>
>:
> * c_4 = a_2(D) + b_3(D); *
> * _5 = c_4;*
>
>
> As you can see, while propagating certain dataflow facts among local
> variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly
> somehow "link" function parameter "a" (or "b") with its first local usage
> "a_2(D)" or "b_3(D)".
>
> So my question is, when traversing the GIMPLE statements and encounter SSA
> variables like "a_2(D)" or "b_3(D)", how do I know they originate from
> parameter "a" and "b"?
>
> Thank you!
>
> Best,
> Shuai
>
>
>
>
Copyright Assignment Form
Hey, I would like to contribute some patches to the gccrs project (https://github.com/Rust-GCC/gccrs/) and I'd like to get a copyright assignment form as per the guidelines outlined at https://gcc.gnu.org/contribute.html. Do let me know if there are any more steps involved. Thanks, Akshat Agarwal
Re: Performing inter-procedural dataflow analysis
On Thu, 18 Feb 2021 at 08:39, Shuai Wang via Gcc wrote:
>
> Hello,
>
> I am doing interprocedural dataflow analysis and countered the following
> issue. Suppose I have an GIMPLE IR code as follows, which is after the
> "simdclone" pass while before my own SIMPLE IPA pass:
>
>
> foo (int a, int b)
> {
> int c;
> int d;
> int D.2425;
> int _5;
>
>:
> * c_4 = a_2(D) + b_3(D); *
> * _5 = c_4;*
>
>
> As you can see, while propagating certain dataflow facts among local
> variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly somehow
> "link" function parameter "a" (or "b") with its first local usage "a_2(D)"
> or "b_3(D)".
>
> So my question is, when traversing the GIMPLE statements and encounter SSA
> variables like "a_2(D)" or "b_3(D)", how do I know they originate from
> parameter "a" and "b"?
You can use SSA_NAME_VAR to get the "base" variable corresponding to ssa name,
and then check it against PARM_DECL.
Sth like:
is_param = TREE_CODE (SSA_NAME_VAR (ssa_name)) == PARM_DECL;
Thanks,
Prathamesh
>
> Thank you!
>
> Best,
> Shuai
