On 05/07/2017 18:10, Jonathan Wakely wrote:
On 19/06/17 22:48 +0200, François Dumont wrote:
Hi
Here is the patch to default the default and move constructors on
the std::forward_list. Putting a move constructor on
_Fwd_list_node_base helped limiting the code impact of this patch. It
doesn
On Wed, Jul 12, 2017 at 9:10 PM, Marc Glisse wrote:
> On Wed, 12 Jul 2017, Andrew Pinski wrote:
>
>> Hi,
>> Unlike most other expressions, BIT_INSERT_EXPR has an implicit
>> operand of the precision/size of the second operand. This means if we
>> have an integer constant for the second operand a
On Wed, 12 Jul 2017, Andrew Pinski wrote:
Hi,
Unlike most other expressions, BIT_INSERT_EXPR has an implicit
operand of the precision/size of the second operand. This means if we
have an integer constant for the second operand and that compares to
the same constant value, vn_nary_op_eq would r
On 07/12/2017 06:31 PM, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jul 11, 2017 at 03:19:57PM -0600, Jeff Law wrote:
>> It introduces a new style of stack probing -fstack-check=clash,
>> including documentation of the new option, how it differs from
>> -fstack-check=specific, etc.
>>
>> FWIW -fst
On Wed, Jul 12, 2017 at 7:44 AM, Andreas Krebbel
wrote:
>
> ptrace SETREGS and GETREGS were never supported on S/390. The macros
> were accidentally defined in the Glibc header though. A recent Glibc
> change removed them breaking libgo build on S/390.
>
> This patch changes the ptrace calls to
On Tue, Jul 11, 2017 at 03:20:12PM -0600, Jeff Law wrote:
> * conifg/mips/mips.c (mips_expand_prologue): Likewise.
Typo ("conifg").
> --- a/gcc/defaults.h
> +++ b/gcc/defaults.h
> @@ -1408,8 +1408,11 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively. If not, see
> #endif
>
>
Hi,
Unlike most other expressions, BIT_INSERT_EXPR has an implicit
operand of the precision/size of the second operand. This means if we
have an integer constant for the second operand and that compares to
the same constant value, vn_nary_op_eq would return that these two
expressions are the sam
Hi!
On Tue, Jul 11, 2017 at 03:19:57PM -0600, Jeff Law wrote:
> It introduces a new style of stack probing -fstack-check=clash,
> including documentation of the new option, how it differs from
> -fstack-check=specific, etc.
>
> FWIW -fstack-check=specific is dreadfully named. I haven't tried to
Hmmm, I didn't realize that gcc 6.x also supported __builtin_cpu_*. I imagine
we will need backports there as well.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
GCC Maintainers:
The following patch adds support for the vec_extract_fp_from_shorth()
and vec_extract_fp_from_short builtin functions. The patch has been
tested on powerpc64le-unknown-linux-gnu (Power 8 LE) and
powerpc64le-unknown-linux-gnu (Power 9 LE). The test generates 1
unsupported test on
On Tue, Jul 11, 2017 at 03:19:36PM -0600, Jeff Law wrote:
> Examples of implicit probes include
> 2. ABI mandates that *sp always contain a backchain pointer (ppc)
In the ELFv2 ABI a backchain is not required. GCC still always has
one afaik. I'll find out more.
> To get a sense of overhead,
Thank you for the fix and the cleanup, Jeff!
My tester has been complaining regularly for a little while WRT the
riscv port failing to build due minor header file goof's.
While just reordering the headers is sufficient to fix one of the two
problems, I took the opportunity to remove > 50 unnecessary includes
from riscv.c.
The second problem
On Wed, Jul 12, 2017 at 01:34:01PM -0500, Bill Schmidt wrote:
> Although I said this was invalid code, it really isn't -- it's legal code.
> It's more of an ice-on-stupid-code situation. :) So probably you should
> remove the "invalid" language from the commentary. Sorry for misleading you.
W
On Wed, Jul 12, 2017 at 11:45:07AM -0500, Will Schmidt wrote:
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 10c5521..e21b56f 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -16297,6 +16297,9 @@ rs6000_gimple_fold_builtin (gimple_stm
On Wed, Jul 12, 2017 at 04:07:42PM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, Jul 12, 2017 at 11:38:11AM -0400, Michael Meissner wrote:
> > I also changed the current warning in target_clones handling to be an error
> > instead of a warning, since it really makes no sense to use targe
On 07/12/2017 06:47 AM, Trevor Saunders wrote:
> On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote:
>> On 07/11/2017 06:20 PM, Wilco Dijkstra wrote:
>>> Jeff Law wrote:
aarch64 is the first target that does not have any implicit probes in
the caller. Thus at prologue entry it must
Hi Mike,
On Wed, Jul 12, 2017 at 11:38:11AM -0400, Michael Meissner wrote:
> I also changed the current warning in target_clones handling to be an error
> instead of a warning, since it really makes no sense to use target_clones if
> we
> can't generate a resolver function.
Okay. Another option
On 05/07/2017 17:22, Jonathan Wakely wrote:
It's mostly good, but I'd like to make a few suggestions ...
diff --git a/libstdc++-v3/include/bits/stl_list.h
b/libstdc++-v3/include/bits/stl_list.h
index 232885a..7e5 100644
--- a/libstdc++-v3/include/bits/stl_list.h
+++ b/libstdc++-v3/include
On 07/12/2017 03:14 PM, Christophe Lyon wrote:
Hi Nathan,
/gccsrc/libcc1/libcp1plugin.cc: In function ‘gcc_decl
plugin_build_decl(cc1_plugin::connection*,
const char*, gcc_cp_symbol_kind, gcc_type, const char*, gcc_address,
const char*, unsigned int)’:
/gccsrc/libcc1/libcp1plugin.cc:1422: err
On Wed, Jul 12, 2017 at 03:30:00PM +0200, Georg-Johann Lay wrote:
> On 12.07.2017 14:11, Segher Boessenkool wrote:
> >On Tue, Jul 11, 2017 at 10:47:27AM +0200, Georg-Johann Lay wrote:
> >>This small addition improves costs of PARALLELs in
> >>rtlanal.c:seq_cost(). Up to now, these costs are
> >>as
Hi Nathan,
On 12 July 2017 at 19:34, Nathan Sidwell wrote:
> Now that all the cdtors have special names, we can detect them by looking at
> the name, rather than a collection of other things.
>
> For the DECL_[CD]TOR_P cases we're now comparing identifiers, removing a
> STRIP_TEMPLATE
>
> For th
Although I said this was invalid code, it really isn't -- it's legal code.
It's more of an ice-on-stupid-code situation. :) So probably you should remove
the "invalid" language from the commentary. Sorry for misleading you.
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power To
Now that all the cdtors have special names, we can detect them by looking at the
name, rather than a collection of other things.
For the DECL_[CD]TOR_P cases we're now comparing identifiers, removing a
STRIP_TEMPLATE
For the IN_CHARGE case we're replacing a conjunction of 3 checks (2 of which
On Jul 11 2017, Maxim Ostapenko wrote:
> Ok, I see, it seems that we need to add convert in
> expand_asan_emit_allocas_unpoison too. This patch seems to work for me on
> aarch64 -mabi=ilp32, could you check it as well?
This fixes all regressions.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.
Hi,
Do not do the gimple-folding optimizations of expressions that are
missing their LHS. (Preventing an ICE on invalid code).
This was noticed during debug of PR81317, but is not a fix for that PR.
This is based on a patch suggested by Segher.
(This will need a revisit if/when we get a
The little-endian VSX code uses rotates to swap the two 64-bit halves of
128-bit scalar modes. This is fine for TImode and V1TImode, but it
isn't really valid to use RTL rotates on floating-point modes like
KFmode and TFmode, and doing that triggered an assert added by the
SVE series. This patch
This patchlet fixes a complaint from translation
projects because some non-quoted key words like
"interrupt" or "signal" caused problems there.
Enclosed the sequence in "WITH_AVRLIBC" because that is
only relevant when AVR-LibC start-up code is in use.
Also warns for functions named "ISR", "SIGN
From: Franklin “Snaipe” Mathieu
Due to an earlier change in gcc that split the dwarf info generation
in two steps (one early, one late), the DIE for unreferenced extern
globals are no longer removed (in fact, they didn't emit it at
all since they had already processed the translation unit and
kne
From: Franklin “Snaipe” Mathieu
Due to an earlier change in gcc that split the dwarf info generation
in two steps (one early, one late), the DIE for unreferenced extern
globals are no longer removed (in fact, they didn't emit it at
all since they had already processed the translation unit and
kne
From: Franklin “Snaipe” Mathieu
Due to an earlier change in gcc that split the dwarf info generation
in two steps (one early, one late), the DIE for unreferenced extern
globals are no longer removed (in fact, they didn't emit it at
all since they had already processed the translation unit and
kne
From: Franklin “Snaipe” Mathieu
Hello GCC folks,
This patch series addresses PR 81135 [1].
* patch 1/3 is for trunk (built/tested on trunk@250093).
* patch 2/3 is the gcc7 backport (built/tested on gcc-7-branch@249680).
* patch 3/3 is the gcc6 backport (built/tested on gcc-6-branch@249671).
[1
> On Jul 12, 2017, at 10:28 AM, David Miller wrote:
>
> From: Qing Zhao
> Date: Wed, 12 Jul 2017 08:49:52 -0500
>
>> and it also clearly mentioned that “specially aligned memory might
>> use this constraint”.
>
> It guarantees the achieve the opposite of what you are trying to do.
>
> That i
This patch adds a warning to the built-in function handling if the user used
the __builtin_cpu_supports and __builtin_cpu_is were used when the compiler was
configured to use an old GLIBC that does not provice the hardware capability
bits. Previously, the compiler would silently change the built-i
On 07/11/2017 06:29 AM, Prathamesh Kulkarni wrote:
@@ -6074,6 +6076,12 @@ In C++ enumerated type mismatches in conditional
expressions are also
diagnosed and the warning is enabled by default. In C this warning is
enabled by @option{-Wall}.
+@item -Wenum-conversion @r{(C, Objective-C only)}
From: Qing Zhao
Date: Wed, 12 Jul 2017 08:49:52 -0500
> and it also clearly mentioned that “specially aligned memory might
> use this constraint”.
It guarantees the achieve the opposite of what you are trying to do.
That is, it can be used to guarantee that something is aligned to a
multiple of
On 07/06/2017 07:25 AM, Daniel P. Berrange wrote:
There are several hundred named attribute keys that have been
introduced over many GCC releases. Applications typically need
to be compilable with multiple GCC versions, so it is important
for developers to know when GCC introduced support for eac
Hi,
After change @236817, AArch64 backend could avoid unnecessary conversion
instructions
for register between different modes now. As a result, GCC could initialize
register
in larger mode and use it later in smaller mode. such def-use chain is not
supported
by current regrename.c analyzer, a
On 07/12/2017 07:13 AM, Trevor Saunders wrote:
On Tue, Jul 11, 2017 at 11:24:45AM -0400, David Malcolm wrote:
+/* Some tokens naturally come in pairs e.g.'(' and ')'.
+ This class is for tracking such a matching pair of symbols.
+ In particular, it tracks the location of the first token,
+
The attached patch fixes PR81362.
npeel was erroneously overwritten by vect_peeling_hash_get_lowest_cost
although the corresponding dataref is not used afterwards. It should be
safe to get rid of the npeel parameter since we use the returned
peeling_info's npeel anyway. Also removed the body_cos
This adds code to the backend rtx_costs function in order to model the
costs of a load/store on condition.
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
2017-07-12 Andreas Krebbel
* config/s390/s390.c (s390_rtx_costs): Return proper costs for
load/store on condi
The backend splitter splitting a 3 operand load on condition into 2 is
wrong. The S/390 load on condition instruction might trap on the
memory operand even if the condition is false. So if the first load
on condition overwrites a register used as part of the memory address
of the second the secon
On 12 July 2017 at 12:15, Jonathan Wakely wrote:
> On 12/07/17 09:46 +0200, Christophe Lyon wrote:
>>
>> On 11 July 2017 at 14:39, Jonathan Wakely wrote:
>>>
>>> On 11/07/17 12:53 +0100, Jonathan Wakely wrote:
On 21/04/17 15:54 +0100, Jonathan Wakely wrote:
>
>
> On 4 A
ptrace SETREGS and GETREGS were never supported on S/390. The macros
were accidentally defined in the Glibc header though. A recent Glibc
change removed them breaking libgo build on S/390.
This patch changes the ptrace calls to use PEEKUSR_AREA/POKEUSR_AREA to
access the register sets. That's w
Hi.
Following patch adds -lspp when one uses -mstack-protector-guard=global.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2017-07-12 Martin Liska
PR middle-end/81400
* gcc.c: Add -lssp when one use
Coprocessor intrinsic tests in gcc.target/arm/acle test whether
__ARM_FEATURE_COPROC has the right bit defined before calling the
intrinsic. This allows to test both the correct setting of that macro
and the availability and correct working of the intrinsic. However the
__ARM_FEATURE_COPROC macro
On 12.07.2017 14:11, Segher Boessenkool wrote:
Hi,
On Tue, Jul 11, 2017 at 10:47:27AM +0200, Georg-Johann Lay wrote:
This small addition improves costs of PARALLELs in
rtlanal.c:seq_cost(). Up to now, these costs are
assumed to be 1 which gives gross inexact costs for,
e.g. divmod which is rep
On Tue, Jul 11, 2017 at 11:24:45AM -0400, David Malcolm wrote:
> +/* Some tokens naturally come in pairs e.g.'(' and ')'.
> + This class is for tracking such a matching pair of symbols.
> + In particular, it tracks the location of the first token,
> + so that if the second token is missing, w
Hi Carl,
On Tue, Jul 11, 2017 at 09:55:31PM -0700, Carl Love wrote:
> 2017-07-11 Carl Love
>
> * config/rs6000/rs6000-c.c: Add support for built-in functions
> vector bool char vec_revb (vector bool char);
> vector bool short vec_revb (vector short char);
> vector bool
On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote:
> On 07/11/2017 06:20 PM, Wilco Dijkstra wrote:
> > Jeff Law wrote:
> >> aarch64 is the first target that does not have any implicit probes in
> >> the caller. Thus at prologue entry it must make conservative
> >> assumptions about the offs
Hi Kelvin,
On Tue, Jul 11, 2017 at 04:43:47PM -0600, Kelvin Nilsen wrote:
> I would like to backport the following patches to the GCC 6 branch.
>
> PR9: Fix failure of gcc.dg/loop-8.c on Power
> https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01788.html
>
> PR68972: g++.dg/cpp1y/vla-initlist
Hi,
On Tue, Jul 11, 2017 at 10:47:27AM +0200, Georg-Johann Lay wrote:
> This small addition improves costs of PARALLELs in
> rtlanal.c:seq_cost(). Up to now, these costs are
> assumed to be 1 which gives gross inexact costs for,
> e.g. divmod which is represented as PARALLEL.
insn_rtx_cost retur
2017-07-12 12:45 GMT+04:00 Georg-Johann Lay :
> Hi, if the C++ front-end decides that something will need constructing,
> it will silently put the stuff into .rodata so that according
> pgm_read_xxx will read garbage from .progmem.
>
> As proposed by Jason, this patch diagnoses such situations.
>
>
On 12/07/17 09:46 +0200, Christophe Lyon wrote:
On 11 July 2017 at 14:39, Jonathan Wakely wrote:
On 11/07/17 12:53 +0100, Jonathan Wakely wrote:
On 21/04/17 15:54 +0100, Jonathan Wakely wrote:
On 4 April 2017 at 20:44, Jonathan Wakely wrote:
We got a bug report from a customer pointing ou
Hi Richard,
On 07/07/17 15:19, Richard Earnshaw (lists) wrote:
Hmm, I think that's because really this is a partial conversion. It
looks like doing this properly would involve moving that existing code
to use sbitmaps as well. I think doing that would be better for
long-term maintenance persp
Hi, if the C++ front-end decides that something will need constructing,
it will silently put the stuff into .rodata so that according
pgm_read_xxx will read garbage from .progmem.
As proposed by Jason, this patch diagnoses such situations.
Ok to commit?
Johann
PR target/81407
*
> Actually, My major question is whether the current handling of
> special_memory_constraint in lra_constraints.c is correct or NOT based on
> GCC internal documentation. I thought that’s independent from this
> misaligned insns generation for M8, but looks I was wrong.
The answer is yes, the curr
On 11 July 2017 at 16:09, Christophe Lyon wrote:
> On 10 July 2017 at 10:01, Christophe Lyon wrote:
>> Hi,
>>
>>
>> On 6 July 2017 at 06:50, Jeff Law wrote:
>>> On 07/04/2017 02:50 AM, Christophe Lyon wrote:
On 3 July 2017 at 17:30, Jeff Law wrote:
> On 07/03/2017 09:00 AM, Christophe
On 11 July 2017 at 14:39, Jonathan Wakely wrote:
> On 11/07/17 12:53 +0100, Jonathan Wakely wrote:
>>
>> On 21/04/17 15:54 +0100, Jonathan Wakely wrote:
>>>
>>> On 4 April 2017 at 20:44, Jonathan Wakely wrote:
We got a bug report from a customer pointing out that calling
promise::se
59 matches
Mail list logo
