Richard Biener wrote:
>On Thu, Oct 31, 2013 at 10:02 AM, Ilya Enkovich
> wrote:
>> Hi,
>>
>> Here is a patch which hadles the problem with optimization of
>BUILT_IN_CHKP_ARG_BND calls. Pointer Bounds Checker expects that
>argument of this call is a default SSA_NAME of the PARM_DECL whose
>bounds
On 11/04/2013 06:21 PM, Jason Merrill wrote:
Surely it should be valid to allocate a Java boolean type. Andrew,
how should that work?
Thanks. The problem we are facing (assuming we want to resolve this old
isue) is that something seems seriously broken for the builtin Java
types as declared in
Hi,
This is to fix testcase error reported in PR58985.
The intention of the testcase was to ensure there was no REG_EQUIV
notes generated for a reg which was used in a paradoxical subreg. When
target was x86, there was subreg generated so I omitted to add the
subreg in the regexp pattern. However
2013/10/31 Florian Weimer :
> On 10/20/2013 02:55 PM, Roman Gareev wrote:
>>
>> During testing of the linux kernel (3.8.8) compilation time, the
>> acquired results were the following: increasing by 0.17% for the
>> version 4.8.0, increasing by 1.12% for the version 4.8.1, decreasing
>> by 0.598% f
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967
The removed code is too old. To be honest, I even don't remember why I
added this. LRA has been changed a lot since this change and now it
works fine without it.
There is no test for this case as it is too big.
The
On Mon, Nov 4, 2013 at 2:23 PM, Vladimir Makarov wrote:
> The following patch fixes
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967
>
> The removed code is too old. To be honest, I even don't remember why I
> added this. LRA has been changed a lot since this change and now it
> works fi
On Mon, Nov 4, 2013 at 12:34 AM, Bill Schmidt
wrote:
> Hi,
>
> This patch fixes the widening multiply high/low operations to work
> correctly in the presence of the first patch of this series, which
> reverses the meanings of multiply even/odd instructions. Here we
> reorder the input operands to
Dear Steve,
Thanks for the review. Patch committed to trank as revision 204356.
I'll wait a few days before going back to 4.8 partly because I do
not have a 4.8 tree loaded :-)
Cheers
Paul
On 2 November 2013 18:11, Steve Kargl wrote:
> On Fri, Nov 01, 2013 at 04:56:36PM +0100, Paul Richar
Change dg-additional-files to match the behaviour of dg-additional-sources.
This fix has been in the CS trunk for 2 months without problem.
It's fairly obvious so I'll commit in the next day or two unless there are
objections.
--
Jim Lemke
Mentor Graphics / CodeSourcery
Orillia Ontario
2013-11
On 11/4/2013 2:23 PM, Vladimir Makarov wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967
The removed code is too old. To be honest, I even don't remember why I
added this. LRA has been changed a lot since this change and now it
works fine without it.
Whe
Dear All,
When I first posted it in Bugzilla, I thought that this patch is too
kludgey by far. However, it has grown on me and I now think that it
is the right thing to do. The patch is self-explanatory.
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.7/4.8
with an appropriate de
Paul Richard Thomas wrote:
When I first posted it in Bugzilla, I thought that this patch is too
kludgey by far. However, it has grown on me and I now think that it
is the right thing to do. The patch is self-explanatory.
Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.7/4.8
with
Hi!
This patch fixes PR58984, where determine_known_aggregate_parts
notices that o.f0 = 1 store (because of ESRA) and p.f0 = 1
store (because the field isn't a bitfield) are known constants
at offset 0 of the first parameter, but doesn't record the access
of that size (8 bits) and happily replaces
Hi!
single_imm_use (to my surprise) modifies what it's last argument points to
even when returning false, this function wasn't expecting that.
Furthermore, if a the var is used in a store which does't have lhs as
SSA_NAME, this would ICE.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
Marc Glisse wrote:
>On Mon, 4 Nov 2013, Richard Biener wrote:
>
>> On Mon, Nov 4, 2013 at 12:18 PM, Marc Glisse
>wrote:
>>> On Mon, 4 Nov 2013, Richard Biener wrote:
>>>
On Mon, Nov 4, 2013 at 11:55 AM, Richard Biener
wrote:
>
> On Fri, Nov 1, 2013 at 11:39 PM, Marc Glisse
>
>>
Marc Glisse wrote:
>On Mon, 4 Nov 2013, Richard Biener wrote:
>
>> Well, host_integer_p (, 0) looks correct to me. But ...
>
>Ok, I'll put it back.
>
>>> Index: gcc/tree-ssa-alias.h
>>> ===
>>> --- gcc/tree-ssa-alias.h(revisi
On Mon, Nov 04, 2013 at 06:23:19PM +, James Greenhalgh wrote:
> > --- gcc/optabs.c.jj 2013-10-29 09:25:45.0 +0100
> > +++ gcc/optabs.c2013-10-31 13:20:40.384808642 +0100
> > @@ -6674,7 +6674,7 @@ expand_vec_perm (enum machine_mode mode,
> > }
> >tmp = gen_rtx
Thanks - committed to trunk as r204358. 4.7 and 4.8 are to follow in a few days.
Paul
On 4 November 2013 21:01, Tobias Burnus wrote:
> Paul Richard Thomas wrote:
>>
>> When I first posted it in Bugzilla, I thought that this patch is too
>> kludgey by far. However, it has grown on me and I now
...as suggested by Richard. This means that out-of-range shift values
produce the same results on all targets at the tree level. The rtl level
isn't affected since it explicitly truncates the count.
Tested on mips64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
* double-int.c (lshif
On 11/04/2013 08:00 PM, Zhenqiang Chen wrote:
> Thanks. I add a new hook. The default function will return -1 if the target
> does not care about the order.
>
> +DEFHOOK
> +(select_ccmp_cmp_order,
> + "For some target (like ARM), the order of two compares is sensitive for\n\
> +conditional compare
On Mon, Nov 4, 2013 at 8:46 AM, Jack Howarth wrote:
> On Mon, Nov 04, 2013 at 06:47:13AM -0800, Konstantin Serebryany wrote:
>> +glider, our Mac expert.
>>
>> Hi Jack,
>>
>> This patch has not been tested on Mac and we generally do not claim
>> that gcc-asan is supported on Mac.
>> clang-asan *is*
On 11/01/13 19:42, Vladimir Makarov wrote:
I did not expected from the patch any problems too. It is so obvious.
This simple change should not affect x86 (or any other target currently
using LRA). The code in question is used only for x86-64 and only for
modern intel processing tuning. It is
Tobias Burnus wrote:
Gerald Pfeifer wrote:
To make it easier to reproduce builds of software and entire GNU/Linux
distributions, RMS had the idea of adding a warning to GCC that warns
about the use of __DATE__ and __TIME__.
I assume that he also likes to have a warning for __TIMESTAMP__.
I w
On 11/04/2013 02:26 PM, David Edelsohn wrote:
> On Mon, Nov 4, 2013 at 2:23 PM, Vladimir Makarov wrote:
>> The following patch fixes
>>
>>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967
>>
>> The removed code is too old. To be honest, I even don't remember why I
>> added this. LRA has been
On Mon, 4 Nov 2013, Ian Lance Taylor wrote:
2013-11-04 Ian Lance Taylor
* builtins.def (ATTR_NOTHROWCALL_LEAF_LIST): Define.
* sync-builtins.def: Use ATTR_NOTHROWCALL_LEAF_LIST for all sync
builtins that take pointers.
* lto-opts.c (lto_write_options): Write -
> I am seeing a bootstrap failure that seems related: ...
Me too,
Dominique
Thanks! The three patches are commited as r204367, r204369 and r204371.
Regards,
Wei Mi.
On Sun, Nov 3, 2013 at 5:18 PM, Jan Hubicka wrote:
>> Ping. Is it ok for x86 maintainer?
>
> I tought I already approved the x86 bits.
>>
>> Thanks,
>> Wei Mi.
>>
>> On Wed, Oct 16, 2013 at 4:25 PM, Wei Mi
On Mon, 2013-11-04 at 16:43 -0500, David Malcolm wrote:
> On Mon, 2013-11-04 at 08:19 -0500, Andrew MacLeod wrote:
> > On 11/01/2013 06:58 PM, David Malcolm wrote:
> > > On Fri, 2013-11-01 at 22:57 +0100, Jakub Jelinek wrote:
> > >> On Fri, Nov 01, 2013 at 05:47:14PM -0400, Andrew MacLeod wrote:
>
On Mon, Nov 4, 2013 at 1:24 PM, Marc Glisse wrote:
> On Mon, 4 Nov 2013, Ian Lance Taylor wrote:
>
>> 2013-11-04 Ian Lance Taylor
>>
>> * builtins.def (ATTR_NOTHROWCALL_LEAF_LIST): Define.
>> * sync-builtins.def: Use ATTR_NOTHROWCALL_LEAF_LIST for all sync
>> builtins th
On Mon, Nov 04, 2013 at 04:43:33PM -0500, David Malcolm wrote:
> I tried converting gimple_call_set_lhs to accept a gimple_call, rather
> than a gimple, and excitingly, it was easiest to also convert
> cgraph_edge's call_stmt to also be a gimple_call, rather than just a
> gimple.
>
> Am attaching
On 11/04/2013 05:03 PM, David Malcolm wrote:
On Mon, 2013-11-04 at 16:43 -0500, David Malcolm wrote:
On Mon, 2013-11-04 at 08:19 -0500, Andrew MacLeod wrote:
On 11/01/2013 06:58 PM, David Malcolm wrote:
On Fri, 2013-11-01 at 22:57 +0100, Jakub Jelinek wrote:
On Fri, Nov 01, 2013 at 05:47:14PM
I merged trunk into wide-int.
On 11/04/2013 05:03 PM, David Malcolm wrote:
I believe it would be easiest to do them one subclass at-a-time e.g.
convert all gimple_call_* functions to accepting a gimple_call, then
another subclass etc - assuming that this approach is blessed by the
core reviewers.
I think the strategy for re
The warning should say "macro" not "Macro" and I think "reproducing" not
"reproduce". The c-family and libcpp changes are OK with that fixed.
--
Joseph S. Myers
jos...@codesourcery.com
On 11/04/2013 05:25 PM, Jakub Jelinek wrote:
On Mon, Nov 04, 2013 at 04:43:33PM -0500, David Malcolm wrote:
I tried converting gimple_call_set_lhs to accept a gimple_call, rather
than a gimple, and excitingly, it was easiest to also convert
cgraph_edge's call_stmt to also be a gimple_call, rathe
BTW, this part of patch only does the re-factoring work.
I haven't finished the porting of profile-tool part of patch to the
trunk. They should be in a separate patch anyway.
-Rong
On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu wrote:
> Honza, Thanks for the comments!
> Attached is the patch.
> Passed
On Mon, Nov 4, 2013 at 2:43 PM, Rong Xu wrote:
> Honza, Thanks for the comments!
> Attached is the patch.
> Passed spec2006 fdo build and profiledbootstrap in gcc.
> I'm doing some other tests.
>
> -Rong
>
> On Mon, Nov 4, 2013 at 1:55 AM, Jan Hubicka wrote:
>>> Thanks! Can you attach the patch f
Am 31.10.2013 17:40, schrieb Jakub Jelinek:
On Sun, Oct 27, 2013 at 10:45:57PM +0100, Tobias Burnus wrote:
The code is written such that when "-fopenmp" is used,
-f(no-)openmp-simd has no effect. The following "simd" pragmas are
listed in OpenMP 4.0 - and will all get translated into "#pragma om
Hi Iain,
I have prefixed all my replies below with "BVI:"
Thanks,
Balaji V. Iyer.
From: Iain Sandoe [mailto:i...@codesourcery.com]
Sent: Sunday, November 3, 2013 11:01 AM
To: Iyer, Balaji V
Cc: Joseph S. Myers; Tobias Burnus; gcc patches
Subject: Re: Testsuite / Cilk Plus: Include library
Hi,
On Mon, 4 Nov 2013 16:40:38, Dodji Seketeli wrote:
> +static ssize_t
> +get_line (char **lineptr, size_t *n, FILE *fp)
> +{
> + ssize_t cur_len = 0, len;
> + char buf[16384];
> +
> + if (lineptr == NULL || n == NULL)
> + return -1;
> +
> + if (*lineptr == NULL || *n == 0)
> + {
> + *n = 120;
>
This patch to the x86 backend adds .cfi directives for the BX register
swap in the atomic compare-and-exchange-doubleword insn. If we don't do
this, then when compiling with -fnon-call-exceptions, if the cmpxchg8
memory address is invalid, and the SIGSEGV signal handler throws an
exception, the BX
I wonder if it makes sense to get rid of the conditional compile such as
#ifdef L_gcov_x
..
#endif
This has the advantage of producing slightly smaller instrumented
binary, but this benefit can also be achieved via -ffunction-sections
and let linker to garbage collect unused functions.
(pro
On Nov 4, 2013, at 5:43 AM, Senthil Kumar Selvaraj
wrote:
> gcc.dg/superblock.c uses the -fdump-rtl-sched2 option and then scans the
> resulting dump. This fails for the AVR target, as it doesn't have any
> instruction scheduling support.
Ok.
> If ok, could someone commit please?
Committed re
On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote:
> This patch has not been tested on Mac and we generally do not claim
> that gcc-asan is supported on Mac.
> clang-asan *is* supported on Mac and our bots are green (this patch is
> a merge of the sources which are regularly tested on
Hi,
Here's a revised version of this patch according to Richard's
suggestions. It differs from the previous version only in the method
used to ensure vmulouh is generated; we now call the new
gen_altivec_vmulouh to accomplish this.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with
Hi,
Here's a new version of this patch, revised according to Richard
Sandiford's suggestions. Unfortunately the diffing is a little bit ugly
for this version.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Is this ok for trunk?
Thanks,
Bill
2013-11-04 Bill
HJ's regression tester shows the new test gcc.dg/iec-559-macros-9.c
failing for 32-bit x86. It turns out the excess precision handling
for determining the value of __GCC_IEC_559 has two problems:
flag_excess_precision hasn't been initialized at the point it's
tested, so flag_excess_precision_cmdli
Hi Peter.
Does this also mean that asan in llvm trunk is broken for Power?
We'll need to fix it there too (or, in fact, first).
--kcc
On Mon, Nov 4, 2013 at 4:33 PM, Peter Bergner wrote:
> On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote:
>> This patch has not been tested on Mac an
On 11/04/13 06:19, Richard Biener wrote:
On Thu, Oct 31, 2013 at 7:11 AM, Jeff Law wrote:
I've incorporated the various suggestions from Marc and Richi, except for
Richi's to integrate this into jump threading.
I've also made the following changes since the last version:
1. Added more tes
On Mon, 2013-11-04 at 17:48 -0800, Konstantin Serebryany wrote:
> Hi Peter.
> Does this also mean that asan in llvm trunk is broken for Power?
> We'll need to fix it there too (or, in fact, first).
I'm not sure. Bill, can you fire off a quick LLVM trunk build on
powerpc64-linux and see you see th
I've applied this patch to C11-atomic branch to add support for
handling x87 floating-point exceptions for atomic compound assignment.
With this applied, c11-atomic-exec-5.c now passes on
x86_64-unknown-linux-gnu. I consider the branch now feature-complete
regarding _Atomic support (as opposed to
Hi,
This fixes the two companion patterns vec_pack_[su]fix_trunc_v2df in the
same manner as the recent fix for vec_pack_trunc_v2df. The same fix
obviously applies here as well. Bootstrapped and tested on
powerpc64{,le}-unknown-linux-gnu with no regressions. Is this ok for
trunk?
Thanks,
Bill
Hi Peter,
The buildbot shows the latest LLVM ppc64 build is working ok:
http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/8086
This build completed about two hours ago.
Hope this helps,
Bill
On Mon, 2013-11-04 at 20:02 -0600, Peter Bergner wrote:
> On Mon, 2013-11-04 at 17:48 -0800, K
On Mon, Nov 4, 2013 at 10:21 PM, Bill Schmidt
wrote:
> Hi,
>
> This fixes the two companion patterns vec_pack_[su]fix_trunc_v2df in the
> same manner as the recent fix for vec_pack_trunc_v2df. The same fix
> obviously applies here as well. Bootstrapped and tested on
> powerpc64{,le}-unknown-linu
Hello Everyone,
Attached, please find a patch to fix PR 58951. The usage of -ldl is not
necessary. The patch is tested in x86_64 and x86. It is committed as obvious.
Thanks,
Balaji V. Iyer.
Index: Makefile.in
===
--- Makefil
It also breaks x32 build.
On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany
wrote:
> Hi Peter.
> Does this also mean that asan in llvm trunk is broken for Power?
> We'll need to fix it there too (or, in fact, first).
>
> --kcc
>
> On Mon, Nov 4, 2013 at 4:33 PM, Peter Bergner wrote:
>> On M
Is this the same failure or different?
On Mon, Nov 4, 2013 at 9:49 PM, H.J. Lu wrote:
> It also breaks x32 build.
>
>
> On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany
> wrote:
>> Hi Peter.
>> Does this also mean that asan in llvm trunk is broken for Power?
>> We'll need to fix it there to
Bill,
This build does not seem to be testing any of the asan code: you need
"check-asan"
--kcc
On Mon, Nov 4, 2013 at 7:30 PM, Bill Schmidt
wrote:
> Hi Peter,
>
> The buildbot shows the latest LLVM ppc64 build is working ok:
>
> http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/8086
>
On Mon, Nov 04, 2013 at 11:56:38PM +0100, Tobias Burnus wrote:
> gcc/
> * doc/invoke.texi (-fopenmp-simd): Document new option.
> * gimplify.c (gimplify_body): Accept -fopenmp-simd.
> * omp-low.c (execute_expand_omp, execute_lower_omp): Ditto.
> * tree.c (attribute_value_equ
On Tue, Nov 05, 2013 at 01:14:46AM +, Joseph S. Myers wrote:
> HJ's regression tester shows the new test gcc.dg/iec-559-macros-9.c
> failing for 32-bit x86. It turns out the excess precision handling
> for determining the value of __GCC_IEC_559 has two problems:
> flag_excess_precision hasn't
On Mon, Nov 04, 2013 at 05:48:31PM -0800, Konstantin Serebryany wrote:
> Hi Peter.
> Does this also mean that asan in llvm trunk is broken for Power?
> We'll need to fix it there too (or, in fact, first).
I bet on all targets, not just PPC. By including kernel headers directly,
you are entering v
101 - 161 of 161 matches
Mail list logo
