On Feb 27, 2014, Alexandre Oliva wrote:
> I wasn't entirely sure this wouldn't invalidate assumptions made in
> callers of cselib_preserve_only_values (the function called at the end
> of each extended basic block), but some analysis, plus comparing before
> and after assembly output ;-), made su
Hi Denis,
> -Original Message-
> From: Denis Chertykov [mailto:cherty...@gmail.com]
> Sent: Monday, March 03, 2014 10:45 PM
> 2014-03-03 13:34 GMT+04:00 S, Pitchumani :
> > Hi,
> >
> > Few AVR Xmega devices have specific instruction support than the
> architecture
> > it belongs to. For ex
On Wed, Mar 5, 2014 at 9:12 AM, Jakub Jelinek wrote:
> Hi!
>
> arm_legitimize_address may be called with a TLS symbol referenced, even when
> x is not itself a SYMBOL_REF. Most often it is something like:
> (const:SI (plus:SI (symbol_ref:SI "tlsvar") (const_int NNN)))
> but generally it can be so
> On Tue, 4 Mar 2014, Jan Hubicka wrote:
>
> > >
> > > The following patch addresses the common (?) issue of people
> > > omitting -flto from the linker command-line which gets more
> > > severe with GCC 4.9 where slim LTO objects are emitted by
> > > default. The patch simply _always_ arranges
On 03/05/2014 01:52 PM, Jonathan Wakely wrote:
On 5 March 2014 18:16, Ed Smith-Rowland wrote:
After the latest batch of papers came out I updated the status docs.
OK?
OK (CCing gcc-patches with the attachments again).
Thanks.
After the latest batch of papers came out I updated the status doc
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.h (gcc_jit_function_dump_to_dot): New.
* libgccjit.map (gcc_jit_function_dump_to_dot): New.
* libgccjit++.h (gccjit::function::dump_to_dot): New.
* libgccjit.c (gcc_jit_function_dump_to_dot): New.
* inte
On 5 March 2014 21:35, Marc Glisse wrote:
> On Wed, 5 Mar 2014, Jonathan Wakely wrote:
>
>> Please put _GLIBCXX_RESOLVE_DEFECTS (or whatever
>> it is we use elsewhere) in the comment, rather than just "DR 2106". I
>> think the point of that is to be able to grep for all DR fixes
>> (especially ones
On Wed, 5 Mar 2014, Jonathan Wakely wrote:
Please put _GLIBCXX_RESOLVE_DEFECTS (or whatever
it is we use elsewhere) in the comment, rather than just "DR 2106". I
think the point of that is to be able to grep for all DR fixes
(especially ones that aren't actually accepted as defects yet :-)
Bel
slm_cost/intel_cost and TARGET_SLOW_PSHUFB are just preparation to a
next vectorization patch.
Changes in ix86_add_stmt_cost gives real performance to Silvermont.
Let's move all to stage1.
On Wed, Mar 5, 2014 at 9:29 PM, Uros Bizjak wrote:
> On Wed, Mar 5, 2014 at 5:46 PM, H.J. Lu wrote:
>> On W
This patch adds support for the PowerPC ISA 2.07 (power8) 128-bit add/subtract
instructions that use the Altivec (VMX) register set (vaddumq, etc.).
Unfortunately at the moment, TImode (__int128_t) is not allowed to use the
VSX/VMX register set, unless you use the undocumented switch -mvsx-timode.
On 5 March 2014 19:36, Marc Glisse wrote:
> Hello,
>
> this issue got delayed in LWG, apparently because of a failed "improvement"
> to the wording along the way (happens, that's ok), but there seems to be a
> consensus on the resolution and I don't really see the point of waiting (it
> changes cod
On Wed, Mar 5, 2014 at 9:17 AM, Ondřej Bílka wrote:
> On Wed, Mar 05, 2014 at 08:05:25AM -0800, Ian Lance Taylor wrote:
>> On Wed, Mar 5, 2014 at 1:25 AM, Richard Biener
>> wrote:
>> > On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor wrote:
>> >> The GNU glibc qsort function will call malloc in
On Mar 4, 2014, at 8:39 AM, Jakub Jelinek wrote:
> With some -march=/-mtune= flags even i?86/x86_64 has BRANCH_COST 1 and
> various tests fail, furthermore ssa-ifcombine-ccmp* apparently fail on e.g.
> s390* or some arm variants.
>
> This patch tries to fix that up.
>
> ok for trunk?
Ok.
On 3/4/2014, 9:59 AM, Kito Cheng wrote:
Ping.
Although this patch is safe. I guess it could wait for stage 1 as right
now we don't need this functionality.
The patch is ok for the stage1 which is probably about a month away.
Thanks for the patch.
On Thu, Feb 27, 2014 at 12:32 PM, Kito
On 03/05/2014 01:40 PM, Jan Hubicka wrote:
I think the abstract classes probably should never be considered in the type
inheritance graph walk as possible instances. That is we probably want to test
them in record_targets_from_bases, possible_polymorphic_call_targets and
record_target_from_binfo
Hello,
this issue got delayed in LWG, apparently because of a failed
"improvement" to the wording along the way (happens, that's ok), but there
seems to be a consensus on the resolution and I don't really see the point
of waiting (it changes code that currently returns a reference to a
tempor
OK.
Jason
Various code was being confused by the PAREN_EXPR. Let's only add them
when the expression is dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 96995b9f04091798416d64c572950df31d3add8a
Author: Jason Merrill
Date: Wed Mar 5 13:19:16 2014 -0500
PR c++/60409
* semantic
On 02/26/14 08:21, Marek Polacek wrote:
Ping.
Based on Balaji's comments, OK.
jeff
On Wed, Mar 05, 2014 at 07:40:06PM +0100, Jan Hubicka wrote:
> > gcc/cp/
> > * search.c (get_pure_virtuals): Set BINFO_ABSTRACT_P.
> > * tree.c (copy_binfo): Copy it.
>
> You need to also save and restre the flag in LTO streaming.
> I can prepare patch tomorrow if you p
> > This patch fixes the latest 58678 testcase by avoiding speculative
> > devirtualization to the destructor of an abstract class, which can
> > never succeed: you can't create an object of an abstract class, so
> > the pointer must point to an object of a derived class, and the
> > derived class
... finishing testing the below.
Thanks,
Paolo.
///
2014-03-05 Paolo Carlini
* parser.c (cp_lexer_set_source_position): New.
(cp_parser_mem_initializer): Use it.
(cp_parser_postfix_open_square_expression): Likewise.
(cp_parser_parenthesized_exp
> This patch fixes the latest 58678 testcase by avoiding speculative
> devirtualization to the destructor of an abstract class, which can
> never succeed: you can't create an object of an abstract class, so
> the pointer must point to an object of a derived class, and the
> derived class necessaril
Hi,
On 03/05/2014 06:35 PM, Jason Merrill wrote:
+ cp_token *token = cp_lexer_peek_token (parser->lexer);
+ cp_lexer_set_source_position_from_token (token);
Shall we add a static inline void cp_lexer_set_source_position (cp_lexer
*lexer)? We do have a couple of existing instance
The problem in this testcase was that we were initially tentatively
parsing int(A) as a parameter declaration, then complaining about using
that parameter as a template-argument. We should treat it as a parse
error rather than a semantic error until we know how we really want to
parse things.
On Wed, Mar 5, 2014 at 5:46 PM, H.J. Lu wrote:
> On Wed, Mar 5, 2014 at 7:58 AM, Evgeny Stupachenko wrote:
>> Hi,
>>
>> The patch is for x86 Silvermont.
>> It improves x86 Silvermont vector cost model.
>> It gives +20% on facerec spec on Silvermont.
>> It passes make check and bootstrap on x86.
>
On Wed, Mar 05, 2014 at 08:05:25AM -0800, Ian Lance Taylor wrote:
> On Wed, Mar 5, 2014 at 1:25 AM, Richard Biener
> wrote:
> > On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor wrote:
> >> The GNU glibc qsort function will call malloc in some cases. That makes
> >> it unsuitable for libbacktrace
On Wed, Mar 5, 2014 at 4:53 PM, Rainer Orth
wrote:
> When using GNU as with Solaris ld, the TLS local dynamic tests
> (gcc.dg/torture/tls/run-ld.c etc.) FAIL to execute before Solaris 11:
> the programs crash with an illegal instruction: e.g. in the
> gcc.dg/lto/20090210 test, we have
>
> 0x8050c
This patch fixes the latest 58678 testcase by avoiding speculative
devirtualization to the destructor of an abstract class, which can never
succeed: you can't create an object of an abstract class, so the pointer
must point to an object of a derived class, and the derived class
necessarily has
On 28 Feb 17:21, Bernd Schmidt wrote:
> I think it won't help that much - I still think this entire scheme
> is likely to fail on nvptx. I'll try to construct an example at some
> point.
>
> One other thing about the split tables is that we don't have to
> write a useless size of 1 for functions.
Hi!
../../map.c: In function 'main':
../../map.c:4:21: error: array type has incomplete element type
extern struct foo s2[1];
^
../../map.c:8:11: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in c_finish_omp
On Wed, Mar 5, 2014 at 7:58 AM, Evgeny Stupachenko wrote:
> Hi,
>
> The patch is for x86 Silvermont.
> It improves x86 Silvermont vector cost model.
> It gives +20% on facerec spec on Silvermont.
> It passes make check and bootstrap on x86.
>
> Is this patch ok for stage1?
>
> ChangeLog:
>
> 2014-
On Wed, 5 Mar 2014, David Malcolm wrote:
On Wed, 2014-03-05 at 15:46 +0800, lin zuojian wrote:
On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote:
That is not true. The indentation style is:
http://www.gnu.org/prep/standards/standards.html#Formatting
...
The above also mentions parti
On 2014.03.05 at 11:18 -0500, David Malcolm wrote:
> On Wed, 2014-03-05 at 15:46 +0800, lin zuojian wrote:
> > On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote:
> > > >That is not true. The indentation style is:
> > > >http://www.gnu.org/prep/standards/standards.html#Formatting
> > > >.
On Wed, 2014-03-05 at 15:46 +0800, lin zuojian wrote:
> On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote:
> > >That is not true. The indentation style is:
> > >http://www.gnu.org/prep/standards/standards.html#Formatting
> > >...
> > >The above also mentions particular options
> > >for G
On Wed, Mar 5, 2014 at 1:25 AM, Richard Biener
wrote:
> On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor wrote:
>> The GNU glibc qsort function will call malloc in some cases. That makes
>> it unsuitable for libbacktrace, which is intended to work when called
>> from a signal handler. This patc
Hi,
The patch is for x86 Silvermont.
It improves x86 Silvermont vector cost model.
It gives +20% on facerec spec on Silvermont.
It passes make check and bootstrap on x86.
Is this patch ok for stage1?
ChangeLog:
2014-03-05 Evgeny Stupachenko
* config/i386/x86-tune.def (TARGET_SLOW_PSHUFB
When using GNU as with Solaris ld, the TLS local dynamic tests
(gcc.dg/torture/tls/run-ld.c etc.) FAIL to execute before Solaris 11:
the programs crash with an illegal instruction: e.g. in the
gcc.dg/lto/20090210 test, we have
0x8050ce0 : mov%gs:0x0,%eax
0x8050ce6 : call 0x8050ce7
0x8050ce7
On Wed, 2014-03-05 at 15:00 +0100, Jakub Jelinek wrote:
> Hi!
>
> The PR requests beyond the already commited ones some further headers.
>
> Tested with make install, ok for trunk?
I am not authorized to approve that, but I hope it will be committed.
Cheers.
--
Basile STARYNKEVITCH htt
On Wed, 5 Mar 2014, Jakub Jelinek wrote:
> Hi!
>
> The PR requests beyond the already commited ones some further headers.
>
> Tested with make install, ok for trunk?
Ok.
Thanks,
Richard.
> 2014-03-05 Jakub Jelinek
>
> PR plugins/59335
> * Makefile.in (PLUGIN_HEADERS): Add tree
Hi!
The PR requests beyond the already commited ones some further headers.
Tested with make install, ok for trunk?
2014-03-05 Jakub Jelinek
PR plugins/59335
* Makefile.in (PLUGIN_HEADERS): Add tree-phinodes.h, stor-layout.h,
ssa-iterators.h, $(RESOURCE_H) and tree-cfg
Hi Mikael,
>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
> I'm asking for one more minor change, namely:
>
>> @@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
>> return false;
>> }
>>
>> + /* Add the hidden deferred length field. */
>> +
On Mon, Mar 03, 2014 at 01:33:18PM +, Richard Sandiford wrote:
> Alan Modra writes:
> > On Mon, Mar 03, 2014 at 02:14:51PM +1030, Alan Modra wrote:
> >> I'll post update-copyright.py separately.
>
> Thanks for doing this, looks good to me FWIW. I don't know whether
> we want to keep a single
On 05/03/2014 11:51, Richard Biener wrote:
On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres
wrote:
Revision 208312 causes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427
Uhm. pointer comparison against double_type_node ...
I'd say we want to revert the patch. Paulo, please do that.
On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres wrote:
>
> Revision 208312 causes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427
Uhm. pointer comparison against double_type_node ...
I'd say we want to revert the patch. Paulo, please do that. Let's
do the alternate approach of mark
Revision 208312 causes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427
Also compiling the test gcc.dg/lto/pr55113 with -m32 gives an ICE
FAIL: gcc.dg/lto/pr55113 c_lto_pr55113_0.o assemble, -flto -fshort-double -O0
(internal compiler error)
internal compiler error: in layout_type, at stor
Le 01/03/2014 16:58, Janus Weil a écrit :
>>> Index: gcc/fortran/trans-stmt.c
>>> ===
>>> --- gcc/fortran/trans-stmt.c (revision 207896)
>>> +++ gcc/fortran/trans-stmt.c (working copy)
>>> @@ -5028,6 +5028,11 @@ gfc_trans_allocate (g
Ping?
On 25/02/14 10:08, Kyrill Tkachov wrote:
Hi all,
The problem solved in this patch is that when gcc is configured with
--with-arch=armv8-a gcc will go into aarch64-arches.def, pick the
representative CPU (Cortex-A53 for ARMv8-A) and use that CPUs ISA flags. Now
that we specified that Cort
On Wed, Mar 5, 2014 at 10:25 AM, Richard Biener wrote:
> On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor wrote:
>> The GNU glibc qsort function will call malloc in some cases. That makes
>> it unsuitable for libbacktrace, which is intended to work when called
>> from a signal handler. This patch
> Richard Sandiford writes:
>> Andrew Bennett writes:
>>> Hi,
>>>
>>> I have noticed that a patch was placed in bugzilla to do this change, but
>>> it
>>> does not appear to have been pushed. I was wondering if anyone could
>>> comment
>>> why this is the case?
>>>
>>> The bugzilla URL is the
On Wed, Mar 5, 2014 at 10:20 AM, Jakub Jelinek wrote:
>> > Pretty much all plugins fail to compile against installed plugin headers
>> > on i?86, because stringop.def isn't installed.
>> >
>> > This patch should fix that, ok if testing succeeds?
>> >
>> > 2014-03-05 Jakub Jelinek
>> >
>> >
On Wed, Mar 5, 2014 at 4:34 AM, Ian Lance Taylor wrote:
> The GNU glibc qsort function will call malloc in some cases. That makes
> it unsuitable for libbacktrace, which is intended to work when called
> from a signal handler. This patch changes libbacktrace to use an
> internal qsort function.
On Wed, Mar 05, 2014 at 10:10:13AM +0100, Uros Bizjak wrote:
> On Wed, Mar 5, 2014 at 9:48 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > Pretty much all plugins fail to compile against installed plugin headers
> > on i?86, because stringop.def isn't installed.
> >
> > This patch should fix that, ok if
Hi!
arm_legitimize_address may be called with a TLS symbol referenced, even when
x is not itself a SYMBOL_REF. Most often it is something like:
(const:SI (plus:SI (symbol_ref:SI "tlsvar") (const_int NNN)))
but generally it can be something else (e.g. from expansion of
TARGET_MEM_REF). Unfortunat
On Wed, Mar 5, 2014 at 9:48 AM, Jakub Jelinek wrote:
> Hi!
>
> Pretty much all plugins fail to compile against installed plugin headers
> on i?86, because stringop.def isn't installed.
>
> This patch should fix that, ok if testing succeeds?
>
> 2014-03-05 Jakub Jelinek
>
> * config/i386
On Tue, 4 Mar 2014, Jan Hubicka wrote:
> >
> > The following patch addresses the common (?) issue of people
> > omitting -flto from the linker command-line which gets more
> > severe with GCC 4.9 where slim LTO objects are emitted by
> > default. The patch simply _always_ arranges for the linker
Hi!
Pretty much all plugins fail to compile against installed plugin headers
on i?86, because stringop.def isn't installed.
This patch should fix that, ok if testing succeeds?
2014-03-05 Jakub Jelinek
* config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def.
--- gcc/config/i386/t-i3
On Tue, 4 Mar 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, the assumption that in !optimize functions
> all SSA_NAMEs for a particular PARM_DECL or RESULT_DECL can be coalesced
> together is wrong for -flto, if you compile with optimizations the object
> file and then link with -O
On 31/01/14 12:37, Matthias Klose wrote:
ping, adding build maintainers
I was hoping one of the configury maintainers would comment on this. No
such luck.
Based on the following in the manual:
"@code{MULTIARCH_DIRNAME} is not used for configurations that support
both multilib and multiarc
59 matches
Mail list logo
