On 07/17/2017 10:33 PM, NightStrike wrote:
> On Mon, Jul 17, 2017 at 11:23 AM, Martin Sebor wrote:
>> you did for the bugs below is ideal. Adding a test case if one
>> doesn't exist in the test suite is also very useful, though quite
>> a bit more work.
>
> Isn't a testcase always required?
Requ
On Mon, Jul 17, 2017 at 11:23 AM, Martin Sebor wrote:
> you did for the bugs below is ideal. Adding a test case if one
> doesn't exist in the test suite is also very useful, though quite
> a bit more work.
Isn't a testcase always required?
On 07/17/2017 12:20 AM, Richard Biener wrote:
On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool
Now what should it take as input? An rtx_insn, or just the pattern
(as insn_rtx_cost does)?
Is there any useful info on the other operands of an rtx_insn? If not
then passing in the pattern (a
On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor wrote:
> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>
>> Hi Mikhail,
>>
>> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev
>> wrote:
>>>
>>> Hi. Yes, bug maintenance is appreciated. See this message and replies
>>> to it: https://gcc.gnu.org/ml/gcc/2
Ah OK, thank you, I wasn't aware of that particular mechanism. If I
run the code and break on __mulsc3 it disassembles as I'd expect.
On Mon, Jul 17, 2017 at 12:32 PM, Gabriel Paubert wrote:
> On Mon, Jul 17, 2017 at 10:51:21AM -0600, Sean McAllister wrote:
>> When generating code for a simple i
On Mon, Jul 17, 2017 at 10:51:21AM -0600, Sean McAllister wrote:
> When generating code for a simple inner loop (instantiated with
> std::complex)
>
> template
> void __attribute__((noinline)) benchcore(const cx* __restrict__ aa,
> const cx* __restrict__ bb, const cx* __restrict__ cc, cx* __restr
When generating code for a simple inner loop (instantiated with
std::complex)
template
void __attribute__((noinline)) benchcore(const cx* __restrict__ aa,
const cx* __restrict__ bb, const cx* __restrict__ cc, cx* __restrict__
dd, cx uu, cx vv, size_t nn) {
for (ssize_t ii=0; ii < nn; ii++) {
On 07/17/2017 02:14 AM, Yuri Gribov wrote:
Hi Mikhail,
On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev wrote:
Hi. Yes, bug maintenance is appreciated. See this message and replies
to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
Replies in your link suggest to leave a final comment
Him
On Mon, Jul 17, 2017 at 03:36:13PM +0200, Georg-Johann Lay wrote:
> >On Wed, Jul 12, 2017 at 03:15:09PM +0200, Georg-Johann Lay wrote:
> >>the current cost computations in rtlanal.c and maybe other places
> >>suffer from the fact that they are hiding parts of the expressions
> >>from the back-
On 7/12/17, Martin Sebor wrote:
> On 07/11/2017 11:50 PM, sa...@hederstierna.com wrote:
>> Hi
>>
>> Reading about macro pitfalls and eg duplication side-effects
>> https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html#Macro-Pitfalls
>>
>> would it be possible to let the preprocessor generate warn
On 16.07.2017 00:51, Segher Boessenkool wrote:
Hi!
On Wed, Jul 12, 2017 at 03:15:09PM +0200, Georg-Johann Lay wrote:
the current cost computations in rtlanal.c and maybe other places
suffer from the fact that they are hiding parts of the expressions
from the back-end, like SET_DESTs of single_s
On 17.07.2017 10:53, Georg-Johann Lay wrote:
Hi, while testing a patch to fix PR81444, I came across a new FAIL due
to the patch in i386.c/pr71321.c
PR81444 is about wrong modes used by expmed.c as it computes costs for
widening operations like widening mul. It uses GET_MODE_WIDER_MODE
for the
On Mon, Jul 17, 2017 at 11:56:50AM +0200, Richard Biener wrote:
> On Thu, Jul 13, 2017 at 2:18 AM, Kugan Vivekanandarajah
> wrote:
> > I am looking into reversing loop to increased efficiency. There is
> > already a PR22041 for this and an old patch
> > https://gcc.gnu.org/ml/gcc-patches/2006-01/m
On Wed, Jul 12, 2017 at 10:12:03AM +0800, Leslie Zhai wrote:
> PS: Trevor's email is not available? thanks!
Sorry about that, I've left Mozilla and been vacationing for a month, so
didn't get to updating MAINTAINERS yet. Here's a patch doing that.
Trev
commit ff900f40d23f765fd59047a90a7e3ff18cb
On Mon, Jul 17, 2017 at 12:20:16PM +0200, Richard Biener wrote:
> > So I argue that we want to have a hook for insn cost.
>
> And I think at previous GNU Cauldrons we agreed to that.
Excellent! So now it just needs to happen ;-)
> > Now what should it take as input? An rtx_insn, or just the pa
On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool
wrote:
> Hi!
>
> On Wed, Jul 12, 2017 at 03:15:09PM +0200, Georg-Johann Lay wrote:
>> the current cost computations in rtlanal.c and maybe other places
>> suffer from the fact that they are hiding parts of the expressions
>> from the back-end, l
On Thu, Jul 13, 2017 at 2:18 AM, Kugan Vivekanandarajah
wrote:
> I am looking into reversing loop to increased efficiency. There is
> already a PR22041 for this and an old patch
> https://gcc.gnu.org/ml/gcc-patches/2006-01/msg01851.html by Zdenek
> which never made it to mainline.
>
> For constant
On Mon, Jul 17, 2017 at 11:10:01AM +0300, Alexander Monakov wrote:
> On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> > > How? There's no stable sort in libc and switching over to std::stable_sort
> > > would be problematic.
> >
> > Why?
>
> - you'd need to decide if the build time cost of extra
Hi, while testing a patch to fix PR81444, I came across a new FAIL due
to the patch in i386.c/pr71321.c
PR81444 is about wrong modes used by expmed.c as it computes costs for
widening operations like widening mul. It uses GET_MODE_WIDER_MODE
for the wider mode where is should use GET_MODE_2XWID
Hi Mikhail,
On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev wrote:
> Hi. Yes, bug maintenance is appreciated. See this message and replies
> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
Replies in your link suggest to leave a final comment in bugs with
explanatory suggestion to clos
On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> > How? There's no stable sort in libc and switching over to std::stable_sort
> > would be problematic.
>
> Why?
- you'd need to decide if the build time cost of extra 8000+ lines
lines brought in by (per each TU) is acceptable;
- you'd need to
21 matches
Mail list logo