Below is a documented we have drafted to provide guidance on using
irange's and converting passes to it. This will future proof any such
passes so that they will work with the ranger, or any other mechanism
using multiple sub-ranges (as opposed to the more limited value_range).
The official d
I think every SSA_NAME variable has a:
* ptr_info_def*
* which points to a pt_solution
* which points to a bitmap field vars
and I think this bitmap vars is set with 1 in the UID location of
variables/references that an SSA_NAME variable might point to it.
So, I am just wondering is there an
On Thu, Sep 03, 2020 at 10:22:52AM +0200, Erick Ochoa wrote:
> So, I am just wondering is there an interface where I could do something
> like:
>
> ```
> // vars is the field in pt_solution of type bitmap
> EXECUTE_IF_SET_IN_BITMAP (vars, 0, uid, bi)
> {
>// uid is set
>
On Thu, Sep 3, 2020 at 10:58 AM Jakub Jelinek via Gcc wrote:
>
> On Thu, Sep 03, 2020 at 10:22:52AM +0200, Erick Ochoa wrote:
> > So, I am just wondering is there an interface where I could do something
> > like:
> >
> > ```
> > // vars is the field in pt_solution of type bitmap
> > EXECUT
>This is absolutely not enough information to guess at the
>issue ;)
That's fair, I was hoping some mad genius out there would confess to a
fubar_adjustment phase that was probably at fault. π
>I suggest you break at the return stmt of make_ssa_name_fn
>looking for t->base.u.version == 101 to see
On September 3, 2020 7:59:12 PM GMT+02:00, Gary Oblock
wrote:
>>This is absolutely not enough information to guess at the
>>issue ;)
>
>That's fair, I was hoping some mad genius out there would confess to a
>fubar_adjustment phase that was probably at fault. π
Ah, well. It's probably your own co
On Thu, 27 Aug 2020, Pip Cet via Gcc wrote:
> I may be missing an obvious workaround, but it seems we currently emit
> a #line directive when including lines from machine description files
> in C files, but never emit a second directive when switching back to
> the generated C file. This makes step
On Thu, 3 Sep 2020, Hans-Peter Nilsson wrote:
> IMHO stepping into the .md really isn't helpful. Even a pattern
> name in a comment in the generated code would be better.
...and JFTR, yes I noticed there is, or rather line indicator
for example /path/to/mmix.md:211 above gen_adddi3 in
insn-emit.c
Snapshot gcc-8-20200903 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20200903/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
I am working a instrumention tool, and need get the location info for a gimple
statement. I use the location structure to get the info, and it can work when i
use -O1. When I use -O2, sometimes the info seems to be lost and I get line num
is zero.Β anyone can tell me how to get the info?
Note, isn't a problem, rather, it's something that puzzles me.
On walking a function types argument types this way
for ( arg = TYPE_ARG_TYPES ( func_type);
arg != NULL;
arg = TREE_CHAIN ( arg))
{
.
.
}
I noticed an extra void argument that didn't exist
tagged
11 matches
Mail list logo
