Re: warn about deprecated access declarations
2011/12/13 Miles Bader :
> Jonathan Wakely writes:
> How about "...; suggest adding the using keyword"?
That sounds like the compiler is suggesting that the user suggests
doing that!
>>>
>>> It is similar to "suggest parentheses ...".
>>
>> Good point, that's not correct English either, but it would be consistent.
>>
>> ("Suggest X" is an imperative, telling the user to suggest X. The
>> intention is for the compiler to suggest it, not tell the user to
>> suggest it, so the correct grammar would be "GCC suggests X".)
>
> How about "; suggestion: use parentheses" or "; suggestion: add the
> `using' keyword" (using whatever convention for quoting code).
Sounds good. Since nobody has objected yet, I am going to prepare the
complete patch, to submit it probably at the end of the week.
--
Fabien
outgoing_args_size and pretend_args_size
Hi, I am finding slightly confusing the difference between outgoing_args_size and pretend_args_size. I think I understand pretend_args_size, at least on the specific case of my port. The first two words of arguments go into two register the remaining goes into the stack. However, if the first argument is one word of size and the second two words of size, the second argument is split between register and stack and pretend_args_size is 1. However, I am slightly unsure about outgoing_args_size. It mentions outgoing_args but I don't really know if it is what I think it is. If I write: void foo(int *x); is x considered an outgoing arg? Can someone try to explain the difference between these? Cheers, -- PMatos
Vectorizer question: DIV to RSHIFT conversion
Hi guys,
While looking at Spec2006/401.bzip2 I found such a loop:
for (i = 1; i <= alphaSize; i++) {
j = weight[i] >> 8;
j = 1 + (j / 2);
weight[i] = j << 8;
}
Which is not vectorizeble (using Intel's AVX2) because division by two
is not recognized as rshift:
5: ==> examining statement: D.3785_6 = j_5 / 2;
5: vect_is_simple_use: operand j_5
5: def_stmt: j_5 = D.3784_4 >> 8;
5: type of def: 3.
5: vect_is_simple_use: operand 2
5: op not supported by target.
5: not vectorized: relevant stmt not supported: D.3785_6 = j_5 / 2;
However, while expanding, it is successfully turned into shift:
(insn 42 41 43 6 (parallel [
(set (reg:SI 107)
(ashiftrt:SI (reg:SI 106)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 1.c:7 -1
(expr_list:REG_EQUAL (div:SI (reg:SI 103)
(const_int 2 [0x2]))
(nil)))
`Division by power of 2` conversion into shift seems to be beneficial at all.
My question is, what is in your opinion best way to do such a conversion?
Obvious solution will be to introduce dedicated pass which will
convert all such a cases.
We also may try to implement dedicated expand, but I have no idea, how
to specify in the name (if possible) that second operand is something
fixed.
Any help is appreciated.
Thanks, K
Re: Vectorizer question: DIV to RSHIFT conversion
On Tue, 13 Dec 2011, Kirill Yukhin wrote:
> Hi guys,
> While looking at Spec2006/401.bzip2 I found such a loop:
> for (i = 1; i <= alphaSize; i++) {
> j = weight[i] >> 8;
> j = 1 + (j / 2);
> weight[i] = j << 8;
> }
>
> Which is not vectorizeble (using Intel's AVX2) because division by two
> is not recognized as rshift:
> 5: ==> examining statement: D.3785_6 = j_5 / 2;
>
> 5: vect_is_simple_use: operand j_5
> 5: def_stmt: j_5 = D.3784_4 >> 8;
>
> 5: type of def: 3.
> 5: vect_is_simple_use: operand 2
> 5: op not supported by target.
> 5: not vectorized: relevant stmt not supported: D.3785_6 = j_5 / 2;
>
> However, while expanding, it is successfully turned into shift:
> (insn 42 41 43 6 (parallel [
> (set (reg:SI 107)
> (ashiftrt:SI (reg:SI 106)
> (const_int 1 [0x1])))
> (clobber (reg:CC 17 flags))
> ]) 1.c:7 -1
>(expr_list:REG_EQUAL (div:SI (reg:SI 103)
> (const_int 2 [0x2]))
> (nil)))
>
> `Division by power of 2` conversion into shift seems to be beneficial at all.
> My question is, what is in your opinion best way to do such a conversion?
> Obvious solution will be to introduce dedicated pass which will
> convert all such a cases.
> We also may try to implement dedicated expand, but I have no idea, how
> to specify in the name (if possible) that second operand is something
> fixed.
This sounds like a job for the pattern recognizer inside the vectorizer.
Richard.
Re: Vectorizer question: DIV to RSHIFT conversion
On Tue, Dec 13, 2011 at 02:07:11PM +0100, Richard Guenther wrote:
> > Hi guys,
> > While looking at Spec2006/401.bzip2 I found such a loop:
> > for (i = 1; i <= alphaSize; i++) {
> > j = weight[i] >> 8;
> > j = 1 + (j / 2);
> > weight[i] = j << 8;
> > }
It would be helpful to have a self-contained testcase, because we don't know
the types of the variables in question. Is j signed or unsigned?
Signed divide by 2 is unfortunately not equivalent to >> 1.
If j is signed int, on x86_64 we expand j / 2 as (j + (j >> 31)) >> 1.
Sure, the pattern recognizer could try that if vector division isn't
supported.
If j is unsigned int, then I'd expect it to be already canonicalized into >>
1 by the time we enter the vectorizer.
Jakub
Re: Vectorizer question: DIV to RSHIFT conversion
The full case attached.
Jakub, you are right, we have to convert signed ints into something a
bit more tricky.
BTW, here is output for that cases from Intel compiler:
vpxor %ymm1, %ymm1, %ymm1 #184.23
vmovdqu .L_2il0floatpacket.12(%rip), %ymm0#184.23
movslq%ecx, %rdi#182.7
# LOE rax rbx rdi edx ecx ymm0 ymm1
..B1.82:# Preds ..B1.82 ..B1.81
vmovdqu 2132(%rsp,%rax,4), %ymm3 #183.14
vmovdqu 2100(%rsp,%rax,4), %ymm2 #183.27
vpsrad$8, %ymm3, %ymm11 #183.27
vpsrad$8, %ymm2, %ymm5 #183.27
vpcmpgtd %ymm5, %ymm1, %ymm4 #184.23
vpcmpgtd %ymm11, %ymm1, %ymm10 #184.23
vpand %ymm0, %ymm4, %ymm6 #184.23
vpand %ymm0, %ymm10, %ymm12 #184.23
vpaddd%ymm6, %ymm5, %ymm7 #184.23
vpaddd%ymm12, %ymm11, %ymm13#184.23
vpsrad$1, %ymm7, %ymm8 #184.23
vpsrad$1, %ymm13, %ymm14#184.23
vpaddd%ymm0, %ymm8, %ymm9 #184.23
vpaddd%ymm0, %ymm14, %ymm15 #184.23
vpslld$8, %ymm9, %ymm2 #185.27
vpslld$8, %ymm15, %ymm3 #185.27
vmovdqu %ymm2, 2100(%rsp,%rax,4) #185.10
vmovdqu %ymm3, 2132(%rsp,%rax,4) #185.10
addq $16, %rax #182.7
cmpq %rdi, %rax#182.7
jb..B1.82 # Prob 99% #182.7
Thanks, K
On Tue, Dec 13, 2011 at 5:21 PM, Jakub Jelinek wrote:
> On Tue, Dec 13, 2011 at 02:07:11PM +0100, Richard Guenther wrote:
>> > Hi guys,
>> > While looking at Spec2006/401.bzip2 I found such a loop:
>> > for (i = 1; i <= alphaSize; i++) {
>> > j = weight[i] >> 8;
>> > j = 1 + (j / 2);
>> > weight[i] = j << 8;
>> > }
>
> It would be helpful to have a self-contained testcase, because we don't know
> the types of the variables in question. Is j signed or unsigned?
> Signed divide by 2 is unfortunately not equivalent to >> 1.
> If j is signed int, on x86_64 we expand j / 2 as (j + (j >> 31)) >> 1.
> Sure, the pattern recognizer could try that if vector division isn't
> supported.
> If j is unsigned int, then I'd expect it to be already canonicalized into >>
> 1 by the time we enter the vectorizer.
>
> Jakub
int weight [ 258 * 2 ];
void foo(int alphaSize) {
int j, i;
for (i = 1; i <= alphaSize; i++) {
j = weight[i] >> 8;
j = 1 + (j / 2);
weight[i] = j << 8;
}
}
Re: Vectorizer question: DIV to RSHIFT conversion
On Tue, Dec 13, 2011 at 05:42:16PM +0400, Kirill Yukhin wrote: > The full case attached. > > Jakub, you are right, we have to convert signed ints into something a > bit more tricky. > BTW, here is output for that cases from Intel compiler: Ah, so that matches to do j / 2 in the pattern recognizer as (j + (j < 0 ? 1 : 0)) >> 1 instead of (j + (j >> 31)) >> 1. What is faster remains to be measured. Let me hack up a quick pattern recognizer for this... Jakub
Re: Vectorizer question: DIV to RSHIFT conversion
Great! Thanks, K > > Let me hack up a quick pattern recognizer for this... > > Jakub
Re: outgoing_args_size and pretend_args_size
"Paulo J. Matos" writes:
> I am finding slightly confusing the difference between
> outgoing_args_size and pretend_args_size.
>
> I think I understand pretend_args_size, at least on the specific case
> of my port. The first two words of arguments go into two register the
> remaining goes into the stack. However, if the first argument is one
> word of size and the second two words of size, the second argument is
> split between register and stack and pretend_args_size is 1.
>
> However, I am slightly unsure about outgoing_args_size. It mentions
> outgoing_args but I don't really know if it is what I think it is.
>
> If I write:
> void foo(int *x);
>
> is x considered an outgoing arg?
>
> Can someone try to explain the difference between these?
outgoing_args_size is the number of bytes required by called functions.
In your question above, the answer is no; x is an incoming argument. If
you write
extern foo(int);
void bar(void) { foo (1); }
then the outgoing_args_size of bar is sizeof(int), because that is the
maximum size of the the arguments passed in a function call.
As you can see outgoing_args_size has nothing to do with
pretend_args_size.
outgoing_args_size matters mainly if ACCUMULATE_OUTGOING_ARGS is
nonzero.
Ian
Re: outgoing_args_size and pretend_args_size
On 13/12/11 14:47, Ian Lance Taylor wrote:
outgoing_args_size is the number of bytes required by called functions.
In your question above, the answer is no; x is an incoming argument. If
you write
extern foo(int);
void bar(void) { foo (1); }
then the outgoing_args_size of bar is sizeof(int), because that is the
maximum size of the the arguments passed in a function call.
Perfect explanation, thanks.
--
PMatos
expanded go support?
Are there plans to expand the number of targets for go in gcc 4.7? In particular, PR46986 has had a proposed set of changes... http://gcc.gnu.org/bugzilla/attachment.cgi?id=25196&action=diff which should provide a starting point to identify the changes required for go support on darwin. Jack
GCC 4.7 Status Report for *-rtems
Hi, From an RTEMS perspective, the head has multiple regressions from the 4.6 branch. avr, bfin, lm32 and m68k have regressions such that they are incapable of compiling a complete tool chain. This means they fail to compile gcc, newlib, or RTEMS. These are the PRs for those regressions. avr - REGRESSION - ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925 bfin - REGRESSION - ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51003 lm32 - REGRESSION - ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50927 m68k - REGRESSION - Invalid code - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51532 Had an ICE and now has assembly that is invalid for CPU32 before it gets that far. I know these are not primary GCC targets but at this point 25% of the RTEMS targets don't build. Beyond that, Go is our biggest known issue. In spite of compiling on 4.6 and testing well, Go does not compile for RTEMS. A first patch was posted but there has been no response: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00201.html If a target can build enough to run C/C++ tests, we have run them and posted test results. After initial compilation problems, Ada and FORTRAN build on at least one RTEMS target and have reasonable test results posted. We have not gotten to GCJ testing yet. Objective-C compiles but has poor test results until RTEMS has a few more thread support routines implemented in libgcc. This would make a nice small project for someone. I hope the communities will pitch in to help get these resolved. Thanks. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: expanded go support?
On 12/13/2011 01:35 PM, Jack Howarth wrote: Are there plans to expand the number of targets for go in gcc 4.7? In particular, PR46986 has had a proposed set of changes... http://gcc.gnu.org/bugzilla/attachment.cgi?id=25196&action=diff which should provide a starting point to identify the changes required for go support on darwin. Jack FWIW Go tested well on RTEMS for 4.6 but doesn't compile right now. I have filed an initial patch but got no response. http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00201.html There is one other code issue that requires a solution and we should be able to provide test results. Help would be appreciated. It isn't very far off. Thanks. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: expanded go support?
Jack Howarth writes: >Are there plans to expand the number of targets for go in gcc 4.7? I would like to but I am also really swamped. I'm knocking down issues as fast as I can. My primary goal for gcc 4.7 is to include complete support for the upcoming Go 1 standard release on GNU/Linux. The absolute best way to contribute changes for gccgo is to follow the procedure outlined at http://golang.org/doc/gccgo_contribute.html which refers to http://golang.org/doc/contribute.html It is much easier for me to review and handle patches sent in using that process than any other way. However, I understand that that is quite different from the usual gcc process, so it's not required. Ian
Re: expanded go support?
On 12/13/2011 2:16 PM, Ian Lance Taylor wrote: Jack Howarth writes: Are there plans to expand the number of targets for go in gcc 4.7? I would like to but I am also really swamped. I'm knocking down issues as fast as I can. My primary goal for gcc 4.7 is to include complete support for the upcoming Go 1 standard release on GNU/Linux. The absolute best way to contribute changes for gccgo is to follow the procedure outlined at http://golang.org/doc/gccgo_contribute.html which refers to http://golang.org/doc/contribute.html It is much easier for me to review and handle patches sent in using that process than any other way. I am OK doing that for the patch I have but the other issue I don't know how to solve. Where should that discussion occur? However, I understand that that is quite different from the usual gcc process, so it's not required. I can deal with another process. I just want to kill problems right now. :) --joel Ian
Re: expanded go support?
Joel Sherrill writes: > Where should that discussion occur? Here and/or gofrontend-...@googlegroups.com. Sorry I have not replied to your earlier message, I will do so now. Ian
gcc-4.4-20111213 is now available
Snapshot gcc-4.4-20111213 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20111213/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 182314 You'll find: gcc-4.4-20111213.tar.bz2 Complete GCC MD5=1dfcdfe8e215117e4ef60e7905e0 SHA1=8d1d32ef18f7489ebe273b08bffa1f3c6f6410dd Diffs from 4.4-20111206 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
add link
I'm interested in your site. I just added your link http://gcc.gnu.org in my website: http://hotelfrance24.com/Rome-site-list50/ Please add my link: Title: Clock widget URL: http://time-24.org/en/widgets/ html code: http://time-24.org/en/widgets/";>Clock widget Best regards.
a new write after approval maintainer
Hi, I'll sponsor Oleg Endo as a new write after approval maintainer. He has written several good patches for SH targets and has filed good PRs. He is working on the issues which will require larger patches and being write after approval looks to be helpful. His paper work with FSF has done. OK? Regards, kaz
Re: GCC 4.7 Status Report for *-rtems
2011/12/13 Joel Sherrill : > Hi, > > From an RTEMS perspective, the head has multiple regressions from the 4.6 > branch. avr, bfin, lm32 and m68k have regressions such that they are > incapable of compiling a complete tool chain. This means they fail to > compile gcc, newlib, or RTEMS. These are the PRs for those regressions. > > avr - REGRESSION - ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925 This is a general regression (not RTEMS related). I have analyzed this PR. Look at bug report. I think that it's a GCC core bug. (reload bug) May be relod maintainers can look at this PR ? (Ulrich Weigand, Bernd Schmidt) Denis.
