David,
Could you please also update the use of FOR_EACH_BB_REVERSE in
config/sh/sh_optimize_sett_clrt.cc ?
Thanks,
Oleg
On Fri, 2013-12-06 at 09:51 -0500, David Malcolm wrote:
> gcc/
> * basic-block.h (FOR_EACH_BB_REVERSE): Eliminate macro.
>
> * cfghooks.c (verify_flow_info): Repla
Hi,
I intend to the patch below to gcc-trunk and 4.8-branch:
It's a partial sync of the microblaze-rtems* section in gcc/config.gcc
with microblaze*-*-elf's:
Add TARGET_BIG_ENDIAN_DEFAULT-switch for microblaze*-*-rtems*.
Ralf
2013-12-07 Ralf Corsépius
* config.gcc (microblaze*-*-rtems*
On Sat, Dec 7, 2013 at 3:20 AM, Jeff Law wrote:
> On 12/06/13 03:29, bin.cheng wrote:
>>
>> Hi,
>> Entry pr41488 shows a case in which induction variable can't be recognized
>> or coalesced. As noted in the bug entry, one possible fix is to teach PRE
>> not to do some specific transformation. Ho
On Fri, Dec 6, 2013 at 7:53 PM, Alan Modra wrote:
> On Fri, Dec 06, 2013 at 05:23:28PM -0500, Vladimir Makarov wrote:
>> On 12/6/2013, 2:40 PM, David Edelsohn wrote:
>> >On Fri, Dec 6, 2013 at 2:02 PM, Vladimir Makarov
>> >wrote:
>> >> * config/rs6000/rs600.md (*bswapdi2_64bit): Remove ?
On Fri, Dec 06, 2013 at 05:23:28PM -0500, Vladimir Makarov wrote:
> On 12/6/2013, 2:40 PM, David Edelsohn wrote:
> >On Fri, Dec 6, 2013 at 2:02 PM, Vladimir Makarov wrote:
> >> * config/rs6000/rs600.md (*bswapdi2_64bit): Remove ?? from the
> >> constraint.
> >
> >Okay, let's just r
After further reviewing this patch, I found I don't have to change the
code in tree-vect-stmts.c to allow further type conversion after
widen-mult operation. Instead, I detect the following pattern in
vect_recog_widen_mult_pattern():
T1 a, b;
ai = (T2) a;
bi = (T2) b;
c = ai * bi;
where T2 is mor
[Jakub, see below]
+ if (!c_parser_elem_fn_vectorlength (parser)) +
{ + c_parser_skip_until_found (parser,
CPP_CLOSE_PAREN, NULL); + /* NO reason to keep
any of these tokens if the + vectorlength is
messed up. */ +
[This patch is on the git-only branch roland/pr59392.]
As described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392, this
bug looks to have been present since 4.2 originally introduced support
for ARM EABI-based C++ exception handling. I'd like to put this fix on
trunk and 4.8, and don't per
On 12/06/2013 01:32 PM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 12/03/2013 11:52 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
Index: tree-vrp.c
===
--- tree-vrp.c (revision 205597)
+++ tree-vrp.c (working cop
On 12/6/2013, 2:40 PM, David Edelsohn wrote:
On Fri, Dec 6, 2013 at 2:02 PM, Vladimir Makarov wrote:
Here is the patch.
Tested and bootstrapped on gcc110.fsffrance.org.
Ok to commit?
2013-12-05 Vladimir Makarov
* config/rs6000/rs600.md (*bswapdi2_64bit): Remove ?? from the
On 12/06/13 02:11, Eric Botcazou wrote:
Here's the Correct Fix(tm). We may or may not decide to go for it because
of concerns about ABI changes; in the latter case, any kludge that we'll
put in place instead must be restricted to the cases caught by this patch.
* stor-layout.c (compute
On 12/06/13 01:51, Bernd Edlinger wrote:
As for the patch itself. In a few places within expand_expr_real_1 you
changed calls to expand_expr to instead call expand_expr_real. ISTM
you could have gotten the same effect by just adding your extra argument
to the existing code?
Yes, but one goal
On 12/06/13 03:06, Richard Biener wrote:
The issue is that we handle expansion of misaligned moves in the code
we recurse to - but that misaligned move handling can only work at
the "outermost" level of the recursion as it is supposed to see the
"real" access (alignment and mode of the memory ac
On 11/27/2013 11:24 AM, Eric Botcazou wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the first half of the rtl code.
--- a/gcc/cse.c
+++ b/gcc/cs
On 12/06/13 13:33, Jakub Jelinek wrote:
Hi!
range->exp can in some cases be equal to op, as in the following testcase:
_2;
int _3;
_Bool _4;
int a.0_5;
_Bool _7;
:
_2 = b.f;
_3 = (int) _2;
_4 = _3 > 0;
_7 = _2 | _4;
a.0_5 = (int) _7;
a = a.0_5;
return a.0
On 12/06/13 12:30, Caroline Tice wrote:
The attached patch fixes two small problems with the current vtable
verification code: it makes the libvtv function decls globally
visible, and it updates all uses of the verified vtable pointer with
the verification results, rather than just the first u
On Fri, Dec 06, 2013 at 02:27:25PM +0100, Jakub Jelinek wrote:
> > You can install that as cleanup now if you split it out (so hopefully
> > no users creep back that make removing it impossible).
>
> Ok, will do.
Here is that part, bootstrapped/regtested on x86_64-linux and i686-linux,
committed
Hi!
range->exp can in some cases be equal to op, as in the following testcase:
_2;
int _3;
_Bool _4;
int a.0_5;
_Bool _7;
:
_2 = b.f;
_3 = (int) _2;
_4 = _3 > 0;
_7 = _2 | _4;
a.0_5 = (int) _7;
a = a.0_5;
return a.0_5;
op here is _2 (and other range's op is _4), the tw
Hi Aldy & Jakub,
I have made the fixes you have mentioned and have answered your
questions below. Attached is the fixed patch and here are the ChangeLog entries.
Gcc/ChangeLog
2013-12-06 Balaji V. Iyer
* omp-low.c (expand_simd_clones): Added a new parameter called "type."
Oleg Endo wrote:
>On Fri, 2013-12-06 at 16:57 +0100, Steven Bosscher wrote:
>> On Fri, Dec 6, 2013 at 3:51 PM, David Malcolm wrote:
>> > * asan.c (transform_statements): Eliminate use of
>last_basic_block
>> > in favor of last_basic_block_for_fn, in order to make use
>of cfun
>> >
On Dec 6, 2013, at 12:02 PM, Dominique Dhumieres wrote:
>> Be sure to attach patches to be applied instead of cut-n-paste if you use
>> Mail, it destroys the text cut and pasted.
>
> I did not use Mail. Did you have troubles with Tabs? Apparently the post on
> the list has them right.
Curious
> :-) We stop using cvs a long time ago.
I meant SVN, just showing my age!-)
> Be sure to attach patches to be applied instead of cut-n-paste if you use
> Mail, it destroys the text cut and pasted.
I did not use Mail. Did you have troubles with Tabs? Apparently the post on the
list has them r
On Fri, Dec 6, 2013 at 2:02 PM, Vladimir Makarov wrote:
> On 12/6/2013, 12:30 PM, Vladimir Makarov wrote:
>>
>> On 12/6/2013, 11:28 AM, Michael Meissner wrote:
>>>
>>> On Thu, Dec 05, 2013 at 12:40:17PM -0500, Vladimir Makarov wrote:
The following patch fixes two GCC testsuite failures f
On Tue, 2013-11-26 at 12:18 +0100, Oleg Endo wrote:
> Hello,
>
> The attached patch is the same as posted in the PR as attachment 31283.
> In addition to the testing done by Kaz and Christian, I've also tested
> it with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-
Patch updated with two more tests to check if the vfmadd insn is being
produced when possible.
Thanks
Sri
On Fri, Dec 6, 2013 at 11:12 AM, Sriraman Tallam wrote:
> Hi,
>
> I have attached a patch to fix
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390. Please review.
>
> Here is the probl
The attached patch fixes two small problems with the current vtable
verification code: it makes the libvtv function decls globally
visible, and it updates all uses of the verified vtable pointer with
the verification results, rather than just the first use.
I have bootstrapped the compiler with
On Dec 6, 2013, at 11:03 AM, Dominique Dhumieres wrote:
>> I think I blew by it the first time with the OK? at the end of the line?
>> maybe I thought you thought it was trivial and checked it in
>
> The patch is indeed trivial, but I don't have write access to CVS,
:-) We stop using cvs a lon
On Nov 18, 2013, at 9:48 AM, Dominique Dhumieres wrote:
> Adjust the following tests to take into account the change of
> "Length of Public Names Info" to "Pub Info Length"
> in revision 203936. Tested on x86_64-apple-darwin13.
Applied:
Committed revision 205758.
Be sure to attach patches to be
On Fri, 2013-12-06 at 09:05 -0500, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Oleg Endo as co-maintainer of the SH port.
>
> Please join me in congratulating Oleg on his new role.
> Oleg, please update your listing in the MAINTAINER
On 12/06/13 03:29, bin.cheng wrote:
Hi,
Entry pr41488 shows a case in which induction variable can't be recognized
or coalesced. As noted in the bug entry, one possible fix is to teach PRE
not to do some specific transformation. However, it's in nature a scalar
evolution issue. Considering bel
Hi,
I have attached a patch to fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390. Please review.
Here is the problem. GCC adds target-specific builtins on demand. The
FMA target-specific builtin __builtin_ia32_vfmaddpd gets added via
this declaration:
void fun() __attribute__((target("fm
On Fri, 2013-12-06 at 16:57 +0100, Steven Bosscher wrote:
> On Fri, Dec 6, 2013 at 3:51 PM, David Malcolm wrote:
> > * asan.c (transform_statements): Eliminate use of last_basic_block
> > in favor of last_basic_block_for_fn, in order to make use of cfun
> > explicit.
>
> Ca
> I think I blew by it the first time with the OK? at the end of the line?
> maybe I thought you thought it was trivial and checked it in
The patch is indeed trivial, but I don't have write access to CVS, so
someone else has to commit it.
Dominique
On 12/6/2013, 12:30 PM, Vladimir Makarov wrote:
On 12/6/2013, 11:28 AM, Michael Meissner wrote:
On Thu, Dec 05, 2013 at 12:40:17PM -0500, Vladimir Makarov wrote:
The following patch fixes two GCC testsuite failures for LRA. The
patch makes swap through registers instead of memory for the test
Hi!
On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> I fixed a few nits Jason pointed out off-line, and both him and Jakub
> have approved the patch for trunk.
>
> In running the final round of tests I noticed a few problems with my
> choice of bit numbers for the GF_OMP_* masks. I
Kenneth Zadeck writes:
> On 12/03/2013 11:52 AM, Richard Sandiford wrote:
>> Kenneth Zadeck writes:
>>> Index: tree-vrp.c
>>> ===
>>> --- tree-vrp.c (revision 205597)
>>> +++ tree-vrp.c (working copy)
>>> @@ -2611,22 +2611,
This patch to libgo fixes the scheduler in the current libgo for systems
that do not use futexes, such as Solaris. I fixed the futex code a
while back, but I managed to forget to fix the non-futex code. This is
PR 59408. Committed to mainline.
Ian
diff -r cc2d51f8c87a libgo/runtime/lock_sema.c
On 12/06/13 10:26, Kyrill Tkachov wrote:
Hi all,
The testcase gcc.dg/tree-ssa/loop-31.c started failing on arm with
r202165. The scan dump pattern looks for "+ 2" appearing exactly once.
With r202165 the loop header is modified from:
:
ivtmp.5_10 = (unsigned int) &a[4294967295];
_16 =
Richard asked to see the patch where i did the changes the way that he
asked in his email. Doing it the way he wants potentially has advantages
over the way that i did it, but his technique fails for non obvious
reasons. The failure in building is:
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti
On 12/06/13 11:04, Gerald Pfeifer wrote:
On Fri, 6 Dec 2013, H.J. Lu wrote:
This patch mentions -mtune=intel in gcc-4.9/changes.html.
OK to install?
Okay. (I guess we can ignore Itanium.)
Seems like the best thing to do for sanity's sake.
jeff
On 12/06/13 09:00, Ralf Corsepius wrote:
Hi,
I am going to apply the patch below to trunk and 4.8-branch.
It adds a copy of the microblaze-*-elf section for microblaze-rtems* to
libgcc/config.host.
This is the missing patch I mentioned in
http://gcc.gnu.org/ml/gcc/2013-11/msg00548.html
Ralf
On Fri, 6 Dec 2013, H.J. Lu wrote:
> This patch mentions -mtune=intel in gcc-4.9/changes.html.
> OK to install?
Okay. (I guess we can ignore Itanium.)
Gerald
On Thu, Dec 5, 2013 at 6:46 AM, Richard Biener wrote:
>
> This finally fixes PR59058.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Richard.
>
> 2013-12-05 Richard Biener
>
> PR tree-optimization/59058
> * tree-vectorizer.h (struct _loop_vec_info): Add n
On 12/06/13 02:37, Bin.Cheng wrote:
Do you have any codes where iv_ca_extend helps? I can see how that hunk
appears to be safe, and I'm guessing that setting the cost pair at each step
could potentially give more accurate costing on the next iteration of the
loop. But I'd love to be able to se
On Nov 18, 2013, at 9:48 AM, Dominique Dhumieres wrote:
> Adjust the following tests to take into account the change of
> "Length of Public Names Info" to "Pub Info Length"
> in revision 203936. Tested on x86_64-apple-darwin13. OK?
Ok. [ also, this is trivial ]
I think I blew by it the first ti
Hi,
This patch mentions -mtune=intel in gcc-4.9/changes.html.
OK to install?
Thanks.
--
H.J.
--
Index: gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.45
diff -u -p -r1.45 ch
On Fri, Dec 6, 2013 at 2:44 AM, Uros Bizjak wrote:
> On Fri, Dec 6, 2013 at 10:38 AM, Richard Biener
> wrote:
>> On Thu, Dec 5, 2013 at 10:05 PM, H.J. Lu wrote:
>>> On Thu, Dec 5, 2013 at 1:02 PM, Patrick Marlier
>>> wrote:
Hi,
On 12/05/2013 07:22 PM, H.J. Lu wrote:
>
>>
Hi,
The attached patch implements support for SHA1 crypto insn.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd-builtins.def: Update builtins table.
* config/aarch64/aarch64-simd.md (aarch64_crypto_sha1hs
Hi,
The attached patch implements support for crypto sha256.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd-builtins.def: Update builtins table.
* config/aarch64/aarch64-simd.md (aarch64_crypto_sha256hv4
Hi,
The attached patch implements support for AES crypto instructions.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd-builtins.def: Update builtins table.
* config/aarch64/aarch64-simd.md (aarch64_crypto_
Hi,
This patch implements support for crypto pmull.64.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
2013-12-06 Tejas Belagod
gcc/
* config/aarch64/aarch64-builtins.c: Define builtin types for poly64_t
poly128_t.
* aarch64/aarch64-simd-builtins.def: Upda
Hi,
The attached patch adds crypto types for instruction classificiation.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas
2013-12-06 Tejas Belagod
* config/arm/types.md (neon_mul_d_long, crypto_aes, crypto_sha1_xor,
crypto_sha1_fast, crypto_sha1_slow, crypto_sha256
Hi,
The attached patch defines TARGET_CRYPTO macro and defines builtin preprocessor
macro __ARM_FEATURE_CRYPTO.
Tested on aarch64-none-elf. OK for trunk?
Thanks,
Tejas.
Changelog
2013-12-06 Tejas Belagod
* config/aarch64/aarch64.h (TARGET_CRYPTO): New.
(__ARM_FEATURE_CR
On 12/6/2013, 11:28 AM, Michael Meissner wrote:
On Thu, Dec 05, 2013 at 12:40:17PM -0500, Vladimir Makarov wrote:
The following patch fixes two GCC testsuite failures for LRA. The
patch makes swap through registers instead of memory for the test
cases when LRA is used.
There are differences in
Hi all,
The testcase gcc.dg/tree-ssa/loop-31.c started failing on arm with r202165. The
scan dump pattern looks for "+ 2" appearing exactly once. With r202165 the loop
header is modified from:
:
ivtmp.5_10 = (unsigned int) &a[4294967295];
_16 = (unsigned int) len_4(D);
_17 = _16 * 2;
Hello!
Currently, gcc emits wrong warning for MMX argument passing on 32 bit
targets, even when MMX is enabled:
pr59405.c: In function ‘foo32x2_be’:
pr59405.c:7:1: warning: SSE vector argument without SSE enabled
changes the ABI [enabled by default]
foo32x2_be (float32x2_t x)
Attached patch fix
On Fri, Dec 06, 2013 at 05:12:08PM +, Tejas Belagod wrote:
> 2013-12-06 Tejas Belagod
>
> testsuite/
> * gcc.dg/vect/vect-nop-move.c: Fix dg options.
Ok, thanks.
> --- a/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
> @@ -1,6 +1,6 @@
Hi all,
Following the implementation of the Crypto intrinsics I posted earlier this
week, this patch implements the vceq_p64 and vtst_p64 intrinsics that operate on
the new poly64_t type. They do not have a regular form and can thus not be
autogenerated from our beloved ML scripts and are ther
Jakub Jelinek wrote:
On Wed, Dec 04, 2013 at 08:14:43AM -0800, H.J. Lu wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
@@ -0,0 +1,64 @@
+/* { dg-do run } */
+/* { dg-require-effective-target vect_float } */
+/* { dg-options "-O3 -fdump-rtl-combine-details" } */
Please chan
Upps ... here is the missing Changlog
ChangeLog
2013-12-06 Kai Tietz
PR target/56807
* config/i386/i386.c (ix86_expand_prologue): Address saved
registers stack-relative, not via frame-pointer.
On Fri, Dec 6, 2013 at 9:06 AM, Kai Tietz wrote:
> Hi,
>
>
> ChangeLog
>
> 2013-12-06 Kai Tietz
>
> PR target/56807
> * config/i386/i386.c (ix86_expand_prologue):
>
Incomplete ChangeLog entry.
--
H.J.
Hi,
ChangeLog
2013-12-06 Kai Tietz
PR target/56807
* config/i386/i386.c (ix86_expand_prologue):
Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
Index: config/i386/i386.c
===
--- conf
Hi,
I am going to apply the patch below to trunk and 4.8-branch.
It adds a copy of the microblaze-*-elf section for microblaze-rtems* to
libgcc/config.host.
This is the missing patch I mentioned in
http://gcc.gnu.org/ml/gcc/2013-11/msg00548.html
Ralf
2013-12-06 Ralf Corsépius
* config
On 12/03/2013 11:52 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
Index: tree-vrp.c
===
--- tree-vrp.c (revision 205597)
+++ tree-vrp.c (working copy)
@@ -2611,22 +2611,28 @@ extract_range_from_binary_expr_1 (value_
On Thu, Dec 05, 2013 at 12:40:17PM -0500, Vladimir Makarov wrote:
> The following patch fixes two GCC testsuite failures for LRA. The
> patch makes swap through registers instead of memory for the test
> cases when LRA is used.
>
> There are differences in reload and LRA constraint matching
> alg
Hi Kugan,
Thanks for working on this issue.
On 12/04/13 21:03, Kugan wrote:
Hi,
gcc trunk aarch64 bootstrapping fails with gas version 2.23.2 (with
error message similar to cannot compute suffix of object files) as this
particular version does not support -mabi=lp64. It succeeds with later
ver
On Fri, Dec 06, 2013 at 10:59:37AM -0500, Vladimir Makarov wrote:
> It is still two different patterns. One for reload and one for LRA.
> Attribute enabled is mostly used to describe insn constraints for
> subtargets.
I meant something like:
(define_insn "*bswapdi2_64bit"
[(set (match_operand:D
On 12/6/2013, 10:45 AM, Jakub Jelinek wrote:
On Fri, Dec 06, 2013 at 10:39:29AM -0500, Vladimir Makarov wrote:
Ok. I guess there is only one option to use one pattern for LRA
and reload without ?? in register alternative. In this case, reload
and LRA will actually work according to GCC docum
On Fri, Dec 6, 2013 at 3:51 PM, David Malcolm wrote:
> * asan.c (transform_statements): Eliminate use of last_basic_block
> in favor of last_basic_block_for_fn, in order to make use of cfun
> explicit.
Can we please make all this _for_fn go away?
Ciao!
Steven
> > Hi,
> >
> > Currently, on ARM, you have to either call abort() or raise(SIGTRAP)
> > to achieve a handy crash.
> >
> > This patch allows you to instead call __builtin_trap() which is much
> > more efficient at falling over because it becomes just a single
> > instruction that will trap for you.
On Fri, Dec 06, 2013 at 04:16:04PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 04:10:31PM +0100, Ondřej Bílka wrote:
> > Currently this code with sanitize=address gets expanded
> >
> > int foo(char *x, char *y, int i)
> > {
> > x[i] = y[i];
> > }
> >
> > to
> >
> > snip
> > movq
On Fri, Dec 06, 2013 at 10:39:29AM -0500, Vladimir Makarov wrote:
> Ok. I guess there is only one option to use one pattern for LRA
> and reload without ?? in register alternative. In this case, reload
> and LRA will actually work according to GCC documentation (LRA
> treats ? cost as the cost o
On 12/6/2013, 8:44 AM, David Edelsohn wrote:
On Thu, Dec 5, 2013 at 12:40 PM, Vladimir Makarov wrote:
The following patch fixes two GCC testsuite failures for LRA. The patch
makes swap through registers instead of memory for the test cases when LRA
is used.
There are differences in reload and
David Malcolm wrote:
>I have a series of 13 follow-up patches which remove the remaining
>"cfun"-using macros from basic-block.h
>
>Successfully bootstrapped®tested on x86_64-unknown-linux-gnu.
>
>These were pre-approved in stage1, and are mechanical in nature [1]
>
>I'd like to apply these to tru
On Fri, Dec 06, 2013 at 04:10:31PM +0100, Ondřej Bílka wrote:
> Currently this code with sanitize=address gets expanded
>
> int foo(char *x, char *y, int i)
> {
> x[i] = y[i];
> }
>
> to
>
> snip
> movq%rsi, %rax
> movq%rsi, %rdx
> shrq$3, %rax
> andl
gcc/
* basic-block.h (FOR_ALL_BB): Eliminate macro.
* cfg.c (alloc_aux_for_blocks, clear_aux_for_blocks): Replace
uses of FOR_ALL_BB with FOR_ALL_BB_FN, making uses of cfun explicit.
* cfganal.c (inverted_post_order_compute): Likewise.
* cfgcleanup.c (try_o
On Fri, Dec 06, 2013 at 01:34:43PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 01:32:42PM +0100, Ondřej Bílka wrote:
> > On second though besides of decreasing of code size there is no reason
> > to complicate compilation for these features. A more flexible way is add
> > environment vari
gcc/
* basic-block.h (profile_status): Eliminate macro.
* cfgbuild.c (find_many_sub_basic_blocks): Eliminate use of
profile_status macro in favor of profile_status_for_fn, making
use of cfun explicit.
* cfghooks.c (account_profile_record): Likewise.
gcc/
* basic-block.h (label_to_block_map): Eliminate macro.
* gimple.c (gimple_set_bb): Replace uses of label_to_block_map
with uses of label_to_block_map_for_fn, making uses of cfun be
explicit.
* tree-cfg.c (delete_tree_cfg_annotations): Likewise.
gcc/
* basic-block.h (basic_block_info): Eliminate macro.
* cfgrtl.c (rtl_create_basic_block): Replace uses of
basic_block_info with basic_block_info_for_fn, making uses
of cfun be explicit.
* tree-cfg.c (build_gimple_cfg, create_bb): Likewise.
---
gcc/basi
gcc/
* basic-block.h (profile_status_for_function): Rename to...
(profile_status_for_fn): ...this.
* cfg.c (check_bb_profile): Update for renaming.
* cgraphbuild.c (compute_call_stmt_bb_frequency): Likewise.
* lto-streamer-in.c (input_cfg): Likewise.
gcc/
* basic-block.h (SET_BASIC_BLOCK): Eliminate macro.
* cfg.c (compact_blocks): Replace uses of SET_BASIC_BLOCK
with SET_BASIC_BLOCK_FOR_FN, making use of cfun explicit.
(expunge_block): Likewise.
* cfgrtl.c (create_basic_block_structure): Likewise.
gcc/
* basic-block.h (label_to_block_map_for_function): Rename to...
(label_to_block_map_for_fn): ...this.
* lto-streamer-in.c (input_cfg): Update for renaming.
* tree-cfg.c (init_empty_tree_cfg_for_function): Likewise.
---
gcc/basic-block.h | 2 +-
gcc/lto-stre
gcc/
* basic-block.h (basic_block_info_for_function): Rename to...
(basic_block_info_for_fn): ...this.
(BASIC_BLOCK_FOR_FUNCTION): Rename to...
(BASIC_BLOCK_FOR_FN): ...this.
(SET_BASIC_BLOCK_FOR_FUNCTION): Rename to...
(SET_BASIC_BLOCK_FOR_FN): ...th
gcc/
* basic-block.h (FOR_EACH_BB_REVERSE): Eliminate macro.
* cfghooks.c (verify_flow_info): Replace uses of FOR_EACH_BB_REVERSE
with FOR_EACH_BB_REVERSE_FN, making uses of cfun explicit.
* cfgrtl.c (print_rtl_with_bb, rtl_verify_edges,
rtl_verify_bb_insns,
I have a series of 13 follow-up patches which remove the remaining
"cfun"-using macros from basic-block.h
Successfully bootstrapped®tested on x86_64-unknown-linux-gnu.
These were pre-approved in stage1, and are mechanical in nature [1]
I'd like to apply these to trunk now, but given that we're n
gcc/
* basic-block.h (last_basic_block_for_function): Rename to...
(last_basic_block_for_fn): ...this.
* ipa-utils.c (ipa_merge_profiles): Update for renaming of
last_basic_block_for_function to last_basic_block_for_fn.
* lto-streamer-in.c (input_cfg): Likewi
On Fri, Dec 6, 2013 at 1:53 AM, Jakub Jelinek wrote:
>
> The alternative would be to just (perhaps under #ifdef SANITIZER_CP_DEMANGLE)
> compile in libiberty/cp-demangle.c (similarly how libstdc++ compiles it in)
> as part of libsanitizer/libiberty/ or even libsanitizer/libbacktrace/,
> and tweak
On Thu, Dec 5, 2013 at 11:50 PM, Jakub Jelinek wrote:
>
> 2013-12-06 Jakub Jelinek
>
> * elf.c (ET_DYN): Undefine and define again.
> (elf_add): Add exe argument, if true and ehdr.e_type is ET_DYN,
> return early -1 without closing the descriptor.
> (struct phdr_
> Hi, all
>
> This is the new patch for gcov-tool (previously profile-tool).
>
> Honza: can you comment on the new merge interface? David posted some
> comments in an earlier email and we want to know what's your opinion.
>
> Test patch has been tested with boostrap, regresssion,
> profiledboots
On Thu, Dec 5, 2013 at 12:40 PM, Vladimir Makarov wrote:
> The following patch fixes two GCC testsuite failures for LRA. The patch
> makes swap through registers instead of memory for the test cases when LRA
> is used.
>
> There are differences in reload and LRA constraint matching algorithm whic
Konstantin wrote:
> My comment about "don't implement them" was only about the flags
> that change shadow offset & scale
Ah, I see. I didn't mention them in the first place so I got puzzled.
So it looks like people are generally ok with
* --param asan-instrument-reads=0/1
* --param asan-instrume
On Fri, 6 Dec 2013, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 01:49:50PM +0100, Richard Biener wrote:
> > Comments inline (scary large this patch for this stage ...)
>
> Thanks.
>
> > > +(define_expand "maskload"
> > > + [(set (match_operand:V48_AVX2 0 "register_operand")
> > > + (unspec:V
On Fri, Dec 06, 2013 at 01:49:50PM +0100, Richard Biener wrote:
> Comments inline (scary large this patch for this stage ...)
Thanks.
> > +(define_expand "maskload"
> > + [(set (match_operand:V48_AVX2 0 "register_operand")
> > + (unspec:V48_AVX2
> > + [(match_operand: 2 "register_operand")
On Fri, Dec 6, 2013 at 5:10 PM, Yury Gribov wrote:
> Konstantin wrote:
>> Can you have a target specific config for the particular target
>> that will have its own shadow offset & scale?
>
> Yes, we have this but I don't see how this can help with code
> instrumentation overheads.
My comment about
On Fri, Dec 6, 2013 at 2:04 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 01:52:29PM +0100, Richard Biener wrote:
>> > Note that testing still shows some issues, e.g. because the
>> > kThreadDescriptorSize change has not been applied. But it at least builds
>> > and for many tests works.
>>
Konstantin wrote:
> Can you have a target specific config for the particular target
> that will have its own shadow offset & scale?
Yes, we have this but I don't see how this can help with code
instrumentation overheads.
-Y
On Fri, Dec 06, 2013 at 01:52:29PM +0100, Richard Biener wrote:
> > Note that testing still shows some issues, e.g. because the
> > kThreadDescriptorSize change has not been applied. But it at least builds
> > and for many tests works.
>
> What's wrong with just copying the kernel headers 1:1? I
On Fri, Dec 6, 2013 at 4:39 PM, Yury Gribov wrote:
> Konstantin wrote:
>
>> Jakub wrote:
>>> I'm strongly against the blacklist,
>> I don't like it either. We were forced to implement it by reality.
>> ...
>
>> imagine third-party code which you can build but can not change
>
> Same situation here
On Fri, Dec 6, 2013 at 1:43 PM, Jakub Jelinek wrote:
> Hi!
>
> Here is an alternative version of the patch I've posted earlier to allow
> building libsanitizer on 2.6.18-ish kernel headers, this time by adding
> 5 tiny kernel header wrappers.
> The only drawback of this are warnings like:
> ../../
1 - 100 of 153 matches
Mail list logo
