Hi Kirill,
with the current trunk (newst "git" mirror version), bootstrapping fails
here with the following error. Did you forget to commit one file?
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-
On Fri, Oct 25, 2013 at 08:22:22AM +0200, Tobias Burnus wrote:
> Jason Merrill wrote:
> >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 ran
Hi Richard,
>> 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
Jason Merrill wrote:
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: a
On Thu, Oct 24, 2013 at 11:14:42PM -0600, Jeff Law wrote:
> On 10/24/13 15:10, Eric Botcazou wrote:
> >As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
> >pass has been context-sensitive for a long time when scratch registers are
> >needed, in the sense that the behaviour
On Thu, 24 Oct 2013, Jeff Law wrote:
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstra
Gerald Pfeifer wrote:
On Thu, 24 Oct 2013, Tobias Burnus wrote:
Any comments? Or is the patch OK?
thanks for doing this.
Thanks for looking at the patch. However, the patch has a link problem.
The documentation is at
http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html
That'
On 10/21/13 06:10, Ilya Enkovich wrote:
Hi,
This patch introduces two new contructor types supported by
cgraph_build_static_cdtor.
'B' type is used to initialize static objects (bounds) created by Pointers
Checker. The difference of this type from the regular constructor is that 'B'
construc
On 10/23/13 21:00, David Malcolm wrote:
I went through the various requirements listed in the doc and
investigated what happens when they're violated. Some lead to immediate
build failure in gengtype (which is relatively sane), but some lead to
silent lack of field-traversal. The details:
Yea,
On 10/21/13 05:49, Ilya Enkovich wrote:
Hi,
This patch introduces built-in functions used by Pointers Checker and flag to
enable Pointers Checker. Builtins available for user are expanded in
expand_builtin. All other builtins are not allowed in expand until generic
version of Pointers Cheker
On 10/21/13 05:59, Ilya Enkovich wrote:
Hi,
This patch adds attributes 'bnd_variable_size' and 'bnd_legacy' used by
Pointers Checker.
Bootstrapped and tested on linux-x86_64.
Thanks,
Ilya
--
gcc/
2013-10-21 Ilya Enkovich
* c-family/c-common.c (handle_bnd_variable_size_attribute)
On 10/24/13 23:23, Marc Glisse wrote:
Hello,
I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it make sense? (I am
Hello,
I noticed that in some cases we were failing to find aliasing information
because we were only looking at an SSA_NAME variable, missing the fact
that it was really an ADDR_EXPR. The attached patch passes
bootstrap+testsuite, does it make sense? (I am a bit afraid of losing some
type in
On 10/24/13 02:36, Ilya Enkovich wrote:
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 Rich
On 10/24/13 02:24, Ilya Enkovich wrote:
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
On 10/24/13 15:10, Eric Botcazou wrote:
As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
pass has been context-sensitive for a long time when scratch registers are
needed, in the sense that the behaviour of the pass for a given function is
dependent on what happened for
On 10/24/13 18:20, Igor Shevlyakov wrote:
I stumbled on a case like this:
If the multipliers allowed for addressing modes are dependent on actual
mode, in some cases compiler
refuses to recognize address as legitimate.
It boils down to this place in expr.c where address_mode is incorrectly
used i
On 10/24/13 15:28, Eric Botcazou wrote:
This is a very old bug in the alias.c machinery, which is exposed during
the sched2 pass. We have in .split4:
(insn 23 22 24 4 (set (mem/f:DI (reg/v/f:DI 4 si [orig:90 p2 ] [90]) [3
*p2_9(D)+0 S8 A64])
(symbol_ref:DI ("d") )) pr58831-1.c:12 85
{
Yup, my registers are smaller than Pmode.
This is what I ended up with...
Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
when it's really one. None of the register classes have reg 23 (used
for the upper half of $fp) in them. Reg 23 is also listed as being
two bytes, to ke
Oleg Endo wrote:
> The attached patch fixes volatile mem stores on SH so that they won't
> result in redundant sign/zero extensions and will utilize available
> addressing modes. This is similar to what has been done to fix memory
> loads in http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01315.html
On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
> On Mon, 21 Oct 2013, 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.
> >
> >
On Oct 24, 2013, at 6:25 PM, Andrew Pinski wrote:
>> enum raw_str_phase phase = RAW_STR_PREFIX;
>
> This is a good work around but please add a comment of why this is
> needed (to work around a bug in XLC++).
Oh, curious, I was assuming that file was compiled by the C compiler… not as
obvious
On Thu, Oct 24, 2013 at 6:22 PM, Mike Stump wrote:
> On Oct 24, 2013, at 2:05 AM, Jan-Benedict Glaw wrote:
>> - enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX };
>> - raw_str_phase phase = RAW_STR_PREFIX;
>> + enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX } phase =
On Oct 24, 2013, at 2:05 AM, Jan-Benedict Glaw wrote:
> - enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX };
> - raw_str_phase phase = RAW_STR_PREFIX;
> + enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX } phase =
> RAW_STR_PREFIX;
Since no one else chimed in… seems
I noticed that some of the macros in tree.h that act on trees have
parameters named "CODE", rather "NODE", which is confusing when in the
presence of other macros that act on enum tree_code values.
The attached patch renames such params for macros that I believe act on
trees (mostly because they g
Hi Tobias,
On Thu, 24 Oct 2013, Tobias Burnus wrote:
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 [
I stumbled on a case like this:
If the multipliers allowed for addressing modes are dependent on actual
mode, in some cases compiler
refuses to recognize address as legitimate.
It boils down to this place in expr.c where address_mode is incorrectly
used instead of actual mode.
I rebootstraped and
On Wed, Oct 23, 2013 at 11:18 PM, Jakub Jelinek wrote:
> On Wed, Oct 23, 2013 at 09:40:21PM -0700, Cong Hou wrote:
>> On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
>> wrote:
>> > On Tue, 22 Oct 2013, Cong Hou wrote:
>> >
>> >> For abs(char/short), type conversions are needed as the current abs
On Oct 24, 2013, at 2:26 AM, Vidya Praveen wrote:
> 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 u
On 10/24/2013 05:02 AM, Richard Sandiford wrote:
> Do we actually need to do a conversion here at all? It looks like the
> modes of "expected" and "desired" should already match "mem", so we could
> just use create_input_operand.
This works. I've committed the following to mainline, and will
tes
On 10/24/13 15:53, Marek Polacek wrote:
On Thu, Oct 24, 2013 at 03:22:42PM -0600, Jeff Law wrote:
On 10/24/13 14:56, Steven Bosscher wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
the mudflap specific tests were deleted and not run and were manually
ignored whe
Hi Tobias,
On Thu, 24 Oct 2013, Tobias Burnus wrote:
Any comments? Or is the patch OK?
thanks for doing this.
Index: htdocs/gcc-4.9/changes.html
===
+With the new http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.ht
On Mon, 21 Oct 2013, 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 branches, you'd need to
On Thu, Oct 24, 2013 at 03:22:42PM -0600, Jeff Law wrote:
> On 10/24/13 14:56, Steven Bosscher wrote:
> >>Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
> >>the mudflap specific tests were deleted and not run and were manually
> >>ignored when comparing testsuite runs.
>
This is a very old bug in the alias.c machinery, which is exposed during
the sched2 pass. We have in .split4:
(insn 23 22 24 4 (set (mem/f:DI (reg/v/f:DI 4 si [orig:90 p2 ] [90]) [3
*p2_9(D)+0 S8 A64])
(symbol_ref:DI ("d") )) pr58831-1.c:12 85
{*movdi_internal}
(expr_list:REG_DEAD
On 10/24/13 14:56, Steven Bosscher wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
the mudflap specific tests were deleted and not run and were manually
ignored when comparing testsuite runs.
OK for the trunk?
The flags in c.opt should be retained as NOPs. Or
Committed to dmalcolm/jit branch:
This is a work-in-progress, and currently doesn't achieve very deep
coverage of the code, due to mismatching types.
gcc/testsuite/
* jit.dg/harness.h (main): Wrap with #ifndef TEST_PROVIDES_MAIN
* jit.dg/test-fuzzer.c: New.
---
gcc/testsuite/Chan
As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
pass has been context-sensitive for a long time when scratch registers are
needed, in the sense that the behaviour of the pass for a given function is
dependent on what happened for the previously optimized function.
Obv
On Thu, Oct 24, 2013 at 10:35 PM, Jeff Law wrote:
> On 10/24/13 07:40, Richard Biener wrote:
we were supposed to remove mudflap for 4.9, no?
>>> Really? I guess it hasn't been removed yet since the include is still
>>> there? who is doing that?
>>
>>
>> Yeah, nobody has done i
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
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
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 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
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 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
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/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
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
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
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-
> 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
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 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/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
> 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
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
===
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
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
* 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/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
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 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 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
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 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.
>>
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: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
> 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 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
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 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
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
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
==
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
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
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 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
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 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
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
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
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
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
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, 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
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
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.
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 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
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
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 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: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
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
>> 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
> 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
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
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 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 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
1 - 100 of 139 matches
Mail list logo
