Re: No pointer conversion warning for "bool" in C/C++
On 26 September 2011 05:29, Ian Lance Taylor wrote: > Jon Grant writes: > >> Currently gcc, and g++ don't give a warning when a pointer was >> converted to a bool, in the same way it is for other types. At least in C++, it's not really true to say "in the same way it is for other types" because you cannot convert from a pointer to any integer type except bool. Your test uses NULL for the other integer types, which is an integral constant expression with value zero, so it's ok to convert that to an integer type. That's not true for general pointer values: if your test used m_int(g_glob) then it wouldn't compile. > There is a lot of code which uses > if (p) > where p is a pointer to test whether p is not NULL. I don't think we > could reasonably have gcc warn about such a case. > > We might be able to separate out conversion to bool on assignment from > conversion to bool in a test, though. That would still break this: Base* p = getObj(); bool is_derived = dynamic_cast(p); What problem is the warning supposed to solve?
RE: A question about detecting array bounds for case Warray-bounds-3.c
PING...
> -Original Message-
> From: Jiangning Liu [mailto:jiangning@arm.com]
> Sent: Thursday, September 22, 2011 10:19 AM
> To: gcc@gcc.gnu.org
> Cc: 'ja...@gcc.gnu.org'; 'muel...@gcc.gnu.org'; 'rgue...@gcc.gnu.org';
> Matthew Gretton-Dann
> Subject: A question about detecting array bounds for case Warray-
> bounds-3.c
>
> Hi,
>
> For case gcc/testsuite/gcc.dg/Warray-bounds-3.c, obviously it is an
> invalid C program, because the last iterations of all the loops cause
> the access of arrays is beyond the max size of corresponding array
> declarations. The condition of checking upper bound should be "<"
> rather than "<=".
>
> Right now, GCC compiler doesn't report any warning messages for this
> case, should it be a bug in both test case and compiler?
>
> But looking at http://gcc.gnu.org/PR31227 , it seems this test case is
> designed to be like this on purpose. Anybody can explain about this?
>
> The case is like below,
>
> /* { dg-do compile } */
> /* { dg-options "-O2 -Warray-bounds" } */
> /* based on PR 31227 */
>
> struct S
> {
> const char *abday[7];
> const char *day[7];
> const char *abmon[12];
> const char *mon[12];
> const char *am_pm[2];
> };
>
> ...
>
> for (cnt = 0; cnt <= 7; ++cnt)
> {
> iov[2 + cnt].iov_base = (void *) (time->abday[cnt] ?: "");
> iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
> }
>
> for (; cnt <= 14; ++cnt)
> {
> iov[2 + cnt].iov_base = (void *) (time->day[cnt - 7] ?: "");
> iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
> }
>
> for (; cnt <= 26; ++cnt)
> {
> iov[2 + cnt].iov_base = (void *) (time->abmon[cnt - 14] ?: "");
> iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
> }
>
> for (; cnt <= 38; ++cnt)
> {
> iov[2 + cnt].iov_base = (void *) (time->mon[cnt - 26] ?: "");
> iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
> }
>
> for (; cnt <= 40; ++cnt)
> {
> iov[2 + cnt].iov_base = (void *) (time->am_pm[cnt - 38] ?: "");
> iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
> }
>
> Thanks,
> -Jiangning
RE: A case that PRE optimization hurts performance
> > * Without PRE, > > > > Path1: > > movl $2, %eax > > cmpl $1, %eax > > je .L3 > > > > Path2: > > movb $3, %al > > cmpl $1, %eax > > je .L3 > > > > Path3: > > cmpl $1, %eax > > jne .L14 > > > > * With PRE, > > > > Path1: > > movl $1, %ebx > > movl $2, %eax > > testb %bl, %bl > > je .L3 > > > > Path2: > > movl $1, %ebx > > movb $3, %al > > testb %bl, %bl > > je .L3 > > > > Path3: > > cmpl $1, %eax > > setne %bl > > testb %bl, %bl > > jne .L14 > > > > Do you have any more thoughts? > > It seems to me that with PRE all the testb %bl, %bl > should be evaluated at compile-time considering the > preceeding movl $1, %ebx. Am I missing something? > Yes. Can this be done by PRE or any other optimizations in middle end? Thanks, -Jiangning > Richard. >
Re: Volatile qualification on pointer and data
On 26/09/2011 02:37, Miles Bader wrote: David Brown writes: So what advantages would there be in declaring a volatile buffer like this to be "const"? At best, you are helping the compiler check that you don't accidentally write to it in your own code. That's actually pretty handy tho... Oh, I'm all in favour of static error checking - use const pointers where possible, and there are not many of gcc's warning flags that I don't use. But I'd weigh code clarity above error checking in this case, especially since it is very unlikely that you'd write code that accidentally wrote to the buffer.
Re: No pointer conversion warning for "bool" in C/C++
Hello Jonathan Wakely wrote, On 26/09/11 08:10: On 26 September 2011 05:29, Ian Lance Taylor wrote: Jon Grant writes: Currently gcc, and g++ don't give a warning when a pointer was converted to a bool, in the same way it is for other types. At least in C++, it's not really true to say "in the same way it is for other types" because you cannot convert from a pointer to any integer type except bool. Your test uses NULL for the other integer types, which is an integral constant expression with value zero, so it's ok to convert that to an integer type. That's not true for general pointer values: if your test used m_int(g_glob) then it wouldn't compile. Good point. My test should have used g_glob due to NULL being a macro of 0 in C++. There is a lot of code which uses if (p) where p is a pointer to test whether p is not NULL. I don't think we could reasonably have gcc warn about such a case. We might be able to separate out conversion to bool on assignment from conversion to bool in a test, though. That would still break this: Base* p = getObj(); bool is_derived = dynamic_cast(p); What problem is the warning supposed to solve? A programmer assigning a bool with a pointer, there's an implicit evaluation there isn't there? rather than: bool invalid = (NULL == p); I expect this depends on what the standard allows then. Regards, Jon
Re: cc1.exe: warnings being treated as errors
Hi Jonathan Jonathan Wakely wrote, On 24/09/11 15:55: On 24 September 2011 15:40, Jon Grant wrote: It's kind of re-iterating the command line options, that the user will choose to be aware of already. I don't recall seeing that text output before about ~1 year ago. It was there in GCC 4.1, maybe earlier, I didn't check. However, coming back to my query: Is there a need to remind the user that warnings on the build are being treated as errors? Is this a special case because it would cause the build to stop? For example: -Wall means I see "control reaches end of non-void function" messages, but doesn't output "cc1.exe: all warnings turned on" I'd thought because the previous line of output said "gcc -Werror -Wall -o main main.c", the options clear. Not if you run "make" and it doesn't echo the compiler command, or run the compiler from an IDE, or anything else which shows the errors but not the command. I would have though that it's not GCC's responsibility to echo the options passed to it. Like the IDE example, the IDE can inform the user of what compiler options are in use; I don't see why GCC can't keep quiet about -Werror. Best regards, Jon
Re: No pointer conversion warning for "bool" in C/C++
On 26 September 2011 09:32, Jon Grant wrote: > Hello > > Jonathan Wakely wrote, On 26/09/11 08:10: >> >> On 26 September 2011 05:29, Ian Lance Taylor wrote: >>> >>> Jon Grant writes: >>> Currently gcc, and g++ don't give a warning when a pointer was converted to a bool, in the same way it is for other types. >> >> At least in C++, it's not really true to say "in the same way it is >> for other types" because you cannot convert from a pointer to any >> integer type except bool. Your test uses NULL for the other integer >> types, which is an integral constant expression with value zero, so >> it's ok to convert that to an integer type. That's not true for >> general pointer values: if your test used m_int(g_glob) then it >> wouldn't compile. > > Good point. My test should have used g_glob due to NULL being a macro of 0 > in C++. That wouldn't compile. A pointer to boolean conversion is safe and well-defined. >>> There is a lot of code which uses >>> if (p) >>> where p is a pointer to test whether p is not NULL. I don't think we >>> could reasonably have gcc warn about such a case. >>> >>> We might be able to separate out conversion to bool on assignment from >>> conversion to bool in a test, though. >> >> That would still break this: >> >> Base* p = getObj(); >> bool is_derived = dynamic_cast(p); >> >> What problem is the warning supposed to solve? > > A programmer assigning a bool with a pointer, there's an implicit evaluation > there isn't there? rather than: > > bool invalid = (NULL == p); Why is that preferable? > I expect this depends on what the standard allows then. 4.12 Boolean conversions [conv.bool] 1 A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true. A prvalue of type std::nullptr_t can be converted to a prvalue of type bool; the resulting value is false.
Re: cc1.exe: warnings being treated as errors
On 26 September 2011 09:33, Jon Grant wrote: > For example: -Wall means I see "control reaches end of non-void function" > messages, but doesn't output "cc1.exe: all warnings turned on" But it does tell you which option that warning came from: [-Wreturn-type] So if you want to disable it you can use -Wno-return-type If you want to make it a warning not an error you can stop using -Werror, so you get a notice that's in use. Feel free to request a new option in Bugzilla to suppress the note, that's the right place for this discussion.
Re: A question about detecting array bounds for case Warray-bounds-3.c
On 26 September 2011 08:13, Jiangning Liu wrote:
> PING...
>
>> -Original Message-
>> From: Jiangning Liu [mailto:jiangning@arm.com]
>> Sent: Thursday, September 22, 2011 10:19 AM
>> To: gcc@gcc.gnu.org
>> Cc: 'ja...@gcc.gnu.org'; 'muel...@gcc.gnu.org'; 'rgue...@gcc.gnu.org';
>> Matthew Gretton-Dann
>> Subject: A question about detecting array bounds for case Warray-
>> bounds-3.c
>>
>> Hi,
>>
>> For case gcc/testsuite/gcc.dg/Warray-bounds-3.c, obviously it is an
>> invalid C program, because the last iterations of all the loops cause
>> the access of arrays is beyond the max size of corresponding array
>> declarations. The condition of checking upper bound should be "<"
>> rather than "<=".
Which loops are you referring to?
struct iovec iov[43];
...
for (; cnt <= 40; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time->am_pm[cnt - 38] ?: "");
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
What's wrong with that? The last element accessed is iov[42] which is ok.
stringification of PREFIX etc...
Hello All,
It seems to me (file gcc/Makefile.in, definition of DRIVER_DEFINES) that the
configure-d PREFIX is wired inside
gcc.o (hence inside the gcc driver executable) without precautions.
In particular, I don't understand if someone can configure gcc with a prefix
containing weird characters, such as double-quotes " or backslashes \ or
perhaps even spaces.
My intuition is that GCC won't even build if the prefix contains such naughty
characters. If it is the case, should we document that.?
(I heard that on Windows systems, it is often the case that the prefix contains
spaces. I believe that on GNU/Linux systems, the only forbidden characters in
file paths are the slash -used as directory separator- and the null character,
putting spaces, asterisks, question marks, newlines or tabulations in file
names is very bad taste but probably possible.).
Do we have a convention that the PREFIX can only have sensible characters, so
that backslashes, spaces, double-quotes are forbidden there? What about Unicode
UTF8?
Within the context of MELT, I also have to make as string constants several
directories (etc.) related to the prefix or to the plugin directory. Should I
care about naughty characters inside?
For curious people, see
http://groups.google.com/group/gcc-melt/browse_thread/thread/74c36fae50a2b47d
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: stringification of PREFIX etc...
(I heard that on Windows systems, it is often the case that the prefix contains spaces. I believe that on GNU/Linux systems, the only forbidden characters in file paths are the slash -used as directory separator- and the null character, putting spaces, asterisks, question marks, newlines or tabulations in file names is very bad taste but probably possible.). Right, in windows, it is NOT considered bad taste to have spaces in file names, and in some circumstances like "Program Files" it is quite normal. Such spaces have been a continued source of bugs in all kinds of software including some of Microsoft development tools.
Re: cc1.exe: warnings being treated as errors
On 09/19/2011 06:59 PM, Jon Grant wrote: > > I noticed that when compiling C files with GCC and using the -Werror > option, I see this additional output: > > cc1.exe: warnings being treated as errors > ./src/main.c: In function 'main': > ./src/main.c:41:15: error: unused variable 'hello' > > Is the "cc1" line output needed? Oh, sure. It's really helpful to see an explanation as to why the compilation stopped on an apparently legal C program. Andrew.
Re: A question about detecting array bounds for case Warray-bounds-3.c
On 26/09/11 10:03, Jonathan Wakely wrote:
On 26 September 2011 08:13, Jiangning Liu wrote:
PING...
-Original Message-
From: Jiangning Liu [mailto:jiangning@arm.com]
Sent: Thursday, September 22, 2011 10:19 AM
To: gcc@gcc.gnu.org
Cc: 'ja...@gcc.gnu.org'; 'muel...@gcc.gnu.org'; 'rgue...@gcc.gnu.org';
Matthew Gretton-Dann
Subject: A question about detecting array bounds for case Warray-
bounds-3.c
Hi,
For case gcc/testsuite/gcc.dg/Warray-bounds-3.c, obviously it is an
invalid C program, because the last iterations of all the loops cause
the access of arrays is beyond the max size of corresponding array
declarations. The condition of checking upper bound should be "<"
rather than "<=".
Which loops are you referring to?
struct iovec iov[43];
...
for (; cnt<= 40; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time->am_pm[cnt - 38] ?: "");
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
What's wrong with that? The last element accessed is iov[42] which is ok.
This isn't about access to iov - but rather access to the arrays in
struct S *time:
struct S
{
const char *abday[7];
const char *day[7];
const char *abmon[12];
const char *mon[12];
const char *am_pm[2];
};
...
for (cnt = 0; cnt <= 7; ++cnt)
{
iov[2 + cnt].iov_base = (void *) (time->abday[cnt] ?: "");
iov[2 + cnt].iov_len = strlen (iov[2 + cnt].iov_base) + 1;
}
The last iteration (cnt == 7) will dereference time->abday[7] which is
one past the end of the array.
As far as I understand it -Warray-bounds should be emitting a warning
for this case, but PR31227 seemed to be about removing these warnings.
The PR comments do not explain why the array accesses are valid and I'm
hoping someone can shed some light on the situation - what are we missing?
Thanks,
Matt
--
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd
Re: No pointer conversion warning for "bool" in C/C++
Jonathan Wakely wrote, On 26/09/11 09:53: On 26 September 2011 09:32, Jon Grant wrote: [.] bool invalid = (NULL == p); Why is that preferable? It would be clearer IMHO what was happening. I expect this depends on what the standard allows then. 4.12 Boolean conversions [conv.bool] 1 A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true. A prvalue of type std::nullptr_t can be converted to a prvalue of type bool; the resulting value is false. I stand corrected. No reason to change anything if it is in the standard. Thank you for discussing this point. Best regards, Jon
added_clobbers_hard_reg_p and FLAGS_REGNUM
Hi, I was tracking down an assertion failure in GCC which occured while I was trying to bend some GCC constraints. I came accross this function `insn_invalid_p', which calls `added_clobbers_hard_reg_p' and before calling it, has the comment: /* If we have to add CLOBBERs, fail if we have to add ones that reference hard registers since our callers can't know if they are live or not. Otherwise, add them. */ Now, I would expect that this function wouldn't consider FLAGS_REGNUM a hard register in the normal sense, since I don't think it's liveliness is important (at least it doesn't seem important if your FLAGS_REGNUM is not a hard register from the hardware viewpoint. I have this insn: (set (reg:QI RAH) (reg:QI 56)) and this pattern: (parallel [(set (match_operand:QI "register_operand" "") (match_operand:QI "register_operand" "")) (clobber (reg:CC CC_REG))]) `insn_invalid_p' deems the insn as invalid since CC_REG is a hard reg and as the comment above explains it, it fails to process the new insn. My question is, should added_clobbers_hard_reg_p take FLAGS_REGNUM into consideration and allow it in a clobber, just as it allows a scratch? Cheers, -- PMatos
opencl and gcc
Hello All, OpenCL http://www.khronos.org/opencl/ is a new standard proposing an API for GPUs (targetting vector processing on heterogenous systems, like GPU + CPU). It suggests some restricted & specialized C dialect to code "kernel" functions (kernel in OpenCL means running on the GPU). Is there any branch or experimental code for adding OpenCL into GCC? Regards Naveen
Re: A case that PRE optimization hurts performance
On Mon, Sep 26, 2011 at 9:39 AM, Jiangning Liu wrote: >> > * Without PRE, >> > >> > Path1: >> > movl $2, %eax >> > cmpl $1, %eax >> > je .L3 >> > >> > Path2: >> > movb $3, %al >> > cmpl $1, %eax >> > je .L3 >> > >> > Path3: >> > cmpl $1, %eax >> > jne .L14 >> > >> > * With PRE, >> > >> > Path1: >> > movl $1, %ebx >> > movl $2, %eax >> > testb %bl, %bl >> > je .L3 >> > >> > Path2: >> > movl $1, %ebx >> > movb $3, %al >> > testb %bl, %bl >> > je .L3 >> > >> > Path3: >> > cmpl $1, %eax >> > setne %bl >> > testb %bl, %bl >> > jne .L14 >> > >> > Do you have any more thoughts? >> >> It seems to me that with PRE all the testb %bl, %bl >> should be evaluated at compile-time considering the >> preceeding movl $1, %ebx. Am I missing something? >> > > Yes. Can this be done by PRE or any other optimizations in middle end? Hm, the paths as you quote them are obfuscated by missed jump-threading. On the tree level we have # s_2 = PHI <2(5), 3(4), 2(6), s_25(7)> # prephitmp.6_1 = PHI <1(5), 1(4), 1(6), prephitmp.6_3(7)> : t_14 = t_24 + 1; D.2729_6 = MEM[base: t_14, offset: 0B]; D.2732_7 = D.2729_6 != 0; D.2734_9 = prephitmp.6_1 & D.2732_7; if (D.2734_9 != 0) where we could thread the cases with prephitmp.6_1 == 1, ultimately removing the & and forwarding the D.2729_6 != 0 test. Which would of course cause some code duplication. Jeff, you recently looked at tree jump-threading, can you see if we can improve things on this particular testcase? Thanks, Richard. > Thanks, > -Jiangning > >> Richard. >> > > > > >
Re: opencl and gcc
Hello Naveen, A few years ago I did a prototype of the OpenCL support library for google summer of code. As far as I know it has not been incorporated into gcc yet and that was the only OpenCL work done with gcc. The code I did is still available at: https://github.com/pcpratts/gcc_opencl Phil Pratt-Szeliga On Mon, Sep 26, 2011 at 6:54 AM, naveen yadav wrote: > Hello All, > > OpenCL http://www.khronos.org/opencl/ is a new standard proposing an > API for GPUs (targetting vector processing on heterogenous systems, > like GPU + CPU). > It suggests some restricted & specialized C dialect to code "kernel" > functions (kernel in OpenCL means running on the GPU). > > Is there any branch or experimental code for adding OpenCL into GCC? > > Regards > Naveen >
Re: opencl and gcc
On Mon, Sep 26, 2011 at 04:24:19PM +0530, naveen yadav wrote:
> Hello All,
>
> OpenCL http://www.khronos.org/opencl/ is a new standard proposing an
> API for GPUs (targetting vector processing on heterogenous systems,
> like GPU + CPU).
> It suggests some restricted & specialized C dialect to code "kernel"
> functions (kernel in OpenCL means running on the GPU).
>
> Is there any branch or experimental code for adding OpenCL into GCC?
Andrey Belevantsev and others from ISPRAS (Russia) had worked on generating
OpenCL from GCC
with "GRAPHITE-OpenCL: Generate OpenCL Code from Parallel Loops"
http://www.gccsummit.org/2010/view_abstract.php?content_key=15
and I (Basile) am very slowly working on adding an equivalent pass inside MELT
(but OpenCL work in MELT is very incomplete and progress is very slow).
Maybe what you want is the ability to compile OpenCL into binary code running
on the GPUs.
(AMD ATI/Stream OpenCL implementation is probably doing this on code above
LLVM. That code is sadly not free).
As far as I know there is no GCC branch on that part.
And there is also the Nvidia proprietary Cuda language.
Besides, the GPU thing is rapidly moving: with the trend (called APU at AMD...)
consisting of merging the GPU on
the same chip as the CPU, things are changing a big lot, because one of the
biggest issue of GPU computation is the bandwidth and latency between GPU &
CPU, and these two factors change a lot when moving from an PCI Express
external GPU card (like any AMD or Nvidia graphics board) to a GPU inside the
CPU chip.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Information on SCoP coverage by GRAPHITE
Dear all, I would like to know if GCC exposes any flag to collect static information related to the code coverage by the GRAPHITE framework. I have seen this information published on several papers and I am wondering how can I get the same information. What I would like to know is how many SCoPs are identified within a program and what percentage of the input program is a SCoP. thanks for the help. Regards, S. Pellegrini
Re: should sync builtins be full optimization barriers?
Hi, On Tue, 13 Sep 2011, Andrew MacLeod wrote: > Your example was not about regular stores, it used atomic variables. This reads as if there exists non-atomic variables in the new C++ mem-model. Assuming that this is so, why do those ugly requirements of not introducing new data races also apply to those non-atomic datas? Ciao, Michael.
Re: should sync builtins be full optimization barriers?
On Sat, Sep 24, 2011 at 11:24 AM, Richard Guenther wrote: > On Thu, Sep 15, 2011 at 6:26 PM, Paolo Bonzini wrote: >> On 09/15/2011 06:19 PM, Richard Henderson wrote: >>> >>> I wouldn't go that far. They *used* to be compiler barriers, >>> but clearly something broke at some point without anyone noticing. >>> We don't know how many versions are affected until we debug it. >>> For all we know it broke in 4.5 and 4.4 is fine. >> >> 4.4 is not necessarily fine, it may also be that an unrelated 4.5 change >> exposed a latent bug. >> >> But indeed Richard Sandiford mentioned offlist that perhaps >> ALIAS_SET_MEMORY_BARRIER machinery broke. Fixing the bug in 4.5/4.6/4.7 >> will definitely shed more light. > > ALIAS_SET_MEMORY_BARRIER?! Eh, well - that will make TBAA consider > something a memory barrier (I suppose the value of the macro is just zero), > but clearly non-TBAA alias analysis will happily disambiguate things. Nope, it's implemented/tested in a way that should work (on RTL, that is). Richard.
misleading description in vec.h?
Hi, Here is comment from line 36, gcc/vec.h Both the structure object and pointer variants pass pointers to objects around -- in the former case the pointers are stored into the vector and in the latter case the pointers are dereferenced and the objects copied into the vector. But by reading implementation, it seems that this description is reverse. I think that it should be something like in the *latter* case the pointers are stored into the vector and in the *former* case the pointers are dereferenced and the objects copied into the vector. That is, the pointers in structure object variant are dereferenced and the objects copied into the vector. Am I missing something? Thanks, Liang.
Re: cc1.exe: warnings being treated as errors
Andrew Haley writes: > On 09/19/2011 06:59 PM, Jon Grant wrote: > >> >> I noticed that when compiling C files with GCC and using the -Werror >> option, I see this additional output: >> >> cc1.exe: warnings being treated as errors >> ./src/main.c: In function 'main': >> ./src/main.c:41:15: error: unused variable 'hello' >> >> Is the "cc1" line output needed? > > Oh, sure. It's really helpful to see an explanation as to why the > compilation stopped on an apparently legal C program. In the past, definitely, but today I'm going to argue that now that -fdiagnostics-show-option is the default, we can reasonably remove that line. Consider: foo.c: In function ‘foo’: foo.c:1:18: error: unused variable ‘hello’ [-Werror=unused-variable] cc1: all warnings being treated as errors The -Werror= tag output by -fdiagnostics-show-option provides all the required information. Ian
Re: stringification of PREFIX etc...
Basile Starynkevitch writes: > My intuition is that GCC won't even build if the prefix contains such naughty > characters. If it is the case, should we document that.? It's easy enough to try it. You're right: spaces and double quotes in --prefix don't work. Rather than document that restriction, I think we should fix it. At least, we should definitely fix it so that spaces work. Double quotes are far less important. It should not be difficult to modify the configure script or the Makefile to apply proper quoting when passing $(prefix) to $(CC). Ian
Re: cc1.exe: warnings being treated as errors
On 09/26/2011 05:11 PM, Ian Lance Taylor wrote: > Andrew Haley writes: > >> On 09/19/2011 06:59 PM, Jon Grant wrote: >> >>> >>> I noticed that when compiling C files with GCC and using the -Werror >>> option, I see this additional output: >>> >>> cc1.exe: warnings being treated as errors >>> ./src/main.c: In function 'main': >>> ./src/main.c:41:15: error: unused variable 'hello' >>> >>> Is the "cc1" line output needed? >> >> Oh, sure. It's really helpful to see an explanation as to why the >> compilation stopped on an apparently legal C program. > > In the past, definitely, but today I'm going to argue that now that > -fdiagnostics-show-option is the default, we can reasonably remove that > line. Consider: > > foo.c: In function ‘foo’: > foo.c:1:18: error: unused variable ‘hello’ [-Werror=unused-variable] > cc1: all warnings being treated as errors > > The -Werror= tag output by -fdiagnostics-show-option provides all the > required information. That's probably true. Andrew.
Re: added_clobbers_hard_reg_p and FLAGS_REGNUM
"Paulo J. Matos" writes: > My question is, should added_clobbers_hard_reg_p take FLAGS_REGNUM > into consideration and allow it in a clobber, just as it allows a > scratch? There is no middle-end concept of FLAGS_REGNUM (barring reg-stack.c which is really a target-specific pass). Some targets have several different flags registers, of which some are caller-saved and callee-saved. So what you are suggesting would seem to be a large conceptual change to the middle-end. One approach would be to use a pseudo-register which you eliminate to the flag register. I really don't know how well that would work. The function added_clobbers_hard_reg_p is a generated function. So another approach would be some sort of attribute which directs the generator (genemit) to ignore certain hard registers. And another approach would be a new target hook. I haven't thought enough about it to know whether any of these is a good idea. Ian
Re: should sync builtins be full optimization barriers?
Michael Matz writes: > Hi, > > On Tue, 13 Sep 2011, Andrew MacLeod wrote: > >> Your example was not about regular stores, it used atomic variables. > > This reads as if there exists non-atomic variables in the new C++ > mem-model. Assuming that this is so, why do those ugly requirements of > not introducing new data races also apply to those non-atomic datas? My understanding is that the C++ memory model bans speculative stores even for non-atomic variables. I believe this is because of the acquire/release semantics they have adopted--a release of an atomic variable applies to all writes that occur before the release. Ian
Re: misleading description in vec.h?
Liang Wang writes: > Here is comment from line 36, gcc/vec.h > > Both the structure object and pointer variants > pass pointers to objects around -- in the former case the pointers > are stored into the vector and in the latter case the pointers are > dereferenced and the objects copied into the vector. > > But by reading implementation, it seems that this description is reverse. > I think that it should be something like > > in the *latter* case the pointers > are stored into the vector and in the *former* case the pointers are > dereferenced and the objects copied into the vector. > > That is, the pointers in structure object variant are dereferenced and > the objects copied into the vector. I think you are correct and the comment is wrong. Ian
Re: should sync builtins be full optimization barriers?
Hi, On Tue, 13 Sep 2011, Andrew MacLeod wrote: Your example was not about regular stores, it used atomic variables. This reads as if there exists non-atomic variables in the new C++ mem-model. Assuming that this is so, why do those ugly requirements of not introducing new data races also apply to those non-atomic datas? Why is it ugly to avoid introducing a data race into a race-free program? I would think that is a basic necessity for a multi threaded program. There are normal everyday shared variables like we've always had, and there are the new atomic variables which have slightly different characteristics. The C++11 memory model asserts that a program containing data races involving *non-atomic* variables has undefined semantics. The compiler is not allowed to introduce any data races into an otherwise correct program. Atomic variables are effectively serialized across the system. When 2 threads write to an atomic, one will fully happen before the other and *all* threads see it happen in that order. The order may not be predictable from one run of the program to another, but all the threads in a system will see a consistant view of an atomic. This may make them more expensive to use since writes can't be delayed, cache lines may have to be flushed, or other memory subsystems may need to get involved to execute the operation properly. All atomic operations also have a memory model parameter which specifies one of 6 synchronization modes. When the atomic value is being read or written, it controls how other outstanding shared memory operations may also be flushed into the system at the same time, assuring them visibility in other threads. Since atomic operations may have these side effects, there are serious restrictions on how they can be moved and modified by the compiler, as well as what optimizations can be performed around them. For now, the optimizers are simply treating them as function calls with side effects and doing very little. Andrew
Re: opencl and gcc
There's a very basic GCC front-end for LLVM-IR at http://gcc-llvmir.googlecode.com, which has some support for using clang to generate the LLVM IR. It might be usable as a starting point for an OpenCL front-end, assuming that the OpenCL parser made it into clang. Matthew
Re: should sync builtins be full optimization barriers?
On Mon, Sep 26, 2011 at 9:57 AM, Andrew MacLeod wrote: >> Hi, >> >> On Tue, 13 Sep 2011, Andrew MacLeod wrote: >> >>> Your example was not about regular stores, it used atomic variables. >> >> This reads as if there exists non-atomic variables in the new C++ >> mem-model. Assuming that this is so, why do those ugly requirements of >> not introducing new data races also apply to those non-atomic datas? >> >> > Why is it ugly to avoid introducing a data race into a race-free program? I > would think that is a basic necessity for a multi threaded program. > > There are normal everyday shared variables like we've always had, and there > are the new atomic variables which have slightly different characteristics. > > The C++11 memory model asserts that a program containing data races > involving *non-atomic* variables has undefined semantics. The compiler is > not allowed to introduce any data races into an otherwise correct program. C++11 specifies data races in terms of properties of the source code. A conforming implementation may translate that code into something that races on actual hardware if the race is benign _on that hardware_. For example, it might read from a memory address that's being written to concurrently if it knows that the write cannot materially affect the value read. A user's C++ code that attempted to do so would have undefined behavior, but the C++ compiler is generating code for some more concrete platform that will likely have a range of possible behaviors for such races. Of course on a platform that actually diagnosed concurrent accesses such games would be disallowed, and we'd be back to a land in which the C++ compiler really could not introduce races unless they already existed in the user's code. -- James
Re: A case that PRE optimization hurts performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/26/11 05:00, Richard Guenther wrote: > On Mon, Sep 26, 2011 at 9:39 AM, Jiangning Liu > wrote: * Without PRE, Path1: movl$2, %eax cmpl$1, %eax je .L3 Path2: movb$3, %al cmpl$1, %eax je .L3 Path3: cmpl$1, %eax jne .L14 * With PRE, Path1: movl$1, %ebx movl$2, %eax testb %bl, %bl je .L3 Path2: movl$1, %ebx movb$3, %al testb %bl, %bl je .L3 Path3: cmpl$1, %eax setne %bl testb %bl, %bl jne .L14 Do you have any more thoughts? >>> >>> It seems to me that with PRE all the testb %bl, %bl should be >>> evaluated at compile-time considering the preceeding movl $1, >>> %ebx. Am I missing something? >>> >> >> Yes. Can this be done by PRE or any other optimizations in middle >> end? > > Hm, the paths as you quote them are obfuscated by missed > jump-threading. On the tree level we have > > # s_2 = PHI <2(5), 3(4), 2(6), s_25(7)> # prephitmp.6_1 = PHI > <1(5), 1(4), 1(6), prephitmp.6_3(7)> : t_14 = t_24 + 1; > D.2729_6 = MEM[base: t_14, offset: 0B]; D.2732_7 = D.2729_6 != 0; > D.2734_9 = prephitmp.6_1 & D.2732_7; if (D.2734_9 != 0) > > where we could thread the cases with prephitmp.6_1 == 1, > ultimately removing the & and forwarding the D.2729_6 != 0 test. > Which would of course cause some code duplication. > > Jeff, you recently looked at tree jump-threading, can you see if > we can improve things on this particular testcase? There's nothing threading can do here because it doesn't know anything about the value MEM[t14]. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOgKuLAAoJEBRtltQi2kC75aIH/iikuOQXrMrQJFbQw0COXznB OGq8iXdGwTJGH13vxdItTE0upJp7RgUVLzuhdqj1elTLHv/ujYygMsQRNGKcc8tb GMLECmWDhZqQTFXcTJCgJNZiv7MH1PNELXSdIkkSnxY+pwyn9AX5D3+HcTSjGU6B 51AdUNVph/VSaVboAgcrFpu9S0pX9HVTqFy4JI83Lh613zDVSmPo14DDy7vjBvE9 2Srlvlw0srYup97bGmRqN8wT4ZLLlyYSB2rjEFc6jmgXVncxiteQYIUZpy0lcC0M q3j80aXjZ57/iWyAbqDr1jI5tbVKDBkRa9LL1jvn9534adiG4GrnSMPhoog0ibA= =azr5 -END PGP SIGNATURE-
Re: should sync builtins be full optimization barriers?
On 09/26/2011 01:31 PM, James Dennett wrote: On Mon, Sep 26, 2011 at 9:57 AM, Andrew MacLeod wrote: The C++11 memory model asserts that a program containing data races involving *non-atomic* variables has undefined semantics. The compiler is not allowed to introduce any data races into an otherwise correct program. C++11 specifies data races in terms of properties of the source code. A conforming implementation may translate that code into something that races on actual hardware if the race is benign _on that hardware_. For example, it might read from a memory address that's being written to concurrently if it knows that the write cannot materially affect the value read. A user's C++ code that attempted to do so would have undefined behavior, but the C++ compiler is generating code for some more concrete platform that will likely have a range of possible behaviors for such races. I'm only talking about detectable data races, although I didn't clarify that here. We're allowing load races for the most part since they are pretty much benign everywhere. We have to avoid introducing new races with stores though because they can usually be detected. Andrew
Re: misleading description in vec.h?
On Tue, Sep 27, 2011 at 12:27 AM, Ian Lance Taylor wrote: > Liang Wang writes: > >> Here is comment from line 36, gcc/vec.h >> >> Both the structure object and pointer variants >> pass pointers to objects around -- in the former case the pointers >> are stored into the vector and in the latter case the pointers are >> dereferenced and the objects copied into the vector. >> >> But by reading implementation, it seems that this description is reverse. >> I think that it should be something like >> >> in the *latter* case the pointers >> are stored into the vector and in the *former* case the pointers are >> dereferenced and the objects copied into the vector. >> >> That is, the pointers in structure object variant are dereferenced and >> the objects copied into the vector. > > I think you are correct and the comment is wrong. Thanks. Patch is sent to gcc-patches. Liang > > Ian >
RE: A case that PRE optimization hurts performance
> -Original Message- > From: Jeff Law [mailto:l...@redhat.com] > Sent: Tuesday, September 27, 2011 12:43 AM > To: Richard Guenther > Cc: Jiangning Liu; gcc@gcc.gnu.org > Subject: Re: A case that PRE optimization hurts performance > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/26/11 05:00, Richard Guenther wrote: > > On Mon, Sep 26, 2011 at 9:39 AM, Jiangning Liu > > wrote: > * Without PRE, > > Path1: movl$2, %eax cmpl$1, %eax je .L3 > > Path2: movb$3, %al cmpl$1, %eax je .L3 > > Path3: cmpl$1, %eax jne .L14 > > * With PRE, > > Path1: movl$1, %ebx movl$2, %eax testb %bl, %bl je > .L3 > > Path2: movl$1, %ebx movb$3, %al testb %bl, %bl je > .L3 > > Path3: cmpl$1, %eax setne %bl testb %bl, %bl jne > .L14 > > Do you have any more thoughts? > >>> > >>> It seems to me that with PRE all the testb %bl, %bl should be > >>> evaluated at compile-time considering the preceeding movl $1, > >>> %ebx. Am I missing something? > >>> > >> > >> Yes. Can this be done by PRE or any other optimizations in middle > >> end? > > > > Hm, the paths as you quote them are obfuscated by missed > > jump-threading. On the tree level we have > > > > # s_2 = PHI <2(5), 3(4), 2(6), s_25(7)> # prephitmp.6_1 = PHI > > <1(5), 1(4), 1(6), prephitmp.6_3(7)> : t_14 = t_24 + 1; > > D.2729_6 = MEM[base: t_14, offset: 0B]; D.2732_7 = D.2729_6 != 0; > > D.2734_9 = prephitmp.6_1 & D.2732_7; if (D.2734_9 != 0) > > > > where we could thread the cases with prephitmp.6_1 == 1, > > ultimately removing the & and forwarding the D.2729_6 != 0 test. > > Which would of course cause some code duplication. > > > > Jeff, you recently looked at tree jump-threading, can you see if > > we can improve things on this particular testcase? > There's nothing threading can do here because it doesn't know anything > about the value MEM[t14]. > Jeff, Could you please explain more about this? What information does jump threading want to know on MEM[t14]? Do you mean it's hard to duplicate that basic block due to some reasons? Thanks, -Jiangning > > Jeff > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOgKuLAAoJEBRtltQi2kC75aIH/iikuOQXrMrQJFbQw0COXznB > OGq8iXdGwTJGH13vxdItTE0upJp7RgUVLzuhdqj1elTLHv/ujYygMsQRNGKcc8tb > GMLECmWDhZqQTFXcTJCgJNZiv7MH1PNELXSdIkkSnxY+pwyn9AX5D3+HcTSjGU6B > 51AdUNVph/VSaVboAgcrFpu9S0pX9HVTqFy4JI83Lh613zDVSmPo14DDy7vjBvE9 > 2Srlvlw0srYup97bGmRqN8wT4ZLLlyYSB2rjEFc6jmgXVncxiteQYIUZpy0lcC0M > q3j80aXjZ57/iWyAbqDr1jI5tbVKDBkRa9LL1jvn9534adiG4GrnSMPhoog0ibA= > =azr5 > -END PGP SIGNATURE-
