date:20140520

On Mon, May 19, 2014 at 5:51 PM, Michael Matz m...@suse.de wrote:
 Hi,

 On Thu, 15 May 2014, Richard Biener wrote:

 To me predicate (and capture without expression or predicate)
 differs from expression in that predicate is clearly a leaf of the
 expression tree while we have to recurse into expression operands.

 Now, if we want to support applying predicates to the midst of an
 expression, like

 (plus predicate(minus @0 @1)
 @2)
 (...)

 then this would no longer be true.  At the moment you'd write

 (plus (minus@3 @0 @1)
 @2)
   if (predicate (@3))
 (...)

 which makes it clearer IMHO (with the decision tree building
 you'd apply the predicates after matching the expression tree
 anyway I suppose, so code generation would be equivalent).

 Syntaxwise I had this idea for adding generic predicates to expressions:

 (plus (minus @0 @1):predicate
   @2)
 (...)

So you'd write

 (plus @0 :integer_zerop)

instead of

 (plus @0 integer_zerop)

?

 If prefix or suffix doesn't matter much, but using a different syntax
 to separate expression from predicate seems to make things clearer.
 Optionally adding things like and/or for predicates might also make sense:

 (plus (minus @0 @1):positive_p(@0) || positive_p(@1)
   @2)
 (...)

negation whould be more useful I guess.  You open up a can of
worms with ordering though:

(plus (minus @0 @1) @2:operand_equal_p (@1, @2, 0))

which might be declared invalid or is equivalent to

(plus (minus @0 @1) @2):operand_equal_p (@1, @2, 0)

?

Note that your predicate placement doesn't match placement of
captures for non-innermost expressions.  capturing the outer
plus would be

(plus@3 (minus @0 @1) @2)

not

(plus (minus @0 @1) @2)@3

so maybe apply predicates there as well:

(plus:operand_equal_p (@1, @2, 0) (minus @0 @1)  @2)

But I still think that doing all predicates within a if-expr makes
the pattern less convoluted.

Enabling/disabling a whole set of patterns with a common condition
might still be a worthwhile addition.

Richard.


 Ciao,
 Michael.

Re: [GSoC] first phase

On Mon, May 19, 2014 at 7:30 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
 Hi,
Unfortunately I shall need to take this week off, due to university exams,
 which are up-to 27th May. I will start working from 28th on pattern
 matching with decision tree, and try to cover up for the first week. I
 am extremely sorry about this.
 I thought I would be able to do both during exam week, but the exam
 load has become too much -:(

Ok.

 In the first phase (up-to 23rd June), I hope to get genmatch ready:
 a) pattern matching with decision tree.
 b) Add patterns to test genmatch.
 c) Depending upon the patterns, extending the meta-description
 d) Other fixes:

 * capturing outermost expressions.
 For example this pattern does not get simplified
 (match_and_simplify
   (plus@2 (negate @0) @1)
   if (!TYPE_SATURATING (TREE_TYPE (@2)))
   (minus @1 @0))
 I guess this happens because in write_nary_simplifiers:
   if (s-match-type != OP_EXPR)
 continue;

Yeah.

 Maybe this is not correct way to fix this, should we also pass lhs to
 generated gimple_match_and_simplify ? I guess that would be the capture
 for outermost expression.

Unfortunately it is not available for all API entries.  The type of the
expression is, though.

I lean towards rejecting the capture at parsing time and providing
a special capture (for example @@, or just @0, or @T to denote
it's a type, or just refer magically to 'type').  That is,

(match_and_simplify
  (plus (negate @0) @1)
  if (!TYPE_SATURATING (type))
  (minus @1 @0))

works for me.

 For above pattern, I guess @2 represents lhs.

 So for this test-case:
 int foo (int x, int y)
 {
   int t1 = -x;
   int t2 = t1 + y;
   return t2;
 }
 t2 would be @2, t1 would be @0 and y would be @1.
 Is that correct ?
 This would create issues when lhs is NULL, for example,
 in call to built-in functions ?

Yeah, or if the machinery is called via gimple_build () where
there is no existing lhs.

 * avoid using statement expressions for code gen of expression
 * rewriting code-generator using visitor classes, and other refactoring
 (using std::string for example), etc.

 I have a very rough time-line in mind, for completing tasks:
 28th may - 31st may
 a) Have test-case for each pattern present (except COND_EXPR) in match.pd
 I guess most of it is already done, a few patterns are remaining.

Good.

 b) Small fixes (for example, those mentioned above).

Good.

 c) Have an initial idea/prototype for implementing decision tree

 1st June - 15th June
 a) Implementing decision tree
 b) Adding patterns in match.pd to test the decision tree in match.pd,
 and accompanying test-cases in tree-ssa/match-*.c

 16th June - 23rd June
 a) Support for GENERIC code generation.
 b) Refactoring and backup time for backlog.

 GENERIC code generation:
 I am a bit confused about this. Currently, pattern matching is
 implemented for GENERIC. However I believe simplification is done on
 GIMPLE.
 For example:
 (match_and_simplify
   (plus (negate @0) @1)
   (minus @0 @1))
 If given input is GENERIC , it would do matching on GENERIC, but shall
 transform (minus @0 @1) to it's GIMPLE equivalent.
 Is that correct ?

Correct.  Err, not sure what it will do - I implemented it only to support
the weird cases where GENERIC is nested inside GIMPLE, like for
a_2 = b_3  0 ? c_4 : d_5;  thus the comment in match.pd:

/* Due to COND_EXPRs weirdness in GIMPLE the following won't work
   without some hacks in the code generator.  */
(match_and_simplify
  (cond (bit_not @0) @1 @2)
  (cond @0 @2 @1))

the code generator would need to know that COND_EXPR has
a GENERIC op0 ... same applies to REALPART_EXPR, but there
the hacks are already in place ;)


 * Should we have a separate GENERIC match-and-simplify API like for gimple
 instead of having GENERIC matching in gimple_match_and_simplify ?

Yes.  The GENERIC API follows the API of fold_{unary,binary,ternary}.
I suppose we simply provide a slightly different name for them
(but use the original API for recursing and call ourselves from the original
API).

 * Do we add another pattern type, something like
 generic_match_and_simplify that will do the transform on GENERIC
 for example:
 (generic_match_and_simplify
   (plus (negate @0) @1)
   (minus @0 @1))
 would produce GENERIC equivalent of (minus @0 @1).

 or maybe keep match_and_simplify, and tell the transform operand
 to produce GENERIC.
 Something like:
 (match_and_simplify
   (plus (negate @0) @1)
   GENERIC: (minus @0 @1))

we simply process each pattern twice, once we generate the
GIMPLE match-and-simplify routine and once we generate the
GENERIC match-and-simplify routine.  The patterns are supposed
to be the same for both and always apply to both.

 Another thing I would like to do in first phase is figure out dependencies
 of tree-ssa-forwprop on GENERIC folding (for instance fold_comparison 
 patterns).

Yeah.  Having patterns for comparison simplification is important for
other parts of the compiler as well, thus

Re: [GSoC] writing test-case

2014-05-20 Thread Michael Matz

Hi,

On Tue, 20 May 2014, Richard Biener wrote:

  Syntaxwise I had this idea for adding generic predicates to expressions:
 
  (plus (minus @0 @1):predicate
@2)
  (...)
 
 So you'd write
 
  (plus @0 :integer_zerop)
 
 instead of
 
  (plus @0 integer_zerop)
 
 ?

plus is binary, where is your @1?  If you want to not capture the second 
operand but still have it tested for a predicates, then yes, the first 
form it would be.

 
  If prefix or suffix doesn't matter much, but using a different syntax
  to separate expression from predicate seems to make things clearer.
  Optionally adding things like and/or for predicates might also make sense:
 
  (plus (minus @0 @1):positive_p(@0) || positive_p(@1)
@2)
  (...)
 
 negation whould be more useful I guess.  You open up a can of
 worms with ordering though:
 
 (plus (minus @0 @1) @2:operand_equal_p (@1, @2, 0))
 
 which might be declared invalid or is equivalent to

It wouldn't necessarily be invalid, the predicate would apply to @2;
but check operands 1 and 0 as well, which might be surprising.  In this 
case it might indeed be equivalent to :

 (plus (minus @0 @1) @2):operand_equal_p (@1, @2, 0)



 Note that your predicate placement doesn't match placement of
 captures for non-innermost expressions.  capturing the outer
 plus would be
 
 (plus@3 (minus @0 @1) @2)


You're right, I'd allow placing the predicate directly behind the capture, 
i.e.:

(plus@3:predicate (minus @0 @1) @2)

 But I still think that doing all predicates within a if-expr makes the 
 pattern less convoluted.

I think it simply depends on the scope of the predicate.  If it's a 
predicate applying to multiple operands from different nested level an 
if-expr is clearer (IMHO).  If it applies to one operand it seems more 
natural to place it directly next to that operand.  I.e.:

(minus @0 @1:non_negative) // better

vs.

(minus @0 @1)
  (if (non_negative (@1))

But:

(plus@3 (minus @0 @1) @2)  // better
  (if (operand_equal_p (@1, @2, 0))

vs:

(plus@3:operand_equal_p (@1, @2, 0) (minus @0 @1) @2)

That is we could require that predicates that are applied with ':' need to 
be unary and apply to the one expression to which they are bound.

 Enabling/disabling a whole set of patterns with a common condition
 might still be a worthwhile addition.

Right, but that seems orthogonal to the above?


Ciao,
Michael.

Re: [GSoC] first phase

2014-05-20 Thread Prathamesh Kulkarni

On Tue, May 20, 2014 at 5:46 PM, Richard Biener
richard.guent...@gmail.com wrote:
 On Mon, May 19, 2014 at 7:30 PM, Prathamesh Kulkarni
 bilbotheelffri...@gmail.com wrote:
 Hi,
Unfortunately I shall need to take this week off, due to university exams,
 which are up-to 27th May. I will start working from 28th on pattern
 matching with decision tree, and try to cover up for the first week. I
 am extremely sorry about this.
 I thought I would be able to do both during exam week, but the exam
 load has become too much -:(

 Ok.

 In the first phase (up-to 23rd June), I hope to get genmatch ready:
 a) pattern matching with decision tree.
 b) Add patterns to test genmatch.
 c) Depending upon the patterns, extending the meta-description
 d) Other fixes:

 * capturing outermost expressions.
 For example this pattern does not get simplified
 (match_and_simplify
   (plus@2 (negate @0) @1)
   if (!TYPE_SATURATING (TREE_TYPE (@2)))
   (minus @1 @0))
 I guess this happens because in write_nary_simplifiers:
   if (s-match-type != OP_EXPR)
 continue;

 Yeah.

 Maybe this is not correct way to fix this, should we also pass lhs to
 generated gimple_match_and_simplify ? I guess that would be the capture
 for outermost expression.

 Unfortunately it is not available for all API entries.  The type of the
 expression is, though.

 I lean towards rejecting the capture at parsing time and providing
 a special capture (for example @@, or just @0, or @T to denote
 it's a type, or just refer magically to 'type').  That is,

 (match_and_simplify
   (plus (negate @0) @1)
   if (!TYPE_SATURATING (type))
   (minus @1 @0))

 works for me.

 For above pattern, I guess @2 represents lhs.

 So for this test-case:
 int foo (int x, int y)
 {
   int t1 = -x;
   int t2 = t1 + y;
   return t2;
 }
 t2 would be @2, t1 would be @0 and y would be @1.
 Is that correct ?
 This would create issues when lhs is NULL, for example,
 in call to built-in functions ?

 Yeah, or if the machinery is called via gimple_build () where
 there is no existing lhs.

 * avoid using statement expressions for code gen of expression
 * rewriting code-generator using visitor classes, and other refactoring
 (using std::string for example), etc.

 I have a very rough time-line in mind, for completing tasks:
 28th may - 31st may
 a) Have test-case for each pattern present (except COND_EXPR) in match.pd
 I guess most of it is already done, a few patterns are remaining.

 Good.

 b) Small fixes (for example, those mentioned above).

 Good.

 c) Have an initial idea/prototype for implementing decision tree

 1st June - 15th June
 a) Implementing decision tree
 b) Adding patterns in match.pd to test the decision tree in match.pd,
 and accompanying test-cases in tree-ssa/match-*.c

 16th June - 23rd June
 a) Support for GENERIC code generation.
 b) Refactoring and backup time for backlog.

 GENERIC code generation:
 I am a bit confused about this. Currently, pattern matching is
 implemented for GENERIC. However I believe simplification is done on
 GIMPLE.
 For example:
 (match_and_simplify
   (plus (negate @0) @1)
   (minus @0 @1))
 If given input is GENERIC , it would do matching on GENERIC, but shall
 transform (minus @0 @1) to it's GIMPLE equivalent.
 Is that correct ?

 Correct.  Err, not sure what it will do - I implemented it only to support
 the weird cases where GENERIC is nested inside GIMPLE, like for
 a_2 = b_3  0 ? c_4 : d_5;  thus the comment in match.pd:

 /* Due to COND_EXPRs weirdness in GIMPLE the following won't work
without some hacks in the code generator.  */
 (match_and_simplify
   (cond (bit_not @0) @1 @2)
   (cond @0 @2 @1))

 the code generator would need to know that COND_EXPR has
 a GENERIC op0 ... same applies to REALPART_EXPR, but there
 the hacks are already in place ;)


 * Should we have a separate GENERIC match-and-simplify API like for gimple
 instead of having GENERIC matching in gimple_match_and_simplify ?

 Yes.  The GENERIC API follows the API of fold_{unary,binary,ternary}.
 I suppose we simply provide a slightly different name for them
 (but use the original API for recursing and call ourselves from the original
 API).

 * Do we add another pattern type, something like
 generic_match_and_simplify that will do the transform on GENERIC
 for example:
 (generic_match_and_simplify
   (plus (negate @0) @1)
   (minus @0 @1))
 would produce GENERIC equivalent of (minus @0 @1).

 or maybe keep match_and_simplify, and tell the transform operand
 to produce GENERIC.
 Something like:
 (match_and_simplify
   (plus (negate @0) @1)
   GENERIC: (minus @0 @1))

 we simply process each pattern twice, once we generate the
 GIMPLE match-and-simplify routine and once we generate the
 GENERIC match-and-simplify routine.  The patterns are supposed
 to be the same for both and always apply to both.
Yes, for  patterns where transform operand is not c-code.
I guess this wouldn't work for transforms written as c-code that uses
IR-specific API ?
As long

Re: [GSoC] first phase

On Tue, May 20, 2014 at 2:59 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
 On Tue, May 20, 2014 at 5:46 PM, Richard Biener
 richard.guent...@gmail.com wrote:
 On Mon, May 19, 2014 at 7:30 PM, Prathamesh Kulkarni
 bilbotheelffri...@gmail.com wrote:
 Hi,
Unfortunately I shall need to take this week off, due to university 
 exams,
 which are up-to 27th May. I will start working from 28th on pattern
 matching with decision tree, and try to cover up for the first week. I
 am extremely sorry about this.
 I thought I would be able to do both during exam week, but the exam
 load has become too much -:(

 Ok.

 In the first phase (up-to 23rd June), I hope to get genmatch ready:
 a) pattern matching with decision tree.
 b) Add patterns to test genmatch.
 c) Depending upon the patterns, extending the meta-description
 d) Other fixes:

 * capturing outermost expressions.
 For example this pattern does not get simplified
 (match_and_simplify
   (plus@2 (negate @0) @1)
   if (!TYPE_SATURATING (TREE_TYPE (@2)))
   (minus @1 @0))
 I guess this happens because in write_nary_simplifiers:
   if (s-match-type != OP_EXPR)
 continue;

 Yeah.

 Maybe this is not correct way to fix this, should we also pass lhs to
 generated gimple_match_and_simplify ? I guess that would be the capture
 for outermost expression.

 Unfortunately it is not available for all API entries.  The type of the
 expression is, though.

 I lean towards rejecting the capture at parsing time and providing
 a special capture (for example @@, or just @0, or @T to denote
 it's a type, or just refer magically to 'type').  That is,

 (match_and_simplify
   (plus (negate @0) @1)
   if (!TYPE_SATURATING (type))
   (minus @1 @0))

 works for me.

 For above pattern, I guess @2 represents lhs.

 So for this test-case:
 int foo (int x, int y)
 {
   int t1 = -x;
   int t2 = t1 + y;
   return t2;
 }
 t2 would be @2, t1 would be @0 and y would be @1.
 Is that correct ?
 This would create issues when lhs is NULL, for example,
 in call to built-in functions ?

 Yeah, or if the machinery is called via gimple_build () where
 there is no existing lhs.

 * avoid using statement expressions for code gen of expression
 * rewriting code-generator using visitor classes, and other refactoring
 (using std::string for example), etc.

 I have a very rough time-line in mind, for completing tasks:
 28th may - 31st may
 a) Have test-case for each pattern present (except COND_EXPR) in match.pd
 I guess most of it is already done, a few patterns are remaining.

 Good.

 b) Small fixes (for example, those mentioned above).

 Good.

 c) Have an initial idea/prototype for implementing decision tree

 1st June - 15th June
 a) Implementing decision tree
 b) Adding patterns in match.pd to test the decision tree in match.pd,
 and accompanying test-cases in tree-ssa/match-*.c

 16th June - 23rd June
 a) Support for GENERIC code generation.
 b) Refactoring and backup time for backlog.

 GENERIC code generation:
 I am a bit confused about this. Currently, pattern matching is
 implemented for GENERIC. However I believe simplification is done on
 GIMPLE.
 For example:
 (match_and_simplify
   (plus (negate @0) @1)
   (minus @0 @1))
 If given input is GENERIC , it would do matching on GENERIC, but shall
 transform (minus @0 @1) to it's GIMPLE equivalent.
 Is that correct ?

 Correct.  Err, not sure what it will do - I implemented it only to support
 the weird cases where GENERIC is nested inside GIMPLE, like for
 a_2 = b_3  0 ? c_4 : d_5;  thus the comment in match.pd:

 /* Due to COND_EXPRs weirdness in GIMPLE the following won't work
without some hacks in the code generator.  */
 (match_and_simplify
   (cond (bit_not @0) @1 @2)
   (cond @0 @2 @1))

 the code generator would need to know that COND_EXPR has
 a GENERIC op0 ... same applies to REALPART_EXPR, but there
 the hacks are already in place ;)


 * Should we have a separate GENERIC match-and-simplify API like for gimple
 instead of having GENERIC matching in gimple_match_and_simplify ?

 Yes.  The GENERIC API follows the API of fold_{unary,binary,ternary}.
 I suppose we simply provide a slightly different name for them
 (but use the original API for recursing and call ourselves from the original
 API).

 * Do we add another pattern type, something like
 generic_match_and_simplify that will do the transform on GENERIC
 for example:
 (generic_match_and_simplify
   (plus (negate @0) @1)
   (minus @0 @1))
 would produce GENERIC equivalent of (minus @0 @1).

 or maybe keep match_and_simplify, and tell the transform operand
 to produce GENERIC.
 Something like:
 (match_and_simplify
   (plus (negate @0) @1)
   GENERIC: (minus @0 @1))

 we simply process each pattern twice, once we generate the
 GIMPLE match-and-simplify routine and once we generate the
 GENERIC match-and-simplify routine.  The patterns are supposed
 to be the same for both and always apply to both.
 Yes, for  patterns where transform operand is not c-code.
 I

Re: [GSoC] writing test-case

On Tue, May 20, 2014 at 2:20 PM, Michael Matz m...@suse.de wrote:
 Hi,

 On Tue, 20 May 2014, Richard Biener wrote:

  Syntaxwise I had this idea for adding generic predicates to expressions:
 
  (plus (minus @0 @1):predicate
@2)
  (...)

 So you'd write

  (plus @0 :integer_zerop)

 instead of

  (plus @0 integer_zerop)

 ?

 plus is binary, where is your @1?

I know it's zero so I don't need it captured.

(match_and_simplify
   (plus @0 integer_zerop)
   @0)

mind that all predicates apply to leafs only at the moment.

  If you want to not capture the second
 operand but still have it tested for a predicates, then yes, the first
 form it would be.

Ok.


  If prefix or suffix doesn't matter much, but using a different syntax
  to separate expression from predicate seems to make things clearer.
  Optionally adding things like and/or for predicates might also make sense:
 
  (plus (minus @0 @1):positive_p(@0) || positive_p(@1)
@2)
  (...)

 negation whould be more useful I guess.  You open up a can of
 worms with ordering though:

 (plus (minus @0 @1) @2:operand_equal_p (@1, @2, 0))

 which might be declared invalid or is equivalent to

 It wouldn't necessarily be invalid, the predicate would apply to @2;
 but check operands 1 and 0 as well, which might be surprising.  In this
 case it might indeed be equivalent to :

 (plus (minus @0 @1) @2):operand_equal_p (@1, @2, 0)



 Note that your predicate placement doesn't match placement of
 captures for non-innermost expressions.  capturing the outer
 plus would be

 (plus@3 (minus @0 @1) @2)


 You're right, I'd allow placing the predicate directly behind the capture,
 i.e.:

 (plus@3:predicate (minus @0 @1) @2)

 But I still think that doing all predicates within a if-expr makes the
 pattern less convoluted.

 I think it simply depends on the scope of the predicate.  If it's a
 predicate applying to multiple operands from different nested level an
 if-expr is clearer (IMHO).  If it applies to one operand it seems more
 natural to place it directly next to that operand.  I.e.:

 (minus @0 @1:non_negative) // better

 vs.

 (minus @0 @1)
   (if (non_negative (@1))

 But:

 (plus@3 (minus @0 @1) @2)  // better
   (if (operand_equal_p (@1, @2, 0))

 vs:

 (plus@3:operand_equal_p (@1, @2, 0) (minus @0 @1) @2)

 That is we could require that predicates that are applied with ':' need to
 be unary and apply to the one expression to which they are bound.

Your example is to leafs which we already support as

(minus @0 non_negative@1)

any good example that is not convoluted where that applies to a
non-leaf position?

 Enabling/disabling a whole set of patterns with a common condition
 might still be a worthwhile addition.

 Right, but that seems orthogonal to the above?

Right.

Richard.


 Ciao,
 Michael.

Re: RFC: Doc update for attribute

2014-05-20 Thread Carlos O'Donell

On 05/20/2014 03:02 AM, David Wohlferd wrote:
 After thinking about this some more, I believe I have some better
 text. Previously I used the word discouraged to describe this
 practice. The existing docs use the term avoid. I believe what you
 want is something more like the attached. Direct and clear, just like
 docs should be.

David, Thanks for the new patch.

 If you are ok with this, I'll send it to gcc-patches.

Looks good to me.

Cheers,
Carlos.

 Index: extend.texi
 ===
 --- extend.texi   (revision 210624)
 +++ extend.texi   (working copy)
 @@ -3332,16 +3332,15 @@
  
  @item naked
  @cindex function without a prologue/epilogue code
 -Use this attribute on the ARM, AVR, MCORE, MSP430, NDS32, RL78, RX and SPU
 -ports to indicate that the specified function does not need prologue/epilogue
 -sequences generated by the compiler.
 -It is up to the programmer to provide these sequences. The
 -only statements that can be safely included in naked functions are
 -@code{asm} statements that do not have operands.  All other statements,
 -including declarations of local variables, @code{if} statements, and so
 -forth, should be avoided.  Naked functions should be used to implement the
 -body of an assembly function, while allowing the compiler to construct
 -the requisite function declaration for the assembler.
 +This attribute is available on the ARM, AVR, MCORE, MSP430, NDS32,
 +RL78, RX and SPU ports.  It allows the compiler to construct the
 +requisite function declaration, while allowing the body of the
 +function to be assembly code. The specified function will not have
 +prologue/epilogue sequences generated by the compiler. Only Basic
 +@code{asm} statements can safely be included in naked functions
 +(@pxref{Basic Asm}). While using Extended @code{asm} or a mixture of
 +Basic @code{asm} and ``C'' code may appear to work, they cannot be
 +depended upon to work reliably and are not supported.
  
  @item near
  @cindex functions that do not handle memory bank switching on 68HC11/68HC12
 @@ -6269,6 +6268,8 @@
  efficient code, and in most cases it is a better solution. When writing 
  inline assembly language outside of C functions, however, you must use Basic 
  @code{asm}. Extended @code{asm} statements have to be inside a C function.
 +Functions declared with the @code{naked} attribute also require Basic 
 +@code{asm} (@pxref{Function Attributes}).
  
  Under certain circumstances, GCC may duplicate (or remove duplicates of) 
 your 
  assembly code when optimizing. This can lead to unexpected duplicate 
 @@ -6388,6 +6389,8 @@
  
  Note that Extended @code{asm} statements must be inside a function. Only 
  Basic @code{asm} may be outside functions (@pxref{Basic Asm}).
 +Functions declared with the @code{naked} attribute also require Basic 
 +@code{asm} (@pxref{Function Attributes}).
  
  While the uses of @code{asm} are many and varied, it may help to think of an 
  @code{asm} statement as a series of low-level instructions that convert 
 input

Re: RFC: Doc update for attribute

2014-05-20 Thread Carlos O'Donell

On 05/20/2014 03:59 AM, Georg-Johann Lay wrote:
Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell:
On 05/12/2014 11:13 PM, David Wohlferd wrote:
After updating gcc's docs about inline asm, I'm trying to
improve some of the related sections. One that I feel has
problems with clarity is __attribute__ naked.

I have attached my proposed update. Comments/corrections are
welcome.

In a related question:

To better understand how this attribute is used, I looked at the
Linux kernel. While the existing docs say only ... asm
statements that do not have operands can safely be used, Linux
routinely uses asm WITH operands.

That's a bug. Period. You must not use naked with an asm that has
operands. Any kind of operand might inadvertently cause the
compiler to generate code and that would violate the requirements
of the attribute and potentially generate an ICE.

There is target hook TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS that is
intended to cater that case. For example, the documentation
indicates it only works with optimization turned off. But I don't
know how reliable it is in general. For avr target it works as
expected.

https://gcc.gnu.org/onlinedocs/gccint/Misc.html#index-TARGET_005fALLOCATE_005fSTACK_005fSLOTS_005fFOR_005fARGS-4969

It's still a bug for now. That hook is there because we've allowed
bad code to exist for so long that at this point we must for legacy
reasons allow some type of input arguments in the asm. However, that
doesn't mean we should actively promote this feature or let users
use it (until we fix it).

Ideally you do want to use the named input arguments as r types to
avoid needing to know the exact registers used in the call sequence.
Referencing the variables by name and letting gcc emit the right
register is useful, but only if it works consistently and today it
doesn't.

Features that fail to work depending on the optimization level should
not be promoted in the documentation. We should document what works
and file bugs or fix what doesn't work.

Cheers,
Carlos.

Weird startup issue with -fsplit-stack

2014-05-20 Thread Dmitry Antipov


Hello,

I'm trying to support -fsplit-stack in GNU Emacs. The most important problem is 
that
GC uses conservative scanning of a C stack, so I need to iterate over stack 
segments.
I'm doing this by using  __splitstack_find, as described in 
libgcc/generic-morestack.c;
but now I'm facing the weird issue with startup:

Core was generated by `./temacs --batch --load loadup bootstrap'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __morestack () at ../../../gcc-4.9.0/libgcc/config/i386/morestack.S:486
486 pushq   %rax
(gdb) bt 10
#0  __morestack () at ../../../gcc-4.9.0/libgcc/config/i386/morestack.S:486
#1  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#2  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#3  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#4  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#5  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#6  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#7  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#8  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#9  0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
(More stack frames follow...)
(gdb) bt -10
#87310 0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#87311 0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#87312 0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#87313 0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#87314 0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#87315 0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#87316 0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#87317 0x005f15df in __morestack () at 
../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
#87318 0x003791a21d65 in __libc_start_main (main=0x4d111d main, argc=5, 
argv=0x7fffacc868d8, init=optimized out,
fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffacc868c8) 
at libc-start.c:285
#87319 0x00405f69 in _start ()
(gdb)

Unfortunately I was unable to reproduce this issue with small test programs, so
there is no simple and easy-to-use recipe. Anyway, if someone would like to try:

bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk
cd trunk
cat /path/to/emacs_split_stack.patch | patch -p0
# 'configure' options for 'smallest possible' configuration
CPPFLAGS='-DSPLIT_STACK=1' CFLAGS='-O0 -g3 -fsplit-stack' ./configure 
--prefix=/some/dir --without-all --without-x --disable-acl
make

I'm using (homebrew) GCC 4.9.0 and (stock) gold 2.24 on a Fedora 20 system.

Dmitry

=== modified file 'src/alloc.c'
--- src/alloc.c	2014-05-19 19:19:05 +
+++ src/alloc.c	2014-05-20 14:01:56 +
@@ -4932,11 +4932,28 @@
 #endif /* not GC_SAVE_REGISTERS_ON_STACK */
 #endif /* not HAVE___BUILTIN_UNWIND_INIT */
 
-  /* This assumes that the stack is a contiguous region in memory.  If
- that's not the case, something has to be done here to iterate
- over the stack segments.  */
+#ifdef SPLIT_STACK
+
+  /* This assumes gcc = 4.6.0 with -fsplit-stack
+ and corresponding support in libgcc.  */
+  {
+size_t stack_size;
+extern void * __splitstack_find (void *, void *, size_t *,
+ void **, void **, void **);
+void *next_segment = NULL, *next_sp = NULL, *initial_sp = NULL, *stack;
+
+while ((stack = __splitstack_find (next_segment, next_sp, stack_size,
+   next_segment, next_sp, initial_sp)))
+  mark_memory (stack, (char *) stack + stack_size);
+  }
+
+#else /* not SPLIT_STACK */
+
+  /* This assumes that the stack is a contiguous region in memory.  */
   mark_memory (stack_base, end);
 
+#endif /* SPLIT_STACK */
+
   /* Allow for marking a secondary stack, like the register stack on the
  ia64.  */
 #ifdef GC_MARK_SECONDARY_STACK

Re: soft-fp functions support without using libgcc

2014-05-20 Thread Sheheryar Zahoor Qazi

If you have a working compiler that is missing some functions
provided by libgcc, that should be sufficient to build libgcc.
Meaning that even if i am unable build libgcc to my new architecture,
I should be able to able to provide soft-fp support to the
architecture?

Btw i get the following error when i build gcc:
configure:2627: error: in
`/target-arch/target-arch-gcc/builddir/target-arch/libgcc':
configure:2630: error: cannot compute suffix of object files: cannot compile


And regarding soft-fp, I get the following error when i use soft-fp
functions in a test program:
: In function `test':
(.text+0x0): undefined reference to `__floatsisf'
 In function `test':
: In function `test':
(.text+0x2c): undefined reference to `__mulsf3'
: In function `test':
(.text+0x2e): undefined reference to `__fixsfsi'

Is this due to libgcc build fail or it just linking error?


In other words, if you want soft-fp for IEEE float, the job should be very 
simple because that has already been done.  If you want soft-fp for CDC 6000 
float, you have to do a full implementation of that.
Actually i want soft-fp for standard IEEE 754

Sheheryar


On Fri, May 16, 2014 at 6:34 PM,  paul_kon...@dell.com wrote:

 On May 16, 2014, at 12:25 PM, Ian Bolton ian.bol...@arm.com wrote:

 On Fri, May 16, 2014 at 6:34 AM, Sheheryar Zahoor Qazi
 sheheryar.zahoor.q...@gmail.com wrote:

 I am trying to provide soft-fp support to a an 18-bit soft-core
 processor architecture at my university. But the problem is that
 libgcc has not been cross-compiled for my target architecture and
 some
 functions are missing so i cannot build libgcc.I believe soft-fp is
 compiled in libgcc so i am usable to invoke soft-fp functions from
 libgcc.
 It is possible for me to provide soft-fp support without using
 libgcc.
 How should i proceed in defining the functions? Any idea? And does
 any
 archoitecture provide floating point support withoput using libgcc?

 I'm sorry, I don't understand the premise of your question.  It is not
 necessary to build libgcc before building libgcc.  That would not make
 sense.  If you have a working compiler that is missing some functions
 provided by libgcc, that should be sufficient to build libgcc.

 If you replace cross-compiled with ported, I think it makes senses.
 Can one provide soft-fp support without porting libgcc for their
 architecture?

 By definition, in soft-fp you have to implement the FP operations in 
 software.  That’s not quite the same as porting libgcc to the target 
 architecture.  It should translate to porting libgcc (the FP emulation part) 
 to the floating point format being used.

 In other words, if you want soft-fp for IEEE float, the job should be very 
 simple because that has already been done.  If you want soft-fp for CDC 6000 
 float, you have to do a full implementation of that.

 paul

Re: negative latencies

2014-05-20 Thread Vladimir Makarov

On 05/19/2014 02:13 AM, shmeel gutl wrote:
 Are there hooks in gcc to deal with negative latencies? In other
 words, an architecture that permits an instruction to use a result
 from an instruction that will be issued later.


Could you explain more on *an example* what are you trying to achieve
with the negative latency.

Scheduler is based on a critical path algorithm.  Generally speaking
latency time can be negative for this algorithm.  But I guess that is
not what you are asking.

 At first glance it seems that it will will break a few things.
 1) The definition of dependencies cannot come from the simple ordering
 of rtl.
 2) The scheduling problem starts to look like get off the train 3
 stops before me.
 3) The definition of live ranges needs to use actual instruction
 timing information, not just instruction sequencing.

 The hooks in the scheduler seem to be enough to stop damage but not
 enough to take advantage of this feature.

Re: Roadmap for 4.9.1, 4.10.0 and onwards?

2014-05-20 Thread Basile Starynkevitch

On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams wrote:
 Hi,
 I've been tracking the latest releases of gcc since 4.7 or so (variously 
 interested in C++1y support, cilk and openmp).
 One thing I've found hard to locate is information about planned inclusions 
 for future releases. 
 As much relies on unpredictable community contributions I don't expect there 
 to be a concrete or reliable plan. 

 However, equally I'm sure the steering committee have some ideas over what 
 ought
 to be upcoming releases. 

As a whole, the steering committee does not have any idea, because GCC
development is based upon volunteer contributions.

However, some members of the steering committee might work in large
organization having a team of GCC contributors. That team might have its
own (private) agenda. But every patch has to be approved by someone
else.

So I don't think that the steering committee knows a lot more than you
and me.

Regards.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

RE: Roadmap for 4.9.1, 4.10.0 and onwards?

2014-05-20 Thread Paulo Matos

 -Original Message-
 From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
 Of Basile Starynkevitch
 Sent: 20 May 2014 16:29
 To: Bruce Adams
 Cc: gcc@gcc.gnu.org
 Subject: Re: Roadmap for 4.9.1, 4.10.0 and onwards?

 On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams wrote:
  Hi,
  I've been tracking the latest releases of gcc since 4.7 or so
 (variously interested in C++1y support, cilk and openmp).
  One thing I've found hard to locate is information about planned
 inclusions for future releases.
  As much relies on unpredictable community contributions I don't
 expect there to be a concrete or reliable plan.

  However, equally I'm sure the steering committee have some ideas
 over
  what ought to be upcoming releases.

 As a whole, the steering committee does not have any idea, because GCC
 development is based upon volunteer contributions.

I understand the argument but I am not sure it's the way to go. Even if the 
project is based on volunteer contributions it would be interesting to have a 
tentative roadmap. This, I would think, would also help possible beginner 
volunteers know where to start if they wanted to contribute to the project. So 
the roadmap could be a list of features (big or small) of bug fixes that we 
would like fixed for a particular version. Even if we don't want to name it 
roadmap it would still be interesting to have a list of things that are being 
worked on or on the process of being merged into mainline and therefore will 
make it to the next major version.

That being said I know it's hard to set sometime apart to write this kind of 
thing given most of us prefer to be hacking on GCC. From a newcomer point of 
view, however, not having things like a roadmap makes it look like the project 
is heading nowhere.

Re: soft-fp functions support without using libgcc

2014-05-20 Thread Ian Lance Taylor

On Tue, May 20, 2014 at 7:37 AM, Sheheryar Zahoor Qazi
sheheryar.zahoor.q...@gmail.com wrote:
If you have a working compiler that is missing some functions
provided by libgcc, that should be sufficient to build libgcc.
 Meaning that even if i am unable build libgcc to my new architecture,
 I should be able to able to provide soft-fp support to the
 architecture?

You need to build soft-fp as part of libgcc.  What I am saying is that
you don't need soft-fp support in order to build libgcc.


 Btw i get the following error when i build gcc:
 configure:2627: error: in
 `/target-arch/target-arch-gcc/builddir/target-arch/libgcc':
 configure:2630: error: cannot compute suffix of object files: cannot compile

You need to look in target-arch/libgcc/config.log to see what the
problem is.


 And regarding soft-fp, I get the following error when i use soft-fp
 functions in a test program:
 : In function `test':
 (.text+0x0): undefined reference to `__floatsisf'
  In function `test':
 : In function `test':
 (.text+0x2c): undefined reference to `__mulsf3'
 : In function `test':
 (.text+0x2e): undefined reference to `__fixsfsi'

 Is this due to libgcc build fail or it just linking error?

It's because libgcc was not built.

Ian

Re: Roadmap for 4.9.1, 4.10.0 and onwards?

2014-05-20 Thread Bruce Adams

- Original Message -
 From: Paulo Matos pma...@broadcom.com
 To: Basile Starynkevitch bas...@starynkevitch.net; Bruce Adams 
 tortoise...@yahoo.co.uk
 Cc: gcc@gcc.gnu.org gcc@gcc.gnu.org
 Sent: Tuesday, May 20, 2014 5:04 PM
 Subject: RE: Roadmap for 4.9.1, 4.10.0 and onwards?

  -Original Message-
  From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
  Of Basile Starynkevitch
  Sent: 20 May 2014 16:29
  To: Bruce Adams
  Cc: gcc@gcc.gnu.org
  Subject: Re: Roadmap for 4.9.1, 4.10.0 and onwards?

  On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams wrote:
   Hi,
       I've been tracking the latest releases of gcc since 4.7 or so
  (variously interested in C++1y support, cilk and openmp).
   One thing I've found hard to locate is information about planned
  inclusions for future releases.
   As much relies on unpredictable community contributions I don't
  expect there to be a concrete or reliable plan.

   However, equally I'm sure the steering committee have some ideas
  over
   what ought to be upcoming releases.

  As a whole, the steering committee does not have any idea, because GCC
  development is based upon volunteer contributions.

 I understand the argument but I am not sure it's the way to go. Even if the 
 project is based on volunteer contributions it would be interesting to have a 
 tentative roadmap. This, I would think, would also help possible beginner 
 volunteers know where to start if they wanted to contribute to the project. 
 So 
 the roadmap could be a list of features (big or small) of bug fixes that we 
 would like fixed for a particular version. Even if we don't want to name it 
 roadmap it would still be interesting to have a list of things that are being 
 worked on or on the process of being merged into mainline and therefore will 
 make it to the next major version.

 That being said I know it's hard to set sometime apart to write this kind of 
 thing given most of us prefer to be hacking on GCC. From a newcomer point of 
 view, however, not having things like a roadmap makes it look like the 
 project 
 is heading nowhere.

If you think of gcc as a large distributed agile project the road map may be 
buried
somewhere in the bug database. Perhaps its a matter of mining the relevant 
details
or encouraging practices that make them mineable?
The bugzilla has fields for assignee, priority and target milestone that could 
be used as hints.
The trouble is its very low level. 
The intent is buried in the communities subjective interpretation of priority. 
I don't know
how well that mirrors the actual values in the priority fields. I wouldn't 
expect it to without
a conscious effort.

If I search for ALL cilk 4.9 or ALL cilk it is still not obvious that the 
cilk branch 
was merged into main prior to release 4.9.0. Though that could be down to my 
unfamiliarity with more complex queries in bugzilla.

Regards,

Bruce.

Re: Roadmap for 4.9.1, 4.10.0 and onwards?

2014-05-20 Thread Jeff Law


On 05/20/14 04:09, Bruce Adams wrote:

Hi, I've been tracking the latest releases of gcc since 4.7 or so
(variously interested in C++1y support, cilk and openmp). One thing
I've found hard to locate is information about planned inclusions for
future releases. As much relies on unpredictable community
contributions I don't expect there to be a concrete or reliable plan.
However, equally I'm sure the steering committee have some ideas over
what ought to be upcoming releases. Is this published anywhere?
The steering committee doesn't get involved in that aspect of 
development.  It's just not in the committee's charter.


There is no single roadmap for the GCC project and that's a direct 
result of the decentralized development.


Looking forward to the next major GCC release (4.10 or 5.0):

At a high level, wrapping up the C++11 ABI transition is high on the 
list for the next major GCC release.  As is the ongoing efforts to clean 
up the polymorphism in gimple (and maybe RTL).  Those aren't really user 
visible features, but they're a ton of work.


I'm hoping the Intel team can push the last remaining Cilk+ feature 
through (Cilk_for).  Jakub is working on Fortran support for OpenMP4. 
Others are working on OpenACC support.


Richi's work on folding looks promising, but I'm not sure of its 
relative priority.  There's work to bring AArch64 and Power 8 to first 
class support...  Honza's work on IPA, etc etc.


C++14 support will continue to land as bits are written.

I'm certainly missing lots of important stuff...


WRT to gcc-4.9.1, like most (all?) point releases, it's primarily meant 
to address bugs in the prior release.  I wouldn't expect significant 
features to be appearing in 4.9.x releases.


Jeff

Re: Weird startup issue with -fsplit-stack

2014-05-20 Thread Ian Lance Taylor

On Tue, May 20, 2014 at 7:18 AM, Dmitry Antipov dmanti...@yandex.ru wrote:

 I'm trying to support -fsplit-stack in GNU Emacs. The most important problem
 is that
 GC uses conservative scanning of a C stack, so I need to iterate over stack
 segments.
 I'm doing this by using  __splitstack_find, as described in
 libgcc/generic-morestack.c;
 but now I'm facing the weird issue with startup:

 Core was generated by `./temacs --batch --load loadup bootstrap'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  __morestack () at ../../../gcc-4.9.0/libgcc/config/i386/morestack.S:486
 486 pushq   %rax
 (gdb) bt 10
 #0  __morestack () at ../../../gcc-4.9.0/libgcc/config/i386/morestack.S:486
 #1  0x005f15df in __morestack () at
 ../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
 #2  0x005f15df in __morestack () at
 ../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502
 #3  0x005f15df in __morestack () at
 ../../../gcc-4.9.0/libgcc/config/i386/morestack.S:502

This is the call to __morestack_block_signals in morestack.S.  It
should only be possible if __morestack_block_signals or something it
calls directly has a split stack.  __morestack_block_signals has the
no_split_stack attribute, meaning that it should never call
__morestack.  __morestack_block_signals only calls pthread_sigmark or
sigprocmask, neither of which should be compiled with -fsplit-stack.
So something has gone wrong, but I don't know what.

I would recommend tracing the code instruction by instruction to see
why __morestack_block_signals calls back into __morestack.  Or, if
that analysis is wrong, see what else is happening.

I can advise but I don't have time to look at this in detail.  Sorry.

Ian

Re: Roadmap for 4.9.1, 4.10.0 and onwards?

2014-05-20 Thread Jonathan Wakely

 If I search for ALL cilk 4.9 or ALL cilk it is still not obvious that the 
 cilk branch
 was merged into main prior to release 4.9.0. Though that could be down to my 
 unfamiliarity with more complex queries in bugzilla.

Our bugzilla is usually used for tracking bugs, not merging of feature branches.

https://gcc.gnu.org/gcc-4.9/changes.html#c-family announces the
addition of Cilk Plus.

Merges of major new features should probably also be announced on
https://gcc.gnu.org/news.html

Re: negative latencies

2014-05-20 Thread shmeel gutl


On 20-May-14 06:13 PM, Vladimir Makarov wrote:

On 05/19/2014 02:13 AM, shmeel gutl wrote:

Are there hooks in gcc to deal with negative latencies? In other
words, an architecture that permits an instruction to use a result
from an instruction that will be issued later.


Could you explain more on *an example* what are you trying to achieve
with the negative latency.

Scheduler is based on a critical path algorithm.  Generally speaking
latency time can be negative for this algorithm.  But I guess that is
not what you are asking.
The architecture has an exposed pipeline where instructions read 
registers during the required cycle. So if one instruction produces its 
results in the third pipeline stage and a second instruction reads the 
register in the sixth pipeline stage, the second instruction can read 
the results of the first instruction even if it is issued three cycles 
earlier.


The problem that I see is that the haifa scheduler schedules one cycle 
at a time, in a forward order, by picking from a list of instructions 
that can be scheduled without delays. So, in the above example, if 
instruction one is scheduled during cycle 3, it can't schedule 
instruction two during cycle 0, 1, or 2 because its producer dependency 
(instruction one) hasn't been scheduled yet. It won't be able to 
schedule it until cycle 3. So I am asking if there is an existing 
mechanism to back schedule instruction two once instruction one is issued.


Thanks,
Shmeel

At first glance it seems that it will will break a few things.
1) The definition of dependencies cannot come from the simple ordering
of rtl.
2) The scheduling problem starts to look like get off the train 3
stops before me.
3) The definition of live ranges needs to use actual instruction
timing information, not just instruction sequencing.

The hooks in the scheduler seem to be enough to stop damage but not
enough to take advantage of this feature.

Re: Zero/Sign extension elimination using value ranges

2014-05-20 Thread Kugan


On 20/05/14 16:52, Jakub Jelinek wrote:
 On Tue, May 20, 2014 at 12:27:31PM +1000, Kugan wrote:
 1.  Handling NOP_EXPR or CONVERT_EXPR that are in the IL because they
 are required for type correctness. We have two cases here:

 A) Mode is smaller than word_mode. This is usually from where the
 zero/sign extensions are showing up in final assembly.
 For example :
 int = (int) short
 which usually expands to
  (set (reg:SI )
   (sext:SI (subreg:HI (reg:SI 
 We can expand  this
  (set (reg:SI ) (((reg:SI 

 If following is true:
 1. Value stored in RHS and LHS are of the same signedness
 2. Type can hold the value. i.e., In cases like char = (char) short, we
 check that the value in short is representable char type. (i.e. look at
 the value range in RHS SSA_NAME and see if that can be represented in
 types of LHS without overflowing)

 Subreg here is not a paradoxical subreg. We are removing the subreg and
 zero/sign extend here.

 I am assuming here that QI/HI registers are represented in SImode
 (basically word_mode) with zero/sign extend is used as in
 (zero_extend:SI (subreg:HI (reg:SI 117)).
 
 Wouldn't it be better to just set proper flags on the SUBREG based on value
 range info (SUBREG_PROMOTED_VAR_P and SUBREG_PROMOTED_UNSIGNED_P)?
 Then not only the optimizers could eliminate in zext/sext when possible, but
 all other optimizations could benefit from that.

Thanks for the comments. Here is an attempt (attached) that sets
SUBREG_PROMOTED_VAR_P based on value range into. Is this the good place
to do this ?

Thanks,
Kugan
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index b7f6360..d23ae76 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -3120,6 +3120,60 @@ expand_return (tree retval)
 }
 }
 
+
+static bool
+is_assign_promotion_redundant (struct separate_ops *ops)
+{
+  double_int type_min, type_max;
+  double_int min, max;
+  bool uns = TYPE_UNSIGNED (ops-type);
+  double_int msb;
+
+  /* We remove extension for integral stmts.  */
+  if (!INTEGRAL_TYPE_P (ops-type))
+return false;
+
+  if (TREE_CODE_CLASS (ops-code) == tcc_unary)
+{
+  switch (ops-code)
+   {
+   case CONVERT_EXPR:
+   case NOP_EXPR:
+
+ /* Get the value range.  */
+ if (TREE_CODE (ops-op0) != SSA_NAME
+ || POINTER_TYPE_P (TREE_TYPE (ops-op0))
+ || get_range_info (ops-op0, min, max) != VR_RANGE)
+   return false;
+
+ msb = double_int_one.rshift (TYPE_PRECISION (TREE_TYPE (ops-op0)));
+ if (!uns  min.cmp (msb, uns) == 1
+  max.cmp (msb, uns) == 1)
+   {
+ min = min.sext (TYPE_PRECISION (TREE_TYPE (ops-op0)));
+ max = max.sext (TYPE_PRECISION (TREE_TYPE (ops-op0)));
+   }
+
+ /* Signedness of LHS and RHS should match or value range of RHS
+should be all positive values to make zero/sign extension 
redundant.  */
+ if ((uns != TYPE_UNSIGNED (TREE_TYPE (ops-op0)))
+   (min.cmp (double_int_zero, TYPE_UNSIGNED (TREE_TYPE 
(ops-op0))) == -1))
+   return false;
+
+ type_max = tree_to_double_int (TYPE_MAX_VALUE (ops-type));
+ type_min = tree_to_double_int (TYPE_MIN_VALUE (ops-type));
+
+ /* If rhs value range fits lhs type, zero/sign extension is
+   redundant.  */
+ if (max.cmp (type_max, uns) != 1
+  (type_min.cmp (min, uns)) != 1)
+   return true;
+   }
+}
+
+  return false;
+}
+
 /* A subroutine of expand_gimple_stmt, expanding one gimple statement
STMT that doesn't require special handling for outgoing edges.  That
is no tailcalls and no GIMPLE_COND.  */
@@ -3240,6 +3294,12 @@ expand_gimple_stmt_1 (gimple stmt)
  }
ops.location = gimple_location (stmt);
 
+   if (promoted  is_assign_promotion_redundant (ops))
+ {
+   promoted = false;
+   SUBREG_PROMOTED_VAR_P (target) = 0;
+ }
+
/* If we want to use a nontemporal store, force the value to
   register first.  If we store into a promoted register,
   don't directly expand to target.  */

Re: Roadmap for 4.9.1, 4.10.0 and onwards?

2014-05-20 Thread Jan Hubicka

 On 05/20/14 04:09, Bruce Adams wrote:
 Hi, I've been tracking the latest releases of gcc since 4.7 or so
 (variously interested in C++1y support, cilk and openmp). One thing
 I've found hard to locate is information about planned inclusions for
 future releases. As much relies on unpredictable community
 contributions I don't expect there to be a concrete or reliable plan.
 However, equally I'm sure the steering committee have some ideas over
 what ought to be upcoming releases. Is this published anywhere?
 The steering committee doesn't get involved in that aspect of
 development.  It's just not in the committee's charter.
 
 There is no single roadmap for the GCC project and that's a direct
 result of the decentralized development.
 
 Looking forward to the next major GCC release (4.10 or 5.0):
 
 At a high level, wrapping up the C++11 ABI transition is high on the
 list for the next major GCC release.  As is the ongoing efforts to
 clean up the polymorphism in gimple (and maybe RTL).  Those aren't
 really user visible features, but they're a ton of work.
 
 I'm hoping the Intel team can push the last remaining Cilk+ feature
 through (Cilk_for).  Jakub is working on Fortran support for
 OpenMP4. Others are working on OpenACC support.
 
 Richi's work on folding looks promising, but I'm not sure of its
 relative priority.  There's work to bring AArch64 and Power 8 to
 first class support...  Honza's work on IPA, etc etc.

For IPA/FDO I think we are on track to merge some of more interesting
Google's changes (autoFDO, perhaps LIPO and other FDO improvements) and
Martin's pass for merging identical code.

I am personally trying to focus on two things - first is to cleanup APIs of
symbol table and IPA infrastructure after the C++ conversion and try to get
things working well for LTO of large binaries - this is important change for
optimizers, since we go from units consisting of hundred functions to units
consiting of million of functions and heuristics needs to retune.
And I also hope we will continue pushing bits making LTO more transparent
and reliable (command line arguments, debug info etc.)

Honza
 
 C++14 support will continue to land as bits are written.
 
 I'm certainly missing lots of important stuff...
 
 
 WRT to gcc-4.9.1, like most (all?) point releases, it's primarily
 meant to address bugs in the prior release.  I wouldn't expect
 significant features to be appearing in 4.9.x releases.
 
 Jeff

Reducing Register Pressure through Live range Shrinking through Loops!!

2014-05-20 Thread Ajit Kumar Agarwal


Hello All:

Simpson does the Live range shrinking and reduction of register pressure by 
using the computation that are not load and store but the arithmetic 
computation. The computation
where the operands and registers are live at the entry and exit of the basic 
block but not touched inside the block then the computation is moved at the end 
of the block the reducing the register pressure inside the block by one.  
Extension of the Simpson work by extending the computation not being touched 
inside the basic block to the spanning of the Loops. If the Live ranges spans 
the Loops and live at the entry and exit of the Loop but the computation is not 
being touched inside the Loops then the computation is moved after the exit of 
the Loop. 

REDUCTION OF REGISTER PRESSURE THROUGH LIVE RANGE SHRINKING INSIDE THE LOOPS

for each Loop starting from inner to outer do the following
begin
RELIEFIN(i) = null if i is the entry of the cfg.
Else
For all predecessors j RELIEFOUT(j)
RELIEFOUT(i) = RELIEFIN(i) exposed union relief
INSERT(I,j) = RELIEFOUT(i) RELIEFIN(i) Intersection
Live(i)
end

The Simpson approach does takes the nesting depth into consideration of placing 
the computation and the relieve of the register pressure. Simpson approach 
doesn't takes into
consideration the computation which spans throughout the loop and the operands 
and results are live at the entry of the Loop and exit of the Loop but not 
touched inside the Loops can be useful in reduction of register pressure inside 
the Loops. This  approach will be useful in Region Based Register Allocator for 
Live Range Splitting at the Region Boundaries.

Extension of the Simpson approach is to consider the data flow analysis with 
respect to the given Loop rather than having it for entire control flow graph. 
This data flow analysis starts from the inner loop and extends it to the outer 
loop. If the reference is not through the nested depth or with some depth then 
the computation can be placed accordingly. For register allocator by Graph 
coloring the live ranges that are with respect to operands and results of the 
computation are taken into consideration and for the above approach put into 
the stack during simplification phase of Graph Coloring so that there is a 
chance of getting such Live ranges colorable and thus reduces the register 
pressure. This is extended to splitting
approach based on containment of Live ranges

OPTIMAL PLACEMENT OF THE COMPUTATION FOR SINGLE ENTRY AND MULTIPLE EXIT LOOPS

The placement of the computation to reduce the register pressure for Single 
Entry and Multiple exit by Simpson approach lead to unoptimal solution. The 
unoptimal Solution
is because of the exit node of the loop does not post dominates all the basic 
block inside the Loops. Due to this the placement of the computation just after 
the tail block of the Loop will lead to incorrect results. In order to perform 
the Optimal Solution of the placement of the computation, the computation needs 
to be placed the block just after all the exit points of the Loop reconverge 
and which will post dominates all the blocks of the Loops. This will take care 
of reducing the register pressure for the Loops that are single Entry and 
Multiple Exit. For irreducible Loops the optimization to convert to reducible 
is done before the register allocation that reduces the register pressure and 
will be applicable to structured control flow and thus reduces the register 
pressure.

The Live range shrinkage reducing register pressure takes load and store into 
consideration but not computation as proposed by Simpson. I am proposing to 
extend in GCC for the computation to reduce register pressure and for the Loop 
as given above for both Single Entry and Single Exit and Single Entry and 
Multiple Exit Loops.

Please let me know what do you think.

Thanks  Regards
Ajit

Re: Weird startup issue with -fsplit-stack

2014-05-20 Thread Dmitry Antipov


On 05/20/2014 10:16 PM, Ian Lance Taylor wrote:


This is the call to __morestack_block_signals in morestack.S.  It
should only be possible if __morestack_block_signals or something it
calls directly has a split stack.  __morestack_block_signals has the
no_split_stack attribute, meaning that it should never call
__morestack.  __morestack_block_signals only calls pthread_sigmark or
sigprocmask, neither of which should be compiled with -fsplit-stack.
So something has gone wrong, but I don't know what.


Thanks - that was an application's own copy of pthread_sigmask (compiled
with -fsplit-stack) linked into the binary due to a subtle configuration
issue.

The next major problem is that -fsplit-stack code randomly crashes with the
useless gdb backtrace, usually pointing to the very beginning of the function
(plus occasional Cannot access memory at... messages), e.g.:

(gdb) bt 1
#0  0x005a615b in mark_object (arg=0) at ../../trunk/src/alloc.c:6039

 6037  void
 6038  mark_object (Lisp_Object arg)
==  6039  {

IIUC this usually (with traditional stack) happens due to stack overflow.
But what may be the case with -fsplit-stack? I do not receive any error
messages from libgcc, and there are a lot of free heap memory. If that matters,
mark_object is recursive, and recursion depth may be very high, up to a few
tens of thousands calls.

Dmitry

[Bug middle-end/61243] New: [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65

2014-05-20 Thread Joost.VandeVondele at mat dot ethz.ch

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

Bug ID: 61243
   Summary: [4.10 Regression] verify_flow_info failed: No region
crossing jump at section boundary in bb 65
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch

Recent regression in the one day between good: r210596 bad: r210629

Unfortunately, only happens with -fprofile-use on our large application (CP2K).
Any suggestion on how to get this into a testcase ? I can provide unreduced .F,
.mod and .gcda files.

/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/qs_integrate_potential_low.F:526:0:
error: No region crossing jump at section boundary in bb 65
 END SUBROUTINE xyz_to_vab
 ^
/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/qs_integrate_potential_low.F:526:0:
internal compiler error: verify_flow_info failed
0x6edead verify_flow_info()
../../gcc/gcc/cfghooks.c:260
0xf60a88 try_optimize_cfg
../../gcc/gcc/cfgcleanup.c:2860
0xf60a88 cleanup_cfg(int)
../../gcc/gcc/cfgcleanup.c:3025
0xf5363b execute
../../gcc/gcc/bb-reorder.c:2353
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.
make[2]: *** [qs_integrate_potential_low.o] Error 1

[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup

2014-05-20 Thread alexey.merzlyakov at samsung dot com

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

--- Comment #9 from Alexey Merzlyakov alexey.merzlyakov at samsung dot com ---
The following PR has been opened for Thumb1 problem:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61223

[Bug middle-end/61243] [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65

2014-05-20 Thread ubizjak at gmail dot com

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

Uroš Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
The same failure is triggered with profiledbootstrap build. First recorded
bootstrap failure is at r210603 [1]. Last good bootstrap is at r210599 [2].

It looks that r210603 is problematic [3]. Author CC'd.

[1] https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00224.html
[2] https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01581.html
[3] https://gcc.gnu.org/ml/gcc-cvs/2014-05/msg00646.html

[Bug middle-end/61243] [4.10 Regression] verify_flow_info failed: No region crossing jump at section boundary in bb 65

2014-05-20 Thread ubizjak at gmail dot com

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

Uroš Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-20
   Target Milestone|--- |4.10.0
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
Confirmed.

[Bug c/61236] GCC 4.9 generates incorrect object code

2014-05-20 Thread muks at banu dot com

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

--- Comment #9 from Mukund Sivaraman muks at banu dot com ---
Hi Jakub, Markus

We discussed this during our daily standup call today, and there are two
points we'd like to make:

1. The qsort() defintion in C99 doesn't explicitly state that base must
not be NULL, though it seems you are deducing that from the initial
element of which is pointed to by base.

The POSIX definition of qsort() adds this:

 If the nel argument has the value zero, the comparison function
  pointed to by compar shall not be called and no rearrangement shall
  take place.

2. From our perpective as users of GCC, this kind of agressive
optimization seems counter-intuitive. We'd like code to compile to
correct object code first before performance.

When the compiler knows at that point that base (=x) is NULL as an
argument to qsort(), why isn't it warning when the attribute expects it
to be non-NULL, esp. as it is using this inferred decision to optimize
code down below?

The compiler knows x is NULL at this point in this codepath regardless
of what qsort()'s attributes say. Why is it using the attribute then?

qsort() also does not assert (at runtime) that base is non-NULL.  There
is no way to detect this for code which used to run correctly before,
but doesn't anymore (without it _hopefully_ crashing somewhere).

Other similar functions such as memcpy(), etc. also have this annotation
in glibc, whereas there is no definition of n=0 case in C99.

This example of qsort() is in libc, but imagine a case where a program
uses a 3rd party system installed utility shared library. If the
library, in a new version, adds a nonnull annotation for a function, but
the library function itself continues to work for NULL input, see what
happens to the program: The library is not affected, but the pointer in
the calling program is affected if the compiler infers that the pointer
is non-NULL due to the attribute. The calling program is now buggy due
to a change in the library. How do we discover it?

It makes sense to just avoid the qsort() in our case and we will update
our code to do so, but please consider the arguments above.

[Bug go/61244] New: gccgo: ICE in write_specific_type_functions

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

Bug ID: 61244
   Summary: gccgo: ICE in write_specific_type_functions
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dvyukov at google dot com

Created attachment 32824
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32824action=edit
reproducer

$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,go --disable-bootstrap
--enable-checking=yes --disable-multilib --prefix=gcc_trunk/install
Thread model: posix
gcc version 4.10.0 20140516 (experimental) (GCC)

The reproducer program is attached.

$ go build -compiler=gccgo 0.go
go1: internal compiler error: in write_specific_type_functions, at
go/gofrontend/types.cc:1819
0x628f2a Type::write_specific_type_functions(Gogo*, Named_type*,
std::basic_stringchar, std::char_traitschar, std::allocatorchar  const,
Function_type*, std::basic_stringchar, std::char_traitschar,
std::allocatorchar  const, Function_type*)
../../gcc/go/gofrontend/types.cc:1819
0x6276bf Type::specific_type_functions(Gogo*, Named_type*, Function_type*,
Function_type*, Named_object**, Named_object**)
../../gcc/go/gofrontend/types.cc:1798
0x627c86 Type::type_functions(Gogo*, Named_type*, Function_type*,
Function_type*, Named_object**, Named_object**)
../../gcc/go/gofrontend/types.cc:1675
0x630194 Type::type_descriptor_constructor(Gogo*, int, Named_type*, Methods
const*, bool)
../../gcc/go/gofrontend/types.cc:2016
0x6321f3 Array_type::array_type_descriptor(Gogo*, Named_type*)
../../gcc/go/gofrontend/types.cc:6121
0x62a5db Type::make_type_descriptor_var(Gogo*)
../../gcc/go/gofrontend/types.cc:1249
0x62a796 Type::type_descriptor_pointer(Gogo*, Location)
../../gcc/go/gofrontend/types.cc:1206
0x5bf412 Type_descriptor_expression::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/expressions.cc:13863
0x5bb6eb Call_expression::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/expressions.cc:9425
0x5a23f6 Unary_expression::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/expressions.cc:4039
0x607491 If_statement::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/statements.cc:3200
0x5db097 Block::get_backend(Translate_context*)
../../gcc/go/gofrontend/gogo.cc:5454
0x60741c Block_statement::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/statements.cc:1811
0x5db097 Block::get_backend(Translate_context*)
../../gcc/go/gofrontend/gogo.cc:5454
0x60741c Block_statement::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/statements.cc:1811
0x5db097 Block::get_backend(Translate_context*)
../../gcc/go/gofrontend/gogo.cc:5454
0x60741c Block_statement::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/statements.cc:1811
0x5db097 Block::get_backend(Translate_context*)
../../gcc/go/gofrontend/gogo.cc:5454
0x60741c Block_statement::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/statements.cc:1811
0x5db097 Block::get_backend(Translate_context*)
../../gcc/go/gofrontend/gogo.cc:5454

[Bug c/61236] GCC 4.9 generates incorrect object code

2014-05-20 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
If you believe the nonnull attribute on qsort is incorrect, then you should
report that as glibc bug, not gcc bug, the prototype is provided by glibc.
The more aggressive GCC optimization is documented e.g. in
https://gcc.gnu.org/gcc-4.9/porting_to.html
plus we hope to add -fsanitize=undefined instrumentation for this in the
upcoming GCC version, so you find it out more easily.

 When the compiler knows at that point that base (=x) is NULL as an
 argument to qsort(), why isn't it warning when the attribute expects it
 to be non-NULL, esp. as it is using this inferred decision to optimize
 code down below?

But the compiler doesn't know there that x is NULL.  The compiler sees a call
to a function which must not be called with NULL, and from that derives the
value range of x to be anything but NULL.  Instead of qsort consider here some
less controversial function, e.g. memcpy, where the standard is very clear that
memcpy (NULL, , 0); or memcpy (, NULL, 0); is invalid despite the length 0.

[Bug tree-optimization/61245] New: ICE at in expand_ANNOTATE, at internal-fn.c:127 called from cfgexpand.c

2014-05-20 Thread vincenzo.innocente at cern dot ch

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

Bug ID: 61245
   Summary: ICE at in expand_ANNOTATE, at internal-fn.c:127 called
from cfgexpand.c
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch

apologize for not reducing (trivial reduction (bar below) works)
given 
cat NaiveDod.cc
#includearray
#includevector
#includeutility

unsigned int N;
float * a, *b, *c;

void bar() {
#pragma GCC ivdep
  for (auto i=0U; iN; ++i)
a[i] = b[i]*c[i];
}



templateint N
struct SoA {
  using s_t = unsigned int;   
  using Ind = unsigned int;

  auto size() const { return m_n;}

  float  operator()(Ind i, Ind j) { return data[j][i];}
  float const  operator()(Ind i, Ind j) const { return data[j][i];}

  std::arraystd::vectorfloat,N data;
  s_t m_n=0;
};


templateint N
void doT(SoAN  soa) {
#pragma GCC ivdep
  for (auto i=0U; isoa.size(); ++i)
soa(i,0) = soa(i,1)*soa(i,2);
}


void doIt(SoA3  soa) {
  doT(soa);
}


produces

c++ -std=c++1y -Ofast -Wall -fopt-info-vec -fno-tree-slp-vectorize
-march=nehalem -S NaiveDod.cc
NaiveDod.cc:10:17: note: loop vectorized
NaiveDod.cc:10:17: note: loop peeled for vectorization to enhance alignment
NaiveDod.cc: In function 'void doIt(SoA3)':
NaiveDod.cc:34:17: internal compiler error: in expand_ANNOTATE, at
internal-fn.c:127
   for (auto i=0U; isoa.size(); ++i)
 ^
0x9e9a97 expand_ANNOTATE
../../gcc-trunk/gcc/internal-fn.c:127
0x820a7a expand_call_stmt
../../gcc-trunk/gcc/cfgexpand.c:2236
0x820a7a expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:3202
0x820a7a expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:3354
0x821aee expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:5194
0x823746 execute
../../gcc-trunk/gcc/cfgexpand.c:5803
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.


c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w4/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk//configure
--prefix=/afs/cern.ch/user/i/innocent/w4 --enable-languages=c,c++,lto,fortran
-enable-gold=yes --enable-lto --with-gmp-lib=/usr/local/lib64
--with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
--enable-cloog-backend=isl --with-cloog=/usr/local
--with-ppl-lib=/usr/local/lib64 -enable-libitm -disable-multilib
Thread model: posix
gcc version 4.10.0 20140520 (experimental) [trunk revision 210630] (GCC)

[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-- with -m32

2014-05-20 Thread zhenqiang.chen at linaro dot org

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

--- Comment #3 from zhenqiang.chen at linaro dot org ---
I can not reproduce gcc.dg/guality/pr43051-1.c fail with options

-fno-diagnostics-show-caret -fdiagnostics-color=never  -O3 -fomit-frame-pointer
-funroll-all-loops -m32 -mtune=core2

What are your final options to build the test case?

[Bug go/61246] New: gccgo: ICE in do_determine_types [GoSmith]

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

Bug ID: 61246
   Summary: gccgo: ICE in do_determine_types [GoSmith]
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dvyukov at google dot com

$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,go --disable-bootstrap
--enable-checking=yes --disable-multilib --prefix=gcc_trunk/install
Thread model: posix
gcc version 4.10.0 20140516 (experimental) (GCC) 

The reproducer is attached.

$ go build -compiler=gccgo 0.go 
go1: internal compiler error: in do_determine_types, at
go/gofrontend/statements.cc:400
0x6078ed Temporary_statement::do_determine_types()
../../gcc/go/gofrontend/statements.cc:400
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x6073fa If_statement::do_determine_types()
../../gcc/go/gofrontend/statements.cc:3166
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x6073fa If_statement::do_determine_types()
../../gcc/go/gofrontend/statements.cc:3166
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x6073fa If_statement::do_determine_types()
../../gcc/go/gofrontend/statements.cc:3166
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x5d2d4b Block::determine_types()
../../gcc/go/gofrontend/gogo.cc:5410
0x5d5ad8 Function::determine_types()
../../gcc/go/gofrontend/gogo.cc:4562
0x5d5ad8 Gogo::determine_types()
../../gcc/go/gofrontend/gogo.cc:2755
0x5cea3c go_parse_input_files(char const**, unsigned int, bool, bool)
../../gcc/go/gofrontend/go.cc:107

[Bug go/61246] gccgo: ICE in do_determine_types [GoSmith]

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

--- Comment #1 from Dmitry Vyukov dvyukov at google dot com ---
Created attachment 32825
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32825action=edit
reproducer

[Bug tree-optimization/61247] New: vectorization fails if conversion from unsigned int to signed int is involved

2014-05-20 Thread vincenzo.innocente at cern dot ch

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

Bug ID: 61247
   Summary: vectorization fails if conversion from unsigned int to
signed int is involved
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch

in the following example
cat uintLoop.cc
unsigned int N;
float * a, *b, *c;

using Ind = /*unsigned*/ int;
inline
float  val(float * x, Ind i) { return x[i];}
inline
float const  val(float const * x, Ind i) { return x[i];}

void foo() {
#pragma GCC ivdep
  for (auto i=0U; iN; ++i)
val(a,i) = val(b,i)*val(c,i);
}


using Ind = /*unsigned*/ int;
does not vectorize with
c++ -std=c++1y -Ofast -Wall -fopt-info-vec-missed -fno-tree-slp-vectorize
-march=nehalem -S uintLoop.cc
uintLoop.cc:12:17: note: not vectorized: not suitable for gather load _8 =
*_17;

uintLoop.cc:12:17: note: bad data references.


using Ind = unsigned int;
vectorize fine


minor, just annoying

[Bug tree-optimization/61247] vectorization fails if conversion from unsigned int to signed int is involved

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 Target||LP64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-20
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
This is a LP64 issue.  In that on x32 or x86 (or ILP32 with AARCH64), we can
vectorize this.

[Bug c/61236] GCC 4.9 generates incorrect object code

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

--- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)
 If you believe the nonnull attribute on qsort is incorrect, then you should
 report that as glibc bug, not gcc bug, the prototype is provided by glibc.
 The more aggressive GCC optimization is documented e.g. in
 https://gcc.gnu.org/gcc-4.9/porting_to.html
 plus we hope to add -fsanitize=undefined instrumentation for this in the
 upcoming GCC version, so you find it out more easily.

It is not incorrect as the C standard says this about qsort:
nmemb can have the value zero on a call to that function; the comparison
function is not called, a search ﬁnds no matching element, and sorting performs
no rearrangement. Pointer arguments on such a call shall still have valid
values, as described in 7.1.4.

POSIX 2008 defers to the C standard now so this is neither a glibc or a GCC bug
in the end.

[Bug c/61236] GCC 4.9 generates incorrect object code

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

--- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #11) 
 It is not incorrect as the C standard says this about qsort:
 nmemb can have the value zero on a call to that function; the comparison
 function is not called, a search ﬁnds no matching element, and sorting
 performs no rearrangement. Pointer arguments on such a call shall still have
 valid values, as described in 7.1.4.

7.1.4 says this:
Each of the following statements applies unless explicitly stated otherwise in
the detailed
descriptions that follow: If an argument to a function has an invalid value
(such as a value
outside the domain of the function, or a pointer outside the address space of
the program,
or a null pointer, or a pointer to non-modiﬁable storage when the corresponding
parameter is not const-qualiﬁed) or a type (after promotion) not expected by a
function
with variable number of arguments, the behavior is undeﬁned.

So there is not need to say it was detected to be non-null as the null pointer
case is mentioned in 7.1.4.

[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-05-20 Thread bugdal at aerifal dot cx

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

--- Comment #19 from Rich Felker bugdal at aerifal dot cx ---
Here is the commit that seems to have introduced the bug:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=df8d3e8981a99e264b49876f0f5064bdb30ac981

In the function ctor_for_folding, the following erroneous logic appears:

+  /* Non-readonly alias of readonly variable is also de-facto readonly,
+ because the variable itself is in readonly section.  
+ We also honnor READONLY flag on alias assuming that user knows
+ what he is doing.  */
+  if (!TREE_READONLY (decl)  !TREE_READONLY (real_decl))
+return error_mark_node;

This treats the value of an alias as a compile-time constant if either the
alias itself or the alias target has TREE_READONLY being true. Replacing the 
with || seems to make the problem go away in my test case, and makes a bit more
sense (perhaps that was the original intent?), but it's only sufficient if
TREE_READONLY is always false for weak aliases (since they can always be
overridden by a strong symbol from another translation unit, even if the alias
is const-qualified). I'm not sure where the value of TREE_READONLY is set for
aliases yet but I'll keep looking...

[Bug tree-optimization/61221] [4.10 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu

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

--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Tue May 20 08:16:13 2014
New Revision: 210633

URL: http://gcc.gnu.org/viewcvs?rev=210633root=gccview=rev
Log:
2014-05-20  Richard Biener  rguent...@suse.de

PR tree-optimization/61221
* tree-ssa-pre.c (el_to_update): Remove.
(eliminate_dom_walker::before_dom_children): Handle released
VDEFs by value-numbering them to the associated VUSE.  Update
stmt immediately for substituted call address.
(eliminate): Remove delayed stmt updating code.
* tree-ssa-sccvn.c (vuse_ssa_val): New function valueizing
possibly late re-numbered vuses.
(vn_reference_lookup_2): Adjust.
(vn_reference_lookup_pieces): Likewise.
(vn_reference_lookup): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c

[Bug middle-end/61245] ICE at in expand_ANNOTATE, at internal-fn.c:127 called from cfgexpand.c

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-20
 CC||burnus at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|tree-optimization   |middle-end
 Ever confirmed|0   |1
  Known to fail||4.10.0, 4.9.0

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed.  An ANNOTATE survives CFG building:

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5
;;
;; Loop 1
;;  header 4, latch 3
;;  depth 1, outer 0
;;  nodes: 4 3

void doT(SoAN) [with int N = 3] (struct SoA  soa)
{
...
  bb 3:
  D.30093 = SoA3::operator() (soa, i, 0);
  D.30094 = SoA3::operator() (soa, i, 1);
  D.30095 = *D.30094;
  D.30096 = SoA3::operator() (soa, i, 2);
  D.30097 = *D.30096;
  D.30098 = D.30095 * D.30097;
  *D.30093 = D.30098;
  i = i + 1;

  bb 4:
  D.30101 = SoA3::size (soa);
  D.30102 = D.30101  i;
  D.30100 = ANNOTATE (D.30102, 0);
  retval.4 = D.30100;
  if (retval.4 != 0)
goto bb 3;
  else
goto bb 5;

  bb 5:

[Bug go/61248] New: gccgo: spurious error: too many arguments [GoSmith]

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

Bug ID: 61248
   Summary: gccgo: spurious error: too many arguments [GoSmith]
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dvyukov at google dot com

gcc version 4.10.0 20140516 (experimental) (GCC)

Program:

package main
func main() {
var f func(int, interface{})
go f(0, recover())
}

$ go build -compiler=gccgo args.go 
args.go:5:10: error: too many arguments
  go f(0, recover())

[Bug c++/61245] ICE at in expand_ANNOTATE, at internal-fn.c:127 called from cfgexpand.c

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

  Component|middle-end  |c++

--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
For some reason we create a temporary, probably because the very specific
ANNOTATE is inside a cleanup_point:

if (cleanup_point ANNOTATE_EXPR SoA3::size ((struct SoA *) soa)  i,
ivdep) goto D.28269; else goto D.28267;

that is, the wrapped expressions has side-effects.  We should build the
ANNOTATE_EXPR outside of that cleanup.

C++ FE support issue.

[Bug c++/61242] [4.9/4.10 Regression] Bogus no matching function for call to ‘Foo::Create(brace-enclosed initializer list)

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.1

[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-05-20 Thread bugdal at aerifal dot cx

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

--- Comment #20 from Rich Felker bugdal at aerifal dot cx ---
On further investigation, it looks like the code I cited deals with strong
aliases as well as weak ones, and in the strong alias case, the strong folding
behavior might be desirable. A better fix seems to be adding an explicit check
for weak aliases (DECL_WEAK(decl)) when an alias is found and returning
error_mark_node in that case.

Note that prior to the above-mentioned commit, the !TREE_READONLY(decl) case
was always treated as non-foldable, so there seems to have been no subtlety to
avoiding errors with weak aliases. But the new code performs much more
aggressive constant folding and thus needs to avoid stepping on weak aliases.

[Bug rtl-optimization/61241] built-in memset makes the caller function slower

2014-05-20 Thread ktkachov at gcc dot gnu.org

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Can you please send the patch to gcc-patc...@gcc.gnu.org including a ChangeLog

[Bug c/61240] [4.8/4.9/4.10 Regression] Incorrect warning integer overflow in expression on pointer-pointer subtraction

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-20
   Target Milestone|--- |4.8.3
Summary|Incorrect warning integer  |[4.8/4.9/4.10 Regression]
   |overflow in expression on  |Incorrect warning integer
   |pointer-pointer subtraction |overflow in expression on
   ||pointer-pointer subtraction
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
We warn for

 integer_cst 0x76d54e28 type integer_type 0x76c407e0 long int
constant public overflow 1

via c-common.c:overflow_warning called from

#1  0x0065b80e in parser_build_binary_op (location=5653, 
code=MINUS_EXPR, arg1=..., arg2=...)
at /space/rguenther/src/svn/trunk/gcc/c/c-typeck.c:3411
#2  0x0068f5ed in c_parser_binary_expression (parser=0x76d67000, 
after=0x0, omp_atomic_lhs=tree 0x0)
at /space/rguenther/src/svn/trunk/gcc/c/c-parser.c:6282
#3  0x0068dfee in c_parser_conditional_expression (
parser=0x76d67000, after=0x0, omp_atomic_lhs=tree 0x0)
at /space/rguenther/src/svn/trunk/gcc/c/c-parser.c:5934
#4  0x0068dd75 in c_parser_expr_no_commas (parser=0x76d67000, 
after=0x0, omp_atomic_lhs=tree 0x0)
at /space/rguenther/src/svn/trunk/gcc/c/c-parser.c:5852

when building p - (p + -1U) which gets simplified to - -1U - 1U (with overflow
set - as it's sizetype arithmetic).  pointer_diff is guilty here which calls

  /* First do the subtraction as integers;
 then drop through to build the divide operator.
 Do not do default conversions on the minus operator
 in case restype is a short type.  */

  op0 = build_binary_op (loc,
 MINUS_EXPR, convert (inttype, op0),
 convert (inttype, op1), 0);

doing 0 - -1U, converting them to inttype (long int) first.  I suggest
to do that conversion and strip overflow bits in the POINTER_PLUS_EXPR
decomposition part.

[Bug target/60991] [avr] Stack corruption when using 24-bit integers int24 or memx pointers in large stack frame

2014-05-20 Thread gjl at gcc dot gnu.org

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

--- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org ---
Author: gjl
Date: Tue May 20 08:37:50 2014
New Revision: 210635

URL: http://gcc.gnu.org/viewcvs?rev=210635root=gccview=rev
Log:
gcc/
2014-05-20  Senthil Kumar Selvaraj  senthil_kumar.selva...@atmel.com

Backport from mainline r210325
2014-05-12  Senthil Kumar Selvaraj  senthil_kumar.selva...@atmel.com

PR target/60991
* config/avr/avr.c (avr_out_store_psi): Use correct constant
to restore Y.

gcc/testsuite/
2014-05-20  Senthil Kumar Selvaraj  senthil_kumar.selva...@atmel.com

Backport from mainline r210325
2014-05-12  Senthil Kumar Selvaraj  senthil_kumar.selva...@atmel.com

PR target/60991
* gcc.target/avr/pr60991.c: New testcase.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/avr/pr60991.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/avr/avr.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/61239] [4.10 Regression]: ICE in decompose, at rtl.h when compiling vshuf-v16hi.c using -mavx2

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

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

[Bug debug/61237] gcc puts line number 11 ahead of line number 10 in function call in debug info

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

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Well, '-foo (2, 3)' _has_ to be executed before the call to foo.  line-numbers
are a bad representation for C sequence point rules.

I would say this is not a bug.

[Bug target/60991] [avr] Stack corruption when using 24-bit integers int24 or memx pointers in large stack frame

2014-05-20 Thread gjl at gcc dot gnu.org

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |RESOLVED
  Known to work||4.7.4, 4.8.3, 4.9.1
   Keywords||wrong-code
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.1
  Known to fail|4.7.2, 4.8.1|4.7.3, 4.8.2, 4.9.0
   Severity|critical|normal

--- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org ---
Fixed in 4.7.4, 4.8.3, 4.9.1

[Bug c/61236] GCC 4.9 generates incorrect object code

2014-05-20 Thread jakub at gcc dot gnu.org

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

--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #11)
 It is not incorrect as the C standard says this about qsort:
 nmemb can have the value zero on a call to that function; the comparison
 function is not called, a search ﬁnds no matching element, and sorting
 performs no rearrangement. Pointer arguments on such a call shall still have
 valid values, as described in 7.1.4.
 
 POSIX 2008 defers to the C standard now so this is neither a glibc or a GCC
 bug in the end.

I've missed the Pointer arguments on such a call shall still have
valid values, as described in 7.1.4. sentence in C99 7.20.5 (was looking for
that in 7.20.5.2), with that it is exactly the same thing in this regard as
memcpy etc.

[Bug c/61236] GCC 4.9 generates incorrect object code

2014-05-20 Thread muks at banu dot com

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

--- Comment #14 from Mukund Sivaraman muks at banu dot com ---
(In reply to Jakub Jelinek from comment #10)
 But the compiler doesn't know there that x is NULL.  The compiler sees a

See comment #3. It generates 2 codepaths, one where (nalloc == 0) and another
where (nalloc != 0). For the former, it deletes the if statement and
isc_mem_put() call at the free_rdatas label completely:

 free_rdatas:
if (x != NULL)
isc_mem_put(mctx, x, nalloc * sizeof(struct xrdata));
return (result);
}

and instead reduces free_rdata's definition to:

 free_rdatas:
return (result);
}

How does the compiler do that if it has not inferred that x is NULL there?

OTOH, you're the compiler developers, so if you say it doesn't know that x is
NULL, then that is that. :) Maybe the part of compiler code that does this
doesn't know it.

Note that despite all this discussion of correctness, this optimization is
counter intuitive and will bite developers. There should at least be warnings
where they could be generated.

The point about correctness with C standards is taken and agreed.

See what is happening from a programmer's point of view: an explicit NULL check
is deleted. There are no warnings about qsort() used with NULL arguments where
it seems the compiler could warn (see above). Also consider the use of notnull
as an API annotation change by 3rd party libraries, which can make caller code
buggy without any way to notice it.

At the very least, if it is possible to detect that the pointer is NULL by
static analysis and it is being passed to a function that has the notnull
attribute, please warn mentioning inferences being made.

[Bug c/61236] GCC 4.9 generates incorrect object code

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

--- Comment #15 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Mukund Sivaraman from comment #14)
 (In reply to Jakub Jelinek from comment #10)
  But the compiler doesn't know there that x is NULL.  The compiler sees a
 
 See comment #3. It generates 2 codepaths, one where (nalloc == 0) and
 another where (nalloc != 0). For the former, it deletes the if statement and
 isc_mem_put() call at the free_rdatas label completely:
 
  free_rdatas:
 if (x != NULL)
 isc_mem_put(mctx, x, nalloc * sizeof(struct xrdata));
   return (result);
 }
 
 and instead reduces free_rdata's definition to:
 
  free_rdatas:
   return (result);
 }
 
 How does the compiler do that if it has not inferred that x is NULL there?
 
 OTOH, you're the compiler developers, so if you say it doesn't know that x
 is NULL, then that is that. :) Maybe the part of compiler code that does
 this doesn't know it.
 
 Note that despite all this discussion of correctness, this optimization is
 counter intuitive and will bite developers. There should at least be
 warnings where they could be generated.
 
 The point about correctness with C standards is taken and agreed.
 
 See what is happening from a programmer's point of view: an explicit NULL
 check is deleted. There are no warnings about qsort() used with NULL
 arguments where it seems the compiler could warn (see above). Also consider
 the use of notnull as an API annotation change by 3rd party libraries, which
 can make caller code buggy without any way to notice it.
 
 At the very least, if it is possible to detect that the pointer is NULL by
 static analysis and it is being passed to a function that has the notnull
 attribute, please warn mentioning inferences being made.
The warning did not make it into gcc 4.9 due to the patches to do the warning
were not ready. Gcc 4.10 should warn about it. If it does not then that is a
bug.

[Bug target/61249] New: _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments

2014-05-20 Thread mt at debian dot org

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

Bug ID: 61249
   Summary: _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss,
__builtin_ia32_vfrczsd require 2 arguments
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mt at debian dot org

Looking at https://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html on
the one hand and AMD's AMD64 Architecture Programmer’s Manual
Volume 6: 128-Bit and 256-Bit XOP and FMA4 Instructions on the other hand,
vfrczss/vfrczsd require a second argument to specify the destination.

Yet r205495 changed _mm_frcz_ss/_mm_frcz_sd so that only a single argument is
passed to the __builtin_ia32_vfrczss/vfrczsd calls.

This was detected at language level (inconsistent types), I can only speculate
that this may cause invalid code to be generated (or null operands).

Best,
Michael

PS.: The problem persists in the 4.9 branch as xopintrin.h hasn't been touched
since 4.8.

[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra

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

--- Comment #23 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Adding -Wall to the dg-options let the test succeed (in line with the gfortran
manual, see comment 21):

--- ../_clean/gcc/testsuite/gfortran.dg/wextra_1.f2012-10-21
13:06:18.0 +0200
+++ gcc/testsuite/gfortran.dg/wextra_1.f2014-05-15 12:05:56.0 +0200
@@ -1,5 +1,5 @@
 ! { dg-do compile }
-! { dg-options -Wextra }
+! { dg-options -Wall -Wextra }
   program main
   integer, parameter :: x=3 ! { dg-warning Unused parameter }
   real :: a

Indeed the questions asked in comment 22 should be answered.

[Bug c/61236] GCC 4.9 generates incorrect object code

2014-05-20 Thread muks at banu dot com

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

--- Comment #16 from Mukund Sivaraman muks at banu dot com ---
(In reply to Andrew Pinski from comment #15)
  At the very least, if it is possible to detect that the pointer is NULL by
  static analysis and it is being passed to a function that has the notnull
  attribute, please warn mentioning inferences being made.
 The warning did not make it into gcc 4.9 due to the patches to do the
 warning were not ready. Gcc 4.10 should warn about it. If it does not then
 that is a bug.

Thank you for this. :) It should detect at least some cases in that case.

If qsort() can cause this sort of disruption to a caller if NULL is passed, I
guess a change in glibc to add an assert(base != NULL) or similar abort is also
in order given that the caller code becomes buggy otherwise. Do you agree? This
would catch remaining cases before any inferred decisions are executed after
the qsort().

[Bug pch/61250] New: Random pch failures on x86_64-apple-darwin13.

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

Bug ID: 61250
   Summary: Random pch failures on x86_64-apple-darwin13.
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org
  Host: x86_64-apple-darwin13
Target: x86_64-apple-darwin13
 Build: x86_64-apple-darwin13

When running the test suite on x86_64-apple-darwin13 with -j8 (4 cores, 8
threads), I see random failures for the tests

g++.dg/pch/pch.C 
gcc.dg/pch/save-temps-1.c

They are either an ICE:

Internal compiler error: Error reporting routines re-entered.

(may be related to pr59877), or a program timed out leading to an assembly
comparison:

WARNING: program timed out.
FAIL: g++.dg/pch/pch.C  -g -I. -Dwith_PCH (test for excess errors)
FAIL: g++.dg/pch/pch.C -g assembly comparison

AFAICT these failures occur for any set of options or -m32/-m64. The number of
failures ranges from 0 to 4/5 and seems (weakly) correlated to the machine load
(-j8+backup).

[Bug target/61249] _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments

2014-05-20 Thread ubizjak at gmail dot com

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

--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Michael Tautschnig from comment #0)
 Looking at https://gcc.gnu.org/onlinedocs/gcc/X86-Built-in-Functions.html on
 the one hand and AMD's AMD64 Architecture Programmer’s Manual
 Volume 6: 128-Bit and 256-Bit XOP and FMA4 Instructions on the other hand,
 vfrczss/vfrczsd require a second argument to specify the destination.
 
 Yet r205495 changed _mm_frcz_ss/_mm_frcz_sd so that only a single argument
 is passed to the __builtin_ia32_vfrczss/vfrczsd calls.

You should not use __builtin_* function directly. They are internal
implementation details, published interface is in relevant *.h files.

 This was detected at language level (inconsistent types), I can only
 speculate that this may cause invalid code to be generated (or null
 operands).

Did you see the runtime tests in the referred commit?

[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra

2014-05-20 Thread manu at gcc dot gnu.org

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

--- Comment #24 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #23)
 Adding -Wall to the dg-options let the test succeed (in line with the
 gfortran manual, see comment 21):

This is enough to make the test pass, but it is not enough to get the correct
behavior and it will get broken by other reason. The patch in comment #10 is
needed independently of what gfortran chooses.

[Bug target/61249] _mm_frcz_ss, _mm_frcz_sd: __builtin_ia32_vfrczss, __builtin_ia32_vfrczsd require 2 arguments

2014-05-20 Thread mt at debian dot org

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

--- Comment #2 from Michael Tautschnig mt at debian dot org ---
Thanks a lot for your quick reply.

  Yet r205495 changed _mm_frcz_ss/_mm_frcz_sd so that only a single argument
  is passed to the __builtin_ia32_vfrczss/vfrczsd calls.

 You should not use __builtin_* function directly. They are internal
 implementation details, published interface is in relevant *.h files.

Yes, sure. It would still be nice if they were well typed.

  This was detected at language level (inconsistent types), I can only
  speculate that this may cause invalid code to be generated (or null
  operands).

 Did you see the runtime tests in the referred commit?

Just re-ran those tests and looking at the generated assembly (should have done
that before, my apologies) it seems that two operands are generated:

vfrczsd %xmm1, %xmm0

and

vfrczss %xmm1, %xmm1

So shall I read this as an imprecision in documentation?

Best,
Michael

[Bug target/61195] single precision fmov does not need to switch mode

2014-05-20 Thread chrbr at gcc dot gnu.org

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from chrbr at gcc dot gnu.org ---
in 4.10

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

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

--- Comment #3 from Matthias Klose doko at gcc dot gnu.org ---
is test/compile sufficient, or do you have to run it?

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

2014-05-20 Thread fche at redhat dot com

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

--- Comment #4 from Frank Ch. Eigler fche at redhat dot com ---
 is test/compile sufficient, or do you have to run it?

Just compile.

[Bug fortran/61251] New: Hang in write from inside a function

2014-05-20 Thread peter.machon at arcor dot de

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

Bug ID: 61251
   Summary: Hang in write from inside a function
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.machon at arcor dot de

Writing from a functions stops execution of programs.

**

Simple code:

program test

write(*,*) f(3e0)

contains

function f(x)
real :: f,x
write(*,*)x
f=2e0*x
end function

end program

*

The write function inside the function f(x) causes the hang. Sorry if it is
supposed to be like this. But with e.g. the PGI compiler it works fine. 
I'm working with MacOSX 10.6.8 and a self-build gcc, downloaded from the gnu
page.


gfortran -v :

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/Users/pm/bin/gcc_4.8.2/libexec/gcc/x86_64-apple-darwin10.8.0/4.8.2/lto-wrapper
Target: x86_64-apple-darwin10.8.0
Configured with: ./configure --prefix=/Users/pm/bin/gcc_4.8.2/
Thread model: posix
gcc version 4.8.2 (GCC)

[Bug c++/61252] New: Invalid code produced for omp simd reduction(min:var) where var is reference

2014-05-20 Thread hazeman11 at gmail dot com

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

Bug ID: 61252
   Summary: Invalid code produced for omp  simd reduction(min:var)
where var is reference
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hazeman11 at gmail dot com

Created attachment 32826
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32826action=edit
minimal code with reduce_bad

Invalid code produced ( loop optimized out ) for case when reduction variable
is a reference. I've looked into OpenMP specification but didn't find 
requirement for reduction variable to be local ( althought I didn't spend much
time on it :) ).

System: ubuntu 12.04 64bit 

GCC -v
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-checking=release
--enable-languages=c,c++ --enable-multiarch --disable-multilib --enable-shared
--enable-threads=posix --with-abi=m64 --program-suffix=-4.9 --with-gmp=/usr/lib
--with-mpc=/usr/lib --with-mpfr=/usr/lib --without-included-gettext
--with-system-zlib --with-tune=generic --prefix=/usr/local
Thread model: posix
gcc version 4.9.1 20140514 (prerelease) (GCC) 

Compilation options:
g++ -fopenmp -O3 -g3 -ffast-math -Wall -ftree-vectorize -march=core-avx2 -c
test.cpp -o test.o

-- code --
void reduce_bad( int N, float* a0, float* a1, float maxstep )
{
#pragma omp simd reduction(min:maxstep)
for(int i=0;iN;i++) {
maxstep = std::min(a0[i],a1[i]);
}
}
---

and here is workaround for this bug

-- code --
void reduce_good( int N, float* a0, float* a1, float ret )
{
float maxstep = ret;

#pragma omp simd reduction(min:maxstep)
for(int i=0;iN;i++) {
maxstep = std::min(a0[i],a1[i]);
}

ret = maxstep;
}
--

[Bug c++/61252] Invalid code produced for omp simd reduction(min:var) where var is reference

2014-05-20 Thread jakub at gcc dot gnu.org

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
I see a problem in the OpenMP lowering, that said, I hope you know that your
testcase doesn't compute the minimum from all iterations, but just the last few
ones (without -fopenmp just the last one, with -fopenmp from one to
vectorization factor of the loop).  So the value you get doesn't make any
sense.

[Bug c++/61252] Invalid code produced for omp simd reduction(min:var) where var is reference

2014-05-20 Thread hazeman11 at gmail dot com

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

--- Comment #2 from hazeman11 at gmail dot com ---
Yep sorry for so stupid example. I've reduced it to bare minimum without
looking whether it does make sense. Ofcourse something like

maxstep = std::min(std::min(a0[i],a1[i]),maxstep);

would make much more sense. Inside of my original loop ( where i've spotted the
problem ) was much much larger.

[Bug go/61253] New: gccgo: spurious error: expected '-' or '=' [GoSmith]

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

Bug ID: 61253
   Summary: gccgo: spurious error: expected '-' or '='
[GoSmith]
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dvyukov at google dot com

gcc version 4.10.0 20140516 (experimental) (GCC)

The program is:

package main
func main() {
c := make(chan int)
v := new(int)
b := new(bool)
select {
case (*v), (*b) = -c:
}

}

$ go build -compiler=gccgo /tmp/switch.go
src.go:8:11: error: expected '-' or '='
  case (*v), (*b) = -c:

[Bug target/61223] [gcc-4.10 regression] libstdc++ build fail due to pop lr register

2014-05-20 Thread rearnsha at gcc dot gnu.org

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

Richard Earnshaw rearnsha at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-20
Summary|libstdc++ build fail due to |[gcc-4.10 regression]
   |pop lr register |libstdc++ build fail due to
   ||pop lr register
 Ever confirmed|0   |1

[Bug c++/61252] Invalid code produced for omp simd reduction(min:var) where var is reference

2014-05-20 Thread hazeman11 at gmail dot com

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

--- Comment #3 from hazeman11 at gmail dot com ---
Created attachment 32827
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32827action=edit
corrected minimal example

[Bug c++/58664] [c++11] ICE initializing array of incomplete type within union

2014-05-20 Thread paolo at gcc dot gnu.org

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

--- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue May 20 13:30:40 2014
New Revision: 210642

URL: http://gcc.gnu.org/viewcvs?rev=210642root=gccview=rev
Log:
/cp
2014-05-20  Paolo Carlini  paolo.carl...@oracle.com

PR c++/58664
* typeck2.c (cxx_incomplete_type_inform): New.
(cxx_incomplete_type_diagnostic): Use it.
* decl.c (grokdeclarator): Check the element type of an
incomplete array type; call the above.
* cp-tree.h (cxx_incomplete_type_inform): Declare.

/testsuite
2014-05-20  Paolo Carlini  paolo.carl...@oracle.com

PR c++/58664
* g++.dg/cpp0x/nsdmi-union6.C: New.
* g++.dg/parse/pr58664.C: Likewise.
* g++.dg/cpp0x/nsdmi6.C: Tweak.
* g++.dg/parse/crash31.C: Likewise.
* g++.dg/template/error2.C: Likewise.
* g++.dg/template/inherit8.C: Likewise.
* g++.dg/template/offsetof2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-union6.C
trunk/gcc/testsuite/g++.dg/parse/pr58664.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi6.C
trunk/gcc/testsuite/g++.dg/parse/crash31.C
trunk/gcc/testsuite/g++.dg/template/error2.C
trunk/gcc/testsuite/g++.dg/template/inherit8.C
trunk/gcc/testsuite/g++.dg/template/offsetof2.C

[Bug c++/58664] [c++11] ICE initializing array of incomplete type within union

2014-05-20 Thread paolo.carlini at oracle dot com

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |4.10.0

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Fixed for 4.10.0.

[Bug go/61254] New: gccgo: spurious error: slice end must be integer [GoSmith]

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

Bug ID: 61254
   Summary: gccgo: spurious error: slice end must be integer
[GoSmith]
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dvyukov at google dot com

gcc version 4.10.0 20140516 (experimental) (GCC) 

The program is:

package main
func main() {
((([][]int{})[:])[0])[0]++
}

$ go build -compiler=gccgo /tmp/index.go
src.go:4:15: error: slice end must be integer
  ((([][]int{})[:])[0])[0]++

gc compiles successfully.

[Bug go/61255] New: gccgo: spurious error: argument 2 has incompatible type [GoSmith]

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

Bug ID: 61255
   Summary: gccgo: spurious error: argument 2 has incompatible
type [GoSmith]
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dvyukov at google dot com

gcc version 4.10.0 20140516 (experimental) (GCC) 

The program is:

package main
func main() {
append([]byte{}, 0)[0]++
}

$ go build -compiler=gccgo src.go
src.go:4:2: error: argument 2 has incompatible type
  append([]byte{}, 0)[0]++


gc compiles successfully.

[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 CC||peter.machon at arcor dot de

--- Comment #37 from Dominique d'Humieres dominiq at lps dot ens.fr ---
*** Bug 61251 has been marked as a duplicate of this bug. ***

[Bug fortran/61251] Hang in write from inside a function

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The code is invalid: recursive I/O, see pr30617 for discussion (hanging is
darwin specific).

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

[Bug c++/58704] [c++11] ICE initializing array member of template class

2014-05-20 Thread paolo.carlini at oracle dot com

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Mine. Related to c++/58753 and c++/58930.

[Bug rtl-optimization/61241] built-in memset makes the caller function slower

2014-05-20 Thread ma.jiang at zte dot com.cn

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

--- Comment #4 from ma.jiang at zte dot com.cn ---
(In reply to ktkachov from comment #3)
 Can you please send the patch to gcc-patc...@gcc.gnu.org including a
 ChangeLog
Done! Thanks.

[Bug bootstrap/61210] [4.10 regression] bootstrap failure with clang

2014-05-20 Thread rsandifo at gcc dot gnu.org

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

--- Comment #8 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 
---
Author: rsandifo
Date: Tue May 20 14:18:44 2014
New Revision: 210645

URL: http://gcc.gnu.org/viewcvs?rev=210645root=gccview=rev
Log:
gcc/cp/
PR bootstrap/61210
* pt.c (tsubst_copy, tsubst_omp_for_iterator, tsubst_expr)
(tsubst_copy_and_build): Perform recursive substitutions in a
deterministic order.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug middle-end/61225] [4.10 Regression] Several new failures after r210458 on x86_64-- with -m32

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu.org

--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 I can not reproduce gcc.dg/guality/pr43051-1.c fail with options ...

The patch at https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01579.html fixes the
issues I saw on x86_64-apple-darwin13 (not an approval). 

I don't see the other issues at 
https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00155.html
in particular the guality test (not run on darwin): CCing H.J. Lu.

Personal opinion: the guality tests are just a mess that should be fixed or
removed.

[Bug lto/61256] New: [4.10 regression] Building spec2000/252.eon with LTO got a compfail after r210522

2014-05-20 Thread izamyatin at gmail dot com

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

Bug ID: 61256
   Summary: [4.10 regression] Building spec2000/252.eon with LTO
got a compfail after r210522
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com

Linking on x86 as follows

g++ -m64  -Ofast -flto -funroll-loops -m64 -Ofast -flto -funroll-loops 
-DSPEC_CPU2000_LP64 ...

gives

lto1: internal compiler error: in gimple_get_virt_method_for_vtable, at
gimple-fold.c:3276
0x730833 gimple_get_virt_method_for_vtable(long, tree_node*, unsigned long,
bool*)
../../gcc/gimple-fold.c:3276
0x730a23 gimple_get_virt_method_for_binfo(long, tree_node*, bool*)
../../gcc/gimple-fold.c:3377
0x77a133 record_target_from_binfo
../../gcc/ipa-devirt.c:867
0x77a30f record_target_from_binfo
../../gcc/ipa-devirt.c:884
0x77a9bb possible_polymorphic_call_targets_1
../../gcc/ipa-devirt.c:931
0x77e609 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
../../gcc/ipa-devirt.c:1743
0x7a46f9 possible_polymorphic_call_targets
../../gcc/ipa-utils.h:121
0x7a46f9 walk_polymorphic_call_targets
../../gcc/ipa.c:177
0x7a46f9 symtab_remove_unreachable_nodes(bool, _IO_FILE*)
../../gcc/ipa.c:407
0x858ec7 execute_todo
../../gcc/passes.c:1843
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.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake: *** [eon] Error 1


Also 471.omnetpp from spec2006 fails with the same error

[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811

2014-05-20 Thread cltang at gcc dot gnu.org

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

--- Comment #10 from Chung-Lin Tang cltang at gcc dot gnu.org ---
The ICE still happens under -mno-lra (and using reload).

[Bug other/61257] New: configure should check if sys/sdt.h is usable, not just checking the existance of the header

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

Bug ID: 61257
   Summary: configure should check if sys/sdt.h is usable, not
just checking the existance of the header
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

splitting out to a new issue, this started in PR61231, and it came up before in
https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01122.html

(Note that strictly speaking, systemtap per se doesn't need to support
an architecture for the sys/sdt.h header file to work there.  gdb is 
a fully independent client of sys/sdt.h markers.)

Perhaps the way to go forward is to have the gcc configury test-compile
some toy sys/sdt.h code [1], and activate the probes only if that works.

[1]
#include sys/sdt.h

int main ()
{
   DTRACE_PROBE(foo,bar);
   return 0;
}

[Bug target/61231] [4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu

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

Matthias Klose doko at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #5 from Matthias Klose doko at gcc dot gnu.org ---
I was wrong about blaming the sys/sdt.h, header, and filed PR61257 for that.

Now I tracked down (with enough coffee I hope) r210519 as the patch introducing
the bootstrap failure.  Reverting it lets the bootstrap succeed on
powerpc64le-linux-gnu.

The build is configured with:

 --enable-secureplt
 --with-cpu=power7
 --with-tune=power8
 --disable-multilib
 --enable-multiarch
 --disable-werror
 --with-long-double-128
 --enable-checking=release
 --build=powerpc64le-linux-gnu
 --host=powerpc64le-linux-gnu
 --target=powerpc64le-linux-gnu

[Bug c++/60373] half warning: visibility attribute ignored because it

2014-05-20 Thread paolo at gcc dot gnu.org

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

--- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue May 20 15:16:48 2014
New Revision: 210646

URL: http://gcc.gnu.org/viewcvs?rev=210646root=gccview=rev
Log:
/cp
2014-05-20  Paolo Carlini  paolo.carl...@oracle.com

PR c++/60373
* decl.c (duplicate_decls): Replace pair of warning_at with
warning_at + inform.
(maybe_commonize_var): Likewise.

/testsuite
2014-05-20  Paolo Carlini  paolo.carl...@oracle.com

PR c++/60373
* g++.dg/cpp0x/Wattributes1.C: New.
* g++.dg/ext/visibility/redecl1.C: Adjust.
* g++.dg/ext/visibility/visibility-7.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wattributes1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/visibility/redecl1.C
trunk/gcc/testsuite/g++.dg/ext/visibility/visibility-7.C

[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4