Hello,
I reproduced the failure and found reason of it. I understood haw it
resolve and now I need small changes only - additional argument of
EMIT_MODE_SET. Is it good fo trunk?
Thank you,
Vladimir
2012-09-14 Vladimir Yakovlev vladimir.b.yakov...@intel.com
*
On Thu, Sep 13, 2012 at 7:37 PM, Mike Stump mikest...@comcast.net wrote:
On Sep 13, 2012, at 6:52 AM, Robert Dewar de...@adacore.com wrote:
Sure, it is obvious that you don't want -g to affect -O1 or -O2 code,
but I think if you have -Og (if and when we have that), it would not
be a bad thing
Richard,
I've tried to handle more LSHIFT_EXPR cases with a shift range in tree-vrp.
Currently we handle cases like this:
- non-negative shifting out zeros
[5, 6] [1, 2]
== [10, 24]
This patch adds these cases:
- unsigned shifting out ones
[0xff00, 0x] [1, 2]
==
On Fri, Sep 14, 2012 at 09:27:27AM +0200, Tom de Vries wrote:
* gcc.dg/tree-ssa/vrp81.c: New test.
* gcc.dg/tree-ssa/vrp81-2.c: Same.
* gcc.dg/tree-ssa/vrp82.c: Same.
Why not vrp82.c, vrp83.c and vrp84.c (and rename the recently added
vrp80-2.c test to vrp81.c)?
On 14/09/12 09:38, Jakub Jelinek wrote:
On Fri, Sep 14, 2012 at 09:27:27AM +0200, Tom de Vries wrote:
* gcc.dg/tree-ssa/vrp81.c: New test.
* gcc.dg/tree-ssa/vrp81-2.c: Same.
* gcc.dg/tree-ssa/vrp82.c: Same.
Why not vrp82.c, vrp83.c and vrp84.c (and rename the recently added
On Fri, Sep 14, 2012 at 09:51:48AM +0200, Tom de Vries wrote:
On 14/09/12 09:38, Jakub Jelinek wrote:
On Fri, Sep 14, 2012 at 09:27:27AM +0200, Tom de Vries wrote:
* gcc.dg/tree-ssa/vrp81.c: New test.
* gcc.dg/tree-ssa/vrp81-2.c: Same.
* gcc.dg/tree-ssa/vrp82.c: Same.
Why
Additionaly.
You can find the patch history in
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01590.html.
I need this changes for my implementation of vzeroupper placement:
for some statements I have no needs doing real insertion.
I tested the changes on bootstrap using config
I think it's going to make GCC harder to maintain if we drop the -g0
vs. -g no-code-difference requirement for just some optimization
levels.
Seconded, this is surely going to open yet another can of worms.
--
Eric Botcazou
On Fri, Sep 14, 2012 at 11:50:31AM +0300, Janne Blomqvist wrote:
A few quick comments,
1) Although mmap is not guaranteed to be async-signal-safe, in
practice it should be as you mentioned previously. However I see that
when using mmap, the implementation uses pthread mutexes. These are
not
On Thu, 13 Sep 2012, Steven Bosscher wrote:
On Wed, Sep 12, 2012 at 4:52 PM, Steven Bosscher wrote:
On Wed, Sep 12, 2012 at 4:02 PM, Richard Guenther wrote:
for a followup (and I bet sth else than PRE blows up at -O2 as well).
Actually, the only thing that really blows up is that enemy
On Thu, Sep 13, 2012 at 07:46:52PM -0700, H.J. Lu wrote:
There is no reason why --eh-frame-hdr can't be used with static
executable on Linux. This patch enables --eh-frame-hdr for static
Well, there is. For more than 2 years after the addition of --eh-frame-hdr
support dl_iterate_phdr in
On Fri, 14 Sep 2012, Richard Guenther wrote:
On Thu, 13 Sep 2012, Steven Bosscher wrote:
On Wed, Sep 12, 2012 at 4:52 PM, Steven Bosscher wrote:
On Wed, Sep 12, 2012 at 4:02 PM, Richard Guenther wrote:
for a followup (and I bet sth else than PRE blows up at -O2 as well).
Hi,
On 09/14/2012 03:16 AM, H.J. Lu wrote:
Hi,
include/random has
#ifdef _GLIBCXX_USE_C99_STDINT_TR1
#include cstdint // For uint_fast32_t, uint_fast64_t, uint_least32_t
#include bits/random.h
#include bits/random.tcc
#endif // _GLIBCXX_USE_C99_STDINT_TR1
random_device is defined in
On Thu, Sep 13, 2012 at 8:05 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
this patch is a minor cleanup of my previous forwprop patches for vectors. I
have known about get_prop_source_stmt from the beginning, but for some
reason I always used SSA_NAME_DEF_STMT. This makes the source
Vladimir Yakovlev vbyakov...@gmail.com wrote:
I reproduced the failure and found reason of it. I understood haw it
resolve and now I need small changes only - additional argument of
EMIT_MODE_SET. Is it good fo trunk?
Thank you,
Vladimir
2012-09-14 Vladimir Yakovlev
On Fri, Sep 14, 2012 at 9:59 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Sep 14, 2012 at 09:51:48AM +0200, Tom de Vries wrote:
On 14/09/12 09:38, Jakub Jelinek wrote:
On Fri, Sep 14, 2012 at 09:27:27AM +0200, Tom de Vries wrote:
* gcc.dg/tree-ssa/vrp81.c: New test.
*
Terry Guo wrote:
-/* { dg-final { scan-assembler movs\tr\[0-9\] } } */
+/* { dg-final { scan-assembler lsrs\tr\[0-9\] { target arm_thumb2_ok } }
} */
+/* { dg-final { scan-assembler movs\tr\[0-9\] { target { ! arm_thumb2_ok
} } } } */
This causes the arm.exp testcase to fail with a tcl
On 2012.09.13 at 14:51 -0700, Andi Kleen wrote:
Markus Trippelsdorf mar...@trippelsdorf.de writes:
Because there is no enthusiastic support for a full libtool update,
here is a minimal version that adds a new slim-lto-bootstrap
build-config.
Can you split the two patches? libtool and
Credits go to Ralf Wildenhues.
2012-09-13 Markus Trippelsdorf mar...@trippelsdorf.de
* libtool.m4 : Handle slim-lto objects
diff --git a/libtool.m4 b/libtool.m4
index a7f99ac..5754fb1 100644
--- a/libtool.m4
+++ b/libtool.m4
@@ -3434,6 +3434,7 @@ for ac_symprfx in _; do
else
Credits go to Ralf Wildenhues.
2012-09-13 Markus Trippelsdorf mar...@trippelsdorf.de
* ltmain.sh: Handle lto options
diff --git a/ltmain.sh b/ltmain.sh
index a03433f..2e09101 100644
--- a/ltmain.sh
+++ b/ltmain.sh
@@ -4980,7 +4980,8 @@ func_mode_link ()
# @file GCC response
2012-09-13 Markus Trippelsdorf mar...@trippelsdorf.de
* Makefile.in (configure-(build-)fixincludes): Pass CFLAGS
diff --git a/Makefile.in b/Makefile.in
index 0108162..891168d 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -2835,6 +2835,7 @@ configure-build-fixincludes:
test ! -f
2012-09-13 Markus Trippelsdorf mar...@trippelsdorf.de
* config/slim-lto-bootstrap.mk: new build-config
diff --git a/config/slim-lto-bootstrap.mk b/config/slim-lto-bootstrap.mk
new file mode 100644
index 000..11d1252
--- /dev/null
+++ b/config/slim-lto-bootstrap.mk
@@ -0,0 +1,9 @@
On 2012-09-14 04:59 , Eric Botcazou wrote:
I think it's going to make GCC harder to maintain if we drop the -g0
vs. -g no-code-difference requirement for just some optimization
levels.
Seconded, this is surely going to open yet another can of worms.
Agreed.
Diego.
On Fri, Sep 14, 2012 at 11:43 AM, Richard Guenther rguent...@suse.de wrote:
Any reason why you didn't just re-use the tree-ssa-live machinery?
Probably I didn't know about it or didn't want to keep the full life
problem life (it tries to free things as soon as possible).
I think it'd be good
On Fri, 14 Sep 2012, Steven Bosscher wrote:
On Fri, Sep 14, 2012 at 11:43 AM, Richard Guenther rguent...@suse.de wrote:
Any reason why you didn't just re-use the tree-ssa-live machinery?
Probably I didn't know about it or didn't want to keep the full life
problem life (it tries to free
This, as suggested in the PR arranges update_address_taken to be
run before forwprop. The patch simply moves it to after CCP
instead of before alias computation.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-09-14 Richard Guenther rguent...@suse.de
PR
On Fri, 14 Sep 2012, Richard Guenther wrote:
As for the equiv sets - yes, that's known. I wanted to investigate
at some point what happens if we instead record the SSA name we
registered the assert for (thus look up a chain of lattice values
instead of recording all relevant entries in a
On Fri, Sep 14, 2012 at 2:41 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Sep 13, 2012 at 07:46:52PM -0700, H.J. Lu wrote:
There is no reason why --eh-frame-hdr can't be used with static
executable on Linux. This patch enables --eh-frame-hdr for static
Well, there is. For more than 2
On Thu, Sep 13, 2012 at 10:42 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Sep 13, 2012 at 5:52 PM, Jakub Jelinek ja...@redhat.com wrote:
The fma-*.c testcase show that these intrinsics probably mean to preserve
the high elements (other than the lowest) of the first argument of the
On Fri, Sep 14, 2012 at 12:50 PM, Richard Guenther wrote:
Yikes, I didn't know about my_rev_post_order_compute. How horrible!
That function doesn't compute reverse post-order of the CFG, but a
post-order of the reverse CFG!
Ok, well - then that's what we need for compute_antic to have
On Fri, Sep 14, 2012 at 05:12:19AM -0700, H.J. Lu wrote:
On Fri, Sep 14, 2012 at 2:41 AM, Jakub Jelinek ja...@redhat.com wrote:
Well, there is. For more than 2 years after the addition of --eh-frame-hdr
support dl_iterate_phdr in libc.a would simply always fail, you aren't
adding any kind
On Fri, 14 Sep 2012, Steven Bosscher wrote:
On Fri, Sep 14, 2012 at 12:50 PM, Richard Guenther wrote:
Yikes, I didn't know about my_rev_post_order_compute. How horrible!
That function doesn't compute reverse post-order of the CFG, but a
post-order of the reverse CFG!
Ok, well - then
Hi,
here we crash because strip_typedefs while processing _RequireInputIter
calls make_typename_type which returns error_mark_node (# line 3281).
Thus I'm simply checking for result == error_mark_node right after the
switch (in the switch finish_decltype_type could also return
On 09/13/2012 07:37 PM, Marc Glisse wrote:
Looks like a latent bug in fold_unary. The following seems to work in
this case.
Looks good.
Jason
Here is the patch I just tested. Changes compared to the previous patch
include:
* same_type_ignoring_top_level_qualifiers_p
* build_vector_type: don't use an opaque vector for the return type of
operator (not sure what the point was of making it opaque?)
* Disable BIT_AND - TRUTH_AND
On Fri, Sep 14, 2012 at 5:26 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Sep 14, 2012 at 05:12:19AM -0700, H.J. Lu wrote:
On Fri, Sep 14, 2012 at 2:41 AM, Jakub Jelinek ja...@redhat.com wrote:
Well, there is. For more than 2 years after the addition of --eh-frame-hdr
support
Markus Trippelsdorf mar...@trippelsdorf.de writes:
If the patches look Ok, I would be nice if someone could commit them,
because I have no access.
I cannot approve them, so needs someone to do that first.
But I can commit once that's done.
-Andi
--
a...@linux.intel.com -- Speaking for
On 09/14/2012 09:59 AM, Marc Glisse wrote:
* build_vector_type: don't use an opaque vector for the return type of
operator (not sure what the point was of making it opaque?)
I think the point was to allow conversion of the result to a different
vector type. Why do you want it not to be
On 09/14/2012 09:05 AM, Paolo Carlini wrote:
here we crash because strip_typedefs while processing _RequireInputIter
calls make_typename_type which returns error_mark_node (# line 3281).
strip_typedefs should not return error_mark_node unless it gets
error_mark_node as an argument; if a
Hi,
There are some Thumb2 patterns in vfp.md which are duplicated with only
minor changes from their ARM equivalents. This patch adds requirement
in *thumb2_movdf_vfp pattern, that one of the operands sould be register,
like in ARM *movdf_vfp pattern.
There is one functional change: the ARM
On Fri, 14 Sep 2012, Jason Merrill wrote:
On 09/14/2012 09:59 AM, Marc Glisse wrote:
* build_vector_type: don't use an opaque vector for the return type of
operator (not sure what the point was of making it opaque?)
I think the point was to allow conversion of the result to a different
The GCC 4.7 branch is now frozen for creating a first release candidate
of the GCC 4.7.2 release.
All changes need explicit release manager approval until the final
release of GCC 4.7.2 which should happen roughly one week after
the release candidate if no issues show up with it.
Previous
Hi,
On 09/14/2012 04:36 PM, Jason Merrill wrote:
On 09/14/2012 09:05 AM, Paolo Carlini wrote:
here we crash because strip_typedefs while processing _RequireInputIter
calls make_typename_type which returns error_mark_node (# line 3281).
strip_typedefs should not return error_mark_node unless
ping...
Thanks,
Dehao
On Sun, Sep 9, 2012 at 5:42 AM, Dehao Chen de...@google.com wrote:
Hi,
I've added a libjava unittest which verifies that this patch will not
break Java debug info. I've also incorporated Richard's review in the
previous mail. Attached is the new patch, which passed
On 09/08/2012 10:42 PM, Dehao Chen wrote:
I've added a libjava unittest which verifies that this patch will not
break Java debug info. I've also incorporated Richard's review in the
previous mail. Attached is the new patch, which passed bootstrap and
all gcc/libjava testsuites on x86.
Is it
On 13 September 2012 19:07, Mike Stump mikest...@comcast.net wrote:
On Sep 13, 2012, at 2:45 AM, Christophe Lyon christophe.l...@linaro.org
wrote:
Ping?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00330.html
So, two things I thought I'd ask about:
+/* __attribute__ ((noinline)) is
I've implemented the standard pattern ffs, which leads to
__builtin_ffs being generated with 4 instructions instead
of 5 instructions.
Regression tests and my new test pass.
OK to commit?
Cheers,
Ian
2012-09-14 Ian Bolton ian.bol...@arm.com
gcc/
* config/aarch64/aarch64.md
On 09/14/2012 05:14 PM, Paolo Carlini wrote:
lookup_field returns NULL_TREE and dependent_type_p (context) is
false. It seems to me that the return value of lookup_field is right.
No, I don't think it makes sense for lookup_field to return NULL_TREE.
For our testcase we should find the nested
Add __builtin_ppc_get_timebase and __builtin_ppc_mftb to read the Time
Base Register on PowerPC.
They are required by applications that measure time at high frequencies
with high precision that can't afford a syscall.
__builtin_ppc_get_timebase returns the 64 bits of the Time Base Register
while
On 09/14/2012 11:03 AM, Marc Glisse wrote:
I wanted to use decltype(xx) to find an integer vector type of the same
size as x, and then actually be able to use it. Being opaque, it refuses
to be initialized (cp/decl.c:5550). Maybe decltype (and others?) could
return non-opaque types?
That
On Fri, 14 Sep 2012, Jason Merrill wrote:
On 09/14/2012 11:03 AM, Marc Glisse wrote:
I wanted to use decltype(xx) to find an integer vector type of the same
size as x, and then actually be able to use it. Being opaque, it refuses
to be initialized (cp/decl.c:5550). Maybe decltype (and others?)
Hi Jakub
I have run it on 4.6, it passes the following testing:
x86-64 bootstrap
x86-64 regression test
regression test on arm qemu
Is it OK for gcc4.6?
Ahmad, is it OK for google/gcc-4_6/ and google/gcc-4_6-mobile ?
thanks
Carrot
On Wed, Sep 12, 2012 at 2:01 PM, Carrot Wei car...@google.com
On Fri, Sep 14, 2012 at 09:39:43AM -0700, Carrot Wei wrote:
I have run it on 4.6, it passes the following testing:
x86-64 bootstrap
x86-64 regression test
regression test on arm qemu
Is it OK for gcc4.6?
Yes.
Jakub
On 09/14/2012 12:33 PM, Marc Glisse wrote:
Ok, I'll open a bugzilla to remember to try that later.
OK.
The attached just finished the testsuite (changelog unchanged).
This patch is OK.
Jason
On 14/09/12 15:58, Рубен Бучацкий wrote:
Hi,
There are some Thumb2 patterns in vfp.md which are duplicated with only
minor changes from their ARM equivalents. This patch adds requirement
in *thumb2_movdf_vfp pattern, that one of the operands sould be register,
like in ARM *movdf_vfp
Bug 54103 is a C front-end regression involving ICEs in certain cases
of expressions such as 0 / 0 being converted to truthvalues.
c_common_truthvalue_conversion, or
c_objc_common_truthvalue_conversion, received 0 / 0 directly as a
TRUNC_DIV_EXPR, without any wrapping C_MAYBE_CONST_EXPR to
The following standard pattern names were implemented by simply
renaming some existing patterns:
* fnma
* fms
* fnms
I have added an extra pattern for when we don't care about
signed zero, so we can do -fma (a,b,c) more efficiently.
Regression testing all passed.
OK to commit?
Cheers,
Ian
On 14/09/12 18:05, Ian Bolton wrote:
The following standard pattern names were implemented by simply
renaming some existing patterns:
* fnma
* fms
* fnms
I have added an extra pattern for when we don't care about
signed zero, so we can do -fma (a,b,c) more efficiently.
Regression
On Sep 14, 2012, at 8:23 AM, Christophe Lyon christophe.l...@linaro.org wrote:
OK. So I will remove the noinline stuff, and update the bugzilla entry
with the name of this testcase.
Should I really leave the test as FAILED rather then XFAIL?
No. Best to either add the test case as that bug is
On Sep 11, 2012, at 7:55 AM, Jack Howarth howa...@bromo.med.uc.edu wrote:
The attached patch fixes the bootstrap on darwin to cope with the
VEC changes to remove unnecessary VEC function overloads. Tested on
x86_64-apple-darwin12. Okay for gcc trunk.
Ok.
On Fri, 14 Sep 2012, Jason Merrill wrote:
[decltype of opaque vector]
I think a simple TYPE_MAIN_VARIANT will do, I just need to find where to
add it, and how much to constrain that change. Type deduction in templates
and auto already seem to remove opacity :-)
This patch is OK.
On 14/09/12 16:26, Ian Bolton wrote:
I've implemented the standard pattern ffs, which leads to
__builtin_ffs being generated with 4 instructions instead
of 5 instructions.
Regression tests and my new test pass.
OK to commit?
Cheers,
Ian
2012-09-14 Ian Bolton
Segher Boessenkool seg...@kernel.crashing.org writes:
Hi Tulio,
Hi Segher,
+(define_expand rs6000_get_timebase
+ [(use (match_operand:DI 0 gpc_reg_operand ))]
+
+
+{
+ if (TARGET_POWERPC64)
+emit_insn (gen_rs6000_get_timebase_ppc64 (operands[0]));
+ else
+emit_insn
Hello,
this patch changes the ARM back-end to use vld1.64/vst1.64 instructions
instead of vldm/vstm -where possible- to implement double-word moves.
The main benefit of this is that it allows the compiler to provide
appropriate alignment hints, which may improve performance.
The patch is
Hello,
following up on the prior patch, this patch exploits more opportunities to
generate the vld1 / vst1 family of instructions, this time to implement the
vec_set and vec_extract patterns with memory scalar operands.
Without the patch, vec_set/vec_extract only support register operands for
A fairly trivial follow-up to the patch with the code. I added a line for
PR 53024 while I was there...
2012-09-14 Marc Glisse marc.gli...@inria.fr
PR c/53024
PR c++/54427
* doc/extend.texi (Vector Extensions): C++ improvements.
Power of 2 size requirement.
Jason,
H.J. figured out that this changed when case SCOPE_REF of
value_dependent_expression_p started always returning true, part of the
instantiation_dependent_p work...
I'm unassigning myself, I guess you will immediately see which further
changes are needed.
Thanks!
Paolo.
Hello,
recent patches have let optimizations move from forwprop2 to forwprop1.
The attached checks that this remains the case. (copyprop1 is the first
pass after forwprop1 that does a dce-like cleanup)
Only manually tested for now, will check better if it is accepted.
2012-09-15 Marc
Hi
Here is a patch to add emplace/emplace_hint on associative
containers in C++11 mode.
I did some refactoring to use as much of the same code between
insert and emplace methods..
I have also change map::operator[] to now use the emplace logic in
C++11 so that we only need the
Backport from trunk r190952 to add counter histogram to gcov program summary,
and follow-on fixes for PR gcov-profile/54487 (r191074 and r191238).
Tested on x86_64-unknown-linux-gnu. Ok for google branches?
2012-09-14 Teresa Johnson tejohn...@google.com
* libgcc/libgcov.c
On Fri, Sep 14, 2012 at 4:09 PM, Teresa Johnson tejohn...@google.com wrote:
Backport from trunk r190952 to add counter histogram to gcov program summary,
and follow-on fixes for PR gcov-profile/54487 (r191074 and r191238).
Why don't we just get this via the trunk - google/main merges?
Diego.
On Fri, Sep 14, 2012 at 1:10 PM, Diego Novillo dnovi...@google.com wrote:
On Fri, Sep 14, 2012 at 4:09 PM, Teresa Johnson tejohn...@google.com wrote:
Backport from trunk r190952 to add counter histogram to gcov program summary,
and follow-on fixes for PR gcov-profile/54487 (r191074 and
On Fri Sep 14 16:17:25 2012, Teresa Johnson wrote:
Should I just put it onto ggogle/4_7 and 4_6 directly then?
Yeah. Not sure it's really needed in 4_6, though.
Diego.
Yes. The google/main update will happen next quarter.
David
On Fri, Sep 14, 2012 at 1:17 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Sep 14, 2012 at 1:10 PM, Diego Novillo dnovi...@google.com wrote:
On Fri, Sep 14, 2012 at 4:09 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Sep 14, 2012 at 1:19 PM, Diego Novillo dnovi...@google.com wrote:
On Fri Sep 14 16:17:25 2012, Teresa Johnson wrote:
Should I just put it onto ggogle/4_7 and 4_6 directly then?
Yeah. Not sure it's really needed in 4_6, though.
Ok. There are only trivial differences between the
yes.
thanks,
David
On Fri, Sep 14, 2012 at 1:20 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Sep 14, 2012 at 1:19 PM, Diego Novillo dnovi...@google.com wrote:
On Fri Sep 14 16:17:25 2012, Teresa Johnson wrote:
Should I just put it onto ggogle/4_7 and 4_6 directly then?
Yeah.
Hi,
Recently we found out that the .interp section starts to show up in
ARM executables compiled with -shared -static and the gold linker
from binutils 2.22. We tracked down the origin of the dynamic linker
commands and they are always explicitly specified in
config/arm/linux-elf.h. We tested the
On 09/14/2012 10:07 PM, François Dumont wrote:
Hi
Here is a patch to add emplace/emplace_hint on associative
containers in C++11 mode.
Ah, excellent! I will review the patch over the next couple of days.
I did some refactoring to use as much of the same code between
insert and
On 9/1/2012 7:33 AM, Gerald Pfeifer wrote:
On Tue, 28 Aug 2012, Walter Lee wrote:
This patch adds support for the -mcmodel=MODEL flag on TILE-Gx.
At which point I cannot help asking for an update to the
release notes at http://gcc.gnu.org/gcc-4.8/changes.html. ;-)
Let me know if you need help
I don't think TARGET_MFCRF is correct. For example, if you use
-mcpu=powerpc64 (which doesn't set this flag) you will get code
that does not run on the newer machines.
Sorry, but it seems to be working here...
I explain how I tested this in the end of the email.
David tells me all current
Bug 54552 is a C front-end regression involving ICEs when an
expression involving C_MAYBE_CONST_EXPR, such as a compound literal of
variably modified type, is cast to a variably modified type. This
patch fixes it by doing the appropriate folding before creating the
outer C_MAYBE_CONST_EXPR.
On Fri, Sep 14, 2012 at 4:52 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
I don't think TARGET_MFCRF is correct. For example, if you use
-mcpu=powerpc64 (which doesn't set this flag) you will get code
that does not run on the newer machines.
Sorry, but it seems to be working
Segher Boessenkool seg...@kernel.crashing.org writes:
I don't think TARGET_MFCRF is correct. For example, if you
use
-mcpu=powerpc64 (which doesn't set this flag) you will get
code
that does not run on the newer machines.
Sorry, but it seems to be working here...
I explain how I tested
While trying to revive an ancient 4.1-based port, I found that tm.texi
still documented things like current_function_pretend_args_size which
were deleted in 2008. I've updated the text to reflect the idioms used
in current code.
Checked in as obvious after building and inspecting the manual.
On Wed, 12 Sep 2012, Hans-Peter Nilsson wrote:
On Wed, 12 Sep 2012, Nathan Froyd wrote:
- Keeping old layout of mmix_reg_or_8bit_operand. That looked like
a spurious change and I prefer the ior construct to the
if_then_else.
ISTR without this change, there were lots of assembly
On Fri, Sep 14, 2012 at 8:34 PM, Tulio Magno Quites Machado Filho
tul...@linux.vnet.ibm.com wrote:
Segher Boessenkool seg...@kernel.crashing.org writes:
I don't understand the problem.
There is no problem.
Segher is concerned that -mcpu=powerpc64, which is suppose to generate
generic PPC64
On Sat, Sep 8, 2012 at 2:42 PM, Dehao Chen de...@google.com wrote:
Hi,
I've added a libjava unittest which verifies that this patch will not
break Java debug info. I've also incorporated Richard's review in the
previous mail. Attached is the new patch, which passed bootstrap and
all
output - source compiled test
spawn [open ...]^M
-1
-1
-1
PASS: sourcelocation -findirect-dispatch execution - source compiled test
FAIL: sourcelocation -findirect-dispatch output - source compiled test
I am using binutils mainline 20120914 from CVS.
--
H.J.
On Fri, Sep 14, 2012 at 9:25 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Sep 8, 2012 at 2:42 PM, Dehao Chen de...@google.com wrote:
Hi,
I've added a libjava unittest which verifies that this patch will not
break Java debug info. I've also incorporated Richard's review in the
previous
89 matches
Mail list logo
