Hello
I am a researcher from Jam Petrochemical company I want to use OpenACC with
GCC compiler(FORTRAN language). I have a question about your compiler.
I could not offload OpenACC computing block on AMD Radeon GPU!! and
OpenACC code run on the host(CPU).
How can I select AMD Radeon GPU as target
On 08/13/2018 03:13 AM, Jonathan Wakely wrote:
On Sun, 12 Aug 2018 at 15:59, zerons wrote:
Should gcc give it an error to prevent a structure from converting to
char* in functions printf/fprintf?
Your question is inappropriate on this mailing list, please use
gcc-help next time. See https:/
On Sun, 12 Aug 2018 at 15:59, zerons wrote:
> Should gcc give it an error to prevent a structure from converting to
> char* in functions printf/fprintf?
Your question is inappropriate on this mailing list, please use
gcc-help next time. See https://gcc.gnu.org/lists.html
Did you try compiling wit
Hi all,
As we know, gcc would give us an error message when we do this:
`struct _test a; char *s = a;`;
However, when we use this in printf/fprintf, it gets wired.
```c
#include
struct _test {
char name[256];
};
struct _test tests[100];
int main(int argc, char *argv[])
{
memcp
On Wed, 1 Aug 2018 at 01:32, Bramandia Ramadhana wrote:
>
> Hi,
>
> I am reading the gcc wiki page about atomic Acquire/Release memory
> model: https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync.
>
> It is mentioned:
>
> "Both of these asserts can pass since there is no ordering imposed
> between th
Hi,
I am reading the gcc wiki page about atomic Acquire/Release memory
model: https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync.
It is mentioned:
"Both of these asserts can pass since there is no ordering imposed
between the stores in thread 1 and thread 2.
If this example were written using the
On Fri, Dec 18, 2015 at 10:40:10PM +, Eric Christopher wrote:
> > >> Without -gsplit-dwarf, there is only one .debug_macro section.
> > >>
> > >
> > > Well, that's fascinating. My guess is something in objcopy is mangling.
> >
> > I did some digging last week. It seemed to me that each block of
On Fri, Dec 18, 2015 at 2:22 PM, Eric Christopher wrote:
>
>
> On Fri, Dec 18, 2015 at 2:20 PM Siva Chandra wrote:
>>
>> On Fri, Dec 18, 2015 at 2:17 PM, Eric Christopher
>> wrote:
>> > Does the object file without -gsplit-dwarf have multiple sections? If
>> > so,
>> > that should narrow it down
On Fri, Dec 18, 2015 at 2:17 PM, Eric Christopher wrote:
> Does the object file without -gsplit-dwarf have multiple sections? If so,
> that should narrow it down for you, otherwise it's really curious.
Without -gsplit-dwarf, there is only one .debug_macro section.
> On Fri, Dec 11, 2015 at 10:33
Hello,
When I compile my cc file with "-g3 -gsplit-dwarf", the resulting .dwo
file has multiple .debug_macro.dwo sections. Is that expected? I did
not find anything in the proposal which explains this:
http://www.dwarfstd.org/ShowIssue.php?issue=110722.1
Thanks,
Siva Chandra
age-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Nikolai Bozhenov
> Sent: Monday, September 14, 2015 2:28
> To: James Greenhalgh
> Cc: gcc@gcc.gnu.org
> Subject: Re: [AArch64] A question about Cortex-A57 pipeline description
>
> Thanks for
Thanks for the reply! I see you point. Indeed, I've also seen cases
where the
load pipeline was overused at the beginning of a basic block, whereas at
the end
the code got stuck with a bunch of stores and no other instructions to
run in
parallel. And indeed, relaxing the restrictions makes thing
On Fri, Sep 11, 2015 at 04:31:37PM +0100, Nikolai Bozhenov wrote:
> Hi!
>
> Recently I got somewhat confused by Cortex-A57 pipeline description in
> GCC and
> I would be grateful if you could help me understand a few unclear points.
Sure,
> Particularly I am interested in how memory operations
Hi!
Recently I got somewhat confused by Cortex-A57 pipeline description in
GCC and
I would be grateful if you could help me understand a few unclear points.
Particularly I am interested in how memory operations (loads/stores) are
scheduled. It seems that according to the cortex-a57.md file, fi
On 12/10/14 02:02, Ajit Kumar Agarwal wrote:
Right. After IRA was complete, I'd walk over the unallocated
allocnos and split their ranges at EBB boundaries. That created
new allocnos with a smaller ??>>conflict set and reduced the
conflict set for the original unallocated allocnos.
Jeff: In t
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jeff Law
Sent: Tuesday, December 09, 2014 11:26 PM
To: Vladimir Makarov; lin zuojian; gcc@gcc.gnu.org
Subject: Re: A Question About LRA/reload
On 12/09/14 10:10, Vladimir Makarov wrote:
> gener
Thanks Vladimir & Jeff & Kugan. Combining the replies I get a better
view of RA problem.
--
Lin Zuojian
On Tue, Dec 09, 2014 at 12:10:29PM -0500, Vladimir Makarov wrote:
> On 12/09/2014 04:37 AM, lin zuojian wrote:
> > Hi,
> > I have read ira/lra code for a while, but still fails to understand
On 12/09/14 14:48, shmeel gutl wrote:
On 09-Dec-14 07:56 PM, Jeff Law wrote:
On 12/09/14 10:10, Vladimir Makarov wrote:
generate the correct code in many cases even for x86. Jeff Law tried
IRA coloring reusage too for reload but whole RA became slower (although
he achieved performance improvem
On 09-Dec-14 07:56 PM, Jeff Law wrote:
On 12/09/14 10:10, Vladimir Makarov wrote:
generate the correct code in many cases even for x86. Jeff Law tried
IRA coloring reusage too for reload but whole RA became slower (although
he achieved performance improvements on x86).
Right. After IRA was com
On 12/09/14 10:10, Vladimir Makarov wrote:
generate the correct code in many cases even for x86. Jeff Law tried
IRA coloring reusage too for reload but whole RA became slower (although
he achieved performance improvements on x86).
Right. After IRA was complete, I'd walk over the unallocated all
On 12/09/2014 04:37 AM, lin zuojian wrote:
> Hi,
> I have read ira/lra code for a while, but still fails to understand
> their relationship. The main question is why ira do color so early?
> lra pass will do the assignment anyway. Sorry if I mess up coloring
> and hard register assi
On 09/12/14 21:14, lin zuojian wrote:
> Hi Kugan,
> I have read these pdfs. My question is LRA will change the insns, so
> why brother do the coloring so early. Changing the insns can
> generates new pseudo registers, so they needs to re-assign. Is that
> correct?
Hi,
IRA's job he
Moreover, LRA assignment does not refer to the assignment result of ira
directly. In find_hard_regno_for, the value of hard_regno comes from
ira_class_hard_regs[rclass][i] with least cost.
On Tue, Dec 09, 2014 at 06:14:29PM +0800, lin zuojian wrote:
> Hi Kugan,
> I have read these pdfs. My qu
Hi Kugan,
I have read these pdfs. My question is LRA will change the insns, so
why brother do the coloring so early. Changing the insns can
generates new pseudo registers, so they needs to re-assign. Is that
correct?
--
Thanks Kugan
On Tue, Dec 09, 2014 at 09:08:46PM +1100, Kugan w
On 09/12/14 20:37, lin zuojian wrote:
> Hi,
> I have read ira/lra code for a while, but still fails to understand
> their relationship. The main question is why ira do color so early?
> lra pass will do the assignment anyway. Sorry if I mess up coloring
> and hard register assignmen
Hi,
I have read ira/lra code for a while, but still fails to understand
their relationship. The main question is why ira do color so early?
lra pass will do the assignment anyway. Sorry if I mess up coloring
and hard register assignment, but I think it's better to get job
done a
On Mon, Nov 5, 2012 at 10:13 PM, Kenneth Zadeck
wrote:
> On 11/05/2012 03:37 PM, Joseph S. Myers wrote:
>>
>> On Mon, 5 Nov 2012, Kenneth Zadeck wrote:
>>
>>> This switch to doing math within the precision causes many test cases to
>>> behave differently. However, I want to know if differently m
On 11/05/2012 03:37 PM, Joseph S. Myers wrote:
On Mon, 5 Nov 2012, Kenneth Zadeck wrote:
This switch to doing math within the precision causes many test cases to
behave differently. However, I want to know if differently means
"incorrectly" or "I have fixed problems that we have just decided
On Mon, 5 Nov 2012, Kenneth Zadeck wrote:
> This switch to doing math within the precision causes many test cases to
> behave differently. However, I want to know if differently means
> "incorrectly" or "I have fixed problems that we have just decided to live
> with".
As far as I know, the TREE
On 11/05/2012 01:08 PM, Ian Lance Taylor wrote:
On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck
wrote:
The question is why is having a case label of 256 on a unsigned char switch
legal?
Are you asking why it is valid in the C language? Or are you asking
why it is valid in GIMPLE? I guess th
On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck
wrote:
>
> The question is why is having a case label of 256 on a unsigned char switch
> legal?
Are you asking why it is valid in the C language? Or are you asking
why it is valid in GIMPLE? I guess the first question is fairly
obvious so you are
i have been trying to change the representation of INT_CSTs so that they
do not carry around the limitation that they can only represent numbers
as large as 2 host_wide_ints (HWI). I have chosen a variable length
implementation that uses an array of HWIs that is just large enough to
hold the s
On Tue, May 22, 2012 at 8:04 PM, Jiangning Liu wrote:
> Richard,
>
> But MODES_TIEABLE_P is a macro hook and isn't exposed to TREE level, so I
> would have to modify xxx-protos.h for all back-ends.
As far as I can tell it is exposed already to the middle-end via that
hook in that you should be ab
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, May 22, 2012 6:36 PM
> To: Jiangning Liu
> Cc: Zdenek Dvorak; Jiangning Liu; gcc@gcc.gnu.org
> Subject: Re: A question about loop ivopt
>
> On Tue, May 22, 2012 at
On Tue, May 22, 2012 at 11:19 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: Tuesday, May 15, 2012 10:17 PM
>> To: Zdenek Dvorak
>> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, May 15, 2012 10:17 PM
> To: Zdenek Dvorak
> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu
> Subject: Re: A question about loop ivopt
>
> On Tue, May 15, 2012 a
On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak wrote:
> Hi,
>
>> > > > Why can't we replace function force_expr_to_var_cost directly with
>> function
>> > > > computation_cost in tree-ssa-loop-ivopt.c?
>> > > >
>> > > > Actually I think it is inaccurate for the current recursive algorithm
>> in
>>
Hi,
> > > > Why can't we replace function force_expr_to_var_cost directly with
> function
> > > > computation_cost in tree-ssa-loop-ivopt.c?
> > > >
> > > > Actually I think it is inaccurate for the current recursive algorithm
> in
> > > > force_expr_to_var_cost to estimate expr cost. Instead
> co
Hi,
> > Why can't we replace function force_expr_to_var_cost directly with function
> > computation_cost in tree-ssa-loop-ivopt.c?
> >
> > Actually I think it is inaccurate for the current recursive algorithm in
> > force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
> > cou
On Tue, May 15, 2012 at 7:05 AM, Jiangning Liu wrote:
> Hi,
>
> Why can't we replace function force_expr_to_var_cost directly with function
> computation_cost in tree-ssa-loop-ivopt.c?
>
> Actually I think it is inaccurate for the current recursive algorithm in
> force_expr_to_var_cost to estimate
Hi,
Why can't we replace function force_expr_to_var_cost directly with function
computation_cost in tree-ssa-loop-ivopt.c?
Actually I think it is inaccurate for the current recursive algorithm in
force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
count some back-end factor
On Tue, 2012-02-28 at 11:52 -0600, William J. Schmidt wrote:
> On Tue, 2012-02-28 at 11:03 -0600, William J. Schmidt wrote:
>
> > I think this is probably a problem with how cprop_into_successor_phis
> > works. It only propagates into immediate successors of a block. In
> > this case copies ar
On Tue, 2012-02-28 at 11:03 -0600, William J. Schmidt wrote:
> I think this is probably a problem with how cprop_into_successor_phis
> works. It only propagates into immediate successors of a block. In
> this case copies are propagated from bb12 into phis in bb13 and bb14 (of
> which there are n
Liu; 'William J. Schmidt'
> >> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> >> Subject: RE: A question about redundant PHI expression stmt
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: gcc-ow...@gcc.gnu.or
On Tue, Feb 28, 2012 at 9:33 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Jiangning Liu
>> Sent: Tuesday, February 28, 2012 4:07 PM
>> To: Jiangning Liu; 'William J. Schmidt'
>> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> -Original Message-
> From: Jiangning Liu
> Sent: Tuesday, February 28, 2012 4:07 PM
> To: Jiangning Liu; 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question about redundant PHI expression stmt
>
>
>
> &g
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Tuesday, February 28, 2012 11:19 AM
> To: 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question abou
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> William J. Schmidt
> Sent: Monday, February 27, 2012 11:32 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: Re: A question about redundan
On Fri, 2012-02-24 at 16:07 +0800, Jiangning Liu wrote:
> Hi,
>
> For the small case below, there are some redundant PHI expression stmt
> generated, and finally cause back-end generates redundant copy instructions
> due to some reasons around IRA.
>
> int *l, *r, *g;
> void test_func(int n)
> {
On Fri, Feb 24, 2012 at 9:07 AM, Jiangning Liu wrote:
> Hi,
>
> For the small case below, there are some redundant PHI expression stmt
> generated, and finally cause back-end generates redundant copy instructions
> due to some reasons around IRA.
>
> int *l, *r, *g;
> void test_func(int n)
> {
>
Hi,
For the small case below, there are some redundant PHI expression stmt
generated, and finally cause back-end generates redundant copy instructions
due to some reasons around IRA.
int *l, *r, *g;
void test_func(int n)
{
int i;
static int j;
static int pos, direction, di
On Fri, Nov 18, 2011 at 2:07 AM, Yuehai Du wrote:
> 2011/11/18 Richard Guenther :
>> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du wrote:
>>> 2011/11/17 Richard Guenther :
On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou
wrote:
>> Huh, IVOPTs should never cause a different size memory
2011/11/18 Richard Guenther :
> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du wrote:
>> 2011/11/17 Richard Guenther :
>>> On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou
>>> wrote:
> Huh, IVOPTs should never cause a different size memory read. I wonder
> if the original issue would still r
On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou wrote:
>> Huh, IVOPTs should never cause a different size memory read. I wonder
>> if the original issue would still reproduce with the fix reverted.
>
> The original issue was unaligned arrays in packed structures. I don't see
> what
> could have
Hi,
On Wed, 16 Nov 2011, Jeff Law wrote:
> Right. In theory, path isolation would make this optimizable. Make a
> copy of the block containing a[x] = 2 and make it the target when x !=
> 100. At the source level it'd look something like this:
>
> int x;
> extern void f(void);
>
> void g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/16/11 04:00, Richard Guenther wrote:
> On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu
> wrote:
>> Hi,
>>
>> For this test case,
>>
>> int x; extern void f(void);
>>
>> void g(int *a) { a[x] = 1; if (x == 100) f(); a[x] = 2; }
>>
>> For trunk
Hi,
On Wed, 16 Nov 2011, Eric Botcazou wrote:
> > f() may change the value of x, so you cannot optimize away the load on that
> > execution path.
>
> This looks more like an aliasing issue with a, doesn't it?
Correct. There's no call to f() between a[x] and x==100, but the store to
a[x] might
> f() may change the value of x, so you cannot optimize away the load on that
> execution path.
This looks more like an aliasing issue with a, doesn't it?
--
Eric Botcazou
> Huh, IVOPTs should never cause a different size memory read. I wonder
> if the original issue would still reproduce with the fix reverted.
The original issue was unaligned arrays in packed structures. I don't see what
could have changed since then.
--
Eric Botcazou
On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu wrote:
> Hi,
>
> For this test case,
>
> int x;
> extern void f(void);
>
> void g(int *a)
> {
> a[x] = 1;
> if (x == 100)
> f();
> a[x] = 2;
> }
>
> For trunk, the x86 assembly code is like below,
>
> movl
On Mon, Nov 14, 2011 at 4:58 AM, Yuehai Du wrote:
> Hi
>
> i found IVOPTS didn't work well on some case if the loop contain
> some unaligned access. it didn't take this kind of memory access into
> account because this check in function:find_interesting_uses_address
>
> /* Moreover, on stric
From tree dump we can see that there are two assignments from x, one
to unsigned and one to signed. I guess that's the reason. Apparently
there is room to improve though.
int prephitmp.8;
int * D.2027;
unsigned int D.2026;
unsigned int x.1;
int x.0;
# BLOCK 2 freq:1
# PRED: ENTR
Hi,
For this test case,
int x;
extern void f(void);
void g(int *a)
{
a[x] = 1;
if (x == 100)
f();
a[x] = 2;
}
For trunk, the x86 assembly code is like below,
movlx, %eax
movl16(%esp), %ebx
movl$1, (%ebx,%eax,4)
Hi
i found IVOPTS didn't work well on some case if the loop contain
some unaligned access. it didn't take this kind of memory access into
account because this check in function:find_interesting_uses_address
/* Moreover, on strict alignment platforms, check that it is
sufficiently a
> I appreciate any advise of how to resolve this -- should I add
>
> (*fun) (&XEXP (dest, 0), data); ?
Actually I don't see why not - a zero_extract on the LHS of an
expression is supposed to be a bit field insert on that register.
Isn't there an implicit read of the destination register involved
Hello,
I am trying to extract the regsiter uses in instructions using note_uses
function. When encountering the following instruction I do not get r479
as a use; seemingly because of the following in note_use function:
if (GET_CODE (dest) == ZERO_EXTRACT)
{
(*fun) (&X
On Monday 26 September 2011, Matthew Gretton-Dann wrote:
> 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 ca
...@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 acce
;; '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
>&g
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-
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 "<=".
Rig
>AFAIK SMS will not do speculative memory access.
Right, SMS does no speculative memory access. Though that might not be
a bad idea...
Ayal.
2011/8/11 Revital Eres
>
> Hello,
>
> >> I appriciate explanation regarding the following piece of code in
> >> sched_analyze_insn function (sched-deps.c)
Hello,
>> I appriciate explanation regarding the following piece of code in
>> sched_analyze_insn function (sched-deps.c): When handling jump instruction
>> dependence edges are created between the jump instruction and memory
>> writes and volatile reads and I'm not quite sure the reason why.
>
>
Revital Eres writes:
> I appriciate explanation regarding the following piece of code in
> sched_analyze_insn function (sched-deps.c): When handling jump instruction
> dependence edges are created between the jump instruction and memory
> writes and volatile reads and I'm not quite sure the reaso
Hello,
I appriciate explanation regarding the following piece of code in
sched_analyze_insn function (sched-deps.c): When handling jump instruction
dependence edges are created between the jump instruction and memory
writes and volatile reads and I'm not quite sure the reason why.
Thanks,
Revital
Hello,
I wonder how the instruction scheduler deals with debug_insn?
Looking at how SMS handles notes I wonder if this mechanism is adopted to
handle debug_insn in other schedulers: notes are ignored during the
scheduling procedure
and are carefully placed before the instruction that follow them
Hi,
On Sat, 26 Mar 2011, Levon Haykazyan wrote:
> I was trying to configure vim to work better with gcc coding
> conventions. When I set 'tab' symbol to be interpreted as 2 spaces, I
> noticed that a lot of formatting in e.g. gcc/cp/parser.c was gone.
Yeah, never change tabstop, change shiftwi
Hi everybody,
I was trying to configure vim to work better with gcc coding conventions.
When I set 'tab' symbol to be interpreted as 2 spaces, I noticed that a lot
of formatting in e.g. gcc/cp/parser.c was gone. A bit of research showed
that in a lot of places 'tab' was used for 8 spaces. I've
On Fri, 12 Nov 2010, Joern Rennecke wrote:
Please read the node "Register Classes" in doc/tm.texi .
I am sorry , could you please highlight the relevant portion for me?
In the pattern that i have given the combination (a,W) satisfies the
pattern. But its not matched because i have given then lik
0:37
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: RE: A question about using restrict
>
> Hello Bingfeng,
>
> Thanks for your reply! I would be very interested to try your patch.
>
> Revital
>
>
>
>
> From: "Bingfeng Mei"
> To: Revital
Hello Bingfeng,
Thanks for your reply! I would be very interested to try your patch.
Revital
From: "Bingfeng Mei"
To: Revital1 Eres/Haifa/i...@ibmil, "gcc@gcc.gnu.org"
Date: 13/12/2010 12:20 PM
Subject: RE: A question about using restrict
13 December 2010 07:59
> To: gcc@gcc.gnu.org
> Cc: Bingfeng Mei
> Subject: A question about using restrict
>
>
> Hello,
>
> I have the loop below and I want to pass to gcc that src1 and src2
> never
> alias with dst; so I used the restrict keyword as below; how
Hello,
I have the loop below and I want to pass to gcc that src1 and src2 never
alias with dst; so I used the restrict keyword as below; however I still
see that there are dependence edges between dst and src1 and src2 in
the DDG created by SMS and I wonder how can I resolve this.
(I used GCC -v1
Quoting Dave Korn :
Had a good look through and still couldn't find it, would you mind
giving me
a pointer to where should I start reading?
reload.c line 4094 (as of revision 18)
On 12/11/2010 16:06, Joern Rennecke wrote:
> Quoting Dave Korn:
>
>> Is that documented anywhere? I couldn't find it in the constraints
>> chapters of the internals manual.
>
> It's in the reload source code...
Had a good look through and still couldn't find it, would you mind giving me
a poi
Quoting Dave Korn :
Is that documented anywhere? I couldn't find it in the
constraints chapters
of the internals manual.
It's in the reload source code...
And there are subtle register priority implications of having merged or
separate alternatives.
Sorry, is this separate from the
On 12/11/2010 15:32, Joern Rennecke wrote:
> Quoting Dave Korn :
>
>> By "combine constraints", you mean "Omit all the commas between
>> alternatives, mash them together in a single string, and expect GCC
>> to permute
>> all the possible combinations"?
>>
>> I didn't know that was possible a
Quoting Dave Korn :
By "combine constraints", you mean "Omit all the commas between
alternatives, mash them together in a single string, and expect GCC
to permute
all the possible combinations"?
I didn't know that was possible at all. I thought GCC would
interpret those
as multi-le
On 12/11/2010 12:51, Mohamed Shafi wrote:
> All the constraints are one letter constraints for my target. Here 'W'
> is for symbol_ref and all others are register constraints. So for a
> particular combination when operand 0 is 'a' and operand 1 is 'W' i
> got the following ICE :
> I get this ICE
Quoting Mohamed Shafi :
On 12 November 2010 18:39, Joern Rennecke wrote:
Quoting Mohamed Shafi :
So i have the following questions:
1. Why is that constraints are not matched here?
Please read the node "Register Classes" in doc/tm.texi .
I am sorry , could you please highlight the rele
On 12 November 2010 18:39, Joern Rennecke wrote:
> Quoting Mohamed Shafi :
>
>> So i have the following questions:
>>
>> 1. Why is that constraints are not matched here?
>
> Please read the node "Register Classes" in doc/tm.texi .
>
I am sorry , could you please highlight the relevant portion for
Quoting Mohamed Shafi :
So i have the following questions:
1. Why is that constraints are not matched here?
Please read the node "Register Classes" in doc/tm.texi .
Hi,
For a private target that i am porting in GCC 4.5 I have the following
pattern in my md file for call value:
(define_insn "call_value_op"
[(set (match_operand 0 "register_operand" "=da")
(call (mem:QI (match_operand:QI 1 "call_operand" "Wd"))
(match_operand:QI 2 "" ""
On Mon, Aug 23, 2010 at 02:46:21PM +0300, Revital1 Eres wrote:
> I'm compiling the following test with GCC 4.6.0 and I do not see that
> MAX_EXPR is generated for (num)<0)?0:(num).
> With GCC 4.3.2 it is generated OK in original dump (both compilation were
> made with -O3). Is there a flag I shoul
Hello,
I'm compiling the following test with GCC 4.6.0 and I do not see that
MAX_EXPR is generated for (num)<0)?0:(num).
With GCC 4.3.2 it is generated OK in original dump (both compilation were
made with -O3). Is there a flag I should use to generate MAX_EXPR
with GCC 4.6.0?
Thanks,
Revital
#
On Mon, 26 Jul 2010, Revital1 Eres wrote:
>
> Hello,
>
> Doloop optimization fails to be applied on the following kernel from
> tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite
> iteration
> case' message; taken from the loop2_doloop dump. (please see below).
> With an older
Hello,
Doloop optimization fails to be applied on the following kernel from
tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite
iteration
case' message; taken from the loop2_doloop dump. (please see below).
With an older version of gcc (-r 146278) doloop succeeded to be applied
an
On 07/13/2010 12:20 PM, Mingming Sun wrote:
On Tue, Jul 13, 2010 at 12:17 PM, Jie Zhang wrote:
On 07/13/2010 11:56 AM, Mingming Sun wrote:
I want to submit a patch about loongson 3A, a new architecture
different from loongson 2E&2F.
My patch is based on Gcc4.4.0.
If I want to submit my pat
Do you mean I must submit it to the main brach?
On Tue, Jul 13, 2010 at 12:17 PM, Jie Zhang wrote:
> On 07/13/2010 11:56 AM, Mingming Sun wrote:
>>
>> Hi,
>>
>> I want to submit a patch about loongson 3A, a new architecture
>> different from loongson 2E& 2F.
>> My patch is based on Gcc4.4.0.
>>
On 07/13/2010 11:56 AM, Mingming Sun wrote:
Hi,
I want to submit a patch about loongson 3A, a new architecture
different from loongson 2E& 2F.
My patch is based on Gcc4.4.0.
If I want to submit my patch, which branch shoud I submit to, gcc4.4.0
branch or I should change the patch to
suite with
1 - 100 of 275 matches
Mail list logo
