On 21 March 2017 at 08:48, Jakub Jelinek wrote:
> Formatting etc. nits:
>
>> 2017-03-21 Ville Voutilainen
>>
>> gcc/
>>
>> PR c++/35878
>
> This should go into gcc/cp/ ChangeLog
>
>> * cp/init.c (std_placement_new_fn_p): New.
>
> without cp/ here.
Yeah, so modified before the commi
Hi!
On Tue, Mar 21, 2017 at 03:21:11AM +0200, Ville Voutilainen wrote:
Formatting etc. nits:
> 2017-03-21 Ville Voutilainen
>
> gcc/
>
> PR c++/35878
This should go into gcc/cp/ ChangeLog
> * cp/init.c (std_placement_new_fn_p): New.
without cp/ here.
> (build_new_1): Cal
On Wed, Mar 15, 2017 at 8:20 AM, Wilco Dijkstra wrote:
> Hi,
>
> I think the patch isn't quite complete yet. You will also need changes in
> generic code. Currently sched_macro_fuse_insns() does:
>
> if (any_condjump_p (insn))
> {
> unsigned int condreg1, condreg2;
> rtx cc_reg_1
On Mon, Mar 20, 2017 at 7:58 PM, Martin Sebor wrote:
> On 03/20/2017 05:51 PM, Jason Merrill wrote:
>> On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
>>>
>>> Attached is a minimal patch to avoid an ICE in CHKP upon
>>> encountering one form of an initializer for a flexible array
>>> member,
OK. Let's leave the BZ open to help remember to remove the
cxx_dialect check in stage 1.
Jason
On Mon, Mar 20, 2017 at 9:21 PM, Ville Voutilainen
wrote:
> On 21 March 2017 at 02:46, Ville Voutilainen
> wrote:
>> On 21 March 2017 at 02:43, Ville Voutilainen
>> wrote:
>>> Hmm. I should either r
On 21 March 2017 at 02:46, Ville Voutilainen
wrote:
> On 21 March 2017 at 02:43, Ville Voutilainen
> wrote:
>> Hmm. I should either rename that function or flip its logic. Now it's
>> a bit backwards. :) I'll flip its logic.
>
> In other words, see attached.
Let's call the function what it reall
On 21 March 2017 at 02:43, Ville Voutilainen
wrote:
> Hmm. I should either rename that function or flip its logic. Now it's
> a bit backwards. :) I'll flip its logic.
In other words, see attached.
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index dc5a5f7..a6be32e 100644
--- a/gcc/cp/init.c
+++ b/g
On 21 March 2017 at 02:36, Ville Voutilainen
wrote:
> On 21 March 2017 at 01:44, Jason Merrill wrote:
>>> It looks strange to me. Why not change the definition of check_new instead
>>> of changing the condition that uses it?
>>
>> Agreed. Also, let's factor the new tests out into a function, say
On 21 March 2017 at 01:44, Jason Merrill wrote:
>> It looks strange to me. Why not change the definition of check_new instead
>> of changing the condition that uses it?
>
> Agreed. Also, let's factor the new tests out into a function, say
> non_allocating_fn_p.
This also conveniently let's me pr
On Sat, Mar 18, 2017 at 11:23:56AM -0500, Segher Boessenkool wrote:
> > >So, no, I'm not okay with this. It is very expensive, it is doing open
> > >heart surgery on combine's internal structures (in a way that may or may
> > >not work), and all that to combine some insns in a case that should not
On 03/20/2017 05:51 PM, Jason Merrill wrote:
On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
Attached is a minimal patch to avoid an ICE in CHKP upon
encountering one form of an initializer for a flexible array
member, specifically the empty string:
int f ()
{
struct B { int n; ch
On Mon, Mar 20, 2017 at 7:04 PM, Martin Sebor wrote:
> Attached is a minimal patch to avoid an ICE in CHKP upon
> encountering one form of an initializer for a flexible array
> member, specifically the empty string:
>
> int f ()
> {
> struct B { int n; char a[]; };
>
> return ((struct
On Mon, Mar 20, 2017 at 7:41 PM, Marc Glisse wrote:
> On Tue, 21 Mar 2017, Ville Voutilainen wrote:
>
>> On 20 March 2017 at 04:27, Jason Merrill wrote:
>>> On Sun, Mar 19, 2017 at 6:19 PM, Ville Voutilainen
>>> wrote:
I ran the tests for g++.dg/init thus far. Does this patch make sense?
>>
On Tue, 21 Mar 2017, Ville Voutilainen wrote:
On 20 March 2017 at 04:27, Jason Merrill wrote:
On Sun, Mar 19, 2017 at 6:19 PM, Ville Voutilainen
wrote:
I ran the tests for g++.dg/init thus far. Does this patch make sense?
The condition needs to be a lot more specific: DR 1748 only applies
On Sun, 19 Mar 2017, Andreas Schwab wrote:
>> @anchor{sparc-x-linux}
>> @heading sparc-*-linux*
> The section is now empty. Should it be removed at all?
I considered that, but then figured we do want to keep this as
an indicator this is a supported platform (and also placeholder
if/when any new
On 20 March 2017 at 04:27, Jason Merrill wrote:
> On Sun, Mar 19, 2017 at 6:19 PM, Ville Voutilainen
> wrote:
>> I ran the tests for g++.dg/init thus far. Does this patch make sense?
>
> The condition needs to be a lot more specific: DR 1748 only applies to
> the non-allocating forms in [new.dele
Hi,
As requested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80094
i'm attaching a patch for the issue described.
Specifically:
when the plugin_name_args_tab hash table has its 11th entry inserted, it
trigers a hash table resize. This resize performs the hash_f against
each slot's value. Th
Attached is a minimal patch to avoid an ICE in CHKP upon
encountering one form of an initializer for a flexible array
member, specifically the empty string:
int f ()
{
struct B { int n; char a[]; };
return ((struct B){ 1, "" }).a[0];
}
Although GCC accepts (and doesn't ICE on) non
On Mon, Mar 20, 2017 at 10:08:25PM +, Moore, Catherine wrote:
> I'm okay with the workaround for stage 4, but would like to see the pr remain
> open until a proper fix is installed on trunk.
Yeah.
> Toma, would you be able to pursue the original patch that you attached to the
> bug report?
On 03/21/2017 07:15 AM, Jakub Jelinek wrote:
Not really sure what we should do if both i1 and i2 are frame related, shall
we check for each of the CFA reg notes if they are available and equal?
Or punt if either of the insns is frame related?
I would punt if either is frame related.
As an asid
On Mon, 20 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> The C fully folding code expects that EXCESS_PRECISION_EXPR is never
> the rhs of a COMPOUND_EXPR, instead it should wrap the whole COMPOUND_EXPR
> if needed. The following patch does that, bootstrapped/regtested on
> x86_64-linux and i686-linu
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Wednesday, March 15, 2017 11:30 AM
> To: Moore, Catherine
> Cc: Segher Boessenkool (seg...@kernel.crashing.org)
> ; Toma Tabacu
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Fix MIPS-specific IC
Hi!
libtsan atomics aren't throwing, so if we transform atomics which
are throwing with -fnon-call-exceptions, we need to clean up EH stuff.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-03-20 Jakub Jelinek
PR sanitizer/80110
* tsan.c: Include tree
Hi!
libtsan only handles the standard memory model values, so I've added
just in case some new unknown memory model is used bail outs (keeping
the __atomic_* builtins instead of transforming them to __tsan_atomic*).
Except that at -O0 (or if unlucky enough otherwise) if the memory model
is variabl
Hi!
On ppc64le we ICE on the following testcase, because during jump2 we decide
to cross-jump
(insn/f 62 61 63 5 (unspec_volatile [
(const_int 0 [0])
] UNSPECV_BLOCK) "pr80102.C":9 -1
(expr_list:REG_CFA_RESTORE (reg:DI 30 30)
(nil)))
(jump_insn 63 62 90 5 (simple_r
On Thu, Feb 23, 2017 at 6:33 PM, Jason Merrill wrote:
> On Thu, Feb 23, 2017 at 12:56 PM, Martin Sebor wrote:
>> On 02/22/2017 05:43 PM, Jason Merrill wrote:
>>> On Wed, Feb 22, 2017 at 3:44 PM, Martin Sebor wrote:
On 02/22/2017 11:02 AM, Jason Merrill wrote:
>
The TREE_USED bit on the
OK.
On Fri, Mar 10, 2017 at 5:38 PM, Paolo Carlini wrote:
> Hi,
>
> On 10/03/2017 16:57, Jason Merrill wrote:
>>
>> On Fri, Mar 10, 2017 at 9:58 AM, Paolo Carlini
>> wrote:
>>>
>>> As such, the broken declaration cannot be rejected by the code we have in
>>> finish_struct, something must happen
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Wednesday, March 15, 2017 11:37 AM
> To: Moore, Catherine
> Cc: Toma Tabacu ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [PATCH,testsuite] Skip gcc.dg/pic-2.c and gcc.dg/pie-2.c for
> MIPS.
>
> Toma
Hi!
The C fully folding code expects that EXCESS_PRECISION_EXPR is never
the rhs of a COMPOUND_EXPR, instead it should wrap the whole COMPOUND_EXPR
if needed. The following patch does that, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
2017-03-20 Jakub Jelinek
Hi!
divisor is unsigned int parameter, if it is 0x8000, we invoke UB.
val is wide_int, so (int) -divisor achieves the same result without UB.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-03-20 Jakub Jelinek
PR c/67338
* fold-const.c (round_up_
On Mon, Mar 20, 2017 at 01:43:37PM -0500, Segher Boessenkool wrote:
> > --- gcc/config/rs6000/rs6000.md (revision 246224)
> > +++ gcc/config/rs6000/rs6000.md (working copy)
> > @@ -6727,7 +6727,7 @@
> >[(set (match_operand:SI 0 "rs6000_nonimmediate_operand"
> > "=r,
A while back I fixed =delete of namespace-scope friend functions, but
that led to this ICE. Fixed by recognizing that =delete is also a
definition in the place that checks for inappropriate definitions of
friend functions.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0ba077c5f36b64b1c1bd
Normally tsubst substitutes into the TREE_TYPE of the argument before
proceeding; that's wrong for an auto template parameter, which should
just get the appropriate type from its non-type argument.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 63a21767d094ac5c7b1a1ca0cd3d0366411c1a77
Autho
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 shows a case where
pass_stdarg ICEs attempting to gimplify a COMPLEX_EXPR with side
effects as an lvalue. This occurs when the LHS of a VA_ARG has been
cast away. This patch, credit to Richard Biener, uses
force_gimple_operand to instantiate
On Mar 20, 2017, at 3:26 AM, Richard Biener wrote:
>
> Hmm, I think force_gimple_oeprand overwrites what is in &pre so can
> you try with using a temporary sequence for force_gimple_operand and
> appending that to pre afterwards instead?
Indeed, that solves the problem. I'll prepare the patch f
We crash with this invalid testcase because we aren't properly checking what we
are passing down to get_range_info, i.e., we can't pass a pointer. So fixed by
checking the argument first, and calling alloca_type_and_limit if it is of a
wrong type.
Bootstrapped/regtested on x86_64-linux, ok for tr
On Mon, Mar 20, 2017 at 01:05:15PM -0500, Aaron Sawdey wrote:
> > 2017-03-20 Aaron Sawdey
> >
> > PR target/80083
> > * config/rs6000/rs6000.md (*movsi_internal1): incorrect
> > constraints
> > for alternatives 14/15.
A changelog line should describe what is changed, not what was w
Here, when we try to look up a constant variable from an enclosing
function when instantiating a generic lambda outside of the context of
that function, we make a dummy instantiation to use. In this case,
the initializer refers to the variable, so we infinitely recurse until
we run out of stack.
On Mon, 2017-03-20 at 11:11 -0500, Aaron Sawdey wrote:
> Test libgomp doacross2.f90 failed only at -O1 because an incorrect
> constraint on movsi_internal1 (for vspltisw) led to confusion between
> vsx and float registers (fix credit to Meissner). In subsequent
> discussion David Edelsohn pointed o
On Fri, Mar 17, 2017 at 02:42:27PM +0100, Richard Biener wrote:
> 2017-03-17 Richard Biener
>
> PR tree-optimization/80032
> * gimplify.c (gimple_push_cleanup): Add force_uncond parameter,
> if set force the cleanup to happen unconditionally.
> (gimplify_target_expr): Pu
Dear Nicolas,
This is indeed an obvious fix and it's OK for trunk
However, we would prefer it that you submit even blindingly obvious
patches for a while. You can generally get rapid approval for such
patches by joining us on #gfortran.
Thanks for the patch.
Paul
PS Are you going to have a sta
On 03/20/2017 10:53 AM, Jakub Jelinek wrote:
On Mon, Mar 20, 2017 at 10:44:25AM -0600, Martin Sebor wrote:
/home/marek/src/gcc/gcc/sanitizer.def:459:1: note: in expansion of macro
‘DEF_SANITIZER_BUILTIN’
DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_TYPE_MISMATCH_ABORT
I would view these as he
On Mär 20 2017, "Richard Earnshaw (lists)" wrote:
> I don't have access to an ILP32 run-time environment, so I'm not sure
> how I'll be able to check this out. There are some pointer checks in
> the code so it's possible something is going awry. Can you compare the
> assembly output for ILP32 a
Hi,
I've tested this with GCC 7.0 on powerpc-ibm-aix7.2.0.0
This test adds periods as a valid character for symbol names. Periods
are allowed in symbol names but I am unsure if they have a special
meaning at the beginning of a name that changes the meaning of this
test. Currently my GFortran is g
2017-03-20 Violeta Menendez Gonzalez
Change test to expected PASS instead of XFAIL on AIX 6 or above.
For these versions the precision of the floating point for printf was
increased from 17 digits to 37 digits
https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.basetrf1/printf.htm
On Mon, Mar 20, 2017 at 10:44:25AM -0600, Martin Sebor wrote:
> > /home/marek/src/gcc/gcc/sanitizer.def:459:1: note: in expansion of macro
> > ‘DEF_SANITIZER_BUILTIN’
> > DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_TYPE_MISMATCH_ABORT
>
> I would view these as helpful errors and expect them to b
Merged trunk revision 246276 (b105e82d5ab) into gcn branch.
Martin.
ChangeLog | 20 +
MAINTAINERS| 14 +-
config.guess | 16 +-
gcc/ChangeLog
On 03/20/2017 07:42 AM, Marek Polacek wrote:
On Mon, Mar 20, 2017 at 09:37:10AM -0400, Jason Merrill wrote:
On Mon, Mar 20, 2017 at 9:28 AM, Marek Polacek wrote:
#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
+ do { \
On Fri, 17 Mar 2017 15:52:54 PDT (-0700), Palmer Dabbelt wrote:
> The RISC-V memory model is still in the process of being formally
> specified, so for now we're going to be safe and add the I/O bits to
> userspace fences because there's no way to know if userspace is touching
> memory-mapped I/O r
On Fri, 17 Mar 2017 15:52:50 PDT (-0700), Palmer Dabbelt wrote:
> From: Andrew Waterman
>
> The test is coupled to the branch cost model.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/ssa-thread-14.c: Adjust target selector.
> ---
> gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c | 2 +-
On Fri, 17 Mar 2017 15:54:16 PDT (-0700), Palmer Dabbelt wrote:
> On RISC-V we can't store integers in floating-point registers as this is
> forbidden by the ISA. We've always disallowed this, but we were
> setting the preferred mode to FP_REGS for some integer modes. This
> caused the LRA to blo
Whoops, I guess I dropped the ball on this one.
Committed.
On Sun, 19 Mar 2017 02:19:07 PDT (-0700), kito.ch...@gmail.com wrote:
> ping.
>
> On Thu, Feb 9, 2017 at 2:50 AM, Palmer Dabbelt wrote:
>> 2017-02-08 Palmer Dabbelt
>>
>> * MAINTAINERS (CPU Port Maintainers): Add Kito Cheng, P
Test libgomp doacross2.f90 failed only at -O1 because an incorrect
constraint on movsi_internal1 (for vspltisw) led to confusion between
vsx and float registers (fix credit to Meissner). In subsequent
discussion David Edelsohn pointed out that there was an additional
error on the constraint for xxs
On 20/03/17 14:53, Andreas Schwab wrote:
> On Nov 07 2016, "Richard Earnshaw (lists)" wrote:
>
>> This patch contains an implementation of search_line_fast for the CPP
>> lexer. It's based in part on the AArch32 (ARM) code but incorporates
>> new instructions available in AArch64 (reduction add
On Nov 07 2016, "Richard Earnshaw (lists)" wrote:
> This patch contains an implementation of search_line_fast for the CPP
> lexer. It's based in part on the AArch32 (ARM) code but incorporates
> new instructions available in AArch64 (reduction add operations) plus
> some tricks for reducing the
OK.
On Mon, Mar 20, 2017 at 10:36 AM, Marek Polacek wrote:
> On Sat, Mar 18, 2017 at 12:47:39PM -0400, Jason Merrill wrote:
>> On Fri, Mar 17, 2017 at 10:45 AM, Marek Polacek wrote:
>> > + cond = instantiate_non_dependent_expr_sfinae (cond, tf_none);
>>
>> Why this rather than instantiate_n
On Sat, Mar 18, 2017 at 12:47:39PM -0400, Jason Merrill wrote:
> On Fri, Mar 17, 2017 at 10:45 AM, Marek Polacek wrote:
> > + cond = instantiate_non_dependent_expr_sfinae (cond, tf_none);
>
> Why this rather than instantiate_non_dependent_expr (and so tf_error)?
Hmm, I hadn't thought about
On Mon, Mar 20, 2017 at 09:37:10AM -0400, Jason Merrill wrote:
> On Mon, Mar 20, 2017 at 9:28 AM, Marek Polacek wrote:
> > #define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
> > + do { \
> > +decl = add_builtin_function ("
On Mon, Mar 20, 2017 at 09:37:10AM -0400, Jason Merrill wrote:
> On Mon, Mar 20, 2017 at 9:28 AM, Marek Polacek wrote:
> > #define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
> > + do { \
> > +decl = add_builtin_function ("
On Mon, Mar 20, 2017 at 9:28 AM, Marek Polacek wrote:
> #define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
> + do { \
> +decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM,
> \
> +
PVS-Studio tool complained about this and it's right, macros shouldn't expand
to multiple statements like this.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2017-03-20 Marek Polacek
PR sanitizer/80063
* asan.c (DEF_SANITIZER_BUILTIN): Use do { } while (0).
diff
Missing case for ARCEM cpus. Add it.
libgcc/
2016-09-29 Claudiu Zissulescu
* config/arc/ieee-754/divdf3.S (__divdf3): Use __ARCEM__.
---
libgcc/config/arc/ieee-754/divdf3.S | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libgcc/config/arc/ieee-754/divdf3.S
ARC can use scaled offsets when loading (i.e. ld.as rA,[base,
offset]). Where base and offset can be a register or an immediate
operand. The scaling only applies on the offset part of the
instruction. The compiler can accept an address like this:
(plus:SI (mult:SI (reg:SI 2 r2 [orig:596 _2129 ]
Durring compilation process, (subreg (mem ...) ...) can occur. Hence,
we need to check if the address of mem is a valid one. This patch is
fixing this check by directly calling the address_operand, instead of
calling move_double_src_operand, as the latter is always checking
against the original mod
No need for thread pointer in bare metal toolchain. Use TP register normally.
gcc/
2016-09-29 Claudiu Zissulescu
* config/arc/elf.h (ARGET_ARC_TP_REGNO_DEFAULT): Define.
* config/arc/linux.h (ARGET_ARC_TP_REGNO_DEFAULT): Likewise.
* config/arc/arc.opt (mtp-regno): Use A
BLIBK register needs to be saved/restored in a interrupt. Fix this issue.
gcc/
2016-09-21 Claudiu Zissulescu
* config/arc/arc.c (arc_epilogue_uses): BLINK should be also
restored when in interrupt.
* config/arc/arc.md (simple_return): ARCv2 rtie instruction
does
Hi Andrew,
This is a set of 5 patches that are fixing a number of issues observed
during dejagnu testing. Each patch has a small description about what
it solves.
Ok to apply?
Claudiu
Claudiu Zissulescu (5):
[ARC] Save/restore blink when in ISR.
[ARC] Fix detection of long immediate for load
The following fixes dangling SSA names running havoc with
"simple" out-of-SSA coalescing.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2017-03-20 Richard Biener
PR tree-optimization/80113
* graphite-isl-ast-to-gimple.c (copy_loop_phi_nodes): Do no
Hi!
On Fri, Mar 10, 2017 at 07:57:39PM +0100, Jakub Jelinek wrote:
> On Fri, Mar 10, 2017 at 07:52:37PM +0100, Bernd Schmidt wrote:
> > On 03/10/2017 06:53 PM, Jakub Jelinek wrote:
> > > +
> > > +template
> > > +static inline rtx
> > > +ix86_delegitimize_address_tmpl (rtx x)
> > > {
> >
> > Why
Dear Nicolas,
This is OK for trunk.
Thanks for the patch.
Paul
On 19 March 2017 at 14:34, Nicolas Koenig wrote:
> Hello Paul,
>
> there isn't really a reason for that except for not knowing where to put the
> error. Attached are the new patch & test case.
>
> The paperwork is done and I have c
On Fri, Mar 17, 2017 at 6:27 PM, Bill Schmidt
wrote:
>
>> On Mar 17, 2017, at 9:52 AM, Bill Schmidt
>> wrote:
>>
>> Hi,
>>
>>> On Mar 17, 2017, at 6:44 AM, Richard Biener
>>> wrote:
>>>
>>> No, I was confused in thinking gimplify_expr would handle the case
>>> properly. For
>>> just gimplifyi
71 matches
Mail list logo
