On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
> Meanwhile your patch is ok.
As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
can appear in the vtable and it has pretty much the same properties
as __builtin_unreachable (void return value, no arguments, noret
Hi!
Linus complained about padding inserted in between asm goto. In 4.8
even -mtune=generic performs ix86_avoid_jump_mispredicts, in 4.9 only e.g.
-mtune=atom and others, but not generic.
The issue is that assuming every asm goto must contain a jump is too
pessimistic, often asm goto (may) transf
Hi!
I've noticed that especially with the AVX512F introduction we use
GET_MODE_SIZE (mode) quite heavily in the i386 *.md files, and
the problem with that is GET_MODE_SIZE isn't a compile time constant,
needs to read mode_size array (non-const) at runtime.
This patch attempts to decrease the enor
Hi!
This is an attempt to port my recent
http://gcc.gnu.org/viewcvs?rev=204219&root=gcc&view=rev
http://gcc.gnu.org/viewcvs?rev=205663&root=gcc&view=rev
http://gcc.gnu.org/viewcvs?rev=206090&root=gcc&view=rev
changes also to AVX512F. The motivation is to get:
#include
__m512i
foo (void *x, voi
On Fri, Jan 3, 2014 at 9:48 AM, Jakub Jelinek wrote:
> I've noticed that especially with the AVX512F introduction we use
> GET_MODE_SIZE (mode) quite heavily in the i386 *.md files, and
> the problem with that is GET_MODE_SIZE isn't a compile time constant,
> needs to read mode_size array (non-co
Jakub Jelinek wrote:
>On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
>> Meanwhile your patch is ok.
>
>As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
>can appear in the vtable and it has pretty much the same properties
>as __builtin_unreachable (void retur
In addition this patch fixes PR 59662.
Also: Ping!
Cheers,
Janus
2013/12/31 Janus Weil :
> Hi all,
>
> ... and the reg-bashing continues: Here is a small patch to fix a
> bind(c) problem. It essentially prevents 'resolve_global_procedure' to
> be applied to bind(c) procedures.
>
> Regtested on
On Fri, Jan 03, 2014 at 10:26:44AM +0100, Richard Biener wrote:
> Jakub Jelinek wrote:
> >On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
> >> Meanwhile your patch is ok.
> >
> >As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
> >can appear in the vtable and
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 10:26:44AM +0100, Richard Biener wrote:
> > Jakub Jelinek wrote:
> > >On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
> > >> Meanwhile your patch is ok.
> > >
> > >As discussed in the PR, the patch wasn't sufficien
On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote:
> > Well, see PR59630. The question is if having to handle it everywhere
> > is worth it.
>
> Well, this case happens because we go back to GENERIC which doesn't
> have this feature. So "everywhere" is somewhat a broad stmt.
> It's
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote:
> > > Well, see PR59630. The question is if having to handle it everywhere
> > > is worth it.
> >
> > Well, this case happens because we go back to GENERIC which doesn't
> > have this featu
On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
> so if there is a decl then use its type signature, otherwise
> (indirect calls) use the caller signature (and hope it matches
> the callee...). That it later falls back to looking at
> DECL_ARGUMENTS is odd (probably a FE issue wher
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
> > so if there is a decl then use its type signature, otherwise
> > (indirect calls) use the caller signature (and hope it matches
> > the callee...). That it later falls back to looking at
On Fri, 3 Jan 2014, Richard Biener wrote:
> On Fri, 3 Jan 2014, Jakub Jelinek wrote:
>
> > On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
> > > so if there is a decl then use its type signature, otherwise
> > > (indirect calls) use the caller signature (and hope it matches
> > >
Hi!
Since the r205959 SCEV changes for peeled chrec, apparently we can end up
with multiple PHIs on the to be vectorized loop that have the same arguments
(both on preheader and latch edges). slpeel_update_phi_nodes_for_guard1
doesn't like that, it asserts that for the argument from the latch edg
On Fri, Jan 03, 2014 at 11:24:53AM +0100, Richard Biener wrote:
> works just fine for me but shows
>
> int (*) () f;
>
> int _4;
>
>
On Thu, Jan 2, 2014 at 11:18 PM, Eric Botcazou wrote:
>> Note that it has unexpected side-effects: previously, in 32-bit mode,
>> 256-bit aggregate objects would have been given 256-bit alignment; now,
>> they will fall back to default alignment, for example 32-bit only.
>
> In case this wasn't cl
> When compiled with -m32 -mavx, we get:
>
> .align 32
> .type a, @object
> .size a, 32
> a:
>
> so, the alignment was already raised elsewhere. We get .align 16 for
> -msse -m32 when vectorizing.
>
> without -msse (and consequently without vectorizing), we get for -m
On Fri, Jan 3, 2014 at 12:20 PM, Eric Botcazou wrote:
>> When compiled with -m32 -mavx, we get:
>>
>> .align 32
>> .type a, @object
>> .size a, 32
>> a:
>>
>> so, the alignment was already raised elsewhere. We get .align 16 for
>> -msse -m32 when vectorizing.
>>
>> with
Personally, I consider the testing insufficent, although the testing
was already insufficient! Note that this is my opinion, don't assume I
talk for all of libstdc++!
After I broke std::nth_element in 4.8.2 (woops), I am of the view that
the libstdc++ testsuite is defficient -- many code paths are
On Fri, Jan 03, 2014 at 12:25:00PM +0100, Uros Bizjak wrote:
> I am testing a patch that removes "max_align" part from ix86_data_alignment.
That looks like unnecessary pessimization. Note the hunk in question is
guarded with opt, which means it is an optimization rather than ABI issue,
it can inc
On Fri, Jan 3, 2014 at 9:37 AM, Jakub Jelinek wrote:
> Linus complained about padding inserted in between asm goto. In 4.8
> even -mtune=generic performs ix86_avoid_jump_mispredicts, in 4.9 only e.g.
> -mtune=atom and others, but not generic.
> The issue is that assuming every asm goto must cont
__builtin_{FILE,FUNCTION} had wrong return types, thus fixed.
Tested by make html and links -g. Ok for trunk?
2014-01-03 Marek Polacek
PR other/59661
* doc/extend.texi: Fix the return value of __builtin_FUNCTION and
__builtin_FILE.
--- gcc/doc/extend.texi.mp 2014
On Fri, Jan 03, 2014 at 01:03:24PM +0100, Marek Polacek wrote:
> __builtin_{FILE,FUNCTION} had wrong return types, thus fixed.
> Tested by make html and links -g. Ok for trunk?
Ok, thanks.
> 2014-01-03 Marek Polacek
>
> PR other/59661
> * doc/extend.texi: Fix the return value of
On Fri, Jan 3, 2014 at 12:59 PM, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 12:25:00PM +0100, Uros Bizjak wrote:
>> I am testing a patch that removes "max_align" part from ix86_data_alignment.
>
> That looks like unnecessary pessimization. Note the hunk in question is
> guarded with opt, whic
This patch fixes a loophole in the -fstack-protector-strong protection.
If a function call uses the return slot optimization, the caller needs
stack protector instrumentation because the return slot is addressable.
Bootstrapped and regression-tested on x86_64-redhat-linux-gnu, with
C/C++/Java
Kyrill Tkachov wrote:
>This patch adds the recently introduced cores to the t-aprofile
>multilib
>machinery. The values added are cortex-a15.cortex-a7, cortex-a12,
>cortex-a57 and
>cortex-a57.cortex-a53.
Are you going to add this to the release notes (gcc-4.9/changes.html) or will
this be part
"H.J. Lu" wrote:
>This patch adds Intel microarchitecture changes to GCC 4.9
>changes.html.
>OK to install?
Okay, modulo the fix Bernhard noted.
Thanks,
Gerald
Renlin Li wrote:
>Hi all,
>
>This patch will add armv7ve support to gcc. Armv7ve is basically a
>armv7-a architecture profile with Virtualization Extensions.
Mind adding this to the release notes?
Gerald
On Fri, Jan 3, 2014 at 1:27 PM, Uros Bizjak wrote:
>>> I am testing a patch that removes "max_align" part from ix86_data_alignment.
>>
>> That looks like unnecessary pessimization. Note the hunk in question is
>> guarded with opt, which means it is an optimization rather than ABI issue,
>> it ca
On Fri, Jan 03, 2014 at 02:35:36PM +0100, Uros Bizjak wrote:
> Like in the patch below. Please note, that the block_tune setting for
> the nocona is wrong, -march=native on my trusted old P4 returns:
>
> --param "l1-cache-size=16" --param "l1-cache-line-size=64" --param
> "l2-cache-size=2048" "-mt
On Fri, Jan 3, 2014 at 2:43 PM, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 02:35:36PM +0100, Uros Bizjak wrote:
>> Like in the patch below. Please note, that the block_tune setting for
>> the nocona is wrong, -march=native on my trusted old P4 returns:
>>
>> --param "l1-cache-size=16" --param
handle_move_double in m68k.c has a special case to handle movd
N(sp),-(sp), but this case can happen with any (address) register,
especially if a stack like variable is forced into a register (this
happened in gforth). Bootstrapped on m68k-suse-linux and installed on
trunk and gcc-4.8 branch.
And
Updated: the patch passes aarch64 tests. Added missing ChangeLog entry for
testsuite. OK to commit?
Bingfeng
-Original Message-
From: Bingfeng Mei
Sent: 02 January 2014 15:02
To: gcc-patches@gcc.gnu.org
Cc: 'tbela...@arm.com'
Subject: [PATCH] fixed pr59651 & new test case
Hi,
This pat
On Fri, Jan 03, 2014 at 03:02:51PM +0100, Uros Bizjak wrote:
> Please note that previous value was based on earlier (pre P4)
> recommendation and it was appropriate for older chips with 32byte
> cache line. The value should be updated long ago, when 64bit cache
> lines were introduced, but was prob
On Fri, Jan 03, 2014 at 02:07:03PM +, Bingfeng Mei wrote:
> This patch fixes pr59651. The original regression for pr52943 only
> appears on AArch64 target. I constructed a similar test that also exposes
> bug on x86-64. The problem is that calculation of address range in alias
> versioning f
On Fri, Jan 3, 2014 at 3:13 PM, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 03:02:51PM +0100, Uros Bizjak wrote:
>> Please note that previous value was based on earlier (pre P4)
>> recommendation and it was appropriate for older chips with 32byte
>> cache line. The value should be updated long
On Fri, Jan 03, 2014 at 03:35:11PM +0100, Uros Bizjak wrote:
> On Fri, Jan 3, 2014 at 3:13 PM, Jakub Jelinek wrote:
> > On Fri, Jan 03, 2014 at 03:02:51PM +0100, Uros Bizjak wrote:
> >> Please note that previous value was based on earlier (pre P4)
> >> recommendation and it was appropriate for old
On 22/12/13 17:42, Eric Botcazou wrote:
> Hi,
>
> this is the last issue with nested APCS frames according to our testing.
> When
> the IP register needs to be preserved on entry and r3 isn't free and there are
> no arguments to push, the prologue creates a slot above the frame, so various
> i
Hello,
this is the piece of patch you commented on in the PR.
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2014-01-03 Marc Glisse
PR c++/58950
gcc/cp/
* cvt.c (convert_to_void): Handle VEC_PERM_EXPR and VEC_COND_EXPR.
gcc/testsuite/
* g++.dg/pr58950.C: New file.
Jakub, thanks. Committed with suggested changes.
Bingfeng
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: 03 January 2014 14:26
To: Bingfeng Mei
Cc: gcc-patches@gcc.gnu.org; tbela...@arm.com
Subject: Re: [PING] [PATCH] fixed pr59651 & new test case
On Fri, Jan 03,
Hello Everyone,
Did anyone get a chance to look into this?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Monday, December 23, 2013 11:51 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Jakub Jelinek
> Subject: [PING][GOMP4][PATCH] SIMD-enabled functions (form
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
> I've noticed that especially with the AVX512F introduction we use
> GET_MODE_SIZE (mode) quite heavily in the i386 *.md files, and
> the problem with that is GET_MODE_SIZE isn't a compile time constant,
> needs to read mode_size array (non-const) at runti
On 11/26/2013 07:34 AM, Richard Biener wrote:
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -98,6 +98,15 @@ along with GCC; see the file COPYING3. If not see
array CONST_VAL[i].VALUE. That is fed into substitute_and_fold for
final substitution and folding.
+ This algorithm u
On Fri, Jan 3, 2014 at 3:02 PM, Uros Bizjak wrote:
>>> Like in the patch below. Please note, that the block_tune setting for
>>> the nocona is wrong, -march=native on my trusted old P4 returns:
>>>
>>> --param "l1-cache-size=16" --param "l1-cache-line-size=64" --param
>>> "l2-cache-size=2048" "-m
As Paul Eggert says in the PR, we shouldn't warn for enum bit-fields
in C99/C11 mode. C11 6.7.2.1 (5) says "A bit-field shall have a type
that is a qualified or unqualified version of _Bool, signed int,
unsigned int, or some other implementation-defined type.", so ISTM
that enum bit-fields should
On Fri, 3 Jan 2014, Marek Polacek wrote:
> As Paul Eggert says in the PR, we shouldn't warn for enum bit-fields
> in C99/C11 mode. C11 6.7.2.1 (5) says "A bit-field shall have a type
> that is a qualified or unqualified version of _Bool, signed int,
> unsigned int, or some other implementation-de
Hi,
On 01/02/2014 10:46 PM, Jason Merrill wrote:
On 12/27/2013 07:02 AM, Paolo Carlini wrote:
the same arguments. Conservatively but still more neatly than my first
try, we could maybe use same_type_ignoring_top_level_qualifiers_p in the
definition of the DERIVED_FROM_P macro?
Sure, let's do
Thanks for your feedback.
I considered my patch enough tested because it impacts basic
operations on the Rb tree containers. There are also a number of tests
that are normally dedicated to exception safety but that has the
advantage of challenging numerous containers operations in a generi
On 01/03/2014 12:29 PM, Paolo Carlini wrote:
- (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_none) != NULL_TREE)
+ (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_none) != NULL_TREE \
+ || ((TYPE) && NON_UNION_CLASS_TYPE_P (TYPE) \
+ && same_type_ignoring_top_level_qualifiers_p ((PA
On 01/03/2014 01:47 PM, Jason Merrill wrote:
+ issued. If the base in incomplete, then NULL_TREE is returned. */
"If T is incomplete"
"...even if BASE is the same type."
Jason
OK.
Jason
On Fri, Jan 03, 2014 at 02:15:51PM +0100, Florian Weimer wrote:
> This patch fixes a loophole in the -fstack-protector-strong
> protection. If a function call uses the return slot optimization,
> the caller needs stack protector instrumentation because the return
> slot is addressable.
>
> Bootst
In the same vein as the other dirs, add a --disable-werror option to the
libbacktrace dir to disable the explicit -Werror usage.
2014-01-03 Mike Frysinger
* configure.ac: Add --enable-werror.
(WARN_FLAGS): Use it.
* configure: Regenerate.
--- a/libbacktrace/configure.a
On Jan 2, 2014, at 2:26 PM, Eric Botcazou wrote:
>> So, I'd like to ping the original patch and Kenny's patch to resolve the
>> issues you found. If you have any other concerns or thoughts, let us
>> know.
>
> Almost OK, but remove the strange quotes in the comment for the INTEGER_CST
> case of
Hi!
On Fri, Jan 03, 2014 at 08:58:30PM +0100, Toon Moene wrote:
> I don't doubt that would work, what I'm interested in, is (cat verintlin.f):
Well, you need gather loads for that and there you hit PR target/59617.
Completely untested patch that let's your testcase be vectorized
using 64-byte ve
On 01/03/2014 07:57 PM, Jakub Jelinek wrote:
+/* Check if the basic block has a call which uses a return slot. */
+
+static bool
+call_with_return_slot_opt_p (basic_block bb)
+{
+ for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
+ !gsi_end_p (gsi); gsi_next (&gsi))
+{
+ gimple
Hello,
On 03 Jan 09:59, Jakub Jelinek wrote:
> Does it matter which of vmovdqu32 vs. vmovdqu64 is used if no
> masking/zeroing is performed (i.e. vmovdqu32 (%rax), %zmm0 vs.
> vmovdqu64 (%rax), %zmm0) for performance reasons (i.e. isn't there some
> reinterpretation penalty)?
No, there should be no
Le 22/12/2013 11:28, Janus Weil a écrit :
> Hi all,
>
> here is a patch for a rejects-valid problem with type-bound
> procedures, which is due to the fact that the PURE attribute is being
> propagated too late. (I'm not sure if this problem could show up also
> with other attributes, so for now I'
On Sun, Dec 22, 2013 at 10:27 AM, Jan Hubicka wrote:
>> On Tue, Dec 17, 2013 at 7:48 AM, Teresa Johnson wrote:
>> > On Mon, Dec 16, 2013 at 2:48 PM, Xinliang David Li
>> > wrote:
>> >> Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
>> >> low level primitives for basic gcov
On Fri, 3 Jan 2014, Teresa Johnson wrote:
> Index: libgcc/libgcov.h
> ===
> --- libgcc/libgcov.h(revision 0)
> +++ libgcc/libgcov.h(revision 0)
> @@ -0,0 +1,224 @@
> +/* Header file for libgcov-*.c.
> + Copyright (C) 1996-20
Hi,
On 01/03/2014 07:47 PM, Jason Merrill wrote:
On 01/03/2014 12:29 PM, Paolo Carlini wrote:
- (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_none) != NULL_TREE)
+ (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_none) != NULL_TREE \
+ || ((TYPE) && NON_UNION_CLASS_TYPE_P (TYPE) \
+
On Fri, Jan 3, 2014 at 2:49 PM, Joseph S. Myers wrote:
> On Fri, 3 Jan 2014, Teresa Johnson wrote:
>
>> Index: libgcc/libgcov.h
>> ===
>> --- libgcc/libgcov.h(revision 0)
>> +++ libgcc/libgcov.h(revision 0)
>> @@ -0,0 +1,224 @
... something like the attached appears to work. Not sure at the moment
if it could be simplified.
Thanks,
Paolo.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 206318)
+++ cp/cp-tree.h(worki
On Fri, Jan 03, 2014 at 03:39:11PM +, Joseph S. Myers wrote:
> On Fri, 3 Jan 2014, Jakub Jelinek wrote:
>
> > I've noticed that especially with the AVX512F introduction we use
> > GET_MODE_SIZE (mode) quite heavily in the i386 *.md files, and
> > the problem with that is GET_MODE_SIZE isn't a
I'm wondering if all the outstanding issues you raised with "tree" have been
addressed. If there are any that remain, let us know.
If they have been, is the original patch (as modified of course by approved
later work) Ok?
On Fri, Jan 3, 2014 at 3:37 PM, Jakub Jelinek wrote:
> On Fri, Jan 03, 2014 at 03:39:11PM +, Joseph S. Myers wrote:
>> On Fri, 3 Jan 2014, Jakub Jelinek wrote:
>>
>> > I've noticed that especially with the AVX512F introduction we use
>> > GET_MODE_SIZE (mode) quite heavily in the i386 *.md fil
On Fri, Jan 3, 2014 at 6:27 PM, Andrew Pinski wrote:
> On Fri, Jan 3, 2014 at 3:37 PM, Jakub Jelinek wrote:
>> On Fri, Jan 03, 2014 at 03:39:11PM +, Joseph S. Myers wrote:
>>> On Fri, 3 Jan 2014, Jakub Jelinek wrote:
>>>
>>> > I've noticed that especially with the AVX512F introduction we use
The data structure _BracketMatcher (storing regex like [123a-z]) could
be quite slow mainly because of regex_traits. So a result of cache for
small range of inputs (char) sounds reasonable. It iterates all 256
inputs and calculate them at regex compile time.
Booted and tested under -m64 and -m32.
On Thu, Jan 02, 2014 at 09:46:56PM +, Joseph S. Myers wrote:
> (Note that there remain other bugs in the IBM long double code, some
> causing glibc test failures, at least (a) invalid results in rounding
> modes other than FE_TONEAREST, (b) spurious overflow and underflow
> exceptions, mainly b
On Fri, Jan 3, 2014 at 11:19 AM, Mike Frysinger wrote:
> In the same vein as the other dirs, add a --disable-werror option to the
> libbacktrace dir to disable the explicit -Werror usage.
As far as I can see most of the target directories do not do this.
And libbacktrace is only turning on -Werro
71 matches
Mail list logo
