> -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
>
> O
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 ca
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 othe
-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
>>>
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
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
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 appl
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
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
> n
"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
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
>>> ./sr
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 restrict
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
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 imp
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
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 ap
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 SCo
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
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
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:
>> >
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
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
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
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
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
(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 tabu
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
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
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
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 i
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, ma
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
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...
O
> > * 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,
> >
>
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
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 y
36 matches
Mail list logo
