On Sat, May 25, 2013 at 04:07:11PM -0700, Benjamin De Kosnik wrote:
>
> > Looks good to me.
>
> Great, trunk patch in.
>
> > Will you prepare corresponding patch for the 4.8
> > branch too (I guess it should be pretty much the same, not sure if it
> > should keep using typedef system_clock ste
The changes suggested by:
http://gcc.gnu.org/ml/fortran/2013-05/msg00057.html
have been made in the below diff and test file.
Could someone please commit this ?
It has been approved, see the above referenced message.
thanks,
Bud Davis
Index: gcc/gcc/fortran/resolve.c
===
On Sat, May 25, 2013 at 4:46 AM, Richard Biener
wrote:
> Easwaran Raman wrote:
>
>>In that case, if my insert_stmt immediately follows dep_stmt and both
>>have the same UID, not_dominated_by would return true and I will end
>>up updating insert_stmt to dep_stmt which is wrong.
>
> But there shoul
Oleg Endo wrote:
> I'd like to fix this ancient PR.
> The attached patch picks up the suggested changes mentioned in comment
> #3 to avoid changing the FPSCR.FR bit in the sdivsi3_i4 and udivsi3_i4
> library functions. As mentioned in the PR, this makes integer division
> a bit slower when using
> Looks good to me.
Great, trunk patch in.
> Will you prepare corresponding patch for the 4.8
> branch too (I guess it should be pretty much the same, not sure if it
> should keep using typedef system_clock steady_clock as before for the
> non-MONOTONIC configuration, or if it should just do t
> Here's an idea that could make it easier to remove the "cfun" global.
>
> "cfun" is a major piece of global state within gcc: it's the 5th most
> accessed variable in the build (accessed in ~4600 places within one stage
> of a build, based on [1]). This is an obstacle to making gcc's code be
>
On Sat, May 25, 2013 at 11:56:31AM -0700, Benjamin De Kosnik wrote:
> I'm tempted to check this patch into trunk. Jakub?
Looks good to me. Will you prepare corresponding patch for the 4.8 branch
too (I guess it should be pretty much the same, not sure if it should keep
using typedef system_clock
> > It scraps the renaming/aliasing approach, and just creates a
> > compatibility-chrono.cc that mimics the default configuration in
> > 4.8.0.
>
> Yeah, I think that is reasonable, with one nit, see below.
Cool, incorporated.
> > Users who specially-configured a build with --enable-libstdcxx
Hello,
this patch only handles the simple case where the constant is 0, I'll keep
the PR open for the more general case. Note that if we split
flag_trapping_math into no|weak|strict, the test here would be !=strict,
since we only remove trapping operations.
Passes bootstrap+testsuite on x86_
> gcc/ChangeLog:
>
> * tree-cfg.c (locus_descrim_hasher::hash): Only hash lineno.
> (locus_descrim_hasher::equal): Likewise.
> (next_discriminator_for_locus): Likewise.
> (assign_discriminator): Add return value.
> (make_edges): Assign more discriminator if necessary.
> (make_cond_expr_edges): Lik
Tidy some mips.h preprocessor goo now that we're allowed to use #elif.
Tested on mips64-linux-gnu and applied.
Richard
gcc/
* config/mips/mips.h: Use #elif in preprocessor conditions.
Index: gcc/config/mips/mips.h
===
---
PR 53916 was originally about a wrong-code division bug in 4.6 and earlier.
Although that in itself has been fixed, the reported pointed out that the
new code isn't able to reuse the same MIPS16 instruction for both division
and modulus results. The problem is that, for MIPS16, we now expose the
(
This patch prevents inlining between functions of different ISA modes.
Tested on mips64-linux-gnu and applied.
Richard
gcc/
PR target/55777
* config/mips/mips.c (mips_can_inline_p): New function.
(TARGET_CAN_INLINE_P): Define.
gcc/testsuite/
PR target/55777
> What is the significance of the target selection?
Copied from optimize-bswapdi-1.c, but I should probably have copied it from
optimize-bswapsi-1.c for the bswapsi case. Will adjust.
> builtin-bswap-9.c fails on ia64, it still generates bswap:DI for foo2,
> foo3 and foo4.
OK, I'll take a look
This patch is 547K in size, so I've uploaded it to:
http://dmalcolm.fedorapeople.org/gcc/large-patches/928e2d33daafe1943766dfb437f6ba7b795dfa41-0002-autogenerated-part-of-cfun-expansion.patch
Patch autogenerated by refactor_cfun.py from
https://github.com/davidmalcolm/gcc-refactoring-scripts
revi
Here's an idea that could make it easier to remove the "cfun" global.
"cfun" is a major piece of global state within gcc: it's the 5th most
accessed variable in the build (accessed in ~4600 places within one stage
of a build, based on [1]). This is an obstacle to making gcc's code be
usable as a
Eliminate all direct references to "cfun" from macros in
basic-block.h and introduce access methods to control_flow_graph
* basic-block.h (control_flow_graph::get_basic_block_by_idx): New
accessor methods.
(control_flow_graph::get_entry_block): New method.
Eric Botcazou writes:
> /* { dg-do compile { target arm*-*-* alpha*-*-* ia64*-*-* x86_64-*-*
> s390x-*-* powerpc*-*-* rs6000-*-* } } */
What is the significance of the target selection?
builtin-bswap-9.c fails on ia64, it still generates bswap:DI for foo2,
foo3 and foo4.
Andreas.
--
Andreas
Hi,
I'm adding the testcase and closing the bug as fixed for 4.9.0.
Thanks,
Paolo.
2013-05-25 Paolo Carlini
PR c++/52216
* g++.dg/cpp0x/new1.C: New.
Index: g++.dg/cpp0x/new1.C
===
--- g++.dg
Easwaran Raman wrote:
>In that case, if my insert_stmt immediately follows dep_stmt and both
>have the same UID, not_dominated_by would return true and I will end
>up updating insert_stmt to dep_stmt which is wrong.
But there should be a safe default answer for
Equal uids. Unless we are asking d
> Sure, will update the patch for that. ...
This cause pr57413.
Dominique
PS the escaping in the regexp seems strange: \[0-9]
On Sat, May 25, 2013 at 08:21:46AM +0200, Jakub Jelinek wrote:
> In this _V2 inline namespace, I think we should change that:
> struct system_clock
> {
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
> typedef chrono::nanoseconds duration;
> #elif defined(_GLIBCXX_U
22 matches
Mail list logo
