Re: [PATCH 1/3] Fix logic bug in Cilk Plus array expansion

[Jakub Jelinek]

On Fri, Jan 01, 2016 at 10:06:34PM -0700, Jeff Law wrote:
> >gcc/cp/ChangeLog:
> >
> > * cp-array-notation.c (cp_expand_cond_array_notations): Return
> > error_mark_node only if find_rank failed, not if it was
> > successful.
> Can you use -fdump-tree-original in the testcase and verify there's no <<<
> error >>> expressions in the resulting dump file?
> 
> With that change, this is OK.

I think the patch is incomplete.  Because, find_rank does not always emit
an error if it returns false, so we again have cases where we can get
error_mark_node in the code without error being emitted.
  else if (*rank != current_rank)
{
  /* In this case, find rank is being recursed through a set of
 expression of the form A  B, where A and B both have
 array notations in them and the rank of A is not equal to rank of 
B.
 A simple example of such case is the following: X[:] + Y[:][:] */
  *rank = current_rank;
  return false;
}
and other spots.  E.g.
  if (prev_arg && EXPR_HAS_LOCATION (prev_arg))
error_at (EXPR_LOCATION (prev_arg),
  "rank mismatch between %qE and %qE", prev_arg,
  TREE_OPERAND (expr, ii));
looks very suspicious.

Jakub

Re: [PATCH] ia64: don't use dynamic relocations for local symbols

[Eric Botcazou]

> Normally we'd require a bootstrap & regression test.  We're more lenient
> with patches to dead architectures. 

I can do it if Sergei or others cannot though.

-- 
Eric Botcazou

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[Richard Biener]

On January 2, 2016 11:32:33 AM GMT+01:00, Uros Bizjak  wrote:
>On Thu, Dec 31, 2015 at 4:29 PM, H.J. Lu  wrote:
>> On Thu, Dec 31, 2015 at 1:14 AM, Uros Bizjak 
>wrote:
>>> On Wed, Dec 30, 2015 at 9:53 PM, H.J. Lu 
>wrote:
 SSE vector arithmetic and logic instructions only accept aligned
>memory
 operand.  This patch adds vector_memory_operand and "Bm" constraint
>for
 aligned SSE memory operand.  They are applied to SSE any_logic
>patterns.

 OK for trunk and release branches if there are regressions?
>>>
>>> This patch is just papering over deeper problem, as Jakub said in
>the PR [1]:
>>>
>>> --q--
>>> GCC uses the ix86_legitimate_combined_insn target hook to disallow
>>> misaligned memory into certain SSE instructions.
>>> (subreg:V4SI (reg:TI 245 [ MEM[(const struct bitset
>&)FeatureEntry_21 + 8] ]) 0)
>>> is not misaligned memory, it is a subreg of a pseudo register, so it
>is fine.
>>> If the replacement of the pseudo register with memory happens in
>some
>>> other pass, then it probably either should use the
>>> legitimate_combined_insn target hook or some other one.  I think we
>>> have already a PR where that happens during live range shrinking.
>>> --/q--
>>>
>>> Please figure out where memory replacement happens. There are
>several
>>> other SSE insns (please grep the .md for "ssememalign" attribute)
>that
>>> are affected by this problem, so fixing a couple of patterns won't
>>> solve the problem completely.
>>
>> LRA turns
>>
>> insn 64 63 108 6 (set (reg:V4SI 148 [ vect__28.85 ])
>> (xor:V4SI (reg:V4SI 149)
>> (subreg:V4SI (reg:TI 147 [ MEM[(const struct bitset
>> &)FeatureEntry_2(D)] ]) 0))) foo.ii:26 3454 {*xorv4si3}
>>  (expr_list:REG_DEAD (reg:V4SI 149)
>> (expr_list:REG_DEAD (reg:TI 147 [ MEM[(const struct bitset
>> &)FeatureEntry_2(D)] ])
>> (expr_list:REG_EQUIV (mem/c:V4SI (plus:DI (reg/f:DI 20
>frame)
>> (const_int -16 [0xfff0])) [3
>> MEM[(unsigned int *)]+0 S16 A128])
>> (nil)
>>
>> into
>>
>> (insn 64 63 108 6 (set (reg:V4SI 21 xmm0 [orig:148 vect__28.85 ]
>[148])
>> (xor:V4SI (reg:V4SI 21 xmm0 [149])
>> (mem:V4SI (reg/v/f:DI 4 si [orig:117 FeatureEntry ]
>[117])
>> [6 MEM[(const struct bitset &)FeatureEntry_2(D)]+0 S16 A32])))
>> foo.ii:26 3454 {*xorv4si3}
>>  (expr_list:REG_EQUIV (mem/c:V4SI (plus:DI (reg/f:DI 20 frame)
>> (const_int -16 [0xfff0])) [3
>MEM[(unsigned
>> int *)]+0 S16 A128])
>> (nil)))
>>
>> since
>>
>> (mem:V4SI (reg/v/f:DI 4 si [orig:117 FeatureEntry ] [117]) [6
>> MEM[(const struct bitset &)FeatureEntry_2(D)]+0 S16 A32])))
>>
>> satisfies the 'm" constraint.  I don't think LRA should call
>> ix86_legitimate_combined_insn to validate to validate constraints on
>> an instruction.
>
>Hm...
>
>if LRA desn't assume that generic "m" constraint implies at least
>natural alignment of propageted operand, then your patch is the way to
>go. 

I don't think it even considers alignment. Archs where alignment validity 
depends on the actual instruction should model this with proper constraints.

But in this case, *every* SSE vector memory constraint should be
>changed to Bm.

I'd say so ...

>
>Let's ask Vladimir for details.
>
>Uros.

Re: [PATCH] * doc/invoke.texi: fix typos of -finite-math-only

[Vladimír Čunát]

On 01/02/2016 12:13 AM, Sandra Loosemore wrote:
> On 01/01/2016 12:31 PM, Vladimír Čunát wrote:
>> I noticed tiny typos in the docs.
>> (CC me with replies, please, as I'm not reading the list.)
> 
> This patch is fine with an appropriate ChangeLog entry.  Generally,
> fixing typos in documentation or comments falls under the "obvious
> patch" rule, so it doesn't need explicit approval anyway.

What about using the simple line that's in the subject?

I didn't realize even such tiny changes need a changelog entry.
(I'm used to handling such information by version control instead.)

Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

On 21.04.2015 16:37, Jakub Jelinek wrote:

On Tue, Apr 21, 2015 at 04:29:52PM +0200, Matthias Klose wrote:

On 04/21/2015 04:19 PM, Jakub Jelinek wrote:

On Tue, Apr 21, 2015 at 04:16:18PM +0200, Matthias Klose wrote:

On 04/21/2015 04:11 PM, Jakub Jelinek wrote:

On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote:

bump the libgcj soname on the trunk, as done for every release cycle,


Is that really needed though these days?
Weren't there basically zero changes to libjava (both libjava and
libjava/classpath) in the last 2 or more years?
The few ones were mostly updating Copyright notices, minor configure
changes, but I really haven't seen anything ABI changing for quite a while.


yes, the GCC version is embedded in the GCJ_VERSIONED_LIBDIR

which is defined as

gcjsubdir=gcj-$gcjversion-$libgcj_soversion
dbexecdir='$(toolexeclibdir)/'$gcjsubdir


But why is that an argument for bumping it?  If both GCC 5 and GCC 6 will
(likely) provide the same ABI in the library, there is no reason not to use
the same directory for those.


but currently there are different directories used (gcjversion already changed
on the trunk) and compiled into the library.  Do you mean that gcjsubdir should
be just defined as gcj?


What depends on BASE-VER sure, that is bumped automatically and should track
the gcc version.  But the soname, which is an unrelated number, there is no
point to bump it.  If you have a packaging issue, just solve it on the
packaging side, but really there is no point to yearly bump a soname of
something that doesn't change at all (and is really dead project for many
years).


preparing for a test rebuild of the archive, and trying to run gcj-dbtool (from 
GCC 5) with libgcj16 (from GCC 6):


$ gcj-dbtool -n /tmp/foo.db
libgcj failure: gcj linkage error.
Incorrect library ABI version detected.  Aborting.

Aborted (core dumped)

natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is defined 
as

libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 10 + 
__GNUC_MINOR__ * 1000)


so this will be seen with everything directly linked to libgcj with a libgcj16 
upgraded to GCC 6. So what to do? Bump the soname, or discard this check?


In any case, GCJ_CXX_ABI_VERSION should be changed to not include __GNUC_MINOR__ 
anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so that it 
won't change anymore with future releases from the gcc-5 branch?


Matthias

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[Uros Bizjak]

On Thu, Dec 31, 2015 at 4:29 PM, H.J. Lu  wrote:
> On Thu, Dec 31, 2015 at 1:14 AM, Uros Bizjak  wrote:
>> On Wed, Dec 30, 2015 at 9:53 PM, H.J. Lu  wrote:
>>> SSE vector arithmetic and logic instructions only accept aligned memory
>>> operand.  This patch adds vector_memory_operand and "Bm" constraint for
>>> aligned SSE memory operand.  They are applied to SSE any_logic patterns.
>>>
>>> OK for trunk and release branches if there are regressions?
>>
>> This patch is just papering over deeper problem, as Jakub said in the PR [1]:
>>
>> --q--
>> GCC uses the ix86_legitimate_combined_insn target hook to disallow
>> misaligned memory into certain SSE instructions.
>> (subreg:V4SI (reg:TI 245 [ MEM[(const struct bitset &)FeatureEntry_21 + 8] 
>> ]) 0)
>> is not misaligned memory, it is a subreg of a pseudo register, so it is fine.
>> If the replacement of the pseudo register with memory happens in some
>> other pass, then it probably either should use the
>> legitimate_combined_insn target hook or some other one.  I think we
>> have already a PR where that happens during live range shrinking.
>> --/q--
>>
>> Please figure out where memory replacement happens. There are several
>> other SSE insns (please grep the .md for "ssememalign" attribute) that
>> are affected by this problem, so fixing a couple of patterns won't
>> solve the problem completely.
>
> LRA turns
>
> insn 64 63 108 6 (set (reg:V4SI 148 [ vect__28.85 ])
> (xor:V4SI (reg:V4SI 149)
> (subreg:V4SI (reg:TI 147 [ MEM[(const struct bitset
> &)FeatureEntry_2(D)] ]) 0))) foo.ii:26 3454 {*xorv4si3}
>  (expr_list:REG_DEAD (reg:V4SI 149)
> (expr_list:REG_DEAD (reg:TI 147 [ MEM[(const struct bitset
> &)FeatureEntry_2(D)] ])
> (expr_list:REG_EQUIV (mem/c:V4SI (plus:DI (reg/f:DI 20 frame)
> (const_int -16 [0xfff0])) [3
> MEM[(unsigned int *)]+0 S16 A128])
> (nil)
>
> into
>
> (insn 64 63 108 6 (set (reg:V4SI 21 xmm0 [orig:148 vect__28.85 ] [148])
> (xor:V4SI (reg:V4SI 21 xmm0 [149])
> (mem:V4SI (reg/v/f:DI 4 si [orig:117 FeatureEntry ] [117])
> [6 MEM[(const struct bitset &)FeatureEntry_2(D)]+0 S16 A32])))
> foo.ii:26 3454 {*xorv4si3}
>  (expr_list:REG_EQUIV (mem/c:V4SI (plus:DI (reg/f:DI 20 frame)
> (const_int -16 [0xfff0])) [3 MEM[(unsigned
> int *)]+0 S16 A128])
> (nil)))
>
> since
>
> (mem:V4SI (reg/v/f:DI 4 si [orig:117 FeatureEntry ] [117]) [6
> MEM[(const struct bitset &)FeatureEntry_2(D)]+0 S16 A32])))
>
> satisfies the 'm" constraint.  I don't think LRA should call
> ix86_legitimate_combined_insn to validate to validate constraints on
> an instruction.

Hm...

if LRA desn't assume that generic "m" constraint implies at least
natural alignment of propageted operand, then your patch is the way to
go. But in this case, *every* SSE vector memory constraint should be
changed to Bm.

Let's ask Vladimir for details.

Uros.

Re: RFA: PR 68770: Fix use of uninitialised value in secondary_reload

[Markus Trippelsdorf]

On 2016.01.01 at 22:33 -0700, Jeff Law wrote:
> On 12/22/2015 03:04 AM, Nick Clifton wrote:
> >Hi Guys,
> >
> >   The patch below fixes PR 68770 - a warning from valgrind about an
> >   uninitialised value being used in the default_secondary_reload.  The
> >   problem turns out to the in copy_costs which creates its own secondary
> >   reload information structure, but it does not initialise all of the
> >   fields.  One field in particular - t_icode - is examined by
> >   default_secondary_reload, and it was this that was triggering the
> >   valgrind warning.
> >
> >   Tested with no regressions on a x86_64-pc-linux-gnu and a
> >   powerpc64-le-linux-gnu toolchain.
> >
> >   OK to apply ?
> >
> >Cheers
> >   Nick
> >
> >gcc/ChangeLog
> >2015-12-22  Nick Clifton  
> >
> > PR target/68770
> > * ira-costs.c (copy_cost): Initialise the t_code field of the sri
> > structure.
> Can you please reduce the testcase from the BZ so that it can be included in
> the testsuite?  I realize it might take a long time with multidelta because
> of the need to run the compiler with valgrind.  But once you've got the
> right script, you ought to be able to just let it run overnight or whatever.
> 
> To speed things up, you might consider first trying to compile the case
> without valgrind and if that fails, then that particular reduction is "not
> interesting".  That should dramatically cut down on the number of times you
> have to run the compiler under valgrind control.
> 
> With a testcase, this is fine.

trippels@gcc2-power8 ~ % cat parallel_settings.ii
struct A {
  unsigned long a;
  float f;
  A() : f(0.01f) {}
};
A s;

trippels@gcc2-power8 ~ % valgrind -q --trace-children=yes g++ -O2 -c 
parallel_settings.ii
==149056== Conditional jump or move depends on uninitialised value(s)
==149056==at 0x10A78484: default_secondary_reload(bool, rtx_def*, int, 
machine_mode, secondary_reload_info*) (targhooks.c:940)
==149056==by 0x10E50D03: rs6000_secondary_reload(bool, rtx_def*, int, 
machine_mode, secondary_reload_info*) (rs6000.c:18414)
==149056==by 0x1085F137: copy_cost(rtx_def*, machine_mode, int, bool, 
secondary_reload_info*) [clone .part.7] (ira-costs.c:445)
==149056==by 0x1085F1A7: copy_cost (ira-costs.c:434)
==149056==by 0x1085F1A7: copy_cost(rtx_def*, machine_mode, int, bool, 
secondary_reload_info*) [clone .part.7] (ira-costs.c:452)
==149056==by 0x1085F6E3: copy_cost (ira-costs.c:434)
==149056==by 0x1085F6E3: record_reg_classes(int, int, rtx_def**, 
machine_mode*, char const**, rtx_insn*, reg_class*) [clone .constprop.43] 
(ira-costs.c:984)
==149056==by 0x10861A7F: record_operand_costs(rtx_insn*, reg_class*) 
(ira-costs.c:1325)
==149056==by 0x10861FCB: scan_one_insn (ira-costs.c:1462)
==149056==by 0x10861FCB: process_bb_for_costs(basic_block_def*) 
(ira-costs.c:1583)
==149056==by 0x10857D2F: ira_traverse_loop_tree(bool, ira_loop_tree_node*, 
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1798)
==149056==by 0x108649FF: find_costs_and_classes(_IO_FILE*) 
(ira-costs.c:1680)
==149056==by 0x108651B3: ira_costs() (ira-costs.c:2213)
==149056==by 0x1085C09B: ira_build() (ira-build.c:3419)
==149056==by 0x10851D3B: ira (ira.c:5221)
==149056==by 0x10851D3B: (anonymous 
namespace)::pass_ira::execute(function*) (ira.c:5513)
==149056== 

-- 
Markus

[PATCH v2] ia64: don't use dynamic relocations for local symbols

[Sergei Trofimovich]

On Sat, 2 Jan 2016 00:30:58 -0700
Jeff Law  wrote:

> > That way gcc will be able to compile glibc's ld: PR/60465
> Egad. PIC on ia64 is a mess. I can kind of see what Richard was trying 
> to do, but ewww. I don't think it's worth the effort to deep dive into 
> the PIC support and make ia64 handle things like most other ports -- 
> it's a dead architecture so ISTM the easiest fix is the right fix.
> 
> A few, relatively minor things.

> > diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
> > index f48cebc..6ea5072 100644
> > --- a/gcc/config/ia64/ia64.c
> > +++ b/gcc/config/ia64/ia64.c
> > @@ -1105,6 +1105,8 @@ ia64_expand_load_address (rtx dest, rtx src)
> >   emit_insn (gen_load_fptr (dest, src));
> > else if (sdata_symbolic_operand (src, VOIDmode))
> >   emit_insn (gen_load_gprel (dest, src));
> > +  else if (local_symbolic_operand64 (src, VOIDmode))
> > +emit_insn (gen_load_gprel64 (dest, src));
> Comment here.  Something like
> 
> /* We want to use gprel rather than ltoff relocations for
> local symbolic operands.  */
Done. Hope not too wordy :)

> 
> >
> > +;; True if OP refers to a local symbol +any large offset).
> ;; True if OP refers to a local symbol [+ any offset ]
> 
> I haven't dug into the ia64 port (and I'm not planning to) to see if/how 
> it MINUS in symbolic expressions.  It's been the source of problems in 
> various ports trough the years.
> 
> Can you take the testcase from your post as well as the one from BZ60465 
> comment #37 (from you) and add them to the testsuite?
Added both tests.

> Note you're not running the full testsuite, just a few dozen ia64 
> specific tests, which will include your new tests.  ANd you're not 
> rebuilding the whole compiler between those steps, just ia64.o and 
> relinking the compiler.  So it ought to be reasonably fast.
> 
> So to summarize, I think your patch needs the two trivial comment fixes 
> noted above, 2 testcases and the before/after results of running just 
> the ia64.exp tests.  Repost with that and I'll get it into the tree.

--- ia64-before.log 2016-01-02 11:20:21.0 +
+++ ia64-after.log  2016-01-02 11:22:37.0 +
@@ -1 +1 @@
-Test Run By slyfox on Sat Jan  2 11:19:38 2016
+Test Run By slyfox on Sat Jan  2 11:22:16 2016
@@ -26,2 +25,0 @@
-FAIL: gcc.target/ia64/pr60465-gprel64-c37.c scan-assembler-not @ltoffx
-FAIL: gcc.target/ia64/pr60465-gprel64.c scan-assembler-not @ltoffx
@@ -31,2 +29,2 @@
-# of expected passes147
-# of unexpected failures11
+# of expected passes149
+# of unexpected failures9

I did ran tests only on amd64 host thus the execution failure tests.

Attached updated patch and test runs on a crosscompiler before
and after the change.

Now I'm building on real ia64 hardware as
make bootstrap
make -k check

for both clean and patched trees.

-- 

  Sergei
From 04a34fd97cffae4f40e1c226489129f42f3ceb2a Mon Sep 17 00:00:00 2001
From: Sergei Trofimovich 
Date: Mon, 28 Dec 2015 17:33:43 +
Subject: [PATCH] ia64: don't use dynamic relocations for local symbols

Tested on the following example:

void * a[77] __attribute((visibility("hidden")));
void f(long o, void * v) { a[0x6eff - o + 66] = v; }

Before the patch generated code uses .GOT entry:

addl r14 = @ltoffx(a#), r1
ld8.mov r14 = [r14], a#

After the patch generated code uses static gprel relocation:

movl r14 = @gprel(a#)
add r14 = r1, r14

That way gcc will be able to compile glibc's ld: PR/60465

Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
Signed-off-by: Sergei Trofimovich 
---
 gcc/config/ia64/ia64.c |  9 
 gcc/config/ia64/predicates.md  | 26 +
 .../gcc.target/ia64/pr60465-gprel64-c37.c  | 10 
 gcc/testsuite/gcc.target/ia64/pr60465-gprel64.c| 27 ++
 4 files changed, 72 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/ia64/pr60465-gprel64-c37.c
 create mode 100644 gcc/testsuite/gcc.target/ia64/pr60465-gprel64.c

diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index f48cebc..ccf2bec 100644
--- a/gcc/config/ia64/ia64.c
+++ b/gcc/config/ia64/ia64.c
@@ -1105,6 +1105,15 @@ ia64_expand_load_address (rtx dest, rtx src)
 emit_insn (gen_load_fptr (dest, src));
   else if (sdata_symbolic_operand (src, VOIDmode))
 emit_insn (gen_load_gprel (dest, src));
+  else if (local_symbolic_operand64 (src, VOIDmode))
+{
+  /* We want to use @gprel rather than @ltoff relocations for local
+symbols:
+ - @gprel does not require dynamic linker
+ - and does not use .sdata section
+https://gcc.gnu.org/bugzilla/60465 */
+  emit_insn (gen_load_gprel64 (dest, src));
+}
   else
 {
   HOST_WIDE_INT addend = 0;
diff --git a/gcc/config/ia64/predicates.md 

Re: [patch] [java] bump libgcj soname

[Matthias Klose]

On 02.01.2016 16:39, Andrew Haley wrote:

On 02/01/16 14:40, Matthias Klose wrote:


preparing for a test rebuild of the archive, and trying to run gcj-dbtool (from
GCC 5) with libgcj16 (from GCC 6):

$ gcj-dbtool -n /tmp/foo.db
libgcj failure: gcj linkage error.
Incorrect library ABI version detected.  Aborting.

Aborted (core dumped)

natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is defined 
as

libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 10 +
__GNUC_MINOR__ * 1000)

so this will be seen with everything directly linked to libgcj with a libgcj16
upgraded to GCC 6. So what to do? Bump the soname, or discard this check?


I'd bump the soname.


In any case, GCJ_CXX_ABI_VERSION should be changed to not include __GNUC_MINOR__
anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so that it
won't change anymore with future releases from the gcc-5 branch?


That's safe only if Classpath and libgcj are not changed at all.


why?  __GNUC_SUBMINOR__ wasn't encoded either for releases up to 4.9.x.

Matthias

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[H.J. Lu]

On Sat, Jan 2, 2016 at 3:58 AM, Richard Biener
 wrote:
> On January 2, 2016 11:32:33 AM GMT+01:00, Uros Bizjak  
> wrote:
>>On Thu, Dec 31, 2015 at 4:29 PM, H.J. Lu  wrote:
>>> On Thu, Dec 31, 2015 at 1:14 AM, Uros Bizjak 
>>wrote:
 On Wed, Dec 30, 2015 at 9:53 PM, H.J. Lu 
>>wrote:
> SSE vector arithmetic and logic instructions only accept aligned
>>memory
> operand.  This patch adds vector_memory_operand and "Bm" constraint
>>for
> aligned SSE memory operand.  They are applied to SSE any_logic
>>patterns.
>
> OK for trunk and release branches if there are regressions?

 This patch is just papering over deeper problem, as Jakub said in
>>the PR [1]:

 --q--
 GCC uses the ix86_legitimate_combined_insn target hook to disallow
 misaligned memory into certain SSE instructions.
 (subreg:V4SI (reg:TI 245 [ MEM[(const struct bitset
>>&)FeatureEntry_21 + 8] ]) 0)
 is not misaligned memory, it is a subreg of a pseudo register, so it
>>is fine.
 If the replacement of the pseudo register with memory happens in
>>some
 other pass, then it probably either should use the
 legitimate_combined_insn target hook or some other one.  I think we
 have already a PR where that happens during live range shrinking.
 --/q--

 Please figure out where memory replacement happens. There are
>>several
 other SSE insns (please grep the .md for "ssememalign" attribute)
>>that
 are affected by this problem, so fixing a couple of patterns won't
 solve the problem completely.
>>>
>>> LRA turns
>>>
>>> insn 64 63 108 6 (set (reg:V4SI 148 [ vect__28.85 ])
>>> (xor:V4SI (reg:V4SI 149)
>>> (subreg:V4SI (reg:TI 147 [ MEM[(const struct bitset
>>> &)FeatureEntry_2(D)] ]) 0))) foo.ii:26 3454 {*xorv4si3}
>>>  (expr_list:REG_DEAD (reg:V4SI 149)
>>> (expr_list:REG_DEAD (reg:TI 147 [ MEM[(const struct bitset
>>> &)FeatureEntry_2(D)] ])
>>> (expr_list:REG_EQUIV (mem/c:V4SI (plus:DI (reg/f:DI 20
>>frame)
>>> (const_int -16 [0xfff0])) [3
>>> MEM[(unsigned int *)]+0 S16 A128])
>>> (nil)
>>>
>>> into
>>>
>>> (insn 64 63 108 6 (set (reg:V4SI 21 xmm0 [orig:148 vect__28.85 ]
>>[148])
>>> (xor:V4SI (reg:V4SI 21 xmm0 [149])
>>> (mem:V4SI (reg/v/f:DI 4 si [orig:117 FeatureEntry ]
>>[117])
>>> [6 MEM[(const struct bitset &)FeatureEntry_2(D)]+0 S16 A32])))
>>> foo.ii:26 3454 {*xorv4si3}
>>>  (expr_list:REG_EQUIV (mem/c:V4SI (plus:DI (reg/f:DI 20 frame)
>>> (const_int -16 [0xfff0])) [3
>>MEM[(unsigned
>>> int *)]+0 S16 A128])
>>> (nil)))
>>>
>>> since
>>>
>>> (mem:V4SI (reg/v/f:DI 4 si [orig:117 FeatureEntry ] [117]) [6
>>> MEM[(const struct bitset &)FeatureEntry_2(D)]+0 S16 A32])))
>>>
>>> satisfies the 'm" constraint.  I don't think LRA should call
>>> ix86_legitimate_combined_insn to validate to validate constraints on
>>> an instruction.
>>
>>Hm...
>>
>>if LRA desn't assume that generic "m" constraint implies at least
>>natural alignment of propageted operand, then your patch is the way to
>>go.
>
> I don't think it even considers alignment. Archs where alignment validity 
> depends on the actual instruction should model this with proper constraints.
>
> But in this case, *every* SSE vector memory constraint should be
>>changed to Bm.
>
> I'd say so ...

The "Bm" constraint should be applied only to non-move SSE
instructions with 16-byte memory operand.

-- 
H.J.

[PATCH 5/5] s390: Add -fsplit-stack support

[Marcin Kościelnicki]

libgcc/ChangeLog:

* config.host: Use t-stack and t-stack-s390 for s390*-*-linux.
* config/s390/morestack.S: New file.
* config/s390/t-stack-s390: New file.
* generic-morestack.c (__splitstack_find): Add s390-specific code.

gcc/ChangeLog:

* common/config/s390/s390-common.c (s390_supports_split_stack):
New function.
(TARGET_SUPPORTS_SPLIT_STACK): New macro.
* config/s390/s390-protos.h: Add s390_expand_split_stack_prologue.
* config/s390/s390.c (struct machine_function): New field
split_stack_varargs_pointer.
(s390_split_branches): Don't split split-stack pseudo-insns, rewire
split-stack prologue conditional jump instead of splitting it.
(s390_chunkify_start): Don't reload const pool register on split-stack
prologue conditional jumps.
(s390_register_info): Mark r12 as clobbered if it'll be used as temp
in s390_emit_prologue.
(s390_emit_prologue): Use r12 as temp if r1 is taken by split-stack
vararg pointer.
(morestack_ref): New global.
(SPLIT_STACK_AVAILABLE): New macro.
(s390_expand_split_stack_prologue): New function.
(s390_expand_split_stack_call_esa): New function.
(s390_expand_split_stack_call_zarch): New function.
(s390_live_on_entry): New function.
(s390_va_start): Use split-stack vararg pointer if appropriate.
(s390_reorg): Lower the split-stack pseudo-insns.
(s390_asm_file_end): Emit the split-stack note sections.
(TARGET_EXTRA_LIVE_ON_ENTRY): New macro.
* config/s390/s390.md: (UNSPEC_STACK_CHECK): New unspec.
(UNSPECV_SPLIT_STACK_CALL_ZARCH): New unspec.
(UNSPECV_SPLIT_STACK_CALL_ESA): New unspec.
(UNSPECV_SPLIT_STACK_SIBCALL): New unspec.
(UNSPECV_SPLIT_STACK_MARKER): New unspec.
(split_stack_prologue): New expand.
(split_stack_call_esa): New insn.
(split_stack_call_zarch_*): New insn.
(split_stack_cond_call_zarch_*): New insn.
(split_stack_space_check): New expand.
(split_stack_sibcall_basr): New insn.
(split_stack_sibcall_*): New insn.
(split_stack_cond_sibcall_*): New insn.
(split_stack_marker): New insn.
---
 gcc/ChangeLog|  41 ++
 gcc/common/config/s390/s390-common.c |  14 +
 gcc/config/s390/s390-protos.h|   1 +
 gcc/config/s390/s390.c   | 538 +-
 gcc/config/s390/s390.md  | 133 +++
 libgcc/ChangeLog |   7 +
 libgcc/config.host   |   4 +-
 libgcc/config/s390/morestack.S   | 718 +++
 libgcc/config/s390/t-stack-s390  |   2 +
 libgcc/generic-morestack.c   |   4 +
 10 files changed, 1454 insertions(+), 8 deletions(-)
 create mode 100644 libgcc/config/s390/morestack.S
 create mode 100644 libgcc/config/s390/t-stack-s390

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4c7046f..a4f4dff 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,46 @@
 2016-01-02  Marcin Kościelnicki  
 
+   * common/config/s390/s390-common.c (s390_supports_split_stack):
+   New function.
+   (TARGET_SUPPORTS_SPLIT_STACK): New macro.
+   * config/s390/s390-protos.h: Add s390_expand_split_stack_prologue.
+   * config/s390/s390.c (struct machine_function): New field
+   split_stack_varargs_pointer.
+   (s390_split_branches): Don't split split-stack pseudo-insns, rewire
+   split-stack prologue conditional jump instead of splitting it.
+   (s390_chunkify_start): Don't reload const pool register on split-stack
+   prologue conditional jumps.
+   (s390_register_info): Mark r12 as clobbered if it'll be used as temp
+   in s390_emit_prologue.
+   (s390_emit_prologue): Use r12 as temp if r1 is taken by split-stack
+   vararg pointer.
+   (morestack_ref): New global.
+   (SPLIT_STACK_AVAILABLE): New macro.
+   (s390_expand_split_stack_prologue): New function.
+   (s390_expand_split_stack_call_esa): New function.
+   (s390_expand_split_stack_call_zarch): New function.
+   (s390_live_on_entry): New function.
+   (s390_va_start): Use split-stack vararg pointer if appropriate.
+   (s390_reorg): Lower the split-stack pseudo-insns.
+   (s390_asm_file_end): Emit the split-stack note sections.
+   (TARGET_EXTRA_LIVE_ON_ENTRY): New macro.
+   * config/s390/s390.md: (UNSPEC_STACK_CHECK): New unspec.
+   (UNSPECV_SPLIT_STACK_CALL_ZARCH): New unspec.
+   (UNSPECV_SPLIT_STACK_CALL_ESA): New unspec.
+   (UNSPECV_SPLIT_STACK_SIBCALL): New unspec.
+   (UNSPECV_SPLIT_STACK_MARKER): New unspec.
+   (split_stack_prologue): New expand.
+   (split_stack_call_esa): New insn.
+   (split_stack_call_zarch_*): New insn.
+   (split_stack_cond_call_zarch_*): New insn.
+   (split_stack_space_check): New 

[PATCH 1/5] s390: Use proper read-only data section for literals.

[Marcin Kościelnicki]

Previously, .rodata was hardcoded.  For C++ vague linkage functions,
this resulted in needlessly duplicated literals.  With the new split
stack support, this resulted in link errors, due to .rodata containing
relocations to the discarded text sections.

gcc/ChangeLog:

* config/s390/s390.md (pool_section_start): Use switch_to_section
to select proper read-only data section instead of hardcoding .rodata.
(pool_section_end): Use switch_to_section to match the above.
---
 gcc/ChangeLog   |  6 ++
 gcc/config/s390/s390.md | 11 +--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 23ce209..2c572a7 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-01-02  Marcin Kościelnicki  
+
+   * config/s390/s390.md (pool_section_start): Use switch_to_section
+   to select proper read-only data section instead of hardcoding .rodata.
+   (pool_section_end): Use switch_to_section to match the above.
+
 2016-01-01  Sandra Loosemore  
 
PR 1078
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index a1fc96a..0ebefd6 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -10247,13 +10247,20 @@
 (define_insn "pool_section_start"
   [(unspec_volatile [(const_int 1)] UNSPECV_POOL_SECTION)]
   ""
-  ".section\t.rodata"
+{
+  switch_to_section (targetm.asm_out.function_rodata_section
+(current_function_decl));
+  return "";
+}
   [(set_attr "length" "0")])
 
 (define_insn "pool_section_end"
   [(unspec_volatile [(const_int 0)] UNSPECV_POOL_SECTION)]
   ""
-  ".previous"
+{
+  switch_to_section (current_function_section ());
+  return "";
+}
   [(set_attr "length" "0")])
 
 (define_insn "main_base_31_small"
-- 
2.6.4

[PATCH 2/5] s390: Fix missing .size directives.

[Marcin Kościelnicki]

It seems at some point the .size hook was hijacked to emit some
machine-specific directives, and the actual .size directive was
forgotten.  This caused problems for split-stack support, since
linker couldn't scan the function body for non-split-stack calls.

gcc/ChangeLog:

* config/s390/s390.c (s390_asm_declare_function_size): Add code
to actually emit the .size directive.
---
 gcc/ChangeLog  | 5 +
 gcc/config/s390/s390.c | 4 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 2c572a7..6aef3f9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,10 @@
 2016-01-02  Marcin Kościelnicki  
 
+   * config/s390/s390.c (s390_asm_declare_function_size): Add code
+   to actually emit the .size directive.
+
+2016-01-02  Marcin Kościelnicki  
+
* config/s390/s390.md (pool_section_start): Use switch_to_section
to select proper read-only data section instead of hardcoding .rodata.
(pool_section_end): Use switch_to_section to match the above.
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 16045f0..9dc8d1e 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -6834,8 +6834,10 @@ s390_asm_output_function_prefix (FILE *asm_out_file,
 
 void
 s390_asm_declare_function_size (FILE *asm_out_file,
-   const char *fnname ATTRIBUTE_UNUSED, tree decl)
+   const char *fnname, tree decl)
 {
+  if (!flag_inhibit_size_directive)
+ASM_OUTPUT_MEASURED_SIZE (asm_out_file, fnname);
   if (DECL_FUNCTION_SPECIFIC_TARGET (decl) == NULL)
 return;
   fprintf (asm_out_file, "\t.machine pop\n");
-- 
2.6.4

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 02/01/16 14:40, Matthias Klose wrote:
> 
> preparing for a test rebuild of the archive, and trying to run gcj-dbtool 
> (from 
> GCC 5) with libgcj16 (from GCC 6):
> 
> $ gcj-dbtool -n /tmp/foo.db
> libgcj failure: gcj linkage error.
> Incorrect library ABI version detected.  Aborting.
> 
> Aborted (core dumped)
> 
> natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is 
> defined as
> 
> libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 10 + 
> __GNUC_MINOR__ * 1000)
> 
> so this will be seen with everything directly linked to libgcj with a 
> libgcj16 
> upgraded to GCC 6. So what to do? Bump the soname, or discard this check?

I'd bump the soname.

> In any case, GCJ_CXX_ABI_VERSION should be changed to not include 
> __GNUC_MINOR__ 
> anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so that it 
> won't change anymore with future releases from the gcc-5 branch?

That's safe only if Classpath and libgcj are not changed at all.  I guess
we can guarantee that on the gcc-5 branch?

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 02/01/16 15:53, Matthias Klose wrote:
>>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include 
>>> __GNUC_MINOR__
>>> >> anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so 
>>> >> that it
>>> >> won't change anymore with future releases from the gcc-5 branch?
>> >
>> > That's safe only if Classpath and libgcj are not changed at all.
> why?

Because of the way that gcj's linkage works.  If you change any of the
vtable/itable indexes your program will crash.

Andrew.

[RFC] [PR 68191] s390: Add -fsplit-stack support.

[Marcin Kościelnicki]

Here's my attempt at adding -fsplit-stack support for s390 targets
(bug 68191).  Patches 1 and 2 fix s390-specific issues affecting split
stack code, and can be pushed independently of the main course.  Patches
3 and 4 attempt to fix target-independent issues involving unconditional
jumps with side effects (see below).  I'm not exactly sure I'm doing
the right thing in these, and I'd really welcome some feedback about
them and the general approach taken.  Patch 5 is split stack support
proper.  This patch should be used along with the matching glibc and
gold patches (I'll soon link them all in the bugzilla entry).

The generic approach is identical to x86: I add a new __private_ss
field to the TCB in glibc, add a target-specific __morestack function
and friends, emit a split-stack prologue, teach va_start to deal with
a dedicated vararg pointer, and teach gold to recognize the split-stack
prologue and handle non-split-stack calls by bumping the requested
frame size.

The differences start in the __morestack calling convention.  Basically,
since pushing things on stuck is unwieldy and there's only one free
register (%r0 could be used for static chain, %r2-%r6 contain arguments,
%r6-%r15 are callee-saved), I stuff the parameters somewhere in .rodata
or .text section, and pass the address of the parameter block in %r1.
The parameter block also contains a (position-relative) address that
__morestack should jump to (x86 just mangles the return address from
__morestack to compute that).  On zSeries CPUs, the parameter block
is stuffed somewhere in .rodata, its address loaded to %r1 by larl
instruction, and __morestack is sibling-called by jg instruction.
On older CPUs, lacking long jump and PC-relative load-address
instructions, I use the following sequence instead:

# load .L1 to %r1
basr %r1, 0 
.L1:
# Load __morestack to %r1
a %r1, .L2-.L1(%r1)
# Jump to __morestack and stuff return address (aka param block address)
# to %r1.
basr %r1, %r1
# param block comes here
.L3:
.long 
.long 
.long .L4-.L3
# relative __morestack address here
.L2:
.long __morestack-.L1
.L4:
# __morestack jumps here

As on other targets, the call to __morestack is conditional, based
on comparing the stack pointer with a field in TCB.  For zSeries,
I just make the jump to __morestack a conditional one, while for
older CPUs I emit a jump over the sequence.  Also, for vararg
functions, I need to stuff the vararg pointer in some register. Since
%r1 is again the only one guaranteed to be free, it's the one used.
If __morestack is called, it'll leave the correct pointer in %r1.
Otherwise, I emit a simple load-address instruction.  Since I only
need that instruction in the not-called branch (as opposed to x86
that emits it on both branches), I get terser code.

Now, here come the problems.  To keep optimization passes from
destroying the above sequence (as well as the simpler ones with larl),
I emit a pseudo-insn (split_stack_call_*) that is expanded to the
above in machine-dependent reorg phase, just like normal const pools.
The instruction is considered to be an unconditional jump to the .L4
label (since __morestack will jump to an arbitrary address selected
by param block anyway, that's what it effectively is).  For a zSeries
CPU with a conditional call, I represent the sequence as a conditional
jump instead.  So overall the sequences, as emitted by
s390_expand_split_stack_prologue, look as follows:

# (1) Old CPU, unconditional

.L4:
# Normal prologue starts here.

# (2) zSeries CPU, unconditional

.L4:
# Normal prologue starts here.

# Which will expand to:
larl %r1, .L3
jg __morestack
.section .rodata
.L3:
# Or .long for 31-bit target.
.quad 
.quad 
.quad .L4-.L3
.text

# (3) Old CPU, conditional

jhe .L5

.L5:
# Compute vararg pointer (vararg functions only)
la %r1, 96(%r15)
.L4:
# Normal prologue starts here.

# (4) zSeries CPU, conditional


# Compute vararg pointer (vararg functions only)
la %r1, 160(%r15)
.L4:
# Normal prologue starts here.
# Expands as above, except with jgl instead of jg.

Case (4) is the least problematic: conditional jumps with side effects
appear to work quite well.  However, the other variants involve an
unconditional jump with side effects, which causes two problems:

- If the jump is to immediately following label (which will happen always
  in cases (1) and (2), and for non-vararg functions in (3)),
  rtl_tidy_fallthru_edge mistakenly marks it as a fallthru edge, even
  though it correctly figures the jump cannot be removed due to the side
  effects.  This causes a verification failure later.
- In case (3), since the call to __morestack is considered to be unlikely,
  the basic block with the call pseudo-insn will be moved to the end of
  the function if we're optimizing.  Since it already ends with
  an unconditional jump, no new jump will be inserted (as opposed to x86).
  Soon afterwards, reposition_prologue_and_epilogue_notes will move
  NOTE_INSN_PROLOGUE_END after the last prologue instruction, which 

[PATCH 3/5] Fix NOTE_INSN_PROLOGUE_END after unconditional jump.

[Marcin Kościelnicki]

With the new s390 split-stack support, when optimization is enabled,
the cold path of calling __morestack is likely to be moved to the
end of the function.  This will result in the function ending in
split_stack_call_esa, which is an unconditional jump instruction and
part of the function prologue.  reposition_prologue_and_epilogue_notes
will insert NOTE_INSN_PROLOGUE_END right after it (and before the
following barrier), causing a verification error.  Insert it after
the barrier instead (and outside of basic block).

gcc/ChangeLog:

* function.c (reposition_prologue_and_epilogue_notes): Avoid
verification error if the last insn of prologue is an unconditional
jump.
---
 gcc/ChangeLog  | 6 ++
 gcc/function.c | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6aef3f9..56e31f6 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,11 @@
 2016-01-02  Marcin Kościelnicki  
 
+   * function.c (reposition_prologue_and_epilogue_notes): Avoid
+   verification error if the last insn of prologue is an unconditional
+   jump.
+
+2016-01-02  Marcin Kościelnicki  
+
* config/s390/s390.c (s390_asm_declare_function_size): Add code
to actually emit the .size directive.
 
diff --git a/gcc/function.c b/gcc/function.c
index 035a49e..921945f 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6348,6 +6348,12 @@ reposition_prologue_and_epilogue_notes (void)
  /* Avoid placing note between CODE_LABEL and BASIC_BLOCK note.  */
  if (LABEL_P (last))
last = NEXT_INSN (last);
+ if (BARRIER_P (last) && BLOCK_FOR_INSN (note))
+   {
+ if (BB_END (BLOCK_FOR_INSN (note)) == note)
+   BB_END (BLOCK_FOR_INSN (note)) = PREV_INSN (note);
+ BLOCK_FOR_INSN (note) = 0;
+   }
  reorder_insns (note, note, last);
}
 }
-- 
2.6.4

[PATCH 4/5] Don't mark targets of unconditional jumps with side effects as FALLTHRU.

[Marcin Kościelnicki]

When an unconditional jump with side effects targets an immediately
following label, rtl_tidy_fallthru_edge is called.  Since it has side
effects, it doesn't remove the jump, but the label is still marked
as fallthru.  This later causes a verification error.  Do nothing in this
case instead.

gcc/ChangeLog:

* cfgrtl.c (rtl_tidy_fallthru_edge): Bail for unconditional jumps
with side effects.
---
 gcc/ChangeLog | 5 +
 gcc/cfgrtl.c  | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 56e31f6..4c7046f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,10 @@
 2016-01-02  Marcin Kościelnicki  
 
+   * cfgrtl.c (rtl_tidy_fallthru_edge): Bail for unconditional jumps
+   with side effects.
+
+2016-01-02  Marcin Kościelnicki  
+
* function.c (reposition_prologue_and_epilogue_notes): Avoid
verification error if the last insn of prologue is an unconditional
jump.
diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index fbfc7cd..dc4c2b1 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -1762,6 +1762,8 @@ rtl_tidy_fallthru_edge (edge e)
  If block B consisted only of this single jump, turn it into a deleted
  note.  */
   q = BB_END (b);
+  if (JUMP_P (q) && !onlyjump_p (q))
+return;
   if (JUMP_P (q)
   && onlyjump_p (q)
   && (any_uncondjump_p (q)
-- 
2.6.4

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

[Andreas Schwab]

Eric Botcazou  writes:

>> I'm also seeing
>> +FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial 17
>> and from what I can see in gcc-testresults, I'm not alone.
>
> Minor oversight, adjusted like so:
>
>   * gnat.dg/specs/debug1.ads: Bump final count to 18.

On powerpc64:

FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial 18

$ grep -c DW_AT_artificial debug1.s
17

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH 1/3] Fix logic bug in Cilk Plus array expansion

[Patrick Palka]

On Sat, Jan 2, 2016 at 3:21 AM, Jakub Jelinek  wrote:
> On Fri, Jan 01, 2016 at 10:06:34PM -0700, Jeff Law wrote:
>> >gcc/cp/ChangeLog:
>> >
>> > * cp-array-notation.c (cp_expand_cond_array_notations): Return
>> > error_mark_node only if find_rank failed, not if it was
>> > successful.
>> Can you use -fdump-tree-original in the testcase and verify there's no <<<
>> error >>> expressions in the resulting dump file?
>>
>> With that change, this is OK.
>
> I think the patch is incomplete.  Because, find_rank does not always emit
> an error if it returns false, so we again have cases where we can get
> error_mark_node in the code without error being emitted.
>   else if (*rank != current_rank)
> {
>   /* In this case, find rank is being recursed through a set of
>  expression of the form A  B, where A and B both have
>  array notations in them and the rank of A is not equal to rank 
> of B.
>  A simple example of such case is the following: X[:] + Y[:][:] */
>   *rank = current_rank;
>   return false;
> }
> and other spots.  E.g.
>   if (prev_arg && EXPR_HAS_LOCATION (prev_arg))
> error_at (EXPR_LOCATION (prev_arg),
>   "rank mismatch between %qE and %qE", prev_arg,
>   TREE_OPERAND (expr, ii));
> looks very suspicious.

Hmm, good point. Here's a contrived test case that causes find_rank to
return false without emitting an error message thus we again end up
with an error_mark_node in the gimplifier:

/* { dg-do compile } */
/* { dg-options "-fcilkplus" } */

void foo() {}

#define ALEN 1024

int main(int argc, char* argv[])
{
  typedef void (*f) (void *);
  f b[ALEN], c[ALEN][ALEN];
  (b[:]) ((void *)c[:][:]);
  _Cilk_spawn foo();
  return 0;
}

But this patch was intended to only fix the testsuite fallout that
patch 3 would have otherwise caused, and not to e.g. fix all the bugs
with find_rank.

(BTW patch 3 also makes this test case trigger an ICE, instead of
being silently miscompiled.)

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

[Eric Botcazou]

> On powerpc64:
> 
> FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial 18
> 
> $ grep -c DW_AT_artificial debug1.s
> 17

Test removed.

-- 
Eric Botcazou

Re: [PATCH] * doc/invoke.texi: fix typos of -finite-math-only

[Sandra Loosemore]

On 01/02/2016 01:37 AM, Vladimír Čunát wrote:

On 01/02/2016 12:13 AM, Sandra Loosemore wrote:

On 01/01/2016 12:31 PM, Vladimír Čunát wrote:

I noticed tiny typos in the docs.
(CC me with replies, please, as I'm not reading the list.)


This patch is fine with an appropriate ChangeLog entry.  Generally,
fixing typos in documentation or comments falls under the "obvious
patch" rule, so it doesn't need explicit approval anyway.


What about using the simple line that's in the subject?

I didn't realize even such tiny changes need a changelog entry.
(I'm used to handling such information by version control instead.)


ChangeLogs are required by the GNU coding standards.

http://www.gnu.org/prep/standards/standards.html#Change-Logs

If you don't want to bother with that, or don't have commit access to 
the repository, I'll check in the patch on your behalf; just let me know 
if you want me to do that.


-Sandra

Re: [PATCH, ARM, 1/3] Document --with-multilib-list for arm*-*-* targets

[Gerald Pfeifer]

On Wed, 16 Dec 2015, Thomas Preud'homme wrote:
> Currently, the documentation for --with-multilib-list in 
> gcc/doc/install.texi only mentions sh*-*-* and x86-64-*-linux* targets. 
> However, arm*-*-* targets also support this option. This patch adds 
> documention for the meaning of this option for arm*-*-* targets.
> 
> 2015-12-09  Thomas Preud'homme  
> 
> * doc/install.texi (--with-multilib-list): Describe the meaning of the
> option for arm*-*-* targets.

Ok (since I don't think I saw a response from the ARM maintainers).

(The list of options for -mfpu= is a bit inconsistent with the other
cases, in that it has -mfpu= only in the first case, but I guess this
is fine if you want to keep it that way.)

Gerald

[PATCH] libiberty: {count,dup,write}argv: constify argv input slightly

[Mike Frysinger]

Would be more useful if we could use "const char * const *", but there's
a long standing bug where gcc warns about incompatible pointers when you
try to pass in "char **".  We can at least constify the array itself as
gcc will not warn in that case.

include/:
2016-01-03  Mike Frysinger  

* libiberty.h (dupargv): Change arg to char * const *.
(writeargv, countargv): Likewise.

libiberty/:
2016-01-03  Mike Frysinger  

* argv.c (dupargv): Change arg to char * const *.  Update comment.
(writeargv, countargv): Likewise.
* functions.texi (dupargv, writeargv, countargv): Likewise.
---
 include/libiberty.h  |  6 +++---
 libiberty/argv.c | 12 ++--
 libiberty/functions.texi |  6 +++---
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/libiberty.h b/include/libiberty.h
index 8e096a0..a9c885f 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -80,7 +80,7 @@ extern void freeargv (char **);
 /* Duplicate an argument vector. Allocates memory using malloc.  Use
freeargv to free the vector.  */
 
-extern char **dupargv (char **) ATTRIBUTE_MALLOC;
+extern char **dupargv (char * const *) ATTRIBUTE_MALLOC;
 
 /* Expand "@file" arguments in argv.  */
 
@@ -88,11 +88,11 @@ extern void expandargv (int *, char ***);
 
 /* Write argv to an @-file, inserting necessary quoting.  */
 
-extern int writeargv (char **, FILE *);
+extern int writeargv (char * const *, FILE *);
 
 /* Return the number of elements in argv.  */
 
-extern int countargv (char**);
+extern int countargv (char * const *);
 
 /* Return the last component of a path name.  Note that we can't use a
prototype here because the parameter is declared inconsistently
diff --git a/libiberty/argv.c b/libiberty/argv.c
index 5c3dd70..994dd35 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -49,7 +49,7 @@ Boston, MA 02110-1301, USA.  */
 
 /*
 
-@deftypefn Extension char** dupargv (char **@var{vector})
+@deftypefn Extension char** dupargv (char * const *@var{vector})
 
 Duplicate an argument vector.  Simply scans through @var{vector},
 duplicating each argument until the terminating @code{NULL} is found.
@@ -62,7 +62,7 @@ argument vector.
 */
 
 char **
-dupargv (char **argv)
+dupargv (char * const *argv)
 {
   int argc;
   char **copy;
@@ -279,7 +279,7 @@ char **buildargv (const char *input)
 
 /*
 
-@deftypefn Extension int writeargv (const char **@var{argv}, FILE *@var{file})
+@deftypefn Extension int writeargv (char * const *@var{argv}, FILE *@var{file})
 
 Write each member of ARGV, handling all necessary quoting, to the file
 named by FILE, separated by whitespace.  Return 0 on success, non-zero
@@ -290,7 +290,7 @@ if an error occurred while writing to FILE.
 */
 
 int
-writeargv (char **argv, FILE *f)
+writeargv (char * const *argv, FILE *f)
 {
   int status = 0;
 
@@ -463,7 +463,7 @@ expandargv (int *argcp, char ***argvp)
 
 /*
 
-@deftypefn Extension int countargv (char **@var{argv})
+@deftypefn Extension int countargv (char * const *@var{argv})
 
 Return the number of elements in @var{argv}.
 Returns zero if @var{argv} is NULL.
@@ -473,7 +473,7 @@ Returns zero if @var{argv} is NULL.
 */
 
 int
-countargv (char **argv)
+countargv (char * const *argv)
 {
   int argc;
 
diff --git a/libiberty/functions.texi b/libiberty/functions.texi
index b5f4e80..24dcc37 100644
--- a/libiberty/functions.texi
+++ b/libiberty/functions.texi
@@ -176,7 +176,7 @@ Concatenate zero or more of strings and return the result 
in freshly
 @end deftypefn
 
 @c argv.c:470
-@deftypefn Extension int countargv (char **@var{argv})
+@deftypefn Extension int countargv (char * const *@var{argv})
 
 Return the number of elements in @var{argv}.
 Returns zero if @var{argv} is NULL.
@@ -213,7 +213,7 @@ make it easy to compose the values of multiple blocks.
 @end deftypefn
 
 @c argv.c:52
-@deftypefn Extension char** dupargv (char **@var{vector})
+@deftypefn Extension char** dupargv (char * const *@var{vector})
 
 Duplicate an argument vector.  Simply scans through @var{vector},
 duplicating each argument until the terminating @code{NULL} is found.
@@ -1915,7 +1915,7 @@ does the return value.  The third argument is unused in 
@libib{}.
 @end deftypefn
 
 @c argv.c:286
-@deftypefn Extension int writeargv (const char **@var{argv}, FILE *@var{file})
+@deftypefn Extension int writeargv (char * const *@var{argv}, FILE *@var{file})
 
 Write each member of ARGV, handling all necessary quoting, to the file
 named by FILE, separated by whitespace.  Return 0 on success, non-zero
-- 
2.6.2

[PATCH] libiberty: dupargv: rewrite to use xstrdup

[Mike Frysinger]

This func is basically open coding the xstrdup function, so gut it
and use it directly.

2016-01-03  Mike Frysinger  

* argv.c (dupargv): Replace strlen/xmalloc/strcpy with xstrdup.
---
 libiberty/argv.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/libiberty/argv.c b/libiberty/argv.c
index f2727e8..5c3dd70 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -76,11 +76,7 @@ dupargv (char **argv)
 
   /* the strings */
   for (argc = 0; argv[argc] != NULL; argc++)
-{
-  int len = strlen (argv[argc]);
-  copy[argc] = (char *) xmalloc (len + 1);
-  strcpy (copy[argc], argv[argc]);
-}
+copy[argc] = xstrdup (argv[argc]);
   copy[argc] = NULL;
   return copy;
 }
-- 
2.6.2

Re: [RFC] [PR 68191] s390: Add -fsplit-stack support.

[Ian Lance Taylor]

On Sat, Jan 2, 2016 at 11:16 AM, Marcin Kościelnicki  wrote:
>
> The differences start in the __morestack calling convention.  Basically,
> since pushing things on stuck is unwieldy and there's only one free
> register (%r0 could be used for static chain, %r2-%r6 contain arguments,
> %r6-%r15 are callee-saved), I stuff the parameters somewhere in .rodata
> or .text section, and pass the address of the parameter block in %r1.
> The parameter block also contains a (position-relative) address that
> __morestack should jump to (x86 just mangles the return address from
> __morestack to compute that).  On zSeries CPUs, the parameter block
> is stuffed somewhere in .rodata, its address loaded to %r1 by larl
> instruction, and __morestack is sibling-called by jg instruction.

Does that work in a multi-threaded program if two different threads
are calling the same function at the same time and both threads need
to split the stack?

Ian

[PATCH] cfns: fix mismatch in gnu_inline attributes

[Mike Frysinger]

Since the 3.0.3 release of gperf (made in May 2007), the generated func
has had the gnu_inline attribute applied to it.  The gcc source however
has not been updated to include that which has lead to a mismatch.

In practice, this hasn't been an issue for two reasons:
(1) Before gcc-5, the default standard was (gnu) C89, and gcc does not
warn or throw an error in this mode.
(2) Starting with gcc-4.8, the compiler driver used to build gcc was
changed to C++, and g++ does not warn or throw an error in this mode.

This error does show up though when using gcc-5 to build gcc-4.7 or
older as then the default is (gnu) C11 and the C compiler driver is
used.  That failure looks like:
In file included from .../gcc-4.7.4/gcc/cp/except.c:990:0:
cfns.gperf: At top level:
cfns.gperf:101:1: error: 'gnu_inline' attribute present on 'libc_name_p'
cfns.gperf:26:14: error: but not here

Whether the compiler should always emit this error regardless of the
active standard or compiler driver is debatable (I think it should be
consistent -- either always do it or never do it).

2015-08-06  Mike Frysinger  

* cfns.gperf [__GNUC__, __GNUC_STDC_INLINE__]: Apply the
__gnu_inline__ attribute.
* cfns.h: Regenerated.
---
 gcc/cp/cfns.gperf | 3 +++
 gcc/cp/cfns.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/gcc/cp/cfns.gperf b/gcc/cp/cfns.gperf
index 68acd3d..953262f 100644
--- a/gcc/cp/cfns.gperf
+++ b/gcc/cp/cfns.gperf
@@ -22,6 +22,9 @@ __inline
 static unsigned int hash (const char *, unsigned int);
 #ifdef __GNUC__
 __inline
+#ifdef __GNUC_STDC_INLINE__
+__attribute__ ((__gnu_inline__))
+#endif
 #endif
 const char * libc_name_p (const char *, unsigned int);
 %}
diff --git a/gcc/cp/cfns.h b/gcc/cp/cfns.h
index 1c6665d..6d00c0e 100644
--- a/gcc/cp/cfns.h
+++ b/gcc/cp/cfns.h
@@ -53,6 +53,9 @@ __inline
 static unsigned int hash (const char *, unsigned int);
 #ifdef __GNUC__
 __inline
+#ifdef __GNUC_STDC_INLINE__
+__attribute__ ((__gnu_inline__))
+#endif
 #endif
 const char * libc_name_p (const char *, unsigned int);
 /* maximum key range = 391, duplicates = 0 */
-- 
2.6.2