abled? Or emit a sibcall even if it had been
disabled? Since the problem stems that at sibcall_ok_for_function_p I
don't have enough information to know what to do, is there a way to
decide this later on?
Thanks,
--
Paulo Matos
On 15/02/2019 19:15, Jim Wilson wrote:
> On Thu, Feb 14, 2019 at 11:33 PM Paulo Matos wrote:
>> Are global variables not supposed to alias each other?
>> If I indeed do that, gcc still won't group loads and stores:
>> https://cx.rv8.io/g/rFjGLa
>
> I meant somethi
On 14/02/2019 19:56, Jim Wilson wrote:
> On 2/14/19 3:13 AM, Paulo Matos wrote:
>> If I compile this with -O2, sched1 groups all loads and all stores
>> together. That's perfect. However, if I change TYPE to unsigned char and
>> recompile, the stores and loads are inter
ependencies in sched-rgn.c is
a massive pain. This calls sched_analyze which receives a struct
deps_desc that tracks the dependencies in the insn list. Is there a way
to pretty print this structure in gdb?
Kind regards,
--
Paulo Matos
:) I think it's not impossible with all
that gcc provides, but there's certainly a fair amount of parsing of
these files, which is not ideal given their format might change under my
feet.
--
Paulo Matos
information per basic block so it's not helpful for my
application. It would be great if -dA or -dP would show live out info as
well, but that doesn't seem to be the case at the moment.
--
Paulo Matos
Apologies, wrong mailing list. Should have sent this to gcc-help.
On 06/11/2018 21:35, Paulo Matos wrote:
> Hi,
>
> I remember from awhile ago that there's some option (or there was...)
> that gets GCC to print some register allocation information together
> with the assembler ou
remember the option name
anymore. Can someone point me out to the option or a way to extract such
information?
Kind regards,
--
Paulo Matos
e to a different machine like gcc115
> or gcc116. As far as I know, they are identical.
>
Apologies for the clash on resources. Using gcc115 and gcc116 only now.
Kind regards,
--
Paulo Matos
but... if we wait for that to happen to implement
something... :)
> Send a pull request (I've turned on travis CI on the github repository,
> so pull requests now automatically get tested on a bunch of different
> Python 3 versions).
>
Sure.
--
Paulo Matos
vn and the old and new
revision numbers.
I have started implementing this in my port. Would you consider merging it?
--
Paulo Matos
l definitely get it integrated on Monday and hopefully have
something to say afterwards.
Thanks for keeping me up-to-date with these changes.
--
Paulo Matos
On 20/12/17 12:48, James Greenhalgh wrote:
> On Wed, Dec 20, 2017 at 10:02:45AM +0000, Paulo Matos wrote:
>>
>>
>> On 20/12/17 10:51, Christophe Lyon wrote:
>>>
>>> The recent fix changed the Makefile and configure script in libatomic.
>>> I gu
ilds should always call configure,
just in case.
Thanks,
--
Paulo Matos
On 15/12/17 10:21, Christophe Lyon wrote:
> On 15 December 2017 at 10:19, Paulo Matos <pmatos@linki.tools> wrote:
>>
>>
>> On 14/12/17 21:32, Christophe Lyon wrote:
>>> Great, I thought the CF machines were reserved for developpers.
>>> Good news yo
use all of gcc113..gcc116.
>
> We do not have enough resources to dedicate machines to bots.
>
I have disabled gcc116.
Thanks,
--
Paulo Matos
On 15/12/17 15:29, David Malcolm wrote:
> On Fri, 2017-12-15 at 10:16 +0100, Paulo Matos wrote:
>>
>> On 14/12/17 12:39, David Malcolm wrote:
>
> [...]
>
>>> It looks like you're capturing the textual output from "jv compare"
>>> and
>
On 15/12/17 10:21, Christophe Lyon wrote:
> And the patch was committed last night (r255659), so maybe your builds now
> work?
>
Forgot to mention that. Yes, it built!
https://gcc-buildbot.linki.tools/#/builders/5
--
Paulo Matos
this issue could be
raised with? FSF?
--
Paulo Matos
you are hitting a bug introduced recently, and fixed by:
> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00434.html
>
Wow, that's really useful. Thanks for letting me know.
--
Paulo Matos
.
> If you file pull request(s) for the changes you've made in your copy of
> jamais-vu, I can take at look at merging them.
>
Happy to do so...
Will merge your changes into my fork first then.
Kind regards,
--
Paulo Matos
regards,
--
Paulo Matos
hitectures and flavours as workers. We're
>> also
>> working with glibc community to improve it buildbot and to provide
>> workers
>> for builds on ppc.
>>
>> So, we'd like to know which platform you use for CI and how we can
>> contribute with it.
>>
, that's useful. I will take a look.
--
Paulo Matos
.c (test for errors, line )
>
> Actually, there are quite a few others like that
>
That actually surprised me.
I also see:
PASS: gcc.dg/Werror-13.c (test for errors, line )
PASS: gcc.dg/Werror-13.c (test for errors, line )
PASS: gcc.dg/Werror-13.c (test for errors, line )
PASS: gcc.dg/Werror-13.c (test for errors, line )
among others like it. Looks like a line number is missing?
In any case, it feels like the code I have to track this down needs to
be improved.
--
Paulo Matos
On 10/10/17 23:25, Joseph Myers wrote:
> On Tue, 10 Oct 2017, Paulo Matos wrote:
>
>> new test -> FAIL; New test starts as fail
>
> No, that's not a regression, but you might want to treat it as one (in the
> sense that it's a regression at the higher
On 11/10/17 06:17, Markus Trippelsdorf wrote:
> On 2017.10.10 at 21:45 +0200, Paulo Matos wrote:
>> Hi all,
>>
>> It's almost 3 weeks since I last posted on GCC Buildbot. Here's an update:
>>
>> * 3 x86_64 workers from CF are now installed;
>> * There's one
ts of the tests.
--
Paulo Matos
On 26/09/17 10:43, Martin Liška wrote:
> On 09/25/2017 02:49 PM, Paulo Matos wrote:
>> For benchmarks like Qt, blitz (as mentioned in the gcc testing page), we
>> can plot the build time of the benchmark and resulting size when
>> compiling for size.
>>
>
>
nks for the configuration file. I will take a look. Will eagerly wait
for news on the hardware request.
>
> Yes, duplication in way that it is (will be) same things. I'm adding author
> of the tool,
> hopefully we can unify the effort (and resources of course).
>
Great.
--
Paulo Matos
On 25/09/17 13:14, Jonathan Wakely wrote:
> On 25 September 2017 at 11:13, Paulo Matos wrote:
>>> Apart from that, I fully agree with octoploid that
>>> http://toolchain.lug-owl.de/buildbot/ is duplicated effort which is running
>>> on GCC compile farm mac
eir
configuration. However, found the one by gdb simpler and used it as a
basis for what I have. I will look at their builders nonetheless to
understand what they build and how long they take.
> Anyway, it's good starting point what you did and I'm looking forward to more
> common use of the tool.
> Martin
>
Thanks,
--
Paulo Matos
On 22/09/17 01:23, Joseph Myers wrote:
> On Thu, 21 Sep 2017, Paulo Matos wrote:
>
>> Interesting suggestion. I haven't had the opportunity to look at the
>> compile farm. However, it could be interesting to have a mix of workers:
>> native compile farm ones and
fort and waste of time. But of course, there are many
> more efficient gcc developers than me here :)
>
I think that's the point. I mean, as soon as a regression/build fail is
noticed, the buildbot should notify the right people of what happened
and those need to take notice and fix it or revert their patch. If
someone submits a patch, is notified it breaks GCC and does nothing,
then we have a bigger problem.
> Regarding the cpu power, maybe we could have free slots in
> some cloud? (travis? amazon?, )
>
Any suggestions on how to get these free slots? :)
Thanks for all the great suggestions and tips on your email.
--
Paulo Matos
opening bugs, or
> whatever else might get our attention).
>
This is certainly one of the notifications that I think that need to be
implemented. If a patch breaks build or testing, the responsible parties
need to be informed, i.e. commiters, authors and possibly the list as well.
Thanks,
--
Paulo Matos
t; can keep the false warnings as close to zero as possible.
>
Thanks. This is an interesting idea, however it might not be an easy
exercise to choose a subset of the tests for each compiled language that
PASS, are quick to run and representative. It would be interesting to
hear from some of the main developers which of the tests would be better
to run.
--
Paulo Matos
off that.
>
Yes, with GCC is slightly more complex but it should be possible to
calculate regressions even in the presence of non-zero FAILs.
Thanks for your comments,
--
Paulo Matos
On 21/09/17 01:01, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 20, 2017 at 05:01:55PM +0200, Paulo Matos wrote:
>> This mail's intention is to gauge the interest of having a buildbot for
>> GCC.
>
> +1. Or no, +100.
>
>> - which machines we can us
On 20/09/17 19:14, Joseph Myers wrote:
> On Wed, 20 Sep 2017, Paulo Matos wrote:
>
>> - buildbot can notify people if the build fails or if there's a test
>> regression. Notification can be sent to IRC and email for example. What
>> would people prefer to have as the se
vid pointed out in another email, I should have referenced the
buildbot homepage:
http://buildbot.net/
This is a framework with batteries included to build the kind of things
we want to have for testing. I certainly don't want to start a Jenkins
vs Buildbot discussion.
Kind regards,
--
Paulo Matos
,
--
Paulo Matos
ly and I will give it a try.
Cheers,
--
Paulo Matos
On 18/03/16 15:02, Jonathan Wakely wrote:
>
> It's probably crashing because it's too large, so if you reduce it
> then it won't crash.
>
Would be curious to see what's the limit though, or if it depends on the
machine he's running GCC on.
--
Paulo Matos
signature.asc
On 27/08/15 16:56, Paulo Matos wrote:
I noticed I am not on the list (check commit r225509, user pmatos) either.
And thanks for your help on this transition.
r188804 | mkuvyrkov ma...@codesourcery.com
for example.
--
Paulo Matos
not in the map. It contains
an entry for every distinct Unix username it could extract. What usernames
should I expect these people to have?
I noticed I am not on the list (check commit r225509, user pmatos) either.
And thanks for your help on this transition.
--
Paulo Matos
transition start?
--
Paulo Matos
-Original Message-
From: Andrew Haley [mailto:a...@redhat.com]
Sent: 28 July 2015 18:38
To: Paulo Matos; gcc@gcc.gnu.org
Subject: Re: Expectations for 0/0
On 07/28/2015 04:40 PM, Paulo Matos wrote:
The block skips the test for ((unsigned int) xx 1 == 0 yy == -
1), should we
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Paulo Matos
Sent: 29 July 2015 10:12
To: Andrew Haley; gcc@gcc.gnu.org
Subject: RE: Expectations for 0/0
-Original Message-
From: Andrew Haley [mailto:a...@redhat.com
be peculiar,
this division is also undefined.
The block skips the test for ((unsigned int) xx 1 == 0 yy == -1), should
we skip it if they're both zero as well? If not, what do you expect to get from
0/0 and 0%0?
Regards,
Paulo Matos
/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix
Is this what gcc --version returns on your mac?
Paulo Matos
On Sun, 10 May 2015 22:07:53 -0600, Jeff Law wrote:
On 05/10/2015 03:00 PM, Paulo Matos wrote:
Yes. This would fall under the obvious rule and can be committed
without waiting for approvals.
jeff
Thanks. Committed.
--
Paulo Matos
On Sun, 10 May 2015 21:08:04 +, Paulo Matos wrote:
Somehow I never added myself to the MAINTAINERS file.
Apologies for that. OK to commit?
2015-05-10 Paulo Matos pa...@matos-sorge.com
* MAINTAINERS: Add myself as commit after approval.
diff --git
Somehow I never added myself to the MAINTAINERS file.
Apologies for that. OK to commit?
2015-05-10 Paulo Matos pa...@matos-sorge.com
* MAINTAINERS: Add myself as commit after approval.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7dc4c8f..c5d6c99 100644
OK to commit?
2015-05-10 Paulo Matos pa...@matos-sorge.com
* configure.ac: Fix typo.
* configure: Regenerate.
diff --git a/configure b/configure
index a3f66ba..8ee279f 100755
--- a/configure
+++ b/configure
@@ -7423,7 +7423,7 @@ fi
# multilib
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Andi Kleen
Sent: 20 July 2014 22:29
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: GCC version bikeshedding
Paulo Matos pa...@matos-sorge.com writes:
That's what I understood
to use which sounded like a good idea.
Paulo Matos
Richard.
Jakub
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Basile Starynkevitch
Sent: 20 May 2014 16:29
To: Bruce Adams
Cc: gcc@gcc.gnu.org
Subject: Re: Roadmap for 4.9.1, 4.10.0 and onwards?
On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams wrote:
-Original Message-
From: Steven Bosscher [mailto:stevenb@gmail.com]
Sent: 05 May 2014 10:11
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: jump_table_data and active_insn_p
On Mon, Mar 17, 2014 at 12:51 PM, Paulo Matos wrote:
Why is jump_table_data an active_insn?
int
for bar as well since sizeof unsigned char is 1 and
sizeof enum xpto is 2, therefore the value is truncated but no warning is
issued.
Shall I open a PR?
Paulo Matos
-Original Message-
From: David Brown [mailto:da...@westcontrol.com]
Sent: 19 March 2014 14:44
To: Paulo Matos; gcc@gcc.gnu.org
Subject: Re: returning short-enum and truncate doesn't trigger
conversion warning
On 19/03/14 15:33, Paulo Matos wrote:
Hi all,
This is either a C
-Original Message-
From: David Brown [mailto:da...@westcontrol.com]
Sent: 19 March 2014 15:47
To: Paulo Matos; gcc@gcc.gnu.org
Subject: Re: returning short-enum and truncate doesn't trigger
conversion warning
Usually the discovery of bugs gets discussed on the help list
GET_CODE (PATTERN (insn)) != CLOBBER;
}
It is clear that someone [Steven Bosscher] thought it needs fixing but what's
the problem with just removing it from the OR-expression?
Cheers,
Paulo Matos
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 13 March 2014 18:46
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: RE: dom requires PROP_loops
On March 13, 2014 5:00:53 PM CET, Paulo Matos pma...@broadcom.com wrote:
-Original Message
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 11 March 2014 10:52
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: dom requires PROP_loops
On Mon, Mar 10, 2014 at 12:57 PM, Paulo Matos pma...@broadcom.com wrote:
Hello,
In an attempt
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 13 March 2014 13:24
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: dom requires PROP_loops
Probably RTL cfgcleaup needs the same treatment as GIMPLE cfgcleanup
then - allow removal if loop
property? Do you agree?
Cheers,
Paulo Matos
it
because -fshort-double brokeness on x86_64).
I have tested it and everything looks fine. I have now committed all the
code and testcase. Hopefully it's now sorted.
Thanks for your help,
Paulo Matos
Thanks,
Richard.
--
PMatos
) a22(r119,l0) a23(r114,l0) a24(r118,l0) a25(r117,l0)
a26(r113,l0) a28(r116,l0)
;; total conflict hard regs: 0 20-25
;; conflict hard regs: 0 20-25
Why is r122 conflicting with r0? r0 is dead in insn 21, I can't see a reason
for conflict.
Is there something I am missing?
Cheers,
Paulo
optimizations.
Should we mark it as such?
Cheers,
Paulo Matos
as an optimization?
I think we should.
I will submit a patch to gcc-patches.
Thanks,
--
Paulo Matos
On 06/03/2014 11:19, Richard Biener wrote:
I have reverted the patch for now.
Richard.
That's fine Richard, thanks. I got stuck with another issue in the
meantime but I will look at it again very soon.
--
Paulo Matos
. Paulo, please do that. Let's
do the alternate approach of marking -fshort-double eligible for LTO
as well and handle it there properly.
Sure, I will prepare a new patch and post it for approval by the end of
the day.
Apologies for the regression.
--
Paulo Matos
on the patch and its possible integration
into upstream (I guess it can only go upstream once 4.9 is released, right?).
I bootstrapped and tested x86_64-unknown-linux-gnu with no regressions.
Thanks,
Paulo Matos
simplify-using-context.patch
Description: simplify-using-context.patch
Since the owner of the repo http://gcc.gnu.org/git/?p=gcc.git;a=summary is
marked as being: gcc@gcc.gnu.org
moving this thread of the gcc mailing list.
Paulo Matos
-Original Message-
From: gcc-help-ow...@gcc.gnu.org [mailto:gcc-help-ow...@gcc.gnu.org] On Behalf
Of Paulo Matos
Sent: 04
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: 30 January 2014 15:50
To: Paulo Matos; Andreas Schwab
Cc: gcc@gcc.gnu.org
Subject: Re: Regression [v850,mep...]: sign_extend in loop breaks
zero-overhead
loop generation
OK, of course. Don't know what I am
,
Paulo Matos
-Original Message-
From: Andreas Schwab [mailto:sch...@linux-m68k.org]
Sent: 30 January 2014 14:29
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Regression [v850,mep...]: sign_extend in loop breaks
zero-overhead
loop generation
Paulo Matos pma...@broadcom.com writes
-Original Message-
From: Andreas Schwab [mailto:sch...@linux-m68k.org]
Sent: 30 January 2014 15:15
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Regression [v850,mep...]: sign_extend in loop breaks
zero-overhead
loop generation
Paulo Matos pma...@broadcom.com writes
hook is a way to
avoid ICE but as Richard S. mentioned it's more general to patch GCC up.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
2014-01-30 Paulo Matos pma...@broadcom.com
* simplify-rtx.c (simplify_subreg): Do not adjust address if memory
address has vector mode
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: 30 January 2014 12:43
To: Paulo Matos
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Vector mode addresses
Paulo Matos pma...@broadcom.com writes:
As a followup of the thread:
http
think it got lost. GCC was trying to simplify it. That's why my
patch was in simplify_subreg. GCC was trying to simplify a subreg in
DImode with this mem rtx as SUBREG_REG and offset 8.
--
Paulo Matos
called in
simplify_rtx but there's actually a mode_dependent_address_p in recog.c
and there is where you suggested to add the check _if_ vector modes are
supported. Got it.
I apologize for my misunderstanding and thank you for your patience.
--
Paulo Matos
Thanks,
Richard
On 30/01/14 20:47, Jakub Jelinek wrote:
On Thu, Jan 30, 2014 at 08:27:47PM +, Paulo Matos wrote:
Yes, it looks strange but it was the way we came up with to
implement an instruction that loads from a pair of addresses.
From what I wrote previously to Richard.
We have an instruction
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: 24 January 2014 16:34
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: ICE in trunk due to MEM with address in vector mode
Paulo Matos pma...@broadcom.com writes:
If we do support vector
(subreg:V2HI (match_dup 1) 0)
(const_int 8)))
(set (match_dup 0)
(rotate:SI (match_dup 0)
(const_int 16)))
Is there a better way to handle a situation like this?
Cheers,
Paulo Matos
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: 27 January 2014 16:06
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Mode change for bswap pattern expansion
Paulo Matos pma...@broadcom.com writes:
On a vector processor we can do a bswapsi
-Original Message-
From: Richard Sandiford [mailto:rsand...@linux.vnet.ibm.com]
Sent: 27 January 2014 16:50
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Mode change for bswap pattern expansion
Sorry, I meant we use an unspec for the first (V2HI) rotate.
I.e. rather than
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: 24 January 2014 10:46
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: ICE in trunk due to MEM with address in vector mode
Paulo Matos pma...@broadcom.com writes:
Hello,
I have found
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: 24 January 2014 12:21
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: ICE in trunk due to MEM with address in vector mode
Just in case: the point I was trying to make in the second paragraph
(op))
+ !VECTOR_MODE_P (GET_MODE (XEXP (op, 0
return adjust_address_nv (op, outermode, byte);
/* Handle complex values represented as CONCAT
Comments?
Paulo Matos
if GET_MODE_SIZE (from) GET_MODE_SIZE (to) but it
didn't help.
Any suggestions for a generic solution?
Paulo Matos
-Original Message-
From: Eric Botcazou [mailto:ebotca...@adacore.com]
Sent: 17 January 2014 16:23
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Avoiding paradoxical subregs
I can use canonicalize_comparison like s390 to remove the subreg, however
the question then becomes
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
Matos
Sent: 09 January 2014 16:48
To: Richard Biener
Cc: Andrew Haley; gcc@gcc.gnu.org; Jan Hubicka
Subject: RE: Infinite number of iterations in loop [v850, mep]
I would like some
else bb4
bb3:
r3 - r2 1
goto bb4
bb4:
...
...
if ... goto bb4 else bb5
Is there any way already implemented to find the value of (and (plus r1 r3)
(const_int 1)) at the end of bb4 and simplify it to (const_int 0)?
Cheers,
Paulo Matos
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: 14 January 2014 13:45
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Context dependent expression simplification
On Tue, Jan 14, 2014 at 01:40:36PM +, Paulo Matos wrote:
Before I start to write code
starts creating code like
this performance on my port drops drastically.
What are your thoughts?
Note: I just noticed this doesn't happen in trunk anymore. Any idea of what
went into trunk to fix this?
Paulo Matos
Paulo Matos
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 10 January 2014 13:25
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Useless statement in loop latch looks like performance regression
Most likely changes to SSA coalescing at out
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 08 January 2014 14:42
To: Paulo Matos
Cc: Andrew Haley; gcc@gcc.gnu.org; Jan Hubicka
Subject: Re: Infinite number of iterations in loop [v850, mep]
Well. We have
Loop 2 is simple:
simple exit
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 08 January 2014 14:42
To: Paulo Matos
Cc: Andrew Haley; gcc@gcc.gnu.org; Jan Hubicka
Subject: Re: Infinite number of iterations in loop [v850, mep]
On Wed, Jan 8, 2014 at 3:09 PM, Paulo Matos pma
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 08 January 2014 11:03
To: Paulo Matos
Cc: Andrew Haley; gcc@gcc.gnu.org
Subject: Re: Infinite number of iterations in loop [v850, mep]
That was refering to the case with extern b. For the above case
1 - 100 of 228 matches
Mail list logo
