Hi,
this patch makes us to diagnoze correctly ODR violations such as:
$ cat tt.C
enum test {val1};
enum test a;
>
> Thanks for the review. I have updated the patch based on the comments
> with some other minor changes. Bootstrapped and regression tested on
> aarch64-none-linux-gnu with no-new regressions. Is this OK for trunk?
>
>
> Thanks,
> Kugan
>
>
> gcc/ChangeLog:
>
> 2015-04-24 Kugan Vivekananda
On 04/24/2015 10:52 AM, Aldy Hernandez wrote:
> In the debug-early work we call dwarf2out early from
> rest_of_decl_compilation.
> Dwarf2out, via gen_struct_or_union_type_die(), will eventually look at
> TYPE_VFIELD, which is currently being overloaded by the C front-end to keep
> incomplete vari
On 21/04/15 06:22, James Greenhalgh wrote:
> On Fri, Apr 17, 2015 at 12:19:14PM +0100, Kugan wrote:
My point is that adding your patch while keeping the logic at the top
which claims to catch ALL vector operations makes for less readable
code.
At the very least you'll need
On Fri, Apr 24, 2015 at 06:34:28PM -0400, Jason Merrill wrote:
> On 04/20/2015 10:35 AM, Jakub Jelinek wrote:
> >Wonder what will happen if finalize_type_size or fixup_attribute_variants
> >is called on a type variant with TYPE_USER_ALIGN before it is called
> >on the TYPE_MAIN_VARIANT; I'd guess t
On 04/20/2015 10:35 AM, Jakub Jelinek wrote:
Wonder what will happen if finalize_type_size or fixup_attribute_variants
is called on a type variant with TYPE_USER_ALIGN before it is called
on the TYPE_MAIN_VARIANT; I'd guess that in that case all the variants
including the main variant would be ma
PR 65616 points out that you can't use gccgo to build a PIE because
go-main.c is not compiled with -fPIC. This patch fixes that. I could
have used -fPIE, but -fPIC is essentially the same here and seems more
flexible. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to m
On 04/24/2015 03:31 PM, Martin Sebor wrote:
On 04/24/2015 10:27 AM, Marek Polacek wrote:
On Thu, Apr 23, 2015 at 09:11:39PM -0600, Martin Sebor wrote:
I wonder if the tests where the left shift operands are both
constants really do invoke undefined behavior in GCC. For
example, AFAICS, in (-1 <
Now that we call dwarf2out earlier in the compilation process, we may
get some error_mark_node's. And of course, nobody likes an ICE...
Committed to branch.
commit 92437112d3d4966eecb31df59a6fa4a1014a198c
Author: Aldy Hernandez
Date: Fri Apr 24 14:24:09 2015 -0700
Make gen_typedef_die h
On 04/24/2015 10:27 AM, Marek Polacek wrote:
On Thu, Apr 23, 2015 at 09:11:39PM -0600, Martin Sebor wrote:
I wonder if the tests where the left shift operands are both
constants really do invoke undefined behavior in GCC. For
example, AFAICS, in (-1 << 0) and other constant expressions
gcc compu
GCC regression hunting.. one more down.
Committed to branch.
commit fe086e62a450538efc06c064530bfd564496d6a6
Author: Aldy Hernandez
Date: Fri Apr 24 14:22:58 2015 -0700
Relax condition in check_die_inline so that DW_AT_inline of 0 is
equivalent to no inline.
diff --git a/gcc/dwarf2o
In the debug-early work we call dwarf2out early from
rest_of_decl_compilation. Dwarf2out, via
gen_struct_or_union_type_die(), will eventually look at TYPE_VFIELD,
which is currently being overloaded by the C front-end to keep
incomplete variables.
Nobody should be looking at the type too in
On 02/17/2015 07:58 AM, Richard Biener wrote:
[ Restarting a old thread... ]
On a closer look the record_const_or_copy_1 hunk is redundant
(record_equality is really a bit obfuscated...).
Agreed. I'm not entirely sure how it got to this point.
And record_equality is where the SSA_NAME_VALUEs
Hi!
In vrp_visit_assignment_or_call we try to return SSA_PROP_VARYING
if update_value_range returned true and the new range is VR_VARYING,
but vrp_visit_phi_node fails to do that.
Another thing is that if update_value_range decides to
set_value_range_to_varying (old_vr);
it doesn't update new_vr,
On 02/09/2015 07:00 PM, Thomas Preud'homme wrote:
And this is part 2.
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
Once this is done, the same thing needs to be applied to XEXP
(reg_equal, 0)
before it is sent to nonzero_bits.
-
On 02/09/2015 06:51 PM, Thomas Preud'homme wrote:
ChangeLog entry for part 1 is as follows:
*** gcc/ChangeLog ***
2015-02-09 Thomas Preud'homme
* combine.c (sign_extend_short_imm): New.
(set_nonzero_bits_and_sign_copies): Use above new function for sign
extension
On 04/24/2015 05:36 AM, Marek Polacek wrote:
On Thu, Apr 23, 2015 at 08:25:51PM -0600, Jeff Law wrote:
What happens if we have used the enum inside an aggregate? Can we just
blindly change the alignment/precision like that?
If you just forward declare an enum/struct, it has an incomplete type
On 02/26/2015 08:26 AM, Chen Gang S wrote:
2015-02-26 Chen Gang
* genrecog.c (validate_pattern): Check matching constraint in
MATCH_OPERAND and use 'opnu' for all 'XINT (pattern, 0)'.
I've updated the ChangeLog and verified the x86_64 continues to build
with this patch. I als
On 04/24/2015 09:46 AM, Kai Tietz wrote:
Sure, we can use here instead *_fully_fold, but for what costs? In
general we need to deal here a simple one-level fold for simplifying
constant-values, and/or removing useless type-conversions.
Well, here you're doing a two-level fold. And in general
On Thu, 23 Apr 2015 18:41:34 +0200
Thomas Schwinge wrote:
> Hi!
>
> On Wed, 22 Apr 2015 19:42:43 +0100, Julian Brown
> wrote:
> > This patch is an attempt to fix some potential race conditions with
> > accesses to shared data structures from multiple concurrent threads
> > in libgomp's OpenACC
Jeff Law writes:
> On 04/21/2015 08:24 AM, Jiong Wang wrote:
>>
>> Jiong Wang writes:
>>
>>> 2015-04-14 18:24 GMT+01:00 Jeff Law :
On 04/14/2015 10:48 AM, Steven Bosscher wrote:
>>
>> So I think this stage2/3 binary difference is acceptable?
>
>
> No, they should be ident
On Thu, Apr 23, 2015 at 09:11:39PM -0600, Martin Sebor wrote:
> I wonder if the tests where the left shift operands are both
> constants really do invoke undefined behavior in GCC. For
> example, AFAICS, in (-1 << 0) and other constant expressions
> gcc computes the shift in unsigned HOST_WIDE_INT
Hi,
This patch adds rtl patterns to generate bics instructions with shift.
Added attribute predicable_short_it since last respin.
Done full regression run on arm-none-eabi and arm-none-gnueabihf.
Bootstrapped on arm-none-gnueabihf.
Is this patch ok?
gcc/config
2015-04-24 Alex Velenko
*
On Fri, Apr 24, 2015 at 11:34 AM, Segher Boessenkool
wrote:
> On Thu, Apr 23, 2015 at 02:16:04PM -0500, Peter Bergner wrote:
>> Ok, I created a separate ttest define_insn that hard codes the operands.
>> I switched to using r1 rather than r0 as the second operand, for the
>> reason that there coul
On Thu, Apr 23, 2015 at 02:16:04PM -0500, Peter Bergner wrote:
> Ok, I created a separate ttest define_insn that hard codes the operands.
> I switched to using r1 rather than r0 as the second operand, for the
> reason that there could be code that sets r0 directly before this insn
> and I didn't wa
-Original Message-
From: Maciej W. Rozycki [mailto:ma...@linux-mips.org]
Sent: Thursday, April 23, 2015 4:55 PM
To: Petar Jovanovic
Cc: gcc-patches@gcc.gnu.org; catherine_mo...@mentor.com; Matthew Fortune
Subject: RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
> I hope you find
Hi all,
We usually use uppercase for code iterator names (and other iterators in
general),
but these few were written in lowercase.
Encountering their use in arm.md and neon.md confused me for a bit
because I thought they were primitive RTL codes.
For the sake of consistency, this patch makes al
On 24/04/15 09:39, Marcus Shawcroft wrote:
On 22 April 2015 at 16:08, Kyrill Tkachov wrote:
On 22/04/15 12:46, Kyrill Tkachov wrote:
[Sorry for resending twice. My mail client glitched]
+/* Native CPU detection for aarch64.
+ Copyright (C) 2014 Free Software Foundation, Inc.
+
That shou
New patch, v4. PTAL.
(resending the patch in plan text format, sorry for the multiple emails, I
am going to switch back to git-send-email)
Regards,
Petar
gcc/ChangeLog:
2015-04-21 Petar Jovanovic
* config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Fix the macro to
use
la/jalr in
potential_constant_expression_1 originally implemented an early version
of the constexpr proposal, which included a concept of "potential
constant expression" that no longer exists in the standard. It's still
useful for catching expressions that could never be constant, but these
two are obsol
On 24-04-15 05:25, Bin.Cheng wrote:
On Tue, Apr 21, 2015 at 3:10 PM, Tom de Vries wrote:
Hi,
this patch fixes PR65802.
diff --git a/gcc/testsuite/g++.dg/
pr65802.C b/gcc/testsuite/g++.dg/pr65802.C
new file mode 100644
index 000..26e5317
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr65802.C
On Thu, Apr 23, 2015 at 3:25 PM, Michael Meissner
wrote:
> Steve Munroe was tuning an application on PowerPC, and needed to set the
> -msave-toc-indirect option for only one function, and it wasn't available via
> the #praga/attribute target options. This patch adds support for the
> additional o
2015-04-24 6:22 GMT+02:00 Jason Merrill :
>> + expr = fold (expr);
>>/* This may happen, because for LHS op= RHS we preevaluate
>> RHS and create C_MAYBE_CONST_EXPR >, which
>> means we could no longer see the code of the EXPR. */
>>if (TREE_CODE (expr) == C_MAYBE_CONST_EXPR)
On 24/04/15 02:16, Jeff Law wrote:
On 04/10/2015 03:14 AM, Alex Velenko wrote:
On 09/03/15 17:40, Jeff Law wrote:
On 03/09/15 03:53, Steven Bosscher wrote:
On Wed, Mar 4, 2015 at 12:09 PM, Alex Velenko wrote:
For example, in arm testcase pr43920-2.c, CSE previously decided not
to put
an "ob
On Thu, Apr 23, 2015 at 08:25:51PM -0600, Jeff Law wrote:
> What happens if we have used the enum inside an aggregate? Can we just
> blindly change the alignment/precision like that?
If you just forward declare an enum/struct, it has an incomplete type, so you
cannot use it inside an aggregate.
> > I added cunrolle pass that differ from cunrolli by not allowing code size
> > growth even at -O3 (because we do not know what loops are hot yet).
> > We currently unroll tiny loop with 2 calls that I think needs to be tammed
> > down, I can do that if the patch seems to make sense.
>
> Please.
Hello!
This patch revives the old patch from Wei to merge movlpd/movsd with
movhpd to movupd. As evident from the patch, the patch merges only
instructions with simple memory references, which should IMO cover all
interesting cases (please see the included testcases).
I have played a bit with loa
Hi,
first of all, sorry for the delay. We quickly entered stage 4 and I thought
it was best waiting for stage 1 to update you on this.
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> Of course both approaches are not exclusive.
On 23 April 2015 at 17:36, Jakub Jelinek wrote:
> Hi!
>
> This patch undoes the PR65780 performance regressions on a few targets
> I have tested to work fine.
> This PR was about an access to uninitialized COMMON symbol defined in
> executable (or PIE) where there is a normal symbol definition in
> 2015-04-23 Steve Ellcey
>
> * config/mips/mips.md: (*madd4) Remove accum_in attribute.
> (*madd3): Ditto.
> (*msub4): Ditto.
> (*msub3): Ditto.
> (*nmadd4): Ditto.
> (*nmadd3): Ditto.
> (*nmadd4_fastmath): Ditto.
> (*nmadd3_fastmath): Ditto.
>
On 22 April 2015 at 16:08, Kyrill Tkachov wrote:
>
> On 22/04/15 12:46, Kyrill Tkachov wrote:
>>
>> [Sorry for resending twice. My mail client glitched]
+/* Native CPU detection for aarch64.
+ Copyright (C) 2014 Free Software Foundation, Inc.
+
That should be 2015, otherwise OK.
Cheers
/Mar
-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
Sent: Friday, April 24, 2015 12:40 AM
To: Ajit Kumar Agarwal
Cc: vmaka...@redhat.com; GCC Patches; Vinod Kathail; Shail Aditya Gupta;
Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [Patch] OPT: Update heu
Hi all,
Just to clear things up, with
> I have tested the code in the comments of pr61831 with v2 of this patch and
> got no issues.
I meant, that I have checked the code in comment #28 of pr61831. With only
this patch, there still is an illegal free() of unallocated memory.
With this patch and
Ping!
This ICE is still in gfortran and with it the patch still current.
Bootstrapped and regtests ok on x86_64-linux-gnu/F21.
The patch has only changed in being applyable on current trunk (ct) w/o big
shifts.
Ok for trunk?
- Andre
This crash is still current
On Fri, 13 Mar 2015 11:33:39 +
On Fri, 24 Apr 2015, Jan Hubicka wrote:
> Hi,
> I was looking into reordering optimization queue of early passes. This is
> motivated by PR57249 and fact that I run into some super sily loops while
> looking into firefox dumps. It indeed makes a lot of sense for me as for
> code
> dealing with
On Thu, Apr 23, 2015 at 5:49 PM, Jason Merrill wrote:
> In general, TYPE_CANONICAL of a type strips all attributes. An exception to
> this seems to be that TYPE_REF_CAN_ALIAS_ALL remains set on the
> TYPE_CANONICAL of a pointer/reference type even though its TREE_TYPE no
> longer has the may_alia
On Fri, 24 Apr 2015, Jakub Jelinek wrote:
> On Thu, Apr 23, 2015 at 04:31:52PM -0700, H.J. Lu wrote:
> > Hi,
> >
> > I checked this patch into gcc-5-branch.
>
> That's wrong according to https://gcc.gnu.org/develop.html#num_scheme
Yes. Please revert.
In future please don't do this kind of cha
Hello!
2015-04-24 Uros Bizjak
* config/i386/sse.md (*vec_widen_smult_even_v8si):
Mark operand1 commutative.
Tested on x86_64-linux-gnu {,-m32} and committed to mainline and 5.0 branch.
Uros.
Index: config/i386/sse.md
==
Hi Kyrill,
I checked this patch on AMD seattle board and it bootstrapped cleanly with
BOOT_CFLAGS=-O2 -mcpu=native and CFLAGS_FOR_TARGET=-O2 -mcpu=native.
With -mcpu=cortex-57, I get
.cpu cortex-a57+fp+simd+crc
options passed: test.c -mcpu=cortex-a57 -mlittle-endian -mabi=lp64
-auxbase-s
49 matches
Mail list logo
