Hi Janne,
* Janne Blomqvist wrote on Mon, Apr 11, 2011 at 10:34:58PM CEST:
the attached patch removes the definition of _GNU_SOURCE from
AM_CPPFLAGS. This is not needed anymore since nowadays we're calling
AC_USE_SYSTEM_EXTENSIONS in configure.ac which causes _GNU_SOURCE to
be defined in
On Tue, Apr 12, 2011 at 4:54 AM, Jeff Law l...@redhat.com wrote:
On 04/11/11 18:21, Mike Stump wrote:
On Apr 11, 2011, at 1:03 PM, Jeff Law wrote:
The obvious solution is you copy the object, but then you have to be
able to distinguish within the object, what fields point to other
temporary
The resulting speed up for nf.f90 is rather remarkable. What specific
feature of the fortran leads to a 30=15s ?
I think it is the automatic array in the subroutine trisolve. Note that the
speedup is rather 27-19s and may be darwin specific (slow malloc).
Note also that -fstack-arrays
On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
I think all these comments from you old guys ;-) are more
discouraging than fair. What Laurynas and Bernd have done, is nothing
It is IMHO completely fair to point that the risks this brings in
a huge maintainance nightmare are
The propagate_for_debug change alone could fix it, we should never
fall through into next basic block. We are unforuntately not deleting
just jumps (which ought to appear at the end of bbs), but also
any other noop moves, which I think is unintentional, we have
delete_noop_moves that should
hello
good news for you
thousands of new original products here
www.hot-e-trade.com
take a look , it is the best place for Chrisama gift .
i had bought some from them , and i like much
so i tell you
good luck
Hi,
This should fix PR48090 and should be applied to all release branches.
The first alternative doesn't need an early clobber since it is tied to
operand 0 - the second alternative however does need one. This is a bug
that manifests itself with a particular set of command line options and
That is because propagate_for_debug stops at the insn before last, doesn't
process last any longer. So, if there is a DEBUG_INSN right before the
jump being deleted, and it has been propagated into, after the jump is
deleted and retry is done at i2 earlier, following propagate_for_debug
On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
I think all these comments from you old guys ;-) are more
discouraging than fair. What Laurynas and Bernd have done, is nothing
It is IMHO completely fair to
Hi,
tested x86_64-linux, committed mainline and 4_6-branch.
Paolo.
///
2011-04-12 Allan McRae al...@archlinux.org
PR libstdc++/48566
* testsuite/tr1/6_containers/unordered_map/requirements/
iterator_null_neg.cc: Include cstddef.
*
On Tue, 2011-04-12 at 09:05 +0100, Ramana Radhakrishnan wrote:
Hi,
This should fix PR48090 and should be applied to all release branches.
The first alternative doesn't need an early clobber since it is tied to
operand 0 - the second alternative however does need one. This is a bug
that
[Ignoring the other issues for now ...]
On 12/04/11 11:02, Richard Earnshaw wrote:
Also, your change to use a double-letter sequence beginning with 'j'
means any hand-written inline assembly code using a single 'j' will
break (that's a backwards compatibility issue for users); is there
really
Ping for these two changes:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00194.html
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00195.html
They just add a mode argument to TARGET_CANNOT_FORCE_CONST_MEM
and LEGITIMATE_CONSTANT_P (turning the latter into a hook).
This is directly needed
On Apr 12, 2011, at 1:45 AM, Steven Bosscher wrote:
On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
I think all these comments from you old guys ;-) are more
discouraging than fair. What Laurynas and Bernd
On Mon, 11 Apr 2011, Diego Novillo wrote:
On Fri, Apr 8, 2011 at 11:49, Richard Guenther rguent...@suse.de wrote:
I'll leave this for comments over the weekend, and if there are none
will go ahead and check this in early next week.
The approach looks fine to me. Thanks.
I have now
Ping for this change to the NEON vldN and vstN patterns:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01996.html
Thanks,
Richard
On Tue, Apr 12, 2011 at 12:44 PM, Mike Stump mikest...@comcast.net wrote:
- If objects stored in PCH have pointers pointing outside of
PCH-able/GC-managed memory, these become wild pointers on PCH read even with
GTY((skip)) applied properly. However, not all GTY((skip)) pointers point
On Tue, Apr 12, 2011 at 10:29:57AM +0200, Eric Botcazou wrote:
2011-04-12 Jakub Jelinek ja...@redhat.com
PR rtl-optimization/48549
* combine.c (propagate_for_debug): Also stop after BB_END of
this_basic_block. Process LAST and just stop processing after it.
Hi Guys,
I am applying the patch below to the 4.6 branch and mainline sources.
It fixes a problem with the V850 backend where it would generate a
CALLT instruction for a V850 variant which does not support it, when
gcc was compiling an interrupt handler.
Cheers
Nick
gcc/ChangeLog
Hi Richard,
gcc/
* config/arm/arm.c (arm_print_operand): Use MEM_SIZE to get the
size of a '%A' memory reference.
(T_DREG, T_QREG): New neon_builtin_type_bits.
(arm_init_neon_builtins): Assert that the load and store operands
are neon_struct_operands.
So what's the plan for the case where you need to change the lifetime of
an object?
Copying it. Frankly at the moment I don't how much trouble does deep
copying from scratch to function entails, as mentioned in your other
e-mail. ATM I am working at separating permanent from function. If it
[Resending with the correct Mike's address, sorry for the spam]
So what's the plan for the case where you need to change the lifetime of
an object?
Copying it. Frankly at the moment I don't how much trouble does deep
copying from scratch to function entails, as mentioned in your other
e-mail.
Hello,
On Mon, 11 Apr 2011, Steven Bosscher wrote:
Try this patch. I've verified that capacita and nf work with it and
-march=native -ffast-math -funroll-loops -fstack-arrays -O3 . In fact all
of polyhedron works for me on these flags. (I've set a ulimit -s of
512MB, but I don't know
On 04/11/2011 10:03 PM, Jeff Law wrote:
One of the fundamental problems you have to watch out for when dealing
with scratch objects is how to handle the case when you belatedly
realize you want the object to have a longer lifetime.
Historically, our problems with obstacks were a consequence of
On Mon, 11 Apr 2011, Hans-Peter Nilsson wrote:
A nit: you had several lines consisting of TAB*. (with the
obvious expansion) in the changelogs you posted.
Yes, that's the result of line wrapping of struct rtx_def * at end of
sentence.
--
Joseph S. Myers
jos...@codesourcery.com
Joseph S. Myers jos...@codesourcery.com writes:
On Mon, 11 Apr 2011, Hans-Peter Nilsson wrote:
A nit: you had several lines consisting of TAB*. (with the
obvious expansion) in the changelogs you posted.
Yes, that's the result of line wrapping of struct rtx_def * at end of
sentence.
You
On Mon, 11 Apr 2011, Ed Smith-Rowland wrote:
+case CPP_CHAR_USERDEF:
+case CPP_WCHAR_USERDEF:
+case CPP_CHAR16_USERDEF:
+case CPP_CHAR32_USERDEF:
+ {
+ tree literal;
+ cpp_token temp_tok = *tok;
+ char suffix[256] = ;
+ cpp_get_userdef_suffix
On Tue, 2011-04-12 at 11:14 +0100, Andrew Stubbs wrote:
[Ignoring the other issues for now ...]
On 12/04/11 11:02, Richard Earnshaw wrote:
Also, your change to use a double-letter sequence beginning with 'j'
means any hand-written inline assembly code using a single 'j' will
break
This patch is a prerequisite for:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02168.html
(approved but not yet applied, because I'd forgotten about this).
At the moment, gen* programs that want predicate information need
to process the DEFINE*_PREDICATE directives themselves. They can
On Apr 12 2011, Michael Matz wrote:
On Mon, 11 Apr 2011, Steven Bosscher wrote:
Isn't there a way to put a maximum on the size of the arrays on stack,
e.g. -fstack-arrays-limit= or something like that?
Not without generating contorded code. The problem is that these arrays
are variable
On 04/12/2011 02:28 PM, Richard Sandiford wrote:
This patch is a prerequisite for:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02168.html
(approved but not yet applied, because I'd forgotten about this).
At the moment, gen* programs that want predicate information need
to
David Miller da...@davemloft.net writes:
From: Rainer Orth r...@cebitec.uni-bielefeld.de
Date: Mon, 11 Apr 2011 14:57:58 +0200
The follwing patch uses the easy way out and just tests ld_ver. Tested
with make configure-gcc on sparc-sun-solaris2.11 with Sun as/ld, GNU
as/Sun ld, and GNU
vectorizable_load allocates n_copies+1 dr_chains, even though only
the first n_copies are needed. This patch removes the extra one and
IMO makes the flow a bit more obvious.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
* tree-vect-stmts.c
On Tue, Apr 12, 2011 at 3:05 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
vectorizable_store prints the number of copies in the dump output,
but vectorizable_loads doesn't.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Ok.
Thanks,
Richard.
Richard
gcc/
On Tue, Apr 12, 2011 at 3:09 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
vectorizable_load allocates n_copies+1 dr_chains, even though only
the first n_copies are needed. This patch removes the extra one and
IMO makes the flow a bit more obvious.
Tested on x86_64-linux-gnu and
The vectoriser can handle interleaved loads such as:
for (int i = 0; i N; i++)
res[i] = a[2 * i] + a[2 * i + 1];
The vectorised code loads two consecutive vectors from A, then permutes
the elements. It can handle stores in a similar way.
This patch series adds support for load and
This first patch generalises vect_create_data_ref_ptr bump_data_ref_ptr
so that they can handle array as well as vector types. The two cases are
so similar that it's mostly a renaming exercise.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
*
On Tue, Apr 12, 2011 at 3:24 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
This first patch generalises vect_create_data_ref_ptr bump_data_ref_ptr
so that they can handle array as well as vector types. The two cases are
so similar that it's mostly a renaming exercise.
Tested on
On Tue, Apr 12, 2011 at 3:28 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
This patch just reindents part of vectorizable_load and vectorizable_store
so that the main diff is easier to read. It also CSEs the element type,
which seemed better than breaking the long lines.
I've
On Tue, Apr 12, 2011 at 3:44 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
NEON has vld3 and vst3 instructions, which support an interleaving of
three vectors. This patch therefore removes the blanket power-of-two
requirement for interleaving and enforces it on a per-operation
This patch adds vec_load_lanes and vec_store_lanes optabs for instructions
like NEON's vldN and vstN. The optabs are defined this way because the
vectors must be allocated to a block of consecutive registers.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
This patch adds vec_load_lanes and vec_store_lanes patterns for NEON.
They feed directly into the corresponding intrinsic patterns.
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
Richard
gcc/
* config/arm/neon.md (vec_load_lanesmodemode): New expanders,
On Tue, Apr 12, 2011 at 5:28 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
This patch is a prerequisite for:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02168.html
(approved but not yet applied, because I'd forgotten about this).
At the moment, gen* programs that want
Hi,
as that's the first time I propose a patch for gcc: sorry for all formal
mistakes (and please tell me what I should do differently ...)
Those lines were introduced in svn:164531 (22. Sep. 2010), but in
svn:166534 (10. Nov. 2010) the part which could change argv_copied
was removed. As
It's a shame more passes don't make use of the statistics_*
infrastructure. This patch is a step towards rectifying that and adds
statistics_counter_event calls to passes mentioned in $SUBJECT.
postreload-gcse already tracked the stats for the dump file and so only
needs the
The next patch introduces separate vect_stridedN target selectors
for each tested stride factor N. At the moment, some tests contain
several independent loops that have different stride factors.
It's easier to make the next change if we put these loops into
separate tests.
Tested on
On Tue, Apr 12, 2011 at 4:16 PM, Nathan Froyd froy...@codesourcery.com wrote:
It's a shame more passes don't make use of the statistics_*
infrastructure. This patch is a step towards rectifying that and adds
statistics_counter_event calls to passes mentioned in $SUBJECT.
postreload-gcse
This patch replaces the general vect_strided target selector with
a group of vect_stridedN selectors, one for each tested stride factor N.
Also, some tests used vect_interleave vect_extract_even_odd for
strided accesses. The two conditions used to be equivalent, but aren't
after this series for
On Tue, Apr 12, 2011 at 04:27:01PM +0200, Richard Guenther wrote:
On Tue, Apr 12, 2011 at 4:16 PM, Nathan Froyd froy...@codesourcery.com
wrote:
It's a shame more passes don't make use of the statistics_*
infrastructure. This patch is a step towards rectifying that and adds
This patch adds a test for stride-3 accesses. I didn't add any
particularly complicated cases because I think the testsuite already
covers the interaction between the strided loads stores and other
operations pretty well. Let me know if there's something I should
add though.
Tested on
Hello,
Sorry for getting back to this just now, and thank you very much for the
review. Please find below my reply to your comments.
Tom Tromey tro...@redhat.com writes:
Dodjiexpanded_location xloc;
Dodjiif (loc = BUILTINS_LOCATION)
Dodji -{
Dodji - xloc.file = loc ==
On Tue, Apr 12, 2011 at 4:51 PM, Nathan Froyd froy...@codesourcery.com wrote:
On Tue, Apr 12, 2011 at 04:37:42PM +0200, Richard Guenther wrote:
On Tue, Apr 12, 2011 at 4:32 PM, Nathan Froyd froy...@codesourcery.com
wrote:
Thanks. I may go twiddle that patch to do something similar to mine
H.J. Lu hjl.to...@gmail.com writes:
I think your patch caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48573
Sorry, this didn't show up on pure x86_64. It was caused by the
optabs.c patch rather than this one. I've reverted it for now.
One fix would be:
/* If the operand is a memory,
On Tue, Apr 12, 2011 at 4:37 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Yes, I used it exactly for that. And also to verify that passes don't
do anything if replicated (well, for those that shouldn't at least).
What about passes that undo the work of previous patches -- and then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/11 02:45, Steven Bosscher wrote:
On Tue, Apr 12, 2011 at 9:01 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 12, 2011 at 08:33:56AM +0200, Steven Bosscher wrote:
I think all these comments from you old guys ;-) are more
2011-03-12 Andreas Tobler andre...@fgznet.ch
* config/rs6000/freebsd.h: (RELOCATABLE_NEEDS_FIXUP): Define in
terms of target_flags_explicit. Adjust copyright year.
* config.gcc: Add FreeBSD PowerPC soft-float libgcc bits.
* config/rs6000/t-freebsd: New
On Tue, Apr 12, 2011 at 04:54:43PM +0200, Richard Guenther wrote:
On Tue, Apr 12, 2011 at 4:51 PM, Nathan Froyd froy...@codesourcery.com
wrote:
True, but maybe those testcases should be adjusted--per-pass flags,
rather than blindly assuming -O2 includes them. And it's not clear to
It's
On 12.04.11 17:06, Joern Rennecke wrote:
2011-03-12 Andreas Toblerandre...@fgznet.ch
* config/rs6000/freebsd.h: (RELOCATABLE_NEEDS_FIXUP): Define in
terms of target_flags_explicit. Adjust copyright year.
* config.gcc: Add FreeBSD PowerPC soft-float libgcc bits.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/11 05:54, Bernd Schmidt wrote:
On 04/11/2011 10:03 PM, Jeff Law wrote:
One of the fundamental problems you have to watch out for when dealing
with scratch objects is how to handle the case when you belatedly
realize you want the object to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/11/11 13:52, Jakub Jelinek wrote:
Hi!
On the following testcase build_unary_op ICEs, because
the element type of the array variable (which is TREE_READONLY)
unexpectedly is not TYPE_READONLY.
The problem seems to come from
Changelog:
2011-04-12 Yufeng Zhang yufeng.zh...@arm.com
* MAINTAINERS (Write After Approval): Add myself.
Regards,
Yufeng ZhangIndex: MAINTAINERS
===
--- MAINTAINERS (revision 172321)
+++ MAINTAINERS (working copy)
@@
On Tue, 12 Apr 2011, Axel Freyn wrote:
Hi,
as that's the first time I propose a patch for gcc: sorry for all formal
mistakes (and please tell me what I should do differently ...)
Those lines were introduced in svn:164531 (22. Sep. 2010), but in
svn:166534 (10. Nov. 2010) the part which
Hi!
As the testcase below shows, cxx_eval_array_reference only works
properly if ary is CONSTRUCTOR or narrow STRING_CST, if it is
wchar_t/char16_t/char32_t string literal, it still reads a single
byte from the string as if it was a char string.
The following patch fixes that,
On Tue, Apr 12, 2011 at 09:18:01AM +0200, Eric Botcazou wrote:
The propagate_for_debug change alone could fix it, we should never
fall through into next basic block. We are unforuntately not deleting
just jumps (which ought to appear at the end of bbs), but also
any other noop moves,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/11 11:08, Jakub Jelinek wrote:
On Tue, Apr 12, 2011 at 09:18:01AM +0200, Eric Botcazou wrote:
The propagate_for_debug change alone could fix it, we should never
fall through into next basic block. We are unforuntately not deleting
just
On Apr 12, 2011, at 4:46 AM, Laurynas Biveinis wrote:
So what's the plan for the case where you need to change the lifetime of
an object?
Copying it. Frankly at the moment I don't how much trouble does deep
copying from scratch to function entails,
The code to copy isn't too hard and if
Looks good to me, but please wait for Eric to chime in since you've been
discussing it with him already.
Fine with me as well.
--
Eric Botcazou
This patch reintroduce the -mflat option on SPARC. The -mfalt option was
deprecated in february 2004 with GCC 3.4.6. Now, with the support of
LEON processor on GCC, this option has found a new interest.
Just a couple of remarks:
- the epilogue isn't fully RTL-ized,
- delay slot filling for
On 04/12/2011 05:47 AM, Kai Tietz wrote:
ChangeLog gcc/
* config/i386/mingw32.h (TARGET_SUBTARGET_DEFAULT): Add
MASK_MS_BITFIELD_LAYOUT bit.
ChangeLog gcc/testsuite
* g++.dg/ext/bitfield2.C: Add for i?86/x86_64-*-mingw*
targets the additional -mno-ms-bitfields
This patch fixes another inefficiency in the Objective-C compiler.
When it was comparing method signatures, it would copy all the argument types
into some temporary node chains, and then compare these copies. The copies
are then thrown away. It all seems really pointless (since you can just
This fixes another small inefficiency in the Objective-C compiler.
When a method invocation is found, and the parser calls objc_build_method_expr()
to compile it, it used to invoke it as in
objc_build_message_expr (build_tree_list (rec, args));
this (trivial) patch removes the need to create
This patch stops targets not using the Linux kernel from using
linux*.h config headers.
gnu-user.h has TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS added
(defined to 1, overridden in linux.h) so that the non-Linux targets do
not need to have any libc-choice-related definitions from linux.h and
On Apr 12, 2011, at 11:04 AM, Nicola Pero wrote:
This patch fixes another inefficiency in the Objective-C compiler.
Ok to commit ?
Ok.
On Apr 12, 2011, at 11:37 AM, Nicola Pero wrote:
This fixes another small inefficiency in the Objective-C compiler.
It's more about cleaning up the codebase and migrating it from Lisp to C.
You do know that we are reimplementing gcc in lisp, right? ^L It's a joke,
just a joke.
Ok to
This patch to the Go frontend brings it up to date with Martin's change
to the cgraph code. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r cc9719612058 go/gogo-tree.cc
--- a/go/gogo-tree.cc Thu Apr 07 10:07:32 2011 -0700
+++ b/go/gogo-tree.cc
2011/4/12 Richard Henderson r...@redhat.com:
On 04/12/2011 05:47 AM, Kai Tietz wrote:
ChangeLog gcc/
* config/i386/mingw32.h (TARGET_SUBTARGET_DEFAULT): Add
MASK_MS_BITFIELD_LAYOUT bit.
ChangeLog gcc/testsuite
* g++.dg/ext/bitfield2.C: Add for i?86/x86_64-*-mingw*
On Tue, Apr 12, 2011 at 14:49, Lawrence Crowl cr...@google.com wrote:
This patch provides more finer, more precise compile time information.
I sent an advisory mail some time ago, and it was good then. Please
confirm for trunk.
The patch looks fine to me, but of course it's Jason the one you
Hi Janne,
the attached patch does a bit of janitorial type cleanup for the
library. It replaces the use of ssize_t with ptrdiff_t or index_type
where appropriate; this is entirely for documentation purposes, as on
all targets we support ssize_t == ptrdiff_t.
ssize_t is a POSIX type used in the
This saves a few thousands strlen() calls per compilation by reusing
the length of selector strings instead of calculating it again.
Ok to commit ?
Thanks
PS: I'll come back to hashtables later, as they do deserve some
discussion. I want to get all the other obvious tiny changes in
first.
On 04/08/2011 04:37 PM, Mike Stump wrote:
On Apr 8, 2011, at 8:07 AM, Janis Johnson wrote:
Test gcc.target/arm/pr43698.c specifies -march=armv7-a and fails
execution for multilibs whose hardware or simulator doesn't support that
architecture.
Ideally, I'd like target people to weigh in on
In reconstructing pph images, I found some more language-specific
fields that we were not pickling. There's a few more that I will be
sending shortly.
Tested on x86_64. Committed to pph.
2011-04-12 Diego Novillo dnovi...@google.com
* pph-streamer-in.c
This patch, together with the others I sent today, allows us to
reconstruct all the symbols and types stored inside a pph image. This
is not all we need, but it allows me to get basic declarations and
types reconstructed from pph images.
This causes ~57 failures in pph.exp. The more
On 12 April 2011 20:16, Janis Johnson jani...@codesourcery.com wrote:
On 04/08/2011 04:37 PM, Mike Stump wrote:
On Apr 8, 2011, at 8:07 AM, Janis Johnson wrote:
Test gcc.target/arm/pr43698.c specifies -march=armv7-a and fails
execution for multilibs whose hardware or simulator doesn't support
On 8 April 2011 16:08, Janis Johnson jani...@codesourcery.com wrote:
Test gcc.target/arm/sync-1.c specifies -march=armv7-a and fails
execution for multilibs whose hardware or simulator doesn't support that
architecture. The test uses __sync_fetch_and_add, which GCC doesn't
support for all arm
On Apr 12, 2011, at 12:12 PM, Nicola Pero wrote:
This saves a few thousands strlen() calls per compilation by reusing
the length of selector strings instead of calculating it again.
Ok to commit ?
Ok.
During pph processing, when we find an included file that we are going
to instantiate from an image, we don't want libcpp to stack and read
it.
I've implemented this by allowing the 'include' callback to return a
boolean value. If it returns true, then we call _cpp_stack_include.
Otherwise, the
This fixes a problem on cc0 machines where we split a sequence of insns
at a point where we shouldn't - between a cc0 setter and a cc0 user.
The fix is simple enough; just make sure not to pick a cc0 setter as the
end of such a sequence. The patch below was regression tested on
m68k-rtems4.11 by
Discussed the following with Martin on irc to bring rs6000 target up to date
with his changes to the cgraph code. Bootstrap/regtest on powerpc64-linux.
Committed as obvious.
-Pat
2011-04-12 Pat Haugen pthau...@us.ibm.com
* config/rs6000/rs6000.c (call_ABI_of_interest): Call
Add a test to ensure that PPH files are #included at global scope.
Initially, this test is XFAIL, as it's a low priority error.
Index: gcc/testsuite/ChangeLog.pph
2011-04-12 Lawrence Crowl cr...@google.com
* g++.dg/pph/y2smother.cc: New.
Index: gcc/testsuite/g++.dg/pph/y2smother.cc
On 12/04/11 20:16, Janis Johnson wrote:
On 04/08/2011 04:37 PM, Mike Stump wrote:
On Apr 8, 2011, at 8:07 AM, Janis Johnson wrote:
Test gcc.target/arm/pr43698.c specifies -march=armv7-a and fails
execution for multilibs whose hardware or simulator doesn't support that
architecture.
Ideally,
From: Rainer Orth r...@cebitec.uni-bielefeld.de
Date: Tue, 12 Apr 2011 15:00:53 +0200
On Solaris 10, as assembles the test just fine, but ld cannot deal with
gas 2.21 output:
ld: fatal: relocation error: R_SPARC_GOTDATA_HIX22: file gotdata.o: symbol
unknown: offset 0xff370163 is
This patch adds lightweight debug checks (if enabled by macros).
To be applied only to google/integration branch.
Tested by bootstrapping and running make check.
2011-04-12 Paul Pluzhnikov ppluzhni...@google.com
* libstdc++-v3/include/ext/vstring.h: Enable debug checks when
On 04/12/2011 01:06 PM, Jakub Jelinek wrote:
+: (unsigned)TREE_STRING_LENGTH (ary)
+ * (TYPE_PRECISION (TREE_TYPE (TREE_TYPE (ary)))
+ / TYPE_PRECISION (char_type_node)));
Don't you mean / instead of * here? Let's also calculate the size of
the element once
This fixes 20020425-1.c when the compiler under test is built with -O0 and
we're on a machine with an 8 meg stack.
Ok?
2011-04-12 Mike Stump mikest...@comcast.net
* c-typeck.c (c_finish_if_stmt): Fold result.
* fold-const.c (fold_ternary_loc): Handle an empty else.
This
Hi,
On Tue, 12 Apr 2011, Bernd Schmidt wrote:
This fixes a problem on cc0 machines where we split a sequence of insns
at a point where we shouldn't - between a cc0 setter and a cc0 user.
The fix is simple enough; just make sure not to pick a cc0 setter as the
end of such a sequence. The
On 04/13/2011 01:45 AM, Michael Matz wrote:
And is there any chance to transform this:
+#ifdef HAVE_cc0
+ if (!sets_cc0_p (insn))
+#endif
+ max_to = insn;
into this:
+ if (!sets_cc0_p (insn))
max_to = insn;
? Yes, that implies making
One oddity, otherwise LGTM.
http://codereview.appspot.com/4389045/diff/1/gcc/cp/parser.c
File gcc/cp/parser.c (right):
http://codereview.appspot.com/4389045/diff/1/gcc/cp/parser.c#newcode375
gcc/cp/parser.c:375: if (flag)
This code will never print false, so why have it?
On Apr 12, 2011, at 2:23 PM, Gerald Pfeifer wrote:
This was inspired by Mike, though he probably doesn't know it. :-)
I recall the conversation... :-) Arguably, having a pre-commit hook would be
even more whiz-bang.
LGTM
On 4/12/11, Diego Novillo dnovi...@google.com wrote:
In reconstructing pph images, I found some more language-specific
fields that we were not pickling. There's a few more that I will be
sending shortly.
Tested on x86_64. Committed to pph.
2011-04-12 Diego Novillo
LGTM
On 4/12/11, Diego Novillo dnovi...@google.com wrote:
This patch, together with the others I sent today, allows us to
reconstruct all the symbols and types stored inside a pph image. This
is not all we need, but it allows me to get basic declarations and
types reconstructed from pph
1 - 100 of 107 matches
Mail list logo
