On 01/27/2013 03:16 AM, David Edelsohn wrote:
On Fri, Jan 25, 2013 at 8:55 AM, Michael Haubenwallner
michael.haubenwall...@salomon.at wrote:
Same here, building everything out-of-source. The prerequisites used are:
* CONFIG_SHELL=/usr/local/bin/bash 4.1.7 from bullfreeware (symlinks to
Hi DJ,
Please may I apply the patch below. It fixes the RL78 backend so that
the stack register can be used as a base address register.
Tested with no regressions on an rl78-elf toolchain.
Cheers
Nick
PS. I am currently investigating allow r8-r15 to be used as base
registers.
On Sun, Jan 27, 2013 at 11:26 PM, Steven Bosscher stevenb@gmail.com wrote:
On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote:
The patch was originally worked out by Bernd Schmidt and fixed a problem
introduced in
http://gcc.gnu.org/r190252
Ironically, this revision fixes a reload
[Taking gcc-help off this thread.]
Amol,
I have tested these instruction with GCC and these instructions are generated.
Please review and marge this test support patch in gcc main trunk.
Thanks for this patch and sorry about the delay in getting around to this.
This is ok and I'll take
Gerald Pfeifer wrote:
On Thu, 24 Jan 2013, Georg-Johann Lay wrote:
Committed the following change:
http://gcc.gnu.org/r195424
* config/avr/avr.c (avr_out_fract): Make register numbers that
might be outside of source operand signed.
Can you still post patches to the list, and
Richard Biener wrote:
On Sun, Jan 27, 2013 at 11:26 PM, Steven Bosscher stevenb@gmail.com
wrote:
On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote:
The patch was originally worked out by Bernd Schmidt and fixed a problem
introduced in
http://gcc.gnu.org/r190252
Hi!
We ICE on the following testcase when using cselib, because
cselib_lookup* is never called on the PREFETCH argument, and
add_insn_mem_dependence calls cselib_subst_to_values on it, which
assumes cselib_lookup* already happened on it earlier.
For MEMs sched_analyze_2 calls
This avoids assigning BLOCKs to things that didn't have one before
(originally I observed that the code snippets below happily generate
a UNKNOWN_LOCATION, id-block association). A previous patch last
year changed expansion in a way to not jump back to the outermost
block when observing a NULL
Hi!
As discussed in the PR, this is a safer variant of a fix for 4.8, where
input_location during most optimization passes is set to
DECL_SOURCE_LOCATION (current_function_decl) and various parts of the
gimplifier e.g. during force_gimple_operand* may end up setting
gimple_location to that. For
Hi!
gimple_expand_builtin_pow last two optimizations rely on earlier
optimizations in the same function to be performed, e.g.
folding pow (x, c) for n = 2c into sqrt(x) * powi(x, n / 2) is only
correct for c which isn't an integer (otherwise the sqrt(x) factor would
need to be skipped), but they
Hi!
Some targets apparently force fortification unconditionally or at least by
default, when string.h is then included, memset etc. inlines might call
__builtin_memset or __builtin___memset_chk directly and for explicit builtin
uses -fno-builtin* doesn't work. Fixed by avoiding those includes
On Mon, 28 Jan 2013, Jakub Jelinek wrote:
Hi!
gimple_expand_builtin_pow last two optimizations rely on earlier
optimizations in the same function to be performed, e.g.
folding pow (x, c) for n = 2c into sqrt(x) * powi(x, n / 2) is only
correct for c which isn't an integer (otherwise the
On Mon, Jan 28, 2013 at 03:15:53PM +0100, Richard Biener wrote:
Does this make sense?
Yes. Wouldn't hurt to run GDB testsuite with that, though I bet most of it
is -O0 anyway and thus won't stress it out too much.
2013-01-28 Richard Biener rguent...@suse.de
* tree-inline.c
The following implements what I thought was present (eh ...). For
partitions that contain reductions (feed loop closed PHI nodes) we
rely on them being in the last partition of the loop - as we do not
bother to copy / care for loop closed PHI nodes. The following now
implements that fully (I've
LGTM! Thanks for fixing this.
Bill
On Mon, 2013-01-28 at 15:25 +0100, Jakub Jelinek wrote:
Hi!
gimple_expand_builtin_pow last two optimizations rely on earlier
optimizations in the same function to be performed, e.g.
folding pow (x, c) for n = 2c into sqrt(x) * powi(x, n / 2) is only
Hi,
On Mon, 28 Jan 2013, Richard Biener wrote:
What's the point of switching to the outermost scope for unknown-BLOCK
locations?
It's the most sensical block for code which isn't otherwise associated
with a BLOCK. But the latter Shouldn't Happen, because conceptually all
code runs in some
Ping~
On 01/10/13 16:20, Yufeng Zhang wrote:
Hi,
This patch updates the top-level configuration files to explicitly set
libgloss_dir to aarch64 for aarch64*-*-* targets.
OK to commit?
Thanks,
Yufeng
2013-01-10 Yufeng Zhangyufeng.zh...@arm.com
* configure.ac: Set libgloss_dir for
On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner
michael.haubenwall...@salomon.at wrote:
But still curious if you've been able to reproduce the problem,
and why you didn't encounter this problem beforehand.
As I mentioned before, because of --boot-ld-flags, with earlier libgcc
and
Hi Matt,
Could this patch, or perhaps the much smaller one I attached to bug
35294 be committed to the 4.7 branch?
Yes. Done.
Also, could you close its duplicates, bugs 36798 and 36966?
Sorry no. I do not actually own these PRs, so I cannot close them. :-(
Cheers
Nick
Georg-Johann Lay wrote:
Applied as obvious:
http://gcc.gnu.org/r195471
* doc/extend.texi (Example of asm with clobbered asm reg): Fix
missing ':' in asm example.
The patch:
--- trunk/gcc/doc/extend.texi 2013/01/25 17:55:09 195470
+++ trunk/gcc/doc/extend.texi
On Mon, 28 Jan 2013, Jakub Jelinek wrote:
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56125
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize
pow(x,c) into sqrt(x) * powi(x, n/2) or
1.0 / (sqrt(x) * powi(x, abs(n/2))) if c
On 10 January 2013 21:02, François Dumont wrote:
Hi
Here is an other version of this patch. Indeed there were no need to
expose many stuff public. Inheriting from _Hash_code_base is fine, it is not
final and it deals with EBO itself. I only kept usage of
_Hashtable_ebo_helper when
On Mon, Jan 28, 2013 at 04:41:31PM +0100, Marc Glisse wrote:
On Mon, 28 Jan 2013, Jakub Jelinek wrote:
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56125
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize
pow(x,c) into sqrt(x) * powi(x,
On Mon, 28 Jan 2013, Jakub Jelinek wrote:
On Mon, Jan 28, 2013 at 04:41:31PM +0100, Marc Glisse wrote:
On Mon, 28 Jan 2013, Jakub Jelinek wrote:
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56125
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't
On Mon, Jan 28, 2013 at 05:07:10PM +0100, Marc Glisse wrote:
There is no sqrt, x/(n*n) is just one mul and one div, whereas with
the call I see one mul, 3 movs to prepare for the call, and the
call.
Ah, you're talking about the checked in testcase, rather than the one I've
mentioned in the
On 01/28/2013 07:14 AM, Jakub Jelinek wrote:
Hi!
We ICE on the following testcase when using cselib, because
cselib_lookup* is never called on the PREFETCH argument, and
add_insn_mem_dependence calls cselib_subst_to_values on it, which
assumes cselib_lookup* already happened on it earlier.
For
On Mon, Jan 28, 2013 at 09:39:00AM -0700, Jeff Law wrote:
I'm assuming that we don't need the shallow_copy_rtx call and
related code because in the PREFETCH case we generate a new MEM and
the underlying address can be safely shared. Right?
AFAIK cselib_lookup* never modifies the rtx it is
On 01/28/2013 07:09 AM, Jakub Jelinek wrote:
Hi!
As discussed in the PR, this is a safer variant of a fix for 4.8, where
input_location during most optimization passes is set to
DECL_SOURCE_LOCATION (current_function_decl) and various parts of the
gimplifier e.g. during force_gimple_operand*
On Mon, Jan 28, 2013 at 09:50:35AM -0700, Jeff Law wrote:
2013-01-28 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56094
* gimplify.c (force_gimple_operand_1): Temporarily set input_location
to UNKNOWN_LOCATION while gimplifying expr.
* gcc.dg/pr56094.c: New
This removes modules from libgcc that are already supported by avr-specific
fixed-point implementation and avoids duplicate functions like __mulsa3.
Ok for trunk?
Johann
libgcc/
* config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add:
_mulQQ, _mulHQ, _mulHA, _mulSA,
_mulUQQ,
On 01/27/2013 03:26 PM, Steven Bosscher wrote:
On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote:
The patch was originally worked out by Bernd Schmidt and fixed a problem
introduced in
http://gcc.gnu.org/r190252
Ironically, this revision fixes a reload problem on x86/x86_64 --
which
On 01/27/2013 03:09 PM, Georg-Johann Lay wrote:
If not, it'll probably need release manager approval before it can go
in.
Please attach your patch to PR54814 and attach PR 54814 to the 4.9
pending patches meta bug.
Does this mean the fix is rejected for 4.8?
Not necessarily. We're in a
On 01/28/2013 06:55 AM, Ulrich Weigand wrote:
Richard Biener wrote:
On Sun, Jan 27, 2013 at 11:26 PM, Steven Bosscher stevenb@gmail.com wrote:
On Sun, Jan 27, 2013 at 11:09 PM, Georg-Johann Lay wrote:
The patch was originally worked out by Bernd Schmidt and fixed a problem
introduced in
Please may I apply the patch below. It fixes the RL78 backend so that
the stack register can be used as a base address register.
Yes, please. Thanks!
Uros,
That is intentional. The gthr-rdos.h file is part of libgcc. My intention
was to first patch gcc, then update the patches for newlib, and finally
libgcc. The gthr-rdos.h file would reference include-files part of newlib,
so this is kind of circular. I also cannot define the thread model
On Mon, Jan 28, 2013 at 8:57 PM, Leif Ekblad l...@rdos.net wrote:
That is intentional. The gthr-rdos.h file is part of libgcc. My intention
was to first patch gcc, then update the patches for newlib, and finally
libgcc. The gthr-rdos.h file would reference include-files part of newlib,
so
- Original Message -
From: Uros Bizjak ubiz...@gmail.com
To: Leif Ekblad l...@rdos.net
Cc: Richard Biener rguent...@suse.de; gcc-patches@gcc.gnu.org; H.J.
Lu hjl.to...@gmail.com; Jakub Jelinek ja...@redhat.com
Sent: Monday, January 28, 2013 9:03 PM
Subject: Re: [PATCH] Adding target
Hi,
This is the same patch that I attached in the PR.
It fixes an ICE when building libgcc for the SH2A target.
Tested on rev. 195493 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
... comparing the test results against rev
On Mon, Jan 28, 2013 at 9:14 PM, Leif Ekblad l...@rdos.net wrote:
That is intentional. The gthr-rdos.h file is part of libgcc. My intention
was to first patch gcc, then update the patches for newlib, and finally
libgcc. The gthr-rdos.h file would reference include-files part of
newlib,
so
**ping**
On 23 January 2013 11:06, Tobias Burnus bur...@net-b.de wrote:
Paul Richard Thomas wrote:
*** gfc_alloc_allocatable_for_assignment (gf
*** 8224,8229
--- 8250,8262
desc, tmp);
tmp = gfc_conv_descriptor_dtype (desc);
Attached patch applied.
2013-01-28 François Dumont fdum...@gcc.gnu.org
* include/bits/hashtable_policy.h (_Local_iterator_base): Use
_Hashtable_ebo_helper to embed functors into the local_iterator
when necessary. Pass information about functors involved in hash
code by copy.
On 28 January 2013 21:08, François Dumont wrote:
(Do the performance benchmarks actually tell us anything useful?
When I run them I get such varying results it doesn't seem to be
reliable.)
Last time I run the tests it was showing when not caching was better than
caching.
Yes, I've
On Jan 28, 2013, at 7:07 AM, David Edelsohn dje@gmail.com wrote:
Over the weekend, I successfully tested a different way to configure
and build: all static libraries.
Yeah, I think our build instructions for the dependent libraries should say to
build them statically.
Hi Paul,
This patch is sufficiently straightforward that the ChangeLog entry
describes it completely. The fix for both bugs lay in the
nullification of the allocatable components of the newly (re)allocated
array.
I think this fix is OK for trunk, for the reasons you mentioned. I also
think
Hello,
As the subject suggests, the little patch-set that follows this
message implements a basic optimization for the Address Sanitizer
pass: in the same basic block, it avoids instrumenting an access to a
memory region, if that same access has been instrumented before.
As we store instrumented
Hi Janus,
Or maybe wait for the fix for comment #4?
Rather not (technically it's a separate issue, I guess).
While the patch is rather large, I think it is OK.
One request: Could you add a comment to gfc_sym_get_dummy_args
explaining what the function does and under which conditions
Hello,
The hash table type can handle creation and removal of entries with
malloc/free. This patchlet adds support for using new/delete. It's
useful for hash table entry types that have constructors (and/or
destructors), to prevent the user from having to type boilerplate code
to initialize
Hello,
Like what Address Sanitizer does in LLVM, this patch avoids instrumented
duplicated memory accesses in the same basic blocks.
The approach taken is very conservative, to keep the pass simple, for
a start.
A memory access is considered to be a triplet made of an expression
tree
On Mon, Jan 28, 2013 at 4:17 PM, Mike Stump m...@mrs.kithrup.com wrote:
On Jan 28, 2013, at 7:07 AM, David Edelsohn dje@gmail.com wrote:
Over the weekend, I successfully tested a different way to configure
and build: all static libraries.
Yeah, I think our build instructions for the
That looks good. Thanks, Uros.
Leif
- Original Message -
From: Uros Bizjak ubiz...@gmail.com
To: Leif Ekblad l...@rdos.net
Cc: Richard Biener rguent...@suse.de; gcc-patches@gcc.gnu.org; H.J.
Lu hjl.to...@gmail.com; Jakub Jelinek ja...@redhat.com
Sent: Monday, January 28, 2013 9:45
On 1/28/13, Dodji Seketeli do...@redhat.com wrote:
Hello,
The hash table type can handle creation and removal of entries with
malloc/free. This patchlet adds support for using new/delete. It's
useful for hash table entry types that have constructors (and/or
destructors), to prevent the
Oleg Endo oleg.e...@t-online.de wrote:
This is the same patch that I attached in the PR.
It fixes an ICE when building libgcc for the SH2A target.
Tested on rev. 195493 with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
...
Hello!
2013-01-28 Uros Bizjak ubiz...@gmail.com
* config/alpha/alpha.c (TARGET_LRA_P): New define.
Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
OK for 4.9?
[1] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg02998.html
Uros.
Index: config/alpha/alpha.c
On 01/28/2013 03:14 PM, Uros Bizjak wrote:
2013-01-28 Uros Bizjakubiz...@gmail.com
* config/alpha/alpha.c (TARGET_LRA_P): New define.
Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
OK for 4.9?
Yep.
r~
This patch to the Go frontend fixes a bug determining the initialization
order. I've committed a test case for the bug to the master Go
repository:
https://code.google.com/p/go/source/detail?spec=svn921e53d4863c8827756c0e7b228ab210441e4032r=c3155f9f1bb64c8b3adb2b6f5527895d51f83b74
The old
On 01/28/2013 04:14 PM, Uros Bizjak wrote:
Hello!
2013-01-28 Uros Bizjak ubiz...@gmail.com
* config/alpha/alpha.c (TARGET_LRA_P): New define.
Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
OK for 4.9?
[1]
2013/1/28 Georg-Johann Lay a...@gjlay.de:
This removes modules from libgcc that are already supported by avr-specific
fixed-point implementation and avoids duplicate functions like __mulsa3.
Ok for trunk?
Johann
libgcc/
* config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add:
Ping #1 for
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01053.html
Release Manager approval is here:
http://gcc.gnu.org/ml/gcc/2013-01/msg00222.html
This is tentative patch as discussed in
http://gcc.gnu.org/ml/gcc/2013-01/msg00187.html
fold-const.c gets 2 new function native_encode_fixed
58 matches
Mail list logo
