Re: No pointer conversion warning for bool in C/C++
On 26 September 2011 05:29, Ian Lance Taylor wrote: Jon Grant j...@jguk.org 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_castDerived*(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 Browndavid.br...@hesbynett.no 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 Grantj...@jguk.org 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_castDerived*(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 Grantj...@jguk.org 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_castDerived*(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: basileatstarynkevitchdotnet 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 jiangning@arm.com 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) L10: 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 yad.nav...@gmail.com 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
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 richard.guent...@gmail.com wrote: On Thu, Sep 15, 2011 at 6:26 PM, Paolo Bonzini bonz...@gnu.org 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 a...@redhat.com 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 bas...@starynkevitch.net 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 a...@redhat.com 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 pa...@matos-sorge.com 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 m...@suse.de 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 netcas...@gmail.com 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 amacl...@redhat.com 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 jiangning@arm.com 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) L10: 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 MacLeodamacl...@redhat.com 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 i...@google.com wrote: Liang Wang netcas...@gmail.com 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 jiangning@arm.com 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) L10: 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-
[Bug target/50493] ICE in neon_disambiguate_copy, at config/arm/arm.c:20388
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50493 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-26 CC||irar at il dot ibm.com, ||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-09-26 07:18:29 UTC --- Looks like the problem is with neon_movv4si. My patch enabled the use of quad-word vectors by default, the test doesn't fail with double-words.
[Bug fortran/50515] gfortran should not accept an external that is a common (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50515 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||accepts-invalid Last reconfirmed||2011-09-26 CC||janus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-09-26 07:41:11 UTC --- Trivial patch: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 179143) +++ gcc/fortran/resolve.c(working copy) @@ -905,6 +905,10 @@ resolve_common_blocks (gfc_symtree *common_root) gfc_error (COMMON block '%s' at %L is used as PARAMETER at %L, sym-name, common_root-n.common-where, sym-declared_at); + if (sym-attr.external) +gfc_error (COMMON block '%s' at %L can not have the EXTERNAL attribute, + sym-name, common_root-n.common-where); + if (sym-attr.intrinsic) gfc_error (COMMON block '%s' at %L is also an intrinsic procedure, sym-name, common_root-n.common-where);
[Bug tree-optimization/50522] New: C++ std::valarray vectorization missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50522
Bug #: 50522
Summary: C++ std::valarray vectorization missed optimization
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: i...@gcc.gnu.org, ja...@gcc.gnu.org,
rgue...@gcc.gnu.org
#include valarray
std::valarrayint
f1 (std::valarrayint a, std::valarrayint b, std::valarrayint c, int z)
{
int i;
for (i = 0; i z; i++)
{
a[i] = b[i] + c[i];
a[i] += b[i] * c[i];
}
return a;
}
void
f2 (std::valarrayint __restrict a, std::valarrayint __restrict b,
std::valarrayint __restrict c, int z)
{
int i;
for (i = 0; i z; i++)
{
a[i] = b[i] + c[i];
a[i] += b[i] * c[i];
}
}
should be vectorizable (f2 only since
http://gcc.gnu.org/viewcvs?root=gccview=revrev=179166 ), but it is not.
There seems to be 2 problems:
1) from the inlines we unfortunately have pointers (resp. references)
initialized from TYPE_RESTRICT pointers, which don't have TYPE_RESTRICT
themselves.
--- tree-ssa-alias.c.jj 2011-09-15 12:18:37.0 +0200
+++ tree-ssa-alias.c 2011-09-26 09:10:50.0 +0200
@@ -223,7 +223,6 @@ ptr_deref_may_alias_decl_p (tree ptr, tr
pointer and that pointers points-to set doesn't contain this decl
then they can't alias. */
if (DECL_RESTRICTED_P (decl)
- TYPE_RESTRICT (TREE_TYPE (ptr))
pi-pt.vars_contains_restrict)
return bitmap_bit_p (pi-pt.vars, DECL_PT_UID (decl));
@@ -319,8 +318,8 @@ ptr_derefs_may_alias_p (tree ptr1, tree
/* If both pointers are restrict-qualified try to disambiguate
with restrict information. */
- if (TYPE_RESTRICT (TREE_TYPE (ptr1))
- TYPE_RESTRICT (TREE_TYPE (ptr2))
+ if (pi1-pt.vars_contains_restrict
+ pi2-pt.vars_contains_restrict
!pt_solutions_same_restrict_base (pi1-pt, pi2-pt))
return false;
seems to fix that part, but maybe it is too unsafe (would e.g.
vars_contains_restrict propagate through cast of a pointer to integer and
back?). Maybe just a quick hack of allowing either TYPE_RESTRICT, or
POINTER_TYPE_P SSA_NAME initialized from either a pointer cast or
POINTER_PLUS_EXPR from a TYPE_RESTRICT pointer would be enough to fix this and
don't regress problematic __restrict cases (richi, which are the currently
known ones?).
2) even with that change, the vectorizer didn't vectorize this. But apparently
this turned out to be something Eric fixed over the weekend - r179165 - where
simple_iv checked just for POINTER_TYPE and not for POINTER_TYPE_P.
[Bug c++/26748] gimplify_expr_stmt in cp-gimplifer.c does warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26748 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-26 08:03:42 UTC --- (In reply to comment #2) Andrew what is the issue here? Can you clarify? That the gimplifier should not emit syntax diagnostics, but the way GCC is designed, this may well be impossible in some cases. Bonus points for managing to share the warning between C and C++.
[Bug fortran/50517] gfortran must detect that actual argument type is different from dummy argument type (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50517 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2011-09-26 08:05:10 UTC --- (In reply to comment #0) ! gfortran must detect that actual argument type is different from dummy argument type (r178939) Could you explain why you assume that this is invalid? I would say it is valid at least in F95, see Fortran 95 standard, chapter 4.4.2, Determination of derived types. I haven't checked if this is still the case in F03 or F08. gfortran has a routine to check if two derived types are actually the same (gfc_compare_derived_types in interface.c).
[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 --- Comment #51 from rguenther at suse dot de rguenther at suse dot de 2011-09-26 08:04:37 UTC --- On Mon, 12 Sep 2011, rearnsha at arm dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 --- Comment #48 from Richard Earnshaw rearnsha at arm dot com 2011-09-12 15:31:51 UTC --- On 12/09/11 16:18, law at redhat dot com wrote: A much simpler way to fix this is to emit a barrier just prior to mucking around with stack pointer in the epilogue. That's how targets have dealt with this exact issue for a couple decades. Simpler, but wrong. The compiler should not be generating unsafe code by default. The problem is in the mid-end and expecting every port to get this right in order to work-around a mid-end bug is just stupid stupid stupid. The mid end should not be scheduling around stack moves unless it has been explicitly told it is safe to do this. I don't understand why there is so much resistance to fixing the problem properly. The middle-end does not treat stack moves specially, they are just memory accesses. Extra dependences have to be modeled accordingly. It's a hack to treat stack moves specially, not a proper fix.
[Bug c++/26747] bad break/continue is not detected until the gimplifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26747 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-26 08:06:31 UTC --- (In reply to comment #5) Isn't the C++ front-end also fixed? I can confirm that currently the error comes from cp_parser_jump_statement. In general, the check in build_bc_goto is apparently dead: I have been able to build and test with gcc_assert (label) in its place... So, remove it and close this for good?
[Bug fortran/50517] gfortran must detect that actual argument type is different from dummy argument type (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50517 --- Comment #2 from janus at gcc dot gnu.org 2011-09-26 08:09:09 UTC --- Unfortunately, gfortran also does not reject it if the types actually differ: program main type t integer :: i end type type u real :: r end type type(u), external :: ufunction call sub(ufunction) ! gfortran should emit an error message here contains subroutine sub(tfunction) type(t), external :: tfunction end subroutine end program When exchanging type(u)/type(t) for integer/real, the check works: call sub(ufunction) ! gfortran should emit an error message here 1 Error: Interface mismatch in dummy procedure 'tfunction' at (1): Type/kind mismatch in return value of 'ufunction'
[Bug tree-optimization/50522] C++ std::valarray vectorization missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50522 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-26 08:23:15 UTC --- Created attachment 25365 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25365 gcc47-pr50522-hack.patch The perhaps safer hack, which handles only pointers initialized from casted TYPE_RESTRICT or POINTER_PLUS_EXPR of TYPE_RESTRICT. Both functions are still vectorized.
[Bug tree-optimization/34265] Missed optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #37 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 08:36:26 UTC --- Testcases for runtime properties are not supported.
[Bug fortran/50517] gfortran must detect that actual argument type is different from dummy argument type (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50517 --- Comment #3 from janus at gcc dot gnu.org 2011-09-26 08:45:49 UTC --- (In reply to comment #1) Could you explain why you assume that this is invalid? I would say it is valid at least in F95, see Fortran 95 standard, chapter 4.4.2, Determination of derived types. However, this only applies to types in different namespaces. If they are in the same namespace, the type symbols themselves must be equal. In consequence, I agree that the test case in comment #0 is invalid.
[Bug fortran/50517] gfortran must detect that actual argument type is different from dummy argument type (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50517 --- Comment #4 from janus at gcc dot gnu.org 2011-09-26 09:01:45 UTC --- (In reply to comment #1) Could you explain why you assume that this is invalid? I would say it is valid at least in F95, see Fortran 95 standard, chapter 4.4.2, Determination of derived types. However, this only applies to types in different namespaces. If they are in the same namespace, the type symbols themselves must be equal. In consequence, I agree that the test case in comment #0 is invalid.
[Bug c++/50474] GCC (cc1plus) hangs forever compiling with -O2 (-fcse-follow-jumps)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50474 --- Comment #2 from Steffen Schmidt steffen-schmidt at siemens dot com 2011-09-26 09:04:33 UTC --- I'm very sorry for the inconvenience, but this bug is not directly related to any CodeSourcery built GCC toolchain. It was a pure coincedence using such a toolchain. I am able to reproduce the effect with toolchain GCC 4.6.0 for MIPS built from source using MinGW: Target: mips-siemens-elf Configured with: ../../gcc-4.6.0/configure --enable-languages=c,c++ --with-arch=mips32r2 -enable-poison-system-directories --enable-interwork --enable-multilib --enable-sgxx-sde-multilibs --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --disable-libmudflap --disable-libssp --disable-shared --disable-threads --disable-libgomp --disable-win32-registry --disable-nls --target=mips-siemens-elf --with-newlib --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --prefix=/build_mips_4.6.0_cloog/cross-gcc/mips-siemens-elf --with-gmp=/build_mips_4.6.0_cloog/host --with-mpfr=/build_mips_4.6.0_cloog/host --with-mpc=/build_mips_4.6.0_cloog/host --with-ppl=/build_mips_4.6.0_cloog/host --with-cloog=/build_mips_4.6.0_cloog/host --with-sysroot=/build_mips_4.6.0_cloog/cross-gcc/mips-siemens-elf Thread model: single gcc version 4.6.0 (GCC) The behaviour seems to be related to the code line if(r != !!r) When replacing the condition with the equivalent if(r != 0 r != 1) everything seems fine. Is it worth investigating the issue further and re-open it?
[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-26
09:08:36 UTC ---
#define strcpy(x,y) __builtin___strcpy_chk (x, y, __builtin_object_size (x, 1))
int
f1 (void)
{
struct A { char buf1[9]; char buf2[4]; } a;
strcpy (a.buf1 + 9, a);
return 0;
}
int
f2 (void)
{
struct A { char buf1[9]; char buf2[4]; } a;
strcpy (a.buf2 + 0, a);
return 0;
}
int
f3 (void)
{
struct A { char buf1[9]; char buf2[4]; } a;
strcpy (a.buf1 + 10, a);
return 0;
}
int
f4 (void)
{
struct A { char buf1[9]; char buf2[4]; } a;
strcpy (a.buf2 - 1, a);
return 0;
}
int
f5 (void)
{
struct A { char buf1[9]; char buf2[4]; } a;
strcpy ((char *) a + 10, a);
return 0;
}
int
f6 (void)
{
struct A { char buf1[9]; char buf2[4]; } a;
strcpy ((char *) a.buf2 - 1, a);
return 0;
}
used to warn in f{1,3,4,6} (and fail at runtime) and not in f{2,5} in
4.{1,2,3,4,6} (haven't checked 4.5), doesn't warn nor fail on the trunk.
So yes, 4.0+ clearly did some reconstruction, but only in limited cases (e.g.
when the a is offsetted). Some field + offset remained COMPONENT_REF +
offset.
[Bug fortran/50463] [4.6/4.7 Regression] -ftree-dse leeds to wrong code with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50463 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 09:08:26 UTC --- Invalid. COMMON / / ARRAY(1) ARRAY(START) = CHECK ARRAY(LIMIT) = CHECK the first store is dead as the only valid values for both START and LIMIT are 1 because of the size specification in the declaration of ARRAY. If the fortran standard makes accessing ARRAY(i) with i != 1 well-defined then the Frontend may not provide a declaration of ARRAY with size 1 to the middle-end.
[Bug fortran/50517] gfortran must detect that actual argument type is different from dummy argument type (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50517
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011-09-26
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #5 from janus at gcc dot gnu.org 2011-09-26 09:12:04 UTC ---
With the following patch, both comment #0 and comment #2 are correctly
rejected:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 179143)
+++ gcc/fortran/interface.c(working copy)
@@ -1124,10 +1124,10 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol
/* If both are functions, check type and kind. */
if (s1-ts.type == BT_UNKNOWN)
return 1;
- if ((s1-ts.type != s2-ts.type) || (s1-ts.kind != s2-ts.kind))
+ if (!compare_type_rank (s1,s2))
{
if (errmsg != NULL)
-snprintf (errmsg, err_len, Type/kind mismatch in return value
+snprintf (errmsg, err_len, Type/rank mismatch in return value
of '%s', name2);
return 0;
}
[Bug c++/50523] New: C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523
Bug #: 50523
Summary: C++ FE apparently incorrectly rejects tramp3d
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org
In between the following two builds:
110912.64071
110913.25243
tramp3d stopped building with following errors:
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp: In instantiation of 'static
CreateLeafFieldG1, T1, E1 ::Return_t CreateLeafFieldG1, T1, E1
::make(const Input_t) [with GeometryTag = NoMesh3, T = Vector3, double,
Full, EngineTag = ViewEngine3, IndexFunctionGenericURMMeshTraits3, double,
UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ,
CreateLeafFieldG1, T1, E1 ::Return_t = ReferenceFieldNoMesh3, Vector3,
double, Full, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double,
UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ,
CreateLeafFieldG1, T1, E1 ::Input_t = FieldNoMesh3, Vector3, double,
Full, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double,
UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ]':
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:42503:44: required from
'typename MakeFieldReturnBinaryNodeOpSubtract, typename CreateLeafFieldG1,
T1, E1 ::Leaf_t, typename CreateLeafVectorD2, T2, E2 ::Leaf_t
::Expression_t operator-(const FieldG1, T1, E1, const VectorD2, T2, E2)
[with G1 = NoMesh3, T1 = Vector3, double, Full, E1 = ViewEngine3,
IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag,
CartesianTag, 3 ::PositionsFunctor , int D2 = 3, T2 = double, E2 = Full,
typename MakeFieldReturnBinaryNodeOpSubtract, typename CreateLeafFieldG1,
T1, E1 ::Leaf_t, typename CreateLeafVectorD2, T2, E2 ::Leaf_t
::Expression_t = FieldNoMesh3, Vector3, double, Full,
ExpressionTagBinaryNodeOpSubtract, ReferenceFieldNoMesh3, Vector3,
double, Full, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double,
UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ,
ScalarVector3, double, Full]'
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:55995:68: required from
here
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:43646:22: error: conversion
from 'CreateLeafFieldNoMesh3, Vector3, double, Full, ViewEngine3,
IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag,
CartesianTag, 3 ::PositionsFunctor ::Leaf_t {aka
ReferenceFieldNoMesh3, Vector3, double, Full, ViewEngine3,
IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag,
CartesianTag, 3 ::PositionsFunctor }' to 'const FieldNoMesh3,
Vector3, double, Full, ViewEngine3, IndexFunctionGenericURMMeshTraits3,
double, UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ' is
ambiguous
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:43646:22: note: candidates
are:
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:817:3: note:
ReferenceT::operator T() const [with T = FieldNoMesh3, Vector3, double,
Full, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double,
UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ]
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:816:3: note:
ReferenceT::operator const T() const [with T = FieldNoMesh3, Vector3,
double, Full, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double,
UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ]
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp: In instantiation of
'BinaryNodeOp, Left, Right::BinaryNode(const Left, const Right) [with Op =
OpSubtract, Left = ReferenceFieldNoMesh3, Vector3, double, Full,
ViewEngine3, IndexFunctionGenericURMMeshTraits3, double,
UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor , Right =
ScalarVector3, double, Full ]':
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:42503:44: required from
'typename MakeFieldReturnBinaryNodeOpSubtract, typename CreateLeafFieldG1,
T1, E1 ::Leaf_t, typename CreateLeafVectorD2, T2, E2 ::Leaf_t
::Expression_t operator-(const FieldG1, T1, E1, const VectorD2, T2, E2)
[with G1 = NoMesh3, T1 = Vector3, double, Full, E1 = ViewEngine3,
IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag,
CartesianTag, 3 ::PositionsFunctor , int D2 = 3, T2 = double, E2 = Full,
typename MakeFieldReturnBinaryNodeOpSubtract, typename CreateLeafFieldG1,
T1, E1 ::Leaf_t, typename CreateLeafVectorD2, T2, E2 ::Leaf_t
::Expression_t = FieldNoMesh3, Vector3, double, Full,
ExpressionTagBinaryNodeOpSubtract, ReferenceFieldNoMesh3, Vector3,
double, Full, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double,
UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ,
ScalarVector3, double, Full]'
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:55995:68: required from
here
/gcc/spec/scripts/c++bench/tramp3d/tramp3d-v4.cpp:876:27: error: conversion
from 'const ReferenceFieldNoMesh3, Vector3, double, Full,
[Bug c++/50474] GCC (cc1plus) hangs forever compiling with -O2 (-fcse-follow-jumps)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50474 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-09-26 09:38:11 UTC --- (In reply to comment #2) The behaviour seems to be related to the code line if(r != !!r) This is clearly a dup of PR50380.
[Bug c++/50523] C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-26 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-26 09:50:05 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=178789
[Bug fortran/50524] New: *** glibc detected *** invalid free() pointer on illegal code (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50524 Bug #: 50524 Summary: *** glibc detected *** invalid free() pointer on illegal code (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com !*** glibc detected *** invalid free() pointer on illegal code (r178939) !*/home/vitti/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951: !*free(): invalid pointer: 0x0001 *** ! before compilation must export MALLOC_CHECK_=1 print *,'qwe'(1:1e0) end
[Bug fortran/50525] New: gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 Bug #: 50525 Summary: gfortran should not allow early reference to entry dummy argument (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should not allow early reference to entry dummy argument (r178939) subroutine sub f(y)=x ! this is wrong entry e(x) end
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #27 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 10:16:20 UTC --- Yes, I think I analyzed the reason for this at some point (IPA profile) and fixed it.
[Bug c++/42032] Aliasing errors in stl_tree.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42032 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 10:30:35 UTC --- Nope. Marking fixed in 4.5.
[Bug tree-optimization/50522] C++ std::valarray vectorization missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50522 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-26 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 10:36:38 UTC --- (In reply to comment #1) Created attachment 25365 [details] gcc47-pr50522-hack.patch The perhaps safer hack, which handles only pointers initialized from casted TYPE_RESTRICT or POINTER_PLUS_EXPR of TYPE_RESTRICT. Both functions are still vectorized. Looks like a hack ;) Restrict support was designed to work without the TYPE_RESTRICT checks but ISTR there were miscompiles without adding them - maybe all latent issues have been fixed now, but you might run into PR48764 more often. Restrict will propagate through ptr/int/ptr conversions but should end up aliased whenever two resulting pointers are based off the same initial restrict tag. Thus, if removing TYPE_RESTRICT checks bootstraps and tests ok, I'd approve that patch ...
[Bug c++/50474] GCC (cc1plus) hangs forever compiling with -O2 (-fcse-follow-jumps)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50474 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 10:46:06 UTC --- . *** This bug has been marked as a duplicate of bug 50380 ***
[Bug rtl-optimization/50380] cc1 hangs eating 100% CPU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50380 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 10:46:06 UTC --- *** Bug 50474 has been marked as a duplicate of this bug. ***
[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 10:48:15 UTC --- I don't think volatile union bitfield constitutes a volatile bitfield as per what GCC implements.
[Bug ada/50526] New: Assert_Failure sinfo.adb:717
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50526 Bug #: 50526 Summary: Assert_Failure sinfo.adb:717 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: baldr...@gcc.gnu.org $ gcc-4.7 -S p.ads +===GNAT BUG DETECTED==+ | 4.7.0 20110926 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure sinfo.adb:717| ... Testcase: -- chop here -- generic type T is tagged private; type A is access T'Class; package G is type NA is new A; end; with G; package P is type T is tagged null record; type A is access T'Class; package I is new G (T, A); end;
[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521 --- Comment #2 from Tomohiro Kashiwada kikairoya at gmail dot com 2011-09-26 11:42:37 UTC --- Variable 'bitfield' declared as volatile, so all bitfield's members are volatile. Even if declare 'bits' as volatile, gcc dumps same code. However, adding option -fno-strict-volatile-bitfields instead of -fstrict-volatile-bitfields, gcc ignores type of bit-field.
[Bug target/50465] [avr] Use insn attribute to depict if and how instruction lengths have to be adjusted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50465 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-26 11:53:55 UTC --- Author: gjl Date: Mon Sep 26 11:53:40 2011 New Revision: 179191 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179191 Log: PR target/50465 * config/avr/avr-protos.h (output_reload_insisf): Don't pass insn. * config/avr/avr.md (*reload_insi, *reload_insf): Change call to output_reload_insisf. (adjust_len): Set default to no. Remove alternative yes. Add alternatives: mov8, mov16, mov32, ashlqi, ashrqi, lshrqi, ashlhi, ashrhi, lshrhi, ashlsi, ashrsi, lshrsi. (*movqi, *movhi, *movsi, *ashlqi3, ashlhi3, ashlsi3, *ashlhi3_const, *ashlsi3_const, ashrqi3, ashrhi3, ashrsi3, *ashrhi3_const, *ashrsi3_const, *lshrqi3, lshrhi3, *lshrhi3_const, *lshrsi3_const): Set attribute adjust_len. * config/avr/avr.c (output_reload_insisf): Remove parameter insn. (output_movsisf): Don't pass insn to output_reload_insisf. (adjust_insn_length): Handle new alternatives to adjust_len. Remove handling of ADJUST_LEN_YES. Clean-up code. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug c++/50523] C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523 --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-26 12:07:55 UTC --- Created attachment 25366 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25366 testcase Reduced to ~560 lines. % g++ testcase.cpp -Wfatal-errors testcase.cpp: In instantiation of ‘BinaryNodeOp, Left, Right::BinaryNode(const Left, const Right) [with Op = OpSubtract, Left = ReferenceFieldNoMesh3, Vector3, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor , Right = ScalarVector3 ]’: testcase.cpp:318:123: required from ‘typename MakeFieldReturnBinaryNodeOpSubtract, typename CreateLeafFieldG1, T1, E1 ::Leaf_t, typename CreateLeafT2::Leaf_t ::Expression_t operator-(const FieldG1, T1, E1, const T2) [with G1 = NoMesh3, T1 = Vector3, E1 = ViewEngine3, IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor , T2 = Vector3, typename MakeFieldReturnBinaryNodeOpSubtract, typename CreateLeafFieldG1, T1, E1 ::Leaf_t, typename CreateLeafT2::Leaf_t ::Expression_t = FieldNoMesh3, Vector3, ExpressionTagBinaryNodeOpSubtract, ReferenceFieldNoMesh3, Vector3, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor , ScalarVector3]’ testcase.cpp:567:74: required from here testcase.cpp:34:83: error: conversion from ‘const ReferenceFieldNoMesh3, Vector3, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ’ to ‘const FieldNoMesh3, Vector3, ViewEngine3, IndexFunctionGenericURMMeshTraits3, double, UniformRectilinearTag, CartesianTag, 3 ::PositionsFunctor ’ is ambiguous compilation terminated due to -Wfatal-errors.
[Bug c++/26747] bad break/continue is not detected until the gimplifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26747 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot | |gnu.org, paolo.carlini at | |oracle dot com | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-26 12:11:54 UTC --- Thanks Manuel, I'll send a patch.
[Bug c++/50523] C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-26 12:14:13 UTC --- This testcase fails with all of 4.6, r178788 and r178789, so I doubt it is the right testcase for this bug. I'm running delta using a test if r178788 -fpermissive compiles it without errors and r178789 -fpermissive with errors, so far in 90 minutes reduced it from 2.8MB down to 1.9MB. So it will take a while.
[Bug target/50465] [avr] Use insn attribute to depict if and how instruction lengths have to be adjusted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50465 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-09-26 12:30:25 UTC --- Fixed now.
[Bug c++/50523] C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-26 12:31:32 UTC --- (In reply to comment #3) This testcase fails with all of 4.6, r178788 and r178789, so I doubt it is the right testcase for this bug. I'm running delta using a test if r178788 -fpermissive compiles it without errors and r178789 -fpermissive with errors, so far in 90 minutes reduced it from 2.8MB down to 1.9MB. So it will take a while. Hm, it succeeds (meaning it fails with a different error: error: ‘const class GridLayout3’ has no member named ‘innerDomain’) with 4.6.3 and 4.5.3 on my box.
[Bug regression/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 12:59:02 UTC --- Author: rguenth Date: Mon Sep 26 12:58:35 2011 New Revision: 179196 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179196 Log: 2011-09-26 Richard Guenther rguent...@suse.de PR tree-optimization/50472 * gimple-fold.c (fold_const_aggregate_ref_1): Do not fold volatile references. * gcc.dg/torture/pr50472.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr50472.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug c++/43734] cerr related segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-09-26 13:22:58 UTC --- Not easily, because I don't have an installed version with GNU ld around, and haven't figured out all the options necessary to compile and link with an uninstalled g++. That said, the example works just fine with g++ 4.4.2, 4.5.2, and 4.6.0 configured with Sun as and ld. A couple of comments on the configure options used: Configured with: ../gcc-4.4.3/configure --prefix=/usr/local/gcc-4.4.3 --disable-shared --enable-languages=c,c++ --enable-threads=posix Why --disable-shared? This may cause problems and isn't tested. --enable-__cxa_atexit --with-gnu-as --with-as=/usr/local/binutils-2.20.1/bin/as --enable-__cxa_atexit cannot work on Solaris. I'm working on a patch for the necessary libc support, but that will make it into Solaris 12 or a Solaris 11 update at the earliest. The option should be harmless, but is certainly useless. --with-gnu-ld --with-ld=/usr/local/binutils-2.20.1/bin/ld The installation guide strongly recomments using Sun ld on Solaris for a reason. Many patches necessary to improve the situation with GNU ld on Solaris only went into binutils 2.21, so I'd strongly suggest to retry with gld 2.21.1 if you really insist on using GNU ld. Rainer
[Bug c++/26747] bad break/continue is not detected until the gimplifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26747 --- Comment #8 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-09-26 13:52:04 UTC --- Author: paolo Date: Mon Sep 26 13:51:52 2011 New Revision: 179198 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179198 Log: 2011-09-26 Paolo Carlini paolo.carl...@oracle.com PR c++/26747 * cp-gimplify.c (get_bc_label): Remove obsolete diagnostics. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c
[Bug c++/43734] cerr related segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Resolution||WORKSFORME --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-26 13:55:08 UTC --- Thanks Rainer. I think you provided plenty of information about possible issues at submitter's end. Let's close this as worksforme.
[Bug c++/26747] bad break/continue is not detected until the gimplifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26747 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-26 13:56:33 UTC --- Done.
[Bug regression/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 14:09:04 UTC --- Author: rguenth Date: Mon Sep 26 14:08:53 2011 New Revision: 179200 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179200 Log: 2011-09-26 Richard Guenther rguent...@suse.de PR tree-optimization/50472 * tree-ssa-ccp.c (fold_const_aggregate_ref): Do not fold volatile references. * gcc.dg/torture/pr50472.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr50472.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-ccp.c
[Bug tree-optimization/50472] Volatile qualification in data is not enough to avoid optimization over pointer to data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50472 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|regression |tree-optimization Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 14:09:49 UTC --- Fixed for 4.6.2.
[Bug middle-end/50527] New: inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 Bug #: 50527 Summary: inconsistent vla align Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: vr...@gcc.gnu.org Created attachment 25367 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25367 testcase, modified from pr43513.c testcase To reproduce on x86_64: ... $ gcc -Os pr43513-align.c --param large-stack-frame=30 $ ./a.out 16byte aligned 7fff5c4ce00c ... The address of the vla is printed, and it's not 16-byte aligned (ends in 'c'). Nevertheless the test whether the address is 16-byte aligned succeeds, and the string '16byte aligned' is printed. During compilation the following scenario happens: - During the propagation of the first ccp phase, the align of the alloca (16) is progagated to the lhs results.0D.3306_13 as lattice value 'CONSTANT 0x0 (0xfff0)'. - This not propagated through 'D.3307_14 = *results.0D.3306_13'. The propagation does not look at the lattice value of results.0D.3306_13, but at the alignment of the ptr_info, which at this point is not initialised yet. - During the finalize of the first ccp phase, ptr_info of results.0D.3306_13 is initialized with align 16, based on the lattice value. - During the propagation of the second ccp phase, the align of the ptr_info of results.0D.3306_13 of 16 is used to propagate through to the comparison 'if (D.3309_16 == 0)', which makes sure the '16byte aligned' string is printed. - During the finalize of the second ccp phase, the alloca is folded, and the new declared array gets an align of 4 bytes.
[Bug c++/50523] C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org
|gnu.org |
--- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-09-26
14:42:39 UTC ---
Reduced:
template class T
struct A
{
A();
A(const A);
A(const T);
operator T() const;
operator const T() const;
};
int main()
{
Aint a;
Aint a2(a);
}
[Bug c++/50523] C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523 --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-26 14:47:22 UTC --- Just double-checked and a bisection with my testcase also leads to revision 178789: 98d1b25faaa16abc483251c9acf3cb1ef79cc941 is the first bad commit commit 98d1b25faaa16abc483251c9acf3cb1ef79cc941 Author: jason jason@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Sep 12 18:04:46 2011 + * call.c (convert_class_to_reference) (convert_class_to_reference_1): Remove. (reference_binding): Use build_user_type_conversion_1 instead. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@178789 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 15:00:49 UTC --- Hm, I suppose we should then make all replacement decls have BIGGEST_ALIGNMENT rather than min (BIGGEST_ALIGNMENT, object-size). Or alternatively (given we re-compute alignment together with folding alloca), assign the same alignment as folding would.
[Bug middle-end/50527] inconsistent vla align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC|rguenther at suse dot de|rguenth at gcc dot gnu.org --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-26 15:02:23 UTC --- The question is of course what standards say about the alignment of alloca (4).
[Bug c++/21057] iso C99 complex double: problems with g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21057 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org | Known to work||4.5.0 Resolution||FIXED Known to fail|| --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-26 15:12:58 UTC --- FWIW, this has been fixed for 4.5.x.
[Bug bootstrap/49804] [4.7 regression] 20110709 to 20110716 on sparc64 freebsd9.0 Configuration mismatch! [libgcc-extra-parts] Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49804 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|NEW CC||ro at gcc dot gnu.org Component|libobjc |bootstrap Target Milestone|--- |4.7.0 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2011-09-26 15:29:22 UTC --- This was indeed introduced by my libgcc patches. The ultimate fix is CFT: [build] Move crtstuff support to toplevel libgcc http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01273.html For the moment, you can just add crtbegin.o crtbeginS.o crtend.o crtendS.o to extra_parts in libgcc/config.host (sparc64-*-freebsd*|ultrasparc-*-freebsd*). I hope for the patch above to be approved RSN, so if you can wait for a couple of days, things should be fine. Sorry. Rainer
[Bug c++/50523] C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-09-26 15:47:27 UTC --- Author: jason Date: Mon Sep 26 15:47:17 2011 New Revision: 179203 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179203 Log: PR c++/50523 * call.c (implicit_conversion): Mask out inappropriate LOOKUP flags at the top of the function. Added: trunk/gcc/testsuite/g++.dg/overload/ref-conv2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50523] C++ FE apparently incorrectly rejects tramp3d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50523 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-09-26 15:51:15 UTC --- Fixed.
[Bug middle-end/50528] New: [4.7 Regression] SPEC CPU 2006 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50528 Bug #: 50528 Summary: [4.7 Regression] SPEC CPU 2006 failed to build with LTO Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 179164 failed to build 416.gamess, 447.dealII and 481.wrf with LTO. Failure is gfortran -O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU_LP64 ... lto1: internal compiler error: in account_size_time, at ipa-inline-analysis.c:601 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: gfortran returned 1 exit status /usr/local/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status Revision 179104 is OK.
[Bug fortran/50524] *** glibc detected *** invalid free() pointer on illegal code (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50524 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-09-26 16:45:25 UTC --- Here's a patch. Index: resolve.c === --- resolve.c(revision 179023) +++ resolve.c(working copy) @@ -4836,7 +4837,8 @@ resolve_ref (gfc_expr *expr) break; case REF_SUBSTRING: -resolve_substring (ref); +if (resolve_substring (ref) == FAILURE) + return FAILURE; break; }
[Bug c++/41995] Incorrect point of instantiation for function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.7.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-09-26 17:07:22 UTC --- Fixed by the patch for 29131. *** This bug has been marked as a duplicate of bug 29131 ***
[Bug c++/29131] [DR 225] Bad name lookup for templates due to fundamental types namespace for ADL.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||phresnel at gmail dot com --- Comment #19 from Jason Merrill jason at gcc dot gnu.org 2011-09-26 17:07:22 UTC --- *** Bug 41995 has been marked as a duplicate of this bug. ***
[Bug c/50444] unaligned movdqa instruction after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-09-26 17:24:47 UTC --- The problem is the wrong alignment for e-v in method. The initial RTL has (insn 17 16 18 4 (set (mem/s/j:V2DI (plus:DI (reg/v/f:DI 66 [ e ]) (const_int 40 [0x28])) [0 MEM[(struct Engine *)e_1(D) + 40B].m+0 S16 A128]) (reg:V2DI 68)) x.c:36 -1 (nil)) A128 is wrong.
[Bug c/50444] -ftree-isa ignores alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Summary|unaligned movdqa|-ftree-isa ignores |instruction after inlining |alignment --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-09-26 17:39:41 UTC --- -ftree-isa ignores alignment and generates: SR.11_17 = SR.10_18; MEM[(struct Engine *)e_1(D) + 40B].m = SR.11_17; ^^^ This is wrong.
[Bug middle-end/50528] [4.7 Regression] SPEC CPU 2006 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50528 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.7.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-09-26 17:45:59 UTC --- It is caused by revision 179126: http://gcc.gnu.org/ml/gcc-cvs/2011-09/msg00745.html
[Bug c++/50512] surprising change in overloading resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50512 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-09-26 17:55:12 UTC --- Author: jason Date: Mon Sep 26 17:55:04 2011 New Revision: 179208 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179208 Log: PR c++/50512 * call.c (compare_ics): Only consider rvaluedness_matches_p if the target type is the same or it too differs in rvalueness. Added: trunk/gcc/testsuite/g++.dg/overload/rvalue3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50512] surprising change in overloading resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50512 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-09-26 18:10:25 UTC --- Fixed.
[Bug c++/45487] Request to change comma to semicolon in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45487 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-09-26 18:12:01 UTC --- I'm open to this change.
[Bug debug/42288] please emit empty .debug_aranges section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Mark Wielaard mark at gcc dot gnu.org 2011-09-26 18:15:52 UTC --- Author: mark Date: Tue May 3 19:36:08 2011 New Revision: 173340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173340 Log: PR42288 emit empty .debug_aranges section. * dwarf2out.c (dwarf2out_finish): Always call output_aranges () when info_section_emitted. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug middle-end/50528] [4.7 Regression] SPEC CPU 2006 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50528 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-26 18:16:33 UTC --- Looks like overflow in the fixed point scalling code. Will look into that.
[Bug c++/46105] Ordering failure among partial specializations with non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46105 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-09-26 18:24:36 UTC --- It looks the same to me.
[Bug c++/45012] Invalid ambiguity on partial class specialization matching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45012 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||potswa at mac dot com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-26 18:28:15 UTC --- *** Bug 46105 has been marked as a duplicate of this bug. ***
