On 01/27/2013 03:16 AM, David Edelsohn wrote:
> On Fri, Jan 25, 2013 at 8:55 AM, Michael Haubenwallner
> 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
>> /opt/freeware/bin/)
>> * /
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.
gcc/Cha
"Maciej W. Rozycki" writes:
> On Sat, 26 Jan 2013, Richard Sandiford wrote:
>
>> > How about instead of complicating this we simply add support for
>> > microMIPS encoding in the PLT? I think I should be able to squeeze out
>> > some time next week to dust off and retest the binutils patch I'v
On Sun, Jan 27, 2013 at 11: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 reloa
[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 thi
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 th
Richard Biener wrote:
> On Sun, Jan 27, 2013 at 11: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
> >
>
Dear Ramana,
Thank You very much for the changelog and commit of my patch in gcc.
I will follow the steps mentioned by you.
Thank You,
Amol Pise
On Mon, Jan 28, 2013 at 4:18 PM, Ramana Radhakrishnan wrote:
>
>
> [Taking gcc-help off this thread.]
>
> Amol,
>
>
>> I have tested these instructio
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 cselib_lookup_from_in
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 L
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 4
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 a
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 and
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 t
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
>
> * tree-inline.c (remap_gimple_stmt): D
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 Zhang
* configure.ac: Set libgloss_dir for the aarch64*-*-* tar
On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner
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 libstdc++ installed in that directory
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.tex
On Mon, 28 Jan 2013, Jakub Jelinek wrote:
2013-01-28 Jakub Jelinek
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 is an integer or w
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 e
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
> >
> > 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) o
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
PR tree-optimization/56125
* tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize
p
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 d
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 M
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 p
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* may
On Mon, Jan 28, 2013 at 09:50:35AM -0700, Jeff Law wrote:
> >2013-01-28 Jakub Jelinek
> >
> > 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 test.
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, _mul
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 do
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 regr
On 01/28/2013 06:55 AM, Ulrich Weigand wrote:
Richard Biener wrote:
On Sun, Jan 27, 2013 at 11: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/r19
> 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 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 this is kind
- Original Message -
From: "Uros Bizjak"
To: "Leif Ekblad"
Cc: "Richard Biener" ; ; "H.J.
Lu" ; "Jakub Jelinek"
Sent: Monday, January 28, 2013 9:03 PM
Subject: Re: [PATCH] Adding target rdos to GCC
On Mon, Jan 28, 2013 at 8:57 PM, Leif Ekblad wrote:
That is intentional. The g
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 19
On Mon, Jan 28, 2013 at 9:14 PM, Leif Ekblad 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 t
**ping**
On 23 January 2013 11:06, Tobias Burnus wrote:
> Paul Richard Thomas wrote:
>>
>> *** gfc_alloc_allocatable_for_assignment (gf
>> *** 8224,8229
>> --- 8250,8262
>> desc, tmp);
>> tmp = gfc_conv_descriptor_dtype (desc);
>> gf
Attached patch applied.
2013-01-28 François Dumont
* 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.
* include/bits/ha
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'
On Jan 28, 2013, at 7:07 AM, David Edelsohn 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 i
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 sym->fo
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 them
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 representin
On Mon, Jan 28, 2013 at 4:17 PM, Mike Stump wrote:
> On Jan 28, 2013, at 7:07 AM, David Edelsohn 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
That looks good. Thanks, Uros.
Leif
- Original Message -
From: "Uros Bizjak"
To: "Leif Ekblad"
Cc: "Richard Biener" ; ; "H.J.
Lu" ; "Jakub Jelinek"
Sent: Monday, January 28, 2013 9:45 PM
Subject: Re: [PATCH] Adding target rdos to GCC
On Mon, Jan 28, 2013 at 9:14 PM, Leif Ekbla
On 1/28/13, Dodji Seketeli 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 user from havi
> From: Kenneth Zadeck
> Date: Mon, 28 Jan 2013 02:02:41 +0100
> this looks good to me. does your patch also address the vec_concat
> issue that marc raised?
You mean the issue being "same thing there"? I can confirm that
(I've stumbled upon) the same issue being there (i.e. similarly
applies
Oleg Endo 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}"
>
> ... comparing the
Hello!
2013-01-28 Uros Bizjak
* 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 Bizjak
* 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=svn921e53d4863c8827756c0e7b228ab210441e4032&r=c3155f9f1bb64c8b3adb2b6f5527895d51f83b74
The old algor
On 01/28/2013 04:14 PM, Uros Bizjak wrote:
Hello!
2013-01-28 Uros Bizjak
* 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
Can you a
2013/1/28 Georg-Johann Lay :
> 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,
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
61 matches
Mail list logo
