On 05/27/11 08:10, Tobias Burnus wrote:
> Attached is a small coarray fix, solving two issues:
>
> - For -fcoarray=single, nonallocatable coarrays are nonpointer - but
> currently they get set the "restrict" qualifier. (With -fcoarray=lib,
> nonallocatble coarrays are always pointers.)
> Fixed by
Attached is a small coarray fix, solving two issues:
- For -fcoarray=single, nonallocatable coarrays are nonpointer - but
currently they get set the "restrict" qualifier. (With -fcoarray=lib,
nonallocatble coarrays are always pointers.)
Fixed by not setting "restricted" in this case.
- The p
On Thu, May 26, 2011 at 9:53 PM, H.J. Lu wrote:
> On Fri, Apr 22, 2011 at 5:35 AM, Jan Hubicka wrote:
>> Hi,
>> this patch implements infrastructure to summarize function body size&time in
>> a
>> way that is sensitive on function context. At the moment context means
>>
>> 1) if function is in
On Fri, Apr 22, 2011 at 5:35 AM, Jan Hubicka wrote:
> Hi,
> this patch implements infrastructure to summarize function body size&time in a
> way that is sensitive on function context. At the moment context means
>
> 1) if function is inline or offline
> 2) if some of parameters are known compil
On 05/26/2011 04:03 PM, Dodji Seketeli wrote:
That is what I first did and it worked for this case. But then I wasn't
sure if there could be cases where a function DIE would have the
DW_AT_abstract_origin set, but won't have any actual code? For instance
if the function has DECL_EXTERNAL set. T
On 05/26/2011 08:50 PM, Nathan Froyd wrote:
Sigh, I am an idiot. It appears that we always have something pushed by
the time add_stmt is called. (I ran into problems implementing the
above approach, as I wound up with [ NULL_TREE, ] and that gave
pop_stmt heartburn.) I can't recall why I adde
struct A { static auto i = 42; };
is ill-formed because i is non-const, but we weren't noticing that
because we were checking it before replacing the auto. Fixed by moving
the check into cp_finish_decl.
It also seems we were incorrectly setting DECL_INITIALIZED_IN_CLASS for
some template st
And as a prerequisite for that testcase, I needed to implement DR 1004,
dropping the pedwarn about using an injected class name as a template
template parameter.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0407c6ff58d0e7033de64040ce66d60a85b709e5
Author: Jason Merrill
Date: Thu May
The C++0x draft has allowed "friend T;" to make a template type
parameter a friend since 2005; we've been getting a few bug reports
about not having implemented it yet, so here it is.
I notice that friend template template parameters also seem to work now,
with the syntax
template friend
On 05/26/2011 02:30 PM, Paolo Carlini wrote:
We want to do that only when processing a template, because otherwise we
get a duplicate diagnostic, see, eg, auto9.C
Hmm, where's the error coming from in the non-template case? From
cp_build_c_cast? In that case always giving the error in
build
On Thu, May 26, 2011 at 12:04:43PM +, Bernd Schmidt wrote:
> It occurred to me to do another test, building libgcc with and without
> the patch and comparing the binaries. That showed a problem - if there
> are multiple version files, their order matters. In all cases where
> $$(libgcc_objdir)/
On 05/26/2011 10:24 PM, Lawrence Crowl wrote:
> Index: gcc/cp/cp-objcp-common.c
> ===
> --- gcc/cp/cp-objcp-common.c (revision 174301)
> +++ gcc/cp/cp-objcp-common.c (working copy)
> @@ -99,6 +99,8 @@ cp_tree_size (enum tree_code cod
Oranize the PPH tree switch into tcc_* chunks, in each of four sections:
needs more work, already handled, unimplemented, and unrecognized.
Implement several C++ tree nodes. These nodes do not get any more tests
to pass, but they do move the failures deeper into the compilation.
Index: gcc/cp/Ch
On Thu, May 26, 2011 at 09:39:30AM -0400, Jason Merrill wrote:
> On 05/25/2011 10:21 PM, Nathan Froyd wrote:
> >An alternative solution would be to initialize cur_stmt_list somewhere with
> >an
> >actual 1-element VEC;
>
> Or just push NULL onto the stack and let append_to_statement_list_1
> allo
Thanks for this and sorry about the length of time in reviewing this .
On 10/05/11 07:49, Nathan Sidwell wrote:
This patch implements TLS descriptor support in GCC. TLS descriptors are
described at
http://www.codesourcery.com/publications/RFC-TLSDESC-ARM.txt and blessed
by ARM, who have reserved
On Thu, May 26, 2011 at 4:47 PM, Jing Yu wrote:
> I have tested the following patch to skip building target libiberty
> for arm*-*-linux-androideabi. It works as intended when building
> Android arm-linux-androideabi toolchain.
>
> Doug, do we want to skip building libiberty for non arm android
>
I have tested the following patch to skip building target libiberty
for arm*-*-linux-androideabi. It works as intended when building
Android arm-linux-androideabi toolchain.
Doug, do we want to skip building libiberty for non arm android
toolchain, say *-linux-android*?
Joseph, do you think if si
On Thu, 26 May 2011, Vladimir Makarov wrote:
> On 05/26/2011 04:47 AM, Hans-Peter Nilsson wrote:
> > On Wed, 25 May 2011, Vladimir Makarov wrote:
> > It sounds like you're saying that "the narrowest register
> > classes must be formed of registers for which there are trivial
> > instructions to mov
On 05/25/2011 05:15 AM, Jan Hubicka wrote:
> Am Wed 25 May 2011 11:04:06 AM CEST schrieb Richard Guenther
> :
>
>> On Wed, May 25, 2011 at 10:38 AM, Rainer Orth
>> wrote:
>>> Janis Johnson writes:
>>>
Archived test results for 4.7.0 for most processors with C++ results have:
XPA
On May 26, 2011, at 8:55 AM, Richard Guenther wrote:
> The red on the transition should cause the human that did that transition to
> do that inspection.
[ thinking about this some more ] Agreed. So, that means I should not just
approve the XPASS -> PASS changes and that people that cause them
The latest version that only exports 2 functions from passes.c.
David
On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li wrote:
> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
> wrote:
>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>> wrote:
>>> On Wed, 25 May 2011, Xinliang David Li
On 05/26/2011 02:54 PM, Joseph S. Myers wrote:
> On Thu, 26 May 2011, Janis Johnson wrote:
>
>> On 05/26/2011 01:23 PM, Bernd Schmidt wrote:
>>> On 05/26/2011 08:20 PM, Janis Johnson wrote:
Changes went into ARM support recently to add an informative note after an
error about an invalid
The problem here is that vec.c accesses VEC__base via a
vec_prefix but VEC__base's first field is not a vec_prefix.
This patch fixes the problem by changing how VEC_*_base is done by
using vec_prefix as the real base.
OK? Bootstrapped and tested on x86_64 without any regressions.
Thanks,
Andrew P
On Thu, 26 May 2011, Janis Johnson wrote:
> On 05/26/2011 01:23 PM, Bernd Schmidt wrote:
> > On 05/26/2011 08:20 PM, Janis Johnson wrote:
> >> Changes went into ARM support recently to add an informative note after an
> >> error about an invalid argument to -march=. This patch looks for that
>
On Thu, May 26, 2011 at 12:47 PM, Rainer Orth
wrote:
>>> We could certainly duplicate (some of) the logic that %P already uses,
>>> but I though it easier to just introduce a straightforward variant (%p)
>>> instead. It's not pretty, but it worked.
>>
>> OK then... can you propose a new patch, p
Hi,
On Thu, May 26, 2011 at 03:43:45PM +0200, Michael Matz wrote:
> Index: tree-sra.c
> ===
> --- tree-sra.c.orig 2011-05-26 14:15:01.0 +0200
> +++ tree-sra.c2011-05-26 14:15:41.0 +0200
> @@ -1041,6 +1041,11
On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
wrote:
> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
> wrote:
>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>
>>> Ping. The link to the message:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>
>> I don't consider this a
On 05/26/2011 04:47 AM, Hans-Peter Nilsson wrote:
On Wed, 25 May 2011, Vladimir Makarov wrote:
On 11-05-25 6:58 PM, Hans-Peter Nilsson wrote:
On Wed, 25 May 2011, Vladimir Makarov wrote:
This patch solves http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 for
CRIS.
The problem was in that the
On 05/26/2011 01:23 PM, Bernd Schmidt wrote:
> On 05/26/2011 08:20 PM, Janis Johnson wrote:
>> Changes went into ARM support recently to add an informative note after an
>> error about an invalid argument to -march=. This patch looks for that
>> message on ARM targets and allows the test to once
On 05/26/2011 08:20 PM, Janis Johnson wrote:
> Changes went into ARM support recently to add an informative note after an
> error about an invalid argument to -march=. This patch looks for that
> message on ARM targets and allows the test to once again pass.
>
> OK for trunk?
mtune.c does the
Changes went into ARM support recently to add an informative note after an
error about an invalid argument to -march=. This patch looks for that message
on ARM targets and allows the test to once again pass.
OK for trunk?
Index: gcc.dg/march.c
===
Jason Merrill a écrit:
> Why not just call add_linkage_name after add_abstract_origin_attribute?
That is what I first did and it worked for this case. But then I wasn't
sure if there could be cases where a function DIE would have the
DW_AT_abstract_origin set, but won't have any actual code? Fo
On Thu, 26 May 2011 13:48:13 -0400
Paul Koning wrote:
> Relax? Weird. "Pause" is just as weird. It might be an ia32 instruction,
> so as an ia32 builtin it is a reasonable name But if you want a generic
> builtin, you need a name that actually has some plausible connection with
> what it d
> In fact, I haven't tried to make big changes in how mflat option was
> implemented. From my point of view, the goal was to facilitate mflat
> option reintroduction first, and then improve it after. I hope you
> understand. I know there's some place to improve, maybe you have start
> to do it ?
Y
Patch adds libitm.texi with some documentation, including differences
between our currently targeted ABI and Intel's current ABI
specification.
OK for branch?
Torvald
commit ce12f0535a9eebe02a08b6cb5ef9814132f962f8
Author: Torvald Riegel
Date: Thu May 26 21:04:29 2011 +0200
Add documentat
Bernd Schmidt writes:
> On 05/25/2011 08:33 PM, Richard Sandiford wrote:
>> +subpos2_ptr = &pos->xvecexp0s;
>> for (j = 0; j < XVECLEN (pattern, i); j++)
>>{
>> +subpos2 = next_position (subpos2_ptr, pos, POS_XVECEXP0, j);
>> sub = add_to_seque
On Thu, May 26, 2011 at 6:50 AM, Richard Guenther wrote:
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> Richard.
>
> 2011-05-26 Richard Guenther
>
> * fold-const.c (fold_unary_loc): Remove bogus code.
>
This caused:
http://gcc.gnu.org/bugzilla/show_bug.c
Dear Eric,
In fact, I haven't tried to make big changes in how mflat option was
implemented. From my point of view, the goal was to facilitate mflat
option reintroduction first, and then improve it after. I hope you
understand. I know there's some place to improve, maybe you have start
to do it ?
On 05/26/2011 08:30 PM, Paolo Carlini wrote:
...also, not returning error_mark_node unconditionally, means a better
diagnostic, without redundant "array bound is not an integer constant
before...".
Just noticed that outside a template, we do indeed emit the additional
"array bound is not an int
What padding? bitregion_end-bitregion_start+1 will be 32, but in
Poop, I misread your example.
get_best_mode I see
+ maxbits = bitregion_end - bitpos + 1;
which is 28. No?
Yes, but if you look at the next few lines you'll see:
/* Find the narrowest integer mode that contains the bit
Move TEMPLATE_DECL case next to other DECLs in pph_stream_read_tree
and pph_stream_write_tree. Move pph_output_chain_filtered to just
before its use.
Index: gcc/cp/ChangeLog.pph
2011-05-26 Lawrence Crowl
* pph-streamer-in.c (pph_stream_read_tree): Move TEMPLATE_DECL case
nex
Hi,
I have just regtested on x86_64-linux the below patchlet for a simple
accepts-invalid, exploiting type_uses_auto, as suggested by Jason.
We want to do that only when processing a template, because otherwise we
get a duplicate diagnostic, see, eg, auto9.C; also, not returning
error_mark_n
The problem in this PR was that we had a cxx_binding embedded in another
object and then put a pointer to the cxx_binding in another gc-able
object. So when GC ran we tried to mark the cxx_binding and crash,
because it wasn't allocated separately.
Conveniently, the fix to allocate it separate
> However, I forgot the [*] (or [3,*] or ...). Fortunately, you
> have spotted the sematically relevant typo!
>
;-)
Paul
OK for 4.7.
Jason
On 05/26/2011 01:39 PM, Aldy Hernandez wrote:
On 05/26/11 12:24, Jason Merrill wrote:
struct A
{
int i: 4;
int j: 28;
};
we won't use SImode to access A::j because we're setting maxbits to 28.
No, maxbits is actually 32, because we include padding. So it's correct
in this case.
What pad
> Relax? Weird. "Pause" is just as weird. It might be an ia32 instruction,
> so as an ia32 builtin it is a reasonable name But if you want a generic
> builtin, you need a name that actually has some plausible connection with
> what it does, and neither "pause" nor "relax" do that.
It's a sh
On Thu, 26 May 2011, William J. Schmidt wrote:
> + /* Optimize pow(x,1./3.) = cbrt(x). This is always safe. */
No, it's not always safe. 1./3. isn't exactly representable; if x is
negative (and finite), the correct value of the LHS is a NaN (with the
"invalid" exception raised) because the
On Thu, 2011-05-26 at 11:22 +0200, Richard Guenther wrote:
> There are several extra pre-conditions in the original code in
> builtins.c as well as commens for reasonings (yes, there seem
> to be duplicates of several of the transforms there ...). Please
> try to preserve them. I noticed esp
On May 26, 2011, at 1:37 PM, Andi Kleen wrote:
> On Thu, May 26, 2011 at 06:46:39PM +0200, Jakub Jelinek wrote:
>> On Thu, May 26, 2011 at 09:10:32AM -0700, Andi Kleen wrote:
>>> Richard Guenther writes:
>>> As for why having a builtin: one reason would be portability.
>>
>> You mean portabilit
> "Jan" == Jan Hubicka writes:
Some typos...
Jan> + /* Pack VAL into BP, be more effetive when VAL is small.
Jan> +Implementation is sily, we may want to do better later. */
"effective" and "silly".
Jan> + /* Pack VAL into BP, be more effetive when VAL is small.
Jan> +Implementati
On Thu, Mar 10, 2011 at 11:23:26PM -0500, Nathan Froyd wrote:
> Now that we've encapsulated all uses of BLOCK_CHAINON properly, we can
> make BLOCKs inherit from tree_base and redirect BLOCK_CHAINON to use a
> tree_block-private field instead of tree_common's chain. Doing so saves
> the never-use
On 05/26/11 12:24, Jason Merrill wrote:
I'm afraid I think this is still wrong; the computation of maxbits in
various places assumes that the bitfield is at the start of the unit
we're going to access, so given
struct A
{
int i: 4;
int j: 28;
};
we won't use SImode to access A::j because we're
On Wed, 2011-05-25 at 21:24 -0400, Nathan Froyd wrote:
> On Wed, May 25, 2011 at 03:22:07PM -0400, Nathan Froyd wrote:
> > The patch just requires some shuffling of logic to catch issues now;
> > below is a version that works for me on the trunk.
> >
> > This new checking does require modifying g+
On Thu, May 26, 2011 at 06:46:39PM +0200, Jakub Jelinek wrote:
> On Thu, May 26, 2011 at 09:10:32AM -0700, Andi Kleen wrote:
> > Richard Guenther writes:
> > As for why having a builtin: one reason would be portability.
>
> You mean portability to other compilers (I think reasonable amount
> of t
Hi,
Since we don't have movmisaligntf pattern, we need to handle misaligned
load/store in *movtf_internal, similar to *movti_internal_*. OK for
trunk?
Thanks.
H.J.
---
gcc/
2011-05-26 H.J. Lu
PR target/49168
* config/i386/i386.md (*movtf_internal): Handle misaligned
I'm afraid I think this is still wrong; the computation of maxbits in
various places assumes that the bitfield is at the start of the unit
we're going to access, so given
struct A
{
int i: 4;
int j: 28;
};
we won't use SImode to access A::j because we're setting maxbits to 28.
Jason
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/25/11 15:27, Vladimir Makarov wrote:
> The following patch solves problem
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 for SPARC. SPARC FPCC
> registers were excluded from pressure classes because the movement
> between them is costly. T
This patch allows padding to be specified per-target for libcalls. This
hasn't been traditionally important, because libcalls haven't accepted
quantities which might need padding, but that's no longer true with the
new(-ish) fixed-point support helper functions.
Tested (alongside other fixed-point
On Thu, 26 May 2011 09:12:06 -0700
Andi Kleen wrote:
> Basile Starynkevitch writes:
> >
> > Perhaps the doc might explain why is it necessary to have a builtin for
> > two independent roles: first, the full compiler memory barrier (which
> > probably means to spill all the registers on the stack
On Fri, 13 May 2011 14:58:08 +0100
Julian Brown wrote:
> This makes makes the requirement for "long long" fixed-point types
> optional in the testsuite (fixed-point.exp tests), since they are
> unsupported by the ARM backend.
>
> Tested alongside other patches in the series. OK to apply?
This p
On Thu, May 26, 2011 at 09:10:32AM -0700, Andi Kleen wrote:
> Richard Guenther writes:
> As for why having a builtin: one reason would be portability.
You mean portability to other compilers (I think reasonable amount
of them support gcc-ish inline asm), or to other architectures?
__builtin_ia32_
On Fri, 13 May 2011 17:31:18 +0100
Julian Brown wrote:
> On Fri, 13 May 2011 14:54:47 + (UTC)
> "Joseph S. Myers" wrote:
>
> > On Fri, 13 May 2011, Julian Brown wrote:
> >
> > > although Joseph's comments have (hopefully) all been addressed.
> > > One must now configure with "--enable-fixe
On Thu, May 26, 2011 at 3:43 PM, Michael Matz wrote:
> on IRC we discussed about this, here's the RFC patch. It bootstraps and
> causes some minor regressions most probably due to some missing sprinkled
> checks for the special clobber insns and sometimes due to having to adjust
> some regexps.
Basile Starynkevitch writes:
>
> Perhaps the doc might explain why is it necessary to have a builtin for
> two independent roles: first, the full compiler memory barrier (which
> probably means to spill all the registers on the stack - definitely a
> task for a compiler); second, to "pause" the pr
Richard Guenther writes:
>
> To make it a compiler memory barrier you have to "expand" the
> builtin already in the frontend and present the middle-end with
> __asm__ ("" : : : "memory"). That will serve as a compiler
Those are the intended semantics (at least those I asked
for :-). For all
On Thu, May 26, 2011 at 5:16 PM, Mike Stump wrote:
> On May 26, 2011, at 2:25 AM, Richard Guenther wrote:
>> The XPASS is suprious - that's the whole point of XPASSes. It should
>> FAIL (well, XFAIL). A patch making it PASS is bogus.
>
> There are deeper reasons for my position. Take a look at:
On Mon, 9 May 2011 18:01:12 +0100
Julian Brown wrote:
> How does this look now? (Re-testing in progress.)
The previously-posted version contained a bug in the "extv" expander,
which became apparent only when testing together with my fixed-point
support patch. This is a corrected version.
Re-tes
Hi,
this is updated patch. For whatever reason we now end up with longer .o file
for tramp3d than with my prevoius attempt (by 9KB). We need at average 15 bytes
for location, well, the encoding of small ints might be better with uleb style,
perhaps with smaller chunk (like 4 bits per chunk as oppo
On 05/25/2011 02:15 PM, Nathan Froyd wrote:
The patch below implements just such an idea. The only twist is that
the `explain' parameter is actually a `location_t *' so that when we
provide explanations that aren't produced via tf_warning_or_error
blocks, the explanations are attached to the tem
Hi,
On Thu, 26 May 2011, Richard Guenther wrote:
> > Hmm, I plan to optimize string streaming (since we always stream one
> > uleb to set it is non-NULL that can be easilly handled by assigining
> > NULL string index 0). How precisely you however suggest to bitpack
> > line/column and string
> Yes please. I've been arguing for that for some time.
Since you feel so strongly about it and nobody objects, go ahead.
> http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html
> http://gcc.gnu.org/ml/gcc/2010-03/msg2.html
> http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html
> http://gcc.gnu.org/ml
Why not just call add_linkage_name after add_abstract_origin_attribute?
Jason
On May 26, 2011, at 2:25 AM, Richard Guenther wrote:
> The XPASS is suprious - that's the whole point of XPASSes. It should
> FAIL (well, XFAIL). A patch making it PASS is bogus.
There are deeper reasons for my position. Take a look at:
http://google1.osuosl.org:8011/waterfall
the idea is t
On Thu, May 26, 2011 at 03:11, Alexey Kravets wrote:
> Here is the patch for this issue.
> It is caused by the bug in opencl_get_perfect_nested_loop_depth.
> This functions ignores -fgraphite-opencl-ignore-dep flag while
> opencl_transform_stmt_list considers this flag.
>
> This patch adds a new
I merged one if too eagerly, resulting in not fixing up the
cache for merged types. Oops.
LTO bootstrapped on x86_64-unknown-linux-gnu, testing and SPEC2k6
build in progress.
Richard.
2011-05-26 Richard Guenther
lto/
* lto.c (uniquify_nodes): Fix bug in one of the previous
Hi,
On Thu, 26 May 2011, Andrew Haley wrote:
> >>> +Generates the @code{pause} machine instruction.
> >>
> >> But that's missing the fact that it generates a compiler memory
> >> barrier, which is important. And if you think it's not a compiler
> >> memory barrier, please explain
> >>
> >> a.
Hello,
The constructors (resp. destructors) of a given class K are cloned.
For each constructor (resp. destructor) There is thus an abstract
version of the function and (at least) a concrete version that
actually contains the code of the abstract version.
The debug info generated for a constructo
On 05/26/2011 03:29 PM, Richard Guenther wrote:
> On Thu, May 26, 2011 at 3:53 PM, Andrew Haley wrote:
>> On 05/26/2011 02:51 PM, Richard Guenther wrote:
>>> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley wrote:
On 05/26/2011 10:34 AM, Richard Guenther wrote:
>> Index: doc/extend.tex
On Thu, May 26, 2011 at 4:34 PM, Jakub Jelinek wrote:
> On Thu, May 26, 2011 at 04:29:50PM +0200, Richard Guenther wrote:
>> To make it a compiler memory barrier you have to "expand" the
>> builtin already in the frontend and present the middle-end with
>> __asm__ ("" : : : "memory"). That wi
On Thu, May 26, 2011 at 04:29:50PM +0200, Richard Guenther wrote:
> To make it a compiler memory barrier you have to "expand" the
> builtin already in the frontend and present the middle-end with
> __asm__ ("" : : : "memory"). That will serve as a compiler
> memory barrier also covering local
In preparation to move all frontends common tree node building to
the middle-end this makes the Java frontend actually use the
standard routines. It's still severely broken in overriding
things with stuff that does not match the targets C ABI, but well,
Java ...
Bootstrapped and tested on x86_64
On Thu, May 26, 2011 at 3:53 PM, Andrew Haley wrote:
> On 05/26/2011 02:51 PM, Richard Guenther wrote:
>> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley wrote:
>>> On 05/26/2011 10:34 AM, Richard Guenther wrote:
>>>
> Index: doc/extend.texi
> ===
On Thu, May 26, 2011 at 4:00 PM, Jakub Jelinek wrote:
> On Thu, May 26, 2011 at 03:43:45PM +0200, Michael Matz wrote:
>> --- tree-stdarg.c.orig 2011-05-26 14:15:01.0 +0200
>> +++ tree-stdarg.c 2011-05-26 14:15:41.0 +0200
>> @@ -872,8 +872,12 @@ execute_optimize_stdarg (v
Dear Paul,
thanks for the review. Regarding:
Paul Thomas wrote:
> Maybe I am being stupid but what is the call, in the
> testcase, to subroutine test for?
Well, it is supposed to test coarray decls in functions,
contained functions, and in not-referenced functions.
However, I forgot the [*] (
On Thu, May 26, 2011 at 03:43:45PM +0200, Michael Matz wrote:
> --- tree-stdarg.c.orig2011-05-26 14:15:01.0 +0200
> +++ tree-stdarg.c 2011-05-26 14:15:41.0 +0200
> @@ -872,8 +872,12 @@ execute_optimize_stdarg (void)
> if (get_gimple_rhs_class (gimple_assi
On Thu, 26 May 2011, Andrew Stubbs wrote:
> On 25/05/11 14:47, Joseph S. Myers wrote:
> > The shift must be by a positive constant amount, strictly less than the
> > precision (GET_MODE_PRECISION) of the mode (of the value being shifted).
> > If that applies, the relevant number of bits is the pre
On 05/26/2011 02:51 PM, Richard Guenther wrote:
> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley wrote:
>> On 05/26/2011 10:34 AM, Richard Guenther wrote:
>>
Index: doc/extend.texi
===
--- doc/extend.texi (revision 1
On Thu, May 26, 2011 at 3:30 PM, Andrew Haley wrote:
> On 05/26/2011 10:34 AM, Richard Guenther wrote:
>
>>> Index: doc/extend.texi
>>> ===
>>> --- doc/extend.texi (revision 174216)
>>> +++ doc/extend.texi (working copy)
>>> @
On 05/26/2011 09:46 AM, Nathan Froyd wrote:
On 05/26/2011 09:39 AM, Jason Merrill wrote:
On 05/25/2011 10:21 PM, Nathan Froyd wrote:
An alternative solution would be to initialize cur_stmt_list somewhere with an
actual 1-element VEC;
Or just push NULL onto the stack and let append_to_statemen
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-05-26 Richard Guenther
* fold-const.c (fold_unary_loc): Remove bogus code.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revisi
On 05/26/2011 09:39 AM, Jason Merrill wrote:
> On 05/25/2011 10:21 PM, Nathan Froyd wrote:
>> An alternative solution would be to initialize cur_stmt_list somewhere with
>> an
>> actual 1-element VEC;
>
> Or just push NULL onto the stack and let append_to_statement_list_1 allocate
> the VEC?
Did
Hi,
on IRC we discussed about this, here's the RFC patch. It bootstraps and
causes some minor regressions most probably due to some missing sprinkled
checks for the special clobber insns and sometimes due to having to adjust
some regexps.
Anyway, stack slot sharing is currently using the heur
On 05/26/2011 09:41 AM, Jakub Jelinek wrote:
That is how it ends up being optimized later on, I just think
given how long the bug has been in this is so rare that
we don't need to try to optimize it already at the gimplifier level.
Makes sense.
Jason
On Thu, May 26, 2011 at 09:26:58AM -0400, Jason Merrill wrote:
> On 05/26/2011 06:32 AM, Jakub Jelinek wrote:
> >gimplify_cond_expr knows how to gimplify this, but shortcut_cond_r
> >tried to optimize
> >if (a ? b : throw 1) goto yes; else goto no;
> >into
> >if (a)
> > if (b) goto yes; else goto
On 05/25/2011 10:21 PM, Nathan Froyd wrote:
An alternative solution would be to initialize cur_stmt_list somewhere with an
actual 1-element VEC;
Or just push NULL onto the stack and let append_to_statement_list_1
allocate the VEC?
the check in add_stmt would then be unnecessary, as we'd
alw
On 25/05/11 14:47, Joseph S. Myers wrote:
The shift must be by a positive constant amount, strictly less than the
precision (GET_MODE_PRECISION) of the mode (of the value being shifted).
If that applies, the relevant number of bits is the precision of the mode
minus the number of bits of the shif
On 25.05.2011 19:31, Bernd Schmidt wrote:
On 05/25/2011 03:29 PM, Andrey Belevantsev wrote:
I think the hook is a better idea than the attribute because nobody will
care to mark all offending insns with an attribute.
I don't know. IIRC when I looked at sh or whatever the broken port was,
it wa
On 05/25/2011 01:45 PM, Hans-Peter Nilsson wrote:
> On Wed, 25 May 2011, Bernd Schmidt wrote:
>
>> I'm not sure where you're looking for added documentation for this
>> patch.
>
> I guess no surprise that'd be md.texi node Defining Attributes,
That covers define_attr, not set_attr, so it seems i
On 05/26/2011 10:34 AM, Richard Guenther wrote:
>> Index: doc/extend.texi
>> ===
>> --- doc/extend.texi (revision 174216)
>> +++ doc/extend.texi (working copy)
>> @@ -8699,7 +8699,8 @@ The following built-in function is alway
1 - 100 of 159 matches
Mail list logo
