Re: [Patch, MIPS] Add Octeon3 support

2014-10-30 Thread Hurugalawadi, Naveen
Hi,

Thanks for the review and your comments.

>> Is it intentional that you have not updated driver-native.c to
>> detect an Octeon 3 CPU?

We have not yet looked into that part yet and will be looking at it later.

>> Could you confirm what testing the patch has had?

Run the regression in build folder of gcc using make-check.
The compilation results are good.
Also we have been using the octeon3 patches in cavium toolchain from sometime
without any issues.

Thanks,
Naveen

Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I

2014-10-30 Thread Dominik Vogt
On Wed, Oct 29, 2014 at 10:16:40AM -0700, Ian Taylor wrote:
> Thanks.  Part of the problem is that the m68k max alignment is 16
> bits, but the godump test expects it to be at least 64 bits.  This is
> BIGGEST_ALIGNMENT in config/m68k/m68k.h.  Another part of the problem
> seems to be that structs are sometimes aligned to 16 bits although
> there is no obvious reason for that.  I'm not sure where that is
> coming from.

Hm, the test cases make assumptions about the Abi (structure
padding and alignment) that are true on x86, x64_64 and s390[x].
That may not be the case on other platforms and hence the tests
fail.  Another candidate for test failures is the effect of
bitfields (named or anonymous) on structure layout.

> We could disable the test on m68k or make it more accepting.

Since the point of some of the tests is to make sure that the Go
structure layout matches the C layout, making the tests accept
deviations seems to be rather pointless.  It's possible to add
target selectors to all the "scan-file" lines, but that is a lot
of work and will likely become unmaintainable very soon when more
platforms need to be added.  Personally I cannot provide fixed
tests for all the Abis either, so my suggestion is to "xfail" the
test on all targets except s390[x] and x86_64 and leave it to the
people who know the other platforms to decide whether the test
should work there or how the test could be modified to work.

See attached patch.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
>From fc92faa8532e3ea0ac3b4c8b18eb6b0a3ee862dc Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Thu, 30 Oct 2014 07:50:18 +0100
Subject: [PATCH] Xfail -fdump-go-spec tests for all platforms except s390[x]
 and x86_64.

---
 gcc/testsuite/gcc.misc-tests/godump-1.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.misc-tests/godump-1.c b/gcc/testsuite/gcc.misc-tests/godump-1.c
index f339cc9..91b8637 100644
--- a/gcc/testsuite/gcc.misc-tests/godump-1.c
+++ b/gcc/testsuite/gcc.misc-tests/godump-1.c
@@ -2,6 +2,7 @@
 
 /* { dg-options "-c -fdump-go-spec=godump-1.out" } */
 /* { dg-do compile } */
+/* { dg-xfail-if "not supported for target" { ! "s390*-*-* x86_64-*-*" } } */
 
 #include 
 
-- 
1.8.4.2



Re: [PATCH] Adjust/remove REG_EQ{UAL,UIV} notes in REE (PR rtl-optimization/63659)

2014-10-30 Thread Jakub Jelinek
On Wed, Oct 29, 2014 at 09:47:33PM -0600, Jeff Law wrote:
> On 10/27/14 14:47, Jakub Jelinek wrote:
> >Hi!
> >
> >The following testcase is miscompiled in 4.8+ on x86_64 at -O2+,
> >because REE widens for ZERO_EXTEND mode on
> >(set (reg:QI ax) (const_int -1)) instruction to SImode, but doesn't
> >adjust REG_EQUAL note of (const_int -1) also to (const_int 0xff)
> >like it changes the pattern.
> >
> >The following patch attempts to adjust the notes if they are CONST_INT,
> >or drop otherwise (not sure if it would be desirable to emit
> >a ZERO_EXTEND of the previous content of the note), and both through
> >validate_change, so that if we give up later on, it is undone.
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >What about 4.9.2 (after release) and 4.8.x?
> >
> >2014-10-27  Jakub Jelinek  
> >
> > PR rtl-optimization/63659
> > * ree.c (update_reg_equal_equiv_notes): New function.
> > (combine_set_extension, transform_ifelse): Use it.
> >
> > * gcc.c-torture/execute/pr63659.c: New test.
> Does this do the right thing in the case where there's multiple reaching
> definitions and one of those reaching definitions turns out to be
> non-combinable, while some other has a fixable REG_EQUAL note?

The changes to REG_EQUAL or REG_EQUIV notes (either adjustment of CONST_INT
in it, or its removal) is tied to the changing of the insn holding it
in the patch.  So, if we revert the changes to the instruction, so it is
again the original mode, we revert the changes to the notes too (either put
back the old CONST_INT, or re-add the note).
The granularity of changes in REE is combine_reaching_defs - each cand
separately, if any insn needed to be changed for some cand fails to be
changed, we revert all the changes for the cand in question (it is not
possible to have only a subset of setters adjusted if we want to adjust
the user(s)).  So IMHO the right thing is what the patch does, tie it to
the apply_change_group/cancel_changes that verifies or undoes the insn
changes.

> Don't we have to separate the check for a fixable note from the actual
> changing of the note?

Jakub


[PATCH] x86: extend vect-args testcase to AVX flavors

2014-10-30 Thread Jan Beulich
gcc/testsuite:
2014-10-30  Jan Beulich  

* gcc.target/i386/i386.exp: Extend option set to test
vect-args.c with to include -mavx, -mavx2, and -mavx512f.
* gcc.target/i386/vect-args.c: Add AVX* modes and tests.

--- a/gcc/testsuite/gcc.target/i386/i386.exp
+++ b/gcc/testsuite/gcc.target/i386/i386.exp
@@ -318,9 +318,9 @@ clearcap-init
 
 global runtests
 # Special case compilation of vect-args.c so we don't have to
-# replicate it 10 times.
+# replicate it 16 times.
 if [runtest_file_p $runtests $srcdir/$subdir/vect-args.c] {
-  foreach type { "" -mmmx -m3dnow -msse -msse2 } {
+  foreach type { "" -mmmx -m3dnow -msse -msse2 -mavx -mavx2 -mavx512f } {
 foreach level { "" -O } {
   set flags "$type $level"
   verbose -log "Testing vect-args, $flags" 1
--- a/gcc/testsuite/gcc.target/i386/vect-args.c
+++ b/gcc/testsuite/gcc.target/i386/vect-args.c
@@ -1,6 +1,22 @@
 /* { dg-do compile } */
 /* { dg-options "-w -Wno-psabi" } */
 
+/* AVX512F and AVX512BW modes.  */
+typedef unsigned char V64QImode __attribute__((vector_size(64)));
+typedef unsigned short V32HImode __attribute__((vector_size(64)));
+typedef unsigned int V16SImode __attribute__((vector_size(64)));
+typedef unsigned long long V8DImode __attribute__((vector_size(64)));
+typedef float V16SFmode __attribute__((vector_size(64)));
+typedef double V8DFmode __attribute__((vector_size(64)));
+
+/* AVX and AVX2 modes.  */
+typedef unsigned char V32QImode __attribute__((vector_size(32)));
+typedef unsigned short V16HImode __attribute__((vector_size(32)));
+typedef unsigned int V8SImode __attribute__((vector_size(32)));
+typedef unsigned long long V4DImode __attribute__((vector_size(32)));
+typedef float V8SFmode __attribute__((vector_size(32)));
+typedef double V4DFmode __attribute__((vector_size(32)));
+
 /* SSE1 and SSE2 modes.  */
 typedef unsigned char V16QImode __attribute__((vector_size(16)));
 typedef unsigned short V8HImode __attribute__((vector_size(16)));
@@ -21,12 +37,27 @@ extern TYPE data_##TYPE;\
 void r_##TYPE (TYPE x) { data_##TYPE = x; }\
 void s_##TYPE (void) { r_##TYPE (data_##TYPE); }
 
+TEST(V64QImode)
+TEST(V32HImode)
+TEST(V16SImode)
+TEST(V8DImode)
+TEST(V16SFmode)
+TEST(V8DFmode)
+
+TEST(V32QImode)
+TEST(V16HImode)
+TEST(V8SImode)
+TEST(V4DImode)
+TEST(V8SFmode)
+TEST(V4DFmode)
+
 TEST(V16QImode)
 TEST(V8HImode)
 TEST(V4SImode)
 TEST(V2DImode)
 TEST(V4SFmode)
 TEST(V2DFmode)
+
 TEST(V8QImode)
 TEST(V4HImode)
 TEST(V2SImode)



x86: extend vect-args testcase to AVX flavors

gcc/testsuite:
2014-10-30  Jan Beulich  

* gcc.target/i386/i386.exp: Extend option set to test
vect-args.c with to include -mavx, -mavx2, and -mavx512f.
* gcc.target/i386/vect-args.c: Add AVX* modes and tests.

--- a/gcc/testsuite/gcc.target/i386/i386.exp
+++ b/gcc/testsuite/gcc.target/i386/i386.exp
@@ -318,9 +318,9 @@ clearcap-init
 
 global runtests
 # Special case compilation of vect-args.c so we don't have to
-# replicate it 10 times.
+# replicate it 16 times.
 if [runtest_file_p $runtests $srcdir/$subdir/vect-args.c] {
-  foreach type { "" -mmmx -m3dnow -msse -msse2 } {
+  foreach type { "" -mmmx -m3dnow -msse -msse2 -mavx -mavx2 -mavx512f } {
 foreach level { "" -O } {
   set flags "$type $level"
   verbose -log "Testing vect-args, $flags" 1
--- a/gcc/testsuite/gcc.target/i386/vect-args.c
+++ b/gcc/testsuite/gcc.target/i386/vect-args.c
@@ -1,6 +1,22 @@
 /* { dg-do compile } */
 /* { dg-options "-w -Wno-psabi" } */
 
+/* AVX512F and AVX512BW modes.  */
+typedef unsigned char V64QImode __attribute__((vector_size(64)));
+typedef unsigned short V32HImode __attribute__((vector_size(64)));
+typedef unsigned int V16SImode __attribute__((vector_size(64)));
+typedef unsigned long long V8DImode __attribute__((vector_size(64)));
+typedef float V16SFmode __attribute__((vector_size(64)));
+typedef double V8DFmode __attribute__((vector_size(64)));
+
+/* AVX and AVX2 modes.  */
+typedef unsigned char V32QImode __attribute__((vector_size(32)));
+typedef unsigned short V16HImode __attribute__((vector_size(32)));
+typedef unsigned int V8SImode __attribute__((vector_size(32)));
+typedef unsigned long long V4DImode __attribute__((vector_size(32)));
+typedef float V8SFmode __attribute__((vector_size(32)));
+typedef double V4DFmode __attribute__((vector_size(32)));
+
 /* SSE1 and SSE2 modes.  */
 typedef unsigned char V16QImode __attribute__((vector_size(16)));
 typedef unsigned short V8HImode __attribute__((vector_size(16)));
@@ -21,12 +37,27 @@ extern TYPE data_##TYPE;\
 void r_##TYPE (TYPE x) { data_##TYPE = x; }\
 void s_##TYPE (void) { r_##TYPE (data_##TYPE); }
 
+TEST(V64QImode)
+TEST(V32HImode)
+TEST(V16SImode)
+TEST(V8DImode)
+TEST(V16SFmode)
+TEST(V8DFmode)
+
+TEST(V32QImode)
+TEST(V16HImode)
+TEST(V8SImode)
+TEST(V4DImode)
+TEST(V8SFmode)
+TEST(V4DFmode)
+
 TEST(V16QImode)
 TEST(V8HImode)
 TEST(V4SImode)
 TEST(V2DImode)
 

Re: [PATCH x86] Increase PARAM_MAX_COMPLETELY_PEELED_INSNS when branch is costly

2014-10-30 Thread Uros Bizjak
On Tue, Oct 28, 2014 at 1:07 PM, Evgeny Stupachenko  wrote:
> make check for gcc passed
>
> On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko  
> wrote:
>> The results are the same for Silvermont.
>> There are no significant changes on Haswell.
>> So I agree with Richard, let's enable this x86 wide.
>>
>> Bootstrap/ passed.
>> Make check in progress.
>> Is it ok?
>>
>> 2014-10-25  Evgeny Stupachenko  
>> * config/i386/i386.c (ix86_option_override_internal): Increase
>> PARAM_MAX_COMPLETELY_PEELED_INSNS.

Let's wait for Honza's approval ...

Uros.


Re: [Ping ^ 3] [PATCH] Fix PR 61225

2014-10-30 Thread Uros Bizjak
Hello!

> Ping?
>
>Thanks!
> -Zhenqiang

> On 9 June 2014 17:08, Zhenqiang Chen  wrote:
> Ping ^2?
>
> Thanks!
> -Zhenqiang
>
> On 28 May 2014 15:02, Zhenqiang Chen  wrote:
>> Ping?
>>
>> Thanks!
>> -Zhenqiang
>>
>> On 22 May 2014 17:52, Zhenqiang Chen  wrote:
>>> On 21 May 2014 20:43, Steven Bosscher  wrote:
 On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
> Hi,
>
> The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
> test case tends to check a peephole2 optimization, which optimizes the
> following sequence
>
> 2: bx:SI=ax:SI
> 25: ax:SI=[bx:SI]
> 7: {ax:SI=ax:SI-0x1;clobber flags:CC;}
> 8: [bx:SI]=ax:SI
> 9: flags:CCZ=cmp(ax:SI,0)
> to
>2: bx:SI=ax:SI
>41: {flags:CCZ=cmp([bx:SI]-0x1,0);[bx:SI]=[bx:SI]-0x1;}
>
> The enhanced shrink-wrapping, which calls copyprop_hardreg_forward
> changes the INSN 25 to
>
> 25: ax:SI=[ax:SI]
>
> Then peephole2 can not optimize it since two memory_operands look like
> different.
>
> To fix it, the patch adds another peephole2 rule to read one more
> insn. From the register copy, it knows the address is the same.

 That is one complex peephole2 to deal with a transformation like this.
 It seems to be like it's a too specific solution for a bigger problem.

 Could you please try one of the following solutions instead:

 1. Track register values for peephole2 and try different alternatives
 based on known register equivalences? E.g. in your example, perhaps
 there is already a REG_EQUAL/REG_EQUIV note available on insn 25 after
 copyprop_hardreg_forward, to annotate that [ax:SI] is equivalent to
 [bx:SI] at that point (or if that information is not available, it is
 not very difficult to make it available). Then you could try applying
 peephole2 on the original pattern but also on patterns modified with
 the known equivalences (i.e. try peephole2 on multiple equivalent
 patterns for the same insn). This may expose other peephole2
 opportunities, not just the specific one your patch addresses.
>>>
>>> Patch is updated according to the comment. There is no REG_EQUAL. So I
>>> add it when replace_oldest_value_reg.
>>>
>>> ChangeLog:
>>> 2014-05-22  Zhenqiang Chen  
>>>
>>> Part of PR rtl-optimization/61225
>>> * config/i386/i386-protos.h (ix86_peephole2_rtx_equal_p): New proto.
>>> * config/i386/i386.c (ix86_peephole2_rtx_equal_p): New function.
>>> * regcprop.c (replace_oldest_value_reg): Add REG_EQUAL note when
>>> propagating to SET.
>>>
>>> diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
>>> index 39462bd..0c4a2b9 100644
>>> --- a/gcc/config/i386/i386-protos.h
>>> +++ b/gcc/config/i386/i386-protos.h
>>> @@ -42,6 +42,7 @@ extern enum calling_abi ix86_function_type_abi 
>>> (const_tree);
>>>
>>>  extern void ix86_reset_previous_fndecl (void);
>>>
>>> +extern bool ix86_peephole2_rtx_equal_p (rtx, rtx, rtx, rtx);
>>>  #ifdef RTX_CODE
>>>  extern int standard_80387_constant_p (rtx);
>>>  extern const char *standard_80387_constant_opcode (rtx);
>>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>>> index 6ffb788..583ebe8 100644
>>> --- a/gcc/config/i386/i386.c
>>> +++ b/gcc/config/i386/i386.c
>>> @@ -46856,6 +46856,29 @@ ix86_atomic_assign_expand_fenv (tree *hold,
>>> tree *clear, tree *update)
>>> atomic_feraiseexcept_call);
>>>  }
>>>
>>> +/* OP0 is the SET_DEST of INSN and OP1 is the SET_SRC of INSN.
>>> +   Check whether OP1 and OP6 is equal.  */
>>> +
>>> +bool
>>> +ix86_peephole2_rtx_equal_p (rtx insn, rtx op0, rtx op1, rtx op6)
>>> +{
>>> +  rtx note;
>>> +
>>> +  if (!reg_overlap_mentioned_p (op0, op1) && rtx_equal_p (op1, op6))
>>> +return true;
>>> +
>>> +  gcc_assert (single_set (insn)
>>> + && op0 == SET_DEST (single_set (insn))
>>> + && op1 == SET_SRC (single_set (insn)));
>>> +
>>> +  note = find_reg_note (insn, REG_EQUAL, NULL_RTX);
>>> +  if (note
>>> +  && !reg_overlap_mentioned_p (op0, XEXP (note, 0))
>>> +  && rtx_equal_p (XEXP (note, 0), op6))
>>> +return true;
>>> +
>>> +  return false;
>>> +}
>>>  /* Initialize the GCC target structure.  */
>>>  #undef TARGET_RETURN_IN_MEMORY
>>>  #define TARGET_RETURN_IN_MEMORY ix86_return_in_memory
>>> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
>>> index 44e80ec..b57fc86 100644
>>> --- a/gcc/config/i386/i386.md
>>> +++ b/gcc/config/i386/i386.md
>>> @@ -16996,11 +16996,12 @@
>>>  [(match_dup 0)
>>>   (match_operand:SWI 2 "")]))
>>>   (clobber (reg:CC FLAGS_REG))])
>>> -   (set (match_dup 1) (match_dup 0))
>>> +   (set (match_operand:SWI 6 "memory_operand") (match_dup 0))
>>> (set (reg FLAGS_REG) (compare (match_dup 0) (const_int 0)))]
>>>"(TARGET_READ_MODIFY_WRITE || optimize_insn_for_siz

Re: [PATCH] x86: extend vect-args testcase to AVX flavors

2014-10-30 Thread Uros Bizjak
On Thu, Oct 30, 2014 at 8:50 AM, Jan Beulich  wrote:
> gcc/testsuite:
> 2014-10-30  Jan Beulich  
>
> * gcc.target/i386/i386.exp: Extend option set to test
> vect-args.c with to include -mavx, -mavx2, and -mavx512f.
> * gcc.target/i386/vect-args.c: Add AVX* modes and tests.

OK, but let's also wait for Kirill's opinion.

Thanks,
Uros.

> --- a/gcc/testsuite/gcc.target/i386/i386.exp
> +++ b/gcc/testsuite/gcc.target/i386/i386.exp
> @@ -318,9 +318,9 @@ clearcap-init
>
>  global runtests
>  # Special case compilation of vect-args.c so we don't have to
> -# replicate it 10 times.
> +# replicate it 16 times.
>  if [runtest_file_p $runtests $srcdir/$subdir/vect-args.c] {
> -  foreach type { "" -mmmx -m3dnow -msse -msse2 } {
> +  foreach type { "" -mmmx -m3dnow -msse -msse2 -mavx -mavx2 -mavx512f } {
>  foreach level { "" -O } {
>set flags "$type $level"
>verbose -log "Testing vect-args, $flags" 1
> --- a/gcc/testsuite/gcc.target/i386/vect-args.c
> +++ b/gcc/testsuite/gcc.target/i386/vect-args.c
> @@ -1,6 +1,22 @@
>  /* { dg-do compile } */
>  /* { dg-options "-w -Wno-psabi" } */
>
> +/* AVX512F and AVX512BW modes.  */
> +typedef unsigned char V64QImode __attribute__((vector_size(64)));
> +typedef unsigned short V32HImode __attribute__((vector_size(64)));
> +typedef unsigned int V16SImode __attribute__((vector_size(64)));
> +typedef unsigned long long V8DImode __attribute__((vector_size(64)));
> +typedef float V16SFmode __attribute__((vector_size(64)));
> +typedef double V8DFmode __attribute__((vector_size(64)));
> +
> +/* AVX and AVX2 modes.  */
> +typedef unsigned char V32QImode __attribute__((vector_size(32)));
> +typedef unsigned short V16HImode __attribute__((vector_size(32)));
> +typedef unsigned int V8SImode __attribute__((vector_size(32)));
> +typedef unsigned long long V4DImode __attribute__((vector_size(32)));
> +typedef float V8SFmode __attribute__((vector_size(32)));
> +typedef double V4DFmode __attribute__((vector_size(32)));
> +
>  /* SSE1 and SSE2 modes.  */
>  typedef unsigned char V16QImode __attribute__((vector_size(16)));
>  typedef unsigned short V8HImode __attribute__((vector_size(16)));
> @@ -21,12 +37,27 @@ extern TYPE data_##TYPE;\
>  void r_##TYPE (TYPE x) { data_##TYPE = x; }\
>  void s_##TYPE (void) { r_##TYPE (data_##TYPE); }
>
> +TEST(V64QImode)
> +TEST(V32HImode)
> +TEST(V16SImode)
> +TEST(V8DImode)
> +TEST(V16SFmode)
> +TEST(V8DFmode)
> +
> +TEST(V32QImode)
> +TEST(V16HImode)
> +TEST(V8SImode)
> +TEST(V4DImode)
> +TEST(V8SFmode)
> +TEST(V4DFmode)
> +
>  TEST(V16QImode)
>  TEST(V8HImode)
>  TEST(V4SImode)
>  TEST(V2DImode)
>  TEST(V4SFmode)
>  TEST(V2DFmode)
> +
>  TEST(V8QImode)
>  TEST(V4HImode)
>  TEST(V2SImode)
>
>
>


Re: [PATCH 5/5] add libcc1

2014-10-30 Thread Thomas Schwinge
Hi!

On Tue, 28 Oct 2014 13:23:50 +0100, Jakub Jelinek  wrote:
> On Tue, Oct 28, 2014 at 11:47:31AM +, Phil Muldoon wrote:
> > I think I have a solution.  Though my automake fu is very weak.  Does
> > this patch work for you?  I'm really not sure how to deal with the
> > three possible versions of libiberty any other way.
> 
> That is insufficient,
> a) you don't filter away -fsanitize=address, which would make it
> unusable in gdb
> b) without the -Wc, stuff, you get the ugly libtool warnings
> c) the LTLDFLAGS mess is needed for libtool not eating the -Wc, stuff

> So I'm proposing my patch (which is modeled after lto-plugin changes by
> myself and others), [...]

(Maybe we should now turn that into generic infrastructure?)

> 2014-10-28  Jakub Jelinek  
> 
>   * Makefile.am (CXXFLAGS, LDFLAGS): Filter out -fsanitize=address.
>   (libiberty_normal, libiberty_noasan, libiberty_pic, libiberty_dep):
>   New variables.
>   (libiberty): Set to -Wc, followed by the first existing noasan/,
>   pic/ or . libiberty.a.
>   (libcc1plugin_la_DEPENDENCIES, libcc1plugin_la_LINK,
>   libcc1_la_DEPENDENCIES, libcc1_la_LINK, LTLDFLAGS): New variables.
>   * Makefile.in: Regenerated.

;-) To re-use your words: »That is insufficient«, d) in a configuration
where there is no lto-plugin built, we now try to link the shared libcc1
against a static libiberty:

/bin/bash ./libtool --tag=CXX   --mode=link g++ -m64 [...] -module 
-export-symbols [...]/source-gcc/libcc1/libcc1.sym  -Xcompiler 
'-static-libstdc++' -Xcompiler '-static-libgcc' -o libcc1.la -rpath 
/lib/../lib64 findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo 
marshall.lo   -Wc,../libiberty/libiberty.a 
libtool: link: g++ -m64 [...] -shared -nostdlib [...]/crti.o 
[...]/crtbeginS.o  .libs/findcomp.o .libs/libcc1.o .libs/names.o 
.libs/callbacks.o .libs/connection.o .libs/marshall.o [...] -lstdc++ -lm -lc 
-lgcc_s [...]/crtendS.o [...]/crtn.o  -m64 [...] -static-libstdc++ 
-static-libgcc ../libiberty/libiberty.a   -Wl,-soname -Wl,libcc1.so.0 
-Wl,-retain-symbols-file -Wl,[...]/source-gcc/libcc1/libcc1.sym -o 
.libs/libcc1.so.0.0.0
[...]/ld: ../libiberty/libiberty.a(regex.o): relocation R_X86_64_32S 
against `.rodata' can not be used when making a shared object; recompile with 
-fPIC
../libiberty/libiberty.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[3]: *** [libcc1.la] Error 1
make[3]: Leaving directory `[...]/build-gcc/libcc1'
make[2]: *** [all] Error 2
make[2]: Leaving directory `[...]/build-gcc/libcc1'
make[1]: *** [all-libcc1] Error 2
make[1]: Leaving directory `[...]/build-gcc'
make: *** [all] Error 2

Here is a patch that I'm testing; OK?  I didn't understand what the
conditions are that libcc1 might not be built as a shared library: is it
always built as one -- but is that really supported on all systems?  If
that's indeed true, then this could be further simplified, and
--enable-shared passed to the host libiberty unconditionally.

--- configure.ac
+++ configure.ac
@@ -1865,7 +1865,6 @@ if test -d ${srcdir}/gcc; then
   new_enable_languages=,c,
 
   # If LTO is enabled, add the LTO front end.
-  extra_host_libiberty_configure_flags=
   if test "$enable_lto" = "yes" ; then
 case ,${enable_languages}, in
   *,lto,*) ;;
@@ -1873,10 +1872,8 @@ if test -d ${srcdir}/gcc; then
 esac
 if test "${build_lto_plugin}" = "yes" ; then
   configdirs="$configdirs lto-plugin"
-  extra_host_libiberty_configure_flags=--enable-shared
 fi
   fi
-  AC_SUBST(extra_host_libiberty_configure_flags)
 
   missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e 
s/,c,/,/ `
   potential_languages=,c,
@@ -2190,6 +2187,17 @@ then
   esac
 fi
 
+# Sometimes we have special requirements for the host libiberty.
+extra_host_libiberty_configure_flags=
+case " $configdirs " in
+  *" lto-plugin "* | *" libcc1 "*)
+# When these are to be built as shared libraries, the same applies to
+# libiberty.
+extra_host_libiberty_configure_flags=--enable-shared
+;;
+esac
+AC_SUBST(extra_host_libiberty_configure_flags)
+
 # Produce a warning message for the subdirs we can't configure.
 # This isn't especially interesting in the Cygnus tree, but in the individual
 # FSF releases, it's important to let people know when their machine isn't


Grüße,
 Thomas


pgpGV3unSIXFJ.pgp
Description: PGP signature


Re: libcc1

2014-10-30 Thread Paolo Bonzini


On 10/29/2014 09:10 PM, Jakub Jelinek wrote:
> On Wed, Oct 29, 2014 at 11:45:51AM +0100, Jakub Jelinek wrote:
>> On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
>>> On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
 shouldn't libcc1 be in build_tools instead?
 I mean, it is a library meant to be dlopened by gdb and gcc
 plugin that uses that library, so in canadian-cross should be
 for the build target, where the resulting compiler will be run
 and where gdb will be run.
>>>
>>> That is host, not build.  Build is the system you are on.
>>
>> Oops, sorry, mixed that, sure, it should be host tool then.
>>
>> So without the first two hunks and third hunk changed so that it
>> doesn't bootstrap it?  Doesn't that mean that when bootstrapping
>> natively it will be built by the system compiler rather than the
>> newly built compiler?  I think fixincludes is only built during
>> stage1 normally, we don't need libcc1 during stage1/stage2 unless
>> not bootstrapping, it is needed just for installation and testing.
>>
>> --- configure.ac 2014-10-28 14:39:53.018852391 +0100
>> +++ configure.ac 2014-10-29 11:43:19.873216226 +0100
>> @@ -2677,6 +2677,7 @@ for module in ${configdirs} ; do
>>fi
>>case ${module},${bootstrap_fixincludes} in
>>  fixincludes,no) host_bootstrap_suffix=no-bootstrap ;;
>> +libcc1,*) host_bootstrap_suffix=no-bootstrap ;;
>>  *) host_bootstrap_suffix=$bootstrap_suffix ;;
>>esac
>>extrasub_host="$extrasub_host
> 
> Makefile.def has:
> host_modules= { module= libcc1; bootstrap=true;
> extra_configure_flags=--enable-shared; };
> wonder if that bootstrap=true; is desirable there.

No, it shouldn't be there

Paolo


RE: [PATCH 2/X, i386, PR54232] Enable EBX for x86 in 32bits PIC code

2014-10-30 Thread Zamyatin, Igor
Posted a patch in libc-alpha:

https://sourceware.org/ml/libc-alpha/2014-10/msg00701.html

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Saturday, October 25, 2014 3:42 AM
> To: Evgeny Stupachenko; Andrew Pinski
> Cc: Uros Bizjak; Vladimir Makarov; GCC Patches
> Subject: Re: [PATCH 2/X, i386, PR54232] Enable EBX for x86 in 32bits PIC code
> 
> On 10/24/14 17:37, Evgeny Stupachenko wrote:
> > What if we remove the check?
> > glibc build pass?
> That would be my inclination...   But it's not my decision to make.
> 
> The first check is to verify glibc builds and passes its testsuite with the 
> new
> compiler and that check removed.
> 
> jeff



Re: genmatch infinite loop during bootstrap on AIX

2014-10-30 Thread Richard Biener
On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn  wrote:
> On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
>  wrote:
>
>> Because only genmatch calls functions from libstdc++.  Btw, why
>> would genmatch miscompile an empty function or the call to it?
>
> I tried bootstrapping with libstdc++ built without the AIX ld "-G"
> flag and that is succeeding.
>
> "-G" produces a shared object for use with SVR4-style runtime linking,
> so this version of libstdc++ no longer allows runtime function
> interposition, e.g., operator new, although it is not used frequently.
> Something about the GCC-produced tail calls is interacting badly with
> that feature.
>
> Note that this makes GCC bootstrap on AIX very fragile at the moment
> because it depends on how libstdc++ was built in previous releases.  I
> can bootstrap with GCC 4.6.3 and 4.8.1 but not with 4.7.3, 4.8.0, nor
> 4.9.0.  A problematic libstdc++ from earlier releases causes genmatch
> to loop in stage 1.

I see.  A bootstrap with IPA ICF disabled did not succeed but runs into
the same issue in stage2.  So I wonder if the issue is latent for much
longer and genmatch just exposes it now.

I'll see if I can remove the use of std::map from genmatch as a
workaround.

Thanks,
Richard.

> Thanks, David


Re: [PATCH 5/5] add libcc1

2014-10-30 Thread Jakub Jelinek
On Thu, Oct 30, 2014 at 09:33:08AM +0100, Thomas Schwinge wrote:
> Here is a patch that I'm testing; OK?  I didn't understand what the
> conditions are that libcc1 might not be built as a shared library: is it
> always built as one -- but is that really supported on all systems?  If

It is not unconditionally supported, libcc1/configure.ac uses
GCC_ENABLE_PLUGINS and doesn't compile anything if gcc doesn't support
plugins (one of the several tests of that is that -fPIC -shared is
supported.

> that's indeed true, then this could be further simplified, and
> --enable-shared passed to the host libiberty unconditionally.

Your patch is ok with proper ChangeLog entry.

> --- configure.ac
> +++ configure.ac
> @@ -1865,7 +1865,6 @@ if test -d ${srcdir}/gcc; then
>new_enable_languages=,c,
>  
># If LTO is enabled, add the LTO front end.
> -  extra_host_libiberty_configure_flags=
>if test "$enable_lto" = "yes" ; then
>  case ,${enable_languages}, in
>*,lto,*) ;;
> @@ -1873,10 +1872,8 @@ if test -d ${srcdir}/gcc; then
>  esac
>  if test "${build_lto_plugin}" = "yes" ; then
>configdirs="$configdirs lto-plugin"
> -  extra_host_libiberty_configure_flags=--enable-shared
>  fi
>fi
> -  AC_SUBST(extra_host_libiberty_configure_flags)
>  
>missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e 
> s/,c,/,/ `
>potential_languages=,c,
> @@ -2190,6 +2187,17 @@ then
>esac
>  fi
>  
> +# Sometimes we have special requirements for the host libiberty.
> +extra_host_libiberty_configure_flags=
> +case " $configdirs " in
> +  *" lto-plugin "* | *" libcc1 "*)
> +# When these are to be built as shared libraries, the same applies to
> +# libiberty.
> +extra_host_libiberty_configure_flags=--enable-shared
> +;;
> +esac
> +AC_SUBST(extra_host_libiberty_configure_flags)
> +
>  # Produce a warning message for the subdirs we can't configure.
>  # This isn't especially interesting in the Cygnus tree, but in the individual
>  # FSF releases, it's important to let people know when their machine isn't
> 
> 
> Grüße,
>  Thomas



Jakub


[PATCH, aarch64] Add prefetch support

2014-10-30 Thread Gopalasubramanian, Ganesh
Hi,

Below is the patch that implements prefetching support.

This patch has been already discussed on 
a) https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01644.html
b) https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00612.html

I have not added a test as there are ample tests in compile and execute suites.
"make -k check" passes. Ok for trunk?

Changelog:
2014-10-30  Ganesh Gopalasubramanian 

    * config/aarch64/aarch64.md (define_insn "prefetch"): New.
    * config/arm/types.md (define_attr "type"): Add prefetch.

Regards
Ganesh

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 74b554e..12a3f170 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -320,6 +320,38 @@
   [(set_attr "type" "no_insn")]
)

+
+(define_insn "prefetch"
+  [(prefetch (match_operand:DI 0 "address_operand" "r")
+    (match_operand:QI 1 "const_int_operand" "")
+    (match_operand:QI 2 "const_int_operand" ""))]
+  ""
+  "*
+{
+  const char * pftype[2][10]
+    = { {\"PLDL1STRM\", \"PLDL3KEEP\", \"PLDL2KEEP\", \"PLDL1KEEP\"},
+   {\"PSTL1STRM\", \"PSTL3KEEP\", \"PSTL2KEEP\", \"PSTL1KEEP\"},
+  };
+
+  int locality = INTVAL (operands[2]);
+  char pattern[100];
+
+  gcc_assert (IN_RANGE (locality, 0, 3));
+
+  strcpy (pattern, \"prfm\\t\");
+  strcat (pattern, (const char*)pftype[INTVAL(operands[1])][locality]);
+  strcat (pattern, \", %a0\");
+
+  output_asm_insn (pattern,
+   operands);
+
+  return \"\";
+
+}"
+  [(set_attr "type" "prefetch")]
+)
+
(define_insn "trap"
   [(trap_if (const_int 1) (const_int 8))]
   ""
diff --git a/gcc/config/arm/types.md b/gcc/config/arm/types.md
index c1151f5..8b4b7a1 100644
--- a/gcc/config/arm/types.md
+++ b/gcc/config/arm/types.md
@@ -118,6 +118,7 @@
; mvn_shift_reg  inverting move instruction, shifted operand by a register.
; no_insn    an insn which does not represent an instruction in the
;    final output, thus having no impact on scheduling.
+; prefetch   a prefetch instruction
; rbit   reverse bits.
; rev    reverse bytes.
; sdiv   signed division.
@@ -556,6 +557,7 @@
   call,\
   clz,\
   no_insn,\
+  prefetch,\
   csel,\
   crc,\


Re: [PATCH 2/X, i386, PR54232] Enable EBX for x86 in 32bits PIC code

2014-10-30 Thread Jakub Jelinek
On Thu, Oct 30, 2014 at 08:48:57AM +, Zamyatin, Igor wrote:
> Posted a patch in libc-alpha:
> 
> https://sourceware.org/ml/libc-alpha/2014-10/msg00701.html

That looks wrong.  The non-PIC patterns that are enabled unconditionally
with the patch set/use ebx, which will not work with pre-GCC 5 in PIC mode.

Jakub


[PATCH] Fix fold making valid VEC_PERMs invalid

2014-10-30 Thread Richard Biener

The following patch makes fold_ternary no longer make
VEC_PERMs valid for the target invalid.  As pointed out
in the PR we only need to make sure this doesn't happen
after vector lowering.

I won't have time to improve on the following patch this
week - Marc, can you take over here?

Bootstrapped & tested on x86_64-unknown-linux-gnu.

Thanks,
Richard.

2014-10-30  Richard Biener  

PR middle-end/63666
* fold-const.c: Include optabs.h.
(fold_ternary_loc): Only change the VEC_PERM mask if it
then is a valid constant permutation on the target.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 216834)
+++ gcc/fold-const.c(working copy)
@@ -82,6 +82,7 @@ along with GCC; see the file COPYING3.
 #include "ipa-ref.h"
 #include "cgraph.h"
 #include "generic-match.h"
+#include "optabs.h"
 
 /* Nonzero if we are folding constants inside an initializer; zero
otherwise.  */
@@ -14311,7 +14331,8 @@ fold_ternary_loc (location_t loc, enum t
  if (op0 == op1 && !single_arg)
changed = true;
 
- if (need_mask_canon && arg2 == op2)
+ if (need_mask_canon && arg2 == op2
+ && can_vec_perm_p (TYPE_MODE (type), false, sel))
{
  tree *tsel = XALLOCAVEC (tree, nelts);
  tree eltype = TREE_TYPE (TREE_TYPE (arg2));


Re: [PATCH] Fix fold making valid VEC_PERMs invalid

2014-10-30 Thread Jakub Jelinek
On Thu, Oct 30, 2014 at 09:56:32AM +0100, Richard Biener wrote:
> 
> The following patch makes fold_ternary no longer make
> VEC_PERMs valid for the target invalid.  As pointed out
> in the PR we only need to make sure this doesn't happen
> after vector lowering.

Well, even if you do that before vector lowering, if the original
mask is fine and new one is not, you'd seriously pessimize code.

How about moving the VEC_PERM_EXPR arg2 == VECTOR_CST folding
into a separate function with single_arg argument, call it with
operand_equal_p (op0, op1, 0) initially and call that function again
if single_arg and !can_vec_perm_p (...), that time with
single_arg parameter false?

Jakub


Re: [PATCH] Fix fold making valid VEC_PERMs invalid

2014-10-30 Thread Richard Biener
On Thu, 30 Oct 2014, Jakub Jelinek wrote:

> On Thu, Oct 30, 2014 at 09:56:32AM +0100, Richard Biener wrote:
> > 
> > The following patch makes fold_ternary no longer make
> > VEC_PERMs valid for the target invalid.  As pointed out
> > in the PR we only need to make sure this doesn't happen
> > after vector lowering.
> 
> Well, even if you do that before vector lowering, if the original
> mask is fine and new one is not, you'd seriously pessimize code.

Note that what fold does here isn't very elaborate - it just
tries hard to make a two-input VEC_PERM a one-input one which
is good for canonicalization and CSE.  I'd say that the
optabs.c code should ideally be able to recover the working
variant (or the target expanders should be more clever...).

> How about moving the VEC_PERM_EXPR arg2 == VECTOR_CST folding
> into a separate function with single_arg argument, call it with
> operand_equal_p (op0, op1, 0) initially and call that function again
> if single_arg and !can_vec_perm_p (...), that time with
> single_arg parameter false?

Or how about removing the code instead and doing it during
vector lowering if the original permute is not !can_vec_perm_p?

Richard.


Re: [PATCH 5/5] add libcc1

2014-10-30 Thread Thomas Schwinge
Hi!

On Thu, 30 Oct 2014 09:51:59 +0100, Jakub Jelinek  wrote:
> On Thu, Oct 30, 2014 at 09:33:08AM +0100, Thomas Schwinge wrote:
> > Here is a patch that I'm testing; OK?  I didn't understand what the
> > conditions are that libcc1 might not be built as a shared library: is it
> > always built as one -- but is that really supported on all systems?  If
> 
> It is not unconditionally supported, libcc1/configure.ac uses
> GCC_ENABLE_PLUGINS and doesn't compile anything if gcc doesn't support
> plugins (one of the several tests of that is that -fPIC -shared is
> supported.

Ah, now I see.  Conceptually, as I understand it, that should be done in
the top-level build system, so that libcc1 (and, in case, the shared host
libiberty) isn't even attempted to be built if not supported.  But then,
I don't personally have to deal with hosts that don't support plugins.

> Your patch is ok with proper ChangeLog entry.

Committed in r216912:

commit 944792ef24b74c2b6f5e5d0763b7e5a4a361c3d4
Author: tschwinge 
Date:   Thu Oct 30 10:06:37 2014 +

Build a shared host libiberty also for libcc1's benefit.

* configure.ac (extra_host_libiberty_configure_flags): Add
--enable-shared also for libcc1's benefit.
* configure: Regenerate.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216912 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 ChangeLog|  6 ++
 configure| 16 
 configure.ac | 14 +++---
 3 files changed, 29 insertions(+), 7 deletions(-)

diff --git ChangeLog ChangeLog
index e3636c6..ebcae80 100644
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,9 @@
+2014-10-30  Thomas Schwinge  
+
+   * configure.ac (extra_host_libiberty_configure_flags): Add
+   --enable-shared also for libcc1's benefit.
+   * configure: Regenerate.
+
 2014-10-29  Tristan Gingold  
 
* MAINTAINERS: Change my email address.
diff --git configure configure
index 149acf6..3eab122 100755
--- configure
+++ configure
@@ -642,8 +642,8 @@ CXXFLAGS_FOR_TARGET
 CFLAGS_FOR_TARGET
 DEBUG_PREFIX_CFLAGS_FOR_TARGET
 SYSROOT_CFLAGS_FOR_TARGET
-stage1_languages
 extra_host_libiberty_configure_flags
+stage1_languages
 extra_linker_plugin_flags
 extra_linker_plugin_configure_flags
 clooginc
@@ -6259,7 +6259,6 @@ if test -d ${srcdir}/gcc; then
   new_enable_languages=,c,
 
   # If LTO is enabled, add the LTO front end.
-  extra_host_libiberty_configure_flags=
   if test "$enable_lto" = "yes" ; then
 case ,${enable_languages}, in
   *,lto,*) ;;
@@ -6267,11 +6266,9 @@ if test -d ${srcdir}/gcc; then
 esac
 if test "${build_lto_plugin}" = "yes" ; then
   configdirs="$configdirs lto-plugin"
-  extra_host_libiberty_configure_flags=--enable-shared
 fi
   fi
 
-
   missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e 
s/,c,/,/ `
   potential_languages=,c,
 
@@ -6584,6 +6581,17 @@ then
   esac
 fi
 
+# Sometimes we have special requirements for the host libiberty.
+extra_host_libiberty_configure_flags=
+case " $configdirs " in
+  *" lto-plugin "* | *" libcc1 "*)
+# When these are to be built as shared libraries, the same applies to
+# libiberty.
+extra_host_libiberty_configure_flags=--enable-shared
+;;
+esac
+
+
 # Produce a warning message for the subdirs we can't configure.
 # This isn't especially interesting in the Cygnus tree, but in the individual
 # FSF releases, it's important to let people know when their machine isn't
diff --git configure.ac configure.ac
index b62af38..d8262f8 100644
--- configure.ac
+++ configure.ac
@@ -1852,7 +1852,6 @@ if test -d ${srcdir}/gcc; then
   new_enable_languages=,c,
 
   # If LTO is enabled, add the LTO front end.
-  extra_host_libiberty_configure_flags=
   if test "$enable_lto" = "yes" ; then
 case ,${enable_languages}, in
   *,lto,*) ;;
@@ -1860,10 +1859,8 @@ if test -d ${srcdir}/gcc; then
 esac
 if test "${build_lto_plugin}" = "yes" ; then
   configdirs="$configdirs lto-plugin"
-  extra_host_libiberty_configure_flags=--enable-shared
 fi
   fi
-  AC_SUBST(extra_host_libiberty_configure_flags)
 
   missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e 
s/,c,/,/ `
   potential_languages=,c,
@@ -2177,6 +2174,17 @@ then
   esac
 fi
 
+# Sometimes we have special requirements for the host libiberty.
+extra_host_libiberty_configure_flags=
+case " $configdirs " in
+  *" lto-plugin "* | *" libcc1 "*)
+# When these are to be built as shared libraries, the same applies to
+# libiberty.
+extra_host_libiberty_configure_flags=--enable-shared
+;;
+esac
+AC_SUBST(extra_host_libiberty_configure_flags)
+
 # Produce a warning message for the subdirs we can't configure.
 # This isn't especially interesting in the Cygnus tree, but in the individual
 # FSF releases, it's important to let people know when their machine isn't


Grüße,
 Thomas


pgpBAimpPNBQJ.pgp
Description: PGP signature


[4.9 RFA PATCH, RTL-optimization]: Backport recent AND-alignment alias fixes to 4.9 branch

2014-10-30 Thread Uros Bizjak
Hello!

I would like to backport recent alias fixes to correctly handle memory
references with AND-alignment to 4.9 branch. These patches fix
hundreds of failures in gfortran testsuite on alpha-linux-gnu due to
invalid aliasing of AND-aligned memory references of two QImode flags.

These patches were baking for a couple of weeks in the mainline
without problems. Modulo removal of old and unnecessary functionality,
these changes affect only alpha target.

2014-10-30  Uros Bizjak  

Backport from mainline:
2014-10-20  Uros Bizjak  

* varasm.c (const_alias_set): Remove.
(init_varasm_once): Remove initialization of const_alias_set.
(build_constant_desc): Do not set alias set to const_alias_set.

Backport from mainline:
2014-10-14  Uros Bizjak  

PR rtl-optimization/63475
* alias.c (true_dependence_1): Always use get_addr to extract
true address operands from x_addr and mem_addr.  Use extracted
address operands to check for references with alignment ANDs.
Use extracted address operands with find_base_term and
base_alias_check. For noncanonicalized operands call canon_rtx with
extracted address operand.
(write_dependence_1): Ditto.
(may_alias_p): Ditto.  Remove unused calls to canon_rtx.

Backport from mainline:
2014-10-10  Uros Bizjak  

PR rtl-optimization/63483
* alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P
references when alignment ANDs are involved.
(write_dependence_p): Ditto.
(may_alias_p): Ditto.

The complete backport was tested on alpha-linux-gnu,
alphaev68-linux-gnu and x86_64-linux-gnu on 4.9 branch.

OK for branch?

Uros.
Index: alias.c
===
--- alias.c (revision 216914)
+++ alias.c (working copy)
@@ -2517,6 +2517,7 @@ static int
 true_dependence_1 (const_rtx mem, enum machine_mode mem_mode, rtx mem_addr,
   const_rtx x, rtx x_addr, bool mem_canonicalized)
 {
+  rtx true_mem_addr;
   rtx base;
   int ret;
 
@@ -2536,10 +2537,26 @@ true_dependence_1 (const_rtx mem, enum machine_mod
   || MEM_ALIAS_SET (mem) == ALIAS_SET_MEMORY_BARRIER)
 return 1;
 
+  if (! x_addr)
+x_addr = XEXP (x, 0);
+  x_addr = get_addr (x_addr);
+
+  if (! mem_addr)
+{
+  mem_addr = XEXP (mem, 0);
+  if (mem_mode == VOIDmode)
+   mem_mode = GET_MODE (mem);
+}
+  true_mem_addr = get_addr (mem_addr);
+
   /* Read-only memory is by definition never modified, and therefore can't
- conflict with anything.  We don't expect to find read-only set on MEM,
- but stupid user tricks can produce them, so don't die.  */
-  if (MEM_READONLY_P (x))
+ conflict with anything.  However, don't assume anything when AND
+ addresses are involved and leave to the code below to determine
+ dependence.  We don't expect to find read-only set on MEM, but
+ stupid user tricks can produce them, so don't die.  */
+  if (MEM_READONLY_P (x)
+  && GET_CODE (x_addr) != AND
+  && GET_CODE (true_mem_addr) != AND)
 return 0;
 
   /* If we have MEMs referring to different address spaces (which can
@@ -2548,29 +2565,6 @@ true_dependence_1 (const_rtx mem, enum machine_mod
   if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
 return 1;
 
-  if (! mem_addr)
-{
-  mem_addr = XEXP (mem, 0);
-  if (mem_mode == VOIDmode)
-   mem_mode = GET_MODE (mem);
-}
-
-  if (! x_addr)
-{
-  x_addr = XEXP (x, 0);
-  if (!((GET_CODE (x_addr) == VALUE
-&& GET_CODE (mem_addr) != VALUE
-&& reg_mentioned_p (x_addr, mem_addr))
-   || (GET_CODE (x_addr) != VALUE
-   && GET_CODE (mem_addr) == VALUE
-   && reg_mentioned_p (mem_addr, x_addr
-   {
- x_addr = get_addr (x_addr);
- if (! mem_canonicalized)
-   mem_addr = get_addr (mem_addr);
-   }
-}
-
   base = find_base_term (x_addr);
   if (base && (GET_CODE (base) == LABEL_REF
   || (GET_CODE (base) == SYMBOL_REF
@@ -2577,14 +2571,14 @@ true_dependence_1 (const_rtx mem, enum machine_mod
   && CONSTANT_POOL_ADDRESS_P (base
 return 0;
 
-  rtx mem_base = find_base_term (mem_addr);
-  if (! base_alias_check (x_addr, base, mem_addr, mem_base,
+  rtx mem_base = find_base_term (true_mem_addr);
+  if (! base_alias_check (x_addr, base, true_mem_addr, mem_base,
  GET_MODE (x), mem_mode))
 return 0;
 
   x_addr = canon_rtx (x_addr);
   if (!mem_canonicalized)
-mem_addr = canon_rtx (mem_addr);
+mem_addr = canon_rtx (true_mem_addr);
 
   if ((ret = memrefs_conflict_p (GET_MODE_SIZE (mem_mode), mem_addr,
 SIZE_FOR_MODE (x), x_addr, 0)) != -1)
@@ -2637,6 +2631,7 @@ write_dependence_p (const_rtx mem,
bool mem_canonicalized, bool x_canonicalized, bool writep)
 {
   rtx mem_addr;
+  rtx true_mem_addr, true_x_addr;
   rtx base;
   int ret;
 
@@ -2657,

Re: [patch,avr,4.9] Fix PR63633 ICEs for expanders colliding hard-regs

2014-10-30 Thread Georg-Johann Lay

Am 10/30/2014 07:48 AM, schrieb Denis Chertykov:

Am 10/28/2014 01:34 PM, schrieb Georg-Johann Lay:


Middle-end might come up with hard registers as operands for expanders
which
clobber respective hard regs.  This patch uses freshly created pseudos for
respective expander operands and emits pseudo <-> hard move insn.

Ok for 4.9.2?




Ok.
Please apply.

Denis.


I am also waiting for approval from release manager.

Johann




Re: [patch,avr,4.9] Fix PR63633 ICEs for expanders colliding hard-regs

2014-10-30 Thread Jakub Jelinek
On Thu, Oct 30, 2014 at 11:41:26AM +0100, Georg-Johann Lay wrote:
> Am 10/30/2014 07:48 AM, schrieb Denis Chertykov:
> >>Am 10/28/2014 01:34 PM, schrieb Georg-Johann Lay:
> >>>
> >>>Middle-end might come up with hard registers as operands for expanders
> >>>which
> >>>clobber respective hard regs.  This patch uses freshly created pseudos for
> >>>respective expander operands and emits pseudo <-> hard move insn.
> >>>
> >>>Ok for 4.9.2?
> >>
> >
> >Ok.
> >Please apply.
> >
> >Denis.
> 
> I am also waiting for approval from release manager.

Too late, it has been already released.  The branch is open again, you don't
need any RM approval now.

Jakub


[gomp4] Merge trunk r216846 (2014-10-29) into gomp-4_0-branch

2014-10-30 Thread Thomas Schwinge
Hi!

In r216917, I have committed a merge from trunk r216846 (2014-10-29) into
gomp-4_0-branch.


Grüße,
 Thomas


pgpwOzbsDFp_f.pgp
Description: PGP signature


[gomp4] Re: [PATCH 5/5] add libcc1

2014-10-30 Thread Thomas Schwinge
Hi!

On Thu, 30 Oct 2014 11:10:51 +0100, I wrote:
> Build a shared host libiberty also for libcc1's benefit.

Backported to gomp-4_0-branch in r216918:

commit 595db85c7323b08d29bf344911a7bd709d68685b
Author: tschwinge 
Date:   Thu Oct 30 11:09:14 2014 +

Build a shared host libiberty also for libcc1's benefit.

Backport trunk r216912:

* configure.ac (extra_host_libiberty_configure_flags): Add
--enable-shared also for libcc1's benefit.
* configure: Regenerate.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@216918 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 ChangeLog.gomp |  8 
 configure  | 16 
 configure.ac   | 14 +++---
 3 files changed, 31 insertions(+), 7 deletions(-)

diff --git ChangeLog.gomp ChangeLog.gomp
index 10a0ed7..446329e 100644
--- ChangeLog.gomp
+++ ChangeLog.gomp
@@ -1,3 +1,11 @@
+2014-10-30  Thomas Schwinge  
+
+   Backport trunk r216912:
+
+   * configure.ac (extra_host_libiberty_configure_flags): Add
+   --enable-shared also for libcc1's benefit.
+   * configure: Regenerate.
+
 2014-10-17  Julian Brown  
 
* gomp-constants.h: New file.
diff --git configure configure
index 18781f8..96ee349 100755
--- configure
+++ configure
@@ -642,8 +642,8 @@ CXXFLAGS_FOR_TARGET
 CFLAGS_FOR_TARGET
 DEBUG_PREFIX_CFLAGS_FOR_TARGET
 SYSROOT_CFLAGS_FOR_TARGET
-stage1_languages
 extra_host_libiberty_configure_flags
+stage1_languages
 extra_linker_plugin_flags
 extra_linker_plugin_configure_flags
 clooginc
@@ -6274,7 +6274,6 @@ if test -d ${srcdir}/gcc; then
   new_enable_languages=,c,
 
   # If LTO is enabled, add the LTO front end.
-  extra_host_libiberty_configure_flags=
   if test "$enable_lto" = "yes" ; then
 case ,${enable_languages}, in
   *,lto,*) ;;
@@ -6282,11 +6281,9 @@ if test -d ${srcdir}/gcc; then
 esac
 if test "${build_lto_plugin}" = "yes" ; then
   configdirs="$configdirs lto-plugin"
-  extra_host_libiberty_configure_flags=--enable-shared
 fi
   fi
 
-
   missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e 
s/,c,/,/ `
   potential_languages=,c,
 
@@ -6599,6 +6596,17 @@ then
   esac
 fi
 
+# Sometimes we have special requirements for the host libiberty.
+extra_host_libiberty_configure_flags=
+case " $configdirs " in
+  *" lto-plugin "* | *" libcc1 "*)
+# When these are to be built as shared libraries, the same applies to
+# libiberty.
+extra_host_libiberty_configure_flags=--enable-shared
+;;
+esac
+
+
 # Produce a warning message for the subdirs we can't configure.
 # This isn't especially interesting in the Cygnus tree, but in the individual
 # FSF releases, it's important to let people know when their machine isn't
diff --git configure.ac configure.ac
index 20dbcbc..7b24958 100644
--- configure.ac
+++ configure.ac
@@ -1861,7 +1861,6 @@ if test -d ${srcdir}/gcc; then
   new_enable_languages=,c,
 
   # If LTO is enabled, add the LTO front end.
-  extra_host_libiberty_configure_flags=
   if test "$enable_lto" = "yes" ; then
 case ,${enable_languages}, in
   *,lto,*) ;;
@@ -1869,10 +1868,8 @@ if test -d ${srcdir}/gcc; then
 esac
 if test "${build_lto_plugin}" = "yes" ; then
   configdirs="$configdirs lto-plugin"
-  extra_host_libiberty_configure_flags=--enable-shared
 fi
   fi
-  AC_SUBST(extra_host_libiberty_configure_flags)
 
   missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e 
s/,c,/,/ `
   potential_languages=,c,
@@ -2186,6 +2183,17 @@ then
   esac
 fi
 
+# Sometimes we have special requirements for the host libiberty.
+extra_host_libiberty_configure_flags=
+case " $configdirs " in
+  *" lto-plugin "* | *" libcc1 "*)
+# When these are to be built as shared libraries, the same applies to
+# libiberty.
+extra_host_libiberty_configure_flags=--enable-shared
+;;
+esac
+AC_SUBST(extra_host_libiberty_configure_flags)
+
 # Produce a warning message for the subdirs we can't configure.
 # This isn't especially interesting in the Cygnus tree, but in the individual
 # FSF releases, it's important to let people know when their machine isn't


Grüße,
 Thomas


pgp2sfK4vhc6I.pgp
Description: PGP signature


[Ada] Case variable from another project in an extended project

2014-10-30 Thread Arnaud Charlet
When a case variable is declared in another imported project and its
project is itself extended, the Project Manager is confused and may
crash or report incorrect errors.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-10-30  Vincent Celier  

* prj-proc.adb (Process_Case_Construction): Do not look for
the ultimate extending project for a case variable.

Index: prj-proc.adb
===
--- prj-proc.adb(revision 216770)
+++ prj-proc.adb(working copy)
@@ -2308,7 +2308,9 @@
  Name_Of
(Project_Node_Of (Variable_Node, Node_Tree), Node_Tree);
The_Project :=
- Imported_Or_Extended_Project_From (Project, Name);
+ Imported_Or_Extended_Project_From
+   (Project, Name, No_Extending => True);
+   The_Package := No_Package;
 end if;
 
 --  If a package was specified for the case variable, get its id


[Ada] Insertion of child into multiway tree yields bad cursor

2014-10-30 Thread Arnaud Charlet
This patch corrects the implementation of routine Insert_Child in the following
multiway tree packages:

   Ada.Containers.Indefinite_Multiway_Trees
   Ada.Containers.Multiway_Trees

As a result, Insert_Child no longer returns a faulty Position when inserting
elements.


-- Source --


--  multi_main.adb

with Ada.Containers.Multiway_Trees;
with Ada.Text_IO; use Ada.Text_IO;

procedure Multi_Main is
   Size : constant := 4;

   type Small_Int is new Integer range 1 .. 9
 with Default_Value => 1;

   package MWT is new Ada.Containers.Multiway_Trees (Small_Int);
   use MWT;

   procedure Print_Tree (T : Tree) is
  procedure Output (C : Cursor) is
  begin
 Put_Line (Element (C)'Img);
  end Output;

   begin
  T.Iterate (Output'Access);
   end Print_Tree;

   T : Tree;
   R : constant Cursor := T.Root;
   C : Cursor;

begin
   for Index in 1 .. Size loop
  T.Prepend_Child (R, 8);
   end loop;

   T.Clear;

   T.Insert_Child
 (Parent   => R,
  Before   => No_Element,
  Position => C,
  Count=> 1);

   T.Insert_Child
 (Parent   => R,
  Before   => C,
  Position => C,
  New_Item => 2,
  Count=> 2);

   Print_Tree (T);
end Multi_Main;


-- Compilation and output --


$ gnatmake -q multi_main.adb
$ ./multi_main
 2
 2
 1

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-10-30  Hristian Kirtchev  

* a-comutr.adb, a-cimutr.adb (Insert_Child): Add new variable First.
Update the position after all insertions have taken place.

Index: a-cimutr.adb
===
--- a-cimutr.adb(revision 216770)
+++ a-cimutr.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 2004-2013, Free Software Foundation, Inc. --
+--  Copyright (C) 2004-2014, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -1217,6 +1217,7 @@
   Position  : out Cursor;
   Count : Count_Type := 1)
is
+  First   : Tree_Node_Access;
   Last: Tree_Node_Access;
   Element : Element_Access;
 
@@ -1249,8 +1250,6 @@
with "attempt to tamper with cursors (tree is busy)";
   end if;
 
-  Position.Container := Parent.Container;
-
   declare
  --  The element allocator may need an accessibility check in the case
  --  the actual type is class-wide or has access discriminants (see
@@ -1264,16 +1263,16 @@
  Element := new Element_Type'(New_Item);
   end;
 
-  Position.Node := new Tree_Node_Type'(Parent  => Parent.Node,
-   Element => Element,
-   others  => <>);
+  First := new Tree_Node_Type'(Parent  => Parent.Node,
+   Element => Element,
+   others  => <>);
 
-  Last := Position.Node;
+  Last := First;
+  for J in Count_Type'(2) .. Count loop
 
-  for J in Count_Type'(2) .. Count loop
  --  Reclaim other nodes if Storage_Error.  ???
 
- Element := new Element_Type'(New_Item);
+ Element   := new Element_Type'(New_Item);
  Last.Next := new Tree_Node_Type'(Parent  => Parent.Node,
   Prev=> Last,
   Element => Element,
@@ -1283,7 +1282,7 @@
   end loop;
 
   Insert_Subtree_List
-(First  => Position.Node,
+(First  => First,
  Last   => Last,
  Parent => Parent.Node,
  Before => Before.Node);
@@ -1293,6 +1292,8 @@
   --  nodes we just inserted.
 
   Container.Count := Container.Count + Count;
+
+  Position := Cursor'(Parent.Container, First);
end Insert_Child;
 
-
Index: a-comutr.adb
===
--- a-comutr.adb(revision 216770)
+++ a-comutr.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 2004-2013, Free Software Foundation, Inc. --
+--  Copyright (C) 2004-2014, Free Software Foundation, Inc. --
 --   

[Ada] Prevent generation of gotos during inlining for GNATprove

2014-10-30 Thread Arnaud Charlet
In GNATprove mode, the special frontend inlining could generate gotos on
return statements inside blocks, thus causing errors in GNATprove later.
Now prevent inlining of such subprograms.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-10-30  Yannick Moy  

* inline.adb (Has_Single_Return_In_GNATprove_Mode):
Return False when return statement is inside one or more blocks.

Index: inline.adb
===
--- inline.adb  (revision 216770)
+++ inline.adb  (working copy)
@@ -933,7 +933,10 @@
   function Has_Single_Return_In_GNATprove_Mode return Boolean;
   --  This function is called only in GNATprove mode, and it returns
   --  True if the subprogram has no return statement or a single return
-  --  statement as last statement.
+  --  statement as last statement. It returns False for subprogram with
+  --  a single return as last statement inside one or more blocks, as
+  --  inlining would generate gotos in that case as well (although the
+  --  goto is useless in that case).
 
   function Uses_Secondary_Stack (Bod : Node_Id) return Boolean;
   --  If the body of the subprogram includes a call that returns an
@@ -1003,15 +1006,10 @@
   --  Start of processing for Has_Single_Return_In_GNATprove_Mode
 
   begin
- --  Retrieve last statement inside possible block statements
+ --  Retrieve the last statement
 
  Last_Statement := Last (Statements (Handled_Statement_Sequence (N)));
 
- while Nkind (Last_Statement) = N_Block_Statement loop
-Last_Statement :=
-  Last (Statements (Handled_Statement_Sequence (Last_Statement)));
- end loop;
-
  --  Check that the last statement is the only possible return
  --  statement in the subprogram.
 
@@ -2049,16 +2047,15 @@
   OK: Boolean;
 
begin
-  if Is_Compilation_Unit (P)
+  if Front_End_Inlining
+and then Is_Compilation_Unit (P)
 and then not Is_Generic_Instance (P)
   then
  Bname := Get_Body_Name (Get_Unit_Name (Unit (N)));
 
  E := First_Entity (P);
  while Present (E) loop
-if Has_Pragma_Inline_Always (E)
-  or else (Front_End_Inlining and then Has_Pragma_Inline (E))
-then
+if Has_Pragma_Inline (E) then
if not Is_Loaded (Bname) then
   Load_Needed_Body (N, OK);
 


[Ada] Missing finalization of controlled function result

2014-10-30 Thread Arnaud Charlet
This patch modifies the finalization machinery to detect a subprogram call
that returns a constrolled transient temporary in the context of a function
call that returns an unconstrained result as part of the initialization
expression of an object declaration.


-- Source --


--  types.ads

with Ada.Finalization; use Ada.Finalization;

package Types is
   Ctrl_Error : exception;

   type Ctrl is new Controlled with record
  Id   : Natural := 0;
  Data : Natural;
   end record;

   procedure Adjust (Obj : in out Ctrl);
   procedure Finalize (Obj : in out Ctrl);
   procedure Initialize (Obj : in out Ctrl);

   function Get_Id (Obj : Ctrl) return String;  --  raises Ctrl_Error
   function Make_Ctrl (Data : Natural) return Ctrl;
end Types;

--  types.adb

with Ada.Text_IO; use Ada.Text_IO;

package body Types is
   Id_Gen : Natural := 0;

   procedure Adjust (Obj : in out Ctrl) is
  Old_Id : constant Natural := Obj.Id;
  New_Id : constant Natural := Old_Id * 100;

   begin
  Put_Line ("  adj:" & Old_Id'Img & " =>" & New_Id'Img);
  Obj.Id := New_Id;
   end Adjust;

   procedure Finalize (Obj : in out Ctrl) is
   begin
  Put_Line ("  fin:" & Obj.Id'Img);
  Obj.Id := 0;
   end Finalize;

   function Get_Id (Obj : Ctrl) return String is
   begin
  raise Ctrl_Error;
  return Obj.Id'Img;
   end Get_Id;

   procedure Initialize (Obj : in out Ctrl) is
   begin
  Id_Gen := Id_Gen + 1;
  Obj.Id := Id_Gen;
  Put_Line ("  ini:" & Obj.Id'Img);
   end Initialize;

   function Make_Ctrl (Data : Natural) return Ctrl is
  Obj : Ctrl;

   begin
  Obj.Data := Data;
  return Obj;
   end Make_Ctrl;
end Types;

--  trans_final.adb

with Ada.Text_IO; use Ada.Text_IO;
with Types;   use Types;

procedure Trans_Final is
begin
   declare
  Id : constant String := Get_Id (Make_Ctrl (123));
   begin
  Put_Line ("ERROR: exception not raised");
   end;
exception
   when Ctrl_Error => Put_Line ("OK");
   when others => Put_Line ("ERROR: unexpected exception");
end Trans_Final;


-- Compilation and output --


$ gnatmake -q trans_final.adb
$ ./trans_final
  ini: 1
  adj: 1 => 100
  fin: 1
  fin: 100
OK

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-10-30  Hristian Kirtchev  

* exp_ch7.adb (Is_Subprogram_Call): Account for the case where an
object declaration initialized by a function call that returns
an unconstrained result may be rewritted as a renaming of the
secondary stack result.

Index: exp_ch7.adb
===
--- exp_ch7.adb (revision 216770)
+++ exp_ch7.adb (working copy)
@@ -4532,11 +4532,14 @@
  function Is_Subprogram_Call (N : Node_Id) return Traverse_Result is
  begin
 --  Complex constructs are factored out by the expander and their
---  occurrences are replaced with references to temporaries. Due to
---  this expansion activity, inspect the original tree to detect
---  subprogram calls.
+--  occurrences are replaced with references to temporaries or
+--  object renamings. Due to this expansion activity, inspect the
+--  original tree to detect subprogram calls.
 
-if Nkind (N) = N_Identifier and then Original_Node (N) /= N then
+if Nkind_In (N, N_Identifier,
+N_Object_Renaming_Declaration)
+  and then Original_Node (N) /= N
+then
Detect_Subprogram_Call (Original_Node (N));
 
--  The original construct contains a subprogram call, there is


[Ada] Aspect/pragma Extensions_Visible

2014-10-30 Thread Arnaud Charlet
This patch implements aspect/pragma Extensions_Visible. This construct has the
following rules:

Extensions_Visible is a Boolean-valued aspect which may be specified for a
subprogram. If directly specified, the aspect_definition shall be a static
[Boolean] expression. The aspect is inherited by an inherited primitive
subprogram. If the aspect is neither inherited nor directly specified for a
subprogram, then the aspect is False.

If the Extensions_Visible aspect is False for a subprogram, then certain
restrictions are imposed on the use of any parameter of the subprogram which is
of a specific tagged type (or of a private type whose full view is a specific
tagged type). Such a parameter shall not be converted implicitly or explicitly
to a class-wide type. Such a parameter shall not be passed as an actual
parameter in a call to a subprogram whose Extensions_Visible aspect is True.
These restrictions also apply to any parenthesized expression, qualified
expression, or type conversion whose operand is subject to these restrictions,
and to any conditional expression having at least one dependent_expression
which is subject to these restrictions.

A subprogram whose Extensions_Visible aspect is True shall not override an
inherited primitive operation of a tagged type whose Extensions_Visible aspect
is False.

If a nonnull type extension inherits a procedure having both a False
Extensions_Visible aspect and one or more controlling out-mode parameters, then
the inherited procedure requires overriding.

The Extensions_Visible aspect shall not be specified for a subprogram which has
no parameters of either a specific tagged type or a private type unless the
subprogram is declared in an instance of a generic unit and the corresponding
subprogram in the generic unit satisfies this rule.


-- Source --


--  extensions_visible_illegal_2.ads

package Extensions_Visible_Illegal_2 with SPARK_Mode is
   type T is tagged record
  X : Integer;
   end record;

   procedure Proc   (Param : in T);
   procedure Proc_2 (Param : out T) with Extensions_Visible => False;

   type Extension is new T with record
  Y : Integer;
   end record;

   overriding procedure Proc (Param : in Extension) with Extensions_Visible;

   type Null_Extension is new T with null record;

   overriding procedure Proc (Param : in Null_Extension)
 with Extensions_Visible;
end Extensions_Visible_Illegal_2;


-- Compilation and output --


$ gcc -c extensions_visible_illegal_2.ads
extensions_visible_illegal_2.ads:9:09: type must be declared abstract or
  "Proc_2" overridden
extensions_visible_illegal_2.ads:9:09: "Proc_2" at line 7 is subject to
  Extensions_Visible False
extensions_visible_illegal_2.ads:13:25: subprogram "Proc" with
  Extensions_Visible True cannot override subprogram at line 6 with
  Extensions_Visible False
extensions_visible_illegal_2.ads:17:25: subprogram "Proc" with
  Extensions_Visible True cannot override subprogram at line 6 with
  Extensions_Visible False

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-10-30  Hristian Kirtchev  

* aspects.adb: Add an entry for aspect Extensions_Visible in
table Canonical_Aspect.
* aspects.ads: Add entry for aspect Extensions_Visible in
tables Aspect_Argument, Aspect_Delay, Aspect_Id, Aspect_Names,
Implementation_Defined_Aspect.
* einfo.adb (Get_Pragma): Include pragma Extensions_Visible in
the list of contract pragmas.
* par-prag.adb Pragma Extensions_Visible does not require special
processing from the parser.
* sem_ch3.adb (Analyze_Object_Declaration): Prevent an
implicit class-wide conversion of a formal parameter
of a specific tagged type whose related subprogram is
subject to pragma Extensions_Visible with value "False".
(Check_Abstract_Overriding): Add various overriding checks
related to pragma Extensions_Visible.
(Derive_Subprogram):
A subprogram subject to pragma Extensions_Visible with value
False requires overriding if the subprogram has at least one
controlling OUT parameter.
(Is_EVF_Procedure): New routine.
* sem_ch4.adb (Analyze_Type_Conversion): A formal parameter of
a specific tagged type whose related subprogram is subject to
pragma Extensions_Visible with value "False" cannot appear in
a class-wide conversion.
* sem_ch6.adb (Analyze_Subprogram_Contract): Remove
the assertion to account for pragma Extensions_Visible.
(Check_Overriding_Indicator): An overriding subprogram
inherits the contact of the overridden subprogram.
(New_Overloaded_Entity): An overriding subprogram inherits the
contact of the overridden subprogram.
* sem_ch13.adb (Analyze_Aspect_Specifications): Add processing
for aspect Extensions_Visible.
(Check_Asp

[PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

2014-10-30 Thread Ilya Verbin
Hello,

This patch allows to run non-fallback 'make check-target-libgomp'.  It passes to
the host compiler additional -B options with the paths to the offload compilers,
since non-installed host compiler doesn't know where to find mkoffload tools.
Also in case of intelmic offload targets it appends paths to liboffloadmic lib.
Is it ok for trunk?

Thanks,
  -- Ilya


2014-10-30  Andrey Turetskiy  
Ilya Verbin  

libgomp/
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Set up offload_additional_options,
offload_additional_lib_paths and offload_targets.
* testsuite/Makefile.am: Overrule site.exp.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgomp.exp (libgomp_init): Append
offload_additional_lib_paths to LD_LIBRARY_PATH.  Append
offload_additional_options to ALWAYS_CFLAGS.  Append liboffloadmic
build directory to LD_LIBRARY_PATH for intelmic offload targets.

---

diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 5cd666f..8e4774f 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -268,6 +268,9 @@ lt_host_flags = @lt_host_flags@
 mandir = @mandir@
 mkdir_p = @mkdir_p@
 multi_basedir = @multi_basedir@
+offload_additional_lib_paths = @offload_additional_lib_paths@
+offload_additional_options = @offload_additional_options@
+offload_targets = @offload_targets@
 oldincludedir = @oldincludedir@
 pdfdir = @pdfdir@
 prefix = @prefix@
diff --git a/libgomp/configure b/libgomp/configure
index 97c9be6..aabf25f 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -616,6 +616,9 @@ OMP_LOCK_SIZE
 USE_FORTRAN_FALSE
 USE_FORTRAN_TRUE
 link_gomp
+offload_additional_lib_paths
+offload_additional_options
+offload_targets
 XLDFLAGS
 XCFLAGS
 config_path
@@ -11094,7 +11097,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11097 "configure"
+#line 11100 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11200,7 +11203,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11203 "configure"
+#line 11206 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16207,9 +16210,13 @@ else
   multilib_arg=
 fi
 
+# Get accel target and path to install tree of accel compiler
+offload_additional_options=
+offload_additional_lib_paths=
 offload_targets=
 if test x"$enable_offload_targets" != x; then
   for tgt in `echo $enable_offload_targets | sed -e 's#,# #g'`; do
+tgt_dir=`echo $tgt | grep '=' | sed 's/.*=//'`
 tgt=`echo $tgt | sed 's/=.*//'`
 case $tgt in
   *-intelmic-* | *-intelmicemul-*)
@@ -16222,6 +16229,13 @@ if test x"$enable_offload_targets" != x; then
 else
   offload_targets=$offload_targets,$tgt_name
 fi
+if test x"$tgt_dir" != x; then
+  offload_additional_options="$offload_additional_options 
-B$tgt_dir/libexec/gcc/\$(target_alias)/\$(gcc_version) -B$tgt_dir/bin"
+  
offload_additional_lib_paths="$offload_additional_lib_paths:$tgt_dir/lib64:$tgt_dir/lib"
+else
+  offload_additional_options="$offload_additional_options 
-B\$(libexecdir)/gcc/\$(target_alias)/\$(gcc_version) -B\$(bindir)"
+  
offload_additional_lib_paths="$offload_additional_lib_paths:$toolexeclibdir"
+fi
   done
 fi
 
@@ -16230,6 +16244,9 @@ cat >>confdefs.h <<_ACEOF
 _ACEOF
 
 
+
+
+
 # Set up the set of libraries that we need to link against for libgomp.
 # Note that the GOMP_SELF_SPEC in gcc.c may force -pthread,
 # which will force linkage against -lpthread (or equivalent for the system).
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index 3f34ff8..cea6366 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -280,9 +280,13 @@ else
   multilib_arg=
 fi
 
+# Get accel target and path to install tree of accel compiler
+offload_additional_options=
+offload_additional_lib_paths=
 offload_targets=
 if test x"$enable_offload_targets" != x; then
   for tgt in `echo $enable_offload_targets | sed -e 's#,# #g'`; do
+tgt_dir=`echo $tgt | grep '=' | sed 's/.*=//'`
 tgt=`echo $tgt | sed 's/=.*//'`
 case $tgt in
   *-intelmic-* | *-intelmicemul-*)
@@ -295,10 +299,20 @@ if test x"$enable_offload_targets" != x; then
 else
   offload_targets=$offload_targets,$tgt_name
 fi
+if test x"$tgt_dir" != x; then
+  offload_additional_options="$offload_additional_options 
-B$tgt_dir/libexec/gcc/\$(target_alias)/\$(gcc_version) -B$tgt_dir/bin"
+  
offload_additional_lib_paths="$offload_additional_lib_paths:$tgt_dir/lib64:$tgt_dir/lib"
+else
+  offload_additional_options="$offload_additional_options 
-B\$(libexecdir)/gcc/\$(target_alias)/\$(gcc_version) -B\$(bindir)"
+  
offload_additional_lib_paths="$offload_additional_lib_paths:$toolexeclibdir"
+fi
   done
 fi
 AC_DEFINE_UNQUOTED(OFFLOAD_TARGETS, "$offload_targets",
   [Define to ho

RE: [PATCH 2/X, i386, PR54232] Enable EBX for x86 in 32bits PIC code

2014-10-30 Thread Zamyatin, Igor
> 
> On Thu, Oct 30, 2014 at 08:48:57AM +, Zamyatin, Igor wrote:
> > Posted a patch in libc-alpha:
> >
> > https://sourceware.org/ml/libc-alpha/2014-10/msg00701.html
> 
> That looks wrong.  The non-PIC patterns that are enabled unconditionally
> with the patch set/use ebx, which will not work with pre-GCC 5 in PIC mode.

Could you please specify why do you think it is wrong for PIC mode for pre-GCC 
5?

Thanks,
Igor

> 
>   Jakub


Re: [PATCH][BUILDROBOT] Unused static function (was: RFA: AVR: add infrastructure for device packages)

2014-10-30 Thread Jan-Benedict Glaw
On Thu, 2014-10-30 10:46:39 +0400, Denis Chertykov  wrote:
> 2014-10-29 13:42 GMT+03:00 Jan-Benedict Glaw :
> > On Wed, 2014-10-29 02:23:31 +0100, Jan-Benedict Glaw  
> > wrote:
> > > On Wed, 2014-10-08 18:50:32 +0100, Joern Rennecke 
> > >  wrote:
> > > > Attached is the GCC patch for the basic device package infrastructure.
> > > > OK to apply?
> > > There's some fallout on config-list.mk builds:
> > >
> > > g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
> > > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
> > > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
> > > -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> > > -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. 
> > > -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
> > > -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  
> > > -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd 
> > > -I../libdecnumber -I../../../gcc/gcc/../libbacktrace-I. -I. 
> > > -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
> > > -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  
> > > -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd 
> > > -I../libdecnumber -I../../../gcc/gcc/../libbacktrace   
> > > ../../../gcc/gcc/config/avr/driver-avr.c
> > > ../../../gcc/gcc/config/avr/driver-avr.c:35:1: error: ‘void 
> > > avr_set_current_device(const char*)’ defined but not used 
> > > [-Werror=unused-function]
> > >  avr_set_current_device (const char *name)
> > >  ^
> > > cc1plus: all warnings being treated as errors
> > > make[2]: *** [driver-avr.o] Error 1
> > So I suggest to just remove it.
> >
> > 2014-10-29  Jan-Benedict Glaw  
> >
> > * config/avr/driver-avr.c (avr_set_current_device): Remove.
> I have not plans to use it.
> Please, apply the patch.

Committed as r216932.

Thanks, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Träume nicht von Deinem Leben: Lebe Deinen Traum!
the second  :


signature.asc
Description: Digital signature


[PATCH][9/n] Merge from match-and-simplify, more patterns

2014-10-30 Thread Richard Biener

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2014-10-30  Richard Biener  

* match.pd: Implement more patterns that simplify to a single value.
* fold-const.c (fold_binary_loc): Remove them here.
* tree-ssa-forwprop.c (simplify_bitwise_binary): Likewise.

Index: trunk/gcc/fold-const.c
===
*** trunk.orig/gcc/fold-const.c 2014-10-30 14:02:58.477371843 +0100
--- trunk/gcc/fold-const.c  2014-10-30 14:03:05.829371337 +0100
*** fold_binary_loc (location_t loc,
*** 11089,11097 
  
  case BIT_IOR_EXPR:
  bit_ior:
-   if (operand_equal_p (arg0, arg1, 0))
-   return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg0));
- 
/* ~X | X is -1.  */
if (TREE_CODE (arg0) == BIT_NOT_EXPR
  && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0))
--- 11089,11094 
*** fold_binary_loc (location_t loc,
*** 11227,11235 
goto bit_rotate;
  
  case BIT_XOR_EXPR:
-   if (integer_all_onesp (arg1))
-   return fold_build1_loc (loc, BIT_NOT_EXPR, type, op0);
- 
/* ~X ^ X is -1.  */
if (TREE_CODE (arg0) == BIT_NOT_EXPR
  && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0))
--- 11224,11229 
*** fold_binary_loc (location_t loc,
*** 11384,11394 
goto bit_rotate;
  
  case BIT_AND_EXPR:
-   if (integer_all_onesp (arg1))
-   return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg0));
-   if (operand_equal_p (arg0, arg1, 0))
-   return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg0));
- 
/* ~X & X, (X == 0) & X, and !X & X are always zero.  */
if ((TREE_CODE (arg0) == BIT_NOT_EXPR
   || TREE_CODE (arg0) == TRUTH_NOT_EXPR
--- 11378,11383 
Index: trunk/gcc/match.pd
===
*** trunk.orig/gcc/match.pd 2014-10-30 14:02:58.477371843 +0100
--- trunk/gcc/match.pd  2014-10-30 14:04:22.869366033 +0100
*** along with GCC; see the file COPYING3.
*** 31,37 
  
  
  /* Simplifications of operations with one constant operand and
!simplifications to constants.  */
  
  (for op (plus pointer_plus minus bit_ior bit_xor)
(simplify
--- 31,37 
  
  
  /* Simplifications of operations with one constant operand and
!simplifications to constants or single values.  */
  
  (for op (plus pointer_plus minus bit_ior bit_xor)
(simplify
*** along with GCC; see the file COPYING3.
*** 88,93 
--- 88,109 
(bit_xor @0 @0)
{ build_zero_cst (type); })
  
+ /* Canonicalize X ^ ~0 to ~X.  */
+ (simplify
+   (bit_xor @0 integer_all_onesp@1)
+   (bit_not @0))
+ 
+ /* x & ~0 -> x  */
+ (simplify
+  (bit_and @0 integer_all_onesp)
+   (non_lvalue @0))
+ 
+ /* x & x -> x,  x | x -> x  */
+ (for bitop (bit_and bit_ior)
+  (simplify
+   (bitop @0 @0)
+   (non_lvalue @0)))
+ 
  
  /* Simplifications of conversions.  */
  
Index: trunk/gcc/tree-ssa-forwprop.c
===
*** trunk.orig/gcc/tree-ssa-forwprop.c  2014-10-30 14:02:58.477371843 +0100
--- trunk/gcc/tree-ssa-forwprop.c   2014-10-30 14:03:05.830371337 +0100
*** simplify_bitwise_binary (gimple_stmt_ite
*** 2097,2112 
return true;
  }
  
-   /* Canonicalize X ^ ~0 to ~X.  */
-   if (code == BIT_XOR_EXPR
-   && integer_all_onesp (arg2))
- {
-   gimple_assign_set_rhs_with_ops (gsi, BIT_NOT_EXPR, arg1, NULL_TREE);
-   gcc_assert (gsi_stmt (*gsi) == stmt);
-   update_stmt (stmt);
-   return true;
- }
- 
/* Try simple folding for X op !X, and X op X.  */
res = simplify_bitwise_binary_1 (code, TREE_TYPE (arg1), arg1, arg2);
if (res != NULL_TREE)
--- 2097,2102 


Re: [PATCH 2/X, i386, PR54232] Enable EBX for x86 in 32bits PIC code

2014-10-30 Thread Jakub Jelinek
On Thu, Oct 30, 2014 at 12:34:45PM +, Zamyatin, Igor wrote:
> > 
> > On Thu, Oct 30, 2014 at 08:48:57AM +, Zamyatin, Igor wrote:
> > > Posted a patch in libc-alpha:
> > >
> > > https://sourceware.org/ml/libc-alpha/2014-10/msg00701.html
> > 
> > That looks wrong.  The non-PIC patterns that are enabled unconditionally
> > with the patch set/use ebx, which will not work with pre-GCC 5 in PIC mode.
> 
> Could you please specify why do you think it is wrong for PIC mode for 
> pre-GCC 5?

Those macros use "=&b" etc. in asm constraints, so IMHO you'll get the same
error as for say:

int
foo (void)
{
  bar ();
  int i = 0;
  asm volatile ("" : "+b" (i));
  bar ();
  return i;
}

when compiled by gcc 4.9 and earlier with -O2 -m32 -fpic:
error: inconsistent operand constraints in an ‘asm’

Jakub


Re: [PATCH][9/n] Merge from match-and-simplify, more patterns

2014-10-30 Thread Richard Biener
On Thu, 30 Oct 2014, Richard Biener wrote:

> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Oops, posted the wrong patch.  The following is correct - I've
removed the single-use restriction as no patterns would behave
badly but stuff like x & x wouldn't match.

Richard.

2014-10-30  Richard Biener  

* match.pd: Implement more patterns that simplify to a single value.
* fold-const.c (fold_binary_loc): Remove them here.
* tree-ssa-forwprop.c (simplify_bitwise_binary): Likewise.
(fwprop_ssa_val): Remove restriction on single uses.

Index: trunk/gcc/fold-const.c
===
*** trunk.orig/gcc/fold-const.c 2014-10-30 14:02:58.477371843 +0100
--- trunk/gcc/fold-const.c  2014-10-30 14:03:05.829371337 +0100
*** fold_binary_loc (location_t loc,
*** 11089,11097 
  
  case BIT_IOR_EXPR:
  bit_ior:
-   if (operand_equal_p (arg0, arg1, 0))
-   return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg0));
- 
/* ~X | X is -1.  */
if (TREE_CODE (arg0) == BIT_NOT_EXPR
  && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0))
--- 11089,11094 
*** fold_binary_loc (location_t loc,
*** 11227,11235 
goto bit_rotate;
  
  case BIT_XOR_EXPR:
-   if (integer_all_onesp (arg1))
-   return fold_build1_loc (loc, BIT_NOT_EXPR, type, op0);
- 
/* ~X ^ X is -1.  */
if (TREE_CODE (arg0) == BIT_NOT_EXPR
  && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0))
--- 11224,11229 
*** fold_binary_loc (location_t loc,
*** 11384,11394 
goto bit_rotate;
  
  case BIT_AND_EXPR:
-   if (integer_all_onesp (arg1))
-   return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg0));
-   if (operand_equal_p (arg0, arg1, 0))
-   return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg0));
- 
/* ~X & X, (X == 0) & X, and !X & X are always zero.  */
if ((TREE_CODE (arg0) == BIT_NOT_EXPR
   || TREE_CODE (arg0) == TRUTH_NOT_EXPR
--- 11378,11383 
Index: trunk/gcc/match.pd
===
*** trunk.orig/gcc/match.pd 2014-10-30 14:02:58.477371843 +0100
--- trunk/gcc/match.pd  2014-10-30 14:04:22.869366033 +0100
*** along with GCC; see the file COPYING3.
*** 31,37 
  
  
  /* Simplifications of operations with one constant operand and
!simplifications to constants.  */
  
  (for op (plus pointer_plus minus bit_ior bit_xor)
(simplify
--- 31,37 
  
  
  /* Simplifications of operations with one constant operand and
!simplifications to constants or single values.  */
  
  (for op (plus pointer_plus minus bit_ior bit_xor)
(simplify
*** along with GCC; see the file COPYING3.
*** 88,93 
--- 88,109 
(bit_xor @0 @0)
{ build_zero_cst (type); })
  
+ /* Canonicalize X ^ ~0 to ~X.  */
+ (simplify
+   (bit_xor @0 integer_all_onesp@1)
+   (bit_not @0))
+ 
+ /* x & ~0 -> x  */
+ (simplify
+  (bit_and @0 integer_all_onesp)
+   (non_lvalue @0))
+ 
+ /* x & x -> x,  x | x -> x  */
+ (for bitop (bit_and bit_ior)
+  (simplify
+   (bitop @0 @0)
+   (non_lvalue @0)))
+ 
  
  /* Simplifications of conversions.  */
  
Index: trunk/gcc/tree-ssa-forwprop.c
===
*** trunk.orig/gcc/tree-ssa-forwprop.c  2014-10-30 14:02:58.477371843 +0100
--- trunk/gcc/tree-ssa-forwprop.c   2014-10-30 14:03:05.830371337 +0100
*** simplify_bitwise_binary (gimple_stmt_ite
*** 2097,2112 
return true;
  }
  
-   /* Canonicalize X ^ ~0 to ~X.  */
-   if (code == BIT_XOR_EXPR
-   && integer_all_onesp (arg2))
- {
-   gimple_assign_set_rhs_with_ops (gsi, BIT_NOT_EXPR, arg1, NULL_TREE);
-   gcc_assert (gsi_stmt (*gsi) == stmt);
-   update_stmt (stmt);
-   return true;
- }
- 
/* Try simple folding for X op !X, and X op X.  */
res = simplify_bitwise_binary_1 (code, TREE_TYPE (arg1), arg1, arg2);
if (res != NULL_TREE)
--- 2097,2102 


[PATCH] config-list.mk: Build Go only for supported targets (was: Patch RFA: Top-level configure patch: disable go on systems where it doesn't work)

2014-10-30 Thread Jan-Benedict Glaw
On Mon, 2014-10-27 09:33:41 -0700, Ian Taylor  wrote:
> On Mon, Oct 27, 2014 at 9:02 AM, Jan-Benedict Glaw  wrote:
> > On Mon, 2014-10-27 08:19:34 -0700, Ian Taylor  wrote:
> > > On Mon, Oct 27, 2014 at 8:06 AM, Jan-Benedict Glaw  
> > > wrote:
> > > > On Wed, 2014-10-22 20:36:53 -0700, Ian Taylor  wrote:
> > > > > This patch to the top level GCC configure script disables
> > > > > the go languages on some systems where it is known to not
> > > > > work.  Bootstrapped on x86_64-unknown-gnu-linux.
> > With its initial commit in 2010, Joern had Go in the
> > --enable-languages list in contrib/config-list.mk .  This used to
> > work (read: build succeeded), even if Go wouldn't work (or wasn't
> > built silently, I didn't check.)
> >
> >   With this slight change in behavior, we'd probably fix
> > config-list.mk to reflect these targets where Go would lead to a
> > configury failure early.
> 
> I think changing config-list.mk is appropriate.

This updates contrib/config-list.mk to build Go for all but
known-non-working targets. A comment to configure{.ac,} is also added.

Ok for mainline?



2014-10-30  Jan-Benedict Glaw  

./contrib
* config-list.mk: Don't build Go for certain targets.

./
* configure.ac: Update comment.
* configure: Regenerate.



diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 94884d9..16900e1 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -95,11 +95,24 @@ make-log-dir: ../gcc/MAINTAINERS
 
 $(LIST): make-log-dir
-mkdir $@
-   (cd $@ && \
-   ../../gcc/configure \
-   --target=$(subst SCRIPTS,`pwd`/../scripts/,$(subst OPT,$(empty) -,$@)) \
-   --enable-werror-always ${host_options} --enable-languages=all,ada,go) \
-   > log/$@-config.out 2>&1
+   (   
\
+   cd $@ &&
\
+   echo $@ &&  
\
+   TGT=`echo $@ | sed -e 's/^\(.*\)OPT.*$$/\1/'` &&
\
+   TGT=`../../gcc/config.sub $$TGT` && 
\
+   case $$TGT in   
\
+   *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*)  
\
+   ADDITIONAL_LANGUAGES="";
\
+   ;;  
\
+   *)  
\
+   ADDITIONAL_LANGUAGES=",go"; 
\
+   ;;  
\
+   esac && 
\
+   ../../gcc/configure 
\
+   --target=$(subst SCRIPTS,`pwd`/../scripts/,$(subst 
OPT,$(empty) -,$@))  \
+   --enable-werror-always ${host_options}  
\
+   --enable-languages=all,ada$$ADDITIONAL_LANGUAGES;   
\
+   ) > log/$@-config.out 2>&1
 
 $(LOGFILES) : log/%-make.out : %
-$(MAKE) -C $< $(TEST) > $@ 2>&1 && rm -rf $

signature.asc
Description: Digital signature


Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

2014-10-30 Thread Chen Gang
On 10/29/14 23:58, Chen Gang wrote:
> On 10/27/14 9:42, Chen Gang wrote:
>> On 10/27/14 2:22, Michael Eager wrote:
>>>
>>> Microblaze-sim provides basic instruction set architecture and memory 
>>> simulation.
>>> There is no operating system support.  (It's also quite old.  I'm not sure
>>> which version of the MB architecture it models, but it is not recent.)
>>>
>>> Microblaze-sim is not a full system simulator, like QEMU.  To be able to
>>> run a program which requires glibc, you need to be able to boot a full Linux
>>> image on the simulator, which microblaze-sim cannot do.  QEMU models an
>>> entire processor and can boot a Linux image.
>>>
> 
> At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
> with simple ramfs successfully. Via modify ramfs, can run hello world
> program with static glibc (built by upstream mc_gcc), successfully.
> 

After copy the ramfs' "/lib" and "/usr/lib" to outside, build the hello
world program again with the dynamic glibc, then put it to ramfs. The
hello world program with dynamic glibc can run correctly inside qemu :-)

Next, I need focus on networking (I have found qemu related device, and
kernel related device, and I also know, it needs telnetd in busy box).
But sorry, it seems I can not finish within this month :-(

 - I wasted much time resources on choosing qemu or sim, next I should
   notice about it (do not waste time, again).

 - and another excuse is: I have to do it in my free time (within 2.5
   hours per day, in average). My current job is not related with it
   (at present, it is about Global Platform Java applet for iPhone OS).

Next month:

 - I should finish microblaze qemu test under DejaGNU, should finish
   within next month (2014-11-30).

 - I also shall start tile cross compiling for gcc/binutils, and use it
   to Linux kernel, and test it with qemu. I shall try to finish them
   within 2 months (finish before 2014-12-31).

 - At least, finish 1 patch for gcc, 1 patch for binutils, 1 patch for
   qemu/kvm/xen, 3 patches for kernel, within next month (2014-11-30).


Welcome any ideas, suggestions or completions.

Thanks.

>  - For ramfs:
> 
>wget 
> http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz
> 
>  - Related qemu command:
> 
>./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>  -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>  -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic
> 
> Next, I shall try to let our gdb and DejaGNU work for it:
> 
>  - How to let qemu support network and rsh (ramfs need telnetd, kernel
>may need related driver, and qemu related hardware need be tested).
> 
>  - Let gdb work for it, then config DejaGNU (need we test the program
>with dynamic glib, it will be fail now for not match glibc version
>in ramfs).
> 
>  - At last, run our test.
> 
> It seems, still many things need trying. Welcome any ideas, suggestions,
> and completions for it (especially for ramfs network and/or glibc, and
> DejaGNU configuration ...).
> 
> 
> Thanks.
> 
>>
>> OK, thank you very much, I shall rewind to qemu, and should try my best
>> to finish within within this month.
>>
>>
> 
> 
> Thanks
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed


Re: genmatch infinite loop during bootstrap on AIX

2014-10-30 Thread David Edelsohn
On Thu, Oct 30, 2014 at 4:51 AM, Richard Biener
 wrote:
> On Wed, Oct 29, 2014 at 6:13 PM, David Edelsohn  wrote:
>> On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
>>  wrote:
>>
>>> Because only genmatch calls functions from libstdc++.  Btw, why
>>> would genmatch miscompile an empty function or the call to it?
>>
>> I tried bootstrapping with libstdc++ built without the AIX ld "-G"
>> flag and that is succeeding.
>>
>> "-G" produces a shared object for use with SVR4-style runtime linking,
>> so this version of libstdc++ no longer allows runtime function
>> interposition, e.g., operator new, although it is not used frequently.
>> Something about the GCC-produced tail calls is interacting badly with
>> that feature.
>>
>> Note that this makes GCC bootstrap on AIX very fragile at the moment
>> because it depends on how libstdc++ was built in previous releases.  I
>> can bootstrap with GCC 4.6.3 and 4.8.1 but not with 4.7.3, 4.8.0, nor
>> 4.9.0.  A problematic libstdc++ from earlier releases causes genmatch
>> to loop in stage 1.
>
> I see.  A bootstrap with IPA ICF disabled did not succeed but runs into
> the same issue in stage2.  So I wonder if the issue is latent for much
> longer and genmatch just exposes it now.
>
> I'll see if I can remove the use of std::map from genmatch as a
> workaround.

I assume that this is a pervasive issue in the interaction between GCC
optimizations and AIX -G linker option. Something expects the second
call to point to a different implementation. I don't know if the
address in the TOC (GOT) is wrong or something expects the second call
to use a different TOC, but there is a circular reference.

I am going to apply a patch to GCC to not build libstdc++ with -G.  I
also will apply it to GCC 4.9 branch.  I was hoping that it could be
included in GCC 4.9.2, but I needed to test it thoroughly and Jakub
beat me with the release.

- David


[PATCH, committed] AIX libstdc++ configure.host LD_FLAGS

2014-10-30 Thread David Edelsohn
AIX has been unable to bootstrap since the match-and-simplify merge.
Richard Biener and I tracked this back to a bad interaction between a
GCC optimization and the AIX linker -G option to allow for SVR4-style
runtime linking.

The following patch removes the linker option from the libstdc++
build.  This will prevent runtime function interposition, e.g.
overriding operator new, when using libstdc++, but that is rarely
needed.

This patch also uses the default atomic support

Bootstrapped on powerpc-ibm-aix7.1.0.0

2014-10-30  David Edelsohn  

* configure.host (aix5+): New stanza.
(aix4.3+): Do not use -G in link command.

Index: configure.host
===
--- configure.host  (revision 216851)
+++ configure.host  (working copy)
@@ -212,14 +212,20 @@
 # CPU-specifc, set those here too.
 # THIS TABLE IS SORTED.  KEEP IT THAT WAY.
 case "${host_os}" in
-  aix4.[3456789]* | aix[56789]*)
+  aix[56789]*)
+# Newer versions of AIX only support PowerPC architecture, so use
+# atomic instructions directly.
+os_include_dir="os/aix"
+atomicity_dir="cpu/generic"
+atomic_word_dir="os/aix"
+;;
+  aix4.[3456789]*)
 # We set os_include_dir to os/aix only on AIX 4.3 and newer, but
 # os/aix/atomicity.h works on earlier versions of AIX 4.*, so we
 # explicitly duplicate the directory for 4.[<3].
 os_include_dir="os/aix"
 atomicity_dir="os/aix"
 atomic_word_dir="os/aix"
-OPT_LDFLAGS="-Wl,-G"
 ;;
   aix4.*)
 os_include_dir="os/generic"


Re: [Ping] Port of VTV for Cygwin and MinGW

2014-10-30 Thread Patrick Wollgast
Since I haven't heard back for quite a while, I wanted to ask what the
current stat of the patch is.

Is the patch from the last mail approved (
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01524.html ), or should
the matters discussed further?

regards,
Patrick


RE: [Patch] MIPS configuration patch

2014-10-30 Thread Moore, Catherine


> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Thursday, October 23, 2014 4:37 PM
> To: matthew.fort...@imgtec.com; Moore, Catherine; gcc-
> patc...@gcc.gnu.org
> Subject: [Patch] MIPS configuration patch
> 
> Here is another patch to reduce the differences between the 32 bit MIPS and
> 64 bit MIPS configuration.  This patch combines the two case entries in
> config.gcc into one entry so the header file list and other settings don't 
> have
> to be handled twice.
> 
> This patch should not change the build for any MIPS target except that,
> before this patch, the gnu_ld and gas variables were explicitly set to yes for
> MIPS64 targets but not for MIPS32 targets.  I don't know why this difference
> exists but it shouldn't matter for builds that are on linux because the
> variables were getting set to 'yes' anyway when using the GNU linker and
> assembler.  I don't think anyone builds a linux target that does not use 
> these.
> I chose to put the settings in (matching MIPS64) but I don't think removing
> them would cause any problems if we want to do that.
> 

Hi Steve,
The gnu_ld and gas settings can be removed altogether.  They are set earlier 
for all linux-targets:

*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* | 
*-*-kopensolaris*-gnu)
  extra_options="$extra_options gnu-user.opt"
  gas=yes
  gnu_ld=yes
  case ${enable_threads} in
"" | yes | posix) thread_file='posix' ;;
  Esac

This patch is OK, with that change.
Thanks,
Catherine


> 
> 
> 2014-10-23  Steve Ellcey  
> 
>   * config.gcc (mips*-*-linux*): Combine 32 and 64 bit cases.
> 
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc index 626..8bc59bf 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1945,41 +1945,46 @@ mips*-mti-linux*)
>   gnu_ld=yes
>   gas=yes
>   ;;
> -mips64*-*-linux* | mipsisa64*-*-linux*)
> +mips*-*-linux*)  # Linux MIPS, either endian.
>   tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h glibc-
> stdint.h ${tm_file} mips/gnu-user.h mips/linux.h mips/linux-common.h"
>   extra_options="${extra_options} linux-android.opt"
> - tmake_file="${tmake_file} mips/t-linux64"
> - tm_defines="${tm_defines} MIPS_ABI_DEFAULT=ABI_N32"
>   case ${target} in
> + mipsisa32r2*)
> + tm_defines="${tm_defines}
> MIPS_ISA_DEFAULT=33"
> + ;;
> + mipsisa32*)
> + tm_defines="${tm_defines}
> MIPS_ISA_DEFAULT=32"
> + ;;
>   mips64el-st-linux-gnu)
> + tm_defines="${tm_defines}
> MIPS_ABI_DEFAULT=ABI_N32"
>   tm_file="${tm_file} mips/st.h"
>   tmake_file="${tmake_file} mips/t-st"
> + enable_mips_multilibs="yes"
>   ;;
>   mips64octeon*-*-linux*)
> + tm_defines="${tm_defines}
> MIPS_ABI_DEFAULT=ABI_N32"
>   tm_defines="${tm_defines}
> MIPS_CPU_STRING_DEFAULT=\\\"octeon\\\""
>   target_cpu_default=MASK_SOFT_FLOAT_ABI
> + enable_mips_multilibs="yes"
>   ;;
>   mipsisa64r2*-*-linux*)
> + tm_defines="${tm_defines}
> MIPS_ABI_DEFAULT=ABI_N32"
>   tm_defines="${tm_defines}
> MIPS_ISA_DEFAULT=65"
> + enable_mips_multilibs="yes"
> + ;;
> + mips64*-*-linux* | mipsisa64*-*-linux*)
> + tm_defines="${tm_defines}
> MIPS_ABI_DEFAULT=ABI_N32"
> + enable_mips_multilibs="yes"
>   ;;
>   esac
> - gnu_ld=yes
> - gas=yes
> - ;;
> -mips*-*-linux*)  # Linux MIPS, either endian.
> - tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h glibc-
> stdint.h ${tm_file} mips/gnu-user.h mips/linux.h"
> - extra_options="${extra_options} linux-android.opt"
>   if test x$enable_targets = xall; then
> + enable_mips_multilibs="yes"
> + fi
> + if test x$enable_mips_multilibs = xyes; then
>   tmake_file="${tmake_file} mips/t-linux64"
>   fi
> - tm_file="${tm_file} mips/linux-common.h"
> - case ${target} in
> -mipsisa32r2*)
> - tm_defines="${tm_defines} MIPS_ISA_DEFAULT=33"
> -;;
> -mipsisa32*)
> - tm_defines="${tm_defines} MIPS_ISA_DEFAULT=32"
> -esac
> + gnu_ld=yes
> + gas=yes
>   ;;
>  mips*-mti-elf*)
>   tm_file="elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/n32-elf.h
> mips/sde.h mips/mti-elf.h"


Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I

2014-10-30 Thread Ian Taylor
On Thu, Oct 30, 2014 at 12:25 AM, Dominik Vogt  wrote:
> On Wed, Oct 29, 2014 at 10:16:40AM -0700, Ian Taylor wrote:
>> Thanks.  Part of the problem is that the m68k max alignment is 16
>> bits, but the godump test expects it to be at least 64 bits.  This is
>> BIGGEST_ALIGNMENT in config/m68k/m68k.h.  Another part of the problem
>> seems to be that structs are sometimes aligned to 16 bits although
>> there is no obvious reason for that.  I'm not sure where that is
>> coming from.
>
> Hm, the test cases make assumptions about the Abi (structure
> padding and alignment) that are true on x86, x64_64 and s390[x].
> That may not be the case on other platforms and hence the tests
> fail.  Another candidate for test failures is the effect of
> bitfields (named or anonymous) on structure layout.
>
>> We could disable the test on m68k or make it more accepting.
>
> Since the point of some of the tests is to make sure that the Go
> structure layout matches the C layout, making the tests accept
> deviations seems to be rather pointless.  It's possible to add
> target selectors to all the "scan-file" lines, but that is a lot
> of work and will likely become unmaintainable very soon when more
> platforms need to be added.  Personally I cannot provide fixed
> tests for all the Abis either, so my suggestion is to "xfail" the
> test on all targets except s390[x] and x86_64 and leave it to the
> people who know the other platforms to decide whether the test
> should work there or how the test could be modified to work.
>
> See attached patch.

I don't mind skipping the test on other platforms, but xfail is not
correct.  When an xfail test passes, we get an XPASS error from the
testsuite.  We need dg-skip-if.  I committed this patch.

Ian


2014-10-30  Dominik Vogt  

* gcc.misc-tests/godump-1.c: Skip -fdump-go-spec tests for all
platforms except s390[x] and x86_64.
Index: gcc.misc-tests/godump-1.c
===
--- gcc.misc-tests/godump-1.c   (revision 216840)
+++ gcc.misc-tests/godump-1.c   (working copy)
@@ -2,6 +2,7 @@
 
 /* { dg-options "-c -fdump-go-spec=godump-1.out" } */
 /* { dg-do compile } */
+/* { dg-skip-if "not supported for target" { ! "s390*-*-* x86_64-*-*" } } */
 
 #include 
 


[PATCH AVX512] Fix dg.torture tests with avx512

2014-10-30 Thread Ilya Tocar
Hi,

I've run gcc.dg/torture/* tests with -mavx512bw -mavx512vl -mavx512dq
flags, and got a bunch of fails (mostly in permutes autogen).
Patch below fixes them.
Ok for trunk?

2014-10-30  Ilya Tocar  

* config/i386/i386.c (expand_vec_perm_pshufb): Try vpermq/vpermd
for 512-bit wide modes.
(expand_vec_perm_1): Use correct versions of patterns.
* config/i386/sse.md (avx512f_vec_dup__1): New.
(vashr3): Split V8HImode and V16QImode.

---
 gcc/config/i386/i386.c | 59 --
 gcc/config/i386/sse.md | 54 ++---
 2 files changed, 98 insertions(+), 15 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 71a4f6a..74ff894 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -45889,6 +45889,42 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
{
  if (!TARGET_AVX512BW)
return false;
+
+ /* If vpermq didn't work, vpshufb won't work either.  */
+ if (d->vmode == V8DFmode || d->vmode == V8DImode)
+   return false;
+
+ vmode = V64QImode;
+ if (d->vmode == V16SImode
+ || d->vmode == V32HImode
+ || d->vmode == V64QImode)
+   {
+ /* First see if vpermq can be used for
+V16SImode/V32HImode/V64QImode.  */
+ if (valid_perm_using_mode_p (V8DImode, d))
+   {
+ for (i = 0; i < 8; i++)
+   perm[i] = (d->perm[i * nelt / 8] * 8 / nelt) & 7;
+ if (d->testing_p)
+   return true;
+ target = gen_reg_rtx (V8DImode);
+ if (expand_vselect (target, gen_lowpart (V8DImode, d->op0),
+ perm, 8, false))
+   {
+ emit_move_insn (d->target,
+ gen_lowpart (d->vmode, target));
+ return true;
+   }
+ return false;
+   }
+
+ /* Next see if vpermd can be used.  */
+ if (valid_perm_using_mode_p (V16SImode, d))
+   vmode = V16SImode;
+   }
+ /* Or if vpermps can be used.  */
+ else if (d->vmode == V16SFmode)
+   vmode = V16SImode;
  if (vmode == V64QImode)
{
  /* vpshufb only works intra lanes, it is not
@@ -45908,6 +45944,9 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
   if (vmode == V8SImode)
 for (i = 0; i < 8; ++i)
   rperm[i] = GEN_INT ((d->perm[i * nelt / 8] * 8 / nelt) & 7);
+  else if (vmode == V16SImode)
+for (i = 0; i < 16; ++i)
+  rperm[i] = GEN_INT ((d->perm[i * nelt / 16] * 16 / nelt) & 15);
   else
 {
   eltsz = GET_MODE_SIZE (GET_MODE_INNER (d->vmode));
@@ -45946,8 +45985,14 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
emit_insn (gen_avx512bw_pshufbv64qi3 (target, op0, vperm));
   else if (vmode == V8SFmode)
emit_insn (gen_avx2_permvarv8sf (target, op0, vperm));
-  else
+  else if (vmode == V8SImode)
emit_insn (gen_avx2_permvarv8si (target, op0, vperm));
+  else if (vmode == V16SFmode)
+   emit_insn (gen_avx512f_permvarv16sf (target, op0, vperm));
+  else if (vmode == V16SImode)
+   emit_insn (gen_avx512f_permvarv16si (target, op0, vperm));
+  else
+   gcc_unreachable ();
 }
   else
 {
@@ -46001,21 +46046,21 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
{
case V64QImode:
  if (TARGET_AVX512BW)
-   gen = gen_avx512bw_vec_dupv64qi;
+   gen = gen_avx512bw_vec_dup_v64qi_1;
  break;
case V32QImode:
  gen = gen_avx2_pbroadcastv32qi_1;
  break;
case V32HImode:
  if (TARGET_AVX512BW)
-   gen = gen_avx512bw_vec_dupv32hi;
+   gen = gen_avx512bw_vec_dup_v32hi_1;
  break;
case V16HImode:
  gen = gen_avx2_pbroadcastv16hi_1;
  break;
case V16SImode:
  if (TARGET_AVX512F)
-   gen = gen_avx512f_vec_dupv16si;
+   gen = gen_avx512f_vec_dup_v16si_1;
  break;
case V8SImode:
  gen = gen_avx2_pbroadcastv8si_1;
@@ -46028,18 +46073,18 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
  break;
case V16SFmode:
  if (TARGET_AVX512F)
-   gen = gen_avx512f_vec_dupv16sf;
+   gen = gen_avx512f_vec_dup_v16sf_1;
  break;
case V8SFmode:
  gen = gen_avx2_vec_dupv8sf_1;
  break;
case V8DFmode:
  if (TARGET_AVX512F)
-   gen = gen_avx512f_vec_dupv8df;
+   gen = gen_avx512f_vec_dup_v8df_1;
  break;
case V8DImode:
   

Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I

2014-10-30 Thread Uros Bizjak
Hello!

> I don't mind skipping the test on other platforms, but xfail is not
> correct.  When an xfail test passes, we get an XPASS error from the
> testsuite.  We need dg-skip-if.  I committed this patch.
>
>
> 2014-10-30  Dominik Vogt  
>
> * gcc.misc-tests/godump-1.c: Skip -fdump-go-spec tests for all
> platforms except s390[x] and x86_64.

 /* { dg-options "-c -fdump-go-spec=godump-1.out" } */
 /* { dg-do compile } */
+/* { dg-skip-if "not supported for target" { ! "s390*-*-* x86_64-*-*" } } */

x86_64 also needs && lp64, otherwise -m32 will defeat this condition.

Uros.


Re: [PATCH] config-list.mk: Build Go only for supported targets (was: Patch RFA: Top-level configure patch: disable go on systems where it doesn't work)

2014-10-30 Thread Ian Taylor
On Thu, Oct 30, 2014 at 6:19 AM, Jan-Benedict Glaw  wrote:
>
> This updates contrib/config-list.mk to build Go for all but
> known-non-working targets. A comment to configure{.ac,} is also added.



> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index 94884d9..16900e1 100644
> --- a/contrib/config-list.mk
> +++ b/contrib/config-list.mk
> @@ -95,11 +95,24 @@ make-log-dir: ../gcc/MAINTAINERS
>
>  $(LIST): make-log-dir
> -mkdir $@
> -   (cd $@ && \
> -   ../../gcc/configure \
> -   --target=$(subst SCRIPTS,`pwd`/../scripts/,$(subst OPT,$(empty) 
> -,$@)) \
> -   --enable-werror-always ${host_options} --enable-languages=all,ada,go) 
> \
> -   > log/$@-config.out 2>&1
> +   ( 
>   \
> +   cd $@ &&  
>   \
> +   echo $@ &&
>   \
> +   TGT=`echo $@ | sed -e 's/^\(.*\)OPT.*$$/\1/'` &&  
>   \
> +   TGT=`../../gcc/config.sub $$TGT` &&   
>   \

This isn't necessary.  The OPT bits will be matched by the * at the
end of the cases anyhow.  You can just write
 case $@ in

This is OK with that change.

Thanks for doing it.

Ian


Make soft-fp symbols into compat symbols for powerpc*-*-linux*

2014-10-30 Thread Joseph S. Myers
Continuing preparations for implementing
TARGET_ATOMIC_ASSIGN_EXPAND_FENV for powerpc*-*-linux* soft-float and
e500, this patch makes soft-fp symbols used for those targets into
compat symbols when building with glibc >= 2.19, so that they are only
in shared libgcc for existing binaries requiring them, not in static
libgcc and not available for new links using shared libgcc.  Instead,
new links will get the symbols from libc, which has exported all of
them since 2.19.  (Actually all the symbols were exported from glibc
since 2.4, but some of them were exported by glibc as compat symbols
only - because of a confusion between deliberately present soft-fp
symbols and old accidental reexports of libgcc functions from glibc
2.0 - until 2.19.)

This allows user floating-point arithmetic to interoperate properly
with the state handled by  functions, whether software state
(for soft-float; TLS variables that don't form a public part of
glibc's ABI, so can only be accessed directly by functions within
glibc) or hardware state (for e500 - the copies of the soft-fp
functions in glibc being built to interoperate with the hardware state
whereas those in libgcc aren't).  Previously only glibc's own
functions, and those operations done in hardware on e500, properly
worked with that state, not direct floating-point arithmetic
operations that were implemented in software.

The intended next step is the actual TARGET_ATOMIC_ASSIGN_EXPAND_FENV
implementation.

The test of glibc >= 2.19 uses the same --with-glibc-version configure
option as in the gcc/ directory (but differently implemented; in gcc/
the fallback is to examine headers to find the version, while in
libgcc/ we can use compile for the target and so use AC_COMPUTE_INT).
The TARGET_ATOMIC_ASSIGN_EXPAND_FENV implementation will also only do
anything for glibc >= 2.19, as it will depend on generating calls to
functions __atomic_feholdexcept __atomic_feclearexcept
__atomic_feupdateenv that were added in 2.19 for that purpose (even
for e500, inline code is not readily possible because of the need to
make prctl syscalls from the implementation of these functions).

In order to make symbols compat symbols, the soft-fp files need
wrapping with generated wrappers including asm .symver directives,
which need to name the symbol version in question.  This is extracted
by an awk script from an intermediate stage of generating the .map
file for linking libgcc (that .map itself depends on the objects that
go into the library, so can't be used for this purpose as that would
mean a circular dependency); the extraction is not fully general
regarding the features available in .map generation, but suffices for
the present purpose.

It would make sense for hardfp.c symbols to be compat symbols as well
(in the cases where hardfp.c gets used, the functions in question
should not be used for new links), but this isn't required for the
present purpose, which is only concerned with ensuring that where
functions that should be affected by rounding modes or exceptions get
used, those functions are actually affected by those rounding modes or
exceptions.

Tested with no regressions with cross to powerpc-linux-gnu
(soft-float); c11-atomic-exec-5.c moves from UNSUPPORTED to FAIL, as
expected, now that floating-point arithmetic in user programs uses the
same state as  functions, so the fenv_exceptions test passes,
but TARGET_ATOMIC_ASSIGN_EXPAND_FENV isn't yet implemented.  (For
e500, c11-atomic-exec-5.c was already FAILing, as enough operations
worked with the hardware state for the fenv_exceptions effective
target test to pass.)  Also verified that the exported symbols and
versions are unchanged, with the expected symbols becoming compat
symbols at the same versions, and that with --with-glibc-version=2.18
the symbols remain normal rather than compat symbols.  OK to commit?

2014-10-30  Joseph Myers  

* Makefile.in (libgcc.map.in): New target.
(libgcc.map): Use libgcc.map.in.
* config/t-softfp (softfp_compat): New variable to be set by
users.
[$(softfp_compat) = y] (softfp_map_dep, softfp_set_symver): New
variables.
[$(softfp_compat) = y] (softfp_file_list): Use files in the build
directory.
[$(softfp_compat) = y] ($(softfp_file_list)): Generate wrappers
that use compat symbols and disable all code unless [SHARED].
* config/t-softfp-compat: New file.
* find-symver.awk: New file.
* configure.ac (--with-glibc-version): New configure option.
(ppc_fp_compat): New variable set for powerpc*-*-linux*.
* configure: Regenerate.
* config.host (powerpc*-*-linux*): Use ${ppc_fp_compat} for
soft-float and e500.

Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in  (revision 216835)
+++ libgcc/Makefile.in  (working copy)
@@ -922,12 +922,16 @@
 
 # Map-file generation.
 ifneq ($(SHLIB_MKMAP),)
-libgcc.map: $(S

Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I

2014-10-30 Thread Ian Taylor
On Thu, Oct 30, 2014 at 8:05 AM, Uros Bizjak  wrote:
>
>  /* { dg-options "-c -fdump-go-spec=godump-1.out" } */
>  /* { dg-do compile } */
> +/* { dg-skip-if "not supported for target" { ! "s390*-*-* x86_64-*-*" } } */
>
> x86_64 also needs && lp64, otherwise -m32 will defeat this condition.

Thanks.  I committed this patch.

Ian


2014-10-30  Ian Lance Taylor  

* gcc.misc-tests/godump-1.c: Skip if ! lp64.
Index: gcc.misc-tests/godump-1.c
===
--- gcc.misc-tests/godump-1.c   (revision 216936)
+++ gcc.misc-tests/godump-1.c   (working copy)
@@ -3,6 +3,7 @@
 /* { dg-options "-c -fdump-go-spec=godump-1.out" } */
 /* { dg-do compile } */
 /* { dg-skip-if "not supported for target" { ! "s390*-*-* x86_64-*-*" } } */
+/* { dg-skip-if "not supported for target" { ! lp64 } } */
 
 #include 
 


Re: [PING^2][PATCH] Warn about unclosed pragma omp declare target.

2014-10-30 Thread Ilya Tocar
Ping.
On 20 Oct 19:26, Ilya Tocar wrote:
> Ping.
> 
> On 02 Oct 17:38, Ilya Tocar wrote:
> > Ping.
> > On 15 Aug 16:26, Ilya Tocar wrote:
> > > Ping.
> > > 
> > > On 29 Jul 18:45, Ilya Tocar wrote:
> > > > Hi,
> > > > 
> > > > As discussed here in https://gcc.gnu.org/ml/gcc/2014-01/msg00189.html
> > > > Gcc should complain about pragma omp declare target without
> > > > corresponding pragma omp end declare target. This patch adds a warning
> > > > for those cases.
> > > > Bootstraps/passes make-check.
> > > > Ok for trunk?
> > > > 
> > > > ChangeLog:
> > > > 
> > > > 2014-07-29  Ilya Tocar  
> > > > 
> > > > * c-decl.c (omp_declare_target_location_stack): New.
> > > > * c-lang.h (omp_declare_target_location_stack): Declare.
> > > > * c-parser.c (warn_unclosed_pragma_omp_target): New.
> > > > (c_parser_translation_unit): Call it.
> > > > (c_parser_omp_declare_target): Remeber location.
> > > > (c_parser_omp_end_declare_target): Forget location.
> > > > 
> > > > And ChangeLog for testsuite:
> > > > 
> > > > 2014-07-29  Ilya Tocar  
> > > > 
> > > > * gcc.dg/gomp//target-3.c: New testcase.
> > > > 
> > > > ---
> > > >  gcc/c/c-decl.c   |  3 +++
> > > >  gcc/c/c-lang.h   |  3 +++
> > > >  gcc/c/c-parser.c | 22 +-
> > > >  gcc/testsuite/gcc.dg/gomp/target-3.c | 33 
> > > > +
> > > >  4 files changed, 60 insertions(+), 1 deletion(-)
> > > >  create mode 100644 gcc/testsuite/gcc.dg/gomp/target-3.c
> > > > 
> > > > diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> > > > index 2a4b439..2dd5b2c 100644
> > > > --- a/gcc/c/c-decl.c
> > > > +++ b/gcc/c/c-decl.c
> > > > @@ -158,6 +158,9 @@ enum machine_mode c_default_pointer_mode = VOIDmode;
> > > >  /* If non-zero, implicit "omp declare target" attribute is added into 
> > > > the
> > > > attribute lists.  */
> > > >  int current_omp_declare_target_attribute;
> > > > +
> > > > +/* Holds locations of currently open "omp declare target" pragmas.  */
> > > > +vec omp_declare_target_location_stack;
> > > >  
> > > >  /* Each c_binding structure describes one binding of an identifier to
> > > > a decl.  All the decls in a scope - irrespective of namespace - are
> > > > diff --git a/gcc/c/c-lang.h b/gcc/c/c-lang.h
> > > > index e974906..cef995c 100644
> > > > --- a/gcc/c/c-lang.h
> > > > +++ b/gcc/c/c-lang.h
> > > > @@ -59,4 +59,7 @@ struct GTY(()) language_function {
> > > > attribute lists.  */
> > > >  extern GTY(()) int current_omp_declare_target_attribute;
> > > >  
> > > > +/* Holds locations of currently open "omp declare target" pragmas.  */
> > > > +extern vec omp_declare_target_location_stack;
> > > > +
> > > >  #endif /* ! GCC_C_LANG_H */
> > > > diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> > > > index e32bf04..0b96fe9 100644
> > > > --- a/gcc/c/c-parser.c
> > > > +++ b/gcc/c/c-parser.c
> > > > @@ -1255,6 +1255,8 @@ static bool c_parser_cilk_verify_simd (c_parser 
> > > > *, enum pragma_context);
> > > >  static tree c_parser_array_notation (location_t, c_parser *, tree, 
> > > > tree);
> > > >  static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
> > > >  
> > > > +static void warn_unclosed_pragma_omp_target ();
> > > > +
> > > >  /* Parse a translation unit (C90 6.7, C99 6.9).
> > > >  
> > > > translation-unit:
> > > > @@ -1290,6 +1292,8 @@ c_parser_translation_unit (c_parser *parser)
> > > > }
> > > >while (c_parser_next_token_is_not (parser, CPP_EOF));
> > > >  }
> > > > +
> > > > +  warn_unclosed_pragma_omp_target ();
> > > >  }
> > > >  
> > > >  /* Parse an external declaration (C90 6.7, C99 6.9).
> > > > @@ -13068,8 +13072,10 @@ c_finish_omp_declare_simd (c_parser *parser, 
> > > > tree fndecl, tree parms,
> > > >  static void
> > > >  c_parser_omp_declare_target (c_parser *parser)
> > > >  {
> > > > +  location_t loc = c_parser_peek_token (parser)->location;
> > > >c_parser_skip_to_pragma_eol (parser);
> > > >current_omp_declare_target_attribute++;
> > > > +  omp_declare_target_location_stack.safe_push (loc);
> > > >  }
> > > >  
> > > >  static void
> > > > @@ -13104,7 +13110,10 @@ c_parser_omp_end_declare_target (c_parser 
> > > > *parser)
> > > >  error_at (loc, "%<#pragma omp end declare target%> without 
> > > > corresponding "
> > > >"%<#pragma omp declare target%>");
> > > >else
> > > > -current_omp_declare_target_attribute--;
> > > > +{
> > > > +  current_omp_declare_target_attribute--;
> > > > +  omp_declare_target_location_stack.pop ();
> > > > +}
> > > >  }
> > > >  
> > > >  
> > > > @@ -14267,4 +14276,15 @@ c_parser_array_notation (location_t loc, 
> > > > c_parser *parser, tree initial_index,
> > > >return value_tree;
> > > >  }
> > > >  
> > > > +static void
> > > > +warn_unclosed_pragma_omp_target ()
> > > > +{
> > > > +  int i;
> > > > +  for (i = 0; i < c

[PATCH] Fix some missing CASE_CONVERTs, improve genmatch side-effect handling

2014-10-30 Thread Richard Biener
The following replaces NOP_EXPR uses with CASE_CONVERT appropriately
and improves genmatch handling of side-effects for
captures used in C expressions.

Bootstrapped and tested on x86_64-unknow-linux-gnu, applied.

Richard.

2014-10-30  Richard Biener  

* genmatch.c (capture_info::walk_c_expr): Ignore capture
uses inside TREE_TYPE ().
* gimple-ssa-strength-reduction.c (stmt_cost): Use CASE_CONVERT.
(find_candidates_dom_walker::before_dom_children): Likewise.
(replace_mult_candidate): Use CONVERT_EXPR_CODE_P.
(replace_profitable_candidates): Likewise.
* tree-ssa-dom.c (initialize_hash_element): Canonicalize
CONVERT_EXPR_CODE_P to CONVERT_EXPR.
* convert.c (convert_to_integer): Use CASE_CONVERT.


p2
Description: Binary data


[PATCH] Remove std::map use from genmatch

2014-10-30 Thread Richard Biener
The following removes std::map use from genmatch, avoiding an AIX
issue (and also making the code more GCC-ish).  I had to add
an elements() member to hash_map and implement some GGC
stubs.  Not too bad I guess.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2014-10-30  Richard Biener  

* genmatch.c: Remove ,  and  includes.
Include ggc.h and hash-map.h.
(ggc_internal_cleared_alloc): Provide stub definition.
(ggc_free): Likewise.
(struct capture_id_map_hasher): New traits for hash_map.
(cid_map_t): New typedef.
(everywhere else): Replace std::map use with cid_map_t.
* hash-map.h (hash_map::elements): New member function.
* Makefile.in (build/genmatch.o): Add $(HASH_TABLE_H),
hash-map.h and $(GGC_H) as dependency.


p10
Description: Binary data


[patch] flatten/adjust optabs.h

2014-10-30 Thread Andrew MacLeod
This patch "adjusts" optabs.h.  which was really sub-work of looking at 
expr.h.


I moved the prototypes from expr.h to optabs.h that belong there, and 
realigned the stuff in optabs.h to be in the same order as the .c file.
I also moved gen_move_insn from optabs.c to expr.c... a number of new 
files would have required optabs.h to compile just for that funciton, 
and gen_move_insn primarily calls emit-move_insn_1 which is defined in 
expr.c anyway.. so it makes sense to be there.


the one thing Im on the fence about is insn-opinit.h.   This is *only* 
included from optabs.h, so I am inclined to leave it as an include from 
optabs.h.  We'd likely just be putting it back there later anyway.


I also moved the first section of optabs.h into genopinit.c... that 
contains the parts which define structures, prototypes and a couple of 
small inlines for things in insn-opinit.c.. so I figured we may as well 
may insn-opinit.h follow the same pattern and list the exports and such 
for insn-opinit.c.Now, ultimately I don't feel strongly about that 
since insn-opinit.h is always included from optabs.h...  if someone 
objects I can move them back out of the generated file.


Other than that, its just more header adjustments.

bootstraps on x86_64-unknown-linux-gnu, testsuite regressions a re 
running (I expect none again) and I'll ruin it through a full set of 
targets from contrib/config-list.mk.

Assuming no issues, ok for trunk?

Andrew


	* optabs.h: Flatten insn-codes.h to source files.  Move some prototypes
	and structs to genopinit.c.  Adjust protyoptypes to match optabs.c.
	* genopinit.c (main): Emit prototypes and structs into insn-opinit.h.
	* optabs.c: (gen_move_insn): Move to expr.c.
	* expr.h: Move protypes and enums to optabs.h.
	* expr.c: (gen_move_insn): Relocate from optabs.c.
	* genemit.c (main): Include insn-codes.h.
	* gengtype.c (open_base_files): Include insn-codes.h.

Index: optabs.h
===
--- optabs.h	(revision 216804)
+++ optabs.h	(working copy)
@@ -20,244 +20,11 @@
 #ifndef GCC_OPTABS_H
 #define GCC_OPTABS_H
 
-#include "insn-codes.h"
 #include "insn-opinit.h"
 
-typedef enum optab_tag optab;
-typedef enum optab_tag convert_optab;
-typedef enum optab_tag direct_optab;
-
-struct optab_libcall_d
-{
-  char libcall_suffix;
-  const char *libcall_basename;
-  void (*libcall_gen) (optab, const char *name,
-		   char suffix, enum machine_mode);
-};
-
-struct convert_optab_libcall_d
-{
-  const char *libcall_basename;
-  void (*libcall_gen) (convert_optab, const char *name,
-		   enum machine_mode, enum machine_mode);
-};
-
-/* Given an enum insn_code, access the function to construct
-   the body of that kind of insn.  */
-#define GEN_FCN(CODE) (insn_data[CODE].genfun)
-
-/* Contains the optab used for each rtx code, and vice-versa.  */
-extern const optab code_to_optab_[NUM_RTX_CODE];
-extern const enum rtx_code optab_to_code_[NUM_OPTABS];
-
-static inline optab
-code_to_optab (enum rtx_code code)
-{
-  return code_to_optab_[code];
-}
-
-static inline enum rtx_code
-optab_to_code (optab op)
-{
-  return optab_to_code_[op];
-}
-
-extern const struct convert_optab_libcall_d convlib_def[NUM_CONVLIB_OPTABS];
-extern const struct optab_libcall_d normlib_def[NUM_NORMLIB_OPTABS];
-
-/* Returns the active icode for the given (encoded) optab.  */
-extern enum insn_code raw_optab_handler (unsigned);
-extern bool swap_optab_enable (optab, enum machine_mode, bool);
-
-/* Target-dependent globals.  */
-struct target_optabs {
-  /* Patterns that are used by optabs that are enabled for this target.  */
-  bool pat_enable[NUM_OPTAB_PATTERNS];
-};
-
-extern struct target_optabs default_target_optabs;
-extern struct target_optabs *this_fn_optabs;
-#if SWITCHABLE_TARGET
-extern struct target_optabs *this_target_optabs;
-#else
-#define this_target_optabs (&default_target_optabs)
-#endif
-
-/* Define functions given in optabs.c.  */
-
-extern rtx expand_widen_pattern_expr (sepops ops, rtx op0, rtx op1, rtx wide_op,
-  rtx target, int unsignedp);
-
-extern rtx expand_ternary_op (enum machine_mode mode, optab ternary_optab,
-			  rtx op0, rtx op1, rtx op2, rtx target,
-			  int unsignedp);
-
-/* Expand a binary operation given optab and rtx operands.  */
-extern rtx expand_binop (enum machine_mode, optab, rtx, rtx, rtx, int,
-			 enum optab_methods);
-
-extern rtx simplify_expand_binop (enum machine_mode mode, optab binoptab,
-  rtx op0, rtx op1, rtx target, int unsignedp,
-  enum optab_methods methods);
-
-extern bool force_expand_binop (enum machine_mode, optab, rtx, rtx, rtx, int,
-enum optab_methods);
-
-/* Expand a binary operation with both signed and unsigned forms.  */
-extern rtx sign_expand_binop (enum machine_mode, optab, optab, rtx, rtx,
-			  rtx, int, enum optab_methods);
-
-/* Generate code to perform an operation on one operand with two results.  */
-extern int expand_

Re: [Ping] [PATCH, 4/10] expand ccmp

2014-10-30 Thread Richard Henderson
On 10/29/2014 03:30 AM, Zhenqiang Chen wrote:
> +
> +bool
> +ccmp_insn_p (rtx object)
> +{
> +  rtx x = PATTERN (object);
> +  if (targetm.gen_ccmp_first
> +  && GET_CODE (x) == SET
> +  && GET_CODE (XEXP (x, 1)) == COMPARE
> +  && (GET_CODE (XEXP (XEXP (x, 1), 0)) == IOR
> +   || GET_CODE (XEXP (XEXP (x, 1), 0)) == AND))
> +return true;
> +  return false;
> +}
> +

With the ifcvt changes I requested, I believe this is now unused.

> +}
> +rtx
> +expand_ccmp_expr (gimple g)

Watch your spacing.  And you're missing the comment before the function.

Otherwise ok.


r~


Re: [PATCH, Pointer Bounds Checker 14/x] Passes [1/n] Expand interfaces

2014-10-30 Thread Ilya Enkovich
On 29 Oct 23:37, Jeff Law wrote:
> On 10/15/14 11:54, Ilya Enkovich wrote:
> >
> >Thanks for review!  I see no more patches not reviewed at all.  I see
> >4 more patches requiring approve before I can start a merge.
> >
> >Two of them are parts of split #14 (Passes): #14.3 (Helper functions)
> >and #14.16 (Reduce bounds lifetime)
> These are fine.  We can revisit LCM/anticipated in the future for
> the bounds lifetime reduction.
> 
> 
> >
> >There is also #32 (hooks for i386 target). It has concern about TBAA
> >which I believe is not a problem in my case because accesses using
> >different types are not mixed.
> OK.  That was the only pending issue with that patch, so it's good
> to go as well.
> 
> >
> >The final one is #33 (MPX ABI).  I still see fail on one benchmark but
> >I don't feel ICE in LRA should prevent patch from been committed.
> Assuming it doesn't fail unless you've turned on MPX, that seems
> reasonable at this stage.  Obviously we'd like to get that fixed
> during the general bugfixing phase.
> 
> As I discussed with Areg, I wanted this stuff to wait until the
> Darwin port had settled a bit after the recent problems.  While
> Darwin isn't happy yet, I think the remaining problems are
> manageable and isolated to the i686 code generator.  So if you could
> bootstrap Darwin 64 bit as a sanity test along with a final
> bootstrap & regression test on x86_64 linux, then I think we're good
> to go.
> 
> jeff
> 
> 

Hi,

I rebased patches on current trunk.  Bootstrap and check are clean on 
linux-x86_64.

Darwin bootstrap has few issues due to IPA ICF pass.  I also found my patches 
introduce an unused variable warning due to conditional code (under #ifdef 
ASM_OUTPUT_DEF) in varasm.  With IPA ICF disabled and this warning fixed Darwin 
64 bootstrap is OK.

ARM cross build revealed another problem with conditional code.  Function 
immed_double_const was put under #if (TARGET_SUPPORTS_WIDE_INT == 0) some time 
ago but I missed it and didn't update my patches.  With this fixed cross build 
is also OK.

Below are required changes.  If these fixes are OK, I'm ready to commit whole 
series (I'm going to commit it as a single patch because didn't test each part 
separately).

Thanks,
Ilya
--
diff --git a/gcc/varasm.c b/gcc/varasm.c
index eb68fd3..40eeb5e 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -5522,7 +5522,6 @@ vec *alias_pairs;
 void
 do_assemble_alias (tree decl, tree target)
 {
-  tree orig_decl = decl;
   tree id;
 
   /* Emulated TLS had better not get this var.  */
@@ -5533,11 +5532,6 @@ do_assemble_alias (tree decl, tree target)
   if (TREE_ASM_WRITTEN (decl))
 return;
 
-  if (TREE_CODE (decl) == FUNCTION_DECL
-  && cgraph_node::get (decl)->instrumentation_clone
-  && cgraph_node::get (decl)->instrumented_version)
-orig_decl = cgraph_node::get (decl)->instrumented_version->decl;
-
   id = DECL_ASSEMBLER_NAME (decl);
   ultimate_transparent_alias_target (&id);
 
@@ -5572,6 +5566,13 @@ do_assemble_alias (tree decl, tree target)
 }
 
 #ifdef ASM_OUTPUT_DEF
+  tree orig_decl = decl;
+
+  if (TREE_CODE (decl) == FUNCTION_DECL
+  && cgraph_node::get (decl)->instrumentation_clone
+  && cgraph_node::get (decl)->instrumented_version)
+orig_decl = cgraph_node::get (decl)->instrumented_version->decl;
+
   /* Make name accessible from other files, if appropriate.  */
 
   if (TREE_PUBLIC (decl) || TREE_PUBLIC (orig_decl))
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 41c616d..04f677e 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -6133,7 +6133,10 @@ init_emit_once (void)
   for (mode = GET_CLASS_NARROWEST_MODE (MODE_POINTER_BOUNDS);
mode != VOIDmode;
mode = GET_MODE_WIDER_MODE (mode))
-const_tiny_rtx[0][mode] = immed_double_const (0, 0, mode);
+{
+  wide_int wi_zero = wi::zero (GET_MODE_PRECISION (mode));
+  const_tiny_rtx[0][mode] = immed_wide_int_const (wi_zero, mode);
+}
 
   pc_rtx = gen_rtx_fmt_ (PC, VOIDmode);
   ret_rtx = gen_rtx_fmt_ (RETURN, VOIDmode);


Re: Make soft-fp symbols into compat symbols for powerpc*-*-linux*

2014-10-30 Thread David Edelsohn
On Thu, Oct 30, 2014 at 11:13 AM, Joseph S. Myers
 wrote:
> Continuing preparations for implementing
> TARGET_ATOMIC_ASSIGN_EXPAND_FENV for powerpc*-*-linux* soft-float and
> e500, this patch makes soft-fp symbols used for those targets into
> compat symbols when building with glibc >= 2.19, so that they are only
> in shared libgcc for existing binaries requiring them, not in static
> libgcc and not available for new links using shared libgcc.  Instead,
> new links will get the symbols from libc, which has exported all of
> them since 2.19.  (Actually all the symbols were exported from glibc
> since 2.4, but some of them were exported by glibc as compat symbols
> only - because of a confusion between deliberately present soft-fp
> symbols and old accidental reexports of libgcc functions from glibc
> 2.0 - until 2.19.)
>
> This allows user floating-point arithmetic to interoperate properly
> with the state handled by  functions, whether software state
> (for soft-float; TLS variables that don't form a public part of
> glibc's ABI, so can only be accessed directly by functions within
> glibc) or hardware state (for e500 - the copies of the soft-fp
> functions in glibc being built to interoperate with the hardware state
> whereas those in libgcc aren't).  Previously only glibc's own
> functions, and those operations done in hardware on e500, properly
> worked with that state, not direct floating-point arithmetic
> operations that were implemented in software.
>
> The intended next step is the actual TARGET_ATOMIC_ASSIGN_EXPAND_FENV
> implementation.
>
> The test of glibc >= 2.19 uses the same --with-glibc-version configure
> option as in the gcc/ directory (but differently implemented; in gcc/
> the fallback is to examine headers to find the version, while in
> libgcc/ we can use compile for the target and so use AC_COMPUTE_INT).
> The TARGET_ATOMIC_ASSIGN_EXPAND_FENV implementation will also only do
> anything for glibc >= 2.19, as it will depend on generating calls to
> functions __atomic_feholdexcept __atomic_feclearexcept
> __atomic_feupdateenv that were added in 2.19 for that purpose (even
> for e500, inline code is not readily possible because of the need to
> make prctl syscalls from the implementation of these functions).
>
> In order to make symbols compat symbols, the soft-fp files need
> wrapping with generated wrappers including asm .symver directives,
> which need to name the symbol version in question.  This is extracted
> by an awk script from an intermediate stage of generating the .map
> file for linking libgcc (that .map itself depends on the objects that
> go into the library, so can't be used for this purpose as that would
> mean a circular dependency); the extraction is not fully general
> regarding the features available in .map generation, but suffices for
> the present purpose.
>
> It would make sense for hardfp.c symbols to be compat symbols as well
> (in the cases where hardfp.c gets used, the functions in question
> should not be used for new links), but this isn't required for the
> present purpose, which is only concerned with ensuring that where
> functions that should be affected by rounding modes or exceptions get
> used, those functions are actually affected by those rounding modes or
> exceptions.
>
> Tested with no regressions with cross to powerpc-linux-gnu
> (soft-float); c11-atomic-exec-5.c moves from UNSUPPORTED to FAIL, as
> expected, now that floating-point arithmetic in user programs uses the
> same state as  functions, so the fenv_exceptions test passes,
> but TARGET_ATOMIC_ASSIGN_EXPAND_FENV isn't yet implemented.  (For
> e500, c11-atomic-exec-5.c was already FAILing, as enough operations
> worked with the hardware state for the fenv_exceptions effective
> target test to pass.)  Also verified that the exported symbols and
> versions are unchanged, with the expected symbols becoming compat
> symbols at the same versions, and that with --with-glibc-version=2.18
> the symbols remain normal rather than compat symbols.  OK to commit?
>
> 2014-10-30  Joseph Myers  
>
> * Makefile.in (libgcc.map.in): New target.
> (libgcc.map): Use libgcc.map.in.
> * config/t-softfp (softfp_compat): New variable to be set by
> users.
> [$(softfp_compat) = y] (softfp_map_dep, softfp_set_symver): New
> variables.
> [$(softfp_compat) = y] (softfp_file_list): Use files in the build
> directory.
> [$(softfp_compat) = y] ($(softfp_file_list)): Generate wrappers
> that use compat symbols and disable all code unless [SHARED].
> * config/t-softfp-compat: New file.
> * find-symver.awk: New file.
> * configure.ac (--with-glibc-version): New configure option.
> (ppc_fp_compat): New variable set for powerpc*-*-linux*.
> * configure: Regenerate.
> * config.host (powerpc*-*-linux*): Use ${ppc_fp_compat} for
> soft-float and e500.

Okay.

Thanks, David


[PATCH][PPC] Skip gcc.target tests with conflicting -mcpu

2014-10-30 Thread Andrew Stubbs
Many of the tests in gcc.target/powerpc specify an explicit -mcpu option 
with dg-options. This is a problem for multilib configurations that use 
-mcpu in their definition; the test commands will list both -mcpu 
options, with the multilib option overriding the test option. This 
causes many bogus test failures, typically with assembler-scan mismatches.


Even when the multilib definition is similar enough that the test might 
pass an assembler test, the conflicting -mcpu options cause multilib 
selection problems which lead to link failures in compile tests.


The attached patch add a dg-skip-if to each affected testcase. This 
checks for conflicting -mcpu options, but allows matching ones.


The 405 and SPE already had a similar mechanism, but using 
dg-require-effective-target with a "nocache" target. I have left those 
tests alone, but chose not to use the same technique because it would 
require a proliferation of new "effective targets" and would only 
achieve the same thing in the end. In any case, those tests will not 
stop the multilib selection problem I mentioned. (There was one SPE test 
that had it's powerpc_spe_nocache test in the wrong place; the patch 
corrects it.)


I'm not completely happy with the result, however. Yes, all my 
false-FAILs have gone away, but a lot of tests that used to pass, by 
chance, have also gone away. Maybe it would be better to XFAIL/XPASS them?


Also, I'm fairly dissatisfied with the current situation where a test 
uses dg-require-effective-target to test the default target, and then 
adds options that would change the result of that test; it can cause a 
test to get skipped when actually it would work fine. Anyway, that's a 
problem for a different day.


OK to commit?

Andrew
2014-10-30  Andrew Stubbs  

	gcc/testsuite/
	* gcc.target/powerpc/pr60102.c: Move dg-skip-if after dg-options.
	* gcc.target/powerpc/swaps-p8-12.c: Skip test if there would be
	conflicting -mcpu options.
	* gcc.target/powerpc/ppc-target-2.c: Likewise.
	* gcc.target/powerpc/cell_builtin-7.c: Likewise.
	* gcc.target/powerpc/dfp-builtin-1.c: Likewise.
	* gcc.target/powerpc/p8vector-builtin-1.c: Likewise.
	* gcc.target/powerpc/ppc-fpconv-7.c: Likewise.
	* gcc.target/powerpc/p8vector-vectorize-1.c: Likewise.
	* gcc.target/powerpc/pr48053-3.c: Likewise.
	* gcc.target/powerpc/vsx-builtin-6.c: Likewise.
	* gcc.target/powerpc/440-nmaclhw-1.c: Likewise.
	* gcc.target/powerpc/pr57744.c: Likewise.
	* gcc.target/powerpc/pr47862.c: Likewise.
	* gcc.target/powerpc/vsx-vectorize-8.c: Likewise.
	* gcc.target/powerpc/recip-1.c: Likewise.
	* gcc.target/powerpc/darwin-longlong.c: Likewise.
	* gcc.target/powerpc/bool2-p8.c: Likewise.
	* gcc.target/powerpc/mmfpgpr.c: Likewise.
	* gcc.target/powerpc/pr60203.c: Likewise.
	* gcc.target/powerpc/direct-move-vint1.c: Likewise.
	* gcc.target/powerpc/bool2-av.c: Likewise.
	* gcc.target/powerpc/pr43154.c: Likewise.
	* gcc.target/powerpc/ppc-fma-2.c: Likewise.
	* gcc.target/powerpc/swaps-p8-5.c: Likewise.
	* gcc.target/powerpc/pr59054.c: Likewise.
	* gcc.target/powerpc/ppc-fpconv-11.c: Likewise.
	* gcc.target/powerpc/440-mullhwu-1.c: Likewise.
	* gcc.target/powerpc/swaps-p8-13.c: Likewise.
	* gcc.target/powerpc/ppc-target-3.c: Likewise.
	* gcc.target/powerpc/cell_builtin-8.c: Likewise.
	* gcc.target/powerpc/dfp-builtin-2.c: Likewise.
	* gcc.target/powerpc/p8vector-builtin-2.c: Likewise.
	* gcc.target/powerpc/ppc-fpconv-8.c: Likewise.
	* gcc.target/powerpc/p8vector-vectorize-2.c: Likewise.
	* gcc.target/powerpc/p8vector-vbpermq.c: Likewise.
	* gcc.target/powerpc/vsx-vectorize-1.c: Likewise.
	* gcc.target/powerpc/bswap64-3.c: Likewise.
	* gcc.target/powerpc/bcd-1.c: Likewise.
	* gcc.target/powerpc/440-mulchwu-1.c: Likewise.
	* gcc.target/powerpc/extend-divide-1.c: Likewise.
	* gcc.target/powerpc/vsx-builtin-7.c: Likewise.
	* gcc.target/powerpc/pr48192.c: Likewise.
	* gcc.target/powerpc/pr52775.c: Likewise.
	* gcc.target/powerpc/p8vector-int128-1.c: Likewise.
	* gcc.target/powerpc/pr58673-1.c: Likewise.
	* gcc.target/powerpc/pr53487.c: Likewise.
	* gcc.target/powerpc/440-nmaclhw-2.c: Likewise.
	* gcc.target/powerpc/recip-2.c: Likewise.
	* gcc.target/powerpc/p8vector-fp.c: Likewise.
	* gcc.target/powerpc/direct-move-vint2.c: Likewise.
	* gcc.target/powerpc/ppc-fma-3.c: Likewise.
	* gcc.target/powerpc/pr57150.c: Likewise.
	* gcc.target/powerpc/pr47251.c: Likewise.
	* gcc.target/powerpc/swaps-p8-6.c: Likewise.
	* gcc.target/powerpc/440-mullhwu-2.c: Likewise.
	* gcc.target/powerpc/bool3-p7.c: Likewise.
	* gcc.target/powerpc/cell_builtin-1.c: Likewise.
	* gcc.target/powerpc/swaps-p8-14.c: Likewise.
	* gcc.target/powerpc/ppc-target-4.c: Likewise.
	* gcc.target/powerpc/440-mulhhw-1.c: Likewise.
	* gcc.target/powerpc/ppc-fpconv-1.c: Likewise.
	* gcc.target/powerpc/440-machhw-1.c: Likewise.
	* gcc.target/powerpc/p8vector-builtin-3.c: Likewise.
	* gcc.target/powerpc/vsx-mass-1.c: Likewise.
	* gcc.target/powerpc/ppc-fpconv-9.c: Likewise.
	* gcc.target/powerpc/p8vector-vectorize-3.

Re: [PATCH x86] Increase PARAM_MAX_COMPLETELY_PEELED_INSNS when branch is costly

2014-10-30 Thread Jan Hubicka
> On Tue, Oct 28, 2014 at 1:07 PM, Evgeny Stupachenko  
> wrote:
> > make check for gcc passed
> >
> > On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko  
> > wrote:
> >> The results are the same for Silvermont.
> >> There are no significant changes on Haswell.
> >> So I agree with Richard, let's enable this x86 wide.
> >>
> >> Bootstrap/ passed.
> >> Make check in progress.
> >> Is it ok?
> >>
> >> 2014-10-25  Evgeny Stupachenko  
> >> * config/i386/i386.c (ix86_option_override_internal): Increase
> >> PARAM_MAX_COMPLETELY_PEELED_INSNS.
> 
> Let's wait for Honza's approval ...

Looking through the emails, it is not clear to me if you re-tested that this 
still
makes the intended speedup with the tree-level loop peeling? (comitted 
2014-10-14).
If it still works as intended, I do not think we have any reason to not change 
the
default in params.def given that even ARM folks are calling for peeling by 
default.

Honza
> 
> Uros.


Re: ptx preliminary rtl patches [1/4]

2014-10-30 Thread Segher Boessenkool
On Thu, Sep 11, 2014 at 03:24:54PM +0200, Bernd Schmidt wrote:
> The nvptx backend is somewhat unusual in that call insns set a pseudo. 
> The combiner is surprised by this and allows combining them into other 
> insns, which remain as INSN rather than CALL_INSN. Aborts ensue.

distribute_notes has code for when I2 is a CALL.  This suggests that
on some other targets there can be useful combinations made, so it
isn't in that case terribly nice to disable all combinations with CALLs
as I0 or I1 or I2.

Or it's dead code :-)


Segher


Re: [PATCH x86] Increase PARAM_MAX_COMPLETELY_PEELED_INSNS when branch is costly

2014-10-30 Thread Evgeny Stupachenko
Yes the speed up is the same. However I'm testing only x86
performance. Potentially we can somehow hurt ARM or others
performance.
GCC already has the tuning enabled for rs6000,s390, spu.

Evgeny

On Thu, Oct 30, 2014 at 8:27 PM, Jan Hubicka  wrote:
>> On Tue, Oct 28, 2014 at 1:07 PM, Evgeny Stupachenko  
>> wrote:
>> > make check for gcc passed
>> >
>> > On Mon, Oct 27, 2014 at 11:10 AM, Evgeny Stupachenko  
>> > wrote:
>> >> The results are the same for Silvermont.
>> >> There are no significant changes on Haswell.
>> >> So I agree with Richard, let's enable this x86 wide.
>> >>
>> >> Bootstrap/ passed.
>> >> Make check in progress.
>> >> Is it ok?
>> >>
>> >> 2014-10-25  Evgeny Stupachenko  
>> >> * config/i386/i386.c (ix86_option_override_internal): Increase
>> >> PARAM_MAX_COMPLETELY_PEELED_INSNS.
>>
>> Let's wait for Honza's approval ...
>
> Looking through the emails, it is not clear to me if you re-tested that this 
> still
> makes the intended speedup with the tree-level loop peeling? (comitted 
> 2014-10-14).
> If it still works as intended, I do not think we have any reason to not 
> change the
> default in params.def given that even ARM folks are calling for peeling by 
> default.
>
> Honza
>>
>> Uros.


Re: [PATCH][PPC] Skip gcc.target tests with conflicting -mcpu

2014-10-30 Thread Mike Stump
On Oct 30, 2014, at 10:25 AM, Andrew Stubbs  wrote:
> Many of the tests in gcc.target/powerpc specify an explicit -mcpu option with 
> dg-options.

So, I think this isn’t the strategy people like for this sort of thing.  The 
problem is default flags.  You can have a certain cpu as a target but no flag 
for it, no flag, no way to skip based upon that flag.

> Also, I'm fairly dissatisfied with the current situation where a test uses 
> dg-require-effective-target to test the default target, and then adds options 
> that would change the result of that test; it can cause a test to get skipped 
> when actually it would work fine. Anyway, that's a problem for a different 
> day.


But, that code works the way you want it to?  If you don’t want to add a flag, 
you don’t.

[PATCH] Optimize UBSAN_NULL checks

2014-10-30 Thread Marek Polacek
This patch tries to optimize away redundant UBSAN_NULL checks.
It walks the statements, looks for UBSAN_NULL calls and keeps
track of pointers and statements checking that pointer in a
hash map.  Now, if we can prove that some UBSAN_NULL stmt is
dominated by other one which requires the same or less strict
alignment, there's no point in keeping this check around and
expanding it.

optimize_checks should be enhanced to handle other {ub,a,t}san
checks as well - which is what I'm going to work on next.

Bootstrapped(-ubsan)/regtested on x86_64-linux, ok for trunk?

2014-10-30  Marek Polacek  

* asan.c (optimize_checks): New function.
(pass_sanopt::execute): Call it.
testsuite/
* c-c++-common/ubsan/align-2.c: Remove dg-output.
* c-c++-common/ubsan/align-4.c: Likewise.
* g++.dg/ubsan/null-1.C: Likewise.
* g++.dg/ubsan/null-2.C: Likewise.

diff --git gcc/asan.c gcc/asan.c
index b4b0822..c06bb49 100644
--- gcc/asan.c
+++ gcc/asan.c
@@ -2707,6 +2707,99 @@ asan_expand_check_ifn (gimple_stmt_iterator *iter, bool 
use_calls)
   return true;
 }
 
+/* Try to remove redundant sanitizer checks in function FUN.  */
+
+void
+optimize_checks (function *fun)
+{
+  basic_block bb;
+
+  /* This map maps a pointer (the first argument of UBSAN_NULL) to
+ a vector of UBSAN_NULL call statements that check this pointer.  */
+  hash_map > *null_check_map = NULL;
+  calculate_dominance_info (CDI_DOMINATORS);
+
+  FOR_EACH_BB_FN (bb, fun)
+{
+  gimple_stmt_iterator gsi;
+  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);)
+   {
+ gimple stmt = gsi_stmt (gsi);
+ bool remove = false;
+
+ if (is_gimple_call (stmt)
+ && gimple_call_internal_p (stmt))
+   switch (gimple_call_internal_fn (stmt))
+ {
+ case IFN_UBSAN_NULL:
+   {
+ gcc_assert (gimple_call_num_args (stmt) == 3);
+ tree ptr = gimple_call_arg (stmt, 0);
+ tree cur_align = gimple_call_arg (stmt, 2);
+ gcc_assert (TREE_CODE (cur_align) == INTEGER_CST);
+
+ if (null_check_map == NULL)
+   null_check_map = new hash_map >;
+
+ auto_vec &v = null_check_map->get_or_insert (ptr);
+ if (v.is_empty ())
+   /* For this PTR we don't have any UBSAN_NULL stmts
+  recorded, so there's nothing to optimize yet.  */
+   v.safe_push (stmt);
+ else
+   {
+ /* We already have recorded a UBSAN_NULL check
+for this pointer.  Perhaps we can drop this one.
+But only if this check doesn't specify stricter
+alignment, and is dominated by an earlier stmt.  */
+ int i;
+ gimple g;
+
+ FOR_EACH_VEC_ELT (v, i, g)
+   {
+ tree align = gimple_call_arg (g, 2);
+ basic_block gbb = gimple_bb (g);
+ if (tree_int_cst_le (cur_align, align)
+ && dominated_by_p (CDI_DOMINATORS, bb, gbb))
+   {
+ remove = true;
+ break;
+   }
+   }
+
+ if (remove)
+   {
+ /* Drop this check.  */
+ if (dump_file && (dump_flags & TDF_DETAILS))
+   {
+ fprintf (dump_file, "Optimizing out\n  ");
+ print_gimple_stmt (dump_file, stmt, 0,
+dump_flags);
+ fprintf (dump_file, "\n");
+   }
+ gsi_remove (&gsi, true);
+   }
+ else if (v.length () < 30)
+   v.safe_push (stmt);
+   }
+ break;
+   }
+ default:
+   break;
+ }
+
+ /* If we were able to remove current statement, gsi_remove
+already pointed us to the next statement.  */
+ if (!remove)
+   gsi_next (&gsi);
+   }
+}
+
+  delete null_check_map;
+  null_check_map = NULL;
+  free_dominance_info (CDI_DOMINATORS);
+}
+
 /* Instrument the current function.  */
 
 static unsigned int
@@ -2834,6 +2927,10 @@ pass_sanopt::execute (function *fun)
 {
   basic_block bb;
 
+  /* Try to remove redundant checks.  */
+  if (optimize && (flag_sanitize & (SANITIZE_NULL | SANITIZE_ALIGNMENT)))
+optimize_checks (fun);
+
   int asan_num_accesses = 0;
   if (flag_sanitize & SANITIZE_ADDRESS)
 {
@@ -2889,7 +2986,7 @@ pass_sanopt::execute (function *fun)
 
  if (dump_file && (dump_flags & TD

Re: [PATCH 06/10] Heart of the JIT implementation (was: Re: [PATCH 0/5] Merger of jit branch (v2))

2014-10-30 Thread David Malcolm
On Fri, 2014-10-17 at 21:52 +, Joseph S. Myers wrote:
> Does libgccjit.so end up getting linked with -static-libstdc++ 
> -static-libgcc? 
(sorry for belated reply)

It does when built with a bootstrap, but doesn't with
--disable-bootstrap.  In the former case, the builddir's gcc/Makefile in
the final stage has:
  LDFLAGS = -static-libstdc++ -static-libgcc
and we use $(LDFLAGS) in the src's gcc/jit/Make-lang.in in the rule for
$(LIBGCCJIT_FILENAME).

As far as I can tell, this comes from these lines:
   if test "$poststage1_libs" = ""; then
 poststage1_ldflags="-static-libstdc++ -static-libgcc"
   fi])
in the top-level configure.ac's code for:
   AC_ARG_WITH(boot-ldflags,

> If so, that could be problematic (are static libstdc++ 
> and libgcc necessarily built as PIC so it's even possible to embed them 
> into a shared library?).

It works (on this machine at least); the built libgccjit.so library
successfully runs the test suite.

Looking at the build logs, I see:
  -fPIC
within the xgcc args in the libgcc build logs, and
  -prefer-pic
within the libtool args in the libstdc++ build, which according to the
libtool docs means "try to build only PIC objects".

Hence I believe although we're currently statically-linking libgcc and
libstdc++ into libgccjit.so, they're position-independent.

> It's certainly not clear that the 
> -static-libstdc++ -static-libgcc default for building the compiler 
> executables is the right one for building libgccjit.so.

Agreed, but it's unclear to me what the default should be, and how to go
about fixing it.

That said, it appears that people who want the libgccjit.so to
dynamically-link against libgcc and libstdc++ can already do so, by
selecting appropriate configuration flags (though it's not quite clear
to me what the incantation is; presumably $poststage1_libs needs to be
non-empty to avoid triggering this clause:
   if test "$poststage1_libs" = ""; then
 poststage1_ldflags="-static-libstdc++ -static-libgcc"
   fi
, right ?)

Or maybe I could turn off that clause if the "--enable-host-shared" has
been specified, so it defaults to shared linkage for that setting?

Do you have thoughts on how I should address this?  Also, given that the
code works as-is, is resolving this a blocker for merging the jit
branch?  (I've been rebasing, and plan to repost the fixed-up patches
for review shortly)

Thanks
Dave


> The dump file handling appears to have no I/O error checking (no
> checking 
> for error on fopen, nothing obvious to prevent fwrite to a NULL m_file
> if 
> fopen did have an error, no checking for error on fclose (or fwrite)).

(already addressed in a different reply)



Re: [PATCH] config-list.mk: Build Go only for supported targets (was: Patch RFA: Top-level configure patch: disable go on systems where it doesn't work)

2014-10-30 Thread Jan-Benedict Glaw
On Thu, 2014-10-30 08:08:51 -0700, Ian Taylor  wrote:
> On Thu, Oct 30, 2014 at 6:19 AM, Jan-Benedict Glaw  wrote:
> >
> > This updates contrib/config-list.mk to build Go for all but
> > known-non-working targets. A comment to configure{.ac,} is also added.
> 
> > diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> > index 94884d9..16900e1 100644
> > --- a/contrib/config-list.mk
> > +++ b/contrib/config-list.mk
> > @@ -95,11 +95,24 @@ make-log-dir: ../gcc/MAINTAINERS
> >
> >  $(LIST): make-log-dir
> > -mkdir $@
> > -   (cd $@ && \
> > -   ../../gcc/configure \
> > -   --target=$(subst SCRIPTS,`pwd`/../scripts/,$(subst OPT,$(empty) 
> > -,$@)) \
> > -   --enable-werror-always ${host_options} 
> > --enable-languages=all,ada,go) \
> > -   > log/$@-config.out 2>&1
> > +   (   
> > \
> > +   cd $@ &&
> > \
> > +   echo $@ &&  
> > \
> > +   TGT=`echo $@ | sed -e 's/^\(.*\)OPT.*$$/\1/'` &&
> > \
> > +   TGT=`../../gcc/config.sub $$TGT` && 
> > \
> 
> This isn't necessary.  The OPT bits will be matched by the * at the
> end of the cases anyhow.  You can just write
>  case $@ in
> 
> This is OK with that change.

Not exactly: My intention was to keep the triplet matches as they show
up in configure.ac .  However, the target list in config-list.mk uses
(almost exclusively) shorthands for all the targets, so these need to
be expand (--> config.sub); that however won't really fly with the
OPTs in there.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: God put me on earth to accomplish a certain number of
the second  :things. Right now I am so far behind I will never die.


signature.asc
Description: Digital signature


Re: [PATCH] Optimize UBSAN_NULL checks

2014-10-30 Thread Marek Polacek
And I wonder whether it'd be worth it to create sanopt.c - and move
.sanopt related stuff there (it'd mean making asan_expand_check_ifn
non-static, but that's pretty much it).

Marek


Re: [PATCH RFC]Pair load store instructions using a generic scheduling fusion pass

2014-10-30 Thread Jeff Law

On 10/10/14 21:32, Bin.Cheng wrote:

Mike already gave great answers, here are just some of my thoughts on
the specific questions.  See embedded below.

Thanks to both of you for your answers.

Fundamentally, what I see is this scheme requires us to be able to come 
up with a key based solely on information in a particular insn.  To get 
fusion another insn has to have the same or a closely related key.


This implies that the the two candidates for fusion are related, even if 
there isn't a data dependency between them.  The canonical example would 
be two loads with reg+d addressing modes.  If they use the same base 
register and the displacements differ by a word, then we don't have a 
data dependency between the insns, but the insns are closely related by 
their address computations and we can compute a key to ensure those two 
related insns end up consecutive.  At any given call to the hook, the 
only context we can directly see is the current insn.


I'm pretty sure if I were to tweak the ARM bits ever-so-slightly it 
could easily model the load-load or store-store special case on the 
PA7xxx[LC] processors.  Normally a pair of loads or stores can't dual 
issue.  But if the two loads (or two stores) hit the upper and lower 
half of a double-word objects, then the instructions can dual issue.


I'd forgotten about that special case scheduling opportunity until I 
started looking at some unrelated enhancement for prefetching.


Your code would also appear to allow significant cleanup of the old 
caller-save code that had a fair amount of bookkeeping added to issue 
double-word memory loads/stores rather than single word operations. 
This *greatly* improved performance on the old sparc processors which 
had no call-saved FP registers.


However, your new code doesn't handle fusing instructions which are 
totally independent and of different static types.  There just isn't a 
good way to compute a key that I can see.  And this is OK -- that case, 
if we cared to improve it, would be best handled by the SCHED_REORDER hooks.




I guess another way to ask the question, are fusion priorities static based on 
the insn/alternative, or can they vary?  And if they can vary, can they vary 
each tick of the scheduler?


Though this pass works on predefined fusion types and priorities now,
there might be two possible fixes for this specific problem.
1) Introduce another exclusive_pri, now it's like "fusion_pri,
priority, exclusive_pri".  The first one is assigned to mark
instructions belonging to same fusion type.  The second is assigned to
fusion each pair/consecutive instructions together.  The last one is
assigned to prevent specific pair of instructions from being fused,
just like "BC" mentioned.
2) Extend the idea by using hook function
TARGET_SCHED_REORDER/TARGET_SCHED_REORDER2.  Now we can assign
fusion_pri at the first place, making sure instructions in same fusion
type will be adjacent to each other, then we can change priority (thus
reorder the ready list) at back-end's wish even per each tick of the
scheduler.
#2 would be the best solution for the case I was pondering, but I don't 
think solving that case is terribly important given the processors for 
which it was profitable haven't been made for a very long time.


Jeff


RE: [Patch, MIPS] Add Octeon3 support

2014-10-30 Thread Moore, Catherine


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> Sent: Thursday, October 30, 2014 2:59 AM
> Subject: Re: [Patch, MIPS] Add Octeon3 support
> 
> Hi,
> 
> Thanks for the review and your comments.
> 
> >> Is it intentional that you have not updated driver-native.c to detect
> >> an Octeon 3 CPU?
> 
> We have not yet looked into that part yet and will be looking at it later.
> 
> >> Could you confirm what testing the patch has had?
> 
> Run the regression in build folder of gcc using make-check.
> The compilation results are good.
> Also we have been using the octeon3 patches in cavium toolchain from
> sometime without any issues.
> 

Hi Naveen,

This patch looks good except that is missing testcases.  Would you please add 
some testcases and resubmit your patch?
Thanks,
Catherine



Re: [PATCH] Optimize UBSAN_NULL checks

2014-10-30 Thread ygribov
> And I wonder whether it'd be worth it to create sanopt.c -
> and move sanopt related stuff there

+1



--
View this message in context: 
http://gcc.1065356.n5.nabble.com/PATCH-Optimize-UBSAN-NULL-checks-tp1084891p1084905.html
Sent from the gcc - patches mailing list archive at Nabble.com.


Re: [gofrontend-dev] Re: [PATCH 7/9] Gccgo port to s390[x] -- part I

2014-10-30 Thread Joseph S. Myers
On Thu, 30 Oct 2014, Dominik Vogt wrote:

> platforms need to be added.  Personally I cannot provide fixed
> tests for all the Abis either, so my suggestion is to "xfail" the
> test on all targets except s390[x] and x86_64 and leave it to the

You should never do something in a test for x86_64 and not i?86, because 
they cover exactly the same set of targets (if only LP64 x86 / x86_64 is 
relevant, use { { i?86-*-* x86_64-*-* } && lp64 }).

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [PATCH] Add zero-overhead looping for xtensa backend

2014-10-30 Thread augustine.sterl...@gmail.com
On Tue, Oct 28, 2014 at 5:22 AM, Yangfei (Felix)  wrote:
> Hi Sterling,
>   How do you think about this issue?
>   As c6x/bfin port handles this the same way, is it OK for the patch to be 
> applied?
>   Thanks.

I have committed this patch as attached. I made a couple of minor
cleanups, plus some small fixes to the ChangeLog entry.

The new code generated is better than the old code, but I'm not
particularly happy with the result. In particular, it is way too
conservative around spilling the trip count, and it still maintains
the trip count inside the loop, in spite of the trip count being dead
at that point. It won't always be dead, but when it is, it should be
eliminated.

So there is quite a bit of performance that could still be gained here.

Thanks for the patch Felix.

Sterling

2014-10-10  Felix Yang  

* config/xtensa/xtensa.h (TARGET_LOOPS): New Macro.
* config/xtensa/xtensa.c: Include dumpfile.h and hw-doloop.h.
(xtensa_reorg, xtensa_reorg_loops): New.
(xtensa_can_use_doloop_p, xtensa_invalid_within_doloop): New.
(hwloop_optimize, hwloop_fail, hwloop_pattern_reg): New.
(xtensa_emit_loop_end): Emit the zero-overhead loop end label.
(xtensa_doloop_hooks): Define.
* config/xtensa/xtensa.md (doloop_end, loop_end): New
(zero_cost_loop_start): Rewritten.
(zero_cost_loop_end): Likewise.
Index: gcc/config/xtensa/xtensa.c
===
--- gcc/config/xtensa/xtensa.c  (revision 216943)
+++ gcc/config/xtensa/xtensa.c  (working copy)
@@ -74,6 +74,8 @@
 #include "gimplify.h"
 #include "df.h"
 #include "builtins.h"
+#include "dumpfile.h"
+#include "hw-doloop.h"
 #include "rtl-iter.h"
 
 
@@ -200,6 +202,10 @@
 
 static bool constantpool_address_p (const_rtx addr);
 static bool xtensa_legitimate_constant_p (machine_mode, rtx);
+static void xtensa_reorg (void);
+static bool xtensa_can_use_doloop_p (const widest_int &, const widest_int &,
+ unsigned int, bool);
+static const char *xtensa_invalid_within_doloop (const rtx_insn *);
 
 static bool xtensa_member_type_forces_blk (const_tree,
   machine_mode mode);
@@ -326,6 +332,15 @@
 #undef TARGET_LEGITIMATE_CONSTANT_P
 #define TARGET_LEGITIMATE_CONSTANT_P xtensa_legitimate_constant_p
 
+#undef TARGET_MACHINE_DEPENDENT_REORG
+#define TARGET_MACHINE_DEPENDENT_REORG xtensa_reorg
+
+#undef TARGET_CAN_USE_DOLOOP_P
+#define TARGET_CAN_USE_DOLOOP_P xtensa_can_use_doloop_p
+
+#undef TARGET_INVALID_WITHIN_DOLOOP
+#define TARGET_INVALID_WITHIN_DOLOOP xtensa_invalid_within_doloop
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 
@@ -1690,7 +1705,7 @@
 }
 }
 
-  output_asm_insn ("# loop end for %0", operands);
+  output_asm_insn ("%1_LEND:", operands);
 }
 
 
@@ -3720,4 +3735,236 @@
   return !xtensa_tls_referenced_p (x);
 }
 
+/* Implement TARGET_CAN_USE_DOLOOP_P.  */
+
+static bool
+xtensa_can_use_doloop_p (const widest_int &, const widest_int &,
+ unsigned int loop_depth, bool entered_at_top)
+{
+  /* Considering limitations in the hardware, only use doloop
+ for innermost loops which must be entered from the top.  */
+  if (loop_depth > 1 || !entered_at_top)
+return false;
+
+  return true;
+}
+
+/* NULL if INSN insn is valid within a low-overhead loop.
+   Otherwise return why doloop cannot be applied.  */
+
+static const char *
+xtensa_invalid_within_doloop (const rtx_insn *insn)
+{
+  if (CALL_P (insn))
+return "Function call in the loop.";
+
+  if (JUMP_P (insn) && INSN_CODE (insn) == CODE_FOR_return)
+return "Return from a call instruction in the loop.";
+
+  return NULL;
+}
+
+/* Optimize LOOP.  */
+
+static bool
+hwloop_optimize (hwloop_info loop)
+{
+  int i;
+  edge entry_edge;
+  basic_block entry_bb;
+  rtx iter_reg;
+  rtx_insn *insn, *seq, *entry_after;
+
+  if (loop->depth > 1)
+{
+  if (dump_file)
+fprintf (dump_file, ";; loop %d is not innermost\n",
+ loop->loop_no);
+  return false;
+}
+
+  if (!loop->incoming_dest)
+{
+  if (dump_file)
+fprintf (dump_file, ";; loop %d has more than one entry\n",
+ loop->loop_no);
+  return false;
+}
+
+  if (loop->incoming_dest != loop->head)
+{
+  if (dump_file)
+fprintf (dump_file, ";; loop %d is not entered from head\n",
+ loop->loop_no);
+  return false;
+}
+
+  if (loop->has_call || loop->has_asm)
+{
+  if (dump_file)
+fprintf (dump_file, ";; loop %d has invalid insn\n",
+ loop->loop_no);
+  return false;
+}
+
+  /* Scan all the blocks to make sure they don't use iter_reg.  */
+  if (loop->iter_reg_used || loop->iter_reg_used_outside)
+{
+  if (dump_file)
+fprintf (dump_file, ";; loop %d uses iterator\n",
+ loop->loop_no);
+  return false;
+}
+
+  /* Check if start_label appears before doloop_end. 

Re: ptx preliminary rtl patches [1/4]

2014-10-30 Thread Jeff Law

On 10/30/14 11:36, Segher Boessenkool wrote:

On Thu, Sep 11, 2014 at 03:24:54PM +0200, Bernd Schmidt wrote:

The nvptx backend is somewhat unusual in that call insns set a pseudo.
The combiner is surprised by this and allows combining them into other
insns, which remain as INSN rather than CALL_INSN. Aborts ensue.


distribute_notes has code for when I2 is a CALL.  This suggests that
on some other targets there can be useful combinations made, so it
isn't in that case terribly nice to disable all combinations with CALLs
as I0 or I1 or I2.

Or it's dead code :-)

Most likely it's dead code.

jeff


Re: [testsuite,ARM] PR61153 Fix vbic and vorn tests

2014-10-30 Thread Christophe Lyon
On 29 October 2014 16:28, Ramana Radhakrishnan
 wrote:
> On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
>  wrote:
>> Hi,
>>
>> In PR61153, the vbic and vorn tests fail because when compiled at -O0
>> the expected Neon instructions are not generated, making
>> scan-assembler fail.
>>
>> This patch:
>> - replaces -O0 by -O2
>> - moves the declaration of local variables used as intrinsics
>> parameters and results to global declarations, to prevent the compiler
>> from optimizing the whole test away.
>>
>> OK?
>>
>
> If you really want to do it , do it in neon-testgen.ml and do it for
> the whole lot.
>

I thought it wasn't used anymore.

At -O2 I have many more failures :-(

(vdup, vget_lane, vget_low, vmov, vset_lane)

And -O1 doesn't do the trick either...

Christophe.

> regards
> Ramana
>> Christophe.
>>
>> 2014-10-29  Christophe Lyon  
>>
>> PR target/61153
>> * gcc.target/arm/neon/vbicQs16.c: Compile at O2 and move variables
>> declarations from local to global.
>> * gcc.target/arm/neon/vbicQs16.c: Likewise.
>> * gcc.target/arm/neon/vbicQs32.c: Likewise.
>> * gcc.target/arm/neon/vbicQs64.c: Likewise.
>> * gcc.target/arm/neon/vbicQs8.c: Likewise.
>> * gcc.target/arm/neon/vbicQu16.c: Likewise.
>> * gcc.target/arm/neon/vbicQu32.c: Likewise.
>> * gcc.target/arm/neon/vbicQu64.c: Likewise.
>> * gcc.target/arm/neon/vbicQu8.c: Likewise.
>> * gcc.target/arm/neon/vbics16.c: Likewise.
>> * gcc.target/arm/neon/vbics32.c: Likewise.
>> * gcc.target/arm/neon/vbics64.c: Likewise.
>> * gcc.target/arm/neon/vbics8.c: Likewise.
>> * gcc.target/arm/neon/vbicu16.c: Likewise.
>> * gcc.target/arm/neon/vbicu32.c: Likewise.
>> * gcc.target/arm/neon/vbicu64.c: Likewise.
>> * gcc.target/arm/neon/vbicu8.c: Likewise.
>> * gcc.target/arm/neon/vornQs16.c: Likewise.
>> * gcc.target/arm/neon/vornQs32.c: Likewise.
>> * gcc.target/arm/neon/vornQs64.c: Likewise.
>> * gcc.target/arm/neon/vornQs8.c: Likewise.
>> * gcc.target/arm/neon/vornQu16.c: Likewise.
>> * gcc.target/arm/neon/vornQu32.c: Likewise.
>> * gcc.target/arm/neon/vornQu64.c: Likewise.
>> * gcc.target/arm/neon/vornQu8.c: Likewise.
>> * gcc.target/arm/neon/vorns16.c: Likewise.
>> * gcc.target/arm/neon/vorns32.c: Likewise.
>> * gcc.target/arm/neon/vorns64.c: Likewise.
>> * gcc.target/arm/neon/vorns8.c: Likewise.
>> * gcc.target/arm/neon/vornu16.c: Likewise.
>> * gcc.target/arm/neon/vornu32.c: Likewise.
>> * gcc.target/arm/neon/vornu64.c: Likewise.
>> * gcc.target/arm/neon/vornu8.c: Likewise.


Re: [PATCH RFC]Pair load store instructions using a generic scheduling fusion pass

2014-10-30 Thread Mike Stump
On Oct 30, 2014, at 12:43 PM, Jeff Law  wrote:
> Fundamentally, what I see is this scheme requires us to be able to come up 
> with a key based solely on information in a particular insn.  To get fusion 
> another insn has to have the same or a closely related key.

Right.


Re: [PATCH] config-list.mk: Build Go only for supported targets (was: Patch RFA: Top-level configure patch: disable go on systems where it doesn't work)

2014-10-30 Thread Ian Taylor
On Thu, Oct 30, 2014 at 12:14 PM, Jan-Benedict Glaw  wrote:
> On Thu, 2014-10-30 08:08:51 -0700, Ian Taylor  wrote:
>> On Thu, Oct 30, 2014 at 6:19 AM, Jan-Benedict Glaw  wrote:
>> >
>> > This updates contrib/config-list.mk to build Go for all but
>> > known-non-working targets. A comment to configure{.ac,} is also added.
>>
>> > diff --git a/contrib/config-list.mk b/contrib/config-list.mk
>> > index 94884d9..16900e1 100644
>> > --- a/contrib/config-list.mk
>> > +++ b/contrib/config-list.mk
>> > @@ -95,11 +95,24 @@ make-log-dir: ../gcc/MAINTAINERS
>> >
>> >  $(LIST): make-log-dir
>> > -mkdir $@
>> > -   (cd $@ && \
>> > -   ../../gcc/configure \
>> > -   --target=$(subst SCRIPTS,`pwd`/../scripts/,$(subst OPT,$(empty) 
>> > -,$@)) \
>> > -   --enable-werror-always ${host_options} 
>> > --enable-languages=all,ada,go) \
>> > -   > log/$@-config.out 2>&1
>> > +   (  
>> >  \
>> > +   cd $@ &&   
>> >  \
>> > +   echo $@ && 
>> >  \
>> > +   TGT=`echo $@ | sed -e 's/^\(.*\)OPT.*$$/\1/'` &&   
>> >  \
>> > +   TGT=`../../gcc/config.sub $$TGT` &&
>> >  \
>>
>> This isn't necessary.  The OPT bits will be matched by the * at the
>> end of the cases anyhow.  You can just write
>>  case $@ in
>>
>> This is OK with that change.
>
> Not exactly: My intention was to keep the triplet matches as they show
> up in configure.ac .  However, the target list in config-list.mk uses
> (almost exclusively) shorthands for all the targets, so these need to
> be expand (--> config.sub); that however won't really fly with the
> OPTs in there.

Oh, right, sorry.

The original patch is OK.

Thanks.

Ian


[gomp4] acc enter/exit data

2014-10-30 Thread Cesar Philippidis
This patch add support for OpenACC's enter/exit data directive. Note
that there is a problem in the 2.0a spec regarding the live ranges of
variables in data clauses. Section 2.6.5.7 states that exit data delete
should deallocate memory without writing it back. However, that may
conflict with an acc data variable as the following example demonstrates.

#pragma acc data copy (A)
{
  ...
#pragma acc exit data delete (A)
  ...
} // end of acc data block

The OpenACC technical committee has informed me that this issue has been
corrected in a future revision of OpenACC. For now though, acc exit data
delete will decrement A's refcount and the GC will delete it when it's
no longer necessary. To be clear, this example will result in a runtime
failure at when the acc data block terminates.

One note regarding the mystery 3 refcount in gomp_acc_remove_pointer.
When gomp_acc_insert_pointer creates a mapping for a pset, the array
data itself has three references: (1) the data itself, (2) the pointer,
and (3) the pset. However, when it comes time to deleting the pset,
gomp_acc_remove_pointer is really removing the data itself. The mystery
2 argument comes from acc_unmap_vars. I suspect a similar argument can
be used for 2 which is only used for pointers (really subarrays): (1)
data, and (2) pointer.

Thomas has already approved this patch internally, so I'll commit it to
gomp-4_0-branch in the next few days unless someone complains.

Thanks,
Cesar
2014-10-30  Cesar Philippidis  

	gcc/c-family/
	* c-pragma.c (oacc_pragmas): Add entries for PRAGMA_OACC_ENTER_DATA
	and PRAGMA_OACC_EXIT_DATA.
	* c-pragma.h (pragma_kind): Likewise.

	gcc/c/
	* c-parser.c (c_parser_oacc_enter_exit_data): New function.
	(c_parser_pragma): Handle PRAGMA_OACC_ENTER_DATA and
	PRAGMA_OACC_EXIT_DATA.
	(OACC_ENTER_DATA_CLAUSE_MASK): New macro.
	(OACC_EXIT_DATA_CLAUSE_MASK): New macro.
	(c_parser_oacc_update): Don't create a new stmt if the pragma
	is bogus.

	gcc/cp/
	* parser.c (cp_parser_omp_clause_name): Also consider CPP_KEYWORD
	typed tokens as clauses for delete.
	(OACC_ENTER_DATA_CLAUSE_MASK): New macro.
	(OACC_EXIT_DATA_CLAUSE_MASK): New macro.
	(cp_parser_oacc_enter_exit_data): New function.
	(cp_parser_omp_construct): Handle PRAGMA_OACC_ENTER_DATA and
	PRAGMA_OACC_EXIT_DATA.
	(cp_parser_pragma): Likewise.

	gcc/fortran/
	* gfortran.h (enum OMP_LIST_HOST): Remove.
	(enum OMP_LIST_DEVICE, OMP_LIST_DEVICE): Remove.
	* dump-parse-tree.c (show_omp_clauses): Remove OMP_LIST_HOST and
	OMP_LIST_DEVICE from here also.
	* openmp.c (OMP_CLAUSE_SELF): New define.
	(gfc_match_omp_clauses): Update handling of OMP_CLAUSE_HOST and
	OMP_CLAUSE_DEVICE. Add support for OMP_CLAUSE_SELF.
	* trans-openmp.c (gfc_trans_omp_clauses): Remove support for
	OMP_LIST_HOST and OMP_LIST_DEVICE since they are treated as memory
	maps now.
	(gfc_trans_oacc_executable_directive): Remove stale EXEC_OACC_WAIT.

	gcc/
	* gimple.h (enum gf_mask): Add GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA.
	* gimple-pretty-print.c (dump_gimple_omp_target): Handle it.
	* gimplify.c (gimplify_scan_omp_clauses): Remove switch stmt which
	declared OMP_CLAUSE_MAP_FORCE_DEALLOC as unimplemented.
	(gimplify_omp_target_update): Handle OACC_ENTER_DATA and
	OACC_EXIT_DATA.
	(gimplify_expr): Shuffle around OACC_ENTER_DATA, OACC_EXIT_DATA and
	OACC_WAIT.
	* oacc-builtins.def (BUILD_INT_GOACC_ENTER_EXIT_DATA): New built-in
	function.
	* omp-low.c (expand_omp_target): Handle
	GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA. Don't use quick_push when
	there is an unknown number of wait args.
	(lower_omp_target): Handle GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA.

	gcc/testsuite/
	* c-c++-common/goacc/data-1.c: Exercise enter/exit data pragma.
	* c-c++-common/goacc/update-1.c: Ensure that fortran subarrays err.

	* gcc/testsuite/c-c++-common/goacc/data-2.c: New test.
	* gcc/testsuite/c-c++-common/goacc/update-1.c: Check for malformed
	subarrays.

	libgomp/
	* libgomp.map (GOACC_enter_exit_data): Declare as global.
	* libgomp_g.h (GOACC_enter_exit_data): Declare.
	(GOACC_update): Declare.
	(gomp_acc_insert_pointer): Declare.
	(gomp_acc_remove_pointer): Declare.
	* oacc-mem.c (gomp_acc_insert_pointer): New function.
	(gomp_acc_remove_pointer): New function.
	* oacc-parallel.c (find_pset): New function.
	(GOACC_enter_exit_data): New function.
	(GOACC_update): Handle GOMP_MAP_TO_PSET.
	* testsuite/libgomp.oacc-c++/c++.exp (check_efective_target_oacc_c):
	New proc. 
	* testsuite/libgomp.oacc-c-c++-common/data-2.c: New test.
	* testsuite/libgomp.oacc-c-c++-common/data-3.c: New test.
	* testsuite/libgomp.oacc-c/c.exp (check_efective_target_oacc_c):
	New proc.
	* testsuite/libgomp.oacc-fortran/data-1.f90: New test.
	* testsuite/libgomp.oacc-fortran/data-2.f90: New test.
	* testsuite/libgomp.oacc-fortran/data-3.f90: New test.
	* testsuite/libgomp.oacc-fortran/data-4.f90: New test.


diff --git a/gcc/c-family/c-pragma.c b/gcc/c-family/c-pragma.c
index 39634ea..e98b555 100644
--- a/gcc/c-family/c-pragma.c
+++ b/gcc/c-family/c-prag

[jit] Remove some dead code

2014-10-30 Thread David Malcolm
Pushed to the dmalcolm/jit branch:

gcc/jit/ChangeLog.jit:
* dummy-frontend.c (jit_langhook_init): Remove some dead code.
---
 gcc/jit/ChangeLog.jit| 4 
 gcc/jit/dummy-frontend.c | 3 ---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index ce0ad40..90fccdb 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,7 @@
+2014-10-30  David Malcolm  
+
+   * dummy-frontend.c (jit_langhook_init): Remove some dead code.
+
 2014-10-27  David Malcolm  
 
* dummy-frontend.c: Drop includes of tree-iterator.h,
diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
index de7789e..33f126f 100644
--- a/gcc/jit/dummy-frontend.c
+++ b/gcc/jit/dummy-frontend.c
@@ -101,9 +101,6 @@ struct ggc_root_tab jit_root_tab[] =
 static bool
 jit_langhook_init (void)
 {
-  // eventually this can be a GTY object, and can thus mark
-  // our state without dealing with gengtype...
-  //g->frontend_ = new frontend ();
   static bool registered_root_tab = false;
   if (!registered_root_tab)
 {
-- 
1.7.11.7



Re: [PATCH 06/10] Heart of the JIT implementation (was: Re: [PATCH 0/5] Merger of jit branch (v2))

2014-10-30 Thread Joseph S. Myers
On Thu, 30 Oct 2014, David Malcolm wrote:

> Looking at the build logs, I see:
>   -fPIC
> within the xgcc args in the libgcc build logs, and

That seems to depend on t-libgcc-pic, but that appears to cover most 
likely hosts (including any where I can be confident PIC is actually 
needed for shared libraries).

> > It's certainly not clear that the 
> > -static-libstdc++ -static-libgcc default for building the compiler 
> > executables is the right one for building libgccjit.so.
> 
> Agreed, but it's unclear to me what the default should be, and how to go
> about fixing it.
> 
> That said, it appears that people who want the libgccjit.so to
> dynamically-link against libgcc and libstdc++ can already do so, by

Can do so for libgccjit.so but not the compiler executables?

(There are no doubt cases where it makes sense for the compiler 
executables to be dynamically linked with the shared libraries, but also I 
think cases for linking only libgccjit.so with the shared libraries.)

> Do you have thoughts on how I should address this?  Also, given that the

No.

> code works as-is, is resolving this a blocker for merging the jit
> branch?  (I've been rebasing, and plan to repost the fixed-up patches
> for review shortly)

I don't see it as a blocker, but I would not be surprised if having the 
libraries statically linked into libgccjit.so causes problems (is it safe 
to have two completely separate copies of libstdc++ in the same process?  
I don't know.).

-- 
Joseph S. Myers
jos...@codesourcery.com


Fwd: [testsuite patch] avoid test when compile options is conflict with default mthumb

2014-10-30 Thread Wang Deqiang
This is a ping for

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01049.html


-- Original message --
From: Wang Deqiang 
Date: 11 October 2014 11:27
Subject: [testsuite patch] avoid test when compile options is conflict
with default mthumb
To: gcc-patches@gcc.gnu.org


When testing arm-linux-gnueabihf triple with configure options
--with-mode=thumb(that makes -mthumb option default).
some testcase is failed with error message "sorry, unimplemented:
Thumb-1 hard-float VFP ABI".
I found gcc compiler show this error message when :
1. -mthumb is used with -march=armv6 (or armv5e) and -mcpu=xscale
2. the test source have function body.

And when -mthumb is the default option of compiler, the dg-skip-if
functions can not detect it,
There is no xscale check function in target-supports.exp in. so we
need to add it .
And there are only macros in the test program in
check_effective_target_arm* function . no function body, we need to
add it too.

Here is my patch:

2014-10-08  Wangdeqiang  
* lib/target-supports.exp (check_effective_target_arm_
xscale_ok): New function.
(check_effective_target_arm_arch_FUNC_ok): Add test function body.
* gcc.target/arm/pr40887.c (dg-require-effective-target): add
arm_arch_v5te_ok check
* gcc.target/arm/scd42-1.c (dg-require-effective-target): add
arm_xscale_ok check
* gcc.target/arm/scd42-2.c : Likewise
* gcc.target/arm/scd42-3.c : Likewise
* gcc.target/arm/g2.c : Likewise
* gcc.target/arm/xor-and.c (dg-require-effective-target): add
arm_arch_v6_ok check

Index: gcc/testsuite/gcc.target/arm/pr40887.c
===
--- gcc/testsuite/gcc.target/arm/pr40887.c  (revision 216115)
+++ gcc/testsuite/gcc.target/arm/pr40887.c  (working copy)
@@ -1,6 +1,7 @@
 /* { dg-skip-if "need at least armv5" { *-*-* } { "-march=armv[234]*"
} { "" } } */
 /* { dg-options "-O2 -march=armv5te" }  */
 /* { dg-final { scan-assembler "blx" } } */
+/* { dg-require-effective-target arm_arch_v5te_ok } */

 int (*indirect_func)(int x);

Index: gcc/testsuite/gcc.target/arm/scd42-2.c
===
--- gcc/testsuite/gcc.target/arm/scd42-2.c  (revision 216115)
+++ gcc/testsuite/gcc.target/arm/scd42-2.c  (working copy)
@@ -5,6 +5,7 @@
 /* { dg-skip-if "Test is specific to the Xscale" { arm*-*-* } {
"-mcpu=*" } { "-mcpu=xscale" } } */
 /* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } {
"-mthumb" } { "" } } */
 /* { dg-require-effective-target arm32 } */
+/* { dg-require-effective-target arm_xscale_ok } */

 unsigned load2(void) __attribute__ ((naked));
 unsigned load2(void)
Index: gcc/testsuite/gcc.target/arm/scd42-3.c
===
--- gcc/testsuite/gcc.target/arm/scd42-3.c  (revision 216115)
+++ gcc/testsuite/gcc.target/arm/scd42-3.c  (working copy)
@@ -3,6 +3,7 @@
 /* { dg-skip-if "Test is specific to Xscale" { arm*-*-* } {
"-march=*" } { "-march=xscale" } } */
 /* { dg-skip-if "Test is specific to Xscale" { arm*-*-* } { "-mcpu=*"
} { "-mcpu=xscale" } } */
 /* { dg-options "-mcpu=xscale -O" } */
+/* { dg-require-effective-target arm_xscale_ok } */

 unsigned load4(void) __attribute__ ((naked));
 unsigned load4(void)
Index: gcc/testsuite/gcc.target/arm/g2.c
===
--- gcc/testsuite/gcc.target/arm/g2.c   (revision 216115)
+++ gcc/testsuite/gcc.target/arm/g2.c   (working copy)
@@ -5,6 +5,7 @@
 /* { dg-skip-if "Test is specific to the Xscale" { arm*-*-* } {
"-mcpu=*" } { "-mcpu=xscale" } } */
 /* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } {
"-mthumb" } { "" } } */
 /* { dg-require-effective-target arm32 } */
+/* { dg-require-effective-target arm_xscale_ok } */

 /* Brett Gaines' test case. */
 unsigned BCPL(unsigned) __attribute__ ((naked));
Index: gcc/testsuite/gcc.target/arm/xor-and.c
===
--- gcc/testsuite/gcc.target/arm/xor-and.c  (revision 216115)
+++ gcc/testsuite/gcc.target/arm/xor-and.c  (working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O -march=armv6" } */
 /* { dg-prune-output "switch .* conflicts with" } */
+/* { dg-require-effective-target arm_arch_v6_ok } */

 unsigned short foo (unsigned short x)
 {
Index: gcc/testsuite/gcc.target/arm/scd42-1.c
===
--- gcc/testsuite/gcc.target/arm/scd42-1.c  (revision 216115)
+++ gcc/testsuite/gcc.target/arm/scd42-1.c  (working copy)
@@ -2,6 +2,7 @@
 /* { dg-do compile } */
 /* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "" } } */
 /* { dg-options "-mcpu=xscale -O" } */
+/* { dg-require-effective-target arm_xscale_ok } */

 unsigned load1(void) __attribute__ ((naked));
 unsigned load1(void)
Index: gcc/testsuite/lib/target-supports.exp
===

Re: [PATCH 06/10] Heart of the JIT implementation

2014-10-30 Thread Jeff Law

On 10/30/14 18:50, Joseph S. Myers wrote:



I don't see it as a blocker, but I would not be surprised if having the
libraries statically linked into libgccjit.so causes problems (is it safe
to have two completely separate copies of libstdc++ in the same process?
I don't know.).
Jason, Jakub, Aldy, Ben & others looked at this a few years ago for Red 
Hat and our conclusion was that having separate copies of libstdc++ in 
the same process might work sometimes, but ultimately wasn't anything we 
would be willing to stand behind and support at any level.


jeff


Re: [PATCH RFC]Pair load store instructions using a generic scheduling fusion pass

2014-10-30 Thread Bin.Cheng
Thanks for giving it a try.

On Fri, Oct 31, 2014 at 3:43 AM, Jeff Law  wrote:
> On 10/10/14 21:32, Bin.Cheng wrote:
>>
>> Mike already gave great answers, here are just some of my thoughts on
>> the specific questions.  See embedded below.
>
> Thanks to both of you for your answers.
>
> Fundamentally, what I see is this scheme requires us to be able to come up
> with a key based solely on information in a particular insn.  To get fusion
> another insn has to have the same or a closely related key.
>
> This implies that the the two candidates for fusion are related, even if
> there isn't a data dependency between them.  The canonical example would be
> two loads with reg+d addressing modes.  If they use the same base register
> and the displacements differ by a word, then we don't have a data dependency
> between the insns, but the insns are closely related by their address
> computations and we can compute a key to ensure those two related insns end
> up consecutive.  At any given call to the hook, the only context we can
> directly see is the current insn.
>
> I'm pretty sure if I were to tweak the ARM bits ever-so-slightly it could
> easily model the load-load or store-store special case on the PA7xxx[LC]
> processors.  Normally a pair of loads or stores can't dual issue.  But if
> the two loads (or two stores) hit the upper and lower half of a double-word
> objects, then the instructions can dual issue.
>
> I'd forgotten about that special case scheduling opportunity until I started
> looking at some unrelated enhancement for prefetching.
>
> Your code would also appear to allow significant cleanup of the old
> caller-save code that had a fair amount of bookkeeping added to issue
> double-word memory loads/stores rather than single word operations. This
> *greatly* improved performance on the old sparc processors which had no
> call-saved FP registers.
>
> However, your new code doesn't handle fusing instructions which are totally
> independent and of different static types.  There just isn't a good way to
> compute a key that I can see.  And this is OK -- that case, if we cared to
> improve it, would be best handled by the SCHED_REORDER hooks.
>

 I guess another way to ask the question, are fusion priorities static
 based on the insn/alternative, or can they vary?  And if they can vary, can
 they vary each tick of the scheduler?
>>
>>
>> Though this pass works on predefined fusion types and priorities now,
>> there might be two possible fixes for this specific problem.
>> 1) Introduce another exclusive_pri, now it's like "fusion_pri,
>> priority, exclusive_pri".  The first one is assigned to mark
>> instructions belonging to same fusion type.  The second is assigned to
>> fusion each pair/consecutive instructions together.  The last one is
>> assigned to prevent specific pair of instructions from being fused,
>> just like "BC" mentioned.
>> 2) Extend the idea by using hook function
>> TARGET_SCHED_REORDER/TARGET_SCHED_REORDER2.  Now we can assign
>> fusion_pri at the first place, making sure instructions in same fusion
>> type will be adjacent to each other, then we can change priority (thus
>> reorder the ready list) at back-end's wish even per each tick of the
>> scheduler.
>
> #2 would be the best solution for the case I was pondering, but I don't
> think solving that case is terribly important given the processors for which
> it was profitable haven't been made for a very long time.
I am thinking if it's possible to introduce a pattern-directed fusion.
Something like define_fusion, and adapting haifa-scheduler for it.  I
agree there are two kinds (relevant and irrelevant) fusion types, and
it's not trivial to support both in one scheme.  Do you have a
specific example that I can have a try?

This is just a preliminary idea and definitely can't catch up in GCC
5.0.  Moreover, so far I didn't see such requirement on ARM/AARCH64 or
any other targets that I know, so I would like to continue with this
version if it's fine.

Later I will send patch pairing different kinds of ldp/stp based on
this for aarch64.

Thanks,
bin

>
> Jeff


RE: [PATCH, ifcvt] Check size cost in noce_try_store_flag_mask

2014-10-30 Thread Zhenqiang Chen
Thank you all for the comments. Patch is updated.

Bootstrap and no make check regression on X86-64.
No make check regression with Cortex-M0 qemu.
No performance changes for coremark, dhrystone, spec2000 and spec2006 on
X86-64 and Cortex-A15.

For CSiBE, ARM Cortex-M0 result is a little better. A little regression for
MIPS (less than 0.01%).

diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 653653f..7bb2578 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -1393,6 +1393,9 @@ noce_try_store_flag_mask (struct noce_if_info
*if_info)
 
   if (target)
{
+ int old_cost, new_cost, insn_cost;
+ int speed_p;
+
  if (target != if_info->x)
noce_emit_move_insn (if_info->x, target);
 
@@ -1400,6 +1403,14 @@ noce_try_store_flag_mask (struct noce_if_info
*if_info)
  if (!seq)
return FALSE;
 
+ speed_p = optimize_bb_for_speed_p (BLOCK_FOR_INSN
(if_info->insn_a));
+ insn_cost = insn_rtx_cost (PATTERN (if_info->insn_a), speed_p);
+ old_cost = COSTS_N_INSNS (if_info->branch_cost) + insn_cost;
+ new_cost = seq_cost (seq, speed_p);
+
+ if (new_cost > old_cost)
+   return FALSE;
+
  emit_insn_before_setloc (seq, if_info->jump,
   INSN_LOCATION (if_info->insn_a));
  return TRUE;
diff --git a/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
new file mode 100644
index 000..43fa16b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
@@ -0,0 +1,13 @@
+/* { dg-do assemble } */
+/* { dg-options "-mthumb -Os " }  */
+/* { dg-require-effective-target arm_thumb1_ok } */
+
+int
+test (unsigned char iov_len, int count, int i) {
+  unsigned char bytes = 0;
+  if ((unsigned char) ((char) 127 - bytes) < iov_len)
+return 22;
+  return 0;
+}
+/* { dg-final { object-size text <= 12 } } */


> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Thursday, October 30, 2014 1:27 PM
> To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, ifcvt] Check size cost in noce_try_store_flag_mask
> 
> On 10/26/14 19:53, Zhenqiang Chen wrote:
> > Hi,
> >
> > Function noce_try_store_flag_mask converts "if (test) x = 0;" to "x &=
> > -(test == 0);"
> >
> > But from code size view, "x &= -(test == 0);" might have more
> > instructions than "if (test) x = 0;". The patch checks the cost to
> > determine the conversion is valuable or not.
> >
> > Bootstrap and no make check regression on X86-64.
> > No make check regression with Cortex-M0 qemu.
> > For CSiBE, ARM Cortex-m0 result is a little better. A little
> > regression for MIPS. Roughly no change for PowerPC.
> >
> > OK for trunk?
> >
> > Thanks!
> > -Zhenqiang
> >
> > ChangeLog:
> > 2014-10-27  Zhenqiang Chen  
> >
> > * ifcvt.c (noce_try_store_flag_mask): Check rtx cost.
> >
> > testsuite/ChangeLog:
> > 2014-10-27  Zhenqiang Chen  
> >
> > * gcc.target/arm/ifcvt-size-check.c: New test.
> >
> > diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c index 949d2b4..3abd518 100644
> > --- a/gcc/ifcvt.c
> > +++ b/gcc/ifcvt.c
> > @@ -1393,6 +1393,14 @@ noce_try_store_flag_mask (struct noce_if_info
> > *if_info)
> >   if (!seq)
> > return FALSE;
> >
> > + if (optimize_function_for_size_p (cfun))
> > +   {
> > + int old_cost = COSTS_N_INSNS (if_info->branch_cost + 1);
> > + int new_cost = seq_cost (seq, 0);
> > + if (new_cost > old_cost)
> > +   return FALSE;
> > +   }
> > +
> As Andrew pointed out, there's really no reason to limit this to cases
where
> we're optimizing for size.  So that check should be removed.
> 
> You should also engage with Michael to determine if the MIPS regressions
> are significant enough to warrant deeper investigation.  My gut tells me
that
> if MIPS is regressing because of this, then that's going to be an issue in
the
> MIPS costing model that the MIPS folks will ultimately need to fix.
> 
> jeff
> 






Re: [PATCH, ifcvt] Check size cost in noce_try_store_flag_mask

2014-10-30 Thread Andrew Pinski
On Thu, Oct 30, 2014 at 11:30 PM, Zhenqiang Chen  wrote:
> Thank you all for the comments. Patch is updated.
>
> Bootstrap and no make check regression on X86-64.
> No make check regression with Cortex-M0 qemu.
> No performance changes for coremark, dhrystone, spec2000 and spec2006 on
> X86-64 and Cortex-A15.
>
> For CSiBE, ARM Cortex-M0 result is a little better. A little regression for
> MIPS (less than 0.01%).

I think I have a fix for MIPS which I need to submit too.  The problem
is IF_THEN_ELSE is not implemented for mips_rtx_costs.

Something like the attached one (though It is not updated for the new
cores including octeon3).

Thanks,
Andrew Pinski

>
> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index 653653f..7bb2578 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
> @@ -1393,6 +1393,9 @@ noce_try_store_flag_mask (struct noce_if_info
> *if_info)
>
>if (target)
> {
> + int old_cost, new_cost, insn_cost;
> + int speed_p;
> +
>   if (target != if_info->x)
> noce_emit_move_insn (if_info->x, target);
>
> @@ -1400,6 +1403,14 @@ noce_try_store_flag_mask (struct noce_if_info
> *if_info)
>   if (!seq)
> return FALSE;
>
> + speed_p = optimize_bb_for_speed_p (BLOCK_FOR_INSN
> (if_info->insn_a));
> + insn_cost = insn_rtx_cost (PATTERN (if_info->insn_a), speed_p);
> + old_cost = COSTS_N_INSNS (if_info->branch_cost) + insn_cost;
> + new_cost = seq_cost (seq, speed_p);
> +
> + if (new_cost > old_cost)
> +   return FALSE;
> +
>   emit_insn_before_setloc (seq, if_info->jump,
>INSN_LOCATION (if_info->insn_a));
>   return TRUE;
> diff --git a/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
> b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
> new file mode 100644
> index 000..43fa16b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/ifcvt-size-check.c
> @@ -0,0 +1,13 @@
> +/* { dg-do assemble } */
> +/* { dg-options "-mthumb -Os " }  */
> +/* { dg-require-effective-target arm_thumb1_ok } */
> +
> +int
> +test (unsigned char iov_len, int count, int i) {
> +  unsigned char bytes = 0;
> +  if ((unsigned char) ((char) 127 - bytes) < iov_len)
> +return 22;
> +  return 0;
> +}
> +/* { dg-final { object-size text <= 12 } } */
>
>
>> -Original Message-
>> From: Jeff Law [mailto:l...@redhat.com]
>> Sent: Thursday, October 30, 2014 1:27 PM
>> To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH, ifcvt] Check size cost in noce_try_store_flag_mask
>>
>> On 10/26/14 19:53, Zhenqiang Chen wrote:
>> > Hi,
>> >
>> > Function noce_try_store_flag_mask converts "if (test) x = 0;" to "x &=
>> > -(test == 0);"
>> >
>> > But from code size view, "x &= -(test == 0);" might have more
>> > instructions than "if (test) x = 0;". The patch checks the cost to
>> > determine the conversion is valuable or not.
>> >
>> > Bootstrap and no make check regression on X86-64.
>> > No make check regression with Cortex-M0 qemu.
>> > For CSiBE, ARM Cortex-m0 result is a little better. A little
>> > regression for MIPS. Roughly no change for PowerPC.
>> >
>> > OK for trunk?
>> >
>> > Thanks!
>> > -Zhenqiang
>> >
>> > ChangeLog:
>> > 2014-10-27  Zhenqiang Chen  
>> >
>> > * ifcvt.c (noce_try_store_flag_mask): Check rtx cost.
>> >
>> > testsuite/ChangeLog:
>> > 2014-10-27  Zhenqiang Chen  
>> >
>> > * gcc.target/arm/ifcvt-size-check.c: New test.
>> >
>> > diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c index 949d2b4..3abd518 100644
>> > --- a/gcc/ifcvt.c
>> > +++ b/gcc/ifcvt.c
>> > @@ -1393,6 +1393,14 @@ noce_try_store_flag_mask (struct noce_if_info
>> > *if_info)
>> >   if (!seq)
>> > return FALSE;
>> >
>> > + if (optimize_function_for_size_p (cfun))
>> > +   {
>> > + int old_cost = COSTS_N_INSNS (if_info->branch_cost + 1);
>> > + int new_cost = seq_cost (seq, 0);
>> > + if (new_cost > old_cost)
>> > +   return FALSE;
>> > +   }
>> > +
>> As Andrew pointed out, there's really no reason to limit this to cases
> where
>> we're optimizing for size.  So that check should be removed.
>>
>> You should also engage with Michael to determine if the MIPS regressions
>> are significant enough to warrant deeper investigation.  My gut tells me
> that
>> if MIPS is regressing because of this, then that's going to be an issue in
> the
>> MIPS costing model that the MIPS folks will ultimately need to fix.
>>
>> jeff
>>
>
>
>
>


gcc.git-f37a94987366f2464c7122fa66b8f50797a26f11.patch
Description: Binary data


Re: [Patch, MIPS] Add Octeon3 support

2014-10-30 Thread Hurugalawadi, Naveen
Hi Catherine,

>> Would you please add some testcases and resubmit your patch?

Thanks for the review and suggestions.
Added the testcase "gcc.target/mips/octeon3-pipe-1.c"

Please review the modified patch and let us know if its good.

Thanks,
Naveen

2014-10-31  Andrew Pinski  

* config/mips/mips-cpus.def (octeon3): New cpu.
* config/mips/mips.c (mips_rtx_cost_data): Add octeon3.
(mips_print_operand ): Fix a bug as the mode
of the comparison no longer matches mode of the operands.
(mips_issue_rate): Handle PROCESSOR_OCTEON3.
* config/mips/mips.h (TARGET_OCTEON):  Add Octeon3.
(TARGET_OCTEON2): Likewise.
(TUNE_OCTEON): Add Octeon3.
* config/mips/mips.md (processor): Add octeon3.
* config/mips/octeon.md (octeon_fpu): New automaton and cpu_unit.
(octeon_arith): Add octeon3.
(octeon_condmove): Remove.
(octeon_condmove_o1): New reservation.
(octeon_condmove_o2): New reservation.
(octeon_condmove_o3_int_on_cc): New reservation.
(octeon_load_o2): Add octeon3.
(octeon_cop_o2): Likewise.
(octeon_store): Likewise.
(octeon_brj_o2): Likewise.
(octeon_imul3_o2): Likewise.
(octeon_imul_o2): Likewise.
(octeon_mfhilo_o2): Likewise.
(octeon_imadd_o2): Likewise.
(octeon_idiv_o2_si): Likewise.
(octeon_idiv_o2_di): Likewise.
(octeon_fpu): Add to the automaton.
(octeon_fpu): New cpu unit.
(octeon_condmove_o2): Check for non floating point modes.
(octeon_load_o2): Add prefetchx.
(octeon_cop_o2): Don't check for octeon3.
(octeon3_faddsubcvt): New reservation.
(octeon3_fmul): Likewise.
(octeon3_fmadd): Likewise.
(octeon3_div_sf): Likewise.
(octeon3_div_df): Likewise.
(octeon3_sqrt_sf): Likewise.
(octeon3_sqrt_df): Likewise.
(octeon3_rsqrt_sf): Likewise.
(octeon3_rsqrt_df): Likewise.
(octeon3_fabsnegmov): Likewise.
(octeon_fcond): Likewise.
(octeon_fcondmov): Likewise.
(octeon_fpmtc1): Likewise.
(octeon_fpmfc1): Likewise.
(octeon_fpload): Likewise.
(octeon_fpstore): Likewise.
* config/mips/mips-tables.opt: Regenerate.
* doc/invoke.texi (-march=@var{arch}): Add octeon3.

2014-10-31  Naveen H.S  

* gcc.target/mips/octeon3-pipe-1.c: New test.diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 28ae552..77455a2 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,54 @@
+2014-10-31  Andrew Pinski  
+
+	* config/mips/mips-cpus.def (octeon3): New cpu.
+	* config/mips/mips.c (mips_rtx_cost_data): Add octeon3.
+	(mips_print_operand ): Fix a bug as the mode
+	of the comparison no longer matches mode of the operands.
+	(mips_issue_rate): Handle PROCESSOR_OCTEON3.
+	* config/mips/mips.h (TARGET_OCTEON):  Add Octeon3.
+	(TARGET_OCTEON2): Likewise.
+	(TUNE_OCTEON): Add Octeon3.
+	* config/mips/mips.md (processor): Add octeon3.
+	* config/mips/octeon.md (octeon_fpu): New automaton and cpu_unit.
+	(octeon_arith): Add octeon3.
+	(octeon_condmove): Remove.
+	(octeon_condmove_o1): New reservation.
+	(octeon_condmove_o2): New reservation.
+	(octeon_condmove_o3_int_on_cc): New reservation.
+	(octeon_load_o2): Add octeon3.
+	(octeon_cop_o2): Likewise.
+	(octeon_store): Likewise.
+	(octeon_brj_o2): Likewise.
+	(octeon_imul3_o2): Likewise.
+	(octeon_imul_o2): Likewise.
+	(octeon_mfhilo_o2): Likewise.
+	(octeon_imadd_o2): Likewise.
+	(octeon_idiv_o2_si): Likewise.
+	(octeon_idiv_o2_di): Likewise.
+	(octeon_fpu): Add to the automaton.
+	(octeon_fpu): New cpu unit.
+	(octeon_condmove_o2): Check for non floating point modes.
+	(octeon_load_o2): Add prefetchx.
+	(octeon_cop_o2): Don't check for octeon3.
+	(octeon3_faddsubcvt): New reservation.
+	(octeon3_fmul): Likewise.
+	(octeon3_fmadd): Likewise.
+	(octeon3_div_sf): Likewise.
+	(octeon3_div_df): Likewise.
+	(octeon3_sqrt_sf): Likewise.
+	(octeon3_sqrt_df): Likewise.
+	(octeon3_rsqrt_sf): Likewise.
+	(octeon3_rsqrt_df): Likewise.
+	(octeon3_fabsnegmov): Likewise.
+	(octeon_fcond): Likewise.
+	(octeon_fcondmov): Likewise.
+	(octeon_fpmtc1): Likewise.
+	(octeon_fpmfc1): Likewise.
+	(octeon_fpload): Likewise.
+	(octeon_fpstore): Likewise.
+	* config/mips/mips-tables.opt: Regenerate.
+	* doc/invoke.texi (-march=@var{arch}): Add octeon3.
+
 2014-10-10  Felix Yang  
 
 	* config/xtensa/xtensa.h (TARGET_LOOPS): New Macro.
diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-cpus.def
index d5528d3..e2985b8 100644
--- a/gcc/config/mips/mips-cpus.def
+++ b/gcc/config/mips/mips-cpus.def
@@ -162,4 +162,5 @@ MIPS_CPU ("loongson3a", PROCESSOR_LOONGSON_3A, 65, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU ("octeon", PROCESSOR_OCTEON, 65, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU ("octeon+", PROCESSOR_OCTEON, 65, PTF_AVOID_BRANCHLIKELY)
 MIPS_CPU ("octeon2", PROCESSOR_OCTEON2, 65, PTF_AVOID_BRANCHLIKELY)
+MIPS_CPU ("octeon3", PROCESSOR_OCTE