2012/9/14 Georg-Johann Lay :
> This patch adds more fixed-point support, namely saturated operations:
>
> SS_PLUS, SS_MINUS, SS_NEG, SS_ABS,
> US_PLUS, US_MINUS, US_NEG
>
> for all supported fixed-point modes:
>
> [U]QQ,
> [U]HQ, [U]HA,
> [U]SQ, [U]SA,
> [U]DQ, [U]DA, [U]TA.
>
> Depending on their
On Fri, Sep 14, 2012 at 9:25 PM, H.J. Lu wrote:
> On Sat, Sep 8, 2012 at 2:42 PM, Dehao Chen 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 pat
FAIL: sourcelocation -O3 -findirect-dispatch output - source compiled test
> FAIL: sourcelocation -O3 output - source compiled test
> FAIL: sourcelocation -findirect-dispatch output - source compiled test
> FAIL: sourcelocation 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 Sat, Sep 8, 2012 at 2:42 PM, Dehao Chen 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 gcc/libjava testsui
On Fri, Sep 14, 2012 at 8:34 PM, Tulio Magno Quites Machado Filho
wrote:
> Segher Boessenkool writes:
> I don't understand the problem.
There is no problem.
Segher is concerned that -mcpu=powerpc64, which is suppose to generate
"generic" PPC64 code produces mftb instead of mfspr. However, the
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 lo
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.
Segher Boessenkool 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 this in the end of the email.
On Fri, Sep 14, 2012 at 4:52 PM, Segher Boessenkool
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 here...
>> I expla
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.
Boots
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 CPU
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
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 emplace
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 th
yes.
thanks,
David
On Fri, Sep 14, 2012 at 1:20 PM, Teresa Johnson wrote:
> On Fri, Sep 14, 2012 at 1:19 PM, Diego Novillo 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
On Fri, Sep 14, 2012 at 1:19 PM, Diego Novillo 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 patch I uploaded
Yes. The google/main update will happen next quarter.
David
On Fri, Sep 14, 2012 at 1:17 PM, Teresa Johnson wrote:
> On Fri, Sep 14, 2012 at 1:10 PM, Diego Novillo wrote:
>> On Fri, Sep 14, 2012 at 4:09 PM, Teresa Johnson wrote:
>>> Backport from trunk r190952 to add counter histogram to gcov
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.
On Fri, Sep 14, 2012 at 1:10 PM, Diego Novillo wrote:
> On Fri, Sep 14, 2012 at 4:09 PM, Teresa Johnson 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 vi
On Fri, Sep 14, 2012 at 4:09 PM, Teresa Johnson 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.
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
* libgcc/libgcov.c (gcov_histogram_insert): New func
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
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 Glisse
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.
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
PR c/53024
PR c++/54427
* doc/extend.texi (Vector Extensions): C++ improvements.
Power of 2 size requirement.
--
Marc GlisseIndex: d
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 the
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 based
Segher Boessenkool 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 (gen_rs6000_get_timebase_ppc
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
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.
Committed
On Sep 11, 2012, at 7:55 AM, Jack Howarth 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 Sep 14, 2012, at 8:23 AM, Christophe Lyon 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 fixed or xfail it.
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.
>
> Re
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
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 indicat
Hi Tulio,
@@ -14103,6 +14105,84 @@
""
"")
+(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 (gen_rs6000_get_timebase_ppc32 (
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_vf
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 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
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 wrote:
> Hi Jakub
On Fri, 14 Sep 2012, Jason Merrill wrote:
On 09/14/2012 11:03 AM, Marc Glisse wrote:
I wanted to use decltype(x
That sounds like the right answer.
Ok, I'll open a bugzilla to remember to try that later.
Type is %qT right? I see a number of %q#T but can't remember where the
doc is. Well, I'
On Fri, 14 Sep 2012, H.J. Lu wrote:
> +# Only support for glibc 2.3.0 or higher with AT_PHDR/AT_PHNUM from
> +# Linux kernel.
> + [[if test x$host = x$build -a x$host = x$target &&
> + ldd --version 2>&1 >/dev/null &&
Could we please stop adding this sort of native-only test? There is
v
On 09/14/2012 11:03 AM, Marc Glisse wrote:
I wanted to use decltype(x
That sounds like the right answer.
Type is %qT right? I see a number of %q#T but can't remember where the
doc is. Well, I'll try both and see what happens.
Either one works; the # asks for more verbose output.
Jason
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 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 ty
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
gcc/
* config/aarch64/aarch64.md (csinc3): Make it into a
On 13 September 2012 19:07, Mike Stump wrote:
> On Sep 13, 2012, at 2:45 AM, Christophe Lyon
> 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 currently required, otherwise the
>> + ge
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.
>
>
ping...
Thanks,
Dehao
On Sun, Sep 9, 2012 at 5:42 AM, Dehao Chen 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
>
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 i
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 Repor
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 ve
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 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 typede
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 op
Markus Trippelsdorf 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 myself only
On Fri, Sep 14, 2012 at 5:26 AM, Jakub Jelinek 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 wrote:
>> > Well, there is. For more than 2 years after the addition of --eh-frame-hdr
>> > support dl_iterate_phdr in libc.a would s
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 optimi
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
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
error_mark_node
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, w
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 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 of check t
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 Thu, Sep 13, 2012 at 10:42 AM, Uros Bizjak wrote:
> On Thu, Sep 13, 2012 at 5:52 PM, Jakub Jelinek 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
>> fmaintrin.h *_s{s,d} intrinsics
On Fri, Sep 14, 2012 at 2:41 AM, Jakub Jelinek 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 years after
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
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
PR tree-optimization
On Fri, 14 Sep 2012, Steven Bosscher wrote:
> On Fri, Sep 14, 2012 at 11:43 AM, Richard Guenther 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 thin
On Fri, Sep 14, 2012 at 11:43 AM, Richard Guenther 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 to use t
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.
2012-09-13 Markus Trippelsdorf
* 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 @@
+# This option enables s
2012-09-13 Markus Trippelsdorf
* 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 $(BUILD_SUBDIR)/fixinc
Credits go to Ralf Wildenhues.
2012-09-13 Markus Trippelsdorf
* 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 files
# -tp=* Portl
Credits go to Ralf Wildenhues.
2012-09-13 Markus Trippelsdorf
* 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
lt_cv_sys_global_sy
On 2012.09.13 at 14:51 -0700, Andi Kleen wrote:
> Markus Trippelsdorf 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 ltmain? Thank
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
On Fri, Sep 14, 2012 at 9:59 AM, Jakub Jelinek 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.
>> >>* gcc.dg/tree-s
Vladimir Yakovlev 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
>
> * (optimize_mode_s
On Thu, Sep 13, 2012 at 8:05 PM, Marc Glisse 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 code slightly
> sho
Hi,
On 09/14/2012 03:16 AM, H.J. Lu wrote:
Hi,
include/random has
#ifdef _GLIBCXX_USE_C99_STDINT_TR1
#include // For uint_fast32_t, uint_fast64_t, uint_least32_t
#include
#include
#endif // _GLIBCXX_USE_C99_STDINT_TR1
random_device is defined in . But src/c++11/random.cc
has
#include
.
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).
> >
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 lib
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 tha
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
> 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
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 guaranteed to be async-signal-safe either, but I guess in practice
as l
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
../gcc/configu
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.
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
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)?
Ja
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]
== [0x
91 matches
Mail list logo
