Hi,
In revision 229402, I added logic in loop-invariant.c to check if a
look invariant can be forward propagated to memory references in the
same loop; and increase loop invariant cost if the answer is no. I
think this is a reasonable change. Some targets like AArch64 can
benefit from it because
Hi!
I would like to solve "Bug 17896 - The expression (a>0 & b>0) should
give clearer warning message (-Wparentheses)"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896) but I am new to
gcc internals.
Can someone please guide me how to do it?
--
Thanks and Regards,
Prasad Ghangal
On 01/25/2016 11:42 AM, Bin.Cheng wrote:
Yuri Rumyantsev suggested we may add a hook to handle GOT related
instruction propagation specially so it won't be hoisted out. Is a
hook at this stage sounds feasible?
I think that would be a mistake. ISTM this really needs to be cost driven.
Also
On 01/25/2016 08:51 PM, Jeff Law wrote:
No, the combiner works within a basic block only. There was a group, I
believe in Moscow, that worked on a cross-block combiner. It was
discussed at the Cauldron in California a few years back. I don't know
if they did any further work on those ideas.
I
On 01/25/2016 10:15 PM, Prasad Ghangal wrote:
> Hi!
>
> I would like to solve "Bug 17896 - The expression (a>0 & b>0) should
> give clearer warning message (-Wparentheses)"
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896) but I am new to
> gcc internals.
>
> Can someone please guide me how
On 26 January 2016 at 00:45, Prasad Ghangal wrote:
> Hi!
>
> I would like to solve "Bug 17896 - The expression (a>0 & b>0) should
> give clearer warning message (-Wparentheses)"
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17896) but I am new to
> gcc internals.
>
> Can someone please guide me
Hello gcc developers,
as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
forwarded as PR c/69221), ghc generates non-compliant C code that is not
compiled as intended on m68k. This is because its internal Cmm (a C--
dialect) to C compiler needs to declare external functions (no var
On 25 January 2016 at 20:17, Mikhail Maltsev wrote:
> As I understand, the bug report suggests that we say "suggest || instead of |
> when joining booleans" instead. We now have the API to show fix-it hints, so
> it
> would be nice to output something like
>
> test.c:17:21: warning: suggest || in
Andreas Arnez writes:
> 6 Summary of Open Questions
> ===
>
> 1. Out of the standard interpretations discussed under "options"
> (section 4) above, which do we want to settle on? Or is the
> "preferred" interpretation missing from that list?
> 2. Should piec
Michael Karcher writes:
> but it fixes the return type to some pointer type.
Why does it do that?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Mon, 2016-01-25 at 21:54 +, Manuel López-Ibáñez wrote:
> On 25 January 2016 at 20:17, Mikhail Maltsev wrote:
> > As I understand, the bug report suggests that we say "suggest || instead of
> > |
> > when joining booleans" instead. We now have the API to show fix-it hints,
> > so it
> > wo
On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher
wrote:
>Hello gcc developers,
>
>as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
>forwarded as PR c/69221), ghc generates non-compliant C code that is
>not
>compiled as intended on m68k. This is because its internal Cmm
On 01/26/2016 12:01 AM, Richard Biener wrote:
On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher
wrote:
Hello gcc developers,
as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
forwarded as PR c/69221), ghc generates non-compliant C code that is
not
compiled as intende
On 26.01.2016 08:25, Jeff Law wrote:
> I believe if they make the return type a pointer type, then the m68k
> backend ought to return the value in a0 and d0 to make broken code
> like this work. It may also be the case that we're not doing this
> properly for indirect calls from a quick scan of m6
14 matches
Mail list logo
