On Thu, 24 Aug 2017, Aldy Hernandez wrote:
As discussed in the PR...
CCP is passing a precision of 0 to get_nonzero_bits for complex
numbers. With my last wide_int sign extension patch, the sign
extension of -1 with a precision of 0 returns 0, whereas it previously
was preturning all ones. Th
On Wed, 23 Aug 2017, Tamar Christina wrote:
> Hi Richard,
>
> Thanks for the feedback,
>
> >
> > I think you should split up your work a bit. The pieces from
> > fold_builtin_* you remove and move to lowering that require no control flow
> > like __builtin_isnan (x) -> x UNORD x should move to
On Wed, 23 Aug 2017, Rainer Orth wrote:
> Hi Richard,
>
> > On Fri, 12 May 2017, Richard Biener wrote:
> >
> >>
> >> This is a heads-up that I am in the process of implementing the last
> >> of Jasons review comments on the dwarf2out parts of early LTO debug
> >> support. I hope to post final p
Hi Mike,
On Wed, Aug 23, 2017 at 01:34:43PM -0400, Michael Meissner wrote:
> This patch eliminates the undocumented debugging options -mpower9-dform,
> -mpower9-dform-scalar, and -mpower9-dform-vector. These switches were added
> when I added the support for the ISA 3.0 (power9) d-form (register+
Hi,
I added code handle exit condition like "IV1 le/lt IV2" by changing it into
"IV1' le/lt INV".
Unfortunately, wrapping behavior has subtle impact on the transformation. This
patch for
now skips niter analysis if either IV1 or IV2 can wrap. We can still handle
pointer case
as reported in PR8
On Thu, Aug 24, 2017 at 8:59 AM, Marc Glisse wrote:
> On Thu, 24 Aug 2017, Aldy Hernandez wrote:
>
>> As discussed in the PR...
>>
>> CCP is passing a precision of 0 to get_nonzero_bits for complex
>> numbers. With my last wide_int sign extension patch, the sign
>> extension of -1 with a precisio
On Wed, Aug 23, 2017 at 02:08:47PM -0400, David Malcolm wrote:
> In r251239 I added a c_expr::get_location method for use by
> c_parser_expr_list for building the vec for
> an expression list, rather than using the location of the first token.
>
> When determining whether to use the location withi
This adjusts the x86 backend to allow -mfpmath differences when
deciding whether to allow inlining. -mfpmath doesn't really
matter for functions not containing FP operations.
It appears that the can_inline_p target hook is called from the
C++ FE for multi-versioning, thus the ! ipa_fn_summaries
On Thu, Aug 24, 2017 at 1:10 PM, Richard Biener wrote:
>
> This adjusts the x86 backend to allow -mfpmath differences when
> deciding whether to allow inlining. -mfpmath doesn't really
> matter for functions not containing FP operations.
>
> It appears that the can_inline_p target hook is called
Segher Boessenkool wrote:
>
> "0,r" might work, or "0,?r", or similar (alternatives have commas
> between them).
No, it doesn't work at all. But that is no surprise if you look at
ira_get_dup_out_num.
It iterates over the constraint string and if you have anything that matches
after a "0",
the "
As reported in PR80993, enabling lto causes interrupt handlers to be
removed. This patch marks interrupt handlers as used, preventing them
from being optimized out.
If the attached patch is acceptable, I would appreciate if someone could
commit it for me, as I do not have write access.
Thanks,
J
Reword loop in copy_n specialization for input iterator.
Avoid condition check and jumps within loop.
Pay attention that input iterator incremented n - 1 times,
while output iterator incremented n times.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50119 and
https://gcc.gnu.org/bugzilla/show_b
istream_iterator do unexpected read from stream
when initialized by istream&.
It is not required from increment operators of istream_iterator
that _M_ok will be true as precondition.
---
libstdc++-v3/include/bits/stream_iterator.h| 19 +-
.../24_iterators/istream_iterator/81964.cc
Explicit do sgetc from associated streambuf. Avoid debug-dependent
sgetc (within _M_at_eof()):
__glibcxx_requires_cond(!_M_at_eof(),
_M_message(__gnu_debug::__msg_inc_istreambuf)
._M_iterator(*this));
Increment operators not req
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81964
On Thu, 24 Aug 2017 11:55:58 +0300
Petr Ovtchenkov wrote:
> istream_iterator do unexpected read from stream
> when initialized by istream&.
>
> It is not required from increment operators of istream_iterator
> that _M_ok will be true as precond
On Thu, 24 Aug 2017, Uros Bizjak wrote:
> On Thu, Aug 24, 2017 at 1:10 PM, Richard Biener wrote:
> >
> > This adjusts the x86 backend to allow -mfpmath differences when
> > deciding whether to allow inlining. -mfpmath doesn't really
> > matter for functions not containing FP operations.
> >
> >
On Thu, Aug 24, 2017 at 1:34 PM, Richard Biener wrote:
> On Thu, 24 Aug 2017, Uros Bizjak wrote:
>
>> On Thu, Aug 24, 2017 at 1:10 PM, Richard Biener wrote:
>> >
>> > This adjusts the x86 backend to allow -mfpmath differences when
>> > deciding whether to allow inlining. -mfpmath doesn't really
On 22/08/2017 11:57, Jozef Lawrynowicz wrote:
On 02/08/2017 17:45, Joseph Myers wrote:
On Wed, 2 Aug 2017, Jeff Law wrote:
I think Joseph's suggestion for looking at partial float handling may be
useful, though ia64's RFmode may be more interesting as it's not a
multiple of 8 in bitsize. IF/K
The following fixes offloading fallout from the early LTO debug patches.
Bootstrap and regtest running on x86_64-unknown-linux-gnu, at least
the compile stage is verified to work for nvptx offloading now.
Richard.
2017-08-24 Richard Biener
PR debug/81936
* dwarf2out.c (outpu
On 2017-08-22 10:17 +0200, Richard Biener wrote:
>
> Ok for the gcc 7 branch.
>
Well, I think I should say I don't have SVN write access...
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Hi,
As described in the PR, gcc-6-branch is impacted by this issue. This
patch backports the original fix from Bernd and the recently added
testcase (which does not rely on c++17 features).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00730.htm
On Tue, Aug 22, 2017 at 4:19 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, Aug 18, 2017 at 12:30 PM, Richard Biener
>> wrote:
>>> On Thu, Aug 17, 2017 at 2:24 PM, Bin.Cheng wrote:
On Thu, Aug 17, 2017 at 12:35 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
On 08/24/2017 08:33 AM, Yvan Roux wrote:
Hi,
As described in the PR, gcc-6-branch is impacted by this issue. This
patch backports the original fix from Bernd and the recently added
testcase (which does not rely on c++17 features).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287
https://gcc.
Vladimir Makarov wrote:
>
> As I correctly understand, you just want an intuitive allocation. The
> current allocation performance has the same quality as the intuitive one.
Performance is affected as well but I didn't want to go into details as that
distracts from the underlying issue. But if yo
As reported in PR78554, attempting to store an __int20 address in memory
causes an ICE due to an invalid insn. This only occurs at optimisation
levels higher than -O0 because these optimisation levels pass
-ftree-ter, which causes the compiler to try and do the store in
one instruction.
The issue
On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote:
> Bug 81908 is about a -Wstringop-overflow warning for a Fortran
> test triggered by a recent VRP improvement. A simple test case
> that approximates the warning is:
>
> void f (char *d, const char *s, size_t n)
> {
> if (n > 0 && n <=
On Thu, Aug 24, 2017 at 12:58 PM, Bin Cheng wrote:
> Hi,
> I added code handle exit condition like "IV1 le/lt IV2" by changing it into
> "IV1' le/lt INV".
> Unfortunately, wrapping behavior has subtle impact on the transformation.
> This patch for
> now skips niter analysis if either IV1 or IV2
On 08/24/2017 08:03 AM, Richard Biener wrote:
On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote:
Bug 81908 is about a -Wstringop-overflow warning for a Fortran
test triggered by a recent VRP improvement. A simple test case
that approximates the warning is:
void f (char *d, const char *s,
GCC for the MSP430 target uses hard-coded data to choose the correct CPU
ISA and hardware multiply version for a given MCU. Since the data is
hard-coded, this data can only be updated by updating the compiler
itself.
The following patch changes the mechanism for processing device data to
instead
On 08/18/2017 12:25 PM, Martin Liška wrote:
> On 08/18/2017 11:30 AM, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 2:37 PM, Martin Liška wrote:
>>> On 08/14/2017 10:32 AM, Richard Biener wrote:
Hmm, but the existing "lowering" part is called from the
switch-conversion pass. So
On 07/13/2017 02:56 AM, Richard Sandiford wrote:
> This patch uses opt_scalar_int_mode rather than machine_mode
> when iterating over scalar_int_modes, in cases where that helps
> with future patches. (Using machine_mode is still OK in places
> that don't really care about the mode being a scalar
On 07/13/2017 02:56 AM, Richard Sandiford wrote:
> After a certain point, extract_bit_field and store_bit_field
> ensure that they're dealing with integer modes or BLKmode MEMs.
> This patch uses scalar_int_mode and opt_scalar_int_mode for
> those parts.
>
> 2017-07-13 Richard Sandiford
>
Back when we first designed this, I asked about including devices.csv in
the gcc sources, and... no. It's not GPL. So please make sure to
thoroughly test the "no devices.csv found" case. It's fine to use it to
override the internal data, but not fine to rely on it.
> * gcc/config/msp430/
Some code moved to ease searching for subroutines.
2017-08-24 Uros Bizjak
* lib/target-supports.exp: Group together target-dependant checks.
Tested on x86_64-linux-gnu {-m32}.
Committed to mainline SVN.
Uros.
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target
The changes made in a series of binutils patches
(https://sourceware.org/ml/binutils/2017-08/msg00274.html)
to ld and gas require the -mcode/data-region options to be propagated
from gcc.
The attached patch adds that functionality.
If the patch is acceptable, I would appreciate if someone could
...it's really a general RTL predicate, rather than something that depends
on the DF state. Thanks to Segher for the suggestion.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
2017-08-24 Richard Sandiford
gcc/
* df.h (df_read_modify_subreg_p): Remove in f
Segher Boessenkool writes:
> On Wed, Aug 23, 2017 at 11:49:03AM +0100, Richard Sandiford wrote:
>> This patch uses df_read_modify_subreg_p to check whether writing
>> to a subreg would preserve some of the existing contents.
>
> combine does not keep the DF info up-to-date -- but that is no
> prob
Currently the conversion operator member functions are kept on a set of
METHOD_VEC slots at the start of the method_vec. These are
distinguished by return type.
However, usually we want to grab all the conversion operators to see if
one permits a conversion to whatever we're converting to. U
Richard Biener writes:
> @@ -787,14 +821,14 @@ canonicalize_base_object_address (tree a
>
> bool
> dr_analyze_innermost (innermost_loop_behavior *drb, tree ref,
> - struct loop *loop)
> + gimple *stmt, struct loop *loop)
> {
>
> please amend the function
On Wed, Aug 9, 2017 at 3:39 AM, H.J. Lu wrote:
> On Tue, Aug 8, 2017 at 10:36 PM, Richard Biener
> wrote:
>> On August 9, 2017 12:18:41 AM GMT+02:00, "H.J. Lu"
>> wrote:
>>>This patch adds -static-pie to GCC driver to create static PIE. A
>>>static
>>>position independent executable (PIE) is s
--enable-static-pie configures glibc to compile libc.a as PIE and
creates static executables as PIE. A static position independent
executable (static PIE) is similar to static executable, but can be
loaded at any address without help from a dynamic linker. All linker
input files must be compiled
The bulk of this patch touches what I think is considered
the middle-end (attribs.c) so let me include its maintainers,
Ian, Jeff, and Richard:
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01087.html
The high-level description and rationale for the change are
here:
https://gcc.gnu.org/ml/g
On 08/24/2017 12:21 PM, Richard Sandiford wrote:
> ...it's really a general RTL predicate, rather than something that depends
> on the DF state. Thanks to Segher for the suggestion.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>
> Richard
>
>
> 2017-08-24 Richard Sand
Hi,
https://gcc.gnu.org/PR81504 reports a problem with the use of vec_st to generate
the stvx instruction. With swap optimization enabled, the stvx instruction uses
the wrong base address, causing data corruption.
The problem arises in the recombine_lvx_stvx pre-pass that runs prior to swap
opti
On 08/17/2017 03:55 AM, Wilco Dijkstra wrote:
> Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 4:11 PM, Wilco Dijkstra
>> wrote:
>>> Richard Biener wrote:
> We also change the association of
>
> x / (y * C) -> (x / C) / y
>
> If C is a constant.
Why's that pr
On 08/15/2017 09:27 PM, Alan Modra wrote:
> Ping?
>
> On Wed, Aug 09, 2017 at 08:58:31PM +0930, Alan Modra wrote:
>> PR rtl-optimization/81747
>> * cse.c (cse_extended_basic_block): Don't attempt to record
>> equivalences for degenerate conditional jumps that branch
>> to their
On 08/14/2017 03:19 AM, Bin Cheng wrote:
> Hi,
> This simple patch adds code dumping struct dependence_info.
> Bootstrap and test in series. Is it OK?
>
> Thanks,
> bin
> 2017-08-10 Bin Cheng
>
> * tree-pretty-print.c (dump_generic_node): Dump fixed length
> tag in MEM_REF. Dump
On 07/13/2017 02:57 AM, Richard Sandiford wrote:
> expand_unop can expand narrow clz, clrsb, ctz, bswap, parity and
> ffs operations using optabs for wider modes. These expansions
> apply only to scalar integer modes (and not for example to vectors),
> so the patch adds explicit checks for that.
>
On 07/13/2017 02:58 AM, Richard Sandiford wrote:
> The main scalar integer block in simplify_const_unary_operation
> had the condition:
>
> if (CONST_SCALAR_INT_P (op) && width > 0)
>
> where "width > 0" was a roundabout way of testing != VOIDmode.
> This patch replaces it with a check for a sc
On 07/13/2017 02:58 AM, Richard Sandiford wrote:
> This patch rewrites the condition:
>
> if (tmode != address_mode && tmode != pointer_mode)
> tmode = address_mode;
>
> to the equivalent:
>
> tmode == pointer_mode ? pointer_mode : address_mode
>
> The latter has the advantage that the
On 07/13/2017 02:59 AM, Richard Sandiford wrote:
> This patch uses scalar_int_modes for:
>
> /* If I2 is setting a pseudo to a constant and I3 is setting some
> sub-part of it to another constant, merge them by making a new
> constant. */
>
> This was already implicit, but the danger
On 07/13/2017 02:59 AM, Richard Sandiford wrote:
> This patch adds a helper function to get the mode of the addresses
> or offsets in a jump table. It also changes the final.c code to use
> rtx_jump_table_data over rtx or rtx_insn in cases where it needed
> to use the new helper. This in turn mea
On 07/13/2017 02:59 AM, Richard Sandiford wrote:
> The callers of do_jump_by_parts_* had already established
> that the modes were MODE_INTs, so this patch passes the
> modes down as scalar_int_modes.
>
> 2017-07-13 Richard Sandiford
> Alan Hayward
> David Sherwood
>
>
On 07/13/2017 03:00 AM, Richard Sandiford wrote:
> This patch makes the AArch64 port use scalar_int_mode in various places.
> Other ports won't need this kind of change; we only need it for AArch64
> because of the variable-sized SVE modes.
>
> The only change in functionality is in the rtx_costs
On 07/13/2017 03:00 AM, Richard Sandiford wrote:
> This patch changes the types of various things from machine_mode
> to scalar_int_mode, in cases where (after previous patches)
> simply changing the type is enough on its own. The patch does
> nothing other than that.
>
> 2017-07-13 Richard Sand
On 07/13/2017 03:01 AM, Richard Sandiford wrote:
> This patch makes a few simplifications after the previous
> mechanical machine_mode->scalar_int_mode change.
>
> 2017-07-13 Richard Sandiford
> Alan Hayward
> David Sherwood
>
> gcc/
> * expmed.c (extract_high_hal
On 08/24/2017 09:03 AM, Martin Sebor wrote:
> On 08/24/2017 08:03 AM, Richard Biener wrote:
>> On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote:
>>> Bug 81908 is about a -Wstringop-overflow warning for a Fortran
>>> test triggered by a recent VRP improvement. A simple test case
>>> that approx
On 08/22/2017 08:15 AM, Wilco Dijkstra wrote:
> Jeff Law wrote:
> On 07/26/2017 05:29 PM, Wilco Dijkstra wrote:
>
>>> But then the check size_align % MAX_SUPPORTED_STACK_ALIGNMENT != 0
>>> seems wrong too given that round_push uses a different alignment to align
>>> to.
>> I had started to dig i
Hi!
On Thu, Aug 24, 2017 at 04:04:23PM -0500, Bill Schmidt wrote:
> @@ -1501,7 +1503,21 @@ recombine_lvx_pattern (rtx_insn *insn, del_info *t
> to_delete[INSN_UID (swap_insn)].replace = true;
> to_delete[INSN_UID (swap_insn)].replace_insn = swap_insn;
>
> - XEXP (mem, 0) =
On 08/22/2017 02:45 AM, Richard Biener wrote:
> On Mon, Aug 21, 2017 at 10:10 PM, Martin Sebor wrote:
>> On 08/09/2017 10:14 AM, Jeff Law wrote:
>>>
>>> On 08/06/2017 05:08 PM, Martin Sebor wrote:
>>>
>
> Well, simply because the way as implemented isn't a must-alias query
> but maybe
On 08/17/2017 07:56 AM, Wilco Dijkstra wrote:
> This patch simplifies pow (C, x) into exp (x * C1) if C > 0, C1 = log (C).
> Do this only for fast-math as accuracy is reduced. This is much faster
> since pow is more complex than exp - with current GLIBC the speedup is
> more than 7 times for this
On 08/17/2017 09:43 AM, Alexander Monakov wrote:
> On Thu, 17 Aug 2017, Wilco Dijkstra wrote:
>
>> This patch simplifies pow (C, x) into exp (x * C1) if C > 0, C1 = log (C).
>
> Note this changes the outcome for C == +Inf, x == 0 (pow is specified to
> return 1.0 in that case, but x * C1 == NaN).
On 08/14/2017 03:19 AM, Bin Cheng wrote:
> HI,
> This patch adds copying interface for dependence_info. The methodology
> is we don't copy such information by default, and this interface should
> be called explicitly when it is safe and necessary to do so. Just like
> this patch uses the interfac
Ping.
> 2017-08-07 Steve Ellcey
>
> * Makefile.am (ARCH_AARCH64_LINUX_LSE): Add IFUNC_OPTIONS and
> libatomic_la_LIBADD.
> * config/linux/aarch64/host-config.h: New file.
> * config/linux/aarch64/init.c: New file.
> * configure.ac (AC_CHECK_HEADERS): Check for sys
On 08/24/2017 03:52 PM, Jeff Law wrote:
On 08/24/2017 09:03 AM, Martin Sebor wrote:
On 08/24/2017 08:03 AM, Richard Biener wrote:
On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote:
Bug 81908 is about a -Wstringop-overflow warning for a Fortran
test triggered by a recent VRP improvement. A
On 07/13/2017 03:01 AM, Richard Sandiford wrote:
> This patch adds a scalar_mode class that can hold any scalar mode,
> specifically:
>
> - scalar integers
> - scalar floating-point values
> - scalar fractional modes
> - scalar accumulator modes
> - pointer bounds modes
>
> To start wit
On 07/13/2017 03:01 AM, Richard Sandiford wrote:
> This patch adds a SCALAR_TYPE_MODE macro, along the same lines as
> SCALAR_INT_TYPE_MODE and SCALAR_FLOAT_TYPE_MODE. It also adds
> two instances of as_a to c_common_type, when converting
> an unsigned fixed-point SCALAR_TYPE_MODE to the equivale
On 07/13/2017 03:02 AM, Richard Sandiford wrote:
> This patch treats the mode associated with an integer constant as a
> scalar_mode. We can't use the more natural-sounding scalar_int_mode
> because we also use (const_int 0) for bounds-checking modes. (It might
> be worth adding a bounds-specific
On 07/13/2017 03:02 AM, Richard Sandiford wrote:
> This patch uses scalar_mode for code that operates only on MODE_INT
> and MODE_FLOAT.
>
> 2017-07-13 Richard Sandiford
> Alan Hayward
> David Sherwood
>
> gcc/
> * omp-expand.c (expand_omp_atomic): Use is_int_mode
On 07/13/2017 03:02 AM, Richard Sandiford wrote:
> This patch makes the fixed-value.* routines use scalar_mode.
> It would be possible to define special classes for these modes, as for
> scalar_int_mode and scalar_float_mode, but at the moment nothing would
> benefit from them. In particular, ther
On 07/13/2017 03:03 AM, Richard Sandiford wrote:
> This patch splits the final scalar-only part of convert_mode out
> into its own subroutine and treats the modes as scalar_modes there.
>
> 2017-07-13 Richard Sandiford
> Alan Hayward
> David Sherwood
>
> gcc/
> *
On 07/13/2017 03:03 AM, Richard Sandiford wrote:
> The expand_float code:
>
> /* Unsigned integer, and no way to convert directly. Convert as signed,
> then unconditionally adjust the result. */
>
> and the expand_fix code:
>
> /* For an unsigned conversion, there is one more way to d
On August 24, 2017 11:52:41 PM GMT+02:00, Jeff Law wrote:
>On 08/24/2017 09:03 AM, Martin Sebor wrote:
>> On 08/24/2017 08:03 AM, Richard Biener wrote:
>>> On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor
>wrote:
Bug 81908 is about a -Wstringop-overflow warning for a Fortran
test triggered
73 matches
Mail list logo
