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
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
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, 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
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
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 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
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 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
>> >
>> >
> 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: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
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
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
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
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
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 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
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. */
>> +
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
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
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
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
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
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
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 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, 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 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-
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 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.
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 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
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 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.
>
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.
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
> 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
... 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
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
On 02/26/14 08:21, Marek Polacek wrote:
Ping.
Based on Balaji's comments, OK.
jeff
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
OK.
Jason
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
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
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 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 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 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
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.
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
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
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
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 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
> 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 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
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 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
59 matches
Mail list logo
