On Mon, Jul 9, 2018 at 9:05 PM Richard Henderson wrote:
>
> At the same time, merge several related frame computing functions.
> Recall that HWI is now always 64-bit, so merge IMASK and FMASK,
> which allows merging of several loops within prologue and epilogue.
Btw, if you're not using these wit
On Mon, Jul 9, 2018 at 9:08 PM Will Schmidt wrote:
>
> Hi,
> Re-posting. Richard provided feedback on a previous version of this
> patch, I wanted to make sure he was/is OK with the latest. :-)
>
> Add support for Gimple folding for unaligned vector loads and stores.
>
> Regtest completed acros
On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
>
> On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
> >{ dg-do run }
> >{ do-options "-O2 -fno-tree-strlen" } */
> >
> > I don't think this is doing anything.
> >
> > If you look at the test run you can see that -fno-tree-strlen is ne
Hi!
While working on OpenMP 5.0 range-for support, I've discovered that even for
normal class iterators distribute parallel for gimplification ICEs in
several ways (other composite loop constructs work only because class
iterators are not allowed on them). The problem is that the FEs emit the
cod
On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
wrote:
>
>
> The patches I posted earlier this year for mitigating against
> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
> which it became obvious that a rethink was needed. This mail, and the
> following patches attempt t
Hi!
This patch (in a backwards compatible way) handles saving and restoring of
linear clause modifiers.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2018-07-10 Jakub Jelinek
PR fortran/86421
* module.c (omp_declare_simd_clauses): Add LINEAR with
Hi!
cp_maybe_instrument_return is looking for a return stmt at the end of
function to decide whether to omit -fsanitize=return instrumentation or
__builtin_unreachable addition. If a STATEMENT_LIST has a return followed
by DEBUG_BEGIN_STMT (or multiple of them), it doesn't find the return
though.
On Tue, 10 Jul 2018, Jakub Jelinek wrote:
> Hi!
>
> cp_maybe_instrument_return is looking for a return stmt at the end of
> function to decide whether to omit -fsanitize=return instrumentation or
> __builtin_unreachable addition. If a STATEMENT_LIST has a return followed
> by DEBUG_BEGIN_STMT (o
On 09/07/18 09:11, Martin Liška wrote:
> Hi.
>
> I'm putting back what I accidentally removed.
>
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-09 Martin Liska
>
> * common.opt: Add back wrongly removed attribute.
> ---
> gcc/common.opt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On Tue, Jul 10, 2018 at 10:01:10AM +0200, Richard Biener wrote:
> On Tue, 10 Jul 2018, Jakub Jelinek wrote:
> > cp_maybe_instrument_return is looking for a return stmt at the end of
> > function to decide whether to omit -fsanitize=return instrumentation or
> > __builtin_unreachable addition. If a
Howdy!
Attached are more cleanups to VRP getting rid of some repetitive code,
as well as abstracting wide int handling code into their own functions.
There should be no change to existing functionality.
You may notice that I have removed the PLUS/MINUS_EXPR handling in
vrp_int_const_binop, e
Hi all,
This patch removes some duplicated code. Since this method deals with
four loads or stores, there is a lot of duplicated code that can easily
be replaced with smaller loops.
Regtest and bootstrap OK.
OK for trunk?
Thanks,
Jackson
Changelog:
gcc/
2018-06-28 Jackson Woodruff
Hi all,
This patch resolves PR86014. It does so by noticing that the last load
may clobber the address register without issue (regardless of where it
exists in the final ldp/stp sequence). That check has been changed so
that the last register may be clobbered and the testcase
(gcc.target/aa
On 10/07/18 08:19, Richard Biener wrote:
> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
> wrote:
>>
>>
>> The patches I posted earlier this year for mitigating against
>> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
>> which it became obvious that a rethink was needed.
On 07/09/2018 03:56 PM, Jeff Law wrote:
On 07/09/2018 01:19 AM, Aldy Hernandez wrote:
I'd like decisions about how to expand branches deferred until rtl
expansion. Kai was poking at this in the past but never really got any
traction.
For the record, the problem in this testcase is that sw
The following makes the hash-map iterator dereference return a pair rather than a copy of Value. This matches the hash-table iterator
behavior and avoids issues with
hash_map >
where iterating over the hash-table will call the auto_vec destructor
when dereferencing the iterator. I note that
On 10/07/18 00:13, Jeff Law wrote:
> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>
>> The patches I posted earlier this year for mitigating against
>> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
>> which it became obvious that a rethink was needed. This mail, and th
Adding Jeff and Eric since the patch adds an RTL target hook.
Best regards,
Thomas
On Thu, 5 Jul 2018 at 15:48, Thomas Preudhomme
wrote:
>
> In case of high register pressure in PIC mode, address of the stack
> protector's guard can be spilled on ARM targets as shown in PR85434,
> thus allowing
On Tue, Jul 10, 2018 at 10:43:20AM +0200, Richard Biener wrote:
>
> The following makes the hash-map iterator dereference return a pair Value&> rather than a copy of Value. This matches the hash-table iterator
> behavior and avoids issues with
>
> hash_map >
Eventually somebodies probably goi
On Tue, 10 Jul 2018, Trevor Saunders wrote:
> On Tue, Jul 10, 2018 at 10:43:20AM +0200, Richard Biener wrote:
> >
> > The following makes the hash-map iterator dereference return a pair > Value&> rather than a copy of Value. This matches the hash-table iterator
> > behavior and avoids issues wit
Hi Jackson,
On 10/07/18 09:37, Jackson Woodruff wrote:
Hi all,
This patch removes some duplicated code. Since this method deals with
four loads or stores, there is a lot of duplicated code that can easily
be replaced with smaller loops.
Regtest and bootstrap OK.
OK for trunk?
This looks l
Hi Jackson
On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
Hi all,
This patch removes some duplicated code. Since this method deals with
four loads or stores, there is a lot of duplicated code that can
easily be replaced with smaller loops.
Regtest and bootstrap OK.
OK for trun
I believe[1][2] that the C++ standard says that
std::condition_variable::wait_for should be implemented to be equivalent
to:
return wait_until(lock, chrono::steady_clock::now() + rel_time);
But the existing implementation uses chrono::system_clock. Now that
wait_until has potentially-different b
As currently implemented, condition_variable always ultimately waits
against std::chrono::system_clock. This clock can be changed in arbitrary
ways by the user which may result in us waking up too early or too late
when measured against the caller-supplied clock.
We can't (yet) do much about wakin
On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
wrote:
>
> On 10/07/18 08:19, Richard Biener wrote:
> > On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
> > wrote:
> >>
> >>
> >> The patches I posted earlier this year for mitigating against
> >> CVE-2017-5753 (Spectre variant 1) attracte
Ho hum, more abstractions.
No change in functionality.
OK for trunk?
gcc/
* vr-values.c (gimple_stmt_nonzero_p): Abstract common code to...
* gimple.c (gimple_call_nonnull_result_p): ...here...
(gimple_call_nonnull_arg): ...and here.
* gimple.h (gimple_call_nonn
On 10/07/18 11:10, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
> wrote:
>>
>> On 10/07/18 08:19, Richard Biener wrote:
>>> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
>>> wrote:
The patches I posted earlier this year for mitigating against
On Mon, 2018-07-09 at 15:00 +0200, Richard Biener wrote:
> On Mon, Jul 2, 2018 at 10:51 PM David Malcolm
> wrote:
> >
> > This patch implements a way to consolidate dump_* calls into
> > optinfo objects, as enabling work towards being able to write out
> > optimization records to a file, or emit
I believe I missed this companion patch when I submitted...
Subject: jump threading multiple paths that start from the same BB
The attached patch changes thread_through_all_blocks to allow threads
that start from the same basic block as another thread.
OK for trunk?
gcc/
* tree-ss
On Tue, Jul 10, 2018 at 12:53 PM Richard Earnshaw (lists)
wrote:
>
> On 10/07/18 11:10, Richard Biener wrote:
> > On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 10/07/18 08:19, Richard Biener wrote:
> >>> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
> >>> wr
On Tue, Jul 10, 2018 at 1:00 PM David Malcolm wrote:
>
> On Mon, 2018-07-09 at 15:00 +0200, Richard Biener wrote:
> > On Mon, Jul 2, 2018 at 10:51 PM David Malcolm
> > wrote:
> > >
> > > This patch implements a way to consolidate dump_* calls into
> > > optinfo objects, as enabling work towards b
On 07/10/2018 12:05 AM, Richard Biener wrote:
> On Mon, Jul 9, 2018 at 9:05 PM Richard Henderson wrote:
>>
>> At the same time, merge several related frame computing functions.
>> Recall that HWI is now always 64-bit, so merge IMASK and FMASK,
>> which allows merging of several loops within prolog
On Tue, Jul 10, 2018 at 2:50 PM Richard Henderson wrote:
>
> On 07/10/2018 12:05 AM, Richard Biener wrote:
> > On Mon, Jul 9, 2018 at 9:05 PM Richard Henderson wrote:
> >>
> >> At the same time, merge several related frame computing functions.
> >> Recall that HWI is now always 64-bit, so merge I
The following fixes PR86457. I also removed some leftover tests
of dwarf2out_as_loc_support in favor of output_asm_line_debug_info.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-07-10 Richard Biener
PR debug/86457
* dwarf2out.c (init_sections_and
On Tue, 10 Jul 2018, Richard Biener wrote:
> On Tue, 10 Jul 2018, Trevor Saunders wrote:
>
> > On Tue, Jul 10, 2018 at 10:43:20AM +0200, Richard Biener wrote:
> > >
> > > The following makes the hash-map iterator dereference return a pair > > Value&> rather than a copy of Value. This matches th
Hi,
Jeff told me that the recent popcount built-in detection is causing
kernel build issues as
ERROR: "__popcountsi2"
[drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined!
I could also reproduce this. AFIK, we should check if the libfunc is
defined while checking popcount?
I
The following avoids constant propagating both on a loop and its
children.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
I'm going to remove the checking code I added before committing
(and I will of course re-test).
Richard.
2018-07-10 Richard Biener
* tree-ssa-l
On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
wrote:
>
> Hi,
>
> Jeff told me that the recent popcount built-in detection is causing
> kernel build issues as
> ERROR: "__popcountsi2"
> [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined!
>
> I could also reproduce thi
On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> > Jeff told me that the recent popcount built-in detection is causing
> > kernel build issues as
> > ERROR: "__popcountsi2"
> > [drivers/net/wireless/broadcom/brcm80211/brcmfma
Hi Jackson
On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
Hi all,
This patch resolves PR86014. It does so by noticing that the last
load may clobber the address register without issue (regardless of
where it exists in the final ldp/stp sequence). That check has been
changed so
> On Jul 10, 2018, at 2:10 AM, Richard Biener
> wrote:
>
> On Mon, Jul 9, 2018 at 9:08 PM Will Schmidt wrote:
>>
>> Hi,
>> Re-posting. Richard provided feedback on a previous version of this
>> patch, I wanted to make sure he was/is OK with the latest. :-)
>>
>> Add support for Gimple fol
On Tue, Jul 10, 2018 at 3:27 PM Jakub Jelinek wrote:
>
> On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote:
> > On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> > > Jeff told me that the recent popcount built-in detection is causing
> > > kernel build issues as
> > > ERROR: "_
On 10/07/18 12:21, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 12:53 PM Richard Earnshaw (lists)
> wrote:
>>
>> On 10/07/18 11:10, Richard Biener wrote:
>>> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
>>> wrote:
On 10/07/18 08:19, Richard Biener wrote:
> On Mon, Ju
On Tue, Jul 10, 2018 at 3:33 PM Bill Schmidt wrote:
>
>
> > On Jul 10, 2018, at 2:10 AM, Richard Biener
> > wrote:
> >
> > On Mon, Jul 9, 2018 at 9:08 PM Will Schmidt
> > wrote:
> >>
> >> Hi,
> >> Re-posting. Richard provided feedback on a previous version of this
> >> patch, I wanted to mak
> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists)
> wrote:
>
> On 10/07/18 00:13, Jeff Law wrote:
>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>
>>> The patches I posted earlier this year for mitigating against
>>> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback
> On Jul 10, 2018, at 8:48 AM, Richard Biener
> wrote:
>
> On Tue, Jul 10, 2018 at 3:33 PM Bill Schmidt wrote:
>>
>>
>>> On Jul 10, 2018, at 2:10 AM, Richard Biener
>>> wrote:
>>>
>>> On Mon, Jul 9, 2018 at 9:08 PM Will Schmidt
>>> wrote:
Hi,
Re-posting. Richard provid
On 07/10/2018 01:12 AM, Richard Biener wrote:
On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see th
On 10/07/18 14:48, Bill Schmidt wrote:
>
>> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists)
>> wrote:
>>
>> On 10/07/18 00:13, Jeff Law wrote:
>>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
The patches I posted earlier this year for mitigating against
CVE-2017-5753 (Spe
On Tue, Jul 10, 2018 at 3:51 PM Bill Schmidt wrote:
>
>
> > On Jul 10, 2018, at 8:48 AM, Richard Biener
> > wrote:
> >
> > On Tue, Jul 10, 2018 at 3:33 PM Bill Schmidt wrote:
> >>
> >>
> >>> On Jul 10, 2018, at 2:10 AM, Richard Biener
> >>> wrote:
> >>>
> >>> On Mon, Jul 9, 2018 at 9:08 PM Wi
On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor wrote:
>
> On 07/10/2018 01:12 AM, Richard Biener wrote:
> > On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
> >>
> >> On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
> >>>{ dg-do run }
> >>>{ do-options "-O2 -fno-tree-strlen" } */
> >>>
> >
On 07/10/2018 08:25 AM, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor wrote:
>>
>> On 07/10/2018 01:12 AM, Richard Biener wrote:
>>> On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
>{ dg-do run }
>{
On 07/10/2018 07:17 AM, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi,
>>
>> Jeff told me that the recent popcount built-in detection is causing
>> kernel build issues as
>> ERROR: "__popcountsi2"
>> [drivers/net/wireless/broadcom/brcm80211/brcmfm
On 07/10/2018 07:27 AM, Jakub Jelinek wrote:
> On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote:
>> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
>>> Jeff told me that the recent popcount built-in detection is causing
>>> kernel build issues as
>>> ERROR: "__popcountsi2"
>>>
On 07/10/2018 10:01 AM, Andre Vieira (lists) wrote:
> On 09/07/18 09:11, Martin Liška wrote:
>> Hi.
>>
>> I'm putting back what I accidentally removed.
>>
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2018-07-09 Martin Liska
>>
>> * common.opt: Add back wrongly removed attribute.
>> ---
>> gcc/comm
On 07/10/2018 08:34 AM, Jeff Law wrote:
On 07/10/2018 08:25 AM, Richard Biener wrote:
On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor wrote:
On 07/10/2018 01:12 AM, Richard Biener wrote:
On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ d
> On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote:
>
> check_access() calls warning_at() to issue warnings, and that
> function only issues warnings if they are enabled, so the guard
> isn't necessary to make it work this way.
Okay I see.
then, in the current code: (for routine expand_builtin_
On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 00:13, Jeff Law wrote:
>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>
>>> To address all of the above, these patches adopt a new approach, based
>>> in part on a posting by Chandler Carruth to the LLVM developers list
>>>
On 07/10/2018 08:14 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 14:48, Bill Schmidt wrote:
>>
>>> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 10/07/18 00:13, Jeff Law wrote:
On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>
> The patches I posted
On 07/10/2018 04:53 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 11:10, Richard Biener wrote:
>> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
>> wrote:
>>>
>>> On 10/07/18 08:19, Richard Biener wrote:
On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
wrote:
>
>
>
On July 10, 2018 5:14:37 PM GMT+02:00, Qing Zhao wrote:
>
>> On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote:
>>
>> check_access() calls warning_at() to issue warnings, and that
>> function only issues warnings if they are enabled, so the guard
>> isn't necessary to make it work this way.
>
>Okay
On 10/07/18 16:42, Jeff Law wrote:
> On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
>> On 10/07/18 00:13, Jeff Law wrote:
>>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
To address all of the above, these patches adopt a new approach, based
in part on a posting by Chandl
"mode" is documented as a variable attribute but not as a type attribute. This
fixes that omission. I simply copied the other text, it seemed suitable as it
stands.
The attributes are normally listed in alphabetical order but "mode" was out of
order in the variable attributes.
Ok for trunk?
On 07/10/2018 09:14 AM, Qing Zhao wrote:
On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote:
check_access() calls warning_at() to issue warnings, and that
function only issues warnings if they are enabled, so the guard
isn't necessary to make it work this way.
Okay I see.
then, in the current
On Tue, 2018-07-10 at 16:23 +0200, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:51 PM Bill Schmidt wrote:
> >
> >
> > > On Jul 10, 2018, at 8:48 AM, Richard Biener
> > > wrote:
> > >
> > > On Tue, Jul 10, 2018 at 3:33 PM Bill Schmidt
> > > wrote:
> > >>
> > >>
> > >>> On Jul 10, 2018, at
Hi,
Add support for Gimple folding for unaligned vector loads and stores.
Regtest completed across variety of systems, P6,P7,P8,P9.
[v2] Added the type for the MEM_REF, per feedback.
Testcases for gimple-folding of the same are currently in-tree
as powerpc/fold-vec-load-*.c and powerpc/fo
On Mon, Jul 09, 2018 at 04:50:03PM -0700, Carl Love wrote:
> The following patch is a back port for a commit to mainline prior to
> GCC 8 release. Note, the code fixed by this patch was later modified
> in commit 256798 as part of adding vec_xst_len support. The sldi
> instruction gets replaced b
Richard and Martin,
thanks for the info.
> On Jul 10, 2018, at 11:29 AM, Richard Biener wrote:
>> Is the above condition on variable warn_stringop_overflow unnecessary?
>> all the warnings inside check_access are controlled by
>> OPT_Wstringop_overflow_.
>
> Well, the condition certainly saves
There was a typo in the output_macinfo_op gcc_assert.
The function is called dwarf_FORM, not dwarf_form.
Add the provided testcase from the bug to test -gsplit-dwarf -g3.
gcc/ChangeLog:
PR debug/86459
* dwarf2out.c (output_macinfo_op): Fix dwarf_FORM typo in gcc_assert.
gcc/tests
On Wed, Jul 11, 2018 at 12:20:08AM +0200, Mark Wielaard wrote:
> There was a typo in the output_macinfo_op gcc_assert.
> The function is called dwarf_FORM, not dwarf_form.
> Add the provided testcase from the bug to test -gsplit-dwarf -g3.
>
> gcc/ChangeLog:
>
> PR debug/86459
> * dwa
This patch alphabetizes the list of AltiVec built-in function prototypes that
consume about 15 pages of the gcc.pdf file. As part of the alphabetization
effort, certain functions that should not be documented in this section of the
manual are separated from the others and moved to the end of th
On 10 July 2018 at 23:17, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi,
>>
>> Jeff told me that the recent popcount built-in detection is causing
>> kernel build issues as
>> ERROR: "__popcountsi2"
>> [drivers/net/wireless/broadcom/brcm80211/brc
On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
wrote:
>
> On 10 July 2018 at 23:17, Richard Biener wrote:
> > On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi,
> >>
> >> Jeff told me that the recent popcount built-in detection is causing
> >> kernel build is
Hi Andrew,
On 11 July 2018 at 11:19, Andrew Pinski wrote:
> On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
> wrote:
>>
>> On 10 July 2018 at 23:17, Richard Biener wrote:
>> > On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Jeff told me tha
On Tue, Jul 10, 2018 at 6:35 PM Kugan Vivekanandarajah
wrote:
>
> Hi Andrew,
>
> On 11 July 2018 at 11:19, Andrew Pinski wrote:
> > On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
> > wrote:
> >>
> >> On 10 July 2018 at 23:17, Richard Biener
> >> wrote:
> >> > On Tue, Jul 10, 2018 at 3:
Hmmm, I think we can do better, and since this hasn't been reviewed yet,
I don't think anyone will mind the adjustment to the patch ;-).
I really hate int_const_binop_SOME_RANDOM_NUMBER. We should abstract
them into properly named poly_int_binop, wide_int_binop, and tree_binop,
and then use a
75 matches
Mail list logo
