Hi Martin,
On Wed, 23 Oct 2013 19:11:06, Martin Jambor wrote:
> On Wed, Oct 23, 2013 at 06:00:43PM +0200, Richard Biener wrote:
>>
>
> ...
>
>> ? And why should the same issue not exist for
>>
>> struct { V a[1]; }
>>
>
> indeed, it does and it's simple to trigger (on x86_64):
>
>
On Wed, 2013-10-23 20:21:50 -0400, David Edelsohn wrote:
> On Wed, Oct 23, 2013 at 6:21 PM, Jan-Benedict Glaw wrote:
> > When building on gcc111, I tried to use different compilers for my
> > build robot. This machine has IBM's XL C compiler installed, but not
> > the C++ compiler. So I used CC=x
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Thursday, October 24, 2013 12:14 AM
> To: Zhenqiang Chen; Richard Earnshaw; 'Richard Biener'
> Cc: GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
>
> > +static enum rtx_code
> > +arm_cc
Hi,
REG_INC note is lost in subreg2 pass when resolve_simple_move, which
might lead to wrong dependence for ira. e.g. In function
validate_equiv_mem of ira.c, it checks REG_INC note:
for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
if ((REG_NOTE_KIND (note) == REG_INC
2013/10/24 Jeff Law :
> On 10/21/13 08:20, Ilya Enkovich wrote:
>
>> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
>> index 8d220f3..79bd0f9 100644
>> --- a/gcc/doc/tm.texi
>> +++ b/gcc/doc/tm.texi
>> +@deftypefn {Target Hook} rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx @var{slot},
>> rtx @var{arg}, rtx @
> if bitregion_start/end are used after the adjust_address call then they have
> to be adjusted (or bitpos left in place). In fact why we apply byte-parts
> of bitpos here only if offset != 0 is weird.
Presumably to be able to do arithmetic on symbols when the offset is variable,
which can save
2013/10/24 Richard Henderson :
> On 10/23/2013 02:41 PM, Jeff Law wrote:
>> Out of curiosity, did you consider and/or discuss with Richard whether or not
>> to make these target-dependent or target-independent builtins? I realize
>> it's
>> a bit problematic with Richard being involved during the
> The most isolated patch I can come up with, especially since we ought to
> fix this in 4.8 branch as well, is to only allow expansion of wide int
> modes to const_int when they're positive.
>
> Thoughts?
That's a fairly dangerous hack in my opinion, in particular this breaks the
uniqueness of
On Wed, 23 Oct 2013, Richard Sandiford wrote:
> Mike Stump writes:
> > On Oct 23, 2013, at 5:00 AM, Richard Sandiford
> > wrote:
> >> offset_int, max_int, wi::to_offset and wi::to_max sound OK to me.
> >> Kenny? Mike?
> >
> > Those two names seem reasonable. to_offset should document that thes
On Wed, 23 Oct 2013, Richard Sandiford wrote:
> This patch stores two array lengths in an INTEGER_CST: the length that
> should be used when accessing the constant in its TYPE_PRECISION,
> and the one that should be used for wider precisions. This means that
> the main tree decompose routine is j
2013/10/24 Jeff Law :
> On 10/23/13 04:57, Ilya Enkovich wrote:
>>
>>
>> 2013-10-23 Ilya Enkovich
>>
>> * mode-classes.def (MODE_POINTER_BOUNDS): New.
>> * tree.def (POINTER_BOUNDS_TYPE): New.
>> * genmodes.c (complete_mode): Support MODE_POINTER_BOUNDS.
>> (POINT
> I think that is common practice to write array[1]; at the end of the
> structure, and use it as a flexible array. The compute_record_mode has no
> way to decide if that is going to be a flexible array or not.
>
> Sorry Eric, but now I have no other choice than to go back to my previous
> version
Attached is the patch which does the following scheduler related changes.
* re-models bdver3 decoder.
* It enables lookahead with value 8 for all BD architectures. The patch doesn't
consider if reloading is completed or not (an area that needs to be worked on).
* The issue rate for BD architecture
Hi!
While building with IBM's XL C/C++ compiler, I noticed (cf.
http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=128806):
source='/home/jbglaw/repos-IBM-XL/gcc/libcpp/lex.c' object='lex.o' libtool=no
DEPDIR=.deps depmode=aix /bin/sh
/home/jbglaw/repos-IBM-XL/gcc/libcpp/../
Il 24/10/2013 03:17, Tom Tromey ha scritto:
> Jan-Benedict> I'd like to get some comments on this patch, which works
> Jan-Benedict> for me for stage-1 builds with gcc/g++ (on a amd64-linux
> Jan-Benedict> box) as well as with xlC/g++ on gcc111 (the mentioned AIX
> Jan-Benedict> machine):
>
> FW
> Attached is the patch which does the following scheduler related changes.
> * re-models bdver3 decoder.
> * It enables lookahead with value 8 for all BD architectures. The patch
> doesn't consider if reloading is completed or not (an area that needs to be
> worked on).
> * The issue rate for BD
On Mon, Oct 21, 2013 at 06:40:28PM +0100, Mike Stump wrote:
> On Oct 21, 2013, at 3:28 AM, Vidya Praveen wrote:
> > Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This
> > can
> > be a issue especially since they define uint32_t.
>
> > OK for 4.7, 4.8?
>
> For release bran
On Mon, Oct 21, 2013 at 05:47:44PM +0100, Jeff Law wrote:
> On 10/21/13 04:28, Vidya Praveen wrote:
> > Hello,
> >
> > Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This
> > can
> > be a issue especially since they define uint32_t. Testcase writing
> > guidelines
> > discou
>> I think that is common practice to write array[1]; at the end of the
>> structure, and use it as a flexible array. The compute_record_mode has no
>> way to decide if that is going to be a flexible array or not.
>>
>> Sorry Eric, but now I have no other choice than to go back to my previous
>> ve
On Thu, Oct 24, 2013 at 10:37 AM, Eric Botcazou wrote:
>> if bitregion_start/end are used after the adjust_address call then they have
>> to be adjusted (or bitpos left in place). In fact why we apply byte-parts
>> of bitpos here only if offset != 0 is weird.
>
> Presumably to be able to do arith
On Thu, Oct 24, 2013 at 10:43 AM, Eric Botcazou wrote:
>> The most isolated patch I can come up with, especially since we ought to
>> fix this in 4.8 branch as well, is to only allow expansion of wide int
>> modes to const_int when they're positive.
>>
>> Thoughts?
>
> That's a fairly dangerous ha
> Because of the ABI-change?
While concerns about accidental ABI changes are real, they shouldn't be
overstated either. We have been saying for longer than a decade that the
back-ends must not use the type mode to implement calling conventions and
other external interfaces.
--
Eric Botcazou
On 01 Oct 20:00, Uros Bizjak wrote:
>
> This is OK for mainline, on the condition that target independent part
> is approved and committed first.
>
> Thanks,
> Uros.
Thanks for review!
Attached is a version to be committed. The only difference from the previous
one is BOUND_MODE renamed to PO
Hi,
On Thu, 24 Oct 2013 11:56:52, Richard Biener wrote:
>
> On Thu, Oct 24, 2013 at 10:37 AM, Eric Botcazou wrote:
>>> if bitregion_start/end are used after the adjust_address call then they have
>>> to be adjusted (or bitpos left in place). In fact why we apply byte-parts
>>> of bitpos here only
On Thu, 2013-10-24 10:16:25 +0100, Paolo Bonzini wrote:
> Il 24/10/2013 03:17, Tom Tromey ha scritto:
> > Jan-Benedict> I'd like to get some comments on this patch, which works
> > Jan-Benedict> for me for stage-1 builds with gcc/g++ (on a amd64-linux
> > Jan-Benedict> box) as well as with xlC/g
On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou wrote:
>> I think that is common practice to write array[1]; at the end of the
>> structure, and use it as a flexible array. The compute_record_mode has no
>> way to decide if that is going to be a flexible array or not.
>>
>> Sorry Eric, but now I h
On Thu, Oct 24, 2013 at 9:15 AM, Bernd Edlinger
wrote:
> Hi Martin,
>
> On Wed, 23 Oct 2013 19:11:06, Martin Jambor wrote:
>> On Wed, Oct 23, 2013 at 06:00:43PM +0200, Richard Biener wrote:
>>>
>>
>> ...
>>
>>> ? And why should the same issue not exist for
>>>
>>> struct { V a[1]; }
>>>
>>
>> inde
Hi,
this is a follow-up to http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00895.html
which fixed the 3. issue partially. This resulted in gcc.dg/guality/param-2.c
being compiled with -fno-var-tracking-assignments.
The attached testcase param-3.c is identical to param-2.c but without the
special
On 2013.10.21 at 09:33 +0200, Markus Trippelsdorf wrote:
Ping.
I do not have write access...
>
> LTO bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> I would be grateful if one of you guys could apply it.
> Thanks.
>
> 2013-10-21 Markus Trippelsdorf
>
> PR ipa/58712
>
On Wed, Oct 23, 2013 at 07:22:20PM +0200, Jakub Jelinek wrote:
> On Tue, Oct 22, 2013 at 08:27:54PM +0400, Sergey Ostanevich wrote:
> > still fails on 403 et al.
>
> Ok, reproduced, unfortunately the pending stmt sequences already pretty much
> assume that they will end up in a single combined bas
> That's a fairly dangerous hack in my opinion, in particular this breaks the
> uniqueness of representation of -1 as constm1_rtx. Can't we find a really
> contained hack instead, especially if we want to backport it to 4.8?
In particular, can't Uros' patch be considered as such here? Frankly, t
On Thu, Oct 24, 2013 at 12:06 PM, Ilya Enkovich wrote:
> On 01 Oct 20:00, Uros Bizjak wrote:
>>
>> This is OK for mainline, on the condition that target independent part
>> is approved and committed first.
>>
>> Thanks,
>> Uros.
>
> Thanks for review!
>
> Attached is a version to be committed. Th
Hi,
> Is this with -fschedule-insns? Or only with default settings? Did you test
> the compile time implications of increasing the lookahead? (value of 8 is
> very large, we may consider enbling it only for -Ofast, limiting for
> postreload only or something similar).
The improvement is seen
2013/10/24 Uros Bizjak :
> On Thu, Oct 24, 2013 at 12:06 PM, Ilya Enkovich
> wrote:
>> On 01 Oct 20:00, Uros Bizjak wrote:
>>>
>>> This is OK for mainline, on the condition that target independent part
>>> is approved and committed first.
>>>
>>> Thanks,
>>> Uros.
>>
>> Thanks for review!
>>
>> A
On Thu, Oct 24, 2013 at 1:29 PM, Ilya Enkovich wrote:
This is OK for mainline, on the condition that target independent part
is approved and committed first.
Thanks,
Uros.
>>>
>>> Thanks for review!
>>>
>>> Attached is a version to be committed. The only difference from
Eric Botcazou writes:
>> That's a fairly dangerous hack in my opinion, in particular this breaks the
>> uniqueness of representation of -1 as constm1_rtx. Can't we find a really
>> contained hack instead, especially if we want to backport it to 4.8?
>
> In particular, can't Uros' patch be conside
On Thu, 24 Oct 2013 12:18:43, Richard Biener wrote:
>
> On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou wrote:
>>> I think that is common practice to write array[1]; at the end of the
>>> structure, and use it as a flexible array. The compute_record_mode has no
>>> way to decide if that is going t
I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
believe the suggestion was to eventually move it to targhooks.c.
build_va_arg_indirect_ref seems to hang around with it, and used by all
the same things that use std_gimplify_va_arg_expr, so this patch
currently lumps it
On Thu, Oct 24, 2013 at 12:22 PM, Richard Biener
wrote:
> On Thu, Oct 24, 2013 at 9:15 AM, Bernd Edlinger
> wrote:
>> Hi Martin,
>>
>> On Wed, 23 Oct 2013 19:11:06, Martin Jambor wrote:
>>> On Wed, Oct 23, 2013 at 06:00:43PM +0200, Richard Biener wrote:
>>>
>>> ...
>>>
? And why should
On Thu, Oct 24, 2013 at 2:55 PM, Bernd Edlinger
wrote:
> On Thu, 24 Oct 2013 12:18:43, Richard Biener wrote:
>>
>> On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou
>> wrote:
I think that is common practice to write array[1]; at the end of the
structure, and use it as a flexible array. T
On Thu, Oct 24, 2013 at 3:06 PM, Andrew MacLeod wrote:
> I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
> believe the suggestion was to eventually move it to targhooks.c.
>
> build_va_arg_indirect_ref seems to hang around with it, and used by all the
> same things that use
On Thu, Oct 24, 2013 at 02:55:59PM +0200, Bernd Edlinger wrote:
> On Thu, 24 Oct 2013 12:18:43, Richard Biener wrote:
> >
> > On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou
> > wrote:
> >>> I think that is common practice to write array[1]; at the end of the
> >>> structure, and use it as a flex
On 10/14/2013 08:23 AM, Marek Polacek wrote:
We were ICEing on the attached testcase, because in check_narrowing,
for = {{}}, we wanted to check recursively the CONSTRUCTOR_ELTs,
even though init in this case has 0 CONSTRUCTOR_NELTS. So I added
the check for CONSTRUCTOR_NELTS > 0. Moreover, sin
> Hi,
>
> > Is this with -fschedule-insns? Or only with default settings? Did you test
> > the compile time implications of increasing the lookahead? (value of 8 is
> > very large, we may consider enbling it only for -Ofast, limiting for
> > postreload only or something similar).
>
> The imp
>> Did you just propose:
>>
>> --- stor-layout.c.orig 2013-10-22 10:46:49.233261818 +0200
>> +++ stor-layout.c 2013-10-24 14:54:00.425259062 +0200
>> @@ -471,27 +471,7 @@
>> static enum machine_mode
>> mode_for_array (tree elem_type, tree size)
>> {
>> - tree elem_size;
>> - unsigned HOST_WIDE_INT
Status
==
The trunk is scheduled to transition from Stage 1 to Stage 3 at the end
of Thursday, Nov. 21 (use your timezone to your advantage).
We have been in Stage 1 for more than 7 months now with almost a full
month still to go. Still now is a good time to look into bugzilla
and pick one
On Thu, Oct 24, 2013 at 3:13 PM, Jakub Jelinek wrote:
> On Thu, Oct 24, 2013 at 02:55:59PM +0200, Bernd Edlinger wrote:
>> On Thu, 24 Oct 2013 12:18:43, Richard Biener wrote:
>> >
>> > On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou
>> > wrote:
>> >>> I think that is common practice to write arr
On 10/24/2013 09:11 AM, Richard Biener wrote:
On Thu, Oct 24, 2013 at 3:06 PM, Andrew MacLeod wrote:
I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
believe the suggestion was to eventually move it to targhooks.c.
build_va_arg_indirect_ref seems to hang around with it,
On Thu, Oct 24, 2013 at 3:38 PM, Andrew MacLeod wrote:
> On 10/24/2013 09:11 AM, Richard Biener wrote:
>>
>> On Thu, Oct 24, 2013 at 3:06 PM, Andrew MacLeod
>> wrote:
>>>
>>> I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
>>> believe the suggestion was to eventually move i
On Thu, Oct 24, 2013 at 09:16:05AM -0400, Jason Merrill wrote:
> On 10/14/2013 08:23 AM, Marek Polacek wrote:
> >We were ICEing on the attached testcase, because in check_narrowing,
> >for = {{}}, we wanted to check recursively the CONSTRUCTOR_ELTs,
> >even though init in this case has 0 CONSTRUCTO
Hi Ed,
I committed half of your patch (the unused variable part) in r204011
and removed the unused keywords as a resolution for the other half in
r204012.
Changelog/patch follow:
2013-10-24 Andrew Sutton
* gcc/cp/c-common.c (c_common_r): Remove unused keywords "assume",
"axiom
Richard Biener wrote:
Please instead amend tree-cfg.c:execute_build_cfg and do after
loop_optimizer_init sth like
[...]
possibly doing after it
FOR_EACH_BB (bb)
[...]
+DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expression, 1)
FIXME? Btw, not using a tree operand here is somewhat of a
Hi,
I just hit this problem where gengtype thought an existing gt-*.h header
was the same as what it wanted to write because its prefix was indeed
equal to the buffer, but contained some additional things afterwards.
gengtype simply forgot to check that the file end is reached at buffer
end.
On Thu, 24 Oct 2013, Tobias Burnus wrote:
> Richard Biener wrote:
> > Please instead amend tree-cfg.c:execute_build_cfg and do after
> > loop_optimizer_init sth like
> > [...]
> > possibly doing after it
> >FOR_EACH_BB (bb)
> > [...]
> > +DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expres
On Thu, Oct 24, 2013 at 03:59:14PM +0200, Tobias Burnus wrote:
> + FOR_EACH_LOOP (li, loop, 0)
> +if (loop->latch)
> + FOR_EACH_EDGE (e, ei, loop->latch->succs)
Isn't the only successor of loop->latch loop->header?
Thus, can't you just remove the above two lines and use loop->header
inst
Hi Guys,
I am applying the patch below as an obvious update to the 20020312-2.c
test for the RL78 and MSP430 targets. Neither of them use a specific
regiser for PIC support, but the test needs to be explicitly told
that.
Cheers
Nick
gcc/testsuite/ChangeLog
2013-10-24 Nick Clifton
On Thu, 24 Oct 2013, Jakub Jelinek wrote:
> On Thu, Oct 24, 2013 at 03:59:14PM +0200, Tobias Burnus wrote:
> > + FOR_EACH_LOOP (li, loop, 0)
> > +if (loop->latch)
> > + FOR_EACH_EDGE (e, ei, loop->latch->succs)
>
> Isn't the only successor of loop->latch loop->header?
> Thus, can't you
This finally computes a valid partition ordering (or if not possible
merge partitions again) in loop distribution. This is the only
place where data dependences are relevant, so we delay computing them
(and also do not compute all N^2 dependences).
Bootstrapped and tested on x86_64-unknown-linux
esOn 21 Oct 12:08, Joseph S. Myers wrote:
> On Mon, 21 Oct 2013, Ilya Enkovich wrote:
>
> > + if (flag_check_pointers)
> > +{
> > + if (flag_lto)
> > + sorry ("Pointers checker is not yet fully supported for link-time
> > optimization");
>
> That sounds wrong. It suggests some bug s
On 21 October 2013 09:41, Kyrill Tkachov wrote:
> [gcc/testsuite]
> 2013-10-21 Kyrylo Tkachov
>
> * gcc.target/aarch64/c-output-mod-2.c: Fix for -fPIC.
> * gcc.target/aarch64/c-output-mod-3.c: Likewise.
OK
/Marcus
On 24/10/13 00:04, Kugan wrote:
Hi,
arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
instruction, with other vector instructions. However, a
Here is an updated version with changes due to renames in basic bounds type
patch.
Thanks,
Ilya
--
gcc/
2013-10-23 Ilya Enkovich
* tree-core.h (tree_index): Add TI_POINTER_BOUNDS_TYPE.
* tree.h (POINTER_BOUNDS_P): New.
(BOUNDED_TYPE_P): New.
(BOUNDED_P): New.
On 10/24/13 01:29, Richard Henderson wrote:
On 10/21/2013 03:01 PM, Yufeng Zhang wrote:
This patch changes the widening_mul pass to fuse the widening multiply with
accumulate only when the multiply has single use. The widening_mul pass
currently does the conversion regardless of the number of
Hi Kyrill,
Kugan only fixes the tests we have observed to fail.
The different allocation is not caused by LRA, since we haven't
backported it to our 4.8-based branch.
The different allocation is caused by another difference between 4.8 and trunk.
Christophe.
On 24 October 2013 16:39, Kyrill Tka
On 15 October 2013 22:35, Mike Stump wrote:
> Would be nice for a build/config person to weigh in or to upgrade and make
> bullet proof the system against such failures. My take, by default, the
> compile line should do something useful, and that should be enough for
> autoconf style tests to
Ping?
On 10 October 2013 00:16, Christophe Lyon wrote:
> Hi,
>
> This patch is a first small sample of dejagnu-ization of my ARM Neon
> intrinsics tests.
>
> It's derived from my previous work at
> http://gitorious.org/arm-neon-tests/arm-neon-tests which supports all
> the ARM intrinsics, with ex
This test will fail if we don't have
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=r201824
Bootstrapped and passed regression test.
OK for trunk?
gcc/testsuite/ChangeLog:
2013-10-24 Dehao Chen
* g++.dg/opt/devirt3.C: New test.
Index: gcc/testsuite/g++.dg/opt/devirt3.C
==
Hi,
this is just a preview, but I decided to send it out early to understand
if I'm on the right track or not. As you can see in the Bug, this
started as a spin-off of a library issue with complex pow, which led us to:
__builtin_exp(-__builtin_huge_val())
not being folded to a constant a
On 10/24/2013 09:40 AM, Richard Biener wrote:
On Thu, Oct 24, 2013 at 3:38 PM, Andrew MacLeod wrote:
On 10/24/2013 09:11 AM, Richard Biener wrote:
On Thu, Oct 24, 2013 at 3:06 PM, Andrew MacLeod
wrote:
I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
believe the suggest
On 6/20/13 9:49 AM, Mike Stump wrote:
> On May 30, 2013, at 12:59 PM, Cesar Philippidis
> wrote:
>> Here is a patch from our backlog at Mentor Graphics that addresses a
>> libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following
>> error with dejagnu
>
>> Is it OK for trunk?
>
On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
>> Why would you need to encode comparisons in CCmodes?
>> That looks like a mis-design to me.
>
> The CCmodes are used to check whether the result of a previous conditional
> compare can combine with current compare. By changing it to rtx_code, I can
> This test will fail if we don't have
> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=r201824
>
> Bootstrapped and passed regression test.
>
> OK for trunk?
This is OK. Thanks!
If they fail on FSF 4.8, I can work on backporting the patch.
it is quite self contained and safe.
Honza
>
>
On 24/10/13 17:15, Richard Henderson wrote:
> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
>>> Why would you need to encode comparisons in CCmodes?
>>> That looks like a mis-design to me.
>>
>> The CCmodes are used to check whether the result of a previous conditional
>> compare can combine with
Committed to trunk, and verified that FSF 4.8 will also fail this test.
Quick question, is it possible that these two patches will trigger
other bugs? The reason I ask is that I saw you have many other patches
later for devirtualization related code, which made me a little
nervous about this.
Tha
On 24/10/13 17:26, Richard Henderson wrote:
> On 10/24/2013 09:24 AM, Richard Earnshaw wrote:
>> On 24/10/13 17:15, Richard Henderson wrote:
>>> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
> Why would you need to encode comparisons in CCmodes?
> That looks like a mis-design to me.
>>
Hi Guys,
The patch below includes a selection of improvements for the tests in
the gcc.dg part of the gcc testsuite. It basically annotates tests
that have some implicit assumptions about the target that is being
tested (word size, supported features, etc).
I started making this patch
On Thu, 2013-10-24 at 15:53 +0100, Marcus Shawcroft wrote:
> Steve,
>
> Can your build be fixed allowing us to back out:
> http://gcc.gnu.org/ml/fortran/2013-06/msg00038.html
>
> ?
>
> I'd really like to make some progress on this, while my proposed patch
> does resolve the regression introduce
On 24/10/13 15:52, Christophe Lyon wrote:
Hi Kyrill,
Kugan only fixes the tests we have observed to fail.
The different allocation is not caused by LRA, since we haven't
backported it to our 4.8-based branch.
The different allocation is caused by another difference between 4.8 and trunk.
I can't
On 10/24/2013 09:24 AM, Richard Earnshaw wrote:
> On 24/10/13 17:15, Richard Henderson wrote:
>> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
Why would you need to encode comparisons in CCmodes?
That looks like a mis-design to me.
>>>
>>> The CCmodes are used to check whether the result
On 10/24/2013 09:37 AM, Richard Earnshaw wrote:
> It still needs to put out the right final condition based on the
> comparisons that were previously done. At least traditionaly (in the
> existing ARM code) the comparison was just EQ or NE even if the original
> tests were inequalities; so the onl
* gcc/config/arc/arc.c (arc_ccfsm_post_advance): Also handle
TYPE_UNCOND_BRANCH.
(arc_ifcvt) : Check that arc_ccfsm_post_advance
changes statep->state.
On 10/24/13 10:45, Nick Clifton wrote:
Hi Guys,
The patch below includes a selection of improvements for the tests in
the gcc.dg part of the gcc testsuite. It basically annotates tests
that have some implicit assumptions about the target that is being
tested (word size, supported fe
On 10/24/13 04:50, Markus Trippelsdorf wrote:
On 2013.10.21 at 09:33 +0200, Markus Trippelsdorf wrote:
Ping.
I do not have write access...
LTO bootstrapped and tested on x86_64-unknown-linux-gnu.
I would be grateful if one of you guys could apply it.
Thanks.
2013-10-21 Markus Trippelsdorf
Hi Honza,
It looks like cgraph_fnver_htab defined in cgraph.c is not added
to gc root in gt-cgraph.h. This patch fixes it.
* cgraph.c (cgraph_fnver_htab): Move GTY((...)) to be before htab_t.
Change param_is to use
the struct and not the pointer to the struct.
Index: gcc/cgraph.c
===
> Hi Honza,
>
> It looks like cgraph_fnver_htab defined in cgraph.c is not added
> to gc root in gt-cgraph.h. This patch fixes it.
>
> * cgraph.c (cgraph_fnver_htab): Move GTY((...)) to be before htab_t.
> Change param_is to use
> the struct and not the pointer to the struct.
OK,
thanks!
Hon
On 10/23/13 16:31, Richard Henderson wrote:
On 10/23/2013 02:41 PM, Jeff Law wrote:
Out of curiosity, did you consider and/or discuss with Richard whether or not
to make these target-dependent or target-independent builtins? I realize it's
a bit problematic with Richard being involved during th
I have updated the patch according to your suggestion, and have
committed the patch as the bootstrapping and make check both get
passed.
Thank you for your patient help on this patch! I learned a lot from it.
thanks,
Cong
On Wed, Oct 23, 2013 at 1:13 PM, Joseph S. Myers
wrote:
> On Mon, 7 Oct
On 10/22/13 17:42, Igor Shevlyakov wrote:
2013-10-22 Igor Shevlyakov
* tree-ssa-loop-ivopts.c (multiplier_allowed_in_address_p ): Check both
[reg+mult*reg] and [mult*reg] to determine if multiplier is allowed.
Thanks. I've re-bootstrapped & regtested on x86_64-unknown-linux-gnu
with the tr
> I can't seem to get it to fail on my checkout of the linaro 4.8 branch.
> I tried both arm-none-eabi and arm-none-linux-gnueabihf. What kind of
> options/configuration are needed to reproduce this? Also, what kind of
> assembly is produced when the testcase fails? It'd be nice to make sure
> tha
The master Go testsuite uses lines like
// ERROR "first error" "second error"
to match multiple errors on a second line. This patch to the Go
testsuite driver supports that format. It accepts any of the errors,
but does not require that all of them be present. Ran Go testsuite on
x86_64-
This patch from Chris Manghane adds support for three-index slices to
the Go frontend. Three-index slices are new language feature in Go 1.2
(http://tip.golang.org/doc/go1.2#three_index). Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 88673182
Another small update: Due to a ME review comment, the way ANNOTATE_EXPR
are built has changed.
The patch was tested together with the (now committed) ME/C/Fortran
patch in an all-language bootstrap and regtesting on x86-64-gnu-linux.
Is the C++ patch okay for the trunk?
Tobias
On October 22
On 10/24/2013 12:12 AM, Paolo Carlini wrote:
On 10/23/2013 11:22 PM, François Dumont wrote:
You are right, I am preparing a test case. However you have to know
that __check_dereferenceable is simply not used for the moment. It is
only because I have started using it for a debug mode evolution t
Dear Gerald, dear all,
the patch adds a quip about the new "#pragma GCC ivdep" to the release
notes. Additionally, I updated the Fortran section based on the changes
accumulated on http://gcc.gnu.org/wiki/GFortran#news
Any comments? Or is the patch OK?
Tobias
Index: htdocs/gcc-4.9/changes.ht
On 10/23/13 07:05, Richard Biener wrote:
Btw, -ftree-isolate-paths sounds a bit generic for isolating paths leading
to undefined behavior, maybe -fisolate-errorneous-paths? (please drop
'tree-' from new options, 'tree' isn't meaningful to GCC users)
Seems reasonable, particularly since I think t
Hi Jakub and Gerald,
the attached patch updates the gomp project patch.
(Besides adding an item for the OpenMP 4.0 merge, I removed the "95"
from "Fortran 95" as Fortran is backward compatible and gfortran is
effectively a Fortran 66/77/90/95/2003/2008 compiler [minus bugs and
some missing fe
On 09/25/2013 08:41 AM, Marek Polacek wrote:
+ /* Do the instrumentation of VLAs if desired. */
+ if ((flag_sanitize & SANITIZE_VLA)
+ && size && !TREE_CONSTANT (size)
+ /* From C++1y onwards, we throw an exception on a negative length size
+ of an array. */
+ && cxx_di
Richard Biener writes:
> On Wed, 23 Oct 2013, Richard Sandiford wrote:
>> This patch stores two array lengths in an INTEGER_CST: the length that
>> should be used when accessing the constant in its TYPE_PRECISION,
>> and the one that should be used for wider precisions. This means that
>> the mai
On 10/10/2013 04:46 AM, Tobias Burnus wrote:
I considered to add the annotation also to C++11's range-based loops,
but as those are unlikely to vectorize, I didn't do so.
I would think that a range-based loop over an array should vectorize nicely:
int ar[8];
for (int i: ar) { ... }
But your m
I've committed the following fixes to the dmalcolm/jit branch:
(Found via fuzz testing)
gcc/jit/
* internal-api.c (gcc::jit::function::add_eval): Handle non-NULL
locations.
(gcc::jit::context::handle_locations): Fix test for the various
kinds of declarations, repla
1 - 100 of 139 matches
Mail list logo
