Hi!
On Thu, 12 Dec 2013 10:53:02 +0100, I wrote:
> On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> > 3) I figured out we need to tell the runtime library not just
> > address, size and kind, but also alignment (we won't need that for
> > the #pragma omp declare target global vars though
Am 15.12.2013 23:14, schrieb Jerry DeLisle:
The patch also fixes a few other places I found after auditing all calls to
generate error in libgfortran/io.
I will conjure up a test case for this.
Thanks for both.
I have regression tested on X86-64 Linux. OK for trunk?
OK.
Tobias
2013-12-15
Hello Everyone,
The following changes mentioned in this thread
(http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01280.html) are also applicable
to the C++ patch and the attached patch has been fixed accordingly:
1. Sharing the vectorlength parsing function between #pragma simd and SIMD
ena
> From: Hans-Peter Nilsson
> Date: Sun, 15 Dec 2013 15:20:48 +0100
> +// { dg-options "-std=gnu++0x -DSAMPLES=3" { target { { arm*-* } &&
> simulator } } }
> +// { dg-options "-std=gnu++0x -DSAMPLES=1" { target simulator } }
JFTR, I managed to have two bugs here:
1 - the target tuple (u
Hello,
there's updated version of the patch.
Tested on x86_64 with enable bootstrap.
Martin
On 16 December 2013 00:21, Jan Hubicka wrote:
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index 93e857df..d5a0ac8 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,14 @@
>> +2013
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 93e857df..d5a0ac8 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,14 @@
> +2013-12-15 Martin Liska
> + Jan Hubicka
> +
> + * cgraphunit.c (node_cmp): New function.
> + (expand_all_functions): Function ordering
There's latest version of the patch.
Could you please approve the patch?
Martin
On 5 December 2013 22:32, Jan Hubicka wrote:
>> Hello,
>>thank you for the trick in ipa-split.c. It really helped! I
>
> Good!, this patch is pre-approved after testing.
>> prepared 2 tests for Inkscape, first wa
On 15 December 2013 23:17, Martin Liška wrote:
> Dear Jan and Teresa,
> Jan was right that I've been using changes which were commited by
> Teresa and do live in trunk. So the graph with time profile presented
> in my previous post was really with enabled
> -freorder-blocks-and-partition. I re
> Jan Hubicka wrote:
> >Yep, they should not roduce incorrect code. Isn't the problem
> >that you expect the whole expression to have value and predit_expr
> >"reutrns" nothing?
> >Can you check what lands into gimple?
>
> That could well be the case – I replace "0" by "{ built_predict; 0
> }" and
Hi all,
The attached patch fixes the problem by properly exiting when an error has
occurred rather then falling through and creating the file.
The patch also fixes a few other places I found after auditing all calls to
generate error in libgfortran/io.
I will conjure up a test case for this.
I
Hi,
I checked in this patch to update x32 baseline_symbols.txt on 4.8
branch.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 206002)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-12-15 H.J. Lu
+
+ * config/ab
Jan Hubicka wrote:
Yep, they should not roduce incorrect code. Isn't the problem
that you expect the whole expression to have value and predit_expr
"reutrns" nothing?
Can you check what lands into gimple?
That could well be the case – I replace "0" by "{ built_predict; 0 }"
and I wouldn't be s
Hi,
the problem here is ipa-prop trying to analyze indirect call that has been
already turned to direct. While early opts should optimize this call (and
in fact I have approved patch to do so I forgot to apply), we should
not ICE in this case.
Fixed thus,
bootstrapped/regtested x86_64-linux, will
> Hi Honza,
>
> Jan Hubicka wrote:
> >But if you have something like
> >
> >a=__builtin_expect (b?1:0,0)
> >
> >and you produce
> >
> >a=b?predict_expr not_taken, 0,0
> >...
> >if (a)
> > unlikely path
> >
> >We need to check how it goes down to gimple.
>
> It seems as if something doesn't work
Hi Honza,
Jan Hubicka wrote:
But if you have something like
a=__builtin_expect (b?1:0,0)
and you produce
a=b?predict_expr not_taken, 0,0
...
if (a)
unlikely path
We need to check how it goes down to gimple.
It seems as if something doesn't work in that case – at least I do not
understa
Hi again
On Wednesday 11 December 2013, Uros Bizjak wrote:
> Hello!
>
> > PR gcc/59422
> >
> > This patch extends the supported targets for function multi versiong to
> > also include Haswell, Silvermont, and the most recent AMD models. It
> > also prioritizes AVX2 versions over AMD specific pre-
On 12/15/2013 11:40 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
it is certainly true that in order to do an unbounded set of operations,
you would have to check on every operation. so my suggestion that we
should remove the checking from the infinite precision would not support
this.
Hello!
Attached patch emits necessary emms instructions to fix mixed
V2SFmode/SFmode runtime test on 32bit x86 targets. The patch also
reorders functions a bit to group together MMX argument handlings, so
it becomes less fragile w.r.t. MMX/x87 interactions.
2013-12-15 Uros Bizjak
* gc
Hi,
this is a latent bug exposed on the mainline for the ARM by:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01755.html
The problem is that the CFI expressions for:
(insn/f:TI 102 11 103 (parallel [
(set (mem/c:BLK (pre_modify:SI (reg/f:SI 13 sp)
(plus:SI (
Kenneth Zadeck writes:
> it is certainly true that in order to do an unbounded set of operations,
> you would have to check on every operation. so my suggestion that we
> should remove the checking from the infinite precision would not support
> this. but the reality is that there are cur
On 12/15/2013 03:54 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
The current world
is actually structured so that we never ask about overflow for the two
larger classes because the reason that you used those classes was that
you never wanted to have this discussion. So if you never ask
Hi,
sorry for taking time to return back to this.
> Pre-remark:
>
> I had hoped that something like the following patch would work.
> However, it will lead to a bunch of run-time segfaults in the test
> suite - but the original dump seems to be fine and I also fail to
> spot the problem when looki
> From: Jonathan Wakely
> Date: Sun, 15 Dec 2013 11:38:43 +0100
> On Dec 15, 2013 6:57 AM, "Hans-Peter Nilsson"
> wrote:
> >
> > From the revision range 205803:205810 (excluding:including) an
> > on, my autotester for cris-elf reports a regression:
> >
> > Running
> > /tmp/hpautotest-gcc1/gcc/l
Hello!
This testcase assumes default SSE level less than 4.2. Limit it at SSE2.
2013-12-15 Uros Bizjak
* gcc.target/i386/pr57756.c (dg-options): Add -mno-sse3.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline.
Uros.
Index: gcc.target/i386/pr57756.c
==
On Sun, Dec 15, 2013 at 1:14 PM, Dominique Dhumieres wrote:
>> OTOH, I can't test darwin properly, please provide the patch and I'll
>> commit it for you.
>
> Basically the patch I have in my tree since the PR replace 'linux' with '*'
> (see below).
> Since I can only test darwin, there is no gua
> OTOH, I can't test darwin properly, please provide the patch and I'll
> commit it for you.
Basically the patch I have in my tree since the PR replace 'linux' with '*'
(see below).
Since I can only test darwin, there is no guarantee that the tests pass on
non-linux,
non-darwin platforms. So if
On Sun, Dec 15, 2013 at 12:58 PM, Dominique Dhumieres
wrote:
> This patch fix pr58630. However I still think that the tests
> func-2a.c, func-indirect-2a.c, vaarg-4a.c, and vaarg-5a.c
> should not be restricted to linux: they pass on darwin.
Thanks for the pointer, I'll add PR reference to the C
Hi Uros,
This patch fix pr58630. However I still think that the tests
func-2a.c, func-indirect-2a.c, vaarg-4a.c, and vaarg-5a.c
should not be restricted to linux: they pass on darwin.
TIA
Dominique
Hello!
Corei7 tuning doesn't set -maccumulate-outgoing-args option by default
and triggers various -mabi-ms related failures throughout the
testsuite [1]. Attached patch fixes failures by explicitly adding
-maccumulate-outgoing-args, as documented in the ms-abi option
documentation.
2013-12-15 U
*ping*
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00584.html
On December 6, 2013, Tobias Burnus wrote:
A rather simple fix for an ICE on invalid bug (low-priority 4.8/4.9
regression).
Bootstrapped and regtested without new failure on x86-64-gnu-linux.
OK for the trunk and 4.8?
Tobias
On Dec 15, 2013 6:57 AM, "Hans-Peter Nilsson"
wrote:
>
> From the revision range 205803:205810 (excluding:including) an
> on, my autotester for cris-elf reports a regression:
>
> Running
> /tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
> ...
> WARNING: program timed
Hi Tobias,
>> here is a rather simple fix for a problem with the pointer assignment
>> of an unlimited polymorphic variable. The patch regtests cleanly on
>> x86_64-unknown-linux-gnu.
>>
>> Firstly, I would like to commit to trunk, of course. Ok?
>>
>> Secondly, the bug reporter asked me (privatel
Kenneth Zadeck writes:
>>> + vallen = canonize (val, (uvlen + 1) >> 1, prec);
>>> +
>>> + /* Shift is not always safe to write over one of the
>>> +operands, so we must copy. */
>>> + HOST_WIDE_INT tval[2 * WIDE_INT_MAX_ELTS];
>>> + memcpy (tval, val, vallen * CHAR_BIT / H
Kenneth Zadeck writes:
>>> The current world
>>> is actually structured so that we never ask about overflow for the two
>>> larger classes because the reason that you used those classes was that
>>> you never wanted to have this discussion. So if you never ask about
>>> overflow, then it really do
Hi Janus,
Janus Weil wrote:
here is a rather simple fix for a problem with the pointer assignment
of an unlimited polymorphic variable. The patch regtests cleanly on
x86_64-unknown-linux-gnu.
Firstly, I would like to commit to trunk, of course. Ok?
Secondly, the bug reporter asked me (privatel
35 matches
Mail list logo
