This patch to the Go frontend uses the backend interface for interface
types. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 37dae2a9c21b go/gogo-tree.cc
--- a/go/gogo-tree.cc Wed May 04 08:38:47 2011 -0700
+++ b/go/gogo-tree.cc Wed May 04 22:18
OK.
Jason
On Thu, 5 May 2011, Richard Guenther wrote:
> On Wed, 4 May 2011, Richard Guenther wrote:
> > On Wed, 4 May 2011, Eric Botcazou wrote:
> > Hm. I guess people will scream if something breaks (I can't imagine
> > what though).
AAAaaarghh! Building cris-elf is now broken.
> I have applied the foll
My fix for PR44266 using the libcall machinery to ensure we had a
proper stack frame allocated for __tls_get_addr calls sloppily used r3
as the arg to the dummy libcall. This made the call seem to depend on
whatever was in r3 previously, at least until we get to the first
split pass and the real a
commit bf6ab23aad749d927108ace21ee01a94af31a38b
Author: Cary Coutant
Date: Mon Apr 25 13:54:19 2011 -0700
Check for classes that contain defining declarations of subprograms, and
do not move such classes into a comdat type unit.
I've updated the patch to assert that a type definiti
How about type_dependent_expression_p_push instead?
Jason
On Tue, May 3, 2011 at 5:27 PM, Michael Meissner
wrote:
> When I added VSX support to the powerpc, I overlooked passing and return
> V2DImode arguments, since the only machine operation that supports V2DI is
> vector floating point conversion. Consequentally, V2DI types were passed and
> returned
On Thu, May 5, 2011 at 3:34 PM, Joseph S. Myers wrote:
> On Thu, 5 May 2011, Michael Eager wrote:
>
>> David Edelsohn wrote:
>> > On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers
>> > wrote:
>> >
>> > > Two options, -mcmodel= and -mfpu=, had cases that fell through to the
>> > > next case without
OK.
Jason
Hello,
This is a leftover of the fix for PR c++/48574. When
fold_non_dependent_expr sees the lvalue reference 'b' in the example
of the patch below (because in finish_call_expr,
make_args_non_dependent on 'b' calls build_non_dependent_expr which
calls null_ptr_cst_p which calls fold_non_dependent
On Thu, May 05, 2011 at 11:29:13AM -0400, David Edelsohn wrote:
> Alan, is mcmodel suppose to set m64?
No, that was an accident.
--
Alan Modra
Australia Development Lab, IBM
Jason Merrill writes:
> On 05/05/2011 03:52 PM, Dodji Seketeli wrote:
>> + if (is_overloaded_fn (fn))
>> +fn = get_first_fn (fn);
>> + else if (BASELINK_P (fn))
>
> is_overloaded_fn should be true for a BASELINK.
Correct. I should have seen that. I have bootstrapped the patch below
then.
On 5/5/11, dnovi...@google.com wrote:
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h
> File gcc/cp/pph-streamer.h (right):
>
> http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode152
> gcc/cp/pph-streamer.h:152: for (i = 0; i < c; ++i)
> +#if 0
> +static
On Thu, May 05, 2011 at 03:08:43PM -0400, Michael Meissner wrote:
> Yes, it was an error on my part. Sorry. I will fix the GCC 4.6 branch. I
> will hold off fixing the on trunk, on the assumption this patch will go in. I
> can fix it if desired.
I committed the following patch on the GCC 4.6 b
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):
http://codereview.appspot.com/4486042/diff/1/gcc/cp/pph-streamer.h#newcode152
gcc/cp/pph-streamer.h:152: for (i = 0; i < c; ++i)
+#if 0
+static inline void
+pph_output_tree_array (pph_stream *s
On 05/05/2011 05:33 PM, ccout...@google.com wrote:
I couldn't convince myself that a subprogram definition inside a type
declaration would never happen, so I took the defensive approach. If
you're confident that it can't (or shouldn't) ever happen, then what if
I leave the predicate contains_subp
It's a good check to add, but if it returns true we should abort
rather than
just returning 0.
I couldn't convince myself that a subprogram definition inside a type
declaration would never happen, so I took the defensive approach. If
you're confident that it can't (or shouldn't) ever happen, t
Save and restored globals keyed_classes and unemitted_tinfo_decls.
Save and restore member TYPE_BINFO.
Index: gcc/cp/ChangeLog.pph
2011-05-05 Lawrence Crowl
* pph.c (pph_write_file_contents): Save keyed_classes and
unemitted_tinfo_decls.
(pph_read_file_contents): Restor
Hi,
I just merged the changes from trunk into the graphite branch:
2010-05-05 Sebastian Pop
* Merge from mainline (170411:173446).
Joseph S. Myers wrote:
On Thu, 5 May 2011, Michael Eager wrote:
David Edelsohn wrote:
On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers
wrote:
Two options, -mcmodel= and -mfpu=, had cases that fell through to the
next case without comments to indicate if this was intended. I added
comments t
Hello!
> In this case, GCC wasn't following the ABI. My patch will have GCC follow the
> ABI. The XL compiler also follows the ABI. So we have to decide whether to
> keep the current calling sequence which violates the ABI, or change the
> compiler to follow the ABI, and break backwards compati
On 05/05/2011 03:52 PM, Dodji Seketeli wrote:
+ if (is_overloaded_fn (fn))
+fn = get_first_fn (fn);
+ else if (BASELINK_P (fn))
is_overloaded_fn should be true for a BASELINK.
Jason
Build and regtested on x86-64-linux
OK for the trunk?
I forgot to include a run-time test case. Find one attached.
Tobias
! { dg-do run }
! { dg-additional-sources bind_c_usage_24_c.c }
!
! PR fortran/48858
! PR fortran/48820
!
! TR 29113: BIND(C) with OPTIONAL
!
module m
use iso_c_binding
While working on something else I noticed that REFERENCE_REF_P was being
clobbered by stabilize_expr, so this patch changes it to just use the
type rather than a lang_flag.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f24566a2f2594c7d4c7d7d3e26a4341d87deaec6
Author: Jason Merrill
Date
Jason Merrill writes:
> I think using get_first_fn could make non_static_member_function_p a
> lot shorter.
Like this?
Tested like the previous patch.
gcc/cp
PR c++/48838
* cp-tree.h (non_static_member_function_p): Declare new function.
* tree.c (non_static_member_func
Hello,
Compilation of code containing pragma Assert fails if restriction
No_Implementation_Pragmas is used, even with -gnat2005 or -gnat2012
flags:
% cat test.adb
pragma Restrictions(No_Implementation_Pragmas);
procedure test(I : Integer) is
begin
pragma Assert(I /= 1);
null;
end;
% gcc -c t
On Thu, May 5, 2011 at 01:36, David Li wrote:
> This patch improves cross module option mismatch handling in LIPO mode --
> will be commited to google/main.
>
> 1) Remove duplicates in the option list before comparison;
> 2) Force module incompatiblity when two modules disagree in -fexceptions
>
On Thu, 5 May 2011, Michael Eager wrote:
> David Edelsohn wrote:
> > On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers
> > wrote:
> >
> > > Two options, -mcmodel= and -mfpu=, had cases that fell through to the
> > > next case without comments to indicate if this was intended. I added
> > > commen
On Wed, May 04, 2011 at 11:33:43AM +0200, Richard Guenther wrote:
> On Wed, May 4, 2011 at 4:51 AM, David Edelsohn wrote:
> > What does this do to the ABI? Haven't we now broken the ABI and
> > broken backwards compatibility?
>
> It at least looks like so. You need to add appropriate changes.ht
On Tue, May 03, 2011 at 10:51:51PM -0400, David Edelsohn wrote:
> What does this do to the ABI? Haven't we now broken the ABI and
> broken backwards compatibility?
In this case, GCC wasn't following the ABI. My patch will have GCC follow the
ABI. The XL compiler also follows the ABI. So we hav
This patch continues work on avoiding global state in
rs6000_handle_option by cleaning up the handling of -mabi= options.
The part using global state, a test for TARGET_SPE_ABI, is moved to
rs6000_option_override_internal (so now testing the state after all
options are applied). The -mabi= option
On Thu, May 5, 2011 at 11:47 AM, Diego Novillo wrote:
>> OK for google/main?
Is there a reason why this cannot be an option that someone passes on
the command line of GCC instead of a configure option? Also can you
show an example of why this message would be changed?
Thanks,
Andrew Pinski
Changes:
- Remove (not working) critical functions; a normal coarray of LOCK type
should be used instead. (Stub left in until it is removed the the front
end.)
- Added prototypes and stub implementations for
registering/deregistering coarray (currently unused).
- Small bug fixes.
OK for th
On Thu, May 05, 2011 at 10:08:24AM -0700, Michael Eager wrote:
> David Edelsohn wrote:
> >On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers
> >wrote:
> >
> >>Two options, -mcmodel= and -mfpu=, had cases that fell through to the
> >>next case without comments to indicate if this was intended. I add
On Thu, May 5, 2011 at 14:27, Chris Demetriou wrote:
> Diego,
>
> I know this is a truly horrible and broken way to do this, but alternatives
> (e.g., NLS) don't really work for us.
>
> bootstrapped without new configuration (x86-64 ubuntu lucid, didn't bother
> to run tests), bootstrapped with op
> Date: Thu, 5 May 2011 19:36:47 +0300
> From: Janne Blomqvist
> On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson
> wrote:
> > This time, it happened in 173155:173168.
> >
> > Usually, there's also a brief question whether all changes were
> > intended, or perhaps that some of the regressing tes
Diego,
I know this is a truly horrible and broken way to do this, but alternatives
(e.g., NLS) don't really work for us.
bootstrapped without new configuration (x86-64 ubuntu lucid, didn't bother
to run tests), bootstrapped with option (x86-64 ubuntu lucid, with full
tests, no regressions). Manu
IIRC there's a compile-time way to test for prototypes at least.
On Thu, May 5, 2011 at 09:32, Richard Guenther
wrote:
> And yes, in "harm" I mostly refer to svn blame annoyances and to
> patch/branch merge conflicts where context that causes the conflict
> only changed in whitespace.
Your tools are limiting the quality of your work.
Are we not the toolmakers
On May 5, 2011, at 9:36 AM, Janne Blomqvist wrote:
> The testsuite uses the process return value to determine
> success, right? But which values exactly constitute success
> vs. failure?
0 is success, and != 0 is failure.
DJ Delorie wrote:
> No, we've always hard-coded what newlib does to avoid the link
> problems. I think we should continue with that for now.
>
> I suspect we need to AC_DEFINE(HAVE_PSIGNAL)
Corinna Vinschen had the same suggestion:
> Sorry about that. I guess that should have been something alo
On Thu, May 5, 2011 at 12:54 AM, Corinna Vinschen wrote:
> On May 5 00:40, Andrew Pinski wrote:
>> On Thu, May 5, 2011 at 12:30 AM, Corinna Vinschen
>> wrote:
>> > Thanks,
>> > Corinna
>> >
>> >
>> > * strsignal.c (psignal): Change second parameter to const char *.
>> > Fix commen
David Edelsohn wrote:
On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers wrote:
Two options, -mcmodel= and -mfpu=, had cases that fell through to the
next case without comments to indicate if this was intended. I added
comments to make the semantics explicit. Given the documentation, it
may wel
On Thu, May 5, 2011 at 2:16 AM, Richard Guenther
wrote:
> On Thu, May 5, 2011 at 12:19 AM, Xinliang David Li wrote:
>>>
>>> I can think of some more-or-less obvious high-level forms, one would
>>> for example simply stick a new DISPATCH tree into gimple_call_fn
>>> (similar to how we can have OBJ
> You don't mean the prototype, do you? IMHO the char * should still be
> changed to const char * to adhere to POSIX.
So far, it's served as a good tool for detecting when libiberty's
configure isn't doing its job :-)
At this point, we should avoid "fixing" it until the newlib/configure
issue i
No, we've always hard-coded what newlib does to avoid the link
problems. I think we should continue with that for now.
I suspect we need to AC_DEFINE(HAVE_PSIGNAL)
On May 5 18:44, Ulrich Weigand wrote:
> DJ Delorie wrote:
> > > I don't know how to avoid this problem in configure, other than by adding
> > > AC_LIBOBJ([psignal]).
> >
> > Right, the correct solution is - libiberty shouldn't provide psignal
> > if newlib does. Making it match newlib is the wro
On May 5 11:29, DJ Delorie wrote:
>
> > I don't know how to avoid this problem in configure, other than by adding
> > AC_LIBOBJ([psignal]).
>
> Right, the correct solution is - libiberty shouldn't provide psignal
> if newlib does. Making it match newlib is the wrong solution.
You don't mean th
DJ Delorie wrote:
> > I don't know how to avoid this problem in configure, other than by adding
> > AC_LIBOBJ([psignal]).
>
> Right, the correct solution is - libiberty shouldn't provide psignal
> if newlib does. Making it match newlib is the wrong solution.
I guess I agree, but the problem is e
On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson
wrote:
> Once or twice a year some regression results from changed I/O
> in libgfortran, such that some existing test-case starts
> calling libgfortran/io/unix.c:raw_truncate, which on
> limited-I/O-bare-iron targets will emit "required ftruncate or
On 05/05/2011 07:09 AM, Jason Merrill wrote:
> No, but the rationale isn't documented. It was added by the patch
> that introduced STATEMENT_LIST,
>
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00879.html
>
> but doesn't appear in the ChangeLog entry. I notice that in that
> patch unsave_r c
On May 4, 2011, at 8:17 PM, Nathan Froyd wrote:
> The last remaining uses of build_function_type in the ObjC/C++ frontends
> comes from this pattern:
> OK to commit?
Ok.
>
This is PR ada/48844, a regression present on the mainline and 4.6 branch.
The compiler aborts on an assignment of an aggregate to another object, if the
nominal subtype of the former is a discriminated record type with a variant
part for which the variants all have the same size and one of the v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I should have included these in the last patch of infrastructure changes.
The main change is create_block_for_threading no longer calls
remove_ctrl_stmt_and_useless_edges and instead its callers are expected
to handle that, when needed. This will al
> I don't know how to avoid this problem in configure, other than by adding
> AC_LIBOBJ([psignal]).
Right, the correct solution is - libiberty shouldn't provide psignal
if newlib does. Making it match newlib is the wrong solution.
On Wed, May 4, 2011 at 7:54 AM, Joseph S. Myers wrote:
> Two options, -mcmodel= and -mfpu=, had cases that fell through to the
> next case without comments to indicate if this was intended. I added
> comments to make the semantics explicit. Given the documentation, it
> may well be intentional
On 05/05/2011 10:56 AM, Jakub Jelinek wrote:
We can't handle Pmode void* like other pointers?
mem_mode == VOIDmode doesn't mean a void* pointer, mem_mode != VOIDmode
means mem_loc_descriptor is called on some MEM's address and gives the
mode of the MEM, while VOIDmode mem_mode means it isn't a
On Thu, 2011-05-05 at 14:00 +0100, Ramana Radhakrishnan wrote:
> > The arm.opt change is OK, but 'Report' should stay; and it should also
> > be added to the -marm case.
>
> Ok with this change ? Rebuilt docs and built a cross with arm-linux-gnueabi ?
>
> 2011-05-05 Ramana Radhakrishnan
>
>
On Thu, May 05, 2011 at 10:25:53AM -0400, Jason Merrill wrote:
> >+ && (mode != Pmode
> >+ || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE
>
> This test seems overly cautious; it seems implausible to have
> DWARF2_ADDR_SIZE smaller than GET_MODE_SIZE (ptr_mode), and having
>
Here the issue was that build_new_1 wants to stabilize any constructor
arguments so that the EH region for deleting the allocated memory can be
as small as possible. But stabilize_expr was being over-eager, making a
copy of a class with trivial constructors, but a non-trivial (and indeed
non-c
+ && (mode != Pmode
+ || GET_MODE_SIZE (ptr_mode) != DWARF2_ADDR_SIZE
This test seems overly cautious; it seems implausible to have
DWARF2_ADDR_SIZE smaller than GET_MODE_SIZE (ptr_mode), and having it be
larger doesn't seem like a problem.
+ || m
Hi!
According to a clarification on OpenMP forums, if(0) which creates
an undeferred task doesn't mean if the implementation chooses to schedule
it right away that it is included task. Included tasks are thus only
the children tasks of some final task.
Fixed thusly:
2011-05-05 Jakub Jelinek
On 05/04/2011 06:57 PM, Eric Botcazou wrote:
But you're unilaterally choosing one special handling (copying) among several
ones (copying, not copying, aborting) just because of one caller, for no good
reason IMO.
It seems pretty straightforward to me that a function named copy_tree_r
should co
On Thu, May 5, 2011 at 2:58 PM, Jack Howarth wrote:
> Currently the bootstrap with --enable-build-with-cxx is broken due to
> compiler errors of the form
> "error: converting 'false' to pointer type 'varpool_node*'
> [-Werror=conversion-null]". The attached
> patch changes the last remaing insta
Tobias,
I know Mike already approved that patch. Just a few nits.
> # Test coarray support.
> #
> # For the compilation tests, all files are compiles with the
^ d
> # option -fcoarray=single and with -fcoarray=lib
Jerry,
> My goal is to completely not use any floating point operations for that
> section of code. We have a concept on how to do it. I am still working
> out tweaks to 48787, then I will turn my attention to this. Feel free to
> quiet that test case any way you wish in the meantime.
ok, I've
>
> OK for trunk?
I have now committed this to trunk for you and will backport this to
release branches at some point in the next few days.
cheers
Ramana
>
> -- Michael
>
> gcc/
>
> 2011-05-02 Michael Hope
>
> PR pch/45979
> * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define fo
On Thu, May 5, 2011 at 8:02 AM, Jack Howarth wrote:
> On Thu, May 05, 2011 at 07:56:20AM -0500, Gabriel Dos Reis wrote:
>> On Thu, May 5, 2011 at 7:55 AM, Jack Howarth
>> wrote:
>> > On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote:
>> >> > Currently the bootstrap with --enable-buil
>I didn't see that patch so just reduce mine down to the change for
> change for gcc/varpool.c. Odd that the gcc/varpool.c issue isn't seen on
> other targets besides darwin apparently.
No problem. Please install the entire patch (with Dmitry's name as second
name) as Dmitry hasn't got commi
On Thu, May 05, 2011 at 07:56:20AM -0500, Gabriel Dos Reis wrote:
> On Thu, May 5, 2011 at 7:55 AM, Jack Howarth wrote:
> > On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote:
> >> > Currently the bootstrap with --enable-build-with-cxx is broken due to
> >> > compiler errors of the form
> The arm.opt change is OK, but 'Report' should stay; and it should also
> be added to the -marm case.
Ok with this change ? Rebuilt docs and built a cross with arm-linux-gnueabi ?
2011-05-05 Ramana Radhakrishnan
PR target/47930
* config/arm/arm.opt (marm): Document it.
(
Currently the bootstrap with --enable-build-with-cxx is broken due to compiler
errors of the form
"error: converting 'false' to pointer type 'varpool_node*'
[-Werror=conversion-null]". The attached
patch changes the last remaing instance of false to NULL and restores the
--enable-build-with-cxx
On Thu, May 5, 2011 at 7:55 AM, Jack Howarth wrote:
> On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote:
>> > Currently the bootstrap with --enable-build-with-cxx is broken due to
>> > compiler errors of the form "error: converting 'false' to pointer type
>> > 'varpool_node*' [-Werror=
On Thu, May 05, 2011 at 02:02:19PM +0200, Eric Botcazou wrote:
> > Currently the bootstrap with --enable-build-with-cxx is broken due to
> > compiler errors of the form "error: converting 'false' to pointer type
> > 'varpool_node*' [-Werror=conversion-null]". The attached patch changes
> > these in
On Thu, 2011-05-05 at 13:08 +0100, Julian Brown wrote:
> On Tue, 03 May 2011 15:49:38 +0100
> Richard Earnshaw wrote:
>
> >
> > On Tue, 2011-05-03 at 13:49 +0100, Julian Brown wrote:
> > > Hi,
> > >
> > > This patch fixes vset_lane intrinsic variants for D-register sized
> > > variables. A typ
On Wed, 4 May 2011, Richard Guenther wrote:
> On Wed, 4 May 2011, Eric Botcazou wrote:
>
> > > I think I did it that way because the old code tried to re-construct
> > > the type of the original amount. I can surely simply use op1 here
> > > if that is preferred.
> >
> > Right, but it used the
Hello!
Add --param min-insn-to-prefetch-ratio=0 to avoid "Not prefetching --
instruction to prefetch ratio (6) too small" aprefetch pass rejection.
2011-05-05 Uros Bizjak
* gcc.target/i386/opt-1.c: Add --param min-insn-to-prefetch -ratio=0
to dg-options.
* gcc.target/i
On Tue, 03 May 2011 15:49:38 +0100
Richard Earnshaw wrote:
>
> On Tue, 2011-05-03 at 13:49 +0100, Julian Brown wrote:
> > Hi,
> >
> > This patch fixes vset_lane intrinsic variants for D-register sized
> > variables. A typo meant that the wrong lane would be set in many
> > circumstances.
> >
>
Hi!
This PR has been fixed without testcase being added,
fixed thusly, regtested on x86_64-linux and i686-linux,
committed to trunk.
2011-05-05 Jakub Jelinek
PR rtl-optimization/48381
* gcc.c-torture/compile/pr48381.c: New test.
--- gcc/testsuite/gcc.c-torture/compile/pr48381
> Currently the bootstrap with --enable-build-with-cxx is broken due to
> compiler errors of the form "error: converting 'false' to pointer type
> 'varpool_node*' [-Werror=conversion-null]". The attached patch changes
> these instances of false to NULL and restores the --enable-build-with-cxx
> boo
Hi!
On the attached enhanced typeddwarf.c testcase there is no location
info for the 3 vars in f4 function with -O2 -m32 -g. The parameter
is unused during expansion except for debug stmts, but DECL_INCOMING_RTL
isn't a hard register or MEM with hard register as address that would be
represented
> Hm, ok. I was more looking at removing the calls from fold-const.c where
> it seems to protect things like folding x <= +Inf to x == x, stuff unlikely
> to appear in type sizes. I can imagine the Ada FE wanting to do
> things with type sizes and variable_size's wrapping looks like merely
> an o
There is indeed more simplification possible (alpha-vms for example
caught my attention while reviewing), but proceeding incrementally
does not hurt.
This patch is okay, thanks.
Paolo
2011/5/4, Joseph S. Myers :
> This patch separates cases disabling newlib and libgloss for various
> target OSe
Currently the bootstrap with --enable-build-with-cxx is broken due to compiler
errors of the form
"error: converting 'false' to pointer type 'varpool_node*'
[-Werror=conversion-null]". The attached
patch changes these instances of false to NULL and restores the
--enable-build-with-cxx bootstrap.
Hello!
No functional change.
2011-05-05 Uros Bizjak
* config/i386/i386.md (*movdf_internal_rex64): Simplify nested "if"
conditions.
(*movdf_internal): Ditto.
(*movdf_internal_nointeger): Ditto.
(*movsf_internal): Ditto.
Tested on x86_64-pc-linux-gnu {,
On Thu, May 5, 2011 at 07:07, Richard Guenther
wrote:
> For LTO we have type-merging for that, and we'd continue to pre-load
> the type merger with the (LTO frontend specific) common tree nodes.
OK. For LTO it may make sense to eventually make this hook a nop, then.
> I suppose you are not doi
On Thu, May 5, 2011 at 1:03 PM, Diego Novillo wrote:
> On Thu, May 5, 2011 at 05:06, Richard Guenther
> wrote:
>
>> I think we should move away from pre-loading the streamer cache, that
>> has caused enough trouble when the common nodes are originating from
>> different Frontends and when compili
On Thu, May 5, 2011 at 05:06, Richard Guenther
wrote:
> I think we should move away from pre-loading the streamer cache, that
> has caused enough trouble when the common nodes are originating from
> different Frontends and when compiling units with different flags which
> happen to change those n
On Thu, May 5, 2011 at 12:07 PM, Eric Botcazou wrote:
>> But where do you expand it without the SAVE_EXPR? The same
>> restrictions apply there. So I suppose you expand it to a function
>> in which case there is the context where the SAVE_EXPR can be
>> expanded exactly once.
>
> You don't have
> But where do you expand it without the SAVE_EXPR? The same
> restrictions apply there. So I suppose you expand it to a function
> in which case there is the context where the SAVE_EXPR can be
> expanded exactly once.
You don't have SAVE_EXPRs so you're precisely controlling what you're doing.
On Thu, May 5, 2011 at 11:25 AM, Jakub Jelinek wrote:
> Hi!
>
> create_tmp_var_raw calls build_type_variant, but doesn't actually use
> it in any way (other than set its TYPE_ATTRIBUTES, that's why
> -Wunused-but-set-variable hasn't reported it.
Ok.
Thanks,
Richard.
> 2011-05-05 Jakub Jelinek
Hello,
this patch fixes the long-standing failure:
FAIL: g++.old-deja/g++.jason/thunk3.C (test for excess errors)
by providing a TARGET_ASM_OUTPUT_MI_THUNK implementation for SPU.
Tested on spu-elf, committed to mainline.
Bye,
Ulrich
ChangeLog:
* config/spu/spu.c (TARGET_ASM_OUTPUT_MI
On Thu, May 5, 2011 at 11:23 AM, Eric Botcazou wrote:
>> Sure, but that's a limitation of out SAVE_EXPR handling (given that it
>> would be ok to expand the SAVE_EXPR multiple times - once per
>> "instantiation context").
>
> You need to expand the initializer exactly once and you need to make sur
On Thu, 2011-05-05 at 14:51 +0800, Guozhi Wei wrote:
> Hi
>
> This is the third part of the fixing for
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855
>
> This patch contains the length computation/refinement for insn patterns
> "*thumb2_movsi_insn", "*thumb2_cbz" and "*thumb2_cbnz".
>
>
On Thu, May 5, 2011 at 1:57 AM, Mike Stump wrote:
> On May 4, 2011, at 11:40 AM, Gerald Pfeifer wrote:
>> Documentation may be a bit more relaxed, and if you have one doc
>> maintainer approve and the other abstain that may be more boring
>> that you might hope for. :-)
>
> Actually, I was aiming
Hi!
create_tmp_var_raw calls build_type_variant, but doesn't actually use
it in any way (other than set its TYPE_ATTRIBUTES, that's why
-Wunused-but-set-variable hasn't reported it.
2011-05-05 Jakub Jelinek
* gimplify.c (create_tmp_var_raw): Don't call build_type_variant.
--- gcc/gim
> Sure, but that's a limitation of out SAVE_EXPR handling (given that it
> would be ok to expand the SAVE_EXPR multiple times - once per
> "instantiation context").
You need to expand the initializer exactly once and you need to make sure that
this occurrence is invoked before all the others at r
On May 5 11:09, Ulrich Weigand wrote:
> This list does not include psignal, which indeed newlib did not provide
> -- until yesterday, when that patch was committed ...
>
>
> I'm not quite sure how to fix this ... any suggestions? Did this problem
> occur in the past when newlib was extende
On 05/05/2011 09:38 AM, Eric Botcazou wrote:
> Hi,
>
> this entirely removes the support for pending sizes from the compiler. The
> prerequisite is Joseph's patch from yesterday.
>
> Bootstrapped/regtested on x86_64-suse-linux, OK for the mainline?
OK.
Bernd
Hi!
My typed DWARF stack changes apparently broke ia64-hpux and H.J.'s out of
tree x32 target. There are several issues:
1) for SUBREG mem_loc_descriptor's 3rd argument was wrong, found by code
inspection
2) CONST/SYMBOL_REF/LABEL_REF when in MEM addresses on POINTERS_EXTEND_UNSIGNED
target
1 - 100 of 110 matches
Mail list logo
