ok. thanks,
David
On Tue, Feb 21, 2012 at 8:25 PM, Ollie Wild wrote:
> The latest Crosstool builds reveal one new test failure (and fix several
> others). This patch adds the missing failure to
> x86_64-unknown-linux-gnu.xfail.
>
> 2012-02-21 Ollie Wild
>
> * testsuite-management/x86
To be integrated to google/main as well.
http://codereview.appspot.com/5687075/
The latest Crosstool builds reveal one new test failure (and fix several
others). This patch adds the missing failure to x86_64-unknown-linux-gnu.xfail.
2012-02-21 Ollie Wild
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Add
gcc.c-torture/execute/vshuf-v16qi.c failure
This is DJ's baby, let's see whether he has an alternate site?
(Google did not find me an immediate candidate.)
There is http://www.semicon.toshiba.co.jp/docs/catalog/en/mepum05005-
e_catalog.pdf
("MeP Core (MeP-c4) User’s Manual (Architecture)") but no HTML
page pointing to it, it seems.
Se
On 02/20/2012 04:10 PM, Bernd Schmidt wrote:
For C6X, I added a patch to separate out a REG_WORDS_BIG_ENDIAN macro
from WORDS_BIG_ENDIAN. Since the patch was originally for 4.5, it missed
a few new instances in IRA where we need to change which macro we use.
The following patch makes big-endian k
On Feb 21, 2012, at 10:26 AM, Ulrich Weigand wrote:
> I just noticed that check_effective_target_vect_condition returns false
> for ARM/NEON, even though the platforms in fact supports vectorized
> conditional expressions. This causes a number of tests to be skipped
> unnecessarily.
>
> Fixed by
1) No, I don't. I think I should read FAQ about this then work will be
completed =) I'm not interested in "copyrighting" this, just want to share it
with other people.
2) Probably most hard part for me, but I'll try to do this.
I've never used testsuites before, but now it's time to begin.
3) Wha
2012/2/21 Richard Henderson :
> On 02/21/12 09:08, Georg-Johann Lay wrote:
>> PR rtl-optimization/50063
>> * config/avr/avr.md (movhi_sp_r): Handle -1 (unknown IRQ state)
>> and 2 (8-bit SP) in operand 2.
>> * config/avr/avr.c (avr_prologue_setup_frame): Adjust prologue
>>
The SPARC bootstrap started to fail after recent addition of live range
splitting and trunk merge. The following patch fixes a crash of GCC on
SPARC64 bootstrap. Unfortunately, it is still not enough to fix the
bootstrap failure but I am working on it.
The patch was successfully bootstrapped
Hello,
I just noticed that check_effective_target_vect_condition returns false
for ARM/NEON, even though the platforms in fact supports vectorized
conditional expressions. This causes a number of tests to be skipped
unnecessarily.
Fixed by the following patch. Tested on arm-linux-gnueabi with
On Mon, Feb 20, 2012 at 11:31 PM, Jing Yu wrote:
> Hi H.J.,
>
> I think the patch itself is not enough.
> I compared "AC_DEFUN([gcc_AC_INITFINI_ARRAY]" part (in acinclude.m4)
> of gcc trunk and google/gcc-4_6_2-mobile, and found how
> enable_initfini_array is
> configured is different.
>
> The pat
On 02/21/12 09:08, Georg-Johann Lay wrote:
> PR rtl-optimization/50063
> * config/avr/avr.md (movhi_sp_r): Handle -1 (unknown IRQ state)
> and 2 (8-bit SP) in operand 2.
> * config/avr/avr.c (avr_prologue_setup_frame): Adjust prologue
> setup to use movhi_sp_r instead
On 21/02/12 16:28, Matthew Gretton-Dann wrote:
> The attached patch reverts revision 183011, which changed the branch
> cost heuristics for Cortex-A15.
>
> This is because further benchmarking shows that there are significant
> regressions on some benchmarks which outweigh other performance gains.
On Sun, 19 Feb 2012, Richard Sandiford wrote:
> > The i386 target does it all the time for its __x86.get_pc_thunk.?x thingys.
>
> Thanks for the pointer. Here's a patch that takes the same approach.
> There's no problem relying on comdat groups here, since MIPS16 TLS
> requires 2.22 gas and ld a
Jakub Jelinek wrote:
> On Tue, Feb 21, 2012 at 12:38:48PM +0100, Georg-Johann Lay wrote:
>> However, if all insns that are involved in SP/FP manipulation get the
>> RTX_FRAME_RELATED_P, almost every test case that has -g crashes with this
>> dwarf-ICE.
>
> My suggestion actually wasn't to use unsp
Martin Jambor wrote:
> Hi,
>
> PR 51782 showed that COMPONENT_REFs created by SRA got expanded with a
> wrong address space because the address space was not specified in the
> type of the whole tree. This is however inconsistent with how we
> encode address spaces in MEM_REFs where they are supp
2012/2/15 Georg-Johann Lay :
> Some parts outside the backend use ACCUMULATE_OUTGOING_ARGS without including
> tm_p.h which lead to a build warning because avr.h does
>
> #define ACCUMULATE_OUTGOING_ARGS avr_accumulate_outgoing_args()
>
> This patcs moved the prototype from avr-protos.h to avr.h:
>
The attached patch reverts revision 183011, which changed the branch
cost heuristics for Cortex-A15.
This is because further benchmarking shows that there are significant
regressions on some benchmarks which outweigh other performance gains.
OK?
Thanks,
Matt
gcc/ChangeLog:
2012-02-21 Matthew
2012/2/16 Georg-Johann Lay :
> neghi2's "r,0" alternative reads
>
> com %B0
> neg %A0
> sbc %B0,__zero_reg__
> inc %B0
>
> The INC commutates with the NEG+SBC and can be moved 2 instructions up:
>
> com %B0
> inc %B0
> neg %A0
> sbc %B0,__zero_reg__
>
> COM+INC can be fused to NEG:
>
> neg %B0
> ne
The attached patch fixes instruction generation for unsigned vector
comparisons against a known-zero vector.
ARM's Neon extensions only allow unsigned equality comparison against
unsigned zero, not less than or greater than comparisons.
This patch fixes code generation - there are further changes
By the way, the "compile" subset of the testsuite works for pdp11; it has some
errors which still need cleanup but a large fraction works.
paul
-Original Message-
From: Steven Bosscher [mailto:stevenb@gmail.com]
Sent: Tuesday, February 14, 2012 5:09 PM
To: Koning, Paul; GCC
Build and regtested on x86-64-linux.
OK for the 4.8 trunk?
Tobias
2012-02-21 Tobias Burnus
PR fortran/52325
* primary.c (gfc_match_varspec): Add diagnostic for % with
nonderived types.
2012-02-21 Tobias Burnus
PR fortran/52325
* gfortran.dg/derived_comp_array_ref_8.f90: New.
* gfor
On 02/21/2012 04:27 PM, Jakub Jelinek wrote:
> On Tue, Feb 21, 2012 at 04:23:16PM +0100, Andreas Krebbel wrote:
>> using the -fgnu-tm option fails for targets not supporting libitm with
>> a *link* failure. So the compile test wasn't sufficient.
>>
>> With the attached patch the following failures
PR52294 is a case where we generate a cbz instruction that ends up
trying to reach too far. The reason for this is that we calculate the
size of some instructions as being 2 bytes when in reality they take 4.
The problem in this instance is that a peephole to shorten
lsl reg, reg, reg
into
lsl
"Andreas Krebbel" writes:
> Ok for mainline?
No, this is wrong. How would gcc be able to find the uninstalled libitm.so
and libitm.spec on targets that do support it?
I'm undecided how (and where) best to fix this. One might either handle
it via something like dg-add-options tm_runtime, or co
On Tue, Feb 21, 2012 at 04:23:16PM +0100, Andreas Krebbel wrote:
> using the -fgnu-tm option fails for targets not supporting libitm with
> a *link* failure. So the compile test wasn't sufficient.
>
> With the attached patch the following failures disappear on s390 and
> s390x:
>
> FAIL: gcc.dg/
On 06/02/12 13:13, Andrew Stubbs wrote:
This patch adds DImode shift support in NEON registers/instructions.
The patch causes delays any lowering until the split2 pass, after the
register allocator has chosen whether to do the shift in NEON (VFP)
registers, or in core-registers.
The core-regist
Hi,
using the -fgnu-tm option fails for targets not supporting libitm with
a *link* failure. So the compile test wasn't sufficient.
With the attached patch the following failures disappear on s390 and
s390x:
FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link,
-flto -
Yes,
Patrick, you were faster :)
Seems, we just need to pass 0 as IMM value
On Tue, Feb 21, 2012 at 7:14 PM, Patrick Marlier
wrote:
> On 02/21/2012 02:52 AM, Uros Bizjak wrote:
>>
>> On Tue, Feb 21, 2012 at 12:26 AM, Andi Kleen wrote:
IIUC the documentation, the fallback label is a par
On Tue, Feb 21, 2012 at 2:46 AM, Jakub Jelinek wrote:
> On Tue, Feb 21, 2012 at 08:49:13AM +0100, Uros Bizjak wrote:
>> > 2012-02-20 Quentin Neill
>> >
>> > PR target/52137
>> > * gcc/config/i386/bdver1.md (bdver1_call, bdver1_push,
>
> Please leave out gcc/ prefix from the ChangeLog en
On 02/21/2012 02:52 AM, Uros Bizjak wrote:
On Tue, Feb 21, 2012 at 12:26 AM, Andi Kleen wrote:
IIUC the documentation, the fallback label is a parameter to xbegin
insn, but the insn itself doesn't jump anywhere - it just records the
From the point of view of the program XBEGIN behaves like a
On Tuesday 21 February 2012 10:19:15 Richard Guenther wrote:
> On Mon, Feb 20, 2012 at 8:55 PM, Tijl Coosemans wrote:
>> On Monday 9 January 2012 10:05:08 Richard Guenther wrote:
>>> Since GCC 4.4 applying the malloc attribute to realloc-like
>>> functions does not work under the documented constr
Hi,
with the attached patch -mhard-dfp is used whenever possible. So far
it was disabled by default for -m31 although hardware dfp is available
when also -mzarch is given.
Committed to mainline.
Bye,
-Andreas-
2012-02-21 Andreas Krebbel
* config/s390/s390.c (s390_option_override):
On Tue, Feb 21, 2012 at 3:21 PM, Jakub Jelinek wrote:
>> As far as I undersand, correct one seems like that:
>> .intel_syntax
>> xbegin $0
>> nop
>>
>> .att_syntax
>> xbegin ($0)
>> nop
>>
>> Which disassembles into:
>> <.text>:
>> 0: c7 f8 00
On Tue, Feb 21, 2012 at 06:11:54PM +0400, Kirill Yukhin wrote:
> As far as I undersand, correct one seems like that:
> .intel_syntax
> xbegin $0
> nop
>
> .att_syntax
> xbegin ($0)
> nop
>
> Which disassembles into:
> <.text>:
>0: c7 f8 00 00
On 21/02/12 05:39, Barracuda wrote:
> Hello!
> I'm new to GCC internals, but I'm using GCC for couple of years.
> Yesterday I found that GCC does not support calling SWI routines from C/C++
> code.
> For example, in other ARM-targeted compiliers developer can use such syntax
> for function prototyp
As far as I undersand, correct one seems like that:
.intel_syntax
xbegin $0
nop
.att_syntax
xbegin ($0)
nop
Which disassembles into:
<.text>:
0: c7 f8 00 00 00 00 xbeginq 0x6
6: 90 nop
7: c7 f8 00 00 00 00
On Tue, 21 Feb 2012, Jakub Jelinek wrote:
> On Tue, Feb 21, 2012 at 03:06:40PM +0100, Richard Guenther wrote:
> >
> > The gimplifier, when forcing a value to a temporary, uses the
> > type of the value for that temporary variable, making it for
> > example volatile or const, or puts it in a diffe
On Tue, Feb 21, 2012 at 03:06:40PM +0100, Richard Guenther wrote:
>
> The gimplifier, when forcing a value to a temporary, uses the
> type of the value for that temporary variable, making it for
> example volatile or const, or puts it in a different address-space
> even. That's odd and not requir
The gimplifier, when forcing a value to a temporary, uses the
type of the value for that temporary variable, making it for
example volatile or const, or puts it in a different address-space
even. That's odd and not required, we can decay to the main-variant type.
Bootstrapped and tested on x86_6
Hi,
PR 51782 showed that COMPONENT_REFs created by SRA got expanded with a
wrong address space because the address space was not specified in the
type of the whole tree. This is however inconsistent with how we
encode address spaces in MEM_REFs where they are supposed to be stored
in the type of
On Tue, Feb 21, 2012 at 04:30:01PM +0400, Kirill Yukhin wrote:
> I've played ".+6" and it seems to be working, although I'd rather
> prefer "$0" much better, since it is not deal with insn+ops length.
> Will prepare updated patch later today
xbegin $0
seems to work only for Intel syntax, not AT&T.
When PRE inserts stmts it re-gimplifies them. This causes spurious
TREE_ADDRESSABLE bits to be set on decls as the testcase shows.
It's not easy to fix with the recursive nature of the gimplifier,
and generally we cannot rely on the gimplifier predicates to
properly tell us whether we need to do
Hi guys,
I've played ".+6" and it seems to be working, although I'd rather
prefer "$0" much better, since it is not deal with insn+ops length.
Will prepare updated patch later today
K
On Tue, Feb 21, 2012 at 12:02 PM, Andi Kleen wrote:
>> BTW: Looking a bit more to the spec, we can simply write
http://gcc.gnu.org/viewcvs?view=revision&revision=184434
testsuite/
PR middle-end/51782
* gcc.target/avr/torture/pr51782-1.c: New test.
On Tue, Feb 21, 2012 at 12:38:48PM +0100, Georg-Johann Lay wrote:
> However, if all insns that are involved in SP/FP manipulation get the
> RTX_FRAME_RELATED_P, almost every test case that has -g crashes with this
> dwarf-ICE.
My suggestion actually wasn't to use unspec for reading from sp, but in
This is a tentative patch to the PR. As Jakub explained, GCC does not support
configurations with FP = SP and DSE optimizer generates wrong code for AVR.
This patch implements Jakub's proposal to hack around by hiding the action of
setting/moving between SP and SP into UNSPEC[_VOLATILE]s.
All wor
Hi,
the attached patch fixes several dfp testsuite fails with -march=z196
-m31:
Running target unix
FAIL: c-c++-common/dfp/convert-int-max.c -std=gnu++98 (internal compiler error)
FAIL: c-c++-common/dfp/convert-int-max.c -std=gnu++98 (test for excess errors)
WARNING: c-c++-common/dfp/convert-int-
Hi,
committed mainline and 4_6-branch.
Thanks,
Paolo.
///
2012-02-21 Paolo Carlini
PR libstdc++/52317
* python/Makefile.am: Update boilerplate license text to GPLv3.
* include/profile/unordered_map: Likewise.
* include/profile/set: Likewise.
2012/2/21 Richard Guenther :
> On Mon, Feb 20, 2012 at 11:59 PM, Kai Tietz wrote:
>> Hi,
>>
>> this patch replaces use of "llx" for printf/scanf by inttypes.h
>> PRIxMAX/SCNxMAX macros. If those macros aren't present it defines
>> them as default to "llx".
>
> Bootstrapped and tested on ... ?
>
>
Hello,
Here is a patch to enable __ANDROID__ macro on x86 Android targets.
Currently it is enabled for ARM only. OK for google/gcc-4_6_2-mobile
branch?
Thanks
Ilya
--
2012-02-21 Enkovich Ilya
* gcc/config/i386/linux.h (TARGET_OS_CPP_BUILTINS): Add
ANDROID_TARGET_OS_CPP_BUILTI
Hello,
Here is a ptch which enables exceptions and RTTI by default for
android targets like it is done in current NDK GCC 4.4.3 compiler. OK
for google/gcc-4_6_2-mobile branch.
Thanks,
Ilya
--
2012-02-21 Enkovich Ilya
* gcc/config/linux-android.h (ANDROID_CC1PLUS_SPEC): Enable
Hello,
Here is a patch which enables stack protector feature for Android
targets. OK for google/gcc-4_6_2-mobile branch?
Thanks,
Ilya
--
2012-02-21 Enkovich Ilya
* gcc/configure.ac : Enable stack protector for
Android target.
* gcc/configure : Regenerated.
Index: gc
On Mon, 20 Feb 2012, Jakub Jelinek wrote:
> On Mon, Feb 20, 2012 at 04:11:13PM +0100, Richard Guenther wrote:
> > This fixes PR52298, we need to use the proper DR step for outer
> > loop vectorization.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> Thanks.
>
On 20/02/12 17:51, Bernd Schmidt wrote:
> On 02/20/2012 06:39 PM, Richard Earnshaw wrote:
>> I'm not sure why it should be. Can't a user write
>>
>> #ifdef __cplusplus
>> #define BOOL bool
>> #else
>> #define bool _Bool
>> #endif
>>
>> struct x {
>> volatile BOOL a : 1;
>> volatile BOOL b : 1;
Hello,
Here is a patch which adds -mandroid option support to x86 target. OK
for google/gcc-4_6_2-mobile branch?
Thanks,
Ilya
--
2012-02-21 Enkovich Ilya
* config/i386/linux.h (LINUX_TARGET_CC1_SPEC): New.
(CC1_SPEC): Use LINUX_OR_ANDROID_CC.
(CC1PLUS_SPEC): Likewise.
On Mon, Feb 20, 2012 at 11:59 PM, Kai Tietz wrote:
> Hi,
>
> this patch replaces use of "llx" for printf/scanf by inttypes.h
> PRIxMAX/SCNxMAX macros. If those macros aren't present it defines
> them as default to "llx".
Bootstrapped and tested on ... ?
Ok.
Thanks,
Richard.
> ChangeLog
>
> 20
On Mon, Feb 20, 2012 at 9:59 PM, Richard Henderson wrote:
> On 02/20/12 12:14, Kai Tietz wrote:
>> 2012-02-20 Kai Tietz
>>
>> PR libstdc++/52300
>> * gthr.h (GTHREAD_USE_WEAK): Define as zero for mingw.
>
> Ok.
It looks like this belongs in some config/gthr-mingw.h file instead,
On Mon, Feb 20, 2012 at 8:55 PM, Tijl Coosemans wrote:
> On Monday 9 January 2012 10:05:08 Richard Guenther wrote:
>> Since GCC 4.4 applying the malloc attribute to realloc-like
>> functions does not work under the documented constraints because
>> the contents of the memory pointed to are not pro
Hi,
tiny patch to fix the padding of the identification string. Now left padded,
which is more natural for humans.
Committed on trunk.
Tristan.
2012-02-21 Tristan Gingold
* config/vms/vms-ld.c (main): Fix IDENTIFICATION padding.
Index: gcc/config/vms/vms-ld.c
=
On Tue, 21 Feb 2012, Jakub Jelinek wrote:
> Hi!
>
> This function spends significant amount of code to update the virtual
> uses/defs in the new sequence, but only handles that way stores, not
> non-pure/const calls, so we ICE during tree DSE on this testcase, because
> vop has been marked for re
On Tue, Feb 21, 2012 at 08:49:13AM +0100, Uros Bizjak wrote:
> > 2012-02-20 Quentin Neill
> >
> > PR target/52137
> > * gcc/config/i386/bdver1.md (bdver1_call, bdver1_push,
Please leave out gcc/ prefix from the ChangeLog entry though.
Jakub
> BTW: Looking a bit more to the spec, we can simply write
>
> xbegin $0
>
> as the spec says that offset is relative to the _NEXT_ instruction
Yes that's true. I'm not sure the .+6 even results in 0. Kirill?
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
63 matches
Mail list logo
