Removing "Severity" from New Bug form
I would really like to see the Severity field removed from the bug entry form. A few people use it correctly to mark their bugs as enhancements or trivial, but most users just set it to "blocker" because they think it means "how important is this to you?". Obviously everyone's bug is important to them, but that doesn't make it a GCC release blocker. If we have to keep it could we put a label next to it explaining what it's for, and requesting users to engage brain before choosing "critical" or "blocker" ?
Re: Removing "Severity" from New Bug form
On Tue, Dec 8, 2015 at 1:04 PM, Jonathan Wakely wrote: > I would really like to see the Severity field removed from the bug > entry form. A few people use it correctly to mark their bugs as > enhancements or trivial, but most users just set it to "blocker" > because they think it means "how important is this to you?". Obviously > everyone's bug is important to them, but that doesn't make it a GCC > release blocker. > > If we have to keep it could we put a label next to it explaining what > it's for, and requesting users to engage brain before choosing > "critical" or "blocker" ? Dropping it is ok I think. I'd rather have known-to-work exposed for people filing regressions. In reality we don't use severity at all - exposing important keywords like 'wrong-code' and 'rejects-valid' would be much more useful. People also get Component wrong but it would be inconvenient to have it dropped. Maybe have an advanced bug reporting form and a simple one? Richard.
Re: Removing "Severity" from New Bug form
On 8 December 2015 at 12:42, Richard Biener wrote: > On Tue, Dec 8, 2015 at 1:04 PM, Jonathan Wakely wrote: >> I would really like to see the Severity field removed from the bug >> entry form. A few people use it correctly to mark their bugs as >> enhancements or trivial, but most users just set it to "blocker" >> because they think it means "how important is this to you?". Obviously >> everyone's bug is important to them, but that doesn't make it a GCC >> release blocker. >> >> If we have to keep it could we put a label next to it explaining what >> it's for, and requesting users to engage brain before choosing >> "critical" or "blocker" ? > > Dropping it is ok I think. Yes, even for the valid "enhancement" cases a maintainer who triages the report could set that easily enough. Or we could just change it to choosing between two simple options: bug/enhancement. > I'd rather have known-to-work exposed > for people filing regressions. Agreed. > In reality we don't use severity at all - exposing important keywords > like 'wrong-code' and 'rejects-valid' would be much more useful. Yes, maybe checkboxes for them (which would add the relevant item to the keywords field) would be nice. > People also get Component wrong but it would be inconvenient > to have it dropped. Maybe have an advanced bug reporting form > and a simple one? We already have a "Hide advanced fields" toggle, maybe we should just flip the default setting for that.
Re: Removing "Severity" from New Bug form
On 8 December 2015 at 13:16, Jonathan Wakely wrote: > On 8 December 2015 at 12:42, Richard Biener > wrote: >> People also get Component wrong but it would be inconvenient >> to have it dropped. Maybe have an advanced bug reporting form >> and a simple one? > > We already have a "Hide advanced fields" toggle, maybe we should just > flip the default setting for that. Although we still show Severity even when advanced fields are hidden :-\
Re: Identifying a pointer to a structure
Richard Biener wrote on 12/03/2015 03:32 PM:
On Thu, Dec 3, 2015 at 8:54 AM, Uday P. Khedker wrote:
We are implementing points-to analysis in GCC 4.7.2 and need to distinguish
between
pointers to scalars and the pointers to structures. This distinction by
using the TYPE (TREE_TYPE)
hierarchy of the tree node of the pointer. We have two questions:
(a) Is it sufficient to check for the presence of RECORD_TYPE in type
hierarchy?
(b) Is it safe to assume that the RECORD_TYPE always appears as a leaf node
in
the type description of any pointer to structure?
As an example, the tree nodes of a pointer to an integer (y) and a pointer
to a structure (f)
below. It seems to support our hunch.
Yes, your observations are correct with respect to types.
But you can't rely on the pointer type for determining what kind of
object apointer points to.
First because of int *p = &s.i; with struct { int i; ... } s; points
to an int but it also points
to the start of an aggregate (and so can be trivially casted to a
pointer to s). Second because
GCCs middle-end (thus GIMPLE) ignores pointer types completely so you can have
an SSA name a_1 of type int *X and a dereference a_1->b.c (thus a_1 points to a
structure object even though it is of type int *).
Thanks for this word of caution :)
We understand your example (where SSA variable a_1 is of type int * and it is
dereferenced as a_1->b.c) with the following explanation: Since GIMPLE based
transformations ignore the type information completely, it could differ flow
sensitively for variables and is left implicit. In other words, the type of a
variable in an expression could differ from its type available in VAR_DECL. For the
above example, the type of a_1 in VAR_DECL is int * whereas it is actually used as a
pointer to a struct in the expression a_1->b.c because of some code
transformations.
Fortunately, we do not need the flow sensitive type of a variable in every
expression.
Our basic need is much simpler: We would like to know if a pointer is used for
iteratively accessing a recursive data structure (such as a list), in a loop
or recursive invocation as illustrated below. Due to some transformations, can
a pointer to int show up for such accesses in GIMPLE or would it always have
RECORD_TYPE in its type expression for such limited situations?
while (...)
{
x = x->f;
...
}
At the source level, x is guaranteed to be a pointer to a struct. Our question
is: Does this guarantee hold in GIMPLE in the limited situations of such
iterative accesses to a recursive data structure?
In particular, if this guarantee does not hold for a sequential access pattern
such as below, it is a non-issue for us.
x = x->f;
x = x->f;
x = x->f;
What gives us a ray of hope is our hunch that the code transformations for
iterative accesses are far more limited than they are for sequential accesses.
Thanks and regards,
Uday.
Re: Removing "Severity" from New Bug form
Jonathan Wakely writes: > We already have a "Hide advanced fields" toggle, maybe we should just > flip the default setting for that. They are already hidden by default (the last choice is remembered in a cookie). Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Identifying a pointer to a structure
On Tue, Dec 8, 2015 at 3:35 PM, Richard Biener
wrote:
> On Tue, Dec 8, 2015 at 3:22 PM, Uday P. Khedker wrote:
>>
>>
>> Richard Biener wrote on 12/03/2015 03:32 PM:
>>>
>>> On Thu, Dec 3, 2015 at 8:54 AM, Uday P. Khedker
>>> wrote:
We are implementing points-to analysis in GCC 4.7.2 and need to
distinguish
between
pointers to scalars and the pointers to structures. This distinction by
using the TYPE (TREE_TYPE)
hierarchy of the tree node of the pointer. We have two questions:
(a) Is it sufficient to check for the presence of RECORD_TYPE in type
hierarchy?
(b) Is it safe to assume that the RECORD_TYPE always appears as a leaf
node
in
the type description of any pointer to structure?
As an example, the tree nodes of a pointer to an integer (y) and a
pointer
to a structure (f)
below. It seems to support our hunch.
>>>
>>> Yes, your observations are correct with respect to types.
>>>
>>> But you can't rely on the pointer type for determining what kind of
>>> object apointer points to.
>>> First because of int *p = &s.i; with struct { int i; ... } s; points
>>> to an int but it also points
>>> to the start of an aggregate (and so can be trivially casted to a
>>> pointer to s). Second because
>>> GCCs middle-end (thus GIMPLE) ignores pointer types completely so you can
>>> have
>>> an SSA name a_1 of type int *X and a dereference a_1->b.c (thus a_1 points
>>> to a
>>> structure object even though it is of type int *).
>>>
>>
>> Thanks for this word of caution :)
>>
>> We understand your example (where SSA variable a_1 is of type int * and it
>> is dereferenced as a_1->b.c) with the following explanation: Since GIMPLE
>> based transformations ignore the type information completely, it could
>> differ flow sensitively for variables and is left implicit. In other words,
>> the type of a variable in an expression could differ from its type available
>> in VAR_DECL. For the above example, the type of a_1 in VAR_DECL is int *
>> whereas it is actually used as a pointer to a struct in the expression
>> a_1->b.c because of some code transformations.
>>
>> Fortunately, we do not need the flow sensitive type of a variable in every
>> expression.
>>
>> Our basic need is much simpler: We would like to know if a pointer is used
>> for iteratively accessing a recursive data structure (such as a list), in a
>> loop or recursive invocation as illustrated below. Due to some
>> transformations, can a pointer to int show up for such accesses in GIMPLE or
>> would it always have RECORD_TYPE in its type expression for such limited
>> situations?
>>
>> while (...)
>> {
>> x = x->f;
>> ...
>> }
>>
>> At the source level, x is guaranteed to be a pointer to a struct. Our
>> question is: Does this guarantee hold in GIMPLE in the limited situations of
>> such iterative accesses to a recursive data structure?
>
> No, it doesn't.
>
>> In particular, if this guarantee does not hold for a sequential access
>> pattern such as below, it is a non-issue for us.
>>
>> x = x->f;
>> x = x->f;
>> x = x->f;
>
> struct X { struct X *f; };
> struct X *foo (void *p)
> {
> p = ((struct X *)p)->f;
> p = ((struct X *)p)->f;
> p = ((struct X *)p)->f;
> return p;
> }
>
> is represented as
>
> foo (void * p)
> {
> :
> p_3 = MEM[(struct X *)p_2(D)].f;
> p_4 = MEM[(struct X *)p_3].f;
> p_5 = MEM[(struct X *)p_4].f;
> return p_5;
> }
>
> all pointer types are void *. At accesses you have types of access of course,
> but the pointers themselves can have any pointer type (such as void * here
> or int * if you change the type of p).
Or
struct X { struct X *f; };
struct X *foo (void *p)
{
struct X **q = &((struct X *)p)->f;
p = *q;
q = &((struct X *)p)->f;
p = *q;
q = &((struct X *)p)->f;
p = *q;
return p;
}
foo (void * p)
{
struct X * * q;
:
p_4 = MEM[(struct X * *)p_1(D)];
p_6 = MEM[(struct X * *)p_4];
p_8 = MEM[(struct X * *)p_6];
return p_8;
}
or if you make q void ** then
foo (void * p)
{
void * * q;
:
p_4 = MEM[(void * *)p_1(D)];
p_6 = MEM[(void * *)p_4];
p_8 = MEM[(void * *)p_6];
return p_8;
}
Richard.
> Richard.
>
>> What gives us a ray of hope is our hunch that the code transformations for
>> iterative accesses are far more limited than they are for sequential
>> accesses.
>>
>> Thanks and regards,
>>
>> Uday.
>>
>>
>>
Re: Identifying a pointer to a structure
On Tue, Dec 8, 2015 at 3:22 PM, Uday P. Khedker wrote:
>
>
> Richard Biener wrote on 12/03/2015 03:32 PM:
>>
>> On Thu, Dec 3, 2015 at 8:54 AM, Uday P. Khedker
>> wrote:
>>>
>>> We are implementing points-to analysis in GCC 4.7.2 and need to
>>> distinguish
>>> between
>>> pointers to scalars and the pointers to structures. This distinction by
>>> using the TYPE (TREE_TYPE)
>>> hierarchy of the tree node of the pointer. We have two questions:
>>>
>>> (a) Is it sufficient to check for the presence of RECORD_TYPE in type
>>> hierarchy?
>>> (b) Is it safe to assume that the RECORD_TYPE always appears as a leaf
>>> node
>>> in
>>> the type description of any pointer to structure?
>>>
>>> As an example, the tree nodes of a pointer to an integer (y) and a
>>> pointer
>>> to a structure (f)
>>> below. It seems to support our hunch.
>>
>> Yes, your observations are correct with respect to types.
>>
>> But you can't rely on the pointer type for determining what kind of
>> object apointer points to.
>> First because of int *p = &s.i; with struct { int i; ... } s; points
>> to an int but it also points
>> to the start of an aggregate (and so can be trivially casted to a
>> pointer to s). Second because
>> GCCs middle-end (thus GIMPLE) ignores pointer types completely so you can
>> have
>> an SSA name a_1 of type int *X and a dereference a_1->b.c (thus a_1 points
>> to a
>> structure object even though it is of type int *).
>>
>
> Thanks for this word of caution :)
>
> We understand your example (where SSA variable a_1 is of type int * and it
> is dereferenced as a_1->b.c) with the following explanation: Since GIMPLE
> based transformations ignore the type information completely, it could
> differ flow sensitively for variables and is left implicit. In other words,
> the type of a variable in an expression could differ from its type available
> in VAR_DECL. For the above example, the type of a_1 in VAR_DECL is int *
> whereas it is actually used as a pointer to a struct in the expression
> a_1->b.c because of some code transformations.
>
> Fortunately, we do not need the flow sensitive type of a variable in every
> expression.
>
> Our basic need is much simpler: We would like to know if a pointer is used
> for iteratively accessing a recursive data structure (such as a list), in a
> loop or recursive invocation as illustrated below. Due to some
> transformations, can a pointer to int show up for such accesses in GIMPLE or
> would it always have RECORD_TYPE in its type expression for such limited
> situations?
>
> while (...)
> {
> x = x->f;
> ...
> }
>
> At the source level, x is guaranteed to be a pointer to a struct. Our
> question is: Does this guarantee hold in GIMPLE in the limited situations of
> such iterative accesses to a recursive data structure?
No, it doesn't.
> In particular, if this guarantee does not hold for a sequential access
> pattern such as below, it is a non-issue for us.
>
> x = x->f;
> x = x->f;
> x = x->f;
struct X { struct X *f; };
struct X *foo (void *p)
{
p = ((struct X *)p)->f;
p = ((struct X *)p)->f;
p = ((struct X *)p)->f;
return p;
}
is represented as
foo (void * p)
{
:
p_3 = MEM[(struct X *)p_2(D)].f;
p_4 = MEM[(struct X *)p_3].f;
p_5 = MEM[(struct X *)p_4].f;
return p_5;
}
all pointer types are void *. At accesses you have types of access of course,
but the pointers themselves can have any pointer type (such as void * here
or int * if you change the type of p).
Richard.
> What gives us a ray of hope is our hunch that the code transformations for
> iterative accesses are far more limited than they are for sequential
> accesses.
>
> Thanks and regards,
>
> Uday.
>
>
>
Re: Removing "Severity" from New Bug form
Le 08. 12. 15 14:16, Jonathan Wakely a écrit : >> Dropping it is ok I think. > > Yes, even for the valid "enhancement" cases a maintainer who triages > the report could set that easily enough. If maintainers still use the severity field to triage bugs, then it should not be dropped. It would be much easier to restrict the ability to edit the severity field to users with editbugs privs (basically users with a @gcc.gnu.org account + a few other accounts). Frédéric
Re: Removing "Severity" from New Bug form
On 12/8/2015 4:26 PM, Frédéric Buclin wrote: > Le 08. 12. 15 14:16, Jonathan Wakely a écrit : >>> Dropping it is ok I think. >> >> Yes, even for the valid "enhancement" cases a maintainer who triages >> the report could set that easily enough. > > If maintainers still use the severity field to triage bugs, then it > should not be dropped. It would be much easier to restrict the ability > to edit the severity field to users with editbugs privs (basically users > with a @gcc.gnu.org account + a few other accounts). > If the person submitting the PR gets to set the severity field, it should be dropped. If anybody sets the severity, it should be the people *doing* the triage or the person to whom the PR is eventually assigned. John
RE: GCC Front-End Questions
Good Afternoon,
My colleagues and I are doing a study on compilers. We have some questions
related to gcc and the compilation process that we were hoping you could help
us with.
In a general sense, we were wondering what optimizations may be occurring in
the front-end stages of the compiler? We are noticing some constant
substitution (e.g., 2*15+3 being changed to 33) and some algebraic
simplifications (more later) showing up in the first intermediate file
generated using dump flags with the g++ command. Are we correct in assuming
this first IR file is indeed coming from the front end (.original file)? In
looking at the gcc source code, we are having difficulty seeing where these
optimizations might be occurring in the initial parsing phase. Do you have any
insights you might be able to share?
One algebraic simplification we are seeing is particularly interesting. Given
the following code snippet intended to check for buffer overflow, which is
actually undefined behavior in C++, we expected to maybe see the if check
optimized away entirely.
char buffer[100];
int length; //value received through argument or command line
.
.
If (buffer + length < buffer)
{
cout << "Overflow" << endl;
}
Instead, our assembly code showed that the conditional was changed to length <
0, which is not what was intended at all. Again, this showed up in the first
IR file generated with g++ so we are thinking it happened in the compiler
front-end, which is surprising. Any thoughts on this? In addition, when the
above conditional expression is not used as part of an if check (e.g., assigned
to a Boolean), it is not simplified.
Computer/compiler info:
1. Compilation command: g++ -save-temps -fdump-rtl-all-all fdump-ipa-all-all
-fdump-tree-all-all
2. g++ version: g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2
3. target: i-686
4. uname -a : Linux OptiPlex-755 3.16.0-generic#40~14.04.1-Ubuntu SMP
We look forward to hearing from you.
Thank you in advance for your time and inputs,
Jodi
Jodi A. Miller
Senior Research Assistant
Applied Research Laboratory/Penn State
(814)863-4077
Re: GCC Front-End Questions
On 12/08/2015 12:32 PM, Jodi A. Miller wrote: Good Afternoon, My colleagues and I are doing a study on compilers. We have some questions related to gcc and the compilation process that we were hoping you could help us with. In a general sense, we were wondering what optimizations may be occurring in the front-end stages of the compiler? We are noticing some constant substitution (e.g., 2*15+3 being changed to 33) and some algebraic simplifications (more later) showing up in the first intermediate file generated using dump flags with the g++ command. Are we correct in assuming this first IR file is indeed coming from the front end (.original file)? In looking at the gcc source code, we are having difficulty seeing where these optimizations might be occurring in the initial parsing phase. Do you have any insights you might be able to share? Front-ends do a fair amount of folding, distribution & reassociation (see fold-const.c). We are currently working to delay folding until the optimization pipeline starts. Essentially the guiding principle of that work is that the initial gimple code ought to closely match the input source. The first batch of work to delay folding will show up in gcc-6 for the C++ front-end. jeff
RE: GCC Front-End Questions
On Tue, 8 Dec 2015, Jodi A. Miller wrote:
One algebraic simplification we are seeing is particularly interesting.
Given the following code snippet intended to check for buffer overflow,
which is actually undefined behavior in C++, we expected to maybe see
the if check optimized away entirely.
char buffer[100];
int length; //value received through argument or command line
.
.
If (buffer + length < buffer)
{
cout << "Overflow" << endl;
}
Instead, our assembly code showed that the conditional was changed to
length < 0, which is not what was intended at all. Again, this showed
up in the first IR file generated with g++ so we are thinking it
happened in the compiler front-end, which is surprising. Any thoughts
on this? In addition, when the above conditional expression is not used
as part of an if check (e.g., assigned to a Boolean), it is not
simplified.
Those optimizations during parsing exist mostly for historical reasons,
and we are slowly moving away from them. You can look for any function
call including "fold" in its name in the front-end. They work on
expressions and mostly consist of matching patterns (described in
fold-const.c and match.pd), like p + n < p in this case.
--
Marc Glisse
gcc-5-20151208 is now available
Snapshot gcc-5-20151208 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20151208/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 231430 You'll find: gcc-5-20151208.tar.bz2 Complete GCC MD5=d54e614d33434cfb9e0e5b144ca13460 SHA1=be8771bdf65f32ab2af3b58beca0bea02d6eb405 Diffs from 5-20151124 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
