On 22/04/13 18:13, Richard Henderson wrote:
> On 2013-04-22 09:23, Andreas Krebbel wrote:
>> + /* We save registers 6-15. */
>> + long int __gregs[9];
>
> Comment should be r6-r14, surely.
>
>> + /* r15 is stored into cfa field. It needs to be named that way
>> + since tls.h is acces
Hi, Vladimir
I add the code and the patch has passed bootstrap/regression test
on i686-pc-linux-gnu with current main trunk.
However, I don't have svn write access yet.
Could you please help to commit this patch?
Thanks for your comment and your help. I really appreciate it.
A plaintext gcc/Ch
Hi, this is a follow up simple patch to support 'slim' graph dump:
when -slim option is specified (e.g,
-fdump-tree-optimized-graph-slim), do not dump the boby.
2013-04-22 Xinliang David Li
* cfghhooks.c (dump_bb_for_graph): Support 'slim' graph dump.
Index: cfghooks.c
==
On Mon, Apr 22, 2013 at 8:43 PM, Vladimir Makarov wrote:
> * config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove
> lra_in_progress guard for addressing something bigger than word.
That will work, but I'm worried that it is too fragile. Previously
the code uniformly retu
I had to apply this patch to get the library to build after your change:
commit 0f1151f651987ba6772959c49c5afc6898dd9e83
Author: Jason Merrill
Date: Mon Apr 22 21:20:03 2013 -0400
* src/c++11/hashtable_c++0x.cc: Include ext/aligned_buffer.h.
diff --git a/libstdc++-v3/src/c++11/hashtable_
For cris-elf at r198164:
...
libtool: compile: /tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc/xgcc
-shared-libgcc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc -nostdinc++
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/src
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/s
On 13-04-22 3:31 PM, Michael Meissner wrote:
On Mon, Apr 22, 2013 at 03:26:45PM -0400, Vladimir Makarov wrote:
On 13-04-22 12:35 AM, Alan Modra wrote:
On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:
I don't understand what this check means and what comments ??? means too.
On 04/22/2013 08:20 AM, Richard Biener wrote:
That said, a lot of my pushback is because I feel a little lonesome in this
wide-int review and don't want to lone-some decide about that (generic)
interface part as well.
yeh, now sandiford is back from vacation so there are two of us to beat
on
On 14-Apr-13, at 7:37 AM, Steven Bosscher wrote:
On Tue, Apr 9, 2013 at 3:46 AM, John David Anglin wrote:
Seems to cause a reload problem:
Problem may be in not removing the continuation character "\" from
various
macro definitions.
Right, ASM_OUTPUT_ADDR_VEC_ELT and ASM_OUTPUT_ADDR_DIFF_E
This updates the links for the 4.7.3 and 4.6.4 libstdc++ documentation.
Now 4.6-4.8 links are all consistent.
best,
-benjamin
2013-04-22 Benjamin Kosnik
* htdocs/onlinedocs/index.html: Adjust GDL to GFDL. Change
4.7.3 and 4.6.4 to use gz instead of bz2 compression, like
On 04/19/13 08:29, Jakub Jelinek wrote:
Hi!
I've committed the following patch to gomp4 branch.
#pragma omp simd loops now are handled with all its clauses from parsing up
to and including omp expansion, so should actually run correctly, though
haven't added any runtime testcases yet.
I like i
Richard Biener writes:
> Richard Sandiford wrote:
>>Richard Biener writes:
At the rtl level your idea does not work. rtl constants do not
>>have a mode
or type.
>>>
>>> Which is not true and does not matter. I tell you why. Quote:
>>
>>It _is_ true, as long as you read "rtl constan
> -Original Message-
> From: Maciej W. Rozycki [mailto:ma...@codesourcery.com]
> Sent: Monday, April 22, 2013 5:09 PM
> To: Moore, Catherine
> Cc: rdsandif...@googlemail.com; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [MIPS] Support microMIPS HI/QI moves
>
> On Mon, 1 Apr 2013, Moore,
On Mon, 1 Apr 2013, Moore, Catherine wrote:
> (define_insn "*movhi_internal"
> - [(set (match_operand:HI 0 "nonimmediate_operand" "=d,d,d,m,*a,*d")
> - (match_operand:HI 1 "move_operand" "d,I,m,dJ,*d*J,*a"))]
> + [(set (match_operand:HI 0 "nonimmediate_operand" "=d,!u,d,!u,d,ZU,m,
On Mon, Apr 22, 2013 at 3:25 PM, Jason Merrill wrote:
> For this testcase, the patch changes output like "f.main()::__lambda0::__x"
> to "f.main()".
Agreed.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
In discussion of core issue 1586 at the Bristol meeting, someone
suggested that we should remove ~decltype(expr) and instead allow ~auto.
This patch implements that, currently limited to C++1y mode.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 37c8b2edbc39b6b6278afc08f7b74ace79743c5d
"Moore, Catherine" writes:
> 2013-04-01 Catherine Moore
>
> * config/mips/mips.md (*movhi_internal, *movqi_internal): New
> operands. Record compression.
OK, thanks.
Note that LBU and LHU also appear in *zero_extend2,
*zero_extendqihi2 and *and3.
Richard
While looking at another issue, I noticed that we were missing some
template instantiation context when a class instantiation was triggered
by instantiation of a default template argument to a function; we got
the information that the default argument was involved, but nothing
about the call th
Richard Sandiford wrote:
>Richard Biener writes:
>>> At the rtl level your idea does not work. rtl constants do not
>have a mode
>>> or type.
>>
>> Which is not true and does not matter. I tell you why. Quote:
>
>It _is_ true, as long as you read "rtl constants" as "rtl integer
>constants" :
This PR complained that G++ was using the same type_info node for a
function type with or without function-cv-qualifiers. As I read the
standard, typeid is not one of the few ways that a function-cv-qualifier
can be used, so we should just give an error in that case. I'm also
fixing the compi
On 04/21/2013 10:36 PM, Jonathan Wakely wrote:
On 21 April 2013 21:08, François Dumont wrote:
Hi
Here is another proposal with:
- No attempt to remove const key
- No attempt to use assignment operator
- noexcept move constructor; I slightly modify a static assertion so that it
checks that
For this testcase, the patch changes output like
"f.main()::__lambda0::__x" to "f.main()".
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 22f4e8dfe343bfee35abf9ca0dc884342e343557
Author: Jason Merrill
Date: Thu Apr 18 14:22:08 2013 +0100
* error.c (dump_aggr_type): Fix lambda
On 13-04-22 3:35 PM, Uros Bizjak wrote:
On Mon, Apr 22, 2013 at 9:17 PM, Vladimir Makarov wrote:
I never tried alpha with LRA. So it is not assumed that LRA should work on
alpha. But I am sure LRA can work for alpha if some efforts will be spent.
Porting LRA to a new target always involves ch
Richard Biener writes:
>> At the rtl level your idea does not work. rtl constants do not have a mode
>> or type.
>
> Which is not true and does not matter. I tell you why. Quote:
It _is_ true, as long as you read "rtl constants" as "rtl integer constants" :-)
> +#if TARGET_SUPPORTS_WIDE_INT
On Mon, Apr 22, 2013 at 9:17 PM, Vladimir Makarov wrote:
>
> I never tried alpha with LRA. So it is not assumed that LRA should work on
> alpha. But I am sure LRA can work for alpha if some efforts will be spent.
> Porting LRA to a new target always involves changes in .md and
> machine-dependen
On Mon, Apr 22, 2013 at 03:26:45PM -0400, Vladimir Makarov wrote:
> On 13-04-22 12:35 AM, Alan Modra wrote:
> >On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:
> >> I don't understand what this check means and what comments ??? means too.
> >A lo_sum mem is only valid if you know
2013/4/22 Tobias Burnus :
> Am 22.04.2013 20:00, schrieb Janus Weil:
>>>
>>> >Side remark and just for completeness, there is also rank == -1 for
>>> >assumed-rank arrays. However, as TRANSFER is not an inquiry function, it
>>> >shouldn't reach that code. (Maybe you could quickly check that that's
On 13-04-22 12:35 AM, Alan Modra wrote:
On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:
I don't understand what this check means and what comments ??? means too.
A lo_sum mem is only valid if you know it won't be offset (or that
offsetting will never cross a 64k+32k boundar
This paper corrected a defect in the language whereby we were
prematurely rejecting as ambiguous a conversion required by a context,
such as a delete-expression that wants some pointer type, when the class
has multiple conversion operators to similar types. In many cases, we
can resolve that u
On 2013-04-21 02:37 , Xinliang David Li wrote:
* graph.c (draw_cfg_node_succ_edges): Add branch probility as label.
* cfghhooks.c (dump_bb_for_graph): Dump profile count and frquency.
* Makefile.in: New dependency.
Looks OK.
Diego.
At the Bristol C++ meeting we voted to accept generalized lambda capture
initializers (e.g. [x = 42, y = std::move(y)]{ ... }), which were part
of the initial implementation of lambdas in GCC, so initial support for
C++1y is just a matter of checking cxx_dialect to avoid the pedwarn.
The only
On 13-04-22 2:19 PM, Steven Bosscher wrote:
On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:
On 04/22/2013 11:17 AM, Uros Bizjak wrote:
On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson
wrote:
On 01/28/2013 03:14 PM, Uros Bizjak wrote:
2013-01-28 Uros Bizjak
* config/alpha/alp
We still need to implement references to the object under construction
in constexpr constructors; this will also be useful for implementing the
support for aggregate initialization of classes with NSDMIs. But until
that happens, we shouldn't crash.
Tested x86_64-pc-linux-gnu, applying to trun
On 22 April 2013 12:13, Evgeniy Stepanov wrote:
> Thanks a lot.
> Forgot to mention it earlier, can this be backported in the 4_8 branch as
> well?
Yes, I don't see why not. I'll do that too.
"Moore, Catherine" writes:
>> -Original Message-
>> From: David Daney [mailto:ddaney.c...@gmail.com]
>> Sent: Friday, April 12, 2013 7:29 PM
>> To: Moore, Catherine
>> Cc: Rozycki, Maciej; gcc-patches@gcc.gnu.org; Richard Sandiford
>> Subject: Re: [Patch] [MIPS] Fix Many warnings in MIPS p
When a lambda names a member of an anonymous union, it's not clear
whether it's intended to capture the union as a whole or the member. So
we decided it should be ill-formed.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 37272f53baa15670141fcbf02a3f8219edb3827a
Author: Jason Merrill
D
This is an odd testcase, but we were only rejecting it by accident.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d248b59f755fd2071a27209e034610396c947809
Author: Jason Merrill
Date: Tue Apr 16 11:59:34 2013 +0100
Core 1609
* decl2.c (check_default_args): Check for pack expa
On 03/29/2013 03:51 PM, Jason Merrill wrote:
I've updated my proposal for return type deduction for normal functions
in C++14 for the upcoming Bristol meeting:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3582.html
and this patch implements the changes in the new proposal relativ
Am 22.04.2013 20:00, schrieb Janus Weil:
>Side remark and just for completeness, there is also rank == -1 for
>assumed-rank arrays. However, as TRANSFER is not an inquiry function, it
>shouldn't reach that code. (Maybe you could quickly check that that's indeed
>the case.)
well, I guess you*can*
On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:
> On 04/22/2013 11:17 AM, Uros Bizjak wrote:
>>
>> On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson
>> wrote:
>>>
>>> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
2013-01-28 Uros Bizjak
* config/alpha/alpha.c (TAR
On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:
>> Unfortunately, alphas are much more tied to reload than it was hoped.
>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>> without problems, further testing on ev4 and ev5 triggered various
>> problems, one of them is PR5
Hi,
sorry for getting back to this late.
> >> That's a larger error than I had expected from the merging, although
> >> as you note it is an approximation so there is going to be some amount
> >> of error. If the error is that large then maybe there is a better
> >> merging algorithm, since in the
richard,
i pushed send rather than save, just ignore the last email i sent
sorry.
On 04/22/2013 01:59 PM, Kenneth Zadeck wrote:
On 04/19/2013 09:31 AM, Richard Biener wrote:
+ number of elements of the vector that are in use. When LEN *
+ HOST_BITS_PER_WIDE_INT < the precision, the valu
>>> + if ((source->expr_type == EXPR_ARRAY || source->rank > 0)
>>
>> Minor: we can probably assume that rank > 0 if expr_type == EXPR_ARRAY,
>
> Side remark and just for completeness, there is also rank == -1 for
> assumed-rank arrays. However, as TRANSFER is not an inquiry function, it
> shouldn
On 04/19/2013 09:31 AM, Richard Biener wrote:
+ number of elements of the vector that are in use. When LEN *
+ HOST_BITS_PER_WIDE_INT < the precision, the value has been
+ compressed. The values of the elements of the vector greater than
+ LEN - 1. are all equal to the highest order bit
> We should really be emitting unsigned constants using add_AT_unsigned:
>
> if (TYPE_UNSIGNED (TREE_TYPE (value)))
> {
> if (host_integerp (value, 1))
> add_AT_unsigned (enum_die, DW_AT_const_value, TREE_INT_CST_LOW
> (value));
> else
> add_AT_unsigned_double (en
Hi Honza,
I converted all other weight update locations to use the helper
functions in basic-block.h instead of truncation (the patch I checked
in a couple weeks ago covered the cases that already used RDIV - see
the follow-on messages in this thread). I am almost done testing with
SPEC cpu2006. S
> A : host_integerp (value, TYPE_UNSIGNED (TREE_TYPE (value)))
> B : host_integerp (value, 0)
>
> AB AB AB AB
> type_size,hwi | 00 01 10 11
> --+---
> 32,32 | X X int int
> 64,32 |
On 04/22/2013 11:17 AM, Uros Bizjak wrote:
On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson wrote:
On 01/28/2013 03:14 PM, Uros Bizjak wrote:
2013-01-28 Uros Bizjak
* config/alpha/alpha.c (TARGET_LRA_P): New define.
Bootstrapped and regression tested [1] on alphaev68-unknown-li
> On Wed, Mar 27, 2013 at 6:22 PM, Teresa Johnson wrote:
> > I found that the node weight updates on cloned nodes during ipa-cp were
> > leading to incorrect/insane weights. Both the original and new node weight
> > computations used truncating divides, leading to a loss of total node
> > weight.
On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson wrote:
> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
>>
>> 2013-01-28 Uros Bizjak
>>
>> * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>
>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>
>> OK for 4.9?
>>
>
On 04/22/13 15:43, Marcus Shawcroft wrote:
Yufeng, please back port this patch to 4.8.
Done in r198146.
Yufeng
On Mon, Apr 22, 2013 at 06:53:59PM +0200, Marek Polacek wrote:
> 2013-04-22 Marek Polacek
>
> PR sanitizer/56990
> * tsan.c (instrument_expr): Don't instrument expression
> in case its size is zero.
>
> * gcc.dg/pr56990.c: New test.
Yes, thanks.
> --- gcc/tsan.c.mp
On Mon, Apr 22, 2013 at 05:23:17PM +0100, Richard Henderson wrote:
> On 2013-04-22 17:21, Jakub Jelinek wrote:
> >On Mon, Apr 22, 2013 at 06:11:26PM +0200, Marek Polacek wrote:
> >>We're getting SIGFPE, because one simply does not divide by zero.
> >>Fixed by doing the modulo only when size != 0.
>
On Apr 19, 2013, at 17:31, Andi Kleen wrote:
> Later on I think it's better to either always use large hash tables
> (virtual memory is cheap) or to dynamically size them based on a
> estimate of the available types.
That logic doesn't really work for hash tables. Assuming the hash keys
as clos
On 2013-04-22 17:21, Jakub Jelinek wrote:
On Mon, Apr 22, 2013 at 06:11:26PM +0200, Marek Polacek wrote:
We're getting SIGFPE, because one simply does not divide by zero.
Fixed by doing the modulo only when size != 0.
Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?
2013-04-22 Ma
On Mon, Apr 22, 2013 at 06:11:26PM +0200, Marek Polacek wrote:
> We're getting SIGFPE, because one simply does not divide by zero.
> Fixed by doing the modulo only when size != 0.
>
> Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?
>
> 2013-04-22 Marek Polacek
>
> PR sanit
On 2013-04-22 17:11, Marek Polacek wrote:
We're getting SIGFPE, because one simply does not divide by zero.
Fixed by doing the modulo only when size != 0.
Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?
2013-04-22 Marek Polacek
PR sanitizer/56990
* tsan.c (inst
On 2013-04-22 09:23, Andreas Krebbel wrote:
+ /* We save registers 6-15. */
+ long int __gregs[9];
Comment should be r6-r14, surely.
+ /* r15 is stored into cfa field. It needs to be named that way
+ since tls.h is accessing the field by name. Be aware that this
+ is not ac
On Mon, 22 Apr 2013 21:36:38 +0800
Chung-Lin Tang wrote:
> On 2013/4/19 12:56 AM, Cary Coutant wrote:
> > On Thu, Apr 18, 2013 at 6:49 AM, Chung-Lin Tang
> > wrote:
> >> This patch was a fix by Julian which corrected a
> >> HOST_BITS_PER_WIDE_INT host dependency in dwarf generation. Nios
> >> II
We're getting SIGFPE, because one simply does not divide by zero.
Fixed by doing the modulo only when size != 0.
Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?
2013-04-22 Marek Polacek
PR sanitizer/56990
* tsan.c (instrument_expr): Don't count modulo if the size
Am 22.04.2013 15:44, schrieb Mikael Morin:
+ if ((source->expr_type == EXPR_ARRAY || source->rank > 0)
Minor: we can probably assume that rank > 0 if expr_type == EXPR_ARRAY,
Side remark and just for completeness, there is also rank == -1 for
assumed-rank arrays. However, as TRANSFER is not
On Mon, Apr 22, 2013 at 01:49:39PM +0200, Richard Biener wrote:
> On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > WPA can spend a lot of time just resizing the type merging hash tables.
> > This adds experimental --params to size them large initially. On my large
On Mon, Apr 22, 2013 at 01:46:58PM +0200, Richard Biener wrote:
> On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > For a large LTO test case The previous pointer hash change brought
> > the collision rate for the WPA gimple type hash table from 90% to
> > 70. This
On Mon, Apr 22, 2013 at 5:21 PM, Laurent Alfonsi wrote:
> The patch well fix the adobe_cpp performance regression on the int8_t type.
> But the same degradation exists on uint8_t type, which is not fixed by the
> patch referenced in PR53676.
>
> With the signed version, the code:
>result_5 = (
The patch well fix the adobe_cpp performance regression on the int8_t
type. But the same degradation exists on uint8_t type, which is not
fixed by the patch referenced in PR53676.
With the signed version, the code:
result_5 = (signed char) ((int) result_2 + 2)
is now well narrowed to:
res
Hi Mikael,
> Two comments below:
>
>> Index: gcc/fortran/check.c
>> ===
>> --- gcc/fortran/check.c (revision 198108)
>> +++ gcc/fortran/check.c (working copy)
>> @@ -4456,7 +4455,7 @@ gfc_calculate_transfer_sizes (gfc_exp
Hi,
the other day, while Daniel was discussing a simply wording issue, I
noticed that our implementation is unnecessarily complicated.
Tested x86_64-linux.
Thanks,
Paolo.
//
2013-04-22 Paolo Carlini
* include/std/type_traits (is_signed): Simplify.
Yufeng, please back port this patch to 4.8.
Thanks
/Marcus
On 10 April 2013 15:44, Yufeng Zhang wrote:
> Hi,
>
> This patch changes the compiler to correctly generate .arch and .cpu
> assembly directives in order to support the inline assembly of
> instructions that are part of a feature, e.g. c
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018
The patch was successfully bootstrapped and tested on x86/x86-64 (with
different options).
Committed as rev. 198140.
2013-04-22 Vladimir Makarov
PR target/57018
* lra-eliminations.c (mark_not_elim
Hello,
Le 21/04/2013 23:04, Janus Weil a écrit :
> Hi all,
>
> the attached patch fixes an regression with TRANSFER, which was just
> reported today. The problem was that array-valued SOURCE arguments
> were not treated correctly.
>
> To fix it properly, I had to make 'gfc_target_expr_size' beha
Ping?
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 12 April 2013 15:19
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw; Ramana Radhakrishnan; mikest...@comcast.net
> Subject: [P
On 2013/4/19 12:56 AM, Cary Coutant wrote:
> On Thu, Apr 18, 2013 at 6:49 AM, Chung-Lin Tang
> wrote:
>> This patch was a fix by Julian which corrected a HOST_BITS_PER_WIDE_INT
>> host dependency in dwarf generation. Nios II does not have
>> need_64bit_hwint switched on during configuring, and ra
On Fri, Apr 19, 2013 at 11:01 PM, Eric Botcazou wrote:
>> Maybe we should detect overflow as if the input and output were signed
>> while computing an unsigned result. As far as I can see int_const_binop_1
>> does detect overflow as if operations were signed (it passes 'false' as
>> uns to all do
Hi,
this patch disables rdrand in c++11/random.cc when building with Clang
compiler. Current Clang misses a number of definitions needed to build
that.
Is it OK for google/gcc-4_8 and google/main (or google/integration?) ?
rdrand.patch
Description: Binary data
VRP happily propagates SSA names even if they are used in
abnormal PHI nodes which later can lead to coalescing issues.
The following fixes that.
It also fixes the recursion abnormal edge added for setjmp.
setjmp is leaf (and not longjmp which I already fixed with
the original patch).
Bootstrap
On Sun, Apr 21, 2013 at 10:54 PM, Kenneth Zadeck
wrote:
> Richard,
>
> i pulled these two frags out of your comments because i wanted to get some
> input from you on it while i addressed the other issues you raised.
>
>
>> + enum SignOp {
>> +/* Many of the math functions produce different re
On 2013-04-22 06:37 , Simon Baldwin wrote:
Fix contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail
Add empty attributes to "FAIL: gcc.dg/pr44194-1.c" entry to eliminate
confusion with '|' appearing in the error message. Fix two other comment
lines.
Okay?
OK. No need to make a Chan
On 22/04/13 11:39, James Greenhalgh wrote:
Hi,
This patch removes the need to have a standard pattern and an
aarch64_simd_blah copy of the same RTL instruction by mapping
intrinsics directly to standard pattern names.
This allows us to clean up some redundant patterns.
Regression tested on aa
On 22/04/13 11:34, James Greenhalgh wrote:
Hi,
This patch adds support for handling the:
vrecpe_<32,64>,
vrecpx_<32,64>,
vrecps_<32,64>.
intrinsics in arm_neon.h as as RTL builtins.
The patch has been regression tested on aarch64-none-elf and
aarch64-none-linux-gnu with no regressions.
Is t
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> -flto-report is useful, but it prints for every LTRANS pass and
> is very noisy and the main problem is often in WPA only.
>
> Add a new -flto-report-wpa option that is only printed for WPA.
Ok.
Thanks,
Richard.
> gcc/:
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> Some of the hash tables in lto-report are misnamed in the report.
> Fix this up.
Ok.
Thanks,
Richard.
> gcc/:
>
> 2013-04-19 Andi Kleen
>
> * gcc/lto/lto.c (print_lto_report_1): Fix LTO report names.
> ---
>
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> The LTO report is currently printed when the type merging hash tables
> are already destroyed, which makes them always show up as empty.
> Print it earlier. Right now it's printed twice.
Ok if tested properly.
Thanks,
Ri
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> WPA can spend a lot of time just resizing the type merging hash tables.
> This adds experimental --params to size them large initially. On my large
> LTO build I get a 1.1% improvement in build time from presizing the hash
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> For a large LTO test case The previous pointer hash change brought
> the collision rate for the WPA gimple type hash table from 90% to
> 70. This patch uses the well known murmur3 to improve it further
> to 64%.
But if th
On Fri, Apr 19, 2013 at 7:15 PM, James Greenhalgh
wrote:
> Hi Richard,
>
> Thanks for your feedback. This does feel like a much nicer solution now.
>
>> Yes, it looks basically ok. I'd probably restrict it to folding target
>> builtins
>> though - similar to what TARGET_FOLD_BUILTIN did. Exactly
Thanks a lot.
Forgot to mention it earlier, can this be backported in the 4_8 branch as well?
On Sun, Apr 21, 2013 at 12:40 PM, Jonathan Wakely wrote:
> On 19 April 2013 16:19, Evgeniy Stepanov wrote:
>> Good point, thanks!
>> Revised patch attached.
>
> I've committed that version, thanks very m
Hello,
This patch fixes the following warning in config/aarch64/aarch64.c:
.../gcc/config/aarch64/aarch64.c: In function ‘void
aarch64_print_operand(FILE*, rtx, char)’:
.../gcc/config/aarch64/aarch64.c:3376:42: warning: format ‘%x’ expects argument
of type ‘unsigned int’, but argument 3 has ty
Aspect/pragma Contract_Cases can now be associated with a library level
subprogram.
This patch also verifies the legality of aspect/pragma Contract_Cases when it
appears in a subprogram body.
-- Source --
-- proc.ads
procedure Proc (X : out Integer);
pragma Contract_Ca
Hi,
I went through the items noticed by Nico in the paper and voted to the
wp, and we are missing only the following, I think we can do the change now.
Tested x86_64-linux.
Thanks,
Paolo.
/
2013-04-22 Paolo Carlini
N3669
* include/std/complex (comp
RM 3.2.4 (23/3) stipulates that predicates are checked on out and in-out
by-reference parameters on return from a call. If the call is to a primitive
of the type the predicate call is inserted in the postcondition subprogram.
However, if the call is to an inherited operation, the check must be perf
Hi,
This patch removes the need to have a standard pattern and an
aarch64_simd_blah copy of the same RTL instruction by mapping
intrinsics directly to standard pattern names.
This allows us to clean up some redundant patterns.
Regression tested on aarch64-none-elf and aarch64-none-linux-gnu
wit
Fix contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail
Add empty attributes to "FAIL: gcc.dg/pr44194-1.c" entry to eliminate
confusion with '|' appearing in the error message. Fix two other comment
lines.
Okay?
contrib/ChangeLog
2013-04-22 Simon Baldwin
* testsuite-manag
Hi,
This patch adds support for handling the:
vrecpe_<32,64>,
vrecpx_<32,64>,
vrecps_<32,64>.
intrinsics in arm_neon.h as as RTL builtins.
The patch has been regression tested on aarch64-none-elf and
aarch64-none-linux-gnu with no regressions.
Is this OK for trunk?
Thanks,
James Greenhalgh
Hi,
a straightforward issue, tested x86_64-linux, committed mainline and
4_8-branch.
Thanks,
Paolo.
2013-04-22 Paolo Carlini
PR libstdc++/57010
* include/bits/stl_heap.h (pop_heap): Avoid self move-assignment.
* testsuite/25_algorithms/pop_
Hi!
On Fri, 5 Apr 2013 23:55:37 +0100, "Maciej W. Rozycki"
wrote:
> On Fri, 5 Apr 2013, Thomas Schwinge wrote:
> > > Index: gcc/config/fp-bit.c
> > > ===
> > > RCS file: /cvs/uberbaum/gcc/config/fp-bit.c,v
> > > retrieving revision
Hi,
the patch adds initial libitm support for S/390. For now it is
software only. I'm working on the hardware support.
The libitm testsuite is clean with the patch.
Comments?
I'll apply the patch in a couple of days in case there are no
objections.
Bye,
-Andreas-
2013-04-22 Andreas Krebbe
Hi,
>> This and the preceding scan are the same pattern. So if either passes
>> you'll fail to detect a failure in the other.
Thanks for the suggestion.
Please find attached the modified patch as per your suggestions.
Please review the same and let me know if there should be any
further modific
98 matches
Mail list logo
