Re: gcc 4.9.1 Bug or not

[Jakub Jelinek]

On Thu, Oct 09, 2014 at 01:54:57PM +0800, Rongqing Li wrote:
> The attachment is a piece of C code.
> When compile it with -O2 option, a segfault occurs:
> 
>   strncpy(new, old, cp-old);

It is a bug of course, but in the testcase.
Calling strncpy with NULL second argument, even when the size is 0,
is undefined behavior.
See http://gcc.gnu.org/gcc-4.9/porting_to.html

[Bug libquadmath/55821] Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2014-10/msg00736.ht
   ||ml

--- Comment #4 from Francois-Xavier Coudert  ---
Updated patch proposed:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00736.html

[Bug libquadmath/55821] Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported

[fxcoudert at gcc dot gnu.org]

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

--- Comment #5 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Thu Oct  9 07:40:39 2014
New Revision: 216027

URL: https://gcc.gnu.org/viewcvs?rev=216027&root=gcc&view=rev
Log:
PR libquadmath/55821
* Makefile.am: Conditionally define info_TEXINFOS and
libquadmath_TEXINFOS.
* Makefile.in: Regenerate.

Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/Makefile.am
trunk/libquadmath/Makefile.in

[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-09
 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This started with r205685.

The problem is in the x86 32-bit ABI, which decreases alignment of fields to 32
bits if the field has integral mode, or DFmode/DCmode or complex integral mode.

int
x86_field_alignment (tree field, int computed)
{
  enum machine_mode mode;
  tree type = TREE_TYPE (field);

  if (TARGET_64BIT || TARGET_ALIGN_DOUBLE)
return computed;
  mode = TYPE_MODE (strip_array_types (type));
  if (mode == DFmode || mode == DCmode
  || GET_MODE_CLASS (mode) == MODE_INT
  || GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)
return MIN (32, computed);
  return computed;
}

When the struct has only a single field, it is QImode, therefore despite the
user forced alignment the alignment is lowered to 32 bits.

Now, when actually laying out struct s fields, such as:
struct T { char a; struct s s; } t = { 1, { 2 } };
it actually is given 64-bit alignment, because ADJUST_FIELD_ALIGN is not used
in that case:
  if (! packed_p && ! DECL_USER_ALIGN (decl))
{
  /* Some targets (i.e. i386, VMS) limit struct field alignment
 to a lower boundary than alignment of variables unless
 it was overridden by attribute aligned.  */
#ifdef BIGGEST_FIELD_ALIGNMENT
  DECL_ALIGN (decl)
= MIN (DECL_ALIGN (decl), (unsigned) BIGGEST_FIELD_ALIGNMENT);
#endif
#ifdef ADJUST_FIELD_ALIGN
  DECL_ALIGN (decl) = ADJUST_FIELD_ALIGN (decl, DECL_ALIGN (decl));
#endif
}

As do_type_align for FIELD_DECLs sets DECL_USER_ALIGN:
static inline void
do_type_align (tree type, tree decl)
{
  if (TYPE_ALIGN (type) > DECL_ALIGN (decl))
{
  DECL_ALIGN (decl) = TYPE_ALIGN (type);
  if (TREE_CODE (decl) == FIELD_DECL)
DECL_USER_ALIGN (decl) = TYPE_USER_ALIGN (type);
}
}

if TYPE_USER_ALIGN is set, IMHO ADJUST_FIELD_ALIGN and corresponding 
BIGGEST_FIELD_ALIGNMENT will never be used.

[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 33670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33670&action=edit
gcc5-pr63495.patch

Untested fix.

[Bug libquadmath/55821] Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #6 from Francois-Xavier Coudert  ---
Fixed on trunk

[Bug tree-optimization/63381] [5 Regression] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Richard Biener  ---
Patch for 63380 fixes this as well.

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

[Bug tree-optimization/63380] [5 Regression] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
*** Bug 63381 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu Oct  9 08:20:53 2014
New Revision: 216028

URL: https://gcc.gnu.org/viewcvs?rev=216028&root=gcc&view=rev
Log:
2014-10-09  Richard Biener  

PR tree-optimization/63445
* tree-vrp.c (simplify_cond_using_ranges): Only warn about
overflow for non-equality compares.

* gcc.dg/Wstrict-overflow-26.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/Wstrict-overflow-26.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Oct  9 08:21:46 2014
New Revision: 216029

URL: https://gcc.gnu.org/viewcvs?rev=216029&root=gcc&view=rev
Log:
2014-10-09  Richard Biener  

PR tree-optimization/61969
* tree-nrv.c (pass_nrv::execute): Properly test for automatic
variables.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-nrv.c

[Bug lto/61969] [4.8/4.9 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.0
Summary|[4.8/4.9/5 Regression]  |[4.8/4.9 Regression] wrong
   |wrong code by LTO on|code by LTO on
   |i?86-linux-gnu (affecting   |i?86-linux-gnu (affecting
   |trunk, 4.9.x, and 4.8.x)|trunk, 4.9.x, and 4.8.x)

--- Comment #12 from Richard Biener  ---
Fixed on trunk sofar.

[Bug rtl-optimization/57003] [4.8/4.9/5.0 Regression] gcc breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

[uros at gcc dot gnu.org]

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

--- Comment #30 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Oct  9 08:22:23 2014
New Revision: 216030

URL: https://gcc.gnu.org/viewcvs?rev=216030&root=gcc&view=rev
Log:
Backport from mainline
2014-10-09  Uros Bizjak  

PR rtl-optimization/57003
* regcprop.c (copyprop_hardreg_forward_1): If ksvd.ignore_set_reg,
also check CALL_INSN_FUNCTION_USAGE for clobbers again after
killing regs_invalidated_by_call.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/regcprop.c

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Marek Polacek  ---
Fixed.

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Thu Oct  9 08:25:50 2014
New Revision: 216031

URL: https://gcc.gnu.org/viewcvs?rev=216031&root=gcc&view=rev
Log:
PR c/63480
* c-typeck.c (pop_init_level): Don't warn about initializing
with { }.

* gcc.dg/pr63480.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr63480.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/63489] stack allocated array pointer corrupted

[jonathan.hogg at stfc dot ac.uk]

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

--- Comment #3 from Jonathan Hogg  ---
Confirmed, this is the cause is the larger example as well. I had missed the
introduction of -fsanitize=address, useful feature. I'd assumed something like
that valgrind would have picked up for me however!

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #8 from Paolo Carlini  ---
I think we can anyway close this.

[Bug libstdc++/60132] C++11: lack of is_trivially_copy_constructible

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Oct  9 08:37:26 2014
New Revision: 216032

URL: https://gcc.gnu.org/viewcvs?rev=216032&root=gcc&view=rev
Log:
2014-10-09  Ville Voutilainen  

PR libstdc++/60132
* include/std/type_traits (is_trivially_copyable,
is_trivially_constructible, is_trivially_default_constructible,
is_trivially_copy_constructible, is_trivially_move_constructible,
is_trivially_assignable, is_trivially_copy_assignable,
is_trivially_move_assignable): New.
* testsuite/20_util/is_trivially_assignable/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_assignable/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/is_trivially_assignable/value.cc: Likewise.
* testsuite/20_util/is_trivially_constructible/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_constructible/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/is_trivially_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_copyable/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_copyable/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/is_trivially_copyable/value.cc: Likewise.
* testsuite/20_util/is_trivially_copy_assignable/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_copy_assignable/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/is_trivially_copy_assignable/value.cc: Likewise.
* testsuite/20_util/is_trivially_copy_constructible/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_copy_constructible/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/is_trivially_copy_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_default_constructible/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_default_constructible/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/is_trivially_default_constructible/
value.cc: Likewise.
* testsuite/20_util/is_trivially_move_assignable/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_move_assignable/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/is_trivially_move_assignable/value.cc: Likewise.
* testsuite/20_util/is_trivially_move_constructible/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/is_trivially_move_constructible/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/is_trivially_move_constructible/value.cc:
Likewise.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line number.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

Added:
trunk/libstdc++-v3/testsuite/20_util/is_trivially_assignable/
trunk/libstdc++-v3/testsuite/20_util/is_trivially_assignable/requirements/
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_assignable/requirements/explicit_instantiation.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_assignable/requirements/typedefs.cc
trunk/libstdc++-v3/testsuite/20_util/is_trivially_assignable/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_trivially_constructible/
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_constructible/requirements/
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_constructible/requirements/explicit_instantiation.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_constructible/requirements/typedefs.cc
trunk/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_assignable/
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_assignable/requirements/
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_assignable/requirements/explicit_instantiation.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_assignable/requirements/typedefs.cc
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_assignable/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_constructible/
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_constructible/requirements/
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_constructible/requirements/explicit_instantiation.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_constructible/requirements/typedefs.cc
   
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copy_constructible/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copyable/
trunk/libstdc++-v3/testsuite/20_util/is_trivially_c

[Bug libstdc++/60132] C++11: lack of is_trivially_copy_constructible

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|ville.voutilainen at gmail dot com |
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug target/63428] [4.8/4.9/5 Regression] vshuf-v4di.c miscompilation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/63379] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-09
 Ever confirmed|0   |1
  Known to fail||4.7.4, 4.8.3, 4.9.1, 5.0

--- Comment #2 from Richard Biener  ---
Confirmed.  We're choosing bogus "neutral" operands for MIN/MAX in the case of
SLP.  I am testing

Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 215917)
+++ gcc/tree-vect-slp.c (working copy)
@@ -2395,13 +2395,8 @@ vect_get_constant_vectors (tree op, slp_
 neutral_op = build_int_cst (TREE_TYPE (op), -1);
 break;

-  case MAX_EXPR:
-  case MIN_EXPR:
-def_stmt = SSA_NAME_DEF_STMT (op);
-loop = (gimple_bb (stmt))->loop_father;
-neutral_op = PHI_ARG_DEF_FROM_EDGE (def_stmt,
-loop_preheader_edge (loop));
-break;
+ /* For MIN/MAX we don't have an easy neutral operand but
+the initial values can be used fine here.  */

   default:
 neutral_op = NULL;

[Bug tree-optimization/63379] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
So fixed?

[Bug rtl-optimization/57003] [4.8/4.9/5.0 Regression] gcc breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

[uros at gcc dot gnu.org]

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

--- Comment #31 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Oct  9 09:05:37 2014
New Revision: 216035

URL: https://gcc.gnu.org/viewcvs?rev=216035&root=gcc&view=rev
Log:
Backport from mainline
2014-10-09  Uros Bizjak  

PR rtl-optimization/57003
* regcprop.c (copyprop_hardreg_forward_1): If ksvd.ignore_set_reg,
also check CALL_INSN_FUNCTION_USAGE for clobbers again after
killing regs_invalidated_by_call.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/regcprop.c

[Bug c++/63455] [4.8/4.9/5 Regression] decltype of statement expression internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:25062

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
This started with r171054 .

[Bug middle-end/63311] [4.9/5 Regression] -O1 optimization introduces valgrind warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r208687 , so possibly a latent bug is no longer latent after the
FE changes.

[Bug c++/51501] [DR 1433] decltype over-agressive SFINAE

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Jason Merrill from comment #4)
> Reduced:
> 
> template  T list(T x);
> 
> template 
> auto list(H h, T ...args) -> decltype(list(args...));
> 
> auto list3 = list(1, 2, 3);

Interestingly it works for (static or non-static) member functions:

struct X {
  template  T list(T x);

  template 
  auto list(H h, T ...args) -> decltype(list(args...));
};

auto list3 = X{}.list(1, 2, 3);

[Bug c++/51501] [DR 1433] decltype over-agressive SFINAE

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Also I guess we can unsuspend this and close as INVALID now that EWG rejected
it.

And maybe issue a diagnostic for comment 12, as EDG and clang do?

[Bug fortran/59488] [OpenMP] named constant in parallel construct leads to "not specified in enclosing parallel" error.

[bugs at stellardeath dot org]

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

Lorenz Hüdepohl  changed:

   What|Removed |Added

 CC||bugs at stellardeath dot org

--- Comment #3 from Lorenz Hüdepohl  ---
Any news on this one? We had to resort to guard all default(none) clauses with
#ifndef __GFORTRAN__, which feels a bit embarrassing :)

[Bug c++/46836] implement #pragma system_header "canonical_filename"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-09
Summary|reporting locations for |implement #pragma
   |names in std namespace  |system_header
   |could be improved   |"canonical_filename"
 Ever confirmed|0   |1

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to do...@seketeli.org from comment #8)
> > #pragma GCC system_header "canonical_name"
> 
> Seconded.

Thus, confirmed. Also, it should be an easy hack for a new contributor. Just
process the optional parameter, store the filename somehow, and when printing
diagnostic, use the canonical name if it exists. Also, adjust the #line
directive, so this works even in preprocessed files. I don't think it should
mess up with the original LOCATION_FILE(), since that is used for various other
things.

[Bug c/52981] Separate -Wpadded into two options

[RLynn at fundamentalsltd dot co.uk]

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

Roger Lynn  changed:

   What|Removed |Added

 CC||RLynn at fundamentalsltd dot 
co.uk

--- Comment #2 from Roger Lynn  ---
Note that bug 53514 is essentially the same bug for C++.

If I enable -Wpadded I am flooded with "padding struct size to alignment
boundary" warnings, which makes it difficult to find the rarer and much more
useful "padding struct to align ‘’" warnings.

[Bug lto/61969] [4.8/4.9 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Thu Oct  9 10:50:43 2014
New Revision: 216037

URL: https://gcc.gnu.org/viewcvs?rev=216037&root=gcc&view=rev
Log:
2014-10-09  Richard Biener  

PR tree-optimization/61969
* tree-nrv.c (pass_nrv::execute): Properly test for automatic
variables.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/tree-nrv.c

[Bug bootstrap/63496] New: ../../gcc/ipa-polymorphic-call.c:2117:1: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]

[sch...@linux-m68k.org]

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

Bug ID: 63496
   Summary: ../../gcc/ipa-polymorphic-call.c:2117:1: error:
assuming signed overflow does not occur when assuming
that (X + c) < X is always false
[-Werror=strict-overflow]
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: hubicka at gcc dot gnu.org

Broken by r216010

../../gcc/ipa-polymorphic-call.c: In function 'tree_node*
extr_type_from_vtbl_ptr_store(gimple, type_change_info*, long int*)':
../../gcc/ipa-polymorphic-call.c:2117:1: error: assuming signed overflow does
not occur when assuming that (X + c) < X is always false
[-Werror=strict-overflow]
 }
 ^

[Bug tree-optimization/63476] [5 Regression] ICE: tree check: expected ssa_name, have var_decl in walk_aliased_vdefs_1, at tree-ssa-alias.c:2689

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Ah,

#5  0x00c263c2 in ipa_polymorphic_call_context::get_dynamic_type (
this=0x7fffd790, instance=, 
otr_object=, 
otr_type=, call=)
at /space/rguenther/src/svn/trunk/gcc/ipa-polymorphic-call.c:1606
(gdb) l
1601  tci.multiple_types_encountered = false;
1602  tci.speculative = false;
1603  tci.seen_unanalyzed_store = false;
1604
1605  walk_aliased_vdefs (&ao, gimple_vuse (stmt),
check_stmt_for_type_change,
1606  &tci, NULL, &function_entry_reached);

this walks on gimple_vuse!

(gdb) p debug_gimple_stmt (stmt)
# VUSE <.MEM>
pretmp_5 = this_10(D)->D.2797._vptr.A;

VUSEs are not kept renamed by load PRE insertion phase so this will not work.

The function is called on the call

# .MEM_45 = VDEF <.MEM_6(D)>
OBJ_TYPE_REF(pretmp_1;(struct D)this_10(D)->0) (this_10(D), p1_11(D), p2_14(D),
0);


Of course it would be nice to keep virtual SSA form up-to-date during
PRE insertion, but as of now that was not necessary (and we can't simply
rename VOPs as that will break the SSA value-numbering lattice which includes
virtuals).  Keeping virtual SSA form up-to-date requires computing the
life virtual operand on edges (which means BB exit).

I'm going to try that.

[Bug bootstrap/63496] ../../gcc/ipa-polymorphic-call.c:2117:1: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
I don't know if it is the same one (strange line number):

  return offset + GET_MODE_BITSIZE (Pmode) <= offset

(missing tci-> on the first offset probably)

[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
Whoa.

VALUE RTXes are leaking into various RTX aliasing related functions like crazy!

As an example, please consider following patch for base_alias_check:

--cut here--
Index: alias.c
===
--- alias.c (revision 216025)
+++ alias.c (working copy)
@@ -1824,6 +1824,13 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
   if (rtx_equal_p (x_base, y_base))
 return 1;

+  if (GET_CODE (x) == VALUE || GET_CODE (y) == VALUE)
+{
+  debug_rtx (x);
+  debug_rtx (y);
+  gcc_unreachable ();
+}
+
   /* The base addresses are different expressions.  If they are not accessed
  via AND, there is no conflict.  We can bring knowledge of object
  alignment into play here.  For example, on alpha, "char a, b;" can
--cut here--

The compiler dies immediately on the provided testcase.

One of the checks that trigger this condition in base_alias_check is:

(and:DI (lo_sum:DI (reg/f:DI 13 $13 [72])
(symbol_ref:DI ("aaa") [flags 0x6]  ))
(const_int -8 [0xfff8]))

with

(value:DI 7:3304360 @0x1b619ee0/0x1b614cb0)

and this is the reason why aliasing of aaa and bbb is not detected. The (VALUE)
RTX corresponds to:

cselib value 7:3304360 0x8a84cb0 (and:DI (lo_sum:DI (reg/f:DI 11 $11 [78])
(symbol_ref:DI ("bbb") [flags 0x6]  ))
(const_int -8 [0xfff8]))

so, there is no way for current code to detect aliasing between these two
RTXes.

This is IMO important RTL infrastructure problem.

[Bug c++/53514] Make -Wpadded a meta-option for -Wpadded-in-middle and -Wpadded-at-end

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez  ---
Marking it as a duplicate. There is only one place to update, this is not
specific to any FE.

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

[Bug c/52981] Separate -Wpadded into two options

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||david at doublewise dot net

--- Comment #3 from Manuel López-Ibáñez  ---
*** Bug 53514 has been marked as a duplicate of this bug. ***

[Bug c/52981] Separate -Wpadded into two options

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
This is quite easy to implement. Just add the two new options [*] to
common.opt, add EnabledBy(Wpadding) to them, then update the uses of
OPT_Wpadded and warn_padded throughout the source code and testsuite, then
update doc/invoke.texi. Bootstrap + regression test, submit patch, ping patch
until approved by a maintainer. Commit and add a note to gcc-5/changes.html.
Easy to do, but someone still needs to do all this work. 

If you think this is really worth it, please volunteer to do it. Nobody else
will.


[*] (I like David Stone's proposal of -Wpadded-in-middle and -Wpadded-at-end,
but whoever implements it gets to choose the names)

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
I still don't get it.  What we end up doing is

  reg:DI 72 = /u load from 'a'  (insn 6)
  reg:DI 78 = /u load from 'b'  (insn 15)
...
  RMW sequence on (mem:DI (reg:DI 72 ...
  store to (mem:SI (reg:DI 78 ...

thus completely fine (after sched1).  sched2 then moves the /u load from
'b' until after the R of the RMW sequence, but that's fine.

Now I think you seem to say that this isn't about /u or whatever but
the common issue that for example for globals

char c, d;

two RMW sequences to store to c and d may not overlap if 'c' and 'd' are
not padded out to DImode.

But this is an issue on all targets (ISTR a bug about this), and if
that happens it introduces a store data race that is not allowed with
the C++ memory model for example.  Bad luck for early alphas then I'd say.

At least I can see nothing wrong with the code generated for the two testcases
you provided nor is the fix you propose any good (I see nothing else but
the (and:DI ...) addressing that might possibly serve as "barrier" here,
but even that would not be enough for, say

char c __attribute__((aligned(8)));
char d;

because then we hopefully optimize that AND away for the load from c.

Can you clarify whether I miss anything with the code generated for the
testcase?

[Bug c++/63497] New: std::regex can't handle [^class] correctly and cause runtime crash

[moophy at foxmail dot com]

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

Bug ID: 63497
   Summary: std::regex can't handle [^class] correctly and cause
runtime crash
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moophy at foxmail dot com

Created attachment 33671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33671&action=edit
preprocessed source files generated

When using pattern : "([a-z]*)([^c])(e)(i)([a-z]*)", it incorrectly matched the
input "cei" and caused runtime crash when iterating through the std::smatch
container.

Source:

#include 
#include 
#include 

int main()
{
std::string pattern("([a-z]*)([^c])(e)(i)([a-z]*)");
std::regex r(pattern);
std::smatch results;
std::string test_str = "cei";

if (std::regex_search(test_str, results, r))
{
std::cout << results.str() << std::endl;
for (size_t i = 0; i < results.size(); ++i)
std::cout << i << ": " << results[i].str() << '\n';
}
}

output:
cei
0: cei
1: cei
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create
Aborted (core dumped)

Command Line:
g++-4.9 -v -save-temps -std=c++11 -Wall -Wextra main.cpp

GCC Info:
Using built-in specs.
COLLECT_GCC=g++-4.9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.9/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.1-3ubuntu2~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror
--with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.9.1 (Ubuntu 4.9.1-3ubuntu2~14.04.1) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.9/cc1plus -E -quiet -v -imultiarch
i386-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=i686 -std=c++11
-Wall -Wextra -fpch-preprocess -fstack-protector -Wformat-security -o main.ii
ignoring duplicate directory "/usr/include/i386-linux-gnu/c++/4.9"
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i686-linux-gnu/4.9/../../../../i686-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.9
 /usr/include/i386-linux-gnu/c++/4.9
 /usr/include/c++/4.9/backward
 /usr/lib/gcc/i686-linux-gnu/4.9/include
 /usr/local/include
 /usr/lib/gcc/i686-linux-gnu/4.9/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.9/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=i686 -auxbase main -Wall -Wextra
-std=c++11 -version -fstack-protector -Wformat-security -o main.s
GNU C++ (Ubuntu 4.9.1-3ubuntu2~14.04.1) version 4.9.1 (i686-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.9.1-3ubuntu2~14.04.1) version 4.9.1 (i686-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 55bd930871a1c0a5ebd28bf15548c7c2
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 as -v --32 -o main.o main.s
GNU assembler version 2.24 (i686-linux-gnu) using BFD version (GNU Binutils for
Ubuntu) 2.24
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.9/:/usr/lib/gcc/i686-linux-gnu/4.9/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.9/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PA

[Bug tree-optimization/63379] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||50414

--- Comment #3 from Richard Biener  ---
The simple fix makes gcc.dg/vect/no-scevccp-noreassoc-slp-reduc-7.c ICE as
there
we have a MAX, y> reduction.  Not sure why this goes the SLP
way here - still need to investigate properly.  Ah, that testcase was added
when that broken MIN/MAX_EXPR handling was added:

r178941 | irar | 2011-09-18 13:36:15 +0200 (Sun, 18 Sep 2011) | 6 lines


PR tree-optimization/50414
* tree-vect-slp.c (vect_get_constant_vectors): Handle MAX_EXPR
and MIN_EXPR.

[Bug c++/63489] stack allocated array pointer corrupted

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I think valgrind only checks heap memory, so doesn't help for buffer overflows
on the stack.

[Bug c++/63497] std::regex can't handle [^class] correctly and cause runtime crash

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-09
 CC||timshen at gcc dot gnu.org
  Known to work||5.0
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This seems to be fixed on the trunk, but still crashes with 4.9.2

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #12)
> I still don't get it.  What we end up doing is
> 
>   reg:DI 72 = /u load from 'a'  (insn 6)
>   reg:DI 78 = /u load from 'b'  (insn 15)
> ...
>   RMW sequence on (mem:DI (reg:DI 72 ...
>   store to (mem:SI (reg:DI 78 ...
> 
> thus completely fine (after sched1).  sched2 then moves the /u load from
> 'b' until after the R of the RMW sequence, but that's fine.

This is wrong. The move should not pass the W part of the RMW sequence.

> Now I think you seem to say that this isn't about /u or whatever but
> the common issue that for example for globals
> 
> char c, d;
> 
> two RMW sequences to store to c and d may not overlap if 'c' and 'd' are
> not padded out to DImode.
> 
> But this is an issue on all targets (ISTR a bug about this), and if
> that happens it introduces a store data race that is not allowed with
> the C++ memory model for example.  Bad luck for early alphas then I'd say.

Yes, this is the problem. For the original problem, "c" and "d" live in the
same 8-byte memory location. So memory access with 8-byte granularity aliases
both values. There is a code that prevents memory reads to be moved across
memory writes with alignment ANDs, but /u reads get treated specially and
bypass this code under "can't alias anything due to constness" assumption.

> At least I can see nothing wrong with the code generated for the two
> testcases
> you provided nor is the fix you propose any good (I see nothing else but
> the (and:DI ...) addressing that might possibly serve as "barrier" here,
> but even that would not be enough for, say
> 
> char c __attribute__((aligned(8)));
> char d;
> 
> because then we hopefully optimize that AND away for the load from c.

True, but there will be alignment ANDs in the access of "d". This is the reason
to check both operands for ANDs and in this case pass them down to the code
that handles operands with alignment ANDs to determine their aliasing.

> Can you clarify whether I miss anything with the code generated for the
> testcase?

If we can't guarantee that the value lives outside aliased location, then reads
of this value should not pass writes with alignment ANDs (that could possibly
alias the location of read), no matter if they are /u or not.

IMO, /u reads should be handled as non-/u reads and should not pass writes with
alignment ANDs. This is what my patch does.

[Bug tree-optimization/63379] [4.8/4.9/5 Regression] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.6.3
   Target Milestone|--- |4.8.4
Summary|Incorrect vectorization |[4.8/4.9/5 Regression]
   |when enabling SSE and O3,   |Incorrect vectorization
   |initialises loop with wrong |when enabling SSE and O3,
   |value   |initialises loop with wrong
   ||value

--- Comment #4 from Richard Biener  ---
Makes it a regression.

[Bug tree-optimization/63380] [5 Regression] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug tree-optimization/63380] [5 Regression] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Oct  9 12:45:07 2014
New Revision: 216038

URL: https://gcc.gnu.org/viewcvs?rev=216038&root=gcc&view=rev
Log:
2014-10-09  Richard Biener  

PR tree-optimization/63380
* tree-ssa-tail-merge.c (stmt_local_def): Exclude stmts that
may trap.

* gcc.dg/torture/pr63380-1.c: New testcase.
* gcc.dg/torture/pr63380-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr63380-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr63380-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-tail-merge.c

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Thu, 9 Oct 2014, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
> 
> --- Comment #13 from Uroš Bizjak  ---
> (In reply to Richard Biener from comment #12)
> > I still don't get it.  What we end up doing is
> > 
> >   reg:DI 72 = /u load from 'a'  (insn 6)
> >   reg:DI 78 = /u load from 'b'  (insn 15)
> > ...
> >   RMW sequence on (mem:DI (reg:DI 72 ...
> >   store to (mem:SI (reg:DI 78 ...
> > 
> > thus completely fine (after sched1).  sched2 then moves the /u load from
> > 'b' until after the R of the RMW sequence, but that's fine.
> 
> This is wrong. The move should not pass the W part of the RMW sequence.
> 
> > Now I think you seem to say that this isn't about /u or whatever but
> > the common issue that for example for globals
> > 
> > char c, d;
> > 
> > two RMW sequences to store to c and d may not overlap if 'c' and 'd' are
> > not padded out to DImode.
> > 
> > But this is an issue on all targets (ISTR a bug about this), and if
> > that happens it introduces a store data race that is not allowed with
> > the C++ memory model for example.  Bad luck for early alphas then I'd say.
> 
> Yes, this is the problem. For the original problem, "c" and "d" live in the
> same 8-byte memory location. So memory access with 8-byte granularity aliases
> both values. There is a code that prevents memory reads to be moved across
> memory writes with alignment ANDs, but /u reads get treated specially and
> bypass this code under "can't alias anything due to constness" assumption.
> 
> > At least I can see nothing wrong with the code generated for the two
> > testcases
> > you provided nor is the fix you propose any good (I see nothing else but
> > the (and:DI ...) addressing that might possibly serve as "barrier" here,
> > but even that would not be enough for, say
> > 
> > char c __attribute__((aligned(8)));
> > char d;
> > 
> > because then we hopefully optimize that AND away for the load from c.
> 
> True, but there will be alignment ANDs in the access of "d". This is the 
> reason
> to check both operands for ANDs and in this case pass them down to the code
> that handles operands with alignment ANDs to determine their aliasing.
> 
> > Can you clarify whether I miss anything with the code generated for the
> > testcase?
> 
> If we can't guarantee that the value lives outside aliased location, then 
> reads
> of this value should not pass writes with alignment ANDs (that could possibly
> alias the location of read), no matter if they are /u or not.
> 
> IMO, /u reads should be handled as non-/u reads and should not pass writes 
> with
> alignment ANDs. This is what my patch does.

I see.  But you don't touch write_dependence which has a similar check.
And instead of making the check for AND disable the MEM_READONLY_P
early-out wouldn't it be more correct to treat MEMs with AND addresses
as true barriers?  That is,

 if (GET_CODE (x_addr) == AND
 || GET_CODE (mem_addr) == AND)
   return 1;

 if (MEM_READONLY_P (x))
   return 0;

instead?  I see we're trying to be clever with AND addresses even
though they are "barriers", why's that?

Note that all this should only ever be an issue with that very old Alpha
as other archs should implement the C++ memory model properly.

Richard.

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to rguent...@suse.de from comment #14)

> I see.  But you don't touch write_dependence which has a similar check.

I have in fact changed all these places (I will attach the patch momentarily),
but the attached test check one location only. After the approach is considered
OK, the others are trivial to add.

> And instead of making the check for AND disable the MEM_READONLY_P
> early-out wouldn't it be more correct to treat MEMs with AND addresses
> as true barriers?  That is,
> 
>  if (GET_CODE (x_addr) == AND
>  || GET_CODE (mem_addr) == AND)
>return 1;
> 
>  if (MEM_READONLY_P (x))
>return 0;
> 
> instead?  I see we're trying to be clever with AND addresses even
> though they are "barriers", why's that?

This was my first approach. But DImode (8-byte) reads, aligned to their natural
alignment, can't alias locations that are re-aligned to 8-bytes using alignment
ANDs. This is what the code downstream handles, so the approach, proposed above
would penalize DImode reads too much.

> Note that all this should only ever be an issue with that very old Alpha
> as other archs should implement the C++ memory model properly.

Unfortunately, I have to agree. The alternative would be a target-specific
change that would mark all memory in RMW sequence with some kind of barrier.
IMO, the generic change is preferable, since it doesn't affect other targets,
and makes aliasing more robust w.r.t. to target peculiarities.

[Bug target/62308] A bug with aarch64 big-endian

[venkataramanan.kumar at amd dot com]

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

--- Comment #7 from Venkataramanan  ---
I tried to look at the RTL and assembly code generated after the patch comitted
in 215707. 

The code generated looks good some unoptimal code but it is at -O0.

sub sp, sp, #16 // 15   *adddi3_aarch64/3   [length = 4]
mov x2, x0  // 2*movdi_aarch64/1[length = 4]
mov x0, x2  // 5*movdi_aarch64/1[length = 4]
fmovd0, x1  // 22   move_lo_quad_internal_be_v4si/2 [length = 4]
ins v0.d[1], x0 // 23   aarch64_simd_move_hi_quad_be_v4si/2
[length = 4]
str q0, [sp]// 7*aarch64_simd_movv4si/2 [length = 4]
nop // 13   nop [length = 4]
add sp, sp, 16  // 18   *adddi3_aarch64/1   [length = 4]
ret // 20   *do_return  [length = 4]

The patch r215707 tries to fix situation where paradoxial subregister access
with register X0 results results in acessing register -1 in bigendian.

The same situation happens for this bug.

insn 3 2 4 2 (set (reg:DI 76)
(reg:DI 1 x1 [ args+8 ])) test.c:3 35 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 1 x1 [ args+8 ])
(nil)))
(insn 4 3 5 2 (set (reg:TI 74)
(subreg:TI (reg:DI 76) 0)) test.c:3 38 {*movti_aarch64}
 (expr_list:REG_DEAD (reg:DI 76)
(nil)))

Where reload gets 

(set (reg:DI 0 x0 [76]) (reg:DI 1 x1 [ args+8 ]))
(set (reg:TI 0 x0 [74]) (reg:TI -1 [+-8 ])

Looks same issue to me. 

Vladimir can you please confirm.

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #33665|0   |1
is obsolete||

--- Comment #16 from Uroš Bizjak  ---
Created attachment 33672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33672&action=edit
Updated patch.

[Bug target/63483] Scheduler performs Invalid move of aliased memory reference

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #15)

> ... but the attached test check one location only.

I shoud say:

... but the test from the Description depends specifically on the code, touched
by the patch.

[Bug rtl-optimization/57003] [4.8/4.9/5.0 Regression] gcc breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.0 |4.8.4

--- Comment #32 from Uroš Bizjak  ---
Again fixed everywhere.

[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net ---
On 10/8/2014 11:07 PM, jb at gcc dot gnu.org wrote:
> That being said, googling this issue I stumbled upon
> https://gcc.gnu.org/ml/gcc-patches/2011-03/msg00545.html  where you fixed a
> similar issue for hp-ux 10, seemingly by making the driver always set
> _REENTRANT. Wouldn't a similar thing be the right thing to do for hp-ux 11 as
> well? If there are no ill effects of always enabling _REENTRANT that would 
> help
> other software than just libgfortran, as well as eliminating the risk that
> unconditionally enabling _REENTRANT in libgfortran might break on some other
> target?
It's certainly easy to make the same change to hp-ux 11.  I was
clearly wrong about the guards being removed.

I suspect HP introduced the _REENTRANT guard because they wanted to
remove the _r routines:
http://h21007.www2.hp.com/portal/download/files/unprot/stk/tru64_stk/impacts/i24.html

However, they are not gone so I think we should define _REENTRANT
if there are no ill effects.

Dave

[Bug c/63498] New: spurious warning about unrecognized command line option "-Wno-typedef-redefinition"

[zbyszek at in dot waw.pl]

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

Bug ID: 63498
   Summary: spurious warning about unrecognized command line
option "-Wno-typedef-redefinition"
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbyszek at in dot waw.pl

With the following program:

# test.c
int main(){}

when compiled with 'gcc -Wall -Wno-typedef-redefinition test.c' I get two
warnings, the second one is wrong, because -Wno-typedef-redefinition is a
documented option:

$ gcc -Wall -Wno-typedef-redefinition test.c
test.c: In function ‘main’:
test.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
 int main(){}
 ^
test.c: At top level:
cc1: warning: unrecognized command line option "-Wno-typedef-redefinition"

This warning is emitted only when at least one other warning is emitted.

$ rpm -q gcc
gcc-4.9.1-11.fc21.x86_64
(But older versions exhibit this behaviour too.)

[Bug c/63498] spurious warning about unrecognized command line option "-Wno-typedef-redefinition"

[zbyszek at in dot waw.pl]

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

Zbigniew Jędrzejewski-Szmek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Zbigniew Jędrzejewski-Szmek  ---
Hm, it's a clang option. My bad. gcc doesn't warn about the unknown option
though, but I'll file a separate bug for that.

[Bug c/63499] New: gcc treats unknown -Wno-xxx options differently than -Wxxx

[zbyszek at in dot waw.pl]

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

Bug ID: 63499
   Summary: gcc treats unknown -Wno-xxx options differently than
-Wxxx
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbyszek at in dot waw.pl

$ echo 'int main(){}' > test.c
$ gcc -Wyyy test.c
gcc: error: unrecognized command line option ‘-Wyyy’

$ gcc -Wno-yyy test.c && echo OK
OK

$ gcc -Wall -Wno-yyy test.c && echo OK
test.c: In function ‘main’:
test.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
 int main(){}
 ^
test.c: At top level:
cc1: warning: unrecognized command line option "-Wno-yyy"
OK

Depending on whether a different a different warning is emitted, the -Wno-*
options might cause a warning or not. "Positive" -W* options always emit an
error. This makes it hard to actually detect option support in a ./configure
script.

$ rpm -q gcc
gcc-4.9.1-11.fc21.x86_64

[Bug c/63498] spurious warning about unrecognized command line option "-Wno-typedef-redefinition"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> Hm, it's a clang option. My bad. gcc doesn't warn about the unknown option
> though, but I'll file a separate bug for that.

https://gcc.gnu.org/wiki/FAQ#wnowarning

[Bug c/63499] gcc treats unknown -Wno-xxx options differently than -Wxxx

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Manuel López-Ibáñez  ---
This is on purpose: https://gcc.gnu.org/wiki/FAQ#wnowarning

[Bug other/63492] bconfig.h or config.h for gencondmd.c

[pangbw at gmail dot com]

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

--- Comment #1 from baoshan  ---
CCing Mark who approved the born of genconditions.c, it seems the author Zack
is busy on his study on colleague.

[Bug libstdc++/63500] New: bug in debug version of std::make_move_iterator?

[vermaelen.wouter at gmail dot com]

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

Bug ID: 63500
   Summary: bug in debug version of std::make_move_iterator?
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vermaelen.wouter at gmail dot com

Is the following a bug in the debug version of std::make_move_iterator or is it
a bug in my code? It compiles fine with older gcc versions (both debug and
non-debug). But when using a fairly recent gcc-5.0 snapshot it fails to compile
when using -D_GLIBCXX_DEBUG, non-debug mode works fine.

 8<  8<  8<  8<  8< 

// Compiles fine with:
//   g++-4.8  -std=c++11 -c -D_GLIBCXX_DEBUG bug.cc
//   g++-snapshot -std=c++11 -c  bug.cc
// But this fails:
//   g++-snapshot -std=c++11 -c -D_GLIBCXX_DEBUG bug.cc

#include 
#include 
#include 

class Foo {};

std::vector> v;
std::vector> w;

void test() {
v.insert(end(v),
 make_move_iterator(begin(w)),
 make_move_iterator(end  (w)));
}

[Bug c/63499] gcc treats unknown -Wno-xxx options differently than -Wxxx

[zbyszek at in dot waw.pl]

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

--- Comment #2 from Zbigniew Jędrzejewski-Szmek  ---
Ah, ok. Thanks.

[Bug libquadmath/63488] large errors in y0q

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Paul Zimmermann from comment #0)
> For the input aa below (with 36 digits, we can recover the exact 113-bit
> binary value by rounding to nearest) mpfr_y0 gets the result cc (more
> precisely, the corresponding 113-bit binary value) which should be correctly
> rounded, and y0q gets the result dd which differs from 180688 ulps.
> 
> aa=8.935761195587725798762818805462843676e-01
> cc=-7.446238819993339201075302662649733975e-07 [MPFR]
> dd=-7.446238819993339201075302662815669696e-07
> ulp difference = 180688.00
> 
> For other functions and one million random inputs per function, I got much
> smaller differences (at most 42 ulps).
> 

I suppose I don't understand the intent of this PR.  The
approximation of a special function with either a polynomial
or a rational approximation is know to have issues near the
zeros of the special function.  Given that the zeros of
y0(x) lies close to x=(n+1/4)*pi with n=0,1,2..., I'm
curious to see what you would find if you test in small
intervals about x.

Testing 1 values in a small interval about the lowest
10 zeros, the double precision y0() on FreeBSD (which comes
from fdlibm) has

ULP:  5918, x =  8.9358398197930655e-01
ULP: 15390, x =  3.9576788857941221e+00
ULP: 17833, x =  7.0860502172517021e+00
ULP:  2510, x =  1.0222342340788490e+01
ULP:  4396, x =  1.3361094710349882e+01
ULP:  1203, x =  1.6500927187922073e+01
ULP: 14157, x =  1.9641309720499763e+01
ULP:  2141, x =  2.2782032287080856e+01
ULP:  1048, x =  2.5922964874664050e+01
ULP:  2219, x =  2.9064027475248540e+01

Note, I did not try to find the worse case.

[Bug c/63499] gcc treats unknown -Wno-xxx options differently than -Wxxx

[zbyszek at in dot waw.pl]

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

--- Comment #3 from Zbigniew Jędrzejewski-Szmek  ---
So, there's no way to programmatically check whether a flag is supported,
without resorting to grepping the output or something like that. Great.

[Bug libquadmath/63488] large errors in y0q

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Thu, Oct 09, 2014 at 05:34:11PM +, kargl at gcc dot gnu.org wrote:
> 
> Testing 1 values in a small interval about the lowest
> 10 zeros, the double precision y0() on FreeBSD (which comes
> from fdlibm) has
> 
> ULP:  5918, x =  8.9358398197930655e-01
> ULP: 15390, x =  3.9576788857941221e+00
> ULP: 17833, x =  7.0860502172517021e+00
> ULP:  2510, x =  1.0222342340788490e+01
> ULP:  4396, x =  1.3361094710349882e+01
> ULP:  1203, x =  1.6500927187922073e+01
> ULP: 14157, x =  1.9641309720499763e+01
> ULP:  2141, x =  2.2782032287080856e+01
> ULP:  1048, x =  2.5922964874664050e+01
> ULP:  2219, x =  2.9064027475248540e+01
> 
> Note, I did not try to find the worse case.
> 

Well, I got curious.  Testing 10 values in the 
small interval leads to

ULP: 346703, x =  8.9357674518326613e-01
ULP:  35183, x =  3.9576806238853104e+00
ULP:  69132, x =  7.0860511452537809e+00
ULP:  20098, x =  1.0222345745863045e+01
ULP:  51085, x =  1.3361097371042554e+01
ULP:  26333, x =  1.6500923006962172e+01
ULP:  17190, x =  1.9641309648491845e+01
ULP:  33541, x =  2.2782028293341551e+01
ULP:  18156, x =  2.5922956940291275e+01
ULP:   4118, x =  2.9064029588681016e+01

[Bug c++/63437] [4.9/5 regression][C++14] Parenthesized "movable but not copyable" object doesn't compile in return statement

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Oct  9 18:05:17 2014
New Revision: 216042

URL: https://gcc.gnu.org/viewcvs?rev=216042&root=gcc&view=rev
Log:
PR c++/63437
* cp-tree.h (REF_PARENTHESIZED_P): Also allow INDIRECT_REF.
* semantics.c (force_paren_expr): And set it.
* typeck.c (check_return_expr): And handle it.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/paren1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c

[Bug c++/63309] [4.8/4.9/5 Regression] internal compiler error: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Oct  9 18:05:29 2014
New Revision: 216044

URL: https://gcc.gnu.org/viewcvs?rev=216044&root=gcc&view=rev
Log:
PR c++/63309
* parser.c (cp_parser_class_head): push_template_decl for members
of templates, too.

Added:
trunk/gcc/testsuite/g++.dg/template/nested6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/63415] [4.9/5 Regression] internal compiler error: unexpected expression ‘static_cast(std::is_same{})’ of kind static_cast_expr

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Oct  9 18:05:23 2014
New Revision: 216043

URL: https://gcc.gnu.org/viewcvs?rev=216043&root=gcc&view=rev
Log:
PR c++/63415
* pt.c (value_dependent_expression_p) [CONSTRUCTOR]: Check the type.
(iterative_hash_template_arg): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
Slightly simplified test case that still fails without a function call:

typedef __int128_t __attribute__((__vector_size__(16))) vector_128_t;
typedef unsigned long long scalar_64_t;

vector_128_t
foo (void)
{
  union {
scalar_64_t i64[2];
vector_128_t v128;
  } u;
  u.i64[0] = 1;
  u.i64[1] = 2;
  return u.v128;
}

[Bug c++/63309] [4.8/4.9/5 Regression] internal compiler error: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|4.8.4   |5.0

--- Comment #4 from Jason Merrill  ---
Fixed for GCC 5.

[Bug target/63501] New: ICE in GCC powerpc64le top of trunk with -mupper-regs-df

[saugustine at google dot com]

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

Bug ID: 63501
   Summary: ICE in GCC powerpc64le top of trunk with
-mupper-regs-df
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: saugustine at google dot com

The enclosed (greatly reduced) test case fails with an internal
compiler error on gcc-4.9 and top of trunk. Works great with x86.

saugustine@saugustine: ~/creduce $ cat test.ii
fn1() {
  double fvalue;
  switch (0)
  case 0:
case 'f':
  fmtfp(fvalue);
}

saugustine@saugustine: ~/creduce $
~/gcc-tot/install/libexec/gcc/powerpc64le-linux-gnu/5.0.0/cc1
test.ii   -mcpu=power7   -mupper-regs-df   -O2
 fn1
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>  

Assembling
functions:
 fn1
test.ii: In function 'fn1':
test.ii:7:1: error: unrecognizable insn:
 }
 ^
(insn 24 23 25 2 (set (mem/c:DF (plus:DI (reg:DI 9 9)
(const_int 96 [0x60])) [0  S8 A64])
(reg/v:DF 3 3 [orig:155 fvalue ] [155])) test.ii:6 -1
 (nil))
test.ii:7:1: internal compiler error: in extract_insn, at recog.c:2206

[Bug c/63499] gcc treats unknown -Wno-xxx options differently than -Wxxx

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> So, there's no way to programmatically check whether a flag is supported,
> without resorting to grepping the output or something like that. Great.

No there is way just use the positive side rather than the no- option.

[Bug libstdc++/63500] bug in debug version of std::make_move_iterator?

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to Wouter Vermaelen from comment #0)
> Is the following a bug in the debug version of std::make_move_iterator or is
> it a bug in my code? It compiles fine with older gcc versions (both debug
> and non-debug).

Hmm, earlier this year I modified move_iterator without touching the debug
version (I hadn't realized it existed), that could be related.

[Bug libstdc++/63322] std::atomic where T is not trivially copyable should be disabled.

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct  9 18:17:23 2014
New Revision: 216046

URL: https://gcc.gnu.org/viewcvs?rev=216046&root=gcc&view=rev
Log:
PR libstdc++/63322
* include/std/atomic (atomic): Add assertion for trivially copyable.
* testsuite/29_atomics/atomic/60695.cc: Adjust line number.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/atomic
trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc

[Bug libstdc++/61909] Small function optimization not applied to small objects

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct  9 18:17:28 2014
New Revision: 216047

URL: https://gcc.gnu.org/viewcvs?rev=216047&root=gcc&view=rev
Log:
PR libstdc++/61909
* include/std/functional (__is_location_invariant): Treat all
trivially copyable types as location invariant.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional

[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||saugustine at google dot com

--- Comment #3 from David Edelsohn  ---
*** Bug 63501 has been marked as a duplicate of this bug. ***

[Bug target/63501] ICE in GCC powerpc64le top of trunk with -mupper-regs-df

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||dje at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from David Edelsohn  ---
Duplicate of 63491 opened earlier today.

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

[Bug target/63501] ICE in GCC powerpc64le top of trunk with -mupper-regs-df

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2014-10-09
 CC||bergner at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #2 from David Edelsohn  ---
Sorry, my mistake. I confused it with another bug.

[Bug target/63501] ICE in GCC powerpc64le top of trunk with -mupper-regs-df

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||powerpc64-*-*
   Target Milestone|--- |4.9.3

[Bug libquadmath/63488] large errors in y0q

[zimmerma+gcc at loria dot fr]

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

--- Comment #7 from Paul Zimmermann  ---
I agree that near zeroes we can expect large errors. However for other
functions
I got only small errors in ulps, maybe I was unlucky. Also the ultimate goal is
to get correct rounding, even near zeroes.

[Bug libstdc++/61909] Small function optimization not applied to small objects

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
  std::function f3((X())); // abort

This works now, but the lambda still needs to allocate.

[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-10-09
Summary|bug in debug version of |[4.9/5 Regression] bug in
   |std::make_move_iterator?|debug version of
   ||std::make_move_iterator?
 Ever confirmed|0   |1

--- Comment #2 from Marc Glisse  ---
Ah, no, not my fault. The debug machinery wants at some point
__addressof(*iter) but addressof wants an lvalue reference so it is not happy
with a move iterator.

Note that the error message is confusing:

error: invalid initialization of non-const reference of type
'std::unique_ptr&' from an rvalue of type 'std::unique_ptr'

when it is really an xvalue of type unique_ptr&&.

[Bug libstdc++/63322] std::atomic where T is not trivially copyable should be disabled.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #3 from Jonathan Wakely  ---
Fixed for 5.0

[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
François, is there a quick fix for this?

[Bug libquadmath/63488] large errors in y0q

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Thu, Oct 09, 2014 at 06:27:08PM +, zimmerma+gcc at loria dot fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488
> 
> --- Comment #7 from Paul Zimmermann  ---
> I agree that near zeroes we can expect large errors. However for
> other functions I got only small errors in ulps, maybe I was unlucky.
> Also the ultimate goal is to get correct rounding, even near zeroes.
> 

I suspect you got lucky :-)  IIRC my testing correctly, 
exhaustive testing of values in each interval shows
lgammaf(x) for x < 0 and not an integer also has major
accuracy issues:

Interval: Max ULP Value
[-1.1e+01, -1.0e+01): 6.72889 -1.009e+01
[-1.0e+01, -9.0e+00): 83.4928 -9.029e+00
[-9.0e+00, -8.0e+00): 24615.2 -8.248e+00
[-8.0e+00, -7.0e+00): 22575.7 -7.752e+00
[-7.0e+00, -6.0e+00): 100393. -6.0013852e+00
[-6.0e+00, -5.0e+00): 36966.5 -5.0082183e+00
[-5.0e+00, -4.0e+00): 324309. -4.0393620e+00
[-4.0e+00, -3.0e+00): 2981098 -3.1435809e+00
[-3.0e+00, -2.0e+00): 7497618 -2.4570248e+00
[-2.0e+00, -1.0e+00): 4.18718 -1.7313151e+00
[-1.0e+00, -4.76837e-07): 3.46651 -3.5002786e-01

troutmask:fvwm:kargl[209] ./testf -a -3.1435809e+00
libm: -2.38418579e-07, 1
mpfr: -1.96054615e-07, 1

The relevant code in testf is (RND is round-to-nearest).

x = (float)strtof(optarg, NULL);
y = lgammaf_r(x,&s);
mpfr_inits2(DBL_MANT_DIG, t1, t2, NULL);
mpfr_set_d(t1, (double)x, RND);
mpfr_lgamma(t2, &si, t1, RND);
printf("libm: %.8e, %d\n", y, s);
mpfr_printf("mpfr: %.8Re, %d\n", t2, si);
mpfr_clears(t1, t2, NULL);

[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #10 from Francois-Xavier Coudert  ---
Why is this 2.5 month old bug WAITING? Looks like a clear issue to me.

[Bug c++/63502] New: ICE in s390_add_constant when building with g++ in S390x Linux

[bill.klees at teamquest dot com]

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

Bug ID: 63502
   Summary: ICE in s390_add_constant when building with g++ in
S390x Linux
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bill.klees at teamquest dot com

Created attachment 33673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33673&action=edit
ii file.

System
--
Linux 2.6.18-238.el5 #1 SMP Sun Dec 19 14:27:28 EST 2010 s390x s390x s390x
GNU/Linux

GCC
---
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.9.1/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc-4.9.1/libexec/gcc/s390x-ibm-linux-gnu/4.9.1/lto-wrapper
Target: s390x-ibm-linux-gnu
Configured with: /home/bjk/gcc/gcc-4.9.1/./configure --prefix=/opt/gcc-4.9.1
--with-gmp=/opt/gmp-6.0.0 --with-mpfr=/opt/mpfr-3.1.2 --with-mpc=/opt/mpc-1.0.2
--enable-languages=c,c++ CC=/opt/gcc-4.7.4/bin/gcc CXX=/opt/gcc-4.7.4/bin/g++
--disable-bootstrap
Thread model: posix
gcc version 4.9.1 (GCC)

Source File
---
typedef   struct
   {
   char   system_name[100];
   char   system_model[100];
   char   original_system_name[100];
   intphysical_system;
   }   SB;

typedef   struct
   {
   int work_at_sys;
   }   MWL, *LPMWL;

typedef  struct
   {
   MWL *sys_tier;
   int  shadow_wl;
   int  util_queue_num;
   }   CB;

typedef struct
   {
   int  current_system;
   CB  *clas;
   int number_systems;
   SB *systems;
   int  nr;
   } MO, *LPMO;


void ds(LPMO mptr, int selected_index)
{

for (int i = selected_index; i < mptr->number_systems; i++)
{
   mptr->systems[i] = mptr->systems[i+1];

   for (int r = 1; r <= mptr->nr; r++)
  mptr->clas[r].sys_tier[i] = mptr->clas[r].sys_tier[i+1];

   mptr->systems[i].physical_system -= 1;
}

if (mptr->current_system >= selected_index)
   {
   if (mptr->current_system == 0)
  mptr->current_system = 1;
   }
}


Build Command
-
/opt/gcc-4.9.1/bin/g++ -m31 -O1 -c -o m.o m.c


Result
--
m.c: In function âvoid ds(LPMO, int)â:
m.c:50:1: internal compiler error: in s390_add_constant, at
config/s390/s390.c:6403
 }
 ^
0x8080f0c9 s390_add_constant
/home/bjk/gcc/gcc-4.9.1/./gcc/config/s390/s390.c:6403
0x8080f0c9 s390_add_constant
/home/bjk/gcc/gcc-4.9.1/./gcc/config/s390/s390.c:6395
0x808232d1 s390_mainpool_start
/home/bjk/gcc/gcc-4.9.1/./gcc/config/s390/s390.c:6699
0x808232d1 s390_reorg
/home/bjk/gcc/gcc-4.9.1/./gcc/config/s390/s390.c:11350
0x8055e927 rest_of_handle_machine_reorg
/home/bjk/gcc/gcc-4.9.1/./gcc/reorg.c:3936
0x8055e927 execute
/home/bjk/gcc/gcc-4.9.1/./gcc/reorg.c:3966
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Notes
-
Builds successfully using -O0, -O2, and -O3
Builds successfully with all optimizations when using -m64 instead of -m31

[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

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

--- Comment #23 from H.J. Lu  ---
With r216039, I still got

../../src-trunk/gcc/cp/parser.c: In function ‘cp_parser_declaration_seq_opt’:
../../src-trunk/gcc/cp/parser.c:11049:0: error: verify_flow_info: Wrong
probability of edge 53->54 -1192228368
 cp_parser_declaration_seq_opt (cp_parser* parser)
 ^
../../src-trunk/gcc/cp/parser.c:11049:0: internal compiler error:
verify_flow_info failed
0x6b2e3a verify_flow_info()
../../src-trunk/gcc/cfghooks.c:260
0xddcd27 cleanup_tree_cfg_noloop
../../src-trunk/gcc/tree-cfgcleanup.c:765
0xddcd27 cleanup_tree_cfg()
../../src-trunk/gcc/tree-cfgcleanup.c:814
0xbf5804 execute_function_todo
../../src-trunk/gcc/passes.c:1704
0xc02287 do_per_function
../../src-trunk/gcc/passes.c:1478
0xc02287 execute_todo
../../src-trunk/gcc/passes.c:1808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[7]: *** [/tmp/cchv0APR.ltrans3.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[6]: *** [cc1plus] Error 1

[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Would it make sense to overload __addressof so it accepts any glvalue? In
practice, that means also accepting prvalue...

[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto

[tejohnson at google dot com]

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

--- Comment #24 from Teresa Johnson  ---
On Thu, Oct 9, 2014 at 12:52 PM, hjl.tools at gmail dot com
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
>
> --- Comment #23 from H.J. Lu  ---
> With r216039, I still got
>
> ../../src-trunk/gcc/cp/parser.c: In function ‘cp_parser_declaration_seq_opt’:
> ../../src-trunk/gcc/cp/parser.c:11049:0: error: verify_flow_info: Wrong
> probability of edge 53->54 -1192228368
>  cp_parser_declaration_seq_opt (cp_parser* parser)
>  ^
> ../../src-trunk/gcc/cp/parser.c:11049:0: internal compiler error:
> verify_flow_info failed
> 0x6b2e3a verify_flow_info()
> ../../src-trunk/gcc/cfghooks.c:260
> 0xddcd27 cleanup_tree_cfg_noloop
> ../../src-trunk/gcc/tree-cfgcleanup.c:765
> 0xddcd27 cleanup_tree_cfg()
> ../../src-trunk/gcc/tree-cfgcleanup.c:814
> 0xbf5804 execute_function_todo
> ../../src-trunk/gcc/passes.c:1704
> 0xc02287 do_per_function
> ../../src-trunk/gcc/passes.c:1478
> 0xc02287 execute_todo
> ../../src-trunk/gcc/passes.c:1808
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[7]: *** [/tmp/cchv0APR.ltrans3.ltrans.o] Error 1
> make[7]: *** Waiting for unfinished jobs
> lto-wrapper: fatal error: make returned 2 exit status
> compilation terminated.
> /usr/local/bin/ld: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> make[6]: *** [cc1plus] Error 1

Arg, looks very similar so maybe another instance of the duplicate
threading is slipping through? My own lto profiled bootstrap succeeded
with my patch. I will try updating to r216039 and redo it to see if I
can provoke the same failure.

Teresa

>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug bootstrap/63496] ../../gcc/ipa-polymorphic-call.c:2117:1: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-10-09
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka  ---
mine.

[Bug target/63503] New: [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

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

Bug ID: 63503
   Summary: [AArch64] A57 executes fused multiply-add poorly in
some situations
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e.menezes at samsung dot com
CC: spop at gcc dot gnu.org
Target: aarch64-*

Curious why Geekbench's {D,S}GEMM by GCC were 8-9% slower than by LLVM, I was
baffled to find that the code emitted by GCC for the innermost loop in the
algorithm core is actually very good:

.L8:
ldr d2, [x8, w5, uxtw 3]
ldr d1, [x7, w5, uxtw 3]
add w5, w5, 1
cmp w5, w6
fmadd   d0, d2, d1, d0
bne .L8

LLVM's code is not so neat:

.LBB0_10:
ldr d1, [x27, x22, lsl #3]
ldr d2, [x9, x22, lsl #3]
fmuld1, d1, d2
faddd0, d0, d1
add w21, w21, #1
add x22, x22, #1
cmp w21, w24, uxtw
b.ne .LBB0_10

However, it runs faster.

Methinks that the A57 microarchitecture is performing tricks for discrete FP
operations but not for fused multiply-add, since both code sequences are
semantically the same.  Whatever it is, it seems that fused multiply-add, and
perhaps its cousins, is actually a performance hit only when one depends on the
results of a previous one, as in this case on the results of the fused
operation in the previous loop iteration.

I'll try to create a simple test-case, but, in the meantime, please chime in
about your thoughts.

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This might be true for A57 but for our chip (ThunderX), using fused
multiply-add is better.

The other question here are there denormals happening?  That might cause some
performance differences between using fmadd and fmul/fadd.

On most normal processors using fused multiply-add is an improvement also.

Can you attach the preprocessed source and what options you are using?

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
The other option it is the fusion of the cmp and branch which is causing the
improvement.

Can you manually edit the assembly and swap the cmp and fmadd in the GCC output
and try again?

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

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

--- Comment #3 from Evandro Menezes  ---
(In reply to Andrew Pinski from comment #1)
> The other question here are there denormals happening?  That might cause
> some performance differences between using fmadd and fmul/fadd.

Nope, no denormals.

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[e.menezes at samsung dot com]

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

--- Comment #4 from Evandro Menezes  ---
Here's a simplified code to reproduce these results:

double sum(double *A, double *B, int n) 
{
  int i;
  double res = 0;

  for (i = 0; i < n; i++)
res += A [i] * B [i];

  return res;
}

[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Also how sure are you that it is the fused multiply-add and not the scheduling
of the instructions?  As I mentioned, try swapping the cmp and fmadd; you might
get a performance boost.

[Bug target/63502] ICE in s390_add_constant when building with g++ in S390x Linux

[bill.klees at teamquest dot com]

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

--- Comment #1 from Bill Klees  ---
Setting breakpoint at s390_add_constant

Breakpoint 5, s390_add_constant (pool=0x80da0880, val=0x20003889cc0,
mode=BLKmod
at /home/bjk/gcc/gcc-4.9.1/./gcc/config/s390/s390.c:6400
6400  for (i = 0; i < NR_C_MODES; i++)
(gdb) list
6395s390_add_constant (struct constant_pool *pool, rtx val, enum
machine_mode mode)
6396{
6397  struct constant *c;
6398  int i;
6399
6400  for (i = 0; i < NR_C_MODES; i++)
6401if (constant_modes[i] == mode)
6402  break;
6403  gcc_assert (i != NR_C_MODES);
6404
(gdb) print constant_modes
$4 = {TFmode, TImode, TDmode, DFmode, DImode, DDmode, SFmode, SImode, SDmode,
HImode, QImode}
(gdb) print mode
$5 = BLKmode
(gdb)

Failure occurs on the assert since BLKmode is not in the list.

[Bug middle-end/28367] accessing via union on a vector does not cause vec_extract to be used

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #6 from Marc Glisse  ---
Created attachment 33674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33674&action=edit
rough patch

It needs more work (seems more complicated than it should be), but at least it
managed to produce what I expected for:

#include 
union u { __v4sf v; float a[4]; };

float f(__v4sf x){
  u t;
  t.v=x;
  return t.a[2];
}