On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
The directory should be /libhf/ or /libhfp/ for that for consistency
with all the other architectures. Note e.g. x86_64 dynamic linker
is /lib64/ld-linux-x86-64.so.2,
For thumb1 use move + add instructions for immediate move [256-510].
Following is a complete range if combine an imm mov with listed
instructions. Among them, lsls and neg have already been implemented. The
only missing opportunity is add, in which I enabled in this patch. Others
are replicated w
2012/4/12 Paulo César Pereira de Andrade
:
> Em 11 de abril de 2012 21:16, Michael Hope escreveu:
>> 2012/4/12 Paulo César Pereira de Andrade
>> :
>>> Em 11 de abril de 2012 20:22, Michael Hope
>>> escreveu:
On 12 April 2012 10:38, Steve McIntyre wrote:
> On Wed, Apr 11, 2012 at 02:06:
On 12 April 2012 12:38, Wookey wrote:
> +++ Michael Hope [2012-04-12 12:16 +1200]:
>> 2012/4/12 Paulo César Pereira de Andrade
>> :
>
>> >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>> > Sorry for more bikeshedding,
>> > /lib/ld-linux-armv7hl.so.3
>> I'd rather drop the '
2012/4/12 Paulo César Pereira de Andrade
:
> Em 11 de abril de 2012 20:22, Michael Hope escreveu:
>> On 12 April 2012 10:38, Steve McIntyre wrote:
>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
And here's the details as promised.
I've started a wiki page at
On 12 April 2012 10:38, Steve McIntyre wrote:
> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>
>>And here's the details as promised.
>>
>>I've started a wiki page at
>>
>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>>with a strawman agenda for now, an
PR libstdc++/52924
* include/bits/shared_ptr_base.h (_Sp_counted_deleter): Add
user-defined destructor.
(_Sp_counted_inplace): Likewise.
* testsuite/20_util/shared_ptr/cons/52924.cc: New.
* testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust dg-err
On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote:
> > Tests passing, bootstrap in progress.
> >
> > Comments?
>
> Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> see that in the code. I think that's really required, otherwise the optimizer
> will do the wrong thing
On 04/11/2012 10:35 AM, Bernd Schmidt wrote:
On 12/23/2011 05:31 PM, Vladimir Makarov wrote:
On 12/21/2011 09:09 AM, Bernd Schmidt wrote:
This patch was an experiment to see if we can get the same improvement
with modifications to IRA, making it more tolerant to over-aggressive
scheduling. THe
I think this makes the text read a bit better.
* doc/xml/manual/debug.xml (Debug Versions of Library Binary Files):
Re-arrange text slightly.
Committed to trunk
commit 74b28e0fa40289525b44c79920cbd64a36a0cb52
Author: Jonathan Wakely
Date: Wed Apr 11 23:13:49 2012 +0100
The default expansion of bswapsi2 (and bswapdi2) is pretty suboptimal.
Tested on m68k-linux.
Andreas.
* config/m68k/m68k.md (rotrhi3+1): Name it rotrhi_lowpart.
(bswapsi2): New expander.
diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
index e4b4b59..8104e75 100644
>> 3) As you mentioned, the .mod version incompatibility also severely
>> limits the mixing of code compiled with different compiler versions.
>> And the proc-pointer name mangling (which is under discussion here)
>> *only* concerns proc-pointers inside modules.
>
> Note however, that GCC 4.7 and 4
Oleg Endo wrote:
> The attached patch make the code use some more 'bool' and 'NULL_RTX'.
> Tested with 'make all-gcc'.
> OK?
OK.
Regards,
kaz
Oleg Endo wrote:
> The attached patch adds some more test cases for PR 50751.
>
> Tested on sh-sim with
> make check-gcc RUNTESTFLAGS="sh.exp=pr50751* --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a-single/-mb,-m4-single/-ml,
> -m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
>
> to confirm that
I have checked in the following patch to update my email address. I am
currently working on getting a new copyright assignment filed as my previous
one was based on my employment at HP.
Steve Ellcey
sell...@mips.com
2012-04-11 Steve Ellcey
* MAINTAINERS: Changed email address.
Ind
> > That's true. Actually I see the values are defined by the compiler
> > at compile time, so it would be possible to move all one up?
>
> No, that is IMHO not possible. They need to match the enum values that are
> part of libstdc++ ABI already, and not everybody is going to use the
> __ATOMIC_
Hi,
this is the spurious error on asm statements of the form:
error: 'asm' operand requires impossible reload
present for IA-64 on mainline and 4.7 branch. As diagnosed by Ulrich, the code
responsible for the error implicitly assumes that constraints accepting memory
operands also accept ps
Hello,
The attached patch make the code use some more 'bool' and 'NULL_RTX'.
Tested with 'make all-gcc'.
OK?
ChangeLog:
* config/sh/sh.h (RETURN_ADDR_RTX): Use NULL_RTX instead of 0.
* config/sh/sh.c (INSN_REGMODE_WEIGHT, CURR_REGMODE_PRESSURE):
Fix line width.
(d
On 11 April 2012 18:40, H.J. Lu wrote:
>
> It breaks library tests:
>
> ERROR: tcl error sourcing
> ../../../../src-trunk/boehm-gc/testsuite/../../gcc/testsuite/lib/prune.exp.
> ERROR: tcl error sourcing
> ../../../../src-trunk/libgomp/testsuite/../../gcc/testsuite/lib/prune.exp.
> ERROR: tcl erro
This fixes a check-performance failure caused by my changes for libstdc++/49204
* testsuite/performance/30_threads/future/polling.cc: Adjust.
Tested x86_64-linux, committing to trunk and 4.7 branch.
commit fbb91a75e318226e666967a28883483a027f1f07
Author: Jonathan Wakely
Date: Wed Apr 1
Hi,
This patch simplifies TRY_EMPTY_VM_SPACE for Linux hosts by checking
pointer size when appropriate. Tested on Linux/x86-64, Linux/ia32
and Linux/x32. OK for trunk?
Thanks.
H.J.
---
2012-04-11 H.J. Lu
* config/host-linux.c (TRY_EMPTY_VM_SPACE): Check pointer size
for alp
It was brought to my attention that when I rewrote the floating point
conversion operations for power7, I did not notice that the power4 and 970
powerpc's actually support the FCFID (floating point convert) instruciton in
32-bit mode. This patch fixes it. It is ok to apply? I did bootstraps with
On Apr 11, 2012, at 11:15 AM, Manuel López-Ibáñez wrote:
> contrib/compare_tests does not seem to detect this :-(
I'd bet, either, there were no tests after that point, or, compare_tests
pointed it out. Feel free to send the two .sum files and and I will
investigate if you think that isn't the
On Tue, Apr 10, 2012 at 7:41 AM, H.J. Lu wrote:
> On Thu, Apr 5, 2012 at 8:57 AM, H.J. Lu wrote:
>> On Thu, Apr 5, 2012 at 8:36 AM, Uros Bizjak wrote:
>>> On Thu, Apr 5, 2012 at 3:28 PM, H.J. Lu wrote:
>>>
>>> Looking at how other targets implement this check, I don't think that
>>> thi
On 04/11/2012 09:15 PM, Richard Sandiford wrote:
> Bernd Schmidt writes:
>> On 04/11/2012 07:31 PM, Peter Bigot wrote:
>>> The biggest one is that widening from 20-bit to 32-bit is an extremely
>>> expensive operation: it was a 16-bit ISA, but some newer MCUs support
>>> an extension with 20 bits
Hi,
The attached patch adds some more test cases for PR 50751.
Tested on sh-sim with
make check-gcc RUNTESTFLAGS="sh.exp=pr50751* --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a-single/-mb,-m4-single/-ml,
-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
to confirm that the tests pass as expected.
Bernd Schmidt writes:
> On 04/11/2012 07:31 PM, Peter Bigot wrote:
>> The biggest one is that widening from 20-bit to 32-bit is an extremely
>> expensive operation: it was a 16-bit ISA, but some newer MCUs support
>> an extension with 20 bits in each register and a set of new
>> instructions that
On Wed, Apr 11, 2012 at 6:06 PM, Andi Kleen wrote:
> + static char buf[128], hle[16];
>
> The hle buffer does not need to be static.
> BTW I'm surprised there is no better way to do this in machine descriptions
> than to use static buffers.
Oh, there is. Since we are looking at the operands, we
"H.J. Lu" writes:
> Here is the updated patch to change set_reg_attrs_from_value to
> take arbitrary value and check incompatible pointer sign
> extension. OK for trunk if there are no regressions on Linux/x86-64?
The new code ought to go before the HARD_REGISTER_P check, not after it.
OK with t
On Wed, Apr 11, 2012 at 06:40:03PM +0200, Andi Kleen wrote:
> > But such a model isn't possible. The HLE bits are just some high bits
> > ored into the memory model enum. So, if you use
> > __ATOMIC_HLE_ACQUIRE, it is the same thing as
> > __ATOMIC_HLE_ACQUIRE | __ATOMIC_RELAXED and thus it is a
On Wed, Apr 11, 2012 at 11:15 AM, Manuel López-Ibáñez
wrote:
> So how can I say in tcl "if not defined VAR then set VAR ""?
if ![info exists VAR] {
set VAR XXX
}
Thanks,
Andrew Pinski
In 11 April 2012 18:40, H.J. Lu wrote:
>
> It breaks library tests:
>
> ERROR: tcl error sourcing
> ../../../../src-trunk/boehm-gc/testsuite/../../gcc/testsuite/lib/prune.exp.
> ERROR: tcl error sourcing
> ../../../../src-trunk/libgomp/testsuite/../../gcc/testsuite/lib/prune.exp.
> ERROR: tcl erro
On 04/11/2012 07:31 PM, Peter Bigot wrote:
> The biggest one is that widening from 20-bit to 32-bit is an extremely
> expensive operation: it was a 16-bit ISA, but some newer MCUs support
> an extension with 20 bits in each register and a set of new
> instructions that must be used to preserve the
On Wed, Apr 11, 2012 at 01:48:57PM -0400, Jason Merrill wrote:
> We can't talk about the type if there is no type.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
Shouldn't this go to 4.7 too?
> commit bc94f519583cdfc705c1bde750a06bbd42537193
> Author: Jason Merrill
> Date: Wed Apr 11 10:0
We can't talk about the type if there is no type.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit bc94f519583cdfc705c1bde750a06bbd42537193
Author: Jason Merrill
Date: Wed Apr 11 10:08:37 2012 -0400
PR c++/52906
* decl.c (check_tag_decl): Don't complain about attributes if we
Dodji's final patch for 45088 fixed the GDB regression, but as Jakub
recently pointed out to me, we still end up with redundant
DW_TAG_pointer_types in some cases, with one for pointer-to-class and
the other for pointer-to-injected-class-name. We strip the
injected-class-name in dwarf2out so t
On Wed, Apr 11, 2012 at 7:00 PM, H.J. Lu wrote:
> SUBTARGET_OVERRIDE_OPTIONS and SUBSUBTARGET_OVERRIDE_OPTIONS may depend
> on TARGET_64BIT. This patch moves their handling after TARGET_64BIT
> is updated. Tested on Linux/x86-64. OK for trunk?
>
> 2012-04-10 H.J. Lu
>
> * config/i386/
On Tue, Apr 10, 2012 at 8:15 PM, Mike Frysinger wrote:
> On Tuesday 10 April 2012 12:46:49 Michael Edwards wrote:
>> That way I can grandfather in binaries with ABI-ignorant
>> hard-coded library paths, and still handle ISA variants. The
>> "extranoise" might be "neon", or "ssse3"
>
> aren't ISA
On Wed, Apr 11, 2012 at 7:21 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> Hi,
>>
>> CSE turns (reg:DI 64)
>>
>> (insn 6 3 7 2 (set (reg:DI 64)
>> (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
>> {*extendsidi2_rex64} (nil))
>>
>> into (reg/f:DI 64 [ addr ]).
Hi Janus:
> I would surely appreciate some input from others, also from users (in
> particular from Andrew as the bug reporter). In general: Is ABI
> compatibility of different gfortran versions important to gfortran
> users? (For me personally, as a user, not so much. I usually don't
> link my ow
Hi,
SUBTARGET_OVERRIDE_OPTIONS and SUBSUBTARGET_OVERRIDE_OPTIONS may depend
on TARGET_64BIT. This patch moves their handling after TARGET_64BIT
is updated. Tested on Linux/x86-64. OK for trunk?
Thanks.
H.J.
---
2012-04-10 H.J. Lu
* config/i386/i386.c (ix86_option_override_internal
On 04/11/2012 04:57 PM, Rainer Orth wrote:
> Ok for mainline?
>
> Rainer
>
>
> 2012-04-11 Rainer Orth
>
> * jcf-dump.c (print_constant): Cast JPOOL_USHORT2, JPOOL_USHORT1
> results to long to match formats.
Sure. Sorry for the noise.
I wonder what we're supposed to do ab
On Tue, Apr 10, 2012 at 1:33 PM, Manuel López-Ibáñez
wrote:
> On 10 April 2012 21:41, Manuel López-Ibáñez wrote:
>> On 10 April 2012 21:31, Jason Merrill wrote:
>>> On 04/10/2012 12:46 PM, Manuel López-Ibáñez wrote:
+ max_width = context->caret_max_width;
+ if (max_width<= 0)
>>
> But such a model isn't possible. The HLE bits are just some high bits
> ored into the memory model enum. So, if you use
> __ATOMIC_HLE_ACQUIRE, it is the same thing as
> __ATOMIC_HLE_ACQUIRE | __ATOMIC_RELAXED and thus it is a relaxed xacquire,
> not xacquire with default memory model.
> __atom
This patch makes the branch to build in C++ mode by default.
Tested on x86_64. Committed.
ChangeLog.cxx-conversion
* configure.ac (ENABLE_BUILD_WITH_CXX): Default to 'yes'.
* configure: Regenerate.
gcc/ChangeLog.cxx-conversion
* configure.ac (ENABLE_BUILD_WITH_CXX): Def
On Tue, Apr 3, 2012 at 2:02 PM, Ilya Enkovich wrote:
>> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>
>> The point is that one can build a toolchain for i686-linux-gnu that will
>> support both 32-bit and 64-bit multi
On Wed, Apr 11, 2012 at 06:18:56PM +0200, Andi Kleen wrote:
> > I actually think it is a bad idea to imply any memory model
> > from the HLE bits. If anything, we should warn for memmodel
> > + hle bit combinations that are unlikely to DTRT.
>
> This would be a warning with _RELAXED/_CONSUME, but
> I actually think it is a bad idea to imply any memory model
> from the HLE bits. If anything, we should warn for memmodel
> + hle bit combinations that are unlikely to DTRT.
This would be a warning with _RELAXED/_CONSUME, but there may be very
obscure situations where someone really wants that
On Wed, Apr 11, 2012 at 06:06:58PM +0200, Andi Kleen wrote:
> +static unsigned HOST_WIDE_INT
> +ix86_extend_hle_macro (unsigned HOST_WIDE_INT memmodel)
> +{
> + unsigned HOST_WIDE_INT result = memmodel;
> +
> + if (memmodel & IX86_HLE_ACQUIRE)
> +result |= MEMMODEL_ACQUIRE;
> +
> + if (memmo
On Wed, Apr 11, 2012 at 07:52:59PM +0400, Kirill Yukhin wrote:
> Yet another iteration :)
>
> >> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> Sorry, Andi. Added. So, at the moment you can do smth like
> __atomic_compare_exchange_n (p, &oldv, newv, 0,
> __ATOMIC_H
Andrew Haley writes:
> On 04/11/2012 01:43 PM, Richard Guenther wrote:
>> This breaks bootstrap for me:
>>
>> In file included from
>> /space/rguenther/src/svn/trunk/gcc/java/jcf-parse.c:1009:0:
>> /space/rguenther/src/svn/trunk/gcc/java/jcf-reader.c:550:1: error:
>> 'int jcf_parse_bootstrap_meth
Yet another iteration :)
>> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
Sorry, Andi. Added. So, at the moment you can do smth like
__atomic_compare_exchange_n (p, &oldv, newv, 0,
__ATOMIC_HLE_ACQUIRE, __ATOMIC_ACQUIRE);
And will get __ATOMIC_ACQUIRE model as well
On Apr 11, 2012, at 6:59 AM, Bernd Schmidt wrote:
> This is another problem I found working on a new target. In fold-const,
> when folding conversions, there are two instances where mode bitsizes
> are compared to type precisions. This fails to do the right thing if
> mode precision and bitsize dif
On Apr 11, 2012, at 4:52 PM, Mike Stump wrote:
> On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:
>> On 04/11/2012 04:02 PM, Tristan Gingold wrote:
>>>
>>> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
I'm working on a target where intptr_t and pointers are larger than
size_t and
On Apr 11, 2012, at 6:55 AM, Bernd Schmidt wrote:
> I'm working on a target where intptr_t and pointers are larger than
> size_t and ptrdiff_t.
Hum, we question your sanity :-)
> Ok?
Ok. I hope you tested it on your target too!
On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:
> On 04/11/2012 04:02 PM, Tristan Gingold wrote:
>>
>> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
>>> I'm working on a target where intptr_t and pointers are larger than
>>> size_t and ptrdiff_t. The testsuite has problems in this area, sinc
This pattern is of type load, but the operands don't match the pattern
found in other load insns, so we must explicitly set op_pattern to
unknown. Committed.
Bernd
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 186325)
++
We sometimes get to invoke Makefile targets with a CC variable value containing
spaces (for extra options, typically). This causes failure at some stages on
powerpc-aix from mh-ppc-aix which has
LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;`
The problem is the expansion of spaces a
On 04/11/2012 10:08 AM, Bernd Schmidt wrote:
On 02/10/2012 08:01 PM, Vladimir Makarov wrote:
On 02/08/2012 10:01 AM, Bernd Schmidt wrote:
We found a scheduler problem while testing Coldfire targets. The
prune_ready_list function I introduced doesn't take SCHED_GROUPs into
account, which can lea
On 12/23/2011 05:31 PM, Vladimir Makarov wrote:
> On 12/21/2011 09:09 AM, Bernd Schmidt wrote:
>> This patch was an experiment to see if we can get the same improvement
>> with modifications to IRA, making it more tolerant to over-aggressive
>> scheduling. THe idea is that if an instruction sets a
I stumbled over the following hunk in one of my pending patches
Index: gcc/tree-ssa-loop-prefetch.c
===
--- gcc/tree-ssa-loop-prefetch.c.orig 2011-10-12 13:14:10.0
+0200
+++ gcc/tree-ssa-loop-prefetch.c2012-02-23 1
On Wed, Apr 11, 2012 at 4:16 PM, Bernd Schmidt wrote:
> The order of calls to sched_rgn_init and sched_init differs between
> sched-rgn and sel-sched. This caused a scheduler patch I was working on
> to segfault once sel-sched was enabled. The following patch swaps the
> two function calls.
>
> Bo
"H.J. Lu" writes:
> Hi,
>
> CSE turns (reg:DI 64)
>
> (insn 6 3 7 2 (set (reg:DI 64)
> (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
> {*extendsidi2_rex64} (nil))
>
> into (reg/f:DI 64 [ addr ]). But nonzero_bits1 in rtlanal.c has
>
> #if defined(POINTERS_EXTEND_UNS
The order of calls to sched_rgn_init and sched_init differs between
sched-rgn and sel-sched. This caused a scheduler patch I was working on
to segfault once sel-sched was enabled. The following patch swaps the
two function calls.
Bootstrapped & tested on i686-linux. Ok?
Bernd
* sel-sched
On Wed, Apr 11, 2012 at 3:59 PM, Bernd Schmidt wrote:
> This is another problem I found working on a new target. In fold-const,
> when folding conversions, there are two instances where mode bitsizes
> are compared to type precisions. This fails to do the right thing if
> mode precision and bitsiz
On 02/10/2012 08:01 PM, Vladimir Makarov wrote:
> On 02/08/2012 10:01 AM, Bernd Schmidt wrote:
>> We found a scheduler problem while testing Coldfire targets. The
>> prune_ready_list function I introduced doesn't take SCHED_GROUPs into
>> account, which can lead to a random insn being scheduled bet
On Wed, Apr 11, 2012 at 3:38 PM, Andi Kleen wrote:
> Igor Zamyatin writes:
>
>> Hi All!
>>
>> It is known that imul placement is rather critical for Atom processors
>> and changes try to improve imul scheduling for Atom.
>>
>> This gives +5% performance on several tests from new OA 2.0 testsuite
On 04/11/2012 04:02 PM, Tristan Gingold wrote:
>
> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
>
>> I'm working on a target where intptr_t and pointers are larger than
>> size_t and ptrdiff_t. The testsuite has problems in this area, since we
>> often use the latter two types for casting fr
On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
> I'm working on a target where intptr_t and pointers are larger than
> size_t and ptrdiff_t. The testsuite has problems in this area, since we
> often use the latter two types for casting from/to pointers, leading to
> unwanted warnings. In some
This is another problem I found working on a new target. In fold-const,
when folding conversions, there are two instances where mode bitsizes
are compared to type precisions. This fails to do the right thing if
mode precision and bitsize differ (which I believe they currently don't
on any target).
I'm working on a target where intptr_t and pointers are larger than
size_t and ptrdiff_t. The testsuite has problems in this area, since we
often use the latter two types for casting from/to pointers, leading to
unwanted warnings. In some cases I've checked the corresponding PRs and
found that the
OK.
Jason
Good thought. OK.
Jason
On 04/10/2012 03:49 PM, Dodji Seketeli wrote:
Apparently, quite some places in the compiler (like the C/C++
preprocessor, the debug info machinery) expect expand_location to
resolve to locations that are in the main source file, even if the
token at stake comes from a macro that was defined in a
On 04/10/2012 03:42 PM, Dodji Seketeli wrote:
In that case, besides returning NULL, enter_macro_context sets
pfile->context->c.macro to NULL, making cpp_get_token_1 forget to set
the location of the "vari" to the expansion point of A.
This seems like a bug that should be fixed rather than worke
On Wed, 2012-04-11 at 22:10 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> >> BTW, do you have the numbers of CSiBE with this?
> >>
> >
> > Only for "-m4-single -ml -O2 -mpretend-cmove" so far.
> > Not so spectacular :T
> > I'll also do a comparison of more variants to see if something went
> > r
On 04/10/2012 10:57 AM, Dodji Seketeli wrote:
+virt_loc = *(context->c.mc->cur_virt_loc - 1);
Style nit: I'd use [-1] here. OK with that change.
Jason
On 04/10/2012 10:55 AM, Dodji Seketeli wrote:
+ if (CPP_OPTION (pfile, track_macro_expansion))
I think this should check context->tokens_kind rather than the compiler
flag.
Jason
Igor Zamyatin writes:
> Hi All!
>
> It is known that imul placement is rather critical for Atom processors
> and changes try to improve imul scheduling for Atom.
>
> This gives +5% performance on several tests from new OA 2.0 testsuite
> from EEMBC.
>
> Tested for i386 and x86-64, ok for trunk?
On Wed, Apr 11, 2012 at 3:59 AM, Dodji Seketeli wrote:
> Now that diagnostics first point to the spelling location of tokens
> coming from macro expansion, the test case
> gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
> va_args (args, some_type), the location that is record
Richard Guenther writes:
>
> 5% is not moderate. Your patch does enable unrolling at -O2 but not -O3,
> why? Why do you disable register renaming? check_imull requires a function
> comment.
>
> This completely looks like a hack for EEMBC2.0, so it's definitely not ok.
>
> -O2 is not supposed to
On Wed, Apr 11, 2012 at 3:46 AM, Dodji Seketeli wrote:
> There are various conversion related warnings that trigger on
> potentially dangerous uses of NULL (or __null). NULL is defined as a
> macro in a system header, so calling warning or warning_at on a virtual
> location of NULL yields no diag
Ping?
2012/4/5 Kai Tietz :
> Hello,
>
> this patch adds some basic folding capabilities to fold-const for
> equal and none-equal comparisons
> on integer typed argument.
>
> ChangeLog
>
> 2012-04-05 Kai Tietz
>
> * fold-const.c (fold_comparison_1): New
> function.
> (fold_c
On Wed, Apr 11, 2012 at 03:12:44PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 11, 2012 at 03:06:35PM +0200, Andi Kleen wrote:
> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> > see that in the code. I think that's really required, otherwise the
> > optimizer
> > will
On 04/11/2012 01:43 PM, Richard Guenther wrote:
> This breaks bootstrap for me:
>
> In file included from
> /space/rguenther/src/svn/trunk/gcc/java/jcf-parse.c:1009:0:
> /space/rguenther/src/svn/trunk/gcc/java/jcf-reader.c:550:1: error:
> 'int jcf_parse_bootstrap_methods(JCF*, int)' defined but not
On Wed, Apr 11, 2012 at 03:06:35PM +0200, Andi Kleen wrote:
> Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> see that in the code. I think that's really required, otherwise the optimizer
> will do the wrong thing and move memory references outside the region.
IMHO the
Oleg Endo wrote:
> The attached patch merges the SCHED_REORDER macro into the ready_reorder
> function, since the macro is used only in that function.
> Tested with 'make all-gcc'
> OK?
OK.
Regards,
kaz
Oleg Endo wrote:
> The attached patch removes the old if'ed out secondary reload code in
> sh.h.
> Tested with 'make all-gcc'
> OK?
OK.
Regards,
kaz
Oleg Endo wrote:
>> BTW, do you have the numbers of CSiBE with this?
>>
>
> Only for "-m4-single -ml -O2 -mpretend-cmove" so far.
> Not so spectacular :T
> I'll also do a comparison of more variants to see if something went
> really bad. It's a bit difficult to isolate the degradations because
> Tests passing, bootstrap in progress.
>
> Comments?
Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
see that in the code. I think that's really required, otherwise the optimizer
will do the wrong thing and move memory references outside the region.
I second Jakub in d
Dear all,
my recent patch for setting PRIVATE module variables and procedures to
TREE_PUBLIC()=0 had a flaw: I completely forgot about generic
interfaces. Even if the specific name is PRIVATE, the specific function
is still callable through the a (public) generic name.
Thanks to HJ for the r
On Wed, Apr 11, 2012 at 12:22 PM, Andrew Haley wrote:
> This adds support for the new (Version 51.0) class file format. It
> doesn't actually generate code for invokedynamic bcause we don't have
> any runtime support yet, but it's a start. jcf-dump prints all of the
> new attributes.
This break
For PR52621 we analyze a loop nest (for prefetching) and
end up with {(integer(kind=8)) {0, +, {2, +, 2}_2}_2, +, 1}_3
which we pass to various predicates in analyze_overlapping_iterations
(the loop nest has loop->num == 1, 2 and 3 are nested in it).
First, evolution_function_is_univariate_p retu
This fixes the corresponding SJLJ part of preserving loops over
EH lowering. The unfortunate thing is, of course, that factoring
the SJLJ breaks the loop structure quite badly because we create
mutliple entry loops all over the place.
Well. That's a pre-existing missed optimization.
Kai bootst
On 04/10/2012 09:37 AM, Steve McIntyre wrote:
Aargh. Again, use of a standard triplet for arm hard-float was agreed
by all parties at the Plumbers' meeting last September. For exactly
this reason. Now it seems that a number of people have totally ignored
that consensus for the last six months.
M
Hi,
On Wed, 11 Apr 2012, Richard Guenther wrote:
> > But it would possibly be an interesting experiment already to do such
> > transformation generally (without profiling) and see what it gives on
> > some benchmarks. Just to get a feel what's on the plate.
>
> The question is, of course, why
Hi,
The attached patch removes the old if'ed out secondary reload code in
sh.h.
Tested with 'make all-gcc'
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/sh.h: Remove old secondary reload code.
Index: gcc/config/sh/sh.h
===
--- g
On Wed, 2012-04-11 at 10:43 +0200, Richard Guenther wrote:
> On Tue, Apr 10, 2012 at 8:50 PM, David Edelsohn wrote:
> > On Tue, Apr 10, 2012 at 1:36 PM, Peter Bergner wrote:
> >
> >> 2012-mm-dd Peter Bergner
> >>Michael Matz
> >>
> >> gcc/
> >>PR target/16458
> >>
Hi,
The attached patch merges the SCHED_REORDER macro into the ready_reorder
function, since the macro is used only in that function.
Tested with 'make all-gcc'
OK?
Cheers,
Oleg
ChangeLog:
* config/sh/sh.c (SCHED_REORDER): Merge macro into ...
(ready_reorder): ... this
On Wed, Apr 11, 2012 at 12:51 PM, Jakub Jelinek wrote:
> What is TARGET_HLE good for? I thought the point of HLE prefixes
> is that they are silently ignored on older CPUs. So, HLE should be
> always enabled IMHO. If you don't use __ATOMIC_HLE_* bits in __atomic_*
> in your source, it won't be
1 - 100 of 129 matches
Mail list logo
