Re: ACM SIGPLAN Programming Languages Software Award
On Wed, Jun 11, 2014 at 2:18 PM, David Edelsohn wrote: > It gives me great pleasure to announce that GCC has won the > > ACM SIGPLAN Programming Languages Software Award > > Congratulations to the entire GCC Community! That's great! The gcc.gnu.org page has a news item but it doesn't contain a link to more information? Richard. > - David
Re: ACM SIGPLAN Programming Languages Software Award
On Thu, Jun 12, 2014 at 10:16:19AM +0200, Richard Biener wrote: > On Wed, Jun 11, 2014@2:18 PM, David Edelsohn wrote: > > It gives me great pleasure to announce that GCC has won the > > > > ACM SIGPLAN Programming Languages Software Award > > > > Congratulations to the entire GCC Community! > > That's great! Congrats everybody! > The gcc.gnu.org page has a news item but it doesn't contain a link > to more information? This looks like the official page: http://www.sigplan.org/node/231 On irc someone posted this picture of the award: https://pbs.twimg.com/media/Bp1zl2qCEAAfNPY.jpg:large Do all GCC contributors get to share all that whisky? :) Cheers, Mark
C++ interop issue due to non-null pointers
In GCC 4.9, we have optimizations that make use of non-null annotations,
at least for removing null pointer checks. Some libc functions are
annotated with it, such as qsort, memcpy, memset, memcmp.
On the other hand, it is unspecified if the data() member of std::vector
returns null pointer if empty() returns true.
As a result, code like this is invalid if the functions are ever called
with empty vectors:
void clear(std::vector &vec)
{
memset(vec.data(), '\0', vec.size());
}
int comparefn(void *, void *);
void sort(std::vector &vec)
{
qsort(vec.data(), vec.size(), sizeof(T), comparefn);
}
I think this is quite surprising. What can we do about it?
--
Florian Weimer / Red Hat Product Security Team
Re: C++ interop issue due to non-null pointers
On 12 June 2014 10:40, Florian Weimer wrote:
> In GCC 4.9, we have optimizations that make use of non-null annotations, at
> least for removing null pointer checks. Some libc functions are annotated
> with it, such as qsort, memcpy, memset, memcmp.
Yep, as described at https://gcc.gnu.org/gcc-4.9/porting_to.html
> On the other hand, it is unspecified if the data() member of std::vector
> returns null pointer if empty() returns true.
>
> As a result, code like this is invalid if the functions are ever called with
> empty vectors:
>
> void clear(std::vector &vec)
> {
> memset(vec.data(), '\0', vec.size());
> }
>
> int comparefn(void *, void *);
>
> void sort(std::vector &vec)
> {
> qsort(vec.data(), vec.size(), sizeof(T), comparefn);
> }
>
> I think this is quite surprising.
I don't see why it's much different to passing a pointer that might be
null. You need to check.
> What can we do about it?
How common is it to use std::vector with qsort, rather than
std::sort(vec.begin(), vec.end()), which does the right thing?
We could make vector::data() guarantee a non-null pointer with
_FORTIFY_SOURCE, but I'd rather not do so in "unfortified" code. Some
users would object to the extra check needed.
Re: [GSoC] decision tree first steps
On Wed, Jun 11, 2014 at 4:09 PM, Prathamesh Kulkarni
wrote:
> On 6/11/14, Richard Biener wrote:
>> On Wed, Jun 11, 2014 at 12:53 PM, Richard Biener
>> wrote:
>>> On Wed, Jun 11, 2014 at 10:51 AM, Richard Biener
>>> wrote:
On Tue, Jun 10, 2014 at 1:57 PM, Richard Biener
wrote:
[...snip...]
> But then why not generate
>
> if (!captures[0]
> || captures[0] == op0)
> {
> captures[0] = op0;
> // simplification code S1
> return true;
> }
>
> and go without label and goto? Or did I miss something?
>
>> c) Shared captures between all patterns:
>> In the patch all patterns share the capture array tree captures[4] =
>> {}
>> (since all match patterns get interleaved in generated code off
>> decision tree).
>> This requires extra code to be generated to make sure captures are
>> correctly restored for another pattern.
Btw, I see that you back-track the decision tree. That is, for
root
|--operand: MINUS_EXPR
|operand: PLUS_EXPR
|--operand: @0
|operand: @1
|--operand: @0
|simplify
|--operand: @1
|simplify
you do
if (code == MINUS_EXPR)
{
tree captures[4] = {};
if (TREE_CODE (op0) == SSA_NAME)
{
gimple def_stmt = SSA_NAME_DEF_STMT (op0);
if (is_gimple_assign (def_stmt) && gimple_assign_rhs_code
(def_stmt) == PLUS_EXPR)
{
tree op01 = gimple_assign_rhs1 (def_stmt);
if (valueize && TREE_CODE (op01) == SSA_NAME)
op01 = valueize (op01);
else
goto L0;
if (op01)
{
L0:
tree op11 = gimple_assign_rhs2 (def_stmt);
if (valueize && TREE_CODE (op11) == SSA_NAME)
op11 = valueize (op11);
else
goto L1;
if (op11)
{
L1:
tree captures_0 = captures[0];
if (!captures[0])
{
captures[0] = op01;
goto L2;
}
else if (captures[0] == op01)
{
L2:
tree captures_1 = captures[1];
if (!captures[1])
{
captures[1] = op11;
goto L3;
}
else if (captures[1] == op11)
{
L3:
tree captures_2 = captures[0];
if (!captures[0])
{
captures[0] = op1;
goto L4;
}
else if (captures[0] == op1)
{
L4:
res_ops[0] = captures[1];
*res_code = TREE_CODE (res_ops[0]);
return true;
}
captures [0] = captures_2;
tree captures_3 = captures[1];
if (!captures[1])
{
captures[1] = op1;
goto L5;
}
else if (captures[1] == op1)
{
L5:
res_ops[0] = captures[0];
*res_code = TREE_CODE (res_ops[0]);
return true;
}
captures [1] = captures_3;
}
captures [1] = captures_1;
}
captures [0] = captures_0;
}
}
}
}
but if you processed all children of a decision tree node and didn't
hit one of the simplifies (which return true) then you know nothing
else will match and you can just return false. That early out seems
to be missing completely and we fall through processing all siblings
of the parents.
But maybe I am missing something? I see that if I make captur
Help understand the may_be_zero field in loop niter information
Hi, I noticed there is below code/comments about may_be_zero field in loop niter desc: tree may_be_zero;/* The boolean expression. If it evaluates to true, the loop will exit in the first iteration (i.e. its latch will not be executed), even if the niter field says otherwise. */ I had difficulty in understanding this because I ran into some cases in which it didn't behave as said. Example1, the dump of loop before sccp is like: : bnd_4 = len_3(D) + 1; : # ivtmp_1 = PHI <0(2), ivtmp_11(4)> _6 = ivtmp_1 + len_3(D); _7 = a[ivtmp_1]; _8 = b[ivtmp_1]; _9 = _7 + _8; a[_6] = _9; ivtmp_11 = ivtmp_1 + 1; if (bnd_4 > ivtmp_11) goto ; else goto ; : goto ; The loop niter information analyzed in sccp is like: Analyzing # of iterations of loop 1 exit condition [1, + , 1] < len_3(D) + 1 bounds on difference of bases: -1 ... 4294967294 result: zero if len_3(D) == 4294967295 # of iterations len_3(D), bounded by 4294967294 Qeustion1, shouldn't it be like "len_3 +1 <= 1" because the latch won't be executed when "len_3 == 0", right? It seems that GCC deliberately skips boundary case. It's ok in this case we can still get zero from niter info "bnd_4 - ivtmp_11" when "bnd_4 == 1" (i,e. len_3 == 0) But when boundary condition is the only case that latch get ZERO executed, the may_be_zero info will not be computed. See example2, with dump of loop before sccp like: foo (int M) : if (M_4(D) > 0) goto ; else goto ; : return; : : # i_13 = PHI <0(4), i_10(6)> _5 = i_13 + M_4(D); _6 = a[i_13]; _7 = b[i_13]; _8 = _6 + _7; a[_5] = _8; i_10 = i_13 + 1; if (M_4(D) > i_10) goto ; else goto ; : goto ; The niter information analyzed in sccp is like: Analyzing # of iterations of loop 1 exit condition [1, + , 1](no_overflow) < M_4(D) bounds on difference of bases: 0 ... 2147483646 result: # of iterations (unsigned int) M_4(D) + 4294967295, bounded by 2147483646 So may_be_zero is always false here, but the latch may be ZERO executed when "M_4 == 1". Start from Example1, we can create Example3 which makes no sense to me. Again, the dump of loop is like: : bnd_4 = len_3(D) + 1; : # ivtmp_1 = PHI <0(2), ivtmp_11(4)> _6 = ivtmp_1 + len_3(D); _7 = a[ivtmp_1]; _8 = b[ivtmp_1]; _9 = _7 + _8; a[_6] = _9; ivtmp_11 = ivtmp_1 + 4; if (bnd_4 > ivtmp_11) goto ; else goto ; : goto ; : return 0; The niter info is like: Analyzing # of iterations of loop 1 exit condition [4, + , 4] < len_3(D) + 1 bounds on difference of bases: -4 ... 4294967291 result: under assumptions len_3(D) + 1 <= 4294967292 zero if len_3(D) == 4294967295 # of iterations len_3(D) / 4, bounded by 1073741823 The problem is: won't latch be ZERO executed when "len_3 == 0/1/2/3"? With these examples, my first feeling is that may_be_zero is computed wrongly, but searching code shows that may_be_zero is mostly used by ivopt. Considering ivopt works well with it now, I am wondering if it's designed behavior? Anyone help? Thanks very much. Thanks, bin -- Best Regards.
Re: Help understand the may_be_zero field in loop niter information
On Thu, Jun 12, 2014 at 1:41 PM, Bin.Cheng wrote: > Hi, > I noticed there is below code/comments about may_be_zero field in loop > niter desc: > > tree may_be_zero;/* The boolean expression. If it evaluates to true, >the loop will exit in the first iteration (i.e. >its latch will not be executed), even if the niter >field says otherwise. */ > > I had difficulty in understanding this because I ran into some cases > in which it didn't behave as said. > > Example1, the dump of loop before sccp is like: > > : > bnd_4 = len_3(D) + 1; > > : > # ivtmp_1 = PHI <0(2), ivtmp_11(4)> > _6 = ivtmp_1 + len_3(D); > _7 = a[ivtmp_1]; > _8 = b[ivtmp_1]; > _9 = _7 + _8; > a[_6] = _9; > ivtmp_11 = ivtmp_1 + 1; > if (bnd_4 > ivtmp_11) > goto ; > else > goto ; > > : > goto ; > > The loop niter information analyzed in sccp is like: > > Analyzing # of iterations of loop 1 > exit condition [1, + , 1] < len_3(D) + 1 > bounds on difference of bases: -1 ... 4294967294 > result: > zero if len_3(D) == 4294967295 > # of iterations len_3(D), bounded by 4294967294 > > Qeustion1, shouldn't it be like "len_3 +1 <= 1" because the latch > won't be executed when "len_3 == 0", right? > > It seems that GCC deliberately skips boundary case. It's ok in this > case we can still get zero from niter info "bnd_4 - ivtmp_11" when > "bnd_4 == 1" (i,e. len_3 == 0) > > But when boundary condition is the only case that latch get ZERO > executed, the may_be_zero info will not be computed. See example2, > with dump of loop before sccp like: > > foo (int M) > > : > if (M_4(D) > 0) > goto ; > else > goto ; > > : > return; > > : > > : > # i_13 = PHI <0(4), i_10(6)> > _5 = i_13 + M_4(D); > _6 = a[i_13]; > _7 = b[i_13]; > _8 = _6 + _7; > a[_5] = _8; > i_10 = i_13 + 1; > if (M_4(D) > i_10) > goto ; > else > goto ; > > : > goto ; > > The niter information analyzed in sccp is like: > > Analyzing # of iterations of loop 1 > exit condition [1, + , 1](no_overflow) < M_4(D) > bounds on difference of bases: 0 ... 2147483646 > result: > # of iterations (unsigned int) M_4(D) + 4294967295, bounded by 2147483646 > > So may_be_zero is always false here, but the latch may be ZERO > executed when "M_4 == 1". > > Start from Example1, we can create Example3 which makes no sense to > me. Again, the dump of loop is like: > > : > bnd_4 = len_3(D) + 1; > > : > # ivtmp_1 = PHI <0(2), ivtmp_11(4)> > _6 = ivtmp_1 + len_3(D); > _7 = a[ivtmp_1]; > _8 = b[ivtmp_1]; > _9 = _7 + _8; > a[_6] = _9; > ivtmp_11 = ivtmp_1 + 4; > if (bnd_4 > ivtmp_11) > goto ; > else > goto ; > > : > goto ; > > : > return 0; > > The niter info is like: > > Analyzing # of iterations of loop 1 > exit condition [4, + , 4] < len_3(D) + 1 > bounds on difference of bases: -4 ... 4294967291 > result: > under assumptions len_3(D) + 1 <= 4294967292 > zero if len_3(D) == 4294967295 > # of iterations len_3(D) / 4, bounded by 1073741823 > > The problem is: won't latch be ZERO executed when "len_3 == 0/1/2/3"? > > With these examples, my first feeling is that may_be_zero is computed > wrongly, but searching code shows that may_be_zero is mostly used by > ivopt. Considering ivopt works well with it now, I am wondering if > it's designed behavior? > > Anyone help? Thanks very much. IMHO may_be_zero should be fully correct, not only for the cases IVOPTs cares. Optimizations needing the value of niters may choose to apply loop-versioning for the may_be_zero condition and doing that should result in a valid niter value. I think Zdenek may help here (but IIRC you already had a (partial?) patch to fix this?) Thanks, Richard. > Thanks, > bin > -- > Best Regards.
Re: Help understand the may_be_zero field in loop niter information
Hi, > > I noticed there is below code/comments about may_be_zero field in loop > > niter desc: > > > > tree may_be_zero;/* The boolean expression. If it evaluates to true, > >the loop will exit in the first iteration (i.e. > >its latch will not be executed), even if the niter > >field says otherwise. */ > > > > I had difficulty in understanding this because I ran into some cases > > in which it didn't behave as said. actually, in all the examples below, the field behaves as described, i.e., the number of iterations = may_be_zero ? 0 : niter; In particular, the fact that may_be_zero is false *does not imply* that the number of iterations as described by niter is non-zero. > > Example1, the dump of loop before sccp is like: > > > > : > > bnd_4 = len_3(D) + 1; > > > > : > > # ivtmp_1 = PHI <0(2), ivtmp_11(4)> > > _6 = ivtmp_1 + len_3(D); > > _7 = a[ivtmp_1]; > > _8 = b[ivtmp_1]; > > _9 = _7 + _8; > > a[_6] = _9; > > ivtmp_11 = ivtmp_1 + 1; > > if (bnd_4 > ivtmp_11) > > goto ; > > else > > goto ; > > > > : > > goto ; > > > > The loop niter information analyzed in sccp is like: > > > > Analyzing # of iterations of loop 1 > > exit condition [1, + , 1] < len_3(D) + 1 > > bounds on difference of bases: -1 ... 4294967294 > > result: > > zero if len_3(D) == 4294967295 > > # of iterations len_3(D), bounded by 4294967294 > > > > Qeustion1, shouldn't it be like "len_3 +1 <= 1" because the latch > > won't be executed when "len_3 == 0", right? the analysis determines the number of iterations as len_3, that is 0 if len_3 == 0. So, the information is computed correctly here. > > But when boundary condition is the only case that latch get ZERO > > executed, the may_be_zero info will not be computed. See example2, > > with dump of loop before sccp like: > > > > foo (int M) > > > > : > > if (M_4(D) > 0) > > goto ; > > else > > goto ; > > > > : > > return; > > > > : > > > > : > > # i_13 = PHI <0(4), i_10(6)> > > _5 = i_13 + M_4(D); > > _6 = a[i_13]; > > _7 = b[i_13]; > > _8 = _6 + _7; > > a[_5] = _8; > > i_10 = i_13 + 1; > > if (M_4(D) > i_10) > > goto ; > > else > > goto ; > > > > : > > goto ; > > > > The niter information analyzed in sccp is like: > > > > Analyzing # of iterations of loop 1 > > exit condition [1, + , 1](no_overflow) < M_4(D) > > bounds on difference of bases: 0 ... 2147483646 > > result: > > # of iterations (unsigned int) M_4(D) + 4294967295, bounded by > > 2147483646 > > > > So may_be_zero is always false here, but the latch may be ZERO > > executed when "M_4 == 1". Again, this is correct, since then ((unsigned int) M_4) + 4294967295 == 0. > > Start from Example1, we can create Example3 which makes no sense to > > me. Again, the dump of loop is like: > > > > : > > bnd_4 = len_3(D) + 1; > > > > : > > # ivtmp_1 = PHI <0(2), ivtmp_11(4)> > > _6 = ivtmp_1 + len_3(D); > > _7 = a[ivtmp_1]; > > _8 = b[ivtmp_1]; > > _9 = _7 + _8; > > a[_6] = _9; > > ivtmp_11 = ivtmp_1 + 4; > > if (bnd_4 > ivtmp_11) > > goto ; > > else > > goto ; > > > > : > > goto ; > > > > : > > return 0; > > > > The niter info is like: > > > > Analyzing # of iterations of loop 1 > > exit condition [4, + , 4] < len_3(D) + 1 > > bounds on difference of bases: -4 ... 4294967291 > > result: > > under assumptions len_3(D) + 1 <= 4294967292 > > zero if len_3(D) == 4294967295 > > # of iterations len_3(D) / 4, bounded by 1073741823 > > > > The problem is: won't latch be ZERO executed when "len_3 == 0/1/2/3"? Again, in all these cases the number of iterations is len_3 / 4 == 0. Zdenek
GCC 4.7 branch is now closed
The GCC 4.7 branch is now closed, please refrain from committing anything there now. Richard.
Attributes for var_decl and fun_decl.
Dear All, We ported gcc 4.8.1 for custom hardware and we have target specific attributes like io for variables and interrupt for functuions and many more. We are able to fetch the attributes for variables like look_up(DECL_ATTRIBUTES(node),attr_name) for typedef variables we are fetching attributes like look_up(TYPE_ATTRIBUTES(node),attr_name) which is not working as expected and group any hints on the same ?? Second,We are able to fetch the attributes for functions like look_up(DECL_ATTRIBUTES(fndecl),attr_name) or look_up(TYPE_ATTRIBUTES(fntype),attr_name) for function pointer to the above attributed functions is not working as expected like int __attribute((cdecl)) test(void); int (*ptr) (void); ptr = &test; We are looking on the exist ports ,meanwhile any lights from experts on the same is appreciated . Thank you ~Umesh
Re: ACM SIGPLAN Programming Languages Software Award
On 06/12/14 02:16, Richard Biener wrote: On Wed, Jun 11, 2014 at 2:18 PM, David Edelsohn wrote: It gives me great pleasure to announce that GCC has won the ACM SIGPLAN Programming Languages Software Award Congratulations to the entire GCC Community! That's great! Most definitely. Sadly, we weren't able to tell the larger development community about the award until it was made public. I would have really liked to have had many of the major contributors to GCC be there for the announcement. Jeff
gcc-4.8-20140612 is now available
Snapshot gcc-4.8-20140612 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140612/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 211600 You'll find: gcc-4.8-20140612.tar.bz2 Complete GCC MD5=ac75bb0d20febf9a2489492cd70b897a SHA1=d76fd391fad8e26f9b09cee171a100517d4e852e Diffs from 4.8-20140605 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
