[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69507

--- Comment #9 from Martin Sebor  ---
Author: msebor
Date: Mon Jun 20 15:46:09 2016
New Revision: 237606

URL: https://gcc.gnu.org/viewcvs?rev=237606=gcc=rev
Log:
PR c/69507 - bogus warning: ISO C does not allow __alignof__ (expression)

gcc/testsuite/ChangeLog:
* gnu89-const-expr-1.c: Avoid diagnosing __alignof__ as not conforming.
* gnu90-const-expr-1.c: Same.
* gnu99-const-expr-1.c: Same.
* gnu99-static-1.c: Same.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/gnu89-const-expr-1.c
trunk/gcc/testsuite/gcc.dg/gnu90-const-expr-1.c
trunk/gcc/testsuite/gcc.dg/gnu99-const-expr-1.c
trunk/gcc/testsuite/gcc.dg/gnu99-static-1.c

Re: [PING] [PATCH] c/69507 - bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[Martin Sebor]

Since this patch was committed, I am now seeing failures on:
gcc.dg/gnu99-const-expr-1.c
gcc.dg/gnu99-static-1.c

(targets arm, aarch64, I don't think that it should matter?)

Can you have  a look?


Sorry about that.  I missed the test updates in my initial patch.
I've committed them in r237606.

Martin

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571

--- Comment #9 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #8)
> all that's "stopping" optimizations.

Bad choice of words, I meant "all that's needed to stop optimizations from
making choices that would not expose the bug".

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571

--- Comment #8 from Hans-Peter Nilsson  ---
(In reply to David B. Robins from comment #7)
> I have verified that the pr71571.C test case attached does expose the bug on
> trunk and that it passes with the above fix.

Great, thanks for the report and for your time.
I think this will do.

> (Note "-O2 -fno-inline" are
> required to ensure a crash; see earlier comment; in 4.3.1 "-O2" sufficed,
> either because it did not inline these thunks or used different criteria.)

For future reference, above I mentioned putting it in
gcc/testsuite/g++.dg/torture, not ../inherit, and there no "-O2 -fno-inline"
combo would not have been required, as I believe the bug would be exposed in
the -O0 iteration.  Experience says it is brittle to assume "-O2 -fno-inline"
would be all that's "stopping" optimizations.

[Bug c/71594] [7 Regression] ice in maybe_legitimize_operand, at optabs.c:6893

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71594

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-20
 CC||trippels at gcc dot gnu.org
Summary|ice in  |[7 Regression] ice in
   |maybe_legitimize_operand,   |maybe_legitimize_operand,
   |at optabs.c:6893|at optabs.c:6893
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
In the future please show us what -march=native expands to.

markus@x4 tmp % cat bug295.i
unsigned short a;
int b, c;
int *d;
void fn1() {
  *d = 24;
  for (; *d <= 65;) {
unsigned short *e = 
b = (a &= 0 <= 0) < (c ?: (*e %= *d));
for (; *d <= 83;)
  ;
  }
}

markus@x4 tmp % gcc -c -O3 -march=amdfam10 bug295.i
bug295.i: In function ‘fn1’:
bug295.i:12:1: internal compiler error: in maybe_legitimize_operand, at
optabs.c:6893

[Bug c/71594] ice in maybe_legitimize_operand, at optabs.c:6893

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71594

David Binderman  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
svn blame suggest that Richard Sandiford wrote the code which fails.
Adding him into the distribution list.

[Bug c++/71576] [4.9/5/6/7 Regression] ICE on valid C++11 code (with xvalue and bitfield) on x86_64-linux-gnu: in build_target_expr, at cp/tree.c:385

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71576

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug c/71594] New: ice in maybe_legitimize_operand, at optabs.c:6893

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71594

Bug ID: 71594
   Summary: ice in maybe_legitimize_operand, at optabs.c:6893
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 38735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38735=edit
C source code

The attached code, when compiled with flags -c -O3 -march=native on x86_64 by
gcc trunk dated 20160619, does this:

bug295.c: In function ‘func_0’:
bug295.c:9100:1: internal compiler error: in maybe_legitimize_operand, at
optabs.c:6893
 }
 ^
0xb2ab3b maybe_legitimize_operand
../../src/trunk/gcc/optabs.c:6892
0xb3442c maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../src/trunk/gcc/optabs.c:6959
0xb3442c maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../src/trunk/gcc/optabs.c:6977
0xb3442c maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../src/trunk/gcc/optabs.c:7020

[Bug c++/71576] [4.9/5/6/7 Regression] ICE on valid C++11 code (with xvalue and bitfield) on x86_64-linux-gnu: in build_target_expr, at cp/tree.c:385

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71576

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-20
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|ICE on valid C++11 code |[4.9/5/6/7 Regression] ICE
   |(with xvalue and bitfield)  |on valid C++11 code (with
   |on x86_64-linux-gnu: in |xvalue and bitfield) on
   |build_target_expr, at   |x86_64-linux-gnu: in
   |cp/tree.c:385   |build_target_expr, at
   ||cp/tree.c:385
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started most likely with r180944 (r180941 properly rejects it, r180959 already
ICEs).

[Bug fortran/71592] Add some facilities for compile-time check

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71592

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
You can't use such static_assert this way in C++, unless the function is
constexpr, nor in C (always), so guess you are proposing something completely
different (like, if this function/subroutine is inlined and the expression is
after inlining/optimizations constant, then see if it is true or false,
otherwise do nothing.  So more like
if (__builtin_constant_p (r >= 0.0))
  {
if (!(r >= 0.0)) __builtin_warning ("...");
  }
Also, !$ already has a specific meaning in OpenMP, so it would be a bad idea to
abuse it.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 15:52, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote:
>> On 20/06/16 15:42, Segher Boessenkool wrote:
>>> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
 On 20/06/16 14:50, Segher Boessenkool wrote:
> If basic asm is deprecated, that means some time later it will be
> removed, at which time an asm without : can be used as extended asm

 Not exactly: it'd be an asm with no inputs, no outputs, and no
 clobbers i.e. no effects.
>>>
>>> I'm not sure what you mean?  It will be treated exactly the same as
>>> basic asm (it is now, anyway).  And it has an effect, it is volatile
>>> after all, not having any outputs?
>>
>> Well, you didn't say that it was volatile: and unless it really is
>> an asm volatile (not just an asm) an extended asm with no effects
>> is a statement with no effects.
> 
> An extended asm without outputs is always volatile (exactly because
> it would be useless otherwise).

Oh, I see what you mean now.  Yes, point taken.

Andrew.

Re: RFC: pass to warn on questionable uses of alloca().

[Joseph Myers]

On Sat, 18 Jun 2016, Martin Sebor wrote:

> the function regardless of the value of its argument).  At
> the same time, it seems that an even more reliable solution
> than pointing out potentially unsafe calls to the function
> and relying on users to modify their code to use malloc for
> large/unbounded allocations would be to let GCC do it for
> them automatically (i.e., in response to some other option,
> emit a call to malloc instead, and insert a call to free when
> appropriate).

Note that such an option would not be usable for the original motivating 
case of glibc, because in code that's meant to be async-signal-safe, 
alloca and VLAs can be used, but malloc cannot.

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

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[gcc at davidrobins dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571

--- Comment #7 from David B. Robins  ---
I have verified that the pr71571.C test case attached does expose the bug on
trunk and that it passes with the above fix. (Note "-O2 -fno-inline" are
required to ensure a crash; see earlier comment; in 4.3.1 "-O2" sufficed,
either because it did not inline these thunks or used different criteria.)

[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash

[gcc at davidrobins dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571

--- Comment #6 from David B. Robins  ---
Created attachment 38734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38734=edit
Test case (for gcc/testsuite/g++.dg/inherit)

Re: [PATCH] c/71552 - Confusing error for incorrect struct initialization

[Joseph Myers]

On Sat, 18 Jun 2016, Martin Sebor wrote:

> The attached patch slightly changes the order in which initializers
> are checked for type compatibility to issue the same error for static
> initializers of incompatible types as for automatic objects, rather
> than rejecting the former for their lack of constness first.

OK, presuming the patch has passed the usual testing.

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

Re: Deprecating basic asm in a function - What now?

[Segher Boessenkool]

On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote:
> On 20/06/16 15:42, Segher Boessenkool wrote:
> > On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
> >> On 20/06/16 14:50, Segher Boessenkool wrote:
> >>> If basic asm is deprecated, that means some time later it will be
> >>> removed, at which time an asm without : can be used as extended asm
> >>
> >> Not exactly: it'd be an asm with no inputs, no outputs, and no
> >> clobbers i.e. no effects.
> > 
> > I'm not sure what you mean?  It will be treated exactly the same as
> > basic asm (it is now, anyway).  And it has an effect, it is volatile
> > after all, not having any outputs?
> 
> Well, you didn't say that it was volatile: and unless it really is
> an asm volatile (not just an asm) an extended asm with no effects
> is a statement with no effects.

An extended asm without outputs is always volatile (exactly because
it would be useless otherwise).


Segher

[Bug target/52305] [avr] ICE in avr_print_operand: unknown mode (const_double)

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52305

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Georg-Johann Lay  ---
(In reply to Pitchumani from comment #3)
> Not re-producible in gcc-7 trunk. Is it valid anymore?

Did you try on a 32-bit host?

ähhh.. the last remains of need_64bit_hwi have been removed with r210632 and
today we assume that HWI is 64 bits at least, i.e. need_64bit_hwint=yes is
assumed.  Hence the test case should work also on 32-bit hosts without any
itches because target long long is always represented as CONST_INT, not as
CONST_DOUBLE.

Issue closed.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 15:42, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
>> On 20/06/16 14:50, Segher Boessenkool wrote:
>>> If basic asm is deprecated, that means some time later it will be
>>> removed, at which time an asm without : can be used as extended asm
>>
>> Not exactly: it'd be an asm with no inputs, no outputs, and no
>> clobbers i.e. no effects.
> 
> I'm not sure what you mean?  It will be treated exactly the same as
> basic asm (it is now, anyway).  And it has an effect, it is volatile
> after all, not having any outputs?

Well, you didn't say that it was volatile: and unless it really is
an asm volatile (not just an asm) an extended asm with no effects
is a statement with no effects.


Andrew.

[Bug middle-end/71581] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71581

--- Comment #3 from Jakub Jelinek  ---
Created attachment 38733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38733=edit
gcc7-pr71581.patch

Untested fix.

Re: Deprecating basic asm in a function - What now?

[Segher Boessenkool]

On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
> On 20/06/16 14:50, Segher Boessenkool wrote:
> > If basic asm is deprecated, that means some time later it will be
> > removed, at which time an asm without : can be used as extended asm
> 
> Not exactly: it'd be an asm with no inputs, no outputs, and no
> clobbers i.e. no effects.

I'm not sure what you mean?  It will be treated exactly the same as
basic asm (it is now, anyway).  And it has an effect, it is volatile
after all, not having any outputs?


Segher

Re: RFC: 2->2 combine patch

[Segher Boessenkool]

On Mon, Jun 20, 2016 at 02:39:06PM +0100, Kyrill Tkachov wrote:
> >So I tried out the patch below.  It decreases code size on most targets
> >(mostly fixed length insn targets), and increases it a small bit on some
> >variable length insn targets (doing an op twice, instead of doing it once
> >and doing a move).  It looks to be all good there too, but there are so
> >many changes that it is almost impossible to really check.
> >
> >So: can people try this out with their favourite benchmarks, please?
> 
> I hope to give this a run on AArch64 but I'll probably manage to get to it 
> only next week.
> In the meantime I've had a quick look at some SPEC2006 codegen on aarch64.
> Some benchmarks decrease in size, others increase. One recurring theme I 
> spotted is
> shifts being repeatedly combined with arithmetic operations rather than 
> being computed
> once and reusing the result. For example:
> lslx30, x15, 3
> addx4, x5, x30
> addx9, x7, x30
> addx24, x8, x30
> addx10, x0, x30
> addx2, x22, x30
> 
> becoming (modulo regalloc fluctuations):
> addx14, x2, x15, lsl 3
> addx13, x22, x15, lsl 3
> addx21, x4, x15, lsl 3
> addx6, x0, x15, lsl 3
> addx3, x30, x15, lsl 3
> 
> which, while saving one instruction can be harmful overall because the 
> extra shift operation
> in the arithmetic instructions can increase the latency of the instruction. 
> I believe the aarch64
> rtx costs should convey this information. Do you expect RTX costs to gate 
> this behaviour?

Yes, RTX costs are used for *all* of combine's combinations.  So it seems
your add,lsl patterns are the same cost as plain add?  If it were more
expensive, combine would reject this combination.

> Some occurrences that hurt code size look like:
> cmpx8, x11, asr 5
> 
> being transformed into:
> asrx12, x11, 5
> cmpx12, x8, uxtw //zero-extend x8
> with the user of the condition code inverted to match the change in order 
> of operands
> to the comparisons.
> I haven't looked at the RTL dumps yet to figure out why this is happening, 
> it could be a backend
> RTL representation issue.

That could be a target thing yes, hard to tell; it's not clear to me
what combination is made here (if any).


Segher

Re: [PATCH] PR target/71549: Convert V1TImode register to TImode in debug insn

[Ilya Enkovich]

2016-06-20 16:39 GMT+03:00 Uros Bizjak :
> On Mon, Jun 20, 2016 at 1:55 PM, H.J. Lu  wrote:
>> TImode register referenced in debug insn can be converted to V1TImode
>> by scalar to vector optimization.  We need to convert a debug insn if
>> it has a variable in a TImode register.
>>
>> Tested on x86-64.  OK for trunk?
>
> Ilya, does this approach look good to you? Also, does DImode STV
> conversion need similar handling of debug insns?

DImode conversion doesn't change register mode (i.e. never calls
PUT_MODE for registers).  That keeps debug instructions valid.

Overall I don't like the idea of having debug insns in candidates
set and in chains.  Looks like it is possible to have a chain
consisting of a debug insn only which is weird (otherwise I don't
see why we may return false in timode_scalar_chain::convert_insn).

What about other possible register uses?  If debug insns are added
to candidates then NONDEBUG_INSN_P check for uses in
timode_check_non_convertible_regs becomes invalid, right?

If we have (or want) to fix some register uses then it's probably
would be better to visit register uses when we convert its mode
and make required fix-ups.  It seems better to me to not involve
debug insns in analysis phase.

Also I don't think debug insns should be accounted as optimized
instructions because we would get different number of optimized
instructions depending on debug info availability which may be
inconvenient for dump scans (and it is not a real instruction
optimization).

Thanks,
Ilya

>
> Uros.
>
>>
>> H.J.
>> 
>> gcc/
>>
>> PR target/71549
>> * config/i386/i386.c (timode_scalar_to_vector_candidate_p):
>> Return true if debug insn has a variable in TImode register.
>> (timode_remove_non_convertible_regs): Skip debug insn.
>> (scalar_chain::convert_insn): Change return type to bool.
>> (scalar_chain::add_insn): Don't check registers in debug insn.
>> (dimode_scalar_chain::convert_insn): Change return type to bool
>> and always return true.
>> (timode_scalar_chain::convert_insn): Change return type to bool.
>> Convert V1TImode register to SUBREG TImode in debug insn.  Return
>> false if debug insn isn't converted.  Otherwise, return true.
>> (scalar_chain::convert): Increment converted_insns only if
>> convert_insn returns true.
>>
>> gcc/testsuite/
>>
>> PR target/71549
>> * gcc.target/i386/pr71549.c: New test.
>> ---
>>  gcc/config/i386/i386.c  | 58 
>> -
>>  gcc/testsuite/gcc.target/i386/pr71549.c | 24 ++
>>  2 files changed, 74 insertions(+), 8 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.target/i386/pr71549.c
>>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index 56a5b9c..e17fc53 100644
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -2845,6 +2845,16 @@ dimode_scalar_to_vector_candidate_p (rtx_insn *insn)
>>  static bool
>>  timode_scalar_to_vector_candidate_p (rtx_insn *insn)
>>  {
>> +  if (DEBUG_INSN_P (insn))
>> +{
>> +  /* If a variable is put in a TImode register, which may be
>> +converted to V1TImode, we need to convert this debug insn.  */
>> +  rtx val = PATTERN (insn);
>> +  return (GET_MODE (val) == TImode
>> + && GET_CODE (val) == VAR_LOCATION
>> + && REG_P (PAT_VAR_LOCATION_LOC (val)));
>> +}
>> +
>>rtx def_set = single_set (insn);
>>
>>if (!def_set)
>> @@ -3012,7 +3022,12 @@ timode_remove_non_convertible_regs (bitmap candidates)
>>
>>EXECUTE_IF_SET_IN_BITMAP (candidates, 0, id, bi)
>>  {
>> -  rtx def_set = single_set (DF_INSN_UID_GET (id)->insn);
>> +  rtx_insn *insn = DF_INSN_UID_GET (id)->insn;
>> +  /* Debug insn isn't a SET insn.  */
>> +  if (DEBUG_INSN_P (insn))
>> +   continue;
>> +
>> +  rtx def_set = single_set (insn);
>>rtx dest = SET_DEST (def_set);
>>rtx src = SET_SRC (def_set);
>>
>> @@ -3111,7 +3126,7 @@ class scalar_chain
>>void add_insn (bitmap candidates, unsigned insn_uid);
>>void analyze_register_chain (bitmap candidates, df_ref ref);
>>virtual void mark_dual_mode_def (df_ref def) = 0;
>> -  virtual void convert_insn (rtx_insn *insn) = 0;
>> +  virtual bool convert_insn (rtx_insn *insn) = 0;
>>virtual void convert_registers () = 0;
>>  };
>>
>> @@ -3123,7 +3138,7 @@ class dimode_scalar_chain : public scalar_chain
>>void mark_dual_mode_def (df_ref def);
>>rtx replace_with_subreg (rtx x, rtx reg, rtx subreg);
>>void replace_with_subreg_in_insn (rtx_insn *insn, rtx reg, rtx subreg);
>> -  void convert_insn (rtx_insn *insn);
>> +  bool convert_insn (rtx_insn *insn);
>>void convert_op (rtx *op, rtx_insn *insn);
>>void convert_reg (unsigned regno);
>>void make_vector_copies (unsigned regno);
>> @@ -3139,7 +3154,7 @@ class timode_scalar_chain : 

[Bug fortran/71580] Internal compiler error associated with type bound defined assignment

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71580

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-20
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr70864?

Re: [PATCH]Fix scan-tree-dump-times syntax errors in gcc.dg/tree-ssa/attr-hotcold-2.c

[Jakub Jelinek]

On Mon, Jun 20, 2016 at 03:07:20PM +0100, Renlin Li wrote:
> Okay to commit?
> 
> Regards,
> Renlin
> 
> gcc/testsuite/ChangeLog:
> 
> 2016-06-20  Renlin Li  
> 
>   * gcc.dg/tree-ssa/attr-hotcold-2.c: Fix syntax errors.

This is obvious.  Please check it in.  Though, it also shows that
it couldn't have been properly tested.

> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c
> index 6623d9e..e2e8143 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c
> @@ -18,8 +18,8 @@ void f(int x, int y)
>return;
>  }
>  
> -/* { dg-final { scan-tree-dump-times 1 "hot label heuristics" 1 
> "profile_estimate" } } */
> -/* { dg-final { scan-tree-dump-times 1 "cold label heuristics" 1 
> "profile_estimate" } } */
> +/* { dg-final { scan-tree-dump-times "hot label heuristics" 1 
> "profile_estimate" } } */
> +/* { dg-final { scan-tree-dump-times "cold label heuristics" 1 
> "profile_estimate" } } */
>  /* { dg-final { scan-tree-dump-times "block 4, loop depth 0, count 0, freq 
> \[1-4\]\[^0-9\]" 1 "profile_estimate" } } */
>  
>  /* Note: we're attempting to match some number > 6000, i.e. > 60%.


Jakub

[Bug c++/71593] New: initializing array with mixed constant and variable size results in error

[editing101 at aol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71593

Bug ID: 71593
   Summary: initializing array with mixed constant and variable
size results in error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: editing101 at aol dot com
  Target Milestone: ---

int length=5;
float test[5][len]={};
gives internal compiler error: in make_decl_rtl, at varasm.c:1313

[PATCH]Fix scan-tree-dump-times syntax errors in gcc.dg/tree-ssa/attr-hotcold-2.c

[Renlin Li]

Hi,

This is a simple patch to fix the syntax errors in dg-final directive 
lines within this test case.


According to the documentation, the syntax of this directive should be:
'''scan-tree-dump-times regex num suffix [{ target/xfail selector }]'''


Now the test case compilers Okay in arm environment. However, the last 
two checks seem failing. This is another issue.


Okay to commit?

Regards,
Renlin

gcc/testsuite/ChangeLog:

2016-06-20  Renlin Li  

* gcc.dg/tree-ssa/attr-hotcold-2.c: Fix syntax errors.

On 13/06/16 17:35, Kyrill Tkachov wrote:

Hi Honza,

On 07/06/16 20:27, Jan Hubicka wrote:

Hello,
Maritn Liska measured branch predictor hitrates on current tree and




In the testsuite I'm seeing:
ERROR: gcc.dg/tree-ssa/attr-hotcold-2.c: error executing dg-final:
syntax error in target selector "profile_estimate"

on aarch64-none-elf.
I think the hunk:
-/* { dg-final { scan-ipa-dump-times "block 4, loop depth 0, count 0,
freq 1\[^0-9\]" 1 "profile_estimate" } } */
+/* { dg-final { scan-tree-dump-times 1 "hot label heuristics" 1
"profile_estimate" } } */
+/* { dg-final { scan-tree-dump-times 1 "cold label heuristics" 1
"profile_estimate" } } */
+/* { dg-final { scan-tree-dump-times "block 4, loop depth 0, count 0,
freq \[1-4\]\[^0-9\]" 1 "profile_estimate" } } */

is buggy, should it be
-/* { dg-final { scan-ipa-dump-times "block 4, loop depth 0, count 0,
freq 1\[^0-9\]" 1 "profile_estimate" } } */
+/* { dg-final { scan-tree-dump-times "hot label heuristics" 1
"profile_estimate" } } */
+/* { dg-final { scan-tree-dump-times "cold label heuristics" 1
"profile_estimate" } } */
+/* { dg-final { scan-tree-dump-times "block 4, loop depth 0, count 0,
freq \[1-4\]\[^0-9\]" 1 "profile_estimate" } } */
?

With that change the test runs but still FAILs:
FAIL: gcc.dg/tree-ssa/attr-hotcold-2.c scan-tree-dump-times
profile_estimate "block 4, loop depth 0, count 0, freq [1-4][^0-9]" 1
FAIL: gcc.dg/tree-ssa/attr-hotcold-2.c scan-tree-dump-times
profile_estimate "block 5, loop depth 0, count 0, freq
[6-9][0-9][0-9][0-9]" 1

Thanks,
Kyrill
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c b/gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c
index 6623d9e..e2e8143 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/attr-hotcold-2.c
@@ -18,8 +18,8 @@ void f(int x, int y)
   return;
 }
 
-/* { dg-final { scan-tree-dump-times 1 "hot label heuristics" 1 "profile_estimate" } } */
-/* { dg-final { scan-tree-dump-times 1 "cold label heuristics" 1 "profile_estimate" } } */
+/* { dg-final { scan-tree-dump-times "hot label heuristics" 1 "profile_estimate" } } */
+/* { dg-final { scan-tree-dump-times "cold label heuristics" 1 "profile_estimate" } } */
 /* { dg-final { scan-tree-dump-times "block 4, loop depth 0, count 0, freq \[1-4\]\[^0-9\]" 1 "profile_estimate" } } */
 
 /* Note: we're attempting to match some number > 6000, i.e. > 60%.

Re: [AArch64] Give some new costs for Cortex-A53 floating-point operations

[Richard Earnshaw (lists)]

On 20/06/16 14:57, James Greenhalgh wrote:
> 
> Hi,
> 
> As recently done for Cortex-A57 [1], this patch rebases the floating-point
> cost table for Cortex-A53 to be relative to the cost of a floating-point move.
> I wrote a little more on the justification for doing this in the other patch,
> but in summary this is what other targets and sub-targets do, so we should
> fall in line with that.
> 
> Unlike the Cortex-A57 changes, this had no performance impact across
> Spec2000 and Spec2006. I'm posting it to keep the strategy for costs
> aligned between the two cores.
> 
> Bootstrapped on aarch64-none-linux-gnu and arm-none-linux-gnueabihf with
> no issues.
> 
> OK?
> 
> Thanks,
> James
> 
> [1]: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00251.html
> 
> ---
> 2016-06-20  James Greenhalgh  
> 
>   * config/arm/aarch-cost-tables.h (cortexa53_extra_costs): Make FP
>   costs relative to the cost of a register move.
> 

OK.

R.

> 
> 0001-AArch64-Give-some-new-costs-for-Cortex-A53-floating-.patch
> 
> 
> diff --git a/gcc/config/arm/aarch-cost-tables.h 
> b/gcc/config/arm/aarch-cost-tables.h
> index 5f42253..8bcfcb4 100644
> --- a/gcc/config/arm/aarch-cost-tables.h
> +++ b/gcc/config/arm/aarch-cost-tables.h
> @@ -191,35 +191,35 @@ const struct cpu_cost_table cortexa53_extra_costs =
>{
>  /* FP SFmode */
>  {
> -  COSTS_N_INSNS (15),/* div.  */
> -  COSTS_N_INSNS (3), /* mult.  */
> -  COSTS_N_INSNS (7), /* mult_addsub. */
> -  COSTS_N_INSNS (7), /* fma.  */
> -  COSTS_N_INSNS (3), /* addsub.  */
> -  COSTS_N_INSNS (1), /* fpconst. */
> -  COSTS_N_INSNS (2), /* neg.  */
> -  COSTS_N_INSNS (1), /* compare.  */
> -  COSTS_N_INSNS (3), /* widen.  */
> -  COSTS_N_INSNS (3), /* narrow.  */
> -  COSTS_N_INSNS (3), /* toint.  */
> -  COSTS_N_INSNS (3), /* fromint.  */
> -  COSTS_N_INSNS (3)  /* roundint.  */
> +  COSTS_N_INSNS (5), /* div.  */
> +  COSTS_N_INSNS (1), /* mult.  */
> +  COSTS_N_INSNS (2), /* mult_addsub.  */
> +  COSTS_N_INSNS (2), /* fma.  */
> +  COSTS_N_INSNS (1), /* addsub.  */
> +  0, /* fpconst.  */
> +  COSTS_N_INSNS (1), /* neg.  */
> +  0, /* compare.  */
> +  COSTS_N_INSNS (1), /* widen.  */
> +  COSTS_N_INSNS (1), /* narrow.  */
> +  COSTS_N_INSNS (1), /* toint.  */
> +  COSTS_N_INSNS (1), /* fromint.  */
> +  COSTS_N_INSNS (1)  /* roundint.  */
>  },
>  /* FP DFmode */
>  {
> -  COSTS_N_INSNS (30),/* div.  */
> -  COSTS_N_INSNS (3), /* mult.  */
> -  COSTS_N_INSNS (7), /* mult_addsub.  */
> -  COSTS_N_INSNS (7), /* fma.  */
> -  COSTS_N_INSNS (3), /* addsub.  */
> -  COSTS_N_INSNS (1), /* fpconst.  */
> -  COSTS_N_INSNS (2), /* neg.  */
> -  COSTS_N_INSNS (1), /* compare.  */
> -  COSTS_N_INSNS (3), /* widen.  */
> -  COSTS_N_INSNS (3), /* narrow.  */
> -  COSTS_N_INSNS (3), /* toint.  */
> -  COSTS_N_INSNS (3), /* fromint.  */
> -  COSTS_N_INSNS (3)  /* roundint.  */
> +  COSTS_N_INSNS (10),/* div.  */
> +  COSTS_N_INSNS (1), /* mult.  */
> +  COSTS_N_INSNS (2), /* mult_addsub.  */
> +  COSTS_N_INSNS (2), /* fma.  */
> +  COSTS_N_INSNS (1), /* addsub.  */
> +  0, /* fpconst.  */
> +  COSTS_N_INSNS (1), /* neg.  */
> +  0, /* compare.  */
> +  COSTS_N_INSNS (1), /* widen.  */
> +  COSTS_N_INSNS (1), /* narrow.  */
> +  COSTS_N_INSNS (1), /* toint.  */
> +  COSTS_N_INSNS (1), /* fromint.  */
> +  COSTS_N_INSNS (1)  /* roundint.  */
>  }
>},
>/* Vector */
> 

[AArch64] Give some new costs for Cortex-A53 floating-point operations

[James Greenhalgh]

Hi,

As recently done for Cortex-A57 [1], this patch rebases the floating-point
cost table for Cortex-A53 to be relative to the cost of a floating-point move.
I wrote a little more on the justification for doing this in the other patch,
but in summary this is what other targets and sub-targets do, so we should
fall in line with that.

Unlike the Cortex-A57 changes, this had no performance impact across
Spec2000 and Spec2006. I'm posting it to keep the strategy for costs
aligned between the two cores.

Bootstrapped on aarch64-none-linux-gnu and arm-none-linux-gnueabihf with
no issues.

OK?

Thanks,
James

[1]: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00251.html

---
2016-06-20  James Greenhalgh  

* config/arm/aarch-cost-tables.h (cortexa53_extra_costs): Make FP
costs relative to the cost of a register move.
diff --git a/gcc/config/arm/aarch-cost-tables.h b/gcc/config/arm/aarch-cost-tables.h
index 5f42253..8bcfcb4 100644
--- a/gcc/config/arm/aarch-cost-tables.h
+++ b/gcc/config/arm/aarch-cost-tables.h
@@ -191,35 +191,35 @@ const struct cpu_cost_table cortexa53_extra_costs =
   {
 /* FP SFmode */
 {
-  COSTS_N_INSNS (15),	/* div.  */
-  COSTS_N_INSNS (3),	/* mult.  */
-  COSTS_N_INSNS (7),	/* mult_addsub. */
-  COSTS_N_INSNS (7),	/* fma.  */
-  COSTS_N_INSNS (3),	/* addsub.  */
-  COSTS_N_INSNS (1),	/* fpconst. */
-  COSTS_N_INSNS (2),	/* neg.  */
-  COSTS_N_INSNS (1),	/* compare.  */
-  COSTS_N_INSNS (3),	/* widen.  */
-  COSTS_N_INSNS (3),	/* narrow.  */
-  COSTS_N_INSNS (3),	/* toint.  */
-  COSTS_N_INSNS (3),	/* fromint.  */
-  COSTS_N_INSNS (3)		/* roundint.  */
+  COSTS_N_INSNS (5),	/* div.  */
+  COSTS_N_INSNS (1),	/* mult.  */
+  COSTS_N_INSNS (2),	/* mult_addsub.  */
+  COSTS_N_INSNS (2),	/* fma.  */
+  COSTS_N_INSNS (1),	/* addsub.  */
+  0,			/* fpconst.  */
+  COSTS_N_INSNS (1),	/* neg.  */
+  0,			/* compare.  */
+  COSTS_N_INSNS (1),	/* widen.  */
+  COSTS_N_INSNS (1),	/* narrow.  */
+  COSTS_N_INSNS (1),	/* toint.  */
+  COSTS_N_INSNS (1),	/* fromint.  */
+  COSTS_N_INSNS (1)		/* roundint.  */
 },
 /* FP DFmode */
 {
-  COSTS_N_INSNS (30),	/* div.  */
-  COSTS_N_INSNS (3),	/* mult.  */
-  COSTS_N_INSNS (7),	/* mult_addsub.  */
-  COSTS_N_INSNS (7),	/* fma.  */
-  COSTS_N_INSNS (3),	/* addsub.  */
-  COSTS_N_INSNS (1),	/* fpconst.  */
-  COSTS_N_INSNS (2),	/* neg.  */
-  COSTS_N_INSNS (1),	/* compare.  */
-  COSTS_N_INSNS (3),	/* widen.  */
-  COSTS_N_INSNS (3),	/* narrow.  */
-  COSTS_N_INSNS (3),	/* toint.  */
-  COSTS_N_INSNS (3),	/* fromint.  */
-  COSTS_N_INSNS (3)		/* roundint.  */
+  COSTS_N_INSNS (10),	/* div.  */
+  COSTS_N_INSNS (1),	/* mult.  */
+  COSTS_N_INSNS (2),	/* mult_addsub.  */
+  COSTS_N_INSNS (2),	/* fma.  */
+  COSTS_N_INSNS (1),	/* addsub.  */
+  0,			/* fpconst.  */
+  COSTS_N_INSNS (1),	/* neg.  */
+  0,			/* compare.  */
+  COSTS_N_INSNS (1),	/* widen.  */
+  COSTS_N_INSNS (1),	/* narrow.  */
+  COSTS_N_INSNS (1),	/* toint.  */
+  COSTS_N_INSNS (1),	/* fromint.  */
+  COSTS_N_INSNS (1)		/* roundint.  */
 }
   },
   /* Vector */

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 14:50, Segher Boessenkool wrote:
> If basic asm is deprecated, that means some time later it will be
> removed, at which time an asm without : can be used as extended asm

Not exactly: it'd be an asm with no inputs, no outputs, and no
clobbers i.e. no effects.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Segher Boessenkool]

On Mon, Jun 20, 2016 at 12:00:16AM -0700, Andrew Pinski wrote:
> Also I think the other place where we should accept basic asm is for
> "nop" instructions.  I have seen people use that heavily.

And anything else that means the same as basic asm and as extended asm.

> Note really I don't like the idea of deprecating basic asm at all.

If basic asm is deprecated, that means some time later it will be
removed, at which time an asm without : can be used as extended asm
(or we can force everyone to write asm("nop":); if we are silly).

Warning about asm without : now is just unnecessary churn (and not just
for us, also for all the users of inline asm).


Segher

[Bug fortran/71592] New: Add some facilities for compile-time check

[heresy-me at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71592

Bug ID: 71592
   Summary: Add some facilities for compile-time check
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: heresy-me at hotmail dot com
  Target Milestone: ---

There are many occasion that to do some compile-time check if we need. For
example, I write my own sqrt function that it may check its parameter should
greater than or equal to zero at compile-time when it is compile-time
evaluated. such as:

function mysqrt(r)
  real :: mysqrt
  $!assert static(r >= 0.0, "radicand is negative.")
  real, intent(in) :: r
end function

just normally likes the compiler behavior.
it also may specify like "!$assert dynamic", "!$assert static_dynamic"
So I need not to fix the obivous compile-time until the program debug. Just
because I know that the C/C++ compiler has been added a standard static_assert
or _Static_assert keyword to finish this work, the Ada language also can
specify the function precondition, then why fortran can't?
C/C++:
float mysqrt(float r) {
static_assert(r >= 0.0, "radicand is negative.");
/* ... */
}
Ada:
function mysqrt(r : Float) return Float
  with Precondition => (r >= 0.0);

[Bug c++/59861] Inconsistent error output format

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59861

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
Please, provide a self-contained testcase. From the output that you quoted, it
is not clear why the note is printed at all.

[Bug c/70477] -Wtautological-compare too aggressive?

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to ecloud from comment #5)
> If a macro exists in order to test something and generate different code
> depending on the test result, then in any given use case of the macro, we
> can say that the test inside the macro is a tautology, right?  But that
> shouldn't mean that doing tests inside macros is bad.

We want to avoid warning for macros in general because of that, and we already
avoid some cases. However, GCC can only detect that something comes from a
macro if it expands to something for which GCC tracks locations. GCC currently
does not track locations for constants (0), variable-uses (x) and some simple
expressions that may get folded too early. So if you have !!0 or 0 != 1, GCC
right now cannot tell whether this is the result of macro expansion (at the
point of warning).

It is not likely that the bug will get fixed in the near term, so if you think
that you may still want this warning in general, a work-around is to disable
this warning for the relevant line using #pragma GCC diagnostic.

Re: [PING 2, PATCH] Remove xfail from thread_local-order2.C.

[Dominik Vogt]

Patch:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01587.html

On Wed, Jan 27, 2016 at 10:39:44AM +0100, Dominik Vogt wrote:
> g++.dg/tls/thread_local-order2.C no longer fail with Glibc-2.18 or
> newer since this commit:
> 
>   2014-08-01  Zifei Tong  
> 
>   * libsupc++/atexit_thread.cc (HAVE___CXA_THREAD_ATEXIT_IMPL): Add
>   _GLIBCXX_ prefix to macro.
> 
>   git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@213504 138bc75d-0d04-0410-96
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02091.html
> 
> So, is it time to remove the xfail from the test case?
> 
> Ciao
> 
> Dominik ^_^  ^_^
> 
> -- 
> 
> Dominik Vogt
> IBM Germany

> gcc/testsuite/ChangeLog
> 
>   * g++.dg/tls/thread_local-order2.C: Remove xfail.

> >From 0b0abbd2e6d9d8b6857622065bdcbdde31b5ddb0 Mon Sep 17 00:00:00 2001
> From: Dominik Vogt 
> Date: Wed, 27 Jan 2016 09:54:07 +0100
> Subject: [PATCH] Remove xfail from thread_local-order2.C.
> 
> This should work with Glibc-2.18 or newer.
> ---
>  gcc/testsuite/g++.dg/tls/thread_local-order2.C | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/gcc/testsuite/g++.dg/tls/thread_local-order2.C 
> b/gcc/testsuite/g++.dg/tls/thread_local-order2.C
> index f8df917..d3351e6 100644
> --- a/gcc/testsuite/g++.dg/tls/thread_local-order2.C
> +++ b/gcc/testsuite/g++.dg/tls/thread_local-order2.C
> @@ -2,7 +2,6 @@
>  // that isn't reverse order of construction.  We need to move
>  // __cxa_thread_atexit into glibc to get this right.
>  
> -// { dg-do run { xfail *-*-* } }
>  // { dg-require-effective-target c++11 }
>  // { dg-add-options tls }
>  // { dg-require-effective-target tls_runtime }
> -- 
> 2.3.0

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH] PR target/71549: Convert V1TImode register to TImode in debug insn

[Uros Bizjak]

On Mon, Jun 20, 2016 at 1:55 PM, H.J. Lu  wrote:
> TImode register referenced in debug insn can be converted to V1TImode
> by scalar to vector optimization.  We need to convert a debug insn if
> it has a variable in a TImode register.
>
> Tested on x86-64.  OK for trunk?

Ilya, does this approach look good to you? Also, does DImode STV
conversion need similar handling of debug insns?

Uros.

>
> H.J.
> 
> gcc/
>
> PR target/71549
> * config/i386/i386.c (timode_scalar_to_vector_candidate_p):
> Return true if debug insn has a variable in TImode register.
> (timode_remove_non_convertible_regs): Skip debug insn.
> (scalar_chain::convert_insn): Change return type to bool.
> (scalar_chain::add_insn): Don't check registers in debug insn.
> (dimode_scalar_chain::convert_insn): Change return type to bool
> and always return true.
> (timode_scalar_chain::convert_insn): Change return type to bool.
> Convert V1TImode register to SUBREG TImode in debug insn.  Return
> false if debug insn isn't converted.  Otherwise, return true.
> (scalar_chain::convert): Increment converted_insns only if
> convert_insn returns true.
>
> gcc/testsuite/
>
> PR target/71549
> * gcc.target/i386/pr71549.c: New test.
> ---
>  gcc/config/i386/i386.c  | 58 
> -
>  gcc/testsuite/gcc.target/i386/pr71549.c | 24 ++
>  2 files changed, 74 insertions(+), 8 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr71549.c
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 56a5b9c..e17fc53 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2845,6 +2845,16 @@ dimode_scalar_to_vector_candidate_p (rtx_insn *insn)
>  static bool
>  timode_scalar_to_vector_candidate_p (rtx_insn *insn)
>  {
> +  if (DEBUG_INSN_P (insn))
> +{
> +  /* If a variable is put in a TImode register, which may be
> +converted to V1TImode, we need to convert this debug insn.  */
> +  rtx val = PATTERN (insn);
> +  return (GET_MODE (val) == TImode
> + && GET_CODE (val) == VAR_LOCATION
> + && REG_P (PAT_VAR_LOCATION_LOC (val)));
> +}
> +
>rtx def_set = single_set (insn);
>
>if (!def_set)
> @@ -3012,7 +3022,12 @@ timode_remove_non_convertible_regs (bitmap candidates)
>
>EXECUTE_IF_SET_IN_BITMAP (candidates, 0, id, bi)
>  {
> -  rtx def_set = single_set (DF_INSN_UID_GET (id)->insn);
> +  rtx_insn *insn = DF_INSN_UID_GET (id)->insn;
> +  /* Debug insn isn't a SET insn.  */
> +  if (DEBUG_INSN_P (insn))
> +   continue;
> +
> +  rtx def_set = single_set (insn);
>rtx dest = SET_DEST (def_set);
>rtx src = SET_SRC (def_set);
>
> @@ -3111,7 +3126,7 @@ class scalar_chain
>void add_insn (bitmap candidates, unsigned insn_uid);
>void analyze_register_chain (bitmap candidates, df_ref ref);
>virtual void mark_dual_mode_def (df_ref def) = 0;
> -  virtual void convert_insn (rtx_insn *insn) = 0;
> +  virtual bool convert_insn (rtx_insn *insn) = 0;
>virtual void convert_registers () = 0;
>  };
>
> @@ -3123,7 +3138,7 @@ class dimode_scalar_chain : public scalar_chain
>void mark_dual_mode_def (df_ref def);
>rtx replace_with_subreg (rtx x, rtx reg, rtx subreg);
>void replace_with_subreg_in_insn (rtx_insn *insn, rtx reg, rtx subreg);
> -  void convert_insn (rtx_insn *insn);
> +  bool convert_insn (rtx_insn *insn);
>void convert_op (rtx *op, rtx_insn *insn);
>void convert_reg (unsigned regno);
>void make_vector_copies (unsigned regno);
> @@ -3139,7 +3154,7 @@ class timode_scalar_chain : public scalar_chain
>
>   private:
>void mark_dual_mode_def (df_ref def);
> -  void convert_insn (rtx_insn *insn);
> +  bool convert_insn (rtx_insn *insn);
>/* We don't convert registers to difference size.  */
>void convert_registers () {}
>  };
> @@ -3276,6 +3291,10 @@ scalar_chain::add_insn (bitmap candidates, unsigned 
> int insn_uid)
>bitmap_set_bit (insns, insn_uid);
>
>rtx_insn *insn = DF_INSN_UID_GET (insn_uid)->insn;
> +  /* Debug insn isn't a SET insn.  */
> +  if (DEBUG_INSN_P (insn))
> +return;
> +
>rtx def_set = single_set (insn);
>if (def_set && REG_P (SET_DEST (def_set))
>&& !HARD_REGISTER_P (SET_DEST (def_set)))
> @@ -3708,7 +3727,7 @@ dimode_scalar_chain::convert_op (rtx *op, rtx_insn 
> *insn)
>
>  /* Convert INSN to vector mode.  */
>
> -void
> +bool
>  dimode_scalar_chain::convert_insn (rtx_insn *insn)
>  {
>rtx def_set = single_set (insn);
> @@ -3788,13 +3807,34 @@ dimode_scalar_chain::convert_insn (rtx_insn *insn)
>INSN_CODE (insn) = -1;
>recog_memoized (insn);
>df_insn_rescan (insn);
> +
> +  return true;
>  }
>
>  /* Convert INSN from TImode to V1T1mode.  */
>
> -void
> +bool
>  timode_scalar_chain::convert_insn (rtx_insn *insn)
>  {
> +  if 

Re: RFC: 2->2 combine patch

[Kyrill Tkachov]

Hi Segher,

On 17/06/16 01:07, Segher Boessenkool wrote:

On Fri, Jun 10, 2016 at 11:20:22AM +0200, Richard Biener wrote:

With the proposed cost change for vector construction we will end up
vectorizing the testcase in PR68961 again (on x86_64 and likely
on ppc64le as well after that target gets adjustments).  Currently
we can't optimize that away again noticing the direct overlap of
argument and return registers.  The obstackle is

(insn 7 4 8 2 (set (reg:V2DF 93)
 (vec_concat:V2DF (reg/v:DF 91 [ a ])
 (reg/v:DF 92 [ aa ])))
...
(insn 21 8 24 2 (set (reg:DI 97 [ D.1756 ])
 (subreg:DI (reg:TI 88 [ D.1756 ]) 0))
(insn 24 21 11 2 (set (reg:DI 100 [+8 ])
 (subreg:DI (reg:TI 88 [ D.1756 ]) 8))

which we eventually optimize to DFmode subregs of (reg:V2DF 93).

First of all simplify_subreg doesn't handle the subregs of a vec_concat
(easy fix below).

Then combine doesn't like to simplify the multi-use (it tries some
parallel it seems).

Combine will not do a 2->2 combination currently.  Say it is combining
A with a later B into C, and the result of A is used again later, then
it tries a parallel of A with C.  That usually does not match an insn for
the target.

If this were a 3->2 (or 4->2) combination, or A or C are no-op moves
(so that they will disappear later in combines), combine will break the
parallel into two and see if that matches.  We can in fact do that for
2->2 combinations as well: this removes a log_link (from A to B), so
combine cannot get into an infinite loop, even though it does not make
the number of RTL insns lower.

So I tried out the patch below.  It decreases code size on most targets
(mostly fixed length insn targets), and increases it a small bit on some
variable length insn targets (doing an op twice, instead of doing it once
and doing a move).  It looks to be all good there too, but there are so
many changes that it is almost impossible to really check.

So: can people try this out with their favourite benchmarks, please?


I hope to give this a run on AArch64 but I'll probably manage to get to it only 
next week.
In the meantime I've had a quick look at some SPEC2006 codegen on aarch64.
Some benchmarks decrease in size, others increase. One recurring theme I 
spotted is
shifts being repeatedly combined with arithmetic operations rather than being 
computed
once and reusing the result. For example:
lslx30, x15, 3
addx4, x5, x30
addx9, x7, x30
addx24, x8, x30
addx10, x0, x30
addx2, x22, x30

becoming (modulo regalloc fluctuations):
addx14, x2, x15, lsl 3
addx13, x22, x15, lsl 3
addx21, x4, x15, lsl 3
addx6, x0, x15, lsl 3
addx3, x30, x15, lsl 3

which, while saving one instruction can be harmful overall because the extra 
shift operation
in the arithmetic instructions can increase the latency of the instruction. I 
believe the aarch64
rtx costs should convey this information. Do you expect RTX costs to gate this 
behaviour?

Some occurrences that hurt code size look like:
cmpx8, x11, asr 5

being transformed into:
asrx12, x11, 5
cmpx12, x8, uxtw //zero-extend x8
with the user of the condition code inverted to match the change in order of 
operands
to the comparisons.
I haven't looked at the RTL dumps yet to figure out why this is happening, it 
could be a backend
RTL representation issue.

Kyrill




Segher


diff --git a/gcc/combine.c b/gcc/combine.c
index 6b5d000..2c99b4e 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -3933,8 +3933,6 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, 
rtx_insn *i0,
   && XVECLEN (newpat, 0) == 2
   && GET_CODE (XVECEXP (newpat, 0, 0)) == SET
   && GET_CODE (XVECEXP (newpat, 0, 1)) == SET
-  && (i1 || set_noop_p (XVECEXP (newpat, 0, 0))
- || set_noop_p (XVECEXP (newpat, 0, 1)))
   && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != ZERO_EXTRACT
   && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 0))) != STRICT_LOW_PART
   && GET_CODE (SET_DEST (XVECEXP (newpat, 0, 1))) != ZERO_EXTRACT

[patch, avr] Fix PR30417: Wrap -Tdata into %{!Tdata:...}.

[Georg-Johann Lay]

This patch allows to specify -Tdata and -Ttext on the command line for MCUs 
where the specs file sets these options.  For -mmcu=atmega88 for example, the 
respective specs reads:


*link_data_start:
-Tdata 0x800100

and the patch changes this to

*link_data_start:
%{!Tdata:-Tdata 0x800100}

Same for *link_text_start and -Ttext.

Ok for trunk and backport?

Johann


PR target/30417
* config/avr/gen-avr-mmcu-specs.c (print_mcu):
[*link_data_start]: Wrap -Tdata into %{!Tdata:...}.
[*link_text_start]: Wrap -Ttext into %{!Ttext:...}.

Index: config/avr/gen-avr-mmcu-specs.c
===
--- config/avr/gen-avr-mmcu-specs.c	(revision 237587)
+++ config/avr/gen-avr-mmcu-specs.c	(working copy)
@@ -242,12 +242,13 @@ bool is_arch = NULL == mcu->macro;
   fprintf (f, "*link_data_start:\n");
   if (mcu->data_section_start
   != arch->default_data_section_start)
-fprintf (f, "\t-Tdata 0x%lX", 0x80UL + mcu->data_section_start);
+fprintf (f, "\t%%{!Tdata:-Tdata 0x%lX}",
+ 0x80UL + mcu->data_section_start);
   fprintf (f, "\n\n");
 
   fprintf (f, "*link_text_start:\n");
   if (mcu->text_section_start != 0x0)
-fprintf (f, "\t-Ttext 0x%lX", 0UL + mcu->text_section_start);
+fprintf (f, "\t%%{!Ttext:-Ttext 0x%lX}", 0UL + mcu->text_section_start);
   fprintf (f, "\n\n");
 }
 

Re: [Patch AArch64] Add some more missing intrinsics

[Richard Earnshaw (lists)]

On 13/06/16 17:31, James Greenhalgh wrote:
> 
> Hi,
> 
> Inspired by Jiong's recent work, here are some more missing intrinsics,
> and a smoke test for each of them.
> 
> This patch covers:
> 
>   vcvt_n_f64_s64
>   vcvt_n_f64_u64
>   vcvt_n_s64_f64
>   vcvt_n_u64_f64
>   vcvt_f64_s64
>   vrecpe_f64
>   vcvt_f64_u64
>   vrecps_f64
> 
> Tested on aarch64-none-elf, and on an internal testsuite for Neon
> intrinsics.
> 
> Note that the new tests will ICE without the fixups in
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00805.html
> 
> OK?
> 

OK, but please fix the nit that Kyrill highlighted.

R.

> Thanks,
> James
> 
> ---
> gcc/ChangeLog
> 
> 2016-06-10  James Greenhalgh  
> 
>   * config/aarch64/arm_neon.h (vcvt_n_f64_s64): New.
>   (vcvt_n_f64_u64): Likewise.
>   (vcvt_n_s64_f64): Likewise.
>   (vcvt_n_u64_f64): Likewise.
>   (vcvt_f64_s64): Likewise.
>   (vrecpe_f64): Likewise.
>   (vcvt_f64_u64): Likewise.
>   (vrecps_f64): Likewise.
> 
> gcc/testsuite/ChangeLog
> 
> 2016-06-10  James Greenhalgh  
> 
>   * gcc.target/aarch64/vcvt_f64_1.c: New.
>   * gcc.target/aarch64/vcvt_n_f64_1.c: New.
>   * gcc.target/aarch64/vrecp_f64_1.c: New.
> 
> 
> 0001-Patch-AArch64-Add-some-more-missing-intrinsics.patch
> 
> 
> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index f70b6d3..2f90938 100644
> --- a/gcc/config/aarch64/arm_neon.h
> +++ b/gcc/config/aarch64/arm_neon.h
> @@ -12447,6 +12447,20 @@ vcvt_n_f32_u32 (uint32x2_t __a, const int __b)
>return __builtin_aarch64_ucvtfv2si_sus (__a, __b);
>  }
>  
> +__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
> +vcvt_n_f64_s64 (int64x1_t __a, const int __b)
> +{
> +  return (float64x1_t)
> +{ __builtin_aarch64_scvtfdi (vget_lane_s64 (__a, 0), __b) };
> +}
> +
> +__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
> +vcvt_n_f64_u64 (uint64x1_t __a, const int __b)
> +{
> +  return (float64x1_t)
> +{ __builtin_aarch64_ucvtfdi_sus (vget_lane_u64 (__a, 0), __b) };
> +}
> +
>  __extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
>  vcvtq_n_f32_s32 (int32x4_t __a, const int __b)
>  {
> @@ -12509,6 +12523,20 @@ vcvt_n_u32_f32 (float32x2_t __a, const int __b)
>return __builtin_aarch64_fcvtzuv2sf_uss (__a, __b);
>  }
>  
> +__extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
> +vcvt_n_s64_f64 (float64x1_t __a, const int __b)
> +{
> +  return (int64x1_t)
> +{ __builtin_aarch64_fcvtzsdf (vget_lane_f64 (__a, 0), __b) };
> +}
> +
> +__extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
> +vcvt_n_u64_f64 (float64x1_t __a, const int __b)
> +{
> +  return (uint64x1_t)
> +{ __builtin_aarch64_fcvtzudf_uss (vget_lane_f64 (__a, 0), __b) };
> +}
> +
>  __extension__ static __inline int32x4_t __attribute__ ((__always_inline__))
>  vcvtq_n_s32_f32 (float32x4_t __a, const int __b)
>  {
> @@ -12571,6 +12599,18 @@ vcvt_f32_u32 (uint32x2_t __a)
>return __builtin_aarch64_floatunsv2siv2sf ((int32x2_t) __a);
>  }
>  
> +__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
> +vcvt_f64_s64 (int64x1_t __a)
> +{
> +  return (float64x1_t) { vget_lane_s64 (__a, 0) };
> +}
> +
> +__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
> +vcvt_f64_u64 (uint64x1_t __a)
> +{
> +  return (float64x1_t) { vget_lane_u64 (__a, 0) };
> +}
> +
>  __extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
>  vcvtq_f32_s32 (int32x4_t __a)
>  {
> @@ -20659,6 +20699,12 @@ vrecpe_f32 (float32x2_t __a)
>return __builtin_aarch64_frecpev2sf (__a);
>  }
>  
> +__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
> +vrecpe_f64 (float64x1_t __a)
> +{
> +  return (float64x1_t) { vrecped_f64 (vget_lane_f64 (__a, 0)) };
> +}
> +
>  __extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
>  vrecpeq_f32 (float32x4_t __a)
>  {
> @@ -20691,6 +20737,13 @@ vrecps_f32 (float32x2_t __a, float32x2_t __b)
>return __builtin_aarch64_frecpsv2sf (__a, __b);
>  }
>  
> +__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
> +vrecps_f64 (float64x1_t __a, float64x1_t __b)
> +{
> +  return (float64x1_t) { vrecpsd_f64  (vget_lane_f64 (__a, 0),
> +vget_lane_f64 (__b, 0)) };
> +}
> +
>  __extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
>  vrecpsq_f32 (float32x4_t __a, float32x4_t __b)
>  {
> diff --git a/gcc/testsuite/gcc.target/aarch64/vcvt_f64_1.c 
> b/gcc/testsuite/gcc.target/aarch64/vcvt_f64_1.c
> new file mode 100644
> index 000..b7ee7af
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/vcvt_f64_1.c
> @@ -0,0 +1,48 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +#include "arm_neon.h"
> +
> +/* For each of these intrinsics, we're 

PING^3: [PATCH] PR33661 Fix problem with register asm in templates

[Andreas Krebbel]

Hi Jason,

could you please have a look?

https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00904.html

Thanks!

-Andreas-

Re: [PATCH] Giant concepts patch

[Jason Merrill]

On Fri, Mar 25, 2016 at 1:33 AM, Andrew Sutton
 wrote:
> I'll just leave this here...
>
> This patch significantly improves performance with concepts (i.e.,
> makes it actually usable for real systems) and improves the
> specificity of diagnostics when constraints fail.
>
> Unfortunately, this isn't easily submittable in small pieces because
> it completely replaces most of the core processing routines for
> constraints, including (essentially) a complete rewrite of logic.cc
> and the diagnostics in constraint.cc. More perfective work could be
> done related to diagnostics, but this needs to be applied first.
>
> As part of the patch, I added timevars for constraint satisfaction and
> subsumption. In template-heavy coe (~80KLOC), I'm seeing satisfaction
> account for ~6% of compilation time and subsumption ~2%. Template
> instantiation remains ~35%, but I think there's still room for
> improvement in concepts. It just requires experimentation.
>
> Tests involving significant number of disjunctions have yet to
> register > 1% of compilation time spent in subsumption, but I'm still
> testing.

Thanks, I've been working on integrating this patch, hoping to have it
in for 6.2.  Have you done more work on it since you sent this out?

A few issues:

I've run into some trouble building cmcstl2: declarator requirements
on a function can lead to constraints that tsubst_constraint doesn't
handle.  What was your theory of only handling a few _CONSTR codes
there?  This is blocking me from checking in the patch.

Adding gcc_unreachable to the ARGUMENT_PACK_SELECT handling in concept
arg hash/compare doesn't seem to break anything in either the GCC
testsuite or your stl2.  Do you have a testcase where that code is
still needed?

> Also, it might be worth noting that partial specialization of variable
> templates is currently broken. We don't seem to be emitting template
> arguments as part of the mangled name, leading to lots and lots of
> late redefinition errors.

This should be fixed now.

Jason

Re: [Patch AArch64] Fixup to fcvt patterns added in r237200

[Richard Earnshaw (lists)]

On 10/06/16 13:29, James Greenhalgh wrote:
> 
> Hi,
> 
> My autotester picked up some issues with the vcvt{ds}_n_* intrinsics
> added in r237200.
> 
> The iterators in this pattern do not resolve, as they have not been
> explicitly tied to the mode iterator (rather than the code iterator)
> used by the pattern.
> 
> This fixup adds the attribute tags, allowing the patterns to work
> correctly.
> 
> Additionally, the types assigned to these instructions were wrong, and
> would permit the immediate operand to be in a register. This will then
> develop in to an ICE as the patterns require an immediate operand, and so
> won't match. The ICE can be exposed by writing a wrapping function around
> the vcvtd_n_* intrinsics, which forces the immediate operand to a register.
> We have the infrastructure to error to the user rather than ICEing, but it
> needs some different types, which this patch adds.
> 
> I've checked this with an aarch64-none-elf test run, and run it through
> several rounds of my autotester for aarch64-none-elf and
> aarch64_be-none-elf.
> 
> OK?
> 

OK.

R.

> Thanks,
> James
> 
> ---
> 2016-06-10  James Greenhalgh  
> 
>   * config/aarch64/aarch64.md
>   (3): Add attributes to
>   iterators.
>   (3): Likewise.  Correct
>   attributes.
>   * config/aarch64/aarch64-builtins.c
>   (aarch64_types_binop_uss_qualifiers): Delete.
>   (TYPES_BINOP_USS): Likewise.
>   (aarch64_types_binop_sus_qualifiers): Likewise.
>   (TYPES_BINOP_SUS): Likewise.
>   (aarch64_types_fcvt_from_unsigned_qualifiers): New.
>   (TYPES_FCVTIMM_SUS): Likewise.
>   * config/aarch64/aarch64-simd-builtins.def (scvtf): Use SHIFTIMM
>   rather than BINOP.
>   (ucvtf): Use FCVTIMM_SUS rather than BINOP_SUS.
>   (fcvtzs): Use SHIFTIMM rather than BINOP.
>   (fcvtzu): Use SHIFTIMM_USS rather than BINOP_USS.
> 
> 
> 0001-Patch-AArch64-Fixup-to-fcvt-patterns-added-in-r23720.patch
> 
> 
> diff --git a/gcc/config/aarch64/aarch64-builtins.c 
> b/gcc/config/aarch64/aarch64-builtins.c
> index 262ea1c..6b90b2a 100644
> --- a/gcc/config/aarch64/aarch64-builtins.c
> +++ b/gcc/config/aarch64/aarch64-builtins.c
> @@ -139,14 +139,6 @@ aarch64_types_binop_ssu_qualifiers[SIMD_MAX_BUILTIN_ARGS]
>= { qualifier_none, qualifier_none, qualifier_unsigned };
>  #define TYPES_BINOP_SSU (aarch64_types_binop_ssu_qualifiers)
>  static enum aarch64_type_qualifiers
> -aarch64_types_binop_uss_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> -  = { qualifier_unsigned, qualifier_none, qualifier_none };
> -#define TYPES_BINOP_USS (aarch64_types_binop_uss_qualifiers)
> -static enum aarch64_type_qualifiers
> -aarch64_types_binop_sus_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> -  = { qualifier_none, qualifier_unsigned, qualifier_none };
> -#define TYPES_BINOP_SUS (aarch64_types_binop_sus_qualifiers)
> -static enum aarch64_type_qualifiers
>  aarch64_types_binopp_qualifiers[SIMD_MAX_BUILTIN_ARGS]
>= { qualifier_poly, qualifier_poly, qualifier_poly };
>  #define TYPES_BINOPP (aarch64_types_binopp_qualifiers)
> @@ -181,6 +173,10 @@ 
> aarch64_types_shift_to_unsigned_qualifiers[SIMD_MAX_BUILTIN_ARGS]
>= { qualifier_unsigned, qualifier_none, qualifier_immediate };
>  #define TYPES_SHIFTIMM_USS (aarch64_types_shift_to_unsigned_qualifiers)
>  static enum aarch64_type_qualifiers
> +aarch64_types_fcvt_from_unsigned_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> +  = { qualifier_none, qualifier_unsigned, qualifier_immediate };
> +#define TYPES_FCVTIMM_SUS (aarch64_types_fcvt_from_unsigned_qualifiers)
> +static enum aarch64_type_qualifiers
>  aarch64_types_unsigned_shift_qualifiers[SIMD_MAX_BUILTIN_ARGS]
>= { qualifier_unsigned, qualifier_unsigned, qualifier_immediate };
>  #define TYPES_USHIFTIMM (aarch64_types_unsigned_shift_qualifiers)
> diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def 
> b/gcc/config/aarch64/aarch64-simd-builtins.def
> index 1332734..02d465b 100644
> --- a/gcc/config/aarch64/aarch64-simd-builtins.def
> +++ b/gcc/config/aarch64/aarch64-simd-builtins.def
> @@ -447,10 +447,10 @@
>BUILTIN_VSDQ_HSI (QUADOP_LANE, sqrdmlsh_laneq, 0)
>  
>/* Implemented by <*><*>3.  */
> -  BUILTIN_VSDQ_SDI (BINOP, scvtf, 3)
> -  BUILTIN_VSDQ_SDI (BINOP_SUS, ucvtf, 3)
> -  BUILTIN_VALLF (BINOP, fcvtzs, 3)
> -  BUILTIN_VALLF (BINOP_USS, fcvtzu, 3)
> +  BUILTIN_VSDQ_SDI (SHIFTIMM, scvtf, 3)
> +  BUILTIN_VSDQ_SDI (FCVTIMM_SUS, ucvtf, 3)
> +  BUILTIN_VALLF (SHIFTIMM, fcvtzs, 3)
> +  BUILTIN_VALLF (SHIFTIMM_USS, fcvtzu, 3)
>  
>/* Implemented by aarch64_rsqrte.  */
>BUILTIN_VALLF (UNOP, rsqrte, 0)
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 926f2da..b3ae42b 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -4640,8 +4640,8 @@
>FCVT_F2FIXED))]
>""
>"@
> -   \t%0, %1, #%2
> -   \t%0, %1, #%2"
> +   \t%0, %1, #%2
> +   \t%0, %1, #%2"
>[(set_attr "type" "f_cvtf2i, neon_fp_to_int_")
> 

Re: [AArch64] Give some new costs for Cortex-A57 floating-point operations

[Richard Earnshaw (lists)]

On 03/06/16 09:35, James Greenhalgh wrote:
> 
> Hi,
> 
> This patch rebases the floating-point cost table for Cortex-A57 to be
> relative to the cost of a floating-point move. This in response to this
> feedback from Richard Sandiford [2] on Ramana's patch to calls.c [1] from
> 2014:
> 
>   I think this is really a bug in the backend.  The backend is assigning a
>   cost of COSTS_N_INSNS (3) to a floating-point constant not because the
>   constant itself is expensive -- it's actually as cheap as a register
>   in this context -- but because the backend considers floating-point
>   moves to be 3 times more expensive than cheap integer moves.
> 
> The argument is that a move in mode X should be treated with cost
> COSTS_N_INSNS (1), and other instructions should have a cost relative to
> that move. For example, in this patch we say that instructions building a
> floating-point constant are the same cost as a floating-point register to
> register move. Fixing this fixes the issue Ramana was seeing, in a way
> consistent with what other back-ends do.
> 
> This patch gives a small improvement to Spec2000FP on a Cortex-A57
> platform.
> 
> Bootstrapped on aarch64-none-linux-gnu with no issues.
> 
> OK?
> 

OK.

R.
> Thanks,
> James
> 
> ---
> 2016-06-03  James Greenhalgh  
> 
>   * config/arm/aarch-cost-tables.h (cortexa57_extra_costs): Make FP
>   costs relative to the cost of a register move.
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00136.html
> [2] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00391.html
> 
> 
> 0001-AArch64-Give-some-new-costs-for-Cortex-A57-floating-.patch
> 
> 
> diff --git a/gcc/config/arm/aarch-cost-tables.h 
> b/gcc/config/arm/aarch-cost-tables.h
> index c971b30..5f42253 100644
> --- a/gcc/config/arm/aarch-cost-tables.h
> +++ b/gcc/config/arm/aarch-cost-tables.h
> @@ -294,35 +294,35 @@ const struct cpu_cost_table cortexa57_extra_costs =
>{
>  /* FP SFmode */
>  {
> -  COSTS_N_INSNS (17),  /* div.  */
> -  COSTS_N_INSNS (5),   /* mult.  */
> -  COSTS_N_INSNS (9),   /* mult_addsub. */
> -  COSTS_N_INSNS (9),   /* fma.  */
> -  COSTS_N_INSNS (4),   /* addsub.  */
> -  COSTS_N_INSNS (2),   /* fpconst. */
> -  COSTS_N_INSNS (2),   /* neg.  */
> -  COSTS_N_INSNS (2),   /* compare.  */
> -  COSTS_N_INSNS (4),   /* widen.  */
> -  COSTS_N_INSNS (4),   /* narrow.  */
> -  COSTS_N_INSNS (4),   /* toint.  */
> -  COSTS_N_INSNS (4),   /* fromint.  */
> -  COSTS_N_INSNS (4)/* roundint.  */
> +  COSTS_N_INSNS (6),  /* div.  */
> +  COSTS_N_INSNS (1),   /* mult.  */
> +  COSTS_N_INSNS (2),   /* mult_addsub.  */
> +  COSTS_N_INSNS (2),   /* fma.  */
> +  COSTS_N_INSNS (1),   /* addsub.  */
> +  0,/* fpconst.  */
> +  0,/* neg.  */
> +  0,/* compare.  */
> +  COSTS_N_INSNS (1),   /* widen.  */
> +  COSTS_N_INSNS (1),   /* narrow.  */
> +  COSTS_N_INSNS (1),   /* toint.  */
> +  COSTS_N_INSNS (1),   /* fromint.  */
> +  COSTS_N_INSNS (1)/* roundint.  */
>  },
>  /* FP DFmode */
>  {
> -  COSTS_N_INSNS (31),  /* div.  */
> -  COSTS_N_INSNS (5),   /* mult.  */
> -  COSTS_N_INSNS (9),   /* mult_addsub.  */
> -  COSTS_N_INSNS (9),   /* fma.  */
> -  COSTS_N_INSNS (4),   /* addsub.  */
> -  COSTS_N_INSNS (2),   /* fpconst.  */
> -  COSTS_N_INSNS (2),   /* neg.  */
> -  COSTS_N_INSNS (2),   /* compare.  */
> -  COSTS_N_INSNS (4),   /* widen.  */
> -  COSTS_N_INSNS (4),   /* narrow.  */
> -  COSTS_N_INSNS (4),   /* toint.  */
> -  COSTS_N_INSNS (4),   /* fromint.  */
> -  COSTS_N_INSNS (4)/* roundint.  */
> +  COSTS_N_INSNS (11),  /* div.  */
> +  COSTS_N_INSNS (1),   /* mult.  */
> +  COSTS_N_INSNS (2),   /* mult_addsub.  */
> +  COSTS_N_INSNS (2),   /* fma.  */
> +  COSTS_N_INSNS (1),   /* addsub.  */
> +  0,/* fpconst.  */
> +  0,/* neg.  */
> +  0,/* compare.  */
> +  COSTS_N_INSNS (1),   /* widen.  */
> +  COSTS_N_INSNS (1),   /* narrow.  */
> +  COSTS_N_INSNS (1),   /* toint.  */
> +  COSTS_N_INSNS (1),   /* fromint.  */
> +  COSTS_N_INSNS (1)/* roundint.  */
>  }
>},
>/* Vector */
> 

[Bug middle-end/71581] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71581

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r210199.

[Bug rtl-optimization/71591] SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71591

--- Comment #2 from Jakub Jelinek  ---
Created attachment 38732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38732=edit
gcc7-pr71591.patch

Untested patch to do that.

[Bug middle-end/71529] [7 regression][CHKP] ICE in expand_expr_real_1

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71529

Ilya Enkovich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Ilya Enkovich  ---
Fixed

[Bug rtl-optimization/71591] SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71591

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is because when preprocessing the backend isn't initialized, so if
-fself-test attempts to run tests that rely on the backend being initialized,
it can't really work.  pc_rtx is NULL among hundreds of other issues.
Trying to initialize the backend just because of -fself-test is weird, I'd say
we should just error loudly in toplev::run_self_tests () if (no_backend).

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
  Known to fail|4.9.2, 5.2.1|4.9.3, 5.4.1, 6.1.1

--- Comment #9 from Georg-Johann Lay  ---
Fixed in 4.9.4, 5.5, 6.2.

[Ada] Reimplementation of type invariants

[Arnaud Charlet]

This patch prevents the insertion of the invariant procedure declaration and
body when the context is a generic unit. This ensures that generated code does
not permiate the template.


-- Source --


--  tester.ads

package Tester is
   type Type_Id is
 (Ext_1_Id,
  Ext_1_FV_Id,
  Ext_2_Id,
  Ext_3_Id,
  Ext_4_Id,
  Ext_4_FV_Id,
  Ext_5_Id,
  Ext_6_Id,
  Ext_6_FV_Id,
  Ext_7_Id,
  Ext_8_Id,
  Iface_1_Id,
  Iface_2_Id,
  Iface_3_Id,
  Iface_4_Id,
  Par_1_Id,
  Par_2_FV_Id,
  Par_3_Id,
  Par_4_Id,
  Par_4_FV_Id,
  Prot_1_FV_Id,
  Prot_2_Id,
  Prot_3_Id,
  Prot_3_FV_Id,
  Synch_1_Id,
  Synch_2_Id,
  Tag_1_Id,
  Tag_2_Id,
  Tag_3_Id,
  Tag_4_Id,
  Tag_4_FV_Id,
  Tag_5_Id,
  Tag_6_Id,
  Tag_7_Id,
  Tag_8_Id,
  Tag_9_Id,
  Tag_10_Id,
  Tag_11_Id,
  Tag_12_Id,
  Tag_13_Id,
  Tag_14_Id,
  Tag_15_Id,
  Tag_15_FV_Id,
  Tag_16_Id,
  Tag_17_Id,
  Tag_18_Id,
  Tag_19_Id,
  Tag_20_Id,
  Tag_20_FV_Id,
  Tag_21_Id,
  Tag_22_Id,
  Tag_23_Id,
  Tag_24_Id,
  Tag_24_FV_Id,
  Tag_25_Id,
  Tag_26_Id,
  Tag_27_Id,
  Tag_28_Id,
  Task_1_Id,
  Task_2_Id,
  Task_2_FV_Id,
  Untag_1_Id,
  Untag_2_Id,
  Untag_3_Id,
  Untag_4_Id,
  Untag_5_Id,
  Untag_6_Id,
  Untag_7_Id,
  Untag_8_Id,
  Untag_9_Id);

   type Results is array (Type_Id) of Boolean;

   function Mark (Typ : Type_Id) return Boolean;
   --  Mark the result for a particular type as verified. The function always
   --  returns True.

   procedure Reset_Results;
   --  Reset the internally kept result state

   procedure Test_Results (Test_Id : String; Exp : Results);
   --  Ensure that the internally kept result state agrees with expected
   --  results Exp. Emit an error if this is not the case.
end Tester;

--  tester.adb

with Ada.Text_IO; use Ada.Text_IO;

package body Tester is
   State : Results;

   --
   -- Mark --
   --

   function Mark (Typ : Type_Id) return Boolean is
   begin
  State (Typ) := True;
  return True;
   end Mark;

   ---
   -- Reset_Results --
   ---

   procedure Reset_Results is
   begin
  State := (others => False);
   end Reset_Results;

   --
   -- Test_Results --
   --

   procedure Test_Results (Test_Id : String; Exp : Results) is
  Exp_Val   : Boolean;
  Posted: Boolean := False;
  State_Val : Boolean;

   begin
  for Index in Results'Range loop
 Exp_Val   := Exp (Index);
 State_Val := State (Index);

 if State_Val /= Exp_Val then
if not Posted then
   Posted := True;
   Put_Line (Test_Id & ": ERROR");
end if;

Put_Line ("  Expected: " & Exp_Val'Img & " for " & Index'Img);
Put_Line ("  Got:  " & State_Val'Img);
 end if;
  end loop;

  if not Posted then
 Put_Line (Test_Id & ": OK");
  end if;
   end Test_Results;
end Tester;

--  gen_invariants.ads

with Tester; use Tester;

generic
package Gen_Invariants is
   type Untag_1 is private
 with Type_Invariant => Mark (Untag_1_Id);

private
   type Untag_1 is null record;

   Obj_1 : Untag_1;
end Gen_Invariants;

-
-- Compilation --
-

$ gcc -c -gnata -gnatDG gen_invariants.ads
$ grep "Invariant" gen_invariants.ads.dg

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

2016-06-20  Hristian Kirtchev  

* exp_ch7.adb (Build_Invariant_Procedure_Body):
Always install the scope of the invariant procedure
in order to produce better error messages. Do not
insert the body when the context is a generic unit.
(Build_Invariant_Procedure_Declaration): Perform minimal
decoration of the invariant procedure and its formal parameter
in case they are not analyzed.  Do not insert the declaration
when the context is a generic unit.

Index: exp_ch7.adb
===
--- exp_ch7.adb (revision 237598)
+++ exp_ch7.adb (working copy)
@@ -4622,7 +4622,16 @@
 
   Set_Ghost_Mode_From_Entity (Work_Typ);
 
+  --  Emulate the environment of the invariant procedure by installing
+  --  its scope and formal parameters. Note that this is not need, but
+  --  having the scope of the invariant procedure installed helps with
+  --  the detection of invariant-related errors.
+
+  Push_Scope (Proc_Id);
+  Install_Formals (Proc_Id);
+
   Obj_Id := First_Formal (Proc_Id);
+  pragma Assert (Present (Obj_Id));
 
   --  The "partial" invariant procedure verifies the invariants of the
   --  partial view only.
@@ -4631,14 +4640,6 @@
  pragma Assert (Present (Priv_Typ));
  

[Ada] Adapt treatment of inherited classwide pre/post to GNATprove

[Arnaud Charlet]

In GNATprove mode, inherited classwide pre/post are copied to the
overriding subprogram declaration, so that GNATprove can find them to
verify Liskov Substitution Principle on SPARK code. The copied pre/post
are not turned into pragma checks anymore in GNATprove mode, so that they
are added to the Contract node of the overriding subprogram entity, which
makes it easier to deal with in GNATprove.

The type of the call node is also set to the appropriate type after the
function has been specialized in the copied pragma, in both GNATprove
mode and normal mode.

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

2016-06-20  Yannick Moy  

* sem_prag.adb, sem_prag.ads (Build_Pragma_Check_Equivalent):
Add parameter Keep_Pragma_Id to optionally keep
the identifier of the pragma instead of converting
to pragma Check. Also set type of new function call
appropriately.  (Collect_Inherited_Class_Wide_Conditions):
Call Build_Pragma_Check_Equivalent with the new parameter
Keep_Pragma_Id set to True to keep the identifier of the copied
pragma.
* sinfo.ads: Add comment.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 237598)
+++ sem_prag.adb(working copy)
@@ -26277,9 +26277,10 @@
---
 
function Build_Pragma_Check_Equivalent
- (Prag : Node_Id;
-  Subp_Id  : Entity_Id := Empty;
-  Inher_Id : Entity_Id := Empty) return Node_Id
+ (Prag   : Node_Id;
+  Subp_Id: Entity_Id := Empty;
+  Inher_Id   : Entity_Id := Empty;
+  Keep_Pragma_Id : Boolean := False) return Node_Id
is
   Map : Elist_Id;
   --  List containing the following mappings
@@ -26361,6 +26362,15 @@
& "for

[Ada] Always consider Linker_Options from package System

[Arnaud Charlet]

On full runtimes, this was always the case.  On restricted one, force system
to be in the closer of the program.
No test for full runtimes (as no behaviour change).

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

2016-06-20  Tristan Gingold  

* make.adb (Check_Standard_Library): Consider system.ads
if s-stalib.adb is not available.
* gnatbind.adb (Add_Artificial_ALI_File): New procedure extracted from
gnatbind.

Index: make.adb
===
--- make.adb(revision 237595)
+++ make.adb(working copy)
@@ -84,8 +84,11 @@
--  Make control characters visible
 
Standard_Library_Package_Body_Name : constant String := "s-stalib.adb";
-   --  Every program depends on this package, that must then be checked,
-   --  especially when -f and -a are used.
+   System_Package_Spec_Name : constant String := "system.ads";
+   --  Every program depends on one of these packages: usually the first one,
+   --  or if Supress_Standard_Library is true on the second one. The dependency
+   --  is not always explicit and considering it is important when -f and -a
+   --  are used.
 
type Sigint_Handler is access procedure;
pragma Convention (C, Sigint_Handler);
@@ -2701,39 +2704,43 @@
   begin
  Need_To_Check_Standard_Library := False;
 
+ Name_Len := 0;
+
  if not Targparm.Suppress_Standard_Library_On_Target then
-declare
-   Sfile  : File_Name_Type;
-   Add_It : Boolean := True;
+Add_Str_To_Name_Buffer (Standard_Library_Package_Body_Name);
+ else
+Add_Str_To_Name_Buffer (System_Package_Spec_Name);
+ end if;
 
-begin
-   Name_Len := 0;
-   Add_Str_To_Name_Buffer (Standard_Library_Package_Body_Name);
-   Sfile := Name_Enter;
+ declare
+Sfile  : File_Name_Type;
+Add_It : Boolean := True;
 
-   --  If we have a special runtime, we add the standard
-   --  library only if we can find it.
+ begin
+Sfile := Name_Enter;
 
-   if RTS_Switch then
-  Add_It := Full_Source_Name (Sfile) /= No_File;
-   end if;
+--  If we have a special runtime, we add the standard library only
+--  if we can find it.
 
-   if Add_It then
-  if not Queue.Insert
-   ((Format  => Format_Gnatmake,
- File=> Sfile,
- Unit=> No_Unit_Name,
- Project => No_Project,
- Index   => 0,
- Sid => No_Source))
-  then
- if Is_In_Obsoleted (Sfile) then
-Executable_Obsolete := True;
- end if;
+if RTS_Switch then
+   Add_It := Full_Source_Name (Sfile) /= No_File;
+end if;
+
+if Add_It then
+   if not Queue.Insert
+((Format  => Format_Gnatmake,
+  File=> Sfile,
+  Unit=> No_Unit_Name,
+  Project => No_Project,
+  Index   => 0,
+  Sid => No_Source))
+   then
+  if Is_In_Obsoleted (Sfile) then
+ Executable_Obsolete := True;
   end if;
end if;
-end;
- end if;
+end if;
+ end;
   end Check_Standard_Library;
 
   ---
Index: gnatbind.adb
===
--- gnatbind.adb(revision 237595)
+++ gnatbind.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2015, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2016, 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- --
@@ -89,6 +89,9 @@
--  Table to record the sources in the closure, to avoid duplications. Used
--  only with switch -R.
 
+   procedure Add_Artificial_ALI_File (Name : String);
+   --  Artificially add ALI file Name in the closure.
+
function Gnatbind_Supports_Auto_Init return Boolean;
--  Indicates if automatic initialization of elaboration procedure
--  through the constructor 

[Ada] Handling of all-digits host names

[Arnaud Charlet]

In Get_Host_By_Name, do not treat a strings consisting of digits only
as an IP address whose lookup should actually be done using
Get_Host_By_Address.

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

2016-06-20  Thomas Quinot  

* g-socket.adb (Is_IP_Address): A string consisting in digits only is
not a dotted quad.

Index: g-socket.adb
===
--- g-socket.adb(revision 237595)
+++ g-socket.adb(working copy)
@@ -150,7 +150,7 @@
--  Output an array of inet address components in hex or decimal mode
 
function Is_IP_Address (Name : String) return Boolean;
-   --  Return true when Name is an IP address in standard dot notation
+   --  Return true when Name is an IPv4 address in dotted quad notation
 
procedure Netdb_Lock;
pragma Inline (Netdb_Lock);
@@ -996,7 +996,8 @@
 
function Get_Host_By_Name (Name : String) return Host_Entry_Type is
begin
-  --  Detect IP address name and redirect to Inet_Addr
+  --  If the given name actually is the string representation of
+  --  an IP address, use Get_Host_By_Address instead.
 
   if Is_IP_Address (Name) then
  return Get_Host_By_Address (Inet_Addr (Name));
@@ -1503,16 +1504,37 @@
---
 
function Is_IP_Address (Name : String) return Boolean is
+  Dots : Natural := 0;
begin
+  --  Perform a cursory check for a dotted quad: we must have 1 to 3
+  --  dots, and there must be at least one digit around each.
+
   for J in Name'Range loop
- if Name (J) /= '.'
-   and then Name (J) not in '0' .. '9'
- then
+ if Name (J) = '.' then
+
+--  Check that the dot is not in first or last position, and
+--  that it is followed by a digit. Note that we already know
+--  that it is preceded by a digit, or we would have returned
+--  earlier on.
+
+if J in Name'First + 1 .. Name'Last - 1
+  and then Name (J + 1) in '0' .. '9'
+then
+   Dots := Dots + 1;
+
+else
+
+   --  Definitely not a proper dotted quad
+
+   return False;
+end if;
+
+ elsif Name (J) not in '0' .. '9' then
 return False;
  end if;
   end loop;
 
-  return True;
+  return Dots in 1 .. 3;
end Is_IP_Address;
 
-

Re: [PATCH 2/2][v3] Drop excess size used for run time allocated stack variables.

[Bernd Schmidt]

On 06/20/2016 02:19 PM, Dominik Vogt wrote:


+/* PR/50938: Check that alloca () reserves the correct amount of stack space.
+ */


Same here really, even if it's only a test.


In this case, the line gets too long with "  */" appended.


In that case we wrap before the last word.


Bernd

Re: [PATCH 2/2][v3] Drop excess size used for run time allocated stack variables.

[Dominik Vogt]

On Wed, Jun 08, 2016 at 01:21:09PM +0200, Bernd Schmidt wrote:
> On 05/25/2016 03:32 PM, Dominik Vogt wrote:
> > * explow.c (round_push): Use know adjustment.
> > (allocate_dynamic_stack_space): Pass known adjustment to round_push.
> >gcc/testsuite/ChangeLog
> >
> 
> I was thinking about whether it would be possible/desirable to
> eliminate the double add entirely, but I couldn't find a way to
> structure the code in a way that seems better than what you have.
> So, ...
> 
> > /* Round the size of a block to be pushed up to the boundary required
> >-   by this machine.  SIZE is the desired size, which need not be constant.  
> >*/
> >+   by this machine.  SIZE is the desired size, which need not be constant.
> >+   ALREADY_ADDED is the number of units that have already been added to SIZE
> >+   for other alignment reasons.
> >+*/
> 
> The */ goes on the last line of the comment.

No problem.

> >+/* PR/50938: Check that alloca () reserves the correct amount of stack 
> >space.
> >+ */
> 
> Same here really, even if it's only a test.

In this case, the line gets too long with "  */" appended.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

[avr, 6, 5, 4.9, committed] Backported PR target/71103

[Georg-Johann Lay]

Applied backports to:

v6: https://gcc.gnu.org/r237591
v5: https://gcc.gnu.org/r237593
v4.9: https://gcc.gnu.org/r237594

Johann


gcc/
Backport from 2016-06-20 trunk r237589, r236558.

PR target/71103
* config/avr/avr.md (movqi): Handle loading subreg:qi (const,
symbol_ref,label_ref).

gcc/testsuite/
Backport from 2016-06-20 trunk r237589, r236558.

PR target/71103
* gcc.target/avr/pr71103.c: New test.
* gcc.target/avr/torture/pr71103-2.c: New test.

Index: config/avr/avr.md
===
--- config/avr/avr.md	(revision 237589)
+++ config/avr/avr.md	(working copy)
@@ -641,6 +641,21 @@ (define_expand "mov"
 if (avr_mem_flash_p (dest))
   DONE;
 
+if (QImode == mode
+&& SUBREG_P (src)
+&& CONSTANT_ADDRESS_P (SUBREG_REG (src)))
+{
+// store_bitfield may want to store a SYMBOL_REF or CONST in a
+// structure that's represented as PSImode.  As the upper 16 bits
+// of PSImode cannot be expressed as an HImode subreg, the rhs is
+// decomposed into QImode (word_mode) subregs of SYMBOL_REF,
+// CONST or LABEL_REF; cf. PR71103.
+
+rtx const_addr = SUBREG_REG (src);
+operands[1] = src = copy_rtx (src);
+SUBREG_REG (src) = copy_to_mode_reg (GET_MODE (const_addr), const_addr);
+  }
+
 /* One of the operands has to be in a register.  */
 if (!register_operand (dest, mode)
 && !reg_or_0_operand (src, mode))
Index: testsuite/gcc.target/avr/pr71103.c
===
--- testsuite/gcc.target/avr/pr71103.c	(nonexistent)
+++ testsuite/gcc.target/avr/pr71103.c	(working copy)
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+struct ResponseStruct{
+unsigned char responseLength;
+char *response;
+};
+
+static char response[5];
+struct ResponseStruct something(){
+struct ResponseStruct returnValue;
+returnValue.responseLength = 5;
+returnValue.response = response;
+return returnValue;
+}
+
Index: testsuite/gcc.target/avr/torture/pr71103-2.c
===
--- testsuite/gcc.target/avr/torture/pr71103-2.c	(nonexistent)
+++ testsuite/gcc.target/avr/torture/pr71103-2.c	(working copy)
@@ -0,0 +1,118 @@
+/* Use -g0 so that this test case doesn't just fail because
+   of PR52472.  */
+
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99 -g0" } */
+
+struct S12
+{
+  char c;
+  const char *p;
+};
+
+struct S12f
+{
+  char c;
+  struct S12f (*f)(void);
+};
+
+struct S12labl
+{
+  char c;
+  void **labl;
+};
+
+struct S121
+{
+  char c;
+  const char *p;
+  char d;
+};
+
+const char str[5] = "abcd";
+
+struct S12 test_S12_0 (void)
+{
+  struct S12 s;
+  s.c = 'A';
+  s.p = str;
+  return s;
+}
+
+struct S12 test_S12_4 (void)
+{
+  struct S12 s;
+  s.c = 'A';
+  s.p = str + 4;
+  return s;
+}
+
+struct S12f test_S12f (void)
+{
+  struct S12f s;
+  s.c = 'A';
+  s.f = test_S12f;
+  return s;
+}
+
+struct S121 test_S121 (void)
+{
+  struct S121 s;
+  s.c = 'c';
+  s.p = str + 4;
+  s.d = 'd';
+  return s;
+}
+
+extern void use_S12lab (struct S12labl*);
+
+struct S12labl test_S12lab (void)
+{
+  struct S12labl s;
+labl:;
+  s.c = 'A';
+  s.labl = &
+  return s;
+}
+
+#ifdef __MEMX
+
+struct S13
+{
+  char c;
+  const __memx char *p;
+};
+
+const __memx char str_x[] = "abcd";
+
+struct S13 test_S13_0 (void)
+{
+  struct S13 s;
+  s.c = 'A';
+  s.p = str_x;
+  return s;
+}
+
+struct S13 test_S13_4a (void)
+{
+  struct S13 s;
+  s.c = 'A';
+  s.p = str_x + 4;
+  return s;
+}
+
+#ifdef __FLASH1
+
+const __flash1 char str_1[] = "abcd";
+
+struct S13 test_13_4b (void)
+{
+  struct S13 s;
+  s.c = 'A';
+  s.p = str_1 + 4;
+  return s;
+}
+
+#endif /* have __flash1 */
+#endif /* have __memx */
+

[Patch, Fortran] PR71194 - Fix ICE with pointer assignment

[Tobias Burnus]

Dear all,

the issue occurs only if the RHS of a pointer assignment is a function and
the ICE is only triggered when a rank remapping is needed.

gfc_conv_expr_descriptor calls for a expr2 gfc_conv_procedure_call, which
sets "se.expr" to NULL_TREE - and the code later tries to access it.

The code correctly sets rse.expr to "tmp", but that does not help as all
actions were wrongly done on lse before. Solution: Stuff the RHS expr2 into
rse not into lse.

Build and regtested* on x86-64-gnu-linux.
OK for the trunk?

Tobias

(* gfortran.dg/graphite/pr68279.f90 fails but is a known PR,
gfortran.dg/vect/vect-8.f90 fails but not only for me, and
gfortran.dg/guality/pr41558.f90 never worked on that system)
	PR fortran/71194
	* trans-expr.c (gfc_trans_pointer_assignment): Correctly handle
	RHS pointer functions.

	PR fortran/71194
	* gfortran.dg/pointer_remapping_10.f90 | 46 ++

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 8f84712..b5731aa 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -7934,11 +7934,11 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
 	   bound, bound, 0,
 	   GFC_ARRAY_POINTER_CONT, false);
 	  tmp = gfc_create_var (tmp, "ptrtemp");
-	  lse.descriptor_only = 0;
-	  lse.expr = tmp;
-	  lse.direct_byref = 1;
-	  gfc_conv_expr_descriptor (, expr2);
-	  strlen_rhs = lse.string_length;
+	  rse.descriptor_only = 0;
+	  rse.expr = tmp;
+	  rse.direct_byref = 1;
+	  gfc_conv_expr_descriptor (, expr2);
+	  strlen_rhs = rse.string_length;
 	  rse.expr = tmp;
 	}
 	  else
diff --git a/gcc/testsuite/gfortran.dg/pointer_remapping_10.f90 b/gcc/testsuite/gfortran.dg/pointer_remapping_10.f90
new file mode 100644
index 000..4810506
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pointer_remapping_10.f90
@@ -0,0 +1,46 @@
+! { dg-do run }
+! { dg-options "-fcheck=all" }
+!
+! PR fortran/71194
+!
+! Contributed by T Kondic
+!
+program ice
+implicit none
+integer, parameter :: pa=10, pb=20
+complex, target :: a(pa*pb)
+real, pointer:: ptr(:,:) =>null()
+integer :: i, j, cnt
+logical :: negative
+
+  do i = 1, size(a)
+a(i) = cmplx(i,-i)
+  end do
+
+  ! Was ICEing before with bounds checks
+  ptr(1:pa*2,1:pb) => conv2real(a)
+
+  negative = .false.
+  cnt = 1
+  do i = 1, ubound(ptr,dim=2)
+do j = 1, ubound(ptr,dim=1)
+  if (negative) then
+if (-cnt /= ptr(j, i)) call abort()
+cnt = cnt + 1
+negative = .false.
+  else
+if (cnt /= ptr(j, i)) call abort()
+negative = .true.
+  end if
+end do 
+  end do
+
+contains
+  function conv2real(carr)
+use, intrinsic :: iso_c_binding
+! returns real pointer to a complex array
+complex, contiguous, intent(inout), target  :: carr(:)
+real,contiguous,pointer :: conv2real(:)
+call c_f_pointer(c_loc(carr),conv2real,[size(carr)*2])
+  end function conv2real
+end program

[Bug c/70477] -Wtautological-compare too aggressive?

[s at ecloud dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477

ecloud  changed:

   What|Removed |Added

 CC||s at ecloud dot org

--- Comment #5 from ecloud  ---
>From my perspective it looks like https://bugreports.qt.io/browse/QTBUG-53373
is also a case of -Wtautological-compare being too aggressive too; but I'm not
an expert on that code, and it might turn out that someone comes up with some
solution other than disabling the warning.

If a macro exists in order to test something and generate different code
depending on the test result, then in any given use case of the macro, we can
say that the test inside the macro is a tautology, right?  But that shouldn't
mean that doing tests inside macros is bad.

Re: i386/prologues: ROP mitigation for normal function epilogues

[Michael Matz]

Hi,

On Fri, 17 Jun 2016, Bernd Schmidt wrote:

> > The "0xe9 " essentially is the leave+return opcode, 
> > after all it jumps to them (let's ignore the possibility that the jump 
> > target address might contain a 0xc3 byte).  So if the attacker finds 
> > some interesting gadget in  I don't see how the change 
> > from leave+ret to jump-to-leave+ret changes anything from a threat 
> > avoidance perspective.  It's fully possible that I don't understand 
> > the threat vector of ROP correctly, in which case I'd also like to 
> > know :)
> 
> The advantage is that this way the attack can't skip the leave opcode by 
> jumping into the "random bytes1" in your first sequence. Hence, we 
> ensure the return path will always overwrite esp first, which is what's 
> supposed to make the attack harder since now you need to control ebp as 
> well.

Okay, thanks.  So it's really the wish for an inseparable leave+ret 
leading to this; that sort of makes sense I guess.


Ciao,
Michael.
P.S: Though I do feel these ROP counter measures are not much more than 
security by obscurity; I guess enough obscurity indeed can at least lead 
to harder to exploit programs.

[Bug c++/55203] No unused warning for variables of non-trivial types

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203

--- Comment #13 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #6)
> Which are the relevant classes?  It seems to me that we want to tag almost
> everything except a few RAII types such as std::lock_guard and
> std::unique_lock, which would be quite tedious.  It's certainly applicable
> on all containers, and most streams except fstreams (which have constructors
> with side-effects.)

__attribute__((unused)) on types seems to exist precisely for the reverse
situation where gcc would warn by default, and we would mark the odd class that
is meant to be used this way:
"When attached to a type (including a union or a struct), this attribute means
that variables of that type are meant to appear possibly unused. GCC does not
produce a warning for any variables of that type, even if the variable appears
to do nothing. This is often the case with lock or thread classes, which are
usually defined and then not referenced, but contain constructors and
destructors that have nontrivial bookkeeping functions."

I would be in favor of:
- mark the few relevant types in libstdc++ with this attribute,
- change the warning to apply to all non-marked types, with an extra note
(possibly restricted to the case of non-trivial types) pointing out this
attribute.

[Bug tree-optimization/71588] [4.9/5/6/7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71588

--- Comment #3 from Jakub Jelinek  ---
Created attachment 38731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38731=edit
gcc7-pr71588.patch

Untested fix.

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103

--- Comment #8 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Jun 20 12:02:36 2016
New Revision: 237594

URL: https://gcc.gnu.org/viewcvs?rev=237594=gcc=rev
Log:
gcc/
Backport from 2016-06-20 trunk r237589, r236558.
PR target/71103
* config/avr/avr.md (movqi): Handle loading subreg:qi (const,
symbol_ref,label_ref).
gcc/testsuite/
Backport from 2016-06-20 trunk r237589, r236558.
PR target/71103
* gcc.target/avr/pr71103.c: New test.
* gcc.target/avr/torture/pr71103-2.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/pr71103.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/avr/avr.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/71549] ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71549

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #6 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01398.html

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103

--- Comment #7 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Jun 20 11:55:11 2016
New Revision: 237593

URL: https://gcc.gnu.org/viewcvs?rev=237593=gcc=rev
Log:
gcc/
Backport from 2016-06-20 trunk r237589, r236558.
PR target/71103
* config/avr/avr.md (movqi): Handle loading subreg:qi (const,
symbol_ref,label_ref).

gcc/testsuite/
Backport from 2016-06-20 trunk r237589, r236558.
PR target/71103
* gcc.target/avr/pr71103.c: New test.
* gcc.target/avr/torture/pr71103-2.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/pr71103.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/avr/avr.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[PATCH] PR target/71549: Convert V1TImode register to TImode in debug insn

[H.J. Lu]

TImode register referenced in debug insn can be converted to V1TImode
by scalar to vector optimization.  We need to convert a debug insn if
it has a variable in a TImode register.

Tested on x86-64.  OK for trunk?


H.J.

gcc/

PR target/71549
* config/i386/i386.c (timode_scalar_to_vector_candidate_p):
Return true if debug insn has a variable in TImode register.
(timode_remove_non_convertible_regs): Skip debug insn.
(scalar_chain::convert_insn): Change return type to bool.
(scalar_chain::add_insn): Don't check registers in debug insn.
(dimode_scalar_chain::convert_insn): Change return type to bool
and always return true.
(timode_scalar_chain::convert_insn): Change return type to bool.
Convert V1TImode register to SUBREG TImode in debug insn.  Return
false if debug insn isn't converted.  Otherwise, return true.
(scalar_chain::convert): Increment converted_insns only if
convert_insn returns true.

gcc/testsuite/

PR target/71549
* gcc.target/i386/pr71549.c: New test.
---
 gcc/config/i386/i386.c  | 58 -
 gcc/testsuite/gcc.target/i386/pr71549.c | 24 ++
 2 files changed, 74 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr71549.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 56a5b9c..e17fc53 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2845,6 +2845,16 @@ dimode_scalar_to_vector_candidate_p (rtx_insn *insn)
 static bool
 timode_scalar_to_vector_candidate_p (rtx_insn *insn)
 {
+  if (DEBUG_INSN_P (insn))
+{
+  /* If a variable is put in a TImode register, which may be
+converted to V1TImode, we need to convert this debug insn.  */
+  rtx val = PATTERN (insn);
+  return (GET_MODE (val) == TImode
+ && GET_CODE (val) == VAR_LOCATION
+ && REG_P (PAT_VAR_LOCATION_LOC (val)));
+}
+
   rtx def_set = single_set (insn);
 
   if (!def_set)
@@ -3012,7 +3022,12 @@ timode_remove_non_convertible_regs (bitmap candidates)
 
   EXECUTE_IF_SET_IN_BITMAP (candidates, 0, id, bi)
 {
-  rtx def_set = single_set (DF_INSN_UID_GET (id)->insn);
+  rtx_insn *insn = DF_INSN_UID_GET (id)->insn;
+  /* Debug insn isn't a SET insn.  */
+  if (DEBUG_INSN_P (insn))
+   continue;
+
+  rtx def_set = single_set (insn);
   rtx dest = SET_DEST (def_set);
   rtx src = SET_SRC (def_set);
 
@@ -3111,7 +3126,7 @@ class scalar_chain
   void add_insn (bitmap candidates, unsigned insn_uid);
   void analyze_register_chain (bitmap candidates, df_ref ref);
   virtual void mark_dual_mode_def (df_ref def) = 0;
-  virtual void convert_insn (rtx_insn *insn) = 0;
+  virtual bool convert_insn (rtx_insn *insn) = 0;
   virtual void convert_registers () = 0;
 };
 
@@ -3123,7 +3138,7 @@ class dimode_scalar_chain : public scalar_chain
   void mark_dual_mode_def (df_ref def);
   rtx replace_with_subreg (rtx x, rtx reg, rtx subreg);
   void replace_with_subreg_in_insn (rtx_insn *insn, rtx reg, rtx subreg);
-  void convert_insn (rtx_insn *insn);
+  bool convert_insn (rtx_insn *insn);
   void convert_op (rtx *op, rtx_insn *insn);
   void convert_reg (unsigned regno);
   void make_vector_copies (unsigned regno);
@@ -3139,7 +3154,7 @@ class timode_scalar_chain : public scalar_chain
 
  private:
   void mark_dual_mode_def (df_ref def);
-  void convert_insn (rtx_insn *insn);
+  bool convert_insn (rtx_insn *insn);
   /* We don't convert registers to difference size.  */
   void convert_registers () {}
 };
@@ -3276,6 +3291,10 @@ scalar_chain::add_insn (bitmap candidates, unsigned int 
insn_uid)
   bitmap_set_bit (insns, insn_uid);
 
   rtx_insn *insn = DF_INSN_UID_GET (insn_uid)->insn;
+  /* Debug insn isn't a SET insn.  */
+  if (DEBUG_INSN_P (insn))
+return;
+
   rtx def_set = single_set (insn);
   if (def_set && REG_P (SET_DEST (def_set))
   && !HARD_REGISTER_P (SET_DEST (def_set)))
@@ -3708,7 +3727,7 @@ dimode_scalar_chain::convert_op (rtx *op, rtx_insn *insn)
 
 /* Convert INSN to vector mode.  */
 
-void
+bool
 dimode_scalar_chain::convert_insn (rtx_insn *insn)
 {
   rtx def_set = single_set (insn);
@@ -3788,13 +3807,34 @@ dimode_scalar_chain::convert_insn (rtx_insn *insn)
   INSN_CODE (insn) = -1;
   recog_memoized (insn);
   df_insn_rescan (insn);
+
+  return true;
 }
 
 /* Convert INSN from TImode to V1T1mode.  */
 
-void
+bool
 timode_scalar_chain::convert_insn (rtx_insn *insn)
 {
+  if (DEBUG_INSN_P (insn))
+{
+  /* It must be a debug insn with a TImode variable in register.  */
+  rtx val = PATTERN (insn);
+  gcc_assert (GET_MODE (val) == TImode
+ && GET_CODE (val) == VAR_LOCATION);
+  rtx loc = PAT_VAR_LOCATION_LOC (val);
+  gcc_assert (REG_P (loc));
+  /* Convert V1TImode register, which has been updated by a SET
+insn before, to SUBREG TImode.  */
+  if 

[Bug tree-optimization/71588] [4.9/5/6/7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71588

Jakub Jelinek  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |4.9.4

Re: Deprecating basic asm in a function - What now?

[Joseph Myers]

On Mon, 20 Jun 2016, Andrew Haley wrote:

> On 20/06/16 08:00, Andrew Pinski wrote:
> > +   /* Acceptable.  */
> > +   asm (" "); /* { dg-warning "Deprecated: asm in function without
> > extended syntax" } */
> 
> This is incorrect English.  It should be
> 
> "Deprecated: asm without extended syntax in function"

No diagnostics should start with uppercase letters.

(I also disagree with the deprecation.)

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

[Bug middle-end/71529] [7 regression][CHKP] ICE in expand_expr_real_1

[ienkovich at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71529

--- Comment #3 from Ilya Enkovich  ---
Author: ienkovich
Date: Mon Jun 20 11:35:02 2016
New Revision: 237592

URL: https://gcc.gnu.org/viewcvs?rev=237592=gcc=rev
Log:
gcc/

Backport from mainline r237484.
2016-06-15  Ilya Enkovich  

PR middle-end/71529
* ipa-chkp.c (chkp_build_instrumented_fndecl): Fix
DECL_CONTEXT for copied arguments.

gcc/testsuite/

Backport from mainline r237484.
2016-06-15  Ilya Enkovich  

PR middle-end/71529
* gcc.target/i386/pr71529.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr71529.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-chkp.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/71591] New: SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71591

Bug ID: 71591
   Summary: SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E
-fself-test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Compiler output:
$ echo '' | x86_64-pc-linux-gnu-gcc -E -fself-test -xc -
# 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 ""
cc1: internal compiler error: Segmentation fault
0xbc434f crash_signal
/repo/gcc-trunk/gcc/toplev.c:335
0x1576a3d test_uncond_jump
/repo/gcc-trunk/gcc/rtl-tests.c:90
0x1576fd4 selftest::rtl_tests_c_tests()
/repo/gcc-trunk/gcc/rtl-tests.c:109
0x1536d94 selftest::run_tests()
/repo/gcc-trunk/gcc/selftest-run-tests.c:57
0xbc5979 toplev::run_self_tests()
/repo/gcc-trunk/gcc/toplev.c:2057
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ x86_64-pc-linux-gnu-gcc -v  
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-237587-checking-yes-rtl-df-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-237587-checking-yes-rtl-df-nographite-amd64
Thread model: posix
gcc version 7.0.0 20160620 (experimental) (GCC)

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71092

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jeffbai at aosc dot xyz

--- Comment #8 from ktkachov at gcc dot gnu.org ---
*** Bug 71584 has been marked as a duplicate of this bug. ***

[Bug c++/71584] [6/7 Regression] internal compiler error: in cxx_eval_call_expression

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Having done that, it looks like it's a duplicate...

*** This bug has been marked as a duplicate of bug 71092 ***

[Bug c++/71584] [6/7 Regression] internal compiler error: in cxx_eval_call_expression

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|WAITING |NEW
   Target Milestone|--- |6.2
Summary|Internal Error compiling|[6/7 Regression] internal
   |LMMS on ARM (Endian Little) |compiler error: in
   ||cxx_eval_call_expression
  Known to fail||6.1.0, 7.0

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Thanks, I've confirmed it on arm, aarch64 and x86_64. It looks like a C++
frontend issue. A reduced testcase is:

class QBasicAtomicPointer {
public:
  typedef int *Type;
  constexpr QBasicAtomicPointer(Type);
};
template  class QAtomicPointer : QBasicAtomicPointer {
public:
  constexpr QAtomicPointer(T *value = 0) : QBasicAtomicPointer(value) {}
};

class JobQueue {
  void m_fn1();
  QAtomicPointer m_items[4];
} MixerWorkerThreadglobalJobQueue;
void JobQueue::m_fn1() {
  int *_job;
  m_items[1] = _job;
}

ICEs with just -fdeclone-ctor-dtor and doesn't ICE without.
The backtrace (on GCC 6) is:
MixerWorkerThread.ii:11:7: internal compiler error: in
cxx_eval_call_expression, at cp/constexpr.c:1455
 class JobQueue {
   ^~~~
0x7f2526 cxx_eval_call_expression
$SRC/gcc/cp/constexpr.c:1455
0x7f31a8 cxx_eval_constant_expression
$SRC/gcc/cp/constexpr.c:3563
0x7ee4d4 cxx_eval_outermost_constant_expr
$SRC/gcc/cp/constexpr.c:4128
0x7fa511 maybe_constant_init(tree_node*, tree_node*)
$SRC/gcc/cp/constexpr.c:4445
0x7388ab build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
$SRC/gcc/cp/init.c:4177
0x7d2540 cp_gimplify_expr(tree_node**, gimple**, gimple**)
$SRC/gcc/cp/cp-gimplify.c:594
0xa8064d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
$SRC/gcc/gimplify.c:10201
0xa858e6 gimplify_stmt(tree_node**, gimple**)
$SRC/gcc/gimplify.c:5688
0xa81e20 gimplify_cleanup_point_expr
$SRC/gcc/gimplify.c:5464
0xa81e20 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
$SRC/gcc/gimplify.c:10657
0xa858e6 gimplify_stmt(tree_node**, gimple**)
$SRC/gcc/gimplify.c:5688
0xa8691f gimplify_bind_expr
$SRC/gcc/gimplify.c:1142
0xa81ff0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
$SRC/gcc/gimplify.c:10491
0xa858e6 gimplify_stmt(tree_node**, gimple**)
$SRC/gcc/gimplify.c:5688
0xa81093 gimplify_statement_list
$SRC/gcc/gimplify.c:1537
0xa81093 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
$SRC/gcc/gimplify.c:10709
0xa858e6 gimplify_stmt(tree_node**, gimple**)
$SRC/gcc/gimplify.c:5688
0xa87723 gimplify_body(tree_node*, bool)
$SRC/gcc/gimplify.c:11438
0xa87e56 gimplify_function_tree(tree_node*)
$SRC/gcc/gimplify.c:11594
0x904a87 cgraph_node::analyze()
$SRC/gcc/cgraphunit.c:625
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/71578] [7 Regression] segfault during LTO/PGO bootstrap on ppc64le

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71578

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Markus Trippelsdorf from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Markus Trippelsdorf from comment #2)
> > > Started with r237556:
> > > 
> > > commit 1176073cc1a63f14198c3ba0a02c8f5a52442c2f
> > > Author: marxin 
> > > Date:   Fri Jun 17 14:28:57 2016 +
> > > 
> > > Change PRED_LOOP_EXIT from 92 to 85.
> > 
> > This definitely exposed a latent bug somewhere.
> 
> Yeah. I will try to bisect with PRED_LOOP_EXIT set to 85...

Bisection is impossible because of:
/home/trippels/bin/ld: error:
/home/trippels/gcc_build_dir_/./prev-gcc/libgcov.a(_gcov.o): multiple
definition of '__gcov_error_file'
(I ran "git bisect skip" three times, but I still hit this issue.)

r236761 LTO/PGO bootstrapped fine with PRED_LOOP_EXIT set to 85.

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103

--- Comment #6 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Jun 20 11:20:27 2016
New Revision: 237591

URL: https://gcc.gnu.org/viewcvs?rev=237591=gcc=rev
Log:
gcc/
Backport from 2016-06-20 trunk r237589, r236558.
PR target/71103
* config/avr/avr.md (movqi): Handle loading subreg:qi (const,
symbol_ref,label_ref).

gcc/testsuite/
Backport from 2016-06-20 trunk r237589, r236558.
PR target/71103
* gcc.target/avr/pr71103.c: New test.
* gcc.target/avr/torture/pr71103-2.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71103.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/avr/avr.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

Re: [PATCH v2, PING 1] Allocate constant size dynamic stack space in the prologue

[Dominik Vogt]

On Fri, May 06, 2016 at 10:44:15AM +0100, Dominik Vogt wrote:
> > diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> > index 21f21c9..4d48afd 100644
> > --- a/gcc/cfgexpand.c
> > +++ b/gcc/cfgexpand.c
> ...
> > @@ -1099,8 +1101,10 @@ expand_stack_vars (bool (*pred) (size_t), struct 
> > stack_vars_data *data)
> >  
> >/* If there were any, allocate space.  */
> >if (large_size > 0)
> > -   large_base = allocate_dynamic_stack_space (GEN_INT (large_size), 0,
> > -  large_align, true);
> > +   {
> > + large_allocsize = GEN_INT (large_size);
> > + get_dynamic_stack_size (_allocsize, 0, large_align, NULL);
> ...
> 
> See below.
> 
> > @@ -1186,6 +1190,18 @@ expand_stack_vars (bool (*pred) (size_t), struct 
> > stack_vars_data *data)
> >   /* Large alignment is only processed in the last pass.  */
> >   if (pred)
> > continue;
> > +
> > + if (large_allocsize && ! large_allocation_done)
> > +   {
> > + /* Allocate space the virtual stack vars area in the prologue.
> > +  */
> > + HOST_WIDE_INT loffset;
> > +
> > + loffset = alloc_stack_frame_space (INTVAL (large_allocsize),
> > +PREFERRED_STACK_BOUNDARY);
> 
> 1) Should this use PREFERRED_STACK_BOUNDARY or just STACK_BOUNDARY?
> 2) Is this the right place for rounding up, or should 
>it be done above, maybe in get_dynamic_stack_size?
> 
> Not sure whether this is the right 
> 
> > + large_base = get_dynamic_stack_base (loffset, large_align);
> > + large_allocation_done = true;
> > +   }
> >   gcc_assert (large_base != NULL);
> >  
> >   large_alloc += alignb - 1;
> 
> > diff --git a/gcc/testsuite/gcc.dg/stack-layout-dynamic-1.c 
> > b/gcc/testsuite/gcc.dg/stack-layout-dynamic-1.c
> > new file mode 100644
> > index 000..e06a16c
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/stack-layout-dynamic-1.c
> > @@ -0,0 +1,14 @@
> > +/* Verify that run time aligned local variables are aloocated in the 
> > prologue
> > +   in one pass together with normal local variables.  */
> > +/* { dg-do compile } */
> > +/* { dg-options "-O0" } */
> > +
> > +extern void bar (void *, void *, void *);
> > +void foo (void)
> > +{
> > +  int i;
> > +  __attribute__ ((aligned(65536))) char runtime_aligned_1[512];
> > +  __attribute__ ((aligned(32768))) char runtime_aligned_2[1024];
> > +  bar (, _aligned_1, _aligned_2);
> > +}
> > +/* { dg-final { scan-assembler-times "cfi_def_cfa_offset" 2 { target { 
> > s390*-*-* } } } } */
> 
> I've no idea how to test this on other targets, or how to express
> the test in a target independent way.  The scan-assembler-times
> does not work on x86_64.
> 
> Ciao
> 
> Dominik ^_^  ^_^
> 
> -- 
> 
> Dominik Vogt
> IBM Germany
> 
> 


Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [Patch AArch64] Add some more missing intrinsics

[James Greenhalgh]

On Mon, Jun 13, 2016 at 05:31:40PM +0100, James Greenhalgh wrote:
> 
> Hi,
> 
> Inspired by Jiong's recent work, here are some more missing intrinsics,
> and a smoke test for each of them.
> 
> This patch covers:
> 
>   vcvt_n_f64_s64
>   vcvt_n_f64_u64
>   vcvt_n_s64_f64
>   vcvt_n_u64_f64
>   vcvt_f64_s64
>   vrecpe_f64
>   vcvt_f64_u64
>   vrecps_f64
> 
> Tested on aarch64-none-elf, and on an internal testsuite for Neon
> intrinsics.
> 
> Note that the new tests will ICE without the fixups in
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00805.html
> 
> OK?

*ping*

https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00977.html

Thanks,
James

> gcc/ChangeLog
> 
> 2016-06-10  James Greenhalgh  
> 
>   * config/aarch64/arm_neon.h (vcvt_n_f64_s64): New.
>   (vcvt_n_f64_u64): Likewise.
>   (vcvt_n_s64_f64): Likewise.
>   (vcvt_n_u64_f64): Likewise.
>   (vcvt_f64_s64): Likewise.
>   (vrecpe_f64): Likewise.
>   (vcvt_f64_u64): Likewise.
>   (vrecps_f64): Likewise.
> 
> gcc/testsuite/ChangeLog
> 
> 2016-06-10  James Greenhalgh  
> 
>   * gcc.target/aarch64/vcvt_f64_1.c: New.
>   * gcc.target/aarch64/vcvt_n_f64_1.c: New.
>   * gcc.target/aarch64/vrecp_f64_1.c: New.

Re: [Patch AArch64] Fixup to fcvt patterns added in r237200

[James Greenhalgh]

On Fri, Jun 10, 2016 at 01:29:39PM +0100, James Greenhalgh wrote:
> 
> Hi,
> 
> My autotester picked up some issues with the vcvt{ds}_n_* intrinsics
> added in r237200.
> 
> The iterators in this pattern do not resolve, as they have not been
> explicitly tied to the mode iterator (rather than the code iterator)
> used by the pattern.
> 
> This fixup adds the attribute tags, allowing the patterns to work
> correctly.
> 
> Additionally, the types assigned to these instructions were wrong, and
> would permit the immediate operand to be in a register. This will then
> develop in to an ICE as the patterns require an immediate operand, and so
> won't match. The ICE can be exposed by writing a wrapping function around
> the vcvtd_n_* intrinsics, which forces the immediate operand to a register.
> We have the infrastructure to error to the user rather than ICEing, but it
> needs some different types, which this patch adds.
> 
> I've checked this with an aarch64-none-elf test run, and run it through
> several rounds of my autotester for aarch64-none-elf and
> aarch64_be-none-elf.
> 
> OK?

*ping*

https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00805.html

Thanks,
James

> ---
> 2016-06-10  James Greenhalgh  
> 
>   * config/aarch64/aarch64.md
>   (3): Add attributes to
>   iterators.
>   (3): Likewise.  Correct
>   attributes.
>   * config/aarch64/aarch64-builtins.c
>   (aarch64_types_binop_uss_qualifiers): Delete.
>   (TYPES_BINOP_USS): Likewise.
>   (aarch64_types_binop_sus_qualifiers): Likewise.
>   (TYPES_BINOP_SUS): Likewise.
>   (aarch64_types_fcvt_from_unsigned_qualifiers): New.
>   (TYPES_FCVTIMM_SUS): Likewise.
>   * config/aarch64/aarch64-simd-builtins.def (scvtf): Use SHIFTIMM
>   rather than BINOP.
>   (ucvtf): Use FCVTIMM_SUS rather than BINOP_SUS.
>   (fcvtzs): Use SHIFTIMM rather than BINOP.
>   (fcvtzu): Use SHIFTIMM_USS rather than BINOP_USS.
> 

Re: [AArch64] Give some new costs for Cortex-A57 floating-point operations

[James Greenhalgh]

On Fri, Jun 10, 2016 at 09:29:46AM +0100, James Greenhalgh wrote:
> On Fri, Jun 03, 2016 at 09:35:50AM +0100, James Greenhalgh wrote:
> > 
> > Hi,
> > 
> > This patch rebases the floating-point cost table for Cortex-A57 to be
> > relative to the cost of a floating-point move. This in response to this
> > feedback from Richard Sandiford [2] on Ramana's patch to calls.c [1] from
> > 2014:
> > 
> >   I think this is really a bug in the backend.  The backend is assigning a
> >   cost of COSTS_N_INSNS (3) to a floating-point constant not because the
> >   constant itself is expensive -- it's actually as cheap as a register
> >   in this context -- but because the backend considers floating-point
> >   moves to be 3 times more expensive than cheap integer moves.
> > 
> > The argument is that a move in mode X should be treated with cost
> > COSTS_N_INSNS (1), and other instructions should have a cost relative to
> > that move. For example, in this patch we say that instructions building a
> > floating-point constant are the same cost as a floating-point register to
> > register move. Fixing this fixes the issue Ramana was seeing, in a way
> > consistent with what other back-ends do.
> > 
> > This patch gives a small improvement to Spec2000FP on a Cortex-A57
> > platform.
> > 
> > Bootstrapped on aarch64-none-linux-gnu with no issues.
> > 
> > OK?
> 
> *ping*

*ping^*

https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00251.html

Thanks,
James

> > 2016-06-03  James Greenhalgh  
> > 
> > * config/arm/aarch-cost-tables.h (cortexa57_extra_costs): Make FP
> > costs relative to the cost of a register move.
> > 
> 

[Bug target/71103] avr-gcc crashes with unrecognizable insn error

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103

--- Comment #5 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Jun 20 11:01:13 2016
New Revision: 237589

URL: https://gcc.gnu.org/viewcvs?rev=237589=gcc=rev
Log:
gcc/
PR target/71103
* config/avr/avr.md (movqi): Handle loading subreg:qi (const).

gcc/testsuite/
PR target/71103
* gcc.target/avr/torture/pr71103-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/71588] [4.9/5/6/7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71588

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-20
 CC||jakub at gcc dot gnu.org
Summary|ICE on valid code at -O2|[4.9/5/6/7 Regression] ICE
   |and -O3 on  |on valid code at -O2 and
   |x86_64-linux-gnu: in|-O3 on x86_64-linux-gnu: in
   |execute_todo, at|execute_todo, at
   |passes.c:2009   |passes.c:2009
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Most likely started with my r179279.  Guess easiest would be for builtins that
aren't meant to be const or pure give up on all tree-ssa-strlen.c optimizations
if somebody misattributes them.

[Bug bootstrap/71578] [7 Regression] segfault during LTO/PGO bootstrap on ppc64le

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71578

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Markus Trippelsdorf from comment #2)
> > Started with r237556:
> > 
> > commit 1176073cc1a63f14198c3ba0a02c8f5a52442c2f
> > Author: marxin 
> > Date:   Fri Jun 17 14:28:57 2016 +
> > 
> > Change PRED_LOOP_EXIT from 92 to 85.
> 
> This definitely exposed a latent bug somewhere.

Yeah. I will try to bisect with PRED_LOOP_EXIT set to 85...

Re: [wwwdocs] Describe behavior of -flifetime-dse in class constructors

[Gerald Pfeifer]

On Mon, 20 Jun 2016, Gerald Pfeifer wrote:
> I know a short version of this was applied, but am wondering
> whether to retain the example (and a note on -flifetime-dse=1),
> both per the discussion in February?
> 
> Want to make those enhancements?

And here is one small change I just applied...

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.85
diff -u -r1.85 changes.html
--- changes.html8 Jun 2016 15:00:53 -   1.85
+++ changes.html20 Jun 2016 10:33:35 -
@@ -283,7 +283,7 @@
 -fconcepts.
 -flifetime-dse is more
 aggressive in dead-store elimination in situations where
-a memory store to a location precedes a constructor to the
+a memory store to a location precedes a constructor to that
 memory location.
 G++ now supports
 https://gcc.gnu.org/projects/cxx-status.html#cxx1z.html;>C++17

[Bug c++/71584] Internal Error compiling LMMS on ARM (Endian Little)

[jeffbai at aosc dot xyz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584

--- Comment #4 from Jeff Bai  ---
I compressed the .ii file with tar.xz as the original file is larger than
1000KB.

[Bug c++/71584] Internal Error compiling LMMS on ARM (Endian Little)

[jeffbai at aosc dot xyz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584

--- Comment #3 from Jeff Bai  ---
Created attachment 38730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38730=edit
Temporary .ii file for MixerWorkerThread.cpp (the invoking file)

[Bug c++/71584] Internal Error compiling LMMS on ARM (Endian Little)

[jeffbai at aosc dot xyz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584

--- Comment #2 from Jeff Bai  ---
Here you go.

Re: [wwwdocs] Describe behavior of -flifetime-dse in class constructors

[Gerald Pfeifer]

Hi Martin,

On Wed, 17 Feb 2016, Martin Liška wrote:
> On 02/17/2016 03:23 PM, Jakub Jelinek wrote:
>> "has been" looks weird.  I'd say that the C++ compiler is now more
>> aggressive...
> Sending v3.

I know a short version of this was applied, but am wondering
whether to retain the example (and a note on -flifetime-dse=1),
both per the discussion in February?

Want to make those enhancements?

Gerald

Index: htdocs/gcc-6/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.14
diff --unified -r1.14 porting_to.html
--- htdocs/gcc-6/porting_to.html14 Feb 2016 13:13:43 -  1.14
+++ htdocs/gcc-6/porting_to.html17 Feb 2016 15:00:35 -
@@ -324,6 +324,52 @@
 -fabi-version or -Wabi option to disable or warn about.
 
 
+More aggressive optimization of -flifetime-dse
+
+
+The C++ compiler (with enabled -flifetime-dse)
+is more aggressive in dead-store elimination in situations where
+a memory store to a location precedes a constructor to the
+memory location. Described situation can be commonly found in programs
+which zero a memory that is eventually passed to a placement new operator:
+
+
+#include stdlib.h
+#include string.h
+#include assert.h
+
+struct A
+{
+  A () {}
+  void *operator new (size_t s)
+  {
+void *ptr = malloc (s);
+memset (ptr, 0, s);
+return ptr;
+  }
+
+  int value;
+};
+
+A *
+__attribute__ ((noinline))
+build (void)
+{
+  return new A ();
+}
+
+int main()
+{
+  A *a =  build ();
+  assert (a-value == 0); /* Use of uninitialized value */
+  free (a);
+}
+
+
+If the program cannot be fixed to remove the undefined behavior then
+the option -fno-lifetime-dse can be used to disable
+this optimization.
+
 -Wmisleading-indentation
 
 A new warning -Wmisleading-indentation was added

[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #18 from Jakub Jelinek  ---
Created attachment 38729
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38729=edit
gcc7-pr71559.patch

Untested patch I'm going to bootstrap/regtest then.
The test coverage should cover all the comparisons except of LTGT, and test
there everything but FE_INEXACT, for SSE2, AVX and AVX512F.

RE: [PATCH, fortran, v4] Use Levenshtein spelling suggestions in Fortran FE

[VandeVondele Joost]

From my point of view, would be really nice to have.

Joost

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579

--- Comment #1 from Jonathan Wakely  ---
Your example has undefined behaviour, the requirements in the standard are
requirements on your use of the trait. If you use it wrong it doesn't work.

Re: [PING] [PATCH] c/69507 - bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[Christophe Lyon]

On 4 June 2016 at 23:24, Martin Sebor  wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02216.html
>
>
> On 05/27/2016 11:34 AM, Martin Sebor wrote:
>>
>> The patch below adjusts the C alignof pedantic warning to avoid
>> diagnosing the GCC extension (__alignof__) and only diagnose
>> _Alignof in C99 and prior modes.  This is consistent with how
>> __attribute__ ((aligned)) and _Alignas is handled (among other
>> extensions vs standard features).
>>
>> Martin
>>
>> PR c/69507 - bogus warning: ISO C does not allow ‘__alignof__
>> (expression)’
>>
>> gcc/testsuite/ChangeLog:
>> 2016-05-27  Martin Sebor  
>>
>>  PR c/69507
>>  * gcc.dg/alignof.c: New test.
>>
>> gcc/c/ChangeLog:
>> 2016-05-27  Martin Sebor  
>>
>>  PR c/69507
>>  * c-parser.c (c_parser_alignof_expression): Avoid diagnosing
>>  __alignof__ (expression).
>>

Hi,

Since this patch was committed, I am now seeing failures on:
gcc.dg/gnu99-const-expr-1.c
gcc.dg/gnu99-static-1.c

(targets arm, aarch64, I don't think that it should matter?)

Can you have  a look?

Christophe



>> Index: gcc/c/c-parser.c
>> ===
>> --- gcc/c/c-parser.c(revision 232841)
>> +++ gcc/c/c-parser.c(working copy)
>> @@ -7019,9 +7019,10 @@ c_parser_alignof_expression (c_parser *p
>> mark_exp_read (expr.value);
>> c_inhibit_evaluation_warnings--;
>> in_alignof--;
>> -  pedwarn (start_loc,
>> -   OPT_Wpedantic, "ISO C does not allow %<%E (expression)%>",
>> -   alignof_spelling);
>> +  if (is_c11_alignof)
>> +pedwarn (start_loc,
>> + OPT_Wpedantic, "ISO C does not allow %<%E (expression)%>",
>> + alignof_spelling);
>> ret.value = c_alignof_expr (start_loc, expr.value);
>> ret.original_code = ERROR_MARK;
>> ret.original_type = NULL;
>> Index: gcc/testsuite/gcc.dg/alignof.c
>> ===
>> --- gcc/testsuite/gcc.dg/alignof.c(revision 0)
>> +++ gcc/testsuite/gcc.dg/alignof.c(working copy)
>> @@ -0,0 +1,11 @@
>> +/* PR c/69507 - bogus warning: ISO C does not allow '__alignof__
>> (expression)'
>> + */
>> +/* { dg-do compile } */
>> +/* { dg-options "-std=c11 -Wno-error -Wpedantic" } */
>> +
>> +extern int e;
>> +
>> +int a[] = {
>> +__alignof__ (e),
>> +_Alignof (e)   /* { dg-warning "ISO C does not allow ._Alignof
>> \\(expression\\)." } */
>> +};
>
>

[PATCH 6/6] loop-iv.c: make cond_list a vec

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-06-20  Trevor Saunders  

* loop-iv.c (simplify_using_initial_values): Make cond_list a vector.
---
 gcc/loop-iv.c | 55 ++-
 1 file changed, 18 insertions(+), 37 deletions(-)

diff --git a/gcc/loop-iv.c b/gcc/loop-iv.c
index 57fb8c1..21c3180 100644
--- a/gcc/loop-iv.c
+++ b/gcc/loop-iv.c
@@ -1860,7 +1860,6 @@ simplify_using_initial_values (struct loop *loop, enum 
rtx_code op, rtx *expr)
 {
   bool expression_valid;
   rtx head, tail, last_valid_expr;
-  rtx_expr_list *cond_list;
   rtx_insn *insn;
   rtx neutral, aggr;
   regset altered, this_altered;
@@ -1936,7 +1935,7 @@ simplify_using_initial_values (struct loop *loop, enum 
rtx_code op, rtx *expr)
 
   expression_valid = true;
   last_valid_expr = *expr;
-  cond_list = NULL;
+  auto_vec cond_list;
   while (1)
 {
   insn = BB_END (e->src);
@@ -1952,17 +1951,18 @@ simplify_using_initial_values (struct loop *loop, enum 
rtx_code op, rtx *expr)
  simplify_using_condition (cond, expr, altered);
  if (old != *expr)
{
- rtx note;
  if (CONSTANT_P (*expr))
goto out;
- for (note = cond_list; note; note = XEXP (note, 1))
+
+ unsigned int len = cond_list.length ();
+ for (unsigned int i = len - 1; i < len; i--)
{
- simplify_using_condition (XEXP (note, 0), expr, altered);
+ simplify_using_condition (cond_list[i], expr, altered);
  if (CONSTANT_P (*expr))
goto out;
}
}
- cond_list = alloc_EXPR_LIST (0, cond, cond_list);
+ cond_list.safe_push (cond);
}
}
 
@@ -1988,39 +1988,30 @@ simplify_using_initial_values (struct loop *loop, enum 
rtx_code op, rtx *expr)
 
  if (suitable_set_for_replacement (insn, , ))
{
- rtx_expr_list **pnote, **pnote_next;
-
  replace_in_expr (expr, dest, src);
  if (CONSTANT_P (*expr))
goto out;
 
- for (pnote = _list; *pnote; pnote = pnote_next)
+ unsigned int len = cond_list.length ();
+ for (unsigned int i = len - 1; i < len; i--)
{
- rtx_expr_list *note = *pnote;
- rtx old_cond = XEXP (note, 0);
+ rtx old_cond = cond_list[i];
 
- pnote_next = (rtx_expr_list **) (note, 1);
- replace_in_expr ( (note, 0), dest, src);
+ replace_in_expr (_list[i], dest, src);
 
  /* We can no longer use a condition that has been simplified
 to a constant, and simplify_using_condition will abort if
 we try.  */
- if (CONSTANT_P (XEXP (note, 0)))
-   {
- *pnote = *pnote_next;
- pnote_next = pnote;
- free_EXPR_LIST_node (note);
-   }
+ if (CONSTANT_P (cond_list[i]))
+   cond_list.ordered_remove (i);
  /* Retry simplifications with this condition if either the
 expression or the condition changed.  */
- else if (old_cond != XEXP (note, 0) || old != *expr)
-   simplify_using_condition (XEXP (note, 0), expr, altered);
+ else if (old_cond != cond_list[i] || old != *expr)
+   simplify_using_condition (cond_list[i], expr, altered);
}
}
  else
{
- rtx_expr_list **pnote, **pnote_next;
-
  /* If we did not use this insn to make a replacement, any overlap
 between stores in this insn and our expression will cause the
 expression to become invalid.  */
@@ -2028,19 +2019,10 @@ simplify_using_initial_values (struct loop *loop, enum 
rtx_code op, rtx *expr)
goto out;
 
  /* Likewise for the conditions.  */
- for (pnote = _list; *pnote; pnote = pnote_next)
-   {
- rtx_expr_list *note = *pnote;
- rtx old_cond = XEXP (note, 0);
-
- pnote_next = (rtx_expr_list **) (note, 1);
- if (altered_reg_used (old_cond, this_altered))
-   {
- *pnote = *pnote_next;
- pnote_next = pnote;
- free_EXPR_LIST_node (note);
-   }
-   }
+ unsigned int len = cond_list.length ();
+ for (unsigned int i = len - 1; i < len; i--)
+   if (altered_reg_used (cond_list[i], this_altered))
+ cond_list.ordered_remove (i);
}
 
  if 

[PATCH 1/6] make antic_stores a vec

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-06-20  Trevor Saunders  

* store-motion.c (struct st_expr): Make antic_stores a vector.
(st_expr_entry): Adjust.
(free_st_expr_entry): Likewise.
(print_store_motion_mems): Likewise.
(find_moveable_store): Likewise.
(compute_store_table): Likewise.
(remove_reachable_equiv_notes): Likewise.
(replace_store_insn): Likewise.
(build_store_vectors): Likewise.
---
 gcc/store-motion.c | 54 +-
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/gcc/store-motion.c b/gcc/store-motion.c
index 301b69b..6d7d37f 100644
--- a/gcc/store-motion.c
+++ b/gcc/store-motion.c
@@ -46,7 +46,6 @@ along with GCC; see the file COPYING3.  If not see
  a compile time hog that needs a rewrite (maybe cache st_exprs to
  invalidate REG_EQUAL/REG_EQUIV notes for?).
- pattern_regs in st_expr should be a regset (on its own obstack).
-   - antic_stores and avail_stores should be VECs instead of lists.
- store_motion_mems should be a vec instead of a list.
- there should be an alloc pool for struct st_expr objects.
- investigate whether it is helpful to make the address of an st_expr
@@ -66,7 +65,7 @@ struct st_expr
   /* List of registers mentioned by the mem.  */
   rtx pattern_regs;
   /* INSN list of stores that are locally anticipatable.  */
-  rtx_insn_list *antic_stores;
+  vec antic_stores;
   /* INSN list of stores that are locally available.  */
   vec avail_stores;
   /* Next in the list.  */
@@ -148,7 +147,7 @@ st_expr_entry (rtx x)
   ptr->next = store_motion_mems;
   ptr->pattern  = x;
   ptr->pattern_regs = NULL_RTX;
-  ptr->antic_stores = NULL;
+  ptr->antic_stores.create (0);
   ptr->avail_stores.create (0);
   ptr->reaching_reg = NULL_RTX;
   ptr->index= 0;
@@ -164,8 +163,8 @@ st_expr_entry (rtx x)
 static void
 free_st_expr_entry (struct st_expr * ptr)
 {
-  free_INSN_LIST_list (& ptr->antic_stores);
-   ptr->avail_stores.release ();
+  ptr->antic_stores.release ();
+  ptr->avail_stores.release ();
 
   free (ptr);
 }
@@ -233,11 +232,7 @@ print_store_motion_mems (FILE * file)
   print_rtl (file, ptr->pattern);
 
   fprintf (file, "\nANTIC stores : ");
-
-  if (ptr->antic_stores)
-   print_rtl (file, ptr->antic_stores);
-  else
-   fprintf (file, "(nil)");
+  print_rtx_insn_vec (file, ptr->antic_stores);
 
   fprintf (file, "\nAVAIL stores : ");
 
@@ -566,11 +561,11 @@ find_moveable_store (rtx_insn *insn, int 
*regs_set_before, int *regs_set_after)
   /* Do not check for anticipatability if we either found one anticipatable
  store already, or tested for one and found out that it was killed.  */
   check_anticipatable = 0;
-  if (!ptr->antic_stores)
+  if (ptr->antic_stores.is_empty ())
 check_anticipatable = 1;
   else
 {
-  rtx_insn *tmp = ptr->antic_stores->insn ();
+  rtx_insn *tmp = ptr->antic_stores.last ();
   if (tmp != NULL_RTX
  && BLOCK_FOR_INSN (tmp) != bb)
check_anticipatable = 1;
@@ -582,7 +577,7 @@ find_moveable_store (rtx_insn *insn, int *regs_set_before, 
int *regs_set_after)
tmp = NULL;
   else
tmp = insn;
-  ptr->antic_stores = alloc_INSN_LIST (tmp, ptr->antic_stores);
+  ptr->antic_stores.safe_push (tmp);
 }
 
   /* It is not necessary to check whether store is available if we did
@@ -683,9 +678,9 @@ compute_store_table (void)
   for (ptr = first_st_expr (); ptr != NULL; ptr = next_st_expr (ptr))
{
  LAST_AVAIL_CHECK_FAILURE (ptr) = NULL_RTX;
- if (ptr->antic_stores
- && (tmp = ptr->antic_stores->insn ()) == NULL_RTX)
-   ptr->antic_stores = ptr->antic_stores->next ();
+ if (!ptr->antic_stores.is_empty ()
+ && (tmp = ptr->antic_stores.last ()) == NULL)
+   ptr->antic_stores.pop ();
}
 }
 
@@ -831,7 +826,7 @@ remove_reachable_equiv_notes (basic_block bb, struct 
st_expr *smexpr)
   int sp;
   edge act;
   sbitmap visited = sbitmap_alloc (last_basic_block_for_fn (cfun));
-  rtx last, note;
+  rtx note;
   rtx_insn *insn;
   rtx mem = smexpr->pattern;
 
@@ -866,13 +861,13 @@ remove_reachable_equiv_notes (basic_block bb, struct 
st_expr *smexpr)
}
   bitmap_set_bit (visited, bb->index);
 
+  rtx_insn *last;
   if (bitmap_bit_p (st_antloc[bb->index], smexpr->index))
{
- for (last = smexpr->antic_stores;
-  BLOCK_FOR_INSN (XEXP (last, 0)) != bb;
-  last = XEXP (last, 1))
-   continue;
- last = XEXP (last, 0);
+ unsigned int i;
+ FOR_EACH_VEC_ELT_REVERSE (smexpr->antic_stores, i, last)
+   if (BLOCK_FOR_INSN (last) == bb)
+ break;
}
   else
last = NEXT_INSN (BB_END (bb));
@@ -911,15 +906,17 @@ 

[PATCH 5/6] make pattern_regs a vec

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-06-20  Trevor Saunders  

* store-motion.c (struct st_expr): Make pattern_regs a vector.
(st_expr_entry): Adjust.
(store_ops_ok): Likewise.
(extract_mentioned_regs): Likewise.
(store_killed_in_insn): Likewise.
(find_moveable_store): Likewise.
---
 gcc/store-motion.c | 49 +++--
 1 file changed, 23 insertions(+), 26 deletions(-)

diff --git a/gcc/store-motion.c b/gcc/store-motion.c
index 6d7d37f..c2ef0d0 100644
--- a/gcc/store-motion.c
+++ b/gcc/store-motion.c
@@ -63,7 +63,7 @@ struct st_expr
   /* Pattern of this mem.  */
   rtx pattern;
   /* List of registers mentioned by the mem.  */
-  rtx pattern_regs;
+  vec pattern_regs;
   /* INSN list of stores that are locally anticipatable.  */
   vec antic_stores;
   /* INSN list of stores that are locally available.  */
@@ -146,7 +146,7 @@ st_expr_entry (rtx x)
 
   ptr->next = store_motion_mems;
   ptr->pattern  = x;
-  ptr->pattern_regs = NULL_RTX;
+  ptr->pattern_regs.create (0);
   ptr->antic_stores.create (0);
   ptr->avail_stores.create (0);
   ptr->reaching_reg = NULL_RTX;
@@ -248,16 +248,12 @@ print_store_motion_mems (FILE * file)
due to set of registers in bitmap REGS_SET.  */
 
 static bool
-store_ops_ok (const_rtx x, int *regs_set)
+store_ops_ok (const vec , int *regs_set)
 {
-  const_rtx reg;
-
-  for (; x; x = XEXP (x, 1))
-{
-  reg = XEXP (x, 0);
-  if (regs_set[REGNO (reg)])
-   return false;
-}
+  unsigned int len = x.length ();
+  for (unsigned int i = 0; i < len; i++)
+if (regs_set[REGNO (x[i])])
+  return false;
 
   return true;
 }
@@ -265,18 +261,16 @@ store_ops_ok (const_rtx x, int *regs_set)
 /* Returns a list of registers mentioned in X.
FIXME: A regset would be prettier and less expensive.  */
 
-static rtx_expr_list *
-extract_mentioned_regs (rtx x)
+static void
+extract_mentioned_regs (rtx x, vec *mentioned_regs)
 {
-  rtx_expr_list *mentioned_regs = NULL;
   subrtx_var_iterator::array_type array;
   FOR_EACH_SUBRTX_VAR (iter, array, x, NONCONST)
 {
   rtx x = *iter;
   if (REG_P (x))
-   mentioned_regs = alloc_EXPR_LIST (0, x, mentioned_regs);
+   mentioned_regs->safe_push (x);
 }
-  return mentioned_regs;
 }
 
 /* Check to see if the load X is aliased with STORE_PATTERN.
@@ -373,9 +367,10 @@ store_killed_in_pat (const_rtx x, const_rtx pat, int after)
after the insn.  Return true if it does.  */
 
 static bool
-store_killed_in_insn (const_rtx x, const_rtx x_regs, const rtx_insn *insn, int 
after)
+store_killed_in_insn (const_rtx x, const vec _regs,
+ const rtx_insn *insn, int after)
 {
-  const_rtx reg, note, pat;
+  const_rtx note, pat;
 
   if (! NONDEBUG_INSN_P (insn))
 return false;
@@ -389,8 +384,9 @@ store_killed_in_insn (const_rtx x, const_rtx x_regs, const 
rtx_insn *insn, int a
 
   /* But even a const call reads its parameters.  Check whether the
 base of some of registers used in mem is stack pointer.  */
-  for (reg = x_regs; reg; reg = XEXP (reg, 1))
-   if (may_be_sp_based_p (XEXP (reg, 0)))
+  unsigned int len = x_regs.length ();
+  for (unsigned int i = 0; i < len; i++)
+   if (may_be_sp_based_p (x_regs[i]))
  return true;
 
   return false;
@@ -435,8 +431,8 @@ store_killed_in_insn (const_rtx x, const_rtx x_regs, const 
rtx_insn *insn, int a
is killed, return the last insn in that it occurs in FAIL_INSN.  */
 
 static bool
-store_killed_after (const_rtx x, const_rtx x_regs, const rtx_insn *insn,
-   const_basic_block bb,
+store_killed_after (const_rtx x, const vec _regs,
+   const rtx_insn *insn, const_basic_block bb,
int *regs_set_after, rtx *fail_insn)
 {
   rtx_insn *last = BB_END (bb), *act;
@@ -465,8 +461,9 @@ store_killed_after (const_rtx x, const_rtx x_regs, const 
rtx_insn *insn,
within basic block BB. X_REGS is list of registers mentioned in X.
REGS_SET_BEFORE is bitmap of registers set before or in this insn.  */
 static bool
-store_killed_before (const_rtx x, const_rtx x_regs, const rtx_insn *insn,
-const_basic_block bb, int *regs_set_before)
+store_killed_before (const_rtx x, const vec _regs,
+const rtx_insn *insn, const_basic_block bb,
+int *regs_set_before)
 {
   rtx_insn *first = BB_HEAD (bb);
 
@@ -555,8 +552,8 @@ find_moveable_store (rtx_insn *insn, int *regs_set_before, 
int *regs_set_after)
 return;
 
   ptr = st_expr_entry (dest);
-  if (!ptr->pattern_regs)
-ptr->pattern_regs = extract_mentioned_regs (dest);
+  if (ptr->pattern_regs.is_empty ())
+extract_mentioned_regs (dest, >pattern_regs);
 
   /* Do not check for anticipatability if we either found one anticipatable
  store already, or tested for one and found out that it was 

[PATCH 4/6] make side_effects a vec

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-06-20  Trevor Saunders  

* var-tracking.c (struct adjust_mem_data): Make side_effects a vector.
(adjust_mems): Adjust.
(adjust_insn): Likewise.
(prepare_call_arguments): Likewise.
---
 gcc/var-tracking.c | 33 ++---
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 9f09d30..5d09879 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -926,7 +926,7 @@ struct adjust_mem_data
   bool store;
   machine_mode mem_mode;
   HOST_WIDE_INT stack_adjust;
-  rtx_expr_list *side_effects;
+  auto_vec side_effects;
 };
 
 /* Helper for adjust_mems.  Return true if X is suitable for
@@ -1072,9 +1072,7 @@ adjust_mems (rtx loc, const_rtx old_rtx, void *data)
   amd->store = false;
   tem = simplify_replace_fn_rtx (tem, old_rtx, adjust_mems, data);
   amd->store = store_save;
-  amd->side_effects = alloc_EXPR_LIST (0,
-  gen_rtx_SET (XEXP (loc, 0), tem),
-  amd->side_effects);
+  amd->side_effects.safe_push (gen_rtx_SET (XEXP (loc, 0), tem));
   return addr;
 case PRE_MODIFY:
   addr = XEXP (loc, 1);
@@ -1088,9 +1086,7 @@ adjust_mems (rtx loc, const_rtx old_rtx, void *data)
   tem = simplify_replace_fn_rtx (XEXP (loc, 1), old_rtx,
 adjust_mems, data);
   amd->store = store_save;
-  amd->side_effects = alloc_EXPR_LIST (0,
-  gen_rtx_SET (XEXP (loc, 0), tem),
-  amd->side_effects);
+  amd->side_effects.safe_push (gen_rtx_SET (XEXP (loc, 0), tem));
   return addr;
 case SUBREG:
   /* First try without delegitimization of whole MEMs and
@@ -1184,7 +1180,6 @@ adjust_mem_stores (rtx loc, const_rtx expr, void *data)
 static void
 adjust_insn (basic_block bb, rtx_insn *insn)
 {
-  struct adjust_mem_data amd;
   rtx set;
 
 #ifdef HAVE_window_save
@@ -1213,9 +1208,9 @@ adjust_insn (basic_block bb, rtx_insn *insn)
 }
 #endif
 
+  adjust_mem_data amd;
   amd.mem_mode = VOIDmode;
   amd.stack_adjust = -VTI (bb)->out.stack_adjust;
-  amd.side_effects = NULL;
 
   amd.store = true;
   note_stores (PATTERN (insn), adjust_mem_stores, );
@@ -1281,10 +1276,10 @@ adjust_insn (basic_block bb, rtx_insn *insn)
validate_change (NULL_RTX, _SRC (set), XEXP (note, 0), true);
 }
 
-  if (amd.side_effects)
+  if (!amd.side_effects.is_empty ())
 {
-  rtx *pat, new_pat, s;
-  int i, oldn, newn;
+  rtx *pat, new_pat;
+  int i, oldn;
 
   pat =  (insn);
   if (GET_CODE (*pat) == COND_EXEC)
@@ -1293,17 +1288,18 @@ adjust_insn (basic_block bb, rtx_insn *insn)
oldn = XVECLEN (*pat, 0);
   else
oldn = 1;
-  for (s = amd.side_effects, newn = 0; s; newn++)
-   s = XEXP (s, 1);
+  unsigned int newn = amd.side_effects.length ();
   new_pat = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (oldn + newn));
   if (GET_CODE (*pat) == PARALLEL)
for (i = 0; i < oldn; i++)
  XVECEXP (new_pat, 0, i) = XVECEXP (*pat, 0, i);
   else
XVECEXP (new_pat, 0, 0) = *pat;
-  for (s = amd.side_effects, i = oldn; i < oldn + newn; i++, s = XEXP (s, 
1))
-   XVECEXP (new_pat, 0, i) = XEXP (s, 0);
-  free_EXPR_LIST_list (_effects);
+
+  rtx effect;
+  unsigned int j;
+  FOR_EACH_VEC_ELT_REVERSE (amd.side_effects, j, effect)
+   XVECEXP (new_pat, 0, j + oldn) = effect;
   validate_change (NULL_RTX, pat, new_pat, true);
 }
 }
@@ -6335,11 +6331,10 @@ prepare_call_arguments (basic_block bb, rtx_insn *insn)
struct adjust_mem_data amd;
amd.mem_mode = VOIDmode;
amd.stack_adjust = -VTI (bb)->out.stack_adjust;
-   amd.side_effects = NULL;
amd.store = true;
mem = simplify_replace_fn_rtx (mem, NULL_RTX, adjust_mems,
   );
-   gcc_assert (amd.side_effects == NULL_RTX);
+   gcc_assert (amd.side_effects.is_empty ());
  }
val = cselib_lookup (mem, GET_MODE (mem), 0, VOIDmode);
if (val && cselib_preserved_value_p (val))
-- 
2.7.4

[PATCH 0/6] remove some usage of rtx_{insn,expr}_list

[tbsaunde+gcc]

From: Trevor Saunders 

Hi,

These few patches to get rid of rtx insn and expr lists should be pretty un
controvertial.  In each case the list is clearly used as a stack and using a
vec as a stack is clearly the same.

In theory I would expect if anything this helps performance since it isn't
necessary to malloc every time a node is added, however the data is less clear.
Here are times for O2 and O0 for fold-const.ii from gcc, and
Unified_js_src_cpp_32.ii from Spider Monkey.  These are best of 3 based on user
time.

fold const O2 new
real0m5.034s
user0m3.408s
sys 0m0.364s

fold const O2 old
real0m4.012s
user0m3.420s
sys 0m0.340s

fold const O0 new
real0m1.637s
user0m1.124s
sys 0m0.280s

fold const O0 old
real0m2.483s
user0m1.092s
sys 0m0.280s

mozjs O2 new
real0m15.565s
user0m12.420s
sys 0m1.536s

mozjs O2 old
real0m13.662s
user0m12.136s
sys 0m1.440s

mozjs O0 new
real0m9.860s
user0m6.796s
sys 0m1.368s

mozjs O0 old
real0m8.922s
user0m6.888s
sys 0m1.388s

So a couple got about .3s slower, and others got about .1 faster, I'm not
really sure but inclined to say any change is too small to easily measure.

bootstrapped + regtested patches individually on x86_64-linux-gnu, ok?

Trev

Trevor Saunders (6):
  make antic_stores a vec
  remove unused loads rtx_insn_list
  make stores rtx_insn_list a vec
  make side_effects a vec
  make pattern_regs a vec
  loop-iv.c: make cond_list a vec

 gcc/gcse.c |  36 ++-
 gcc/loop-iv.c  |  55 ++--
 gcc/store-motion.c | 103 +
 gcc/var-tracking.c |  33 -
 4 files changed, 90 insertions(+), 137 deletions(-)

-- 
2.7.4

[PATCH 3/6] make stores rtx_insn_list a vec

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-06-20  Trevor Saunders  

* gcse.c (struct ls_expr): Make stores field a vector.
(ldst_entry): Adjust.
(free_ldst_entry): Likewise.
(print_ldst_list): Likewise.
(compute_ld_motion_mems): Likewise.
(update_ld_motion_stores): Likewise.
---
 gcc/gcse.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/gcc/gcse.c b/gcc/gcse.c
index 127a65a..49534f2 100644
--- a/gcc/gcse.c
+++ b/gcc/gcse.c
@@ -143,6 +143,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "df.h"
 #include "tm_p.h"
 #include "insn-config.h"
+#include "print-rtl.h"
 #include "regs.h"
 #include "ira.h"
 #include "recog.h"
@@ -342,7 +343,7 @@ struct ls_expr
   struct gcse_expr * expr; /* Gcse expression reference for LM.  */
   rtx pattern; /* Pattern of this mem.  */
   rtx pattern_regs;/* List of registers mentioned by the mem.  */
-  rtx_insn_list *stores;   /* INSN list of stores seen.  */
+  vec stores;  /* INSN list of stores seen.  */
   struct ls_expr * next;   /* Next in the list.  */
   int invalid; /* Invalid for some reason.  */
   int index;   /* If it maps to a bitmap index.  */
@@ -3604,7 +3605,7 @@ ldst_entry (rtx x)
   ptr->expr = NULL;
   ptr->pattern  = x;
   ptr->pattern_regs = NULL_RTX;
-  ptr->stores   = NULL;
+  ptr->stores.create (0);
   ptr->reaching_reg = NULL_RTX;
   ptr->invalid  = 0;
   ptr->index= 0;
@@ -3620,7 +3621,7 @@ ldst_entry (rtx x)
 static void
 free_ldst_entry (struct ls_expr * ptr)
 {
-  free_INSN_LIST_list (& ptr->stores);
+  ptr->stores.release ();
 
   free (ptr);
 }
@@ -3661,11 +3662,7 @@ print_ldst_list (FILE * file)
   print_rtl (file, ptr->pattern);
 
   fprintf (file, "\n   Stores : ");
-
-  if (ptr->stores)
-   print_rtl (file, ptr->stores);
-  else
-   fprintf (file, "(nil)");
+  print_rtx_insn_vec (file, ptr->stores);
 
   fprintf (file, "\n\n");
 }
@@ -3822,7 +3819,7 @@ compute_ld_motion_mems (void)
 returns 0 for all REGs.  */
  && can_assign_to_reg_without_clobbers_p (src,
src_mode))
-   ptr->stores = alloc_INSN_LIST (insn, ptr->stores);
+   ptr->stores.safe_push (insn);
  else
ptr->invalid = 1;
}
@@ -3915,11 +3912,10 @@ update_ld_motion_stores (struct gcse_expr * expr)
 where reg is the reaching reg used in the load.  We checked in
 compute_ld_motion_mems that we can replace (set mem expr) with
 (set reg expr) in that insn.  */
-  rtx list = mem_ptr->stores;
-
-  for ( ; list != NULL_RTX; list = XEXP (list, 1))
+  rtx_insn *insn;
+  unsigned int i;
+  FOR_EACH_VEC_ELT_REVERSE (mem_ptr->stores, i, insn)
{
- rtx_insn *insn = as_a  (XEXP (list, 0));
  rtx pat = PATTERN (insn);
  rtx src = SET_SRC (pat);
  rtx reg = expr->reaching_reg;
-- 
2.7.4

[PATCH 2/6] remove unused loads rtx_insn_list

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-06-20  Trevor Saunders  

* gcse.c (struct ls_expr): Remove loads field.
(ldst_entry): Adjust.
(free_ldst_entry): Likewise.
(print_ldst_list): Likewise.
(compute_ld_motion_mems): Likewise.
---
 gcc/gcse.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/gcc/gcse.c b/gcc/gcse.c
index a3a7dc3..127a65a 100644
--- a/gcc/gcse.c
+++ b/gcc/gcse.c
@@ -342,7 +342,6 @@ struct ls_expr
   struct gcse_expr * expr; /* Gcse expression reference for LM.  */
   rtx pattern; /* Pattern of this mem.  */
   rtx pattern_regs;/* List of registers mentioned by the mem.  */
-  rtx_insn_list *loads;/* INSN list of loads seen.  */
   rtx_insn_list *stores;   /* INSN list of stores seen.  */
   struct ls_expr * next;   /* Next in the list.  */
   int invalid; /* Invalid for some reason.  */
@@ -3605,7 +3604,6 @@ ldst_entry (rtx x)
   ptr->expr = NULL;
   ptr->pattern  = x;
   ptr->pattern_regs = NULL_RTX;
-  ptr->loads= NULL;
   ptr->stores   = NULL;
   ptr->reaching_reg = NULL_RTX;
   ptr->invalid  = 0;
@@ -3622,7 +3620,6 @@ ldst_entry (rtx x)
 static void
 free_ldst_entry (struct ls_expr * ptr)
 {
-  free_INSN_LIST_list (& ptr->loads);
   free_INSN_LIST_list (& ptr->stores);
 
   free (ptr);
@@ -3663,13 +3660,6 @@ print_ldst_list (FILE * file)
 
   print_rtl (file, ptr->pattern);
 
-  fprintf (file, "\nLoads : ");
-
-  if (ptr->loads)
-   print_rtl (file, ptr->loads);
-  else
-   fprintf (file, "(nil)");
-
   fprintf (file, "\n   Stores : ");
 
   if (ptr->stores)
@@ -3801,9 +3791,7 @@ compute_ld_motion_mems (void)
  if (MEM_P (src) && simple_mem (src))
{
  ptr = ldst_entry (src);
- if (REG_P (dest))
-   ptr->loads = alloc_INSN_LIST (insn, ptr->loads);
- else
+ if (!REG_P (dest))
ptr->invalid = 1;
}
  else
-- 
2.7.4

[Bug c++/71584] Internal Error compiling LMMS on ARM (Endian Little)

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-06-20
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Please attache a preprocessed file that causes the crash (that's the .i or .ii
file that you can get by adding --save-temps to the compiler invocation)

[Bug sanitizer/67865] ASAN crashes on thread creation

[dominik.stras...@onespin-solutions.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67865

dominik.stras...@onespin-solutions.com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from dominik.stras...@onespin-solutions.com ---
Works fine with GCC 6.1, let's forget about this issue.

[Bug c++/71590] New: G++ template function initialize with wrong type

[markowitz73 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71590

Bug ID: 71590
   Summary: G++ template function initialize with wrong type
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markowitz73 at gmail dot com
  Target Milestone: ---

The source code is as below:

//source start
#include 
template 
std::string func(T a, int b) {
std::string x;
int y;
if (b == 1) {
x = a;
} else if (b == 2) {
y = a;
}

return x;
}

int main() {
std::string c = func(1, 1);   
return 0;
}
//source ends

this file got compiled successfully. Since there is no overload operator=(int)
version for std::string, so I think that I may came across with a bug.

Anything maybe useful:
I tried to output the std::string object which was assigned by an integer, it
shows
that the string was initialized by a char(the first argument 1 was treated as a
char), and the output is ASCII represented by that integer.

Compile Option:
g++ -o source.cpp main

Compiler Info:
g++ -v shows:Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)

[PATCH][typo] alignement -> alignment

[Kyrill Tkachov]

Hi all,

Committing the attached typo fix as obvious (I believe "alignement" is the 
French form).

Thanks,
Kyrill

2016-06-20  Kyrylo Tkachov  

* params.def (PARAM_ALIGN_LOOP_ITERATIONS): Use "alignment" instead of
"alignement".
* tree.h (TYPE_ALIGN): Likewise.

2016-06-20  Kyrylo Tkachov  

* exp_util.adb (Safe_Unchecked_Type_Conversion): Use "alignment"
instead of "alignement".

2016-06-20  Kyrylo Tkachov  

* gfortran.dg/common_align_2.f90: Use "alignment" instead of
"alignement".
diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb
index fcd16a26cb0126113616534f3e81926d0b1a2a83..bed9ac1641d2fa6144e6c34e790a9bd8c059e60f 100644
--- a/gcc/ada/exp_util.adb
+++ b/gcc/ada/exp_util.adb
@@ -8645,7 +8645,7 @@ package body Exp_Util is
   --  alignment is known to be at least the maximum alignment for the
   --  target or if both alignments are known and the output type's
   --  alignment is no stricter than the input's. We can use the component
-  --  type alignement for an array if a type is an unpacked array type.
+  --  type alignment for an array if a type is an unpacked array type.
 
   if Present (Alignment_Clause (Otyp)) then
  Oalign := Expr_Value (Expression (Alignment_Clause (Otyp)));
diff --git a/gcc/params.def b/gcc/params.def
index a8630463eb84bb2a71354794971ea189e4901870..62ec600ba3c88dde78150fae63591e0855e93752 100644
--- a/gcc/params.def
+++ b/gcc/params.def
@@ -405,7 +405,7 @@ DEFPARAM (PARAM_ALIGN_THRESHOLD,
 
 DEFPARAM (PARAM_ALIGN_LOOP_ITERATIONS,
 	  "align-loop-iterations",
-	  "Loops iterating at least selected number of iterations will get loop alignement..",
+	  "Loops iterating at least selected number of iterations will get loop alignment..",
 	  4, 0, 0)
 
 /* For guessed profiles, the loops having unknown number of iterations
diff --git a/gcc/testsuite/gfortran.dg/common_align_2.f90 b/gcc/testsuite/gfortran.dg/common_align_2.f90
index 09dd3e1fa0a4880333964db6e9d0d7582fbff44d..66b10e6ea9dd5bc12c3278bee7750a9efe83c855 100644
--- a/gcc/testsuite/gfortran.dg/common_align_2.f90
+++ b/gcc/testsuite/gfortran.dg/common_align_2.f90
@@ -1,6 +1,6 @@
 ! { dg-do run }
 ! { dg-options "-pedantic-errors -mdalign" { target sh*-*-* } }
-! Tests the fix for PR37614, in which the alignement of commons followed
+! Tests the fix for PR37614, in which the alignment of commons followed
 ! g77 rather than the standard or other compilers.
 !
 ! Contributed by Tobias Burnus  
diff --git a/gcc/tree.h b/gcc/tree.h
index 90413fcf2090043619e8bf190c11c066f63caa74..012fa542cf302b6668485e16ae9c7602660bc24a 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -1868,7 +1868,7 @@ extern machine_mode element_mode (const_tree t);
 
 /* The alignment necessary for objects of this type.
The value is an int, measured in bits and must be a power of two.
-   We support also an "alignement" of zero.  */
+   We support also an "alignment" of zero.  */
 #define TYPE_ALIGN(NODE) \
 (TYPE_CHECK (NODE)->type_common.align \
  ? ((unsigned)1) << ((NODE)->type_common.align - 1) : 0)

[Bug fortran/71194] ICE on compilation with fcheck=all ; -fcheck=bounds

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71194

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-20
 CC||burnus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
The problem on GCC source level is in gfc_trans_pointer_assignment
(trans-expr.c):

  7936tmp = gfc_create_var (tmp, "ptrtemp");
  7937lse.descriptor_only = 0;
  7938lse.expr = tmp;
  7939lse.direct_byref = 1;
  7940gfc_conv_expr_descriptor (, expr2);

where lse.expr == NULL_TREE after that call.

Looking at the dump (and the source below), w/o bound checking, a "ptrtemp" is
generated and passed to the function:
   conv2real (, D.3483);

If one traces the -fcheck=bound case, the gfc_conv_expr_descriptor call leads
to a call to gfc_conv_procedure_call, which does:

if (byref)
...
  /* Add the function call to the pre chain.  There is no expression.  */
  gfc_add_expr_to_block (>pre, se->expr);
  se->expr = NULL_TREE;

Hence, lse.expr == NULL_TREE, which fails later on.

[Side note: If one sets lse.direct_byref  to 0, it compiles as code following
immediately after the NULL_TREE sets se->expr and, hence, lse.expr again, but
as "conv2real" is called with "atmp", looking at "ptrtemp" will lead to
randomly wrong results.]