ed,
even if the sibcall was enabled? 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 so
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
ebugging compute_block_dependencies 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
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
out 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 assembl
can't 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
ne using pysvn and the old and new
revision numbers.
I have started implementing this in my port. Would you consider merging it?
--
Paulo Matos
t
so I will 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
emental builds 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 wrote:
>>
>>
>> On 14/12/17 21:32, Christophe Lyon wrote:
>>> Great, I thought the CF machines were reserved for developpers.
>>> Good news you could add builders on
y not 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
o you know who this issue could be
raised with? FSF?
--
Paulo Matos
spect 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
much time implementing it, so I thought parsing the output
was just easier.
> 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
pdate in about a months time.
Kind regards,
--
Paulo Matos
eral ppc architectures 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
>> cont
, that's useful. I will take a look.
--
Paulo Matos
t; PASS: gcc.dg/Werror-13.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
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;
>> * T
otify on the #gcc channel the results 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.
>>
>
>
#x27;ll inform you.
>
Thanks 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 machin
at one point tried to read their
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 one
ix it myself. Except for the most trivial ones, it resulted several times
> in duplicated effort 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
(or 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
ou
> 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
7;re a long way 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 c
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 t
As David 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
ented.
Kind regards,
--
Paulo Matos
irectly 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.
--
Pau
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
for example.
--
Paulo Matos
the latest transition start?
--
Paulo Matos
pect 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
> -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-
> -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 ((unsig
our division routine might 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
with:
> --prefix=/Applications/Xcode.app/Contents/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
> -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 writes:
> >
>
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
should be done outside of cc1. Other people have
thought about it and what you suggest is exactly the example found in OpenTuner
(http://opentuner.org/) announcement paper:
http://dspace.mit.edu/handle/1721.1/81958
The difference is that you don't compare .s files but instead choose the metric
based on the execution of the program on a test bench.
HTH,
Paulo Matos
> -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:
>
> -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
> -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 wr
^
I was expecting a warning 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
) != USE
&& 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 wrote:
> >> ---
> -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 cfgcleanu
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 13 March 2014 11:21
> To: Richard Biener
> Cc: gcc@gcc.gnu.org
> Subject: RE: dom requires PROP_loops
>
>
> PROP_loops is enabled from tree
> -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 wrote:
> > Hello,
property? Do you agree?
Cheers,
Paulo Matos
) a21(r120,l0) 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 missin
as an optimization?
I think we should.
I will submit a patch to gcc-patches.
Thanks,
--
Paulo Matos
optimizations.
Should we mark it as such?
Cheers,
Paulo Matos
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
>
> &
> -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
>
>
> -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
>
> Pa
s not in mainline.
Does anyone understand why the mentioned patch is forcing the generation of the
sign extend inside the loop? Is this just a problem with cost calculation in
the backends or some issue lurking in tree-ssa-loop-ivopts?
Thanks,
Paulo Matos
> -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 firs
> -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 writes:
> > On a vector processo
ong these lines:
(set (subreg:V2HI (match_dup 0) 0)
(rotate:V2HI (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: 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 writes:
> >> If we
> -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 tryi
> -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 writes:
> > Hello,
amp;& GET_MODE_SIZE (outermode) <= GET_MODE_SIZE (GET_MODE (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
> -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, ho
GET_MODE_SIZE (from) < GET_MODE_SIZE (to) but it
didn't help.
Any suggestions for a generic solution?
Paulo Matos
> -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,
> -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 wrot
goto bb3 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
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 c
ormance 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
> -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
> -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 ha
> -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 ha
> -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
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
> Matos
> Sent: 13 November 2013 16:14
> To: Andrew Haley
> Cc: gcc@gcc.gnu.org
> Subject: RE: Infinite number of iterations in loop [v850, mep]
>
> > -
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: 28 November 2013 11:27
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: reg_nonzero_bits_for_combine misunderstood
>
> > Right, didn't notice nonzero_sign_valid
> -Original Message-
> From: Eric Botcazou [mailto:ebotca...@adacore.com]
> Sent: 27 November 2013 18:27
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: reg_nonzero_bits_for_combine misunderstood
>
> > But the problem is that if the mode of the regis
}
+ else if (GET_MODE_CLASS (rsp->last_set_mode) == MODE_INT
+ && GET_MODE_CLASS (mode) == MODE_INT
+ && GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION
(mode))
+return NULL;
tem = get_last_value (x);
Fixed the problem. Any comments?
If you have no comments and like the patch I will submit it formally to
gcc-patches.
Paulo Matos
de on
our machine? I am quite confused about what fault it could happen in
BIGGEST_ALIGNMENT is violated, therefore for our machine I guess
BIGGEST_ALIGNMENT can be as high as possible.
Paulo Matos
Paulo Matos
> -Original Message-
> From: Alan Modra [mailto:amo...@gmail.com]
> Sent: 22 November 2013 04:42
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: rs6000: load_multiple code
>
> On Wed, Nov 20, 2013 at 05:06:13PM +, Paulo Matos wrote:
&
definitely missing something.
Can someone please clarify?
Paulo Matos
> -Original Message-
> From: Andrew Haley [mailto:a...@redhat.com]
> Sent: 13 November 2013 15:56
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: Infinite number of iterations in loop [v850, mep]
>
> On 11/13/2013 03:48 PM, Paulo Matos wrote:
>
> Bec
e higher than 'a' (unsigned int) and the loop can't possibly be
infinite.
Does anybody know why GCC is behaving this way?
Paulo Matos
1 - 100 of 182 matches
Mail list logo