[Bug c++/81086] [8 Regression] ICE with structured binding of initializer_list

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-14
 CC||jason at redhat dot com,
   ||marxin at gcc dot gnu.org
Summary|ICE with structured binding |[8 Regression] ICE with
   |of initializer_list |structured binding of
   ||initializer_list
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r247793.

[Bug tree-optimization/81083] [7 Regression] ICE: Unable to coalesce ssa_names 4 and 13 which are marked as MUST COALESCE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] ICE:   |[7 Regression] ICE: Unable
   |Unable to coalesce  |to coalesce ssa_names 4 and
   |ssa_names 4 and 13 which|13 which are marked as MUST
   |are marked as MUST COALESCE |COALESCE
  Known to fail|8.0 |

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

[Bug tree-optimization/81083] [7 Regression] ICE: Unable to coalesce ssa_names 4 and 13 which are marked as MUST COALESCE

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jun 14 07:22:32 2017
New Revision: 249182

URL: https://gcc.gnu.org/viewcvs?rev=249182&root=gcc&view=rev
Log:
2017-06-14  Richard Biener  

PR tree-optimization/81083
* tree-ssa-sccvn.c (vn_reference_lookup_3): Do not use abnormals
as values.

* gcc.dg/torture/pr81083.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81083.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug bootstrap/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-14
 CC||marxin at gcc dot gnu.org,
   ||y.gribov at samsung dot com
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Started with r249150.

[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)

> Then what we need and this patch doesn't implement is a sanopt optimization
> similer to the UBSAN_NULL opts, if we have checked already ptr + i doesn't
> overflow in a dominating stmt, don't check it again, if we have ptr + 10 and
> a dominating stmt checked ptr + 15 (i.e. bigger constant), also don't check
> it.
> 

Having some experience with the sanopt code, I can help with that.

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P1
  Component|bootstrap   |tree-optimization

[Bug c++/81086] [8 Regression] ICE with structured binding of initializer_list

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.0

[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #2)
> Having some experience with the sanopt code, I can help with that.

Ok, if you want, I'll leave that part out for now.

[Bug target/81085] inefficient union with long double argument on 32-bit x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-14
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We RTL expand from

f (long double x)
{
  unsigned int _3;
  _3 = BIT_FIELD_REF ;
  return _3;

that should be "perfect".  But we already spill:

;; return _3;

(insn 6 5 7 (set (mem/c:XF (plus:SI (reg/f:SI 82 virtual-stack-vars)
(const_int -16 [0xfff0])) [0  S12 A128])
(reg/v:XF 88 [ x ])) "t7.c":2 -1
 (nil))

(insn 7 6 8 (set (reg:SI 90)
(mem/c:SI (plus:SI (reg/f:SI 82 virtual-stack-vars)
(const_int -16 [0xfff0])) [0  S4 A128])) "t7.c":2
-1
 (nil))

(insn 8 7 9 (set (reg:SI 87 [  ])
(reg:SI 90)) "t7.c":2 -1
 (nil))

with -m64 we expand to

;; return _3;

(insn 6 5 7 (set (reg:TI 90)
(subreg:TI (reg/v:XF 88 [ x ]) 0)) "t7.c":2 -1
 (nil))

(insn 7 6 8 (set (reg:SI 87 [  ])
(subreg:SI (reg:TI 90) 0)) "t7.c":2 -1
 (nil))

not sure why we need the intermediate TImode subreg -- this one might not
be possible with 32bits.  Thus this might be a middle-end issue as well.

[Bug sanitizer/81088] UBSAN: false positive as a result of reassosiation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-14
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We associate to

(1 - (int) s) + 2147483647

without -fsanitize=undefined which is fine.  But with -fsanitize=undefined
we end up with:

;; Function main (null)
;; enabled by -tree-original


{
  i = if (SAVE_EXPR <(int) y>;, SAVE_EXPR <(int) y> == 0 || (SAVE_EXPR <(int)
y>;, 0);)
{
  __builtin___ubsan_handle_divrem_overflow (&*.Lubsan_data0, 0, (unsigned
long) SAVE_EXPR <(int) y>);
}
  else
{
  <<< Unknown tree: void_cst >>>
}, SAVE_EXPR <(int) y>;, -(int) s + -2147483648(OVF);;
  return 0;
}


this goes wrong somewhere when fully folding

-((int) s + (int) ~(if (SAVE_EXPR <(int) y>;, SAVE_EXPR <(int) y> == 0 ||
(SAVE_EXPR <(int) y>;, 0);)
  {
__builtin___ubsan_handle_divrem_overflow (&*.Lubsan_data0, 0, (unsigned
long) SAVE_EXPR <(int) y>);
  }
else
  {
<<< Unknown tree: void_cst >>>
  }, (unsigned int) (0 / SAVE_EXPR <(int) y>);)) + 2147483647

[Bug middle-end/81088] UBSAN: false positive as a result of reassosiation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|sanitizer   |middle-end
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Testcase that goes wrong without -fsanitize=undefined:

short s = 2;
short y = 1;
int i;
int main() {
i = -(s + (int)(~( y == 0 ? 1 : 0 , (unsigned)(0/y + 0x7fff;
return 0;
}

folded to:

;; Function main (null)
;; enabled by -tree-original


{
  i = y == 0;, -2147483648(OVF) - (int) s;;
  return 0;
}

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[tetra2005 at gmail dot com]

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

--- Comment #3 from Yuri Gribov  ---
Mine.

[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #41524|0   |1
is obsolete||

--- Comment #4 from Jakub Jelinek  ---
Created attachment 41550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41550&action=edit
gcc8-pr80998.patch

Slightly updated, so that it applies against the sanitize_flags_p changes and
optimizes expansion of UBSAN_PTR using get_range_pos_neg.

[Bug middle-end/81088] UBSAN: false positive as a result of reassosiation

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
And the issue is that

associate:
...
  /* Only do something if we found more than two objects.  Otherwise,
 nothing has changed and we risk infinite recursion.  */
  if (ok
  && (2 < ((var0 != 0) + (var1 != 0)
   + (con0 != 0) + (con1 != 0)
   + (lit0 != 0) + (lit1 != 0)
   + (minus_lit0 != 0) + (minus_lit1 != 0
{
  bool any_overflows = false;
  if (lit0) any_overflows |= TREE_OVERFLOW (lit0);
  if (lit1) any_overflows |= TREE_OVERFLOW (lit1);
...
  /* Don't introduce overflows through reassociation.  */
  if (!any_overflows
  && ((lit0 && TREE_OVERFLOW_P (lit0))
  || (minus_lit0 && TREE_OVERFLOW_P (minus_lit0
return NULL_TREE;

fails to see the overflow when associating

  (1(OVF) - (int) s) + 2147483647

the 1(OVF) is from (int)0xU which is implementation defined but
IIRC the FEs require the TREE_OVERFLOW flag to be set.

IMHO this any_overflows code is simply bogus.  To avoid dropping useful
association split_tree should drop pre-existing TREE_OVERFLOW.

[Bug tree-optimization/81090] New: [8 Regression] [graphite] ICE in loop_preheader_edge

[asolokha at gmx dot com]

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

Bug ID: 81090
   Summary: [8 Regression] [graphite] ICE in loop_preheader_edge
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20170611 snapshot ICEs when compiling the following snippet w/
-O2 (-O3, -Ofast) -floop-nest-optimize:

int x3, za;
int hg[1];

void
yw (int dq)
{
  const int r7 = 2;

  while (dq < 1)
{
  for (x3 = 0; x3 < r7; ++x3)
for (za = 0; za < r7; ++za)
  hg[1] = 0;
  ++dq;
}

  x3 = 0;
  while (x3 < r7)
{
  ++x3;
  if (x3 == 0)
break;
}
}

% gcc-8.0.0-alpha20170611 -O2 -floop-nest-optimize -c yrfe1sre.c
during GIMPLE pass: graphite
yrfe1sre.c: In function 'yw':
yrfe1sre.c:5:1: internal compiler error: Segmentation fault
 yw (int dq)
 ^~

(gdb) where
#0  0x0087c4e8 in loop_preheader_edge(loop const*) ()
#1  0x00d44621 in analyze_scalar_evolution(loop*, tree_node*) ()
#2  0x00d47d7b in analyze_scalar_evolution_in_loop(loop*, loop*,
tree_node*, bool*) ()
#3  0x00d47ed2 in simple_iv_with_niters(loop*, loop*, tree_node*,
affine_iv*, tree_node**, bool) ()
#4  0x00bad67f in is_comparison_with_loop_invariant_p(gcond*, loop*,
tree_node**, tree_code*, tree_node**, tree_node**) ()
#5  0x00bb4139 in predict_loops() ()
#6  0x00bb6023 in tree_estimate_probability(bool) ()
#7  0x01375172 in graphite_transform_loops() ()
#8  0x01375701 in (anonymous
namespace)::pass_graphite_transforms::execute(function*) ()
#9  0x00b9b629 in execute_one_pass(opt_pass*) ()
#10 0x00b9be55 in execute_pass_list_1(opt_pass*) ()
#11 0x00b9be67 in execute_pass_list_1(opt_pass*) ()
#12 0x00b9be67 in execute_pass_list_1(opt_pass*) ()
#13 0x00b9be67 in execute_pass_list_1(opt_pass*) ()
#14 0x00b9be99 in execute_pass_list(function*, opt_pass*) ()
#15 0x008a4720 in cgraph_node::expand() ()
#16 0x008a5bd1 in symbol_table::compile() [clone .part.51] ()
#17 0x008a7dc7 in symbol_table::finalize_compilation_unit() ()
#18 0x00c71655 in compile_file() ()
#19 0x0072f69a in toplev::main(int, char**) ()
#20 0x007315bb in main ()

[Bug c++/58541] [c++11] Bogus "error: redeclaration ... differs in ‘constexpr’"

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
This is fixed in 7.1.0. I'm adding a testcase and closing the bug.

[Bug c++/58541] [c++11] Bogus "error: redeclaration ... differs in ‘constexpr’"

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jun 14 09:18:57 2017
New Revision: 249186

URL: https://gcc.gnu.org/viewcvs?rev=249186&root=gcc&view=rev
Log:
2017-06-14  Paolo Carlini  

PR c++/58541
* g++.dg/cpp0x/constexpr-58541.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-58541.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/55004] [meta-bug] constexpr issues

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 58541, which changed state.

Bug 58541 Summary: [c++11] Bogus "error: redeclaration ... differs in 
‘constexpr’"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58541

   What|Removed |Added

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

[Bug c++/58541] [c++11] Bogus "error: redeclaration ... differs in ‘constexpr’"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug libstdc++/81091] New: libstdc++ not built with large file support

[rguenth at gcc dot gnu.org]

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

Bug ID: 81091
   Summary: libstdc++ not built with large file support
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

libstdc++ seems to lack AC_SYS_LARGEFILE in configury and thus uses fopen/open
in fstream and friends that can fail not only because of large files but files
with large inode numbers depending on the underlying filesystem.

[Bug c++/80829] [7/8 Regression] Use of constexpr constructors with base type instantiation fails compilation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-14
  Known to work||6.3.1
Summary|Use of constexpr|[7/8 Regression] Use of
   |constructors with base type |constexpr constructors with
   |instantiation fails |base type instantiation
   |compilation |fails compilation
 Ever confirmed|0   |1
  Known to fail||7.1.1, 8.0

--- Comment #3 from Jonathan Wakely  ---
Confirmed.

[Bug c++/80829] [7/8 Regression] Use of constexpr constructors with base type instantiation fails compilation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
Caused by r241531

[Bug tree-optimization/81090] [8 Regression] [graphite] ICE in loop_preheader_edge

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-14
 CC||amker at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
#6  0x00de6e8e in is_comparison_with_loop_invariant_p (
stmt=0x769d7460, loop=0x769d8210, loop_invariant=0x7fffd800, 
compare_code=0x7fffd814, loop_step=0x7fffd808, 
loop_iv_base=0x7fffd7f8)
at /space/rguenther/src/svn/early-lto-debug/gcc/predict.c:1397
1397  if (!simple_iv (loop, loop_containing_stmt (stmt), op0, &iv0, true))
(gdb) p stmt
$1 = (gcond *) 0x769d7460
(gdb) p debug_gimple_stmt (stmt)
if (0 != 0)
$2 = void
(gdb) p gimple_bb (stmt)
$3 = 

hum.  Ok, so it looks like loop->bounds got invalid and we have stale
nb_iter->stmt pointers.

Caused by moving of IVCANON pass as well.  Testcase works with
-fdisable-tree-ivcanon.

But sth is fishy, I suppose ivcanon fails to invalidate recorded niters.
Honza?  Like the following which fixes the ICE:

Index: gcc/tree-ssa-loop-ivcanon.c
===
--- gcc/tree-ssa-loop-ivcanon.c (revision 249185)
+++ gcc/tree-ssa-loop-ivcanon.c (working copy)
@@ -1216,11 +1216,13 @@ canonicalize_induction_variables (void)
   estimate_numbers_of_iterations ();

   FOR_EACH_LOOP (loop, LI_FROM_INNERMOST)
-{
-  changed |= canonicalize_loop_induction_variables (loop,
-   true, UL_SINGLE_ITER,
-   true);
-}
+if (canonicalize_loop_induction_variables (loop,
+  true, UL_SINGLE_ITER,
+  true))
+  {
+   changed = true;
+   free_numbers_of_iterations_estimates_loop (loop);
+  }
   gcc_assert (!need_ssa_update_p (cfun));

   unloop_loops (loop_closed_ssa_invalidated, &irred_invalidated);

but I can't see where ivcanon builds a new exit condition stmt, it just
updates the existing one...

[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

URL||https://github.com/google/s
   ||anitizers/issues/823

--- Comment #12 from Martin Liška  ---
Adding clang sanitizer issue where argument of type struct { int[5] } is not
handled.

[Bug tree-optimization/81090] [8 Regression] [graphite] ICE in loop_preheader_edge

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Ah, it is CFG cleanup removing a loop exit edge but not updating loop info it
seems.  So when remove_edge calls rescan_loop_exit it doesn't adjust bounds.
So either we are not supposed to keep those "live" at all or we somehow
need to manage them as well during CFG cleanup and other loop opts...

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[tetra2005 at gmail dot com]

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

--- Comment #4 from Yuri Gribov  ---
Created attachment 41551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41551&action=edit
Draft patch

Here's a draft patch. It fixes the repro but bootstrapping will take some time
on my notebook.

[Bug target/71663] aarch64 Vector initialization can be improved slightly

[naveenh at gcc dot gnu.org]

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

--- Comment #1 from naveenh at gcc dot gnu.org ---
Author: naveenh
Date: Wed Jun 14 10:20:07 2017
New Revision: 249187

URL: https://gcc.gnu.org/viewcvs?rev=249187&root=gcc&view=rev
Log:

PR target/71663
gcc
* config/aarch64/aarch64.c (aarch64_expand_vector_init):
Improve vector initialization code gen for only variable case.

gcc/testsuite
* gcc.target/aarch64/vect-init-1.c: Newtestcase.
* gcc.target/aarch64/vect-init-2.c: Likewise.
* gcc.target/aarch64/vect-init-3.c: Likewise.
* gcc.target/aarch64/vect-init-4.c: Likewise.
* gcc.target/aarch64/vect-init-5.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/vect-init-1.c
trunk/gcc/testsuite/gcc.target/aarch64/vect-init-2.c
trunk/gcc/testsuite/gcc.target/aarch64/vect-init-3.c
trunk/gcc/testsuite/gcc.target/aarch64/vect-init-4.c
trunk/gcc/testsuite/gcc.target/aarch64/vect-init-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/81092] New: Missing symbols for new std::wstring constructors

[redi at gcc dot gnu.org]

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

Bug ID: 81092
   Summary: Missing symbols for new std::wstring constructors
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This fails to link for targets where size_t != unsigned long (e.g. ia32)

#define _GLIBCXX_USE_CXX11_ABI 0
#include 

using std::wstring;

struct S : wstring {
  S(wstring s) : wstring(s, 1, s.get_allocator()) { }
};

int main()
{
  wstring s;
  wstring s2(s, 1, s.get_allocator());
  S s3(s);
}

$ g++-7 -g  s.cc -Wl,--no-demangle -m32
/tmp/ccPTDy8v.o: In function `main':
/tmp/s.cc:13: undefined reference to
`_ZNSbIwSt11char_traitsIwESaIwEEC1ERKS2_jRKS1_'
/tmp/ccPTDy8v.o: In function `_ZN1SC2ESbIwSt11char_traitsIwESaIwEE':
/tmp/s.cc:7: undefined reference to
`_ZNSbIwSt11char_traitsIwESaIwEEC2ERKS2_jRKS1_'
collect2: error: ld returned 1 exit status

[Bug libstdc++/81092] Missing symbols for new std::wstring constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-14
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
From Jakub on IRC:

in GLIBCXX_3.4.23 we export _ZNSbIwSt11char_traitsIwESaIwEEC[12]ERKS2_mRKS1_;

which exports something e.g. on x86_64, where size_t is unsigned long int

but nothing is exported if size_t is unsigned int or unsigned long long int

maybe it should bave been [jmy]RKS1_; but guess too late to fix that now in
that revision

so, shall _ZNSbIwSt11char_traitsIwESaIwEEC[12]ERKS2_[jy]RKS1_; be exported in
GLIBCXX_3.4.24 ?

how fatal is the missing symbol?  Can we fix it this way only for GCC8, or
shall we export this at 3.4.24 in 7.2 and move the GCC8 symbols to
GLIBCXX_3.4.25?

[Bug target/81069] nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
(In reply to me from comment #1)
> With trunk r239357, the problem disappears when disabling the "Neuter whole
> SESE regions" optimization:
> 
> --- gcc/config/nvptx/nvptx.c
> +++ gcc/config/nvptx/nvptx.c
> @@ -3719,7 +3719,7 @@ nvptx_neuter_pars (parallel *par, unsigned modes,
> unsigned outer)
>  {
>int ix, len;
>  
> -  if (nvptx_optimize)
> +  if (0 && nvptx_optimize)
> {
>   /* Neuter whole SESE regions.  */
>   bb_pair_vec_t regions;
> 
> Editing out any insignificant code changes, only the following diff remains
> in the PTX code generated with that optimization disabled/enabled:
> 
> --- ["Neuter whole SESE regions" disabled]
> +++ ["Neuter whole SESE regions" enabled (default)]
> @@ -253,20 +253,22 @@
> setp.eq.u64 %r145, %r99, %r155;
> selp.u32%r166, 1, 0, %r145;
> st.shared.u32   [__worker_bcast], %r166;
>  $L20:
>  $L19:
> bar.sync0;
> ld.shared.u32   %r167, [__worker_bcast];
> setp.ne.u32 %r145, %r167, 0;
> bar.sync1;
> @!%r145 bra.uni $L9;
> +   @%r162  bra.uni $L17;
> +   @%r163  bra $L18;
> bra $L8;
>  $L15:
> @%r162  bra.uni $L23;
> @%r163  bra $L24;
> ld.u32  %r146, [%r93+12];
> setp.ne.u32 %r148, %r146, %r142;
> selp.u32%r170, 1, 0, %r148;
> st.shared.u32   [__worker_bcast], %r170;
>  $L24:
>  $L23:
> @@ -291,22 +293,20 @@
>  $L6:
> @%r162  bra.uni $L25;
> @%r163  bra $L26;
> {
> call _gfortran_abort;
> trap; // (noreturn)
> }
>  $L26:
>  $L25:
>  $L8:
> -   @%r162  bra.uni $L17;
> -   @%r163  bra $L18;
> add.u32 %r56, %r56, %r87;
> add.u32 %r152, %r56, -1;
> setp.le.s32 %r154, %r152, %r158;
> selp.u32%r164, 1, 0, %r154;
> st.shared.u32   [__worker_bcast], %r164;
>  $L18:
>  $L17:
> bar.sync0;
> ld.shared.u32   %r165, [__worker_bcast];
> setp.ne.u32 %r154, %r165, 0;

I played with this some more.  Hand-editing the PTX code, I found that we still
get the hang if adding back the two !W0, !V0 "bra"s after "$L8" -- which, to my
current understanding, should make the code identical in behavior to the "good"
version.  (And, I do confirm that when additionally removing the two !W0, !V0
"bra"s before "$L15", the hand-edited code works fine.)

So, after all, maybe this also involves a problem (wrong code generation) in
PTX -> SASS compilation ("ptxas")?  (I say "also" because I still think that
the missing !W0, !V0 neutering/skipping after "$L8" is wrong.)


I also found that removing the "call _gfortran_abort" and/or "trap" and/or
replacing these with an "exit", we still see the hang, so I would assume it's
not something related to PR80035.

[Bug c++/15272] lookup, dependent base

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #16 from Nathan Sidwell  ---
sure thing

[Bug libstdc++/81092] Missing symbols for new std::wstring constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.2

--- Comment #2 from Jonathan Wakely  ---
This was introduced by r239773.

I think we should fix it for 7.2 and bump the symbol versions for trunk.

[Bug middle-end/81088] UBSAN: false positive as a result of reassosiation

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jun 14 11:40:20 2017
New Revision: 249192

URL: https://gcc.gnu.org/viewcvs?rev=249192&root=gcc&view=rev
Log:
2017-06-14  Richard Biener  

PR middle-end/81088
* fold-const.c (split_tree): Drop TREE_OVERFLOW flag from
literal constants.
(fold_binary_loc): When associating do not treat pre-existing
TREE_OVERFLOW on literal constants as a reason to allow
TREE_OVERFLOW on associated literal constants.

* c-c++-common/ubsan/pr81088.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr81088.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/81088] UBSAN: false positive as a result of reassosiation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||7.1.0

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

[Bug tree-optimization/81083] [7 Regression] ICE: Unable to coalesce ssa_names 4 and 13 which are marked as MUST COALESCE

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Jun 14 11:43:31 2017
New Revision: 249193

URL: https://gcc.gnu.org/viewcvs?rev=249193&root=gcc&view=rev
Log:
2017-06-14  Richard Biener  

PR tree-optimization/81083
* gcc.dg/torture/pr81083.c: Add prototypes.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr81083.c

[Bug tree-optimization/81090] [8 Regression] [graphite] ICE in loop_preheader_edge

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Mine.

[Bug fortran/81093] New: Accessing ranges of values in derived types leads to wrong result

[thomas.jourdan at orange dot fr]

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

Bug ID: 81093
   Summary: Accessing ranges of values in derived types leads to
wrong result
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.jourdan at orange dot fr
  Target Milestone: ---

Hello,

The following code leads to a correct or a wrong result, depending on whether
the select type construct is used or not. If it is not used, I get:
   1  -1   1  -1
   2  -2   2  -2
whereas if it is used, the result is
   1   1   1   1
   2   2   2   2
I am not quite sure that the program is standard conforming and that it is a
bug, since there is perhaps no reason for Gfortran to know how to retrieve data
if the complete data structure (data_type2) is not known.

Regards,

Thomas

---

program test

  implicit none

  type data_type1
integer, dimension(2) :: data1
  end type data_type1

  type, extends(data_type1) :: data_type2
integer, dimension(2) :: data2
  end type data_type2

  type data_gen
class(data_type1), dimension(:), allocatable :: mydata
  end type data_gen

  type(data_gen) :: gen_data

  integer :: ii
  integer, parameter :: nn = 4


  allocate(data_type2::gen_data%mydata(nn))

  select type(data => gen_data%mydata)
  type is (data_type2)
do ii = 1, nn
  data(ii)%data1(1:2) = (/1,2/)
  data(ii)%data2(1:2) = (/-1,-2/)
end do
  end select

  ! wrong result
  write(*,*) gen_data%mydata(1:nn)%data1(1)
  write(*,*) gen_data%mydata(1:nn)%data1(2)

  ! correct result
  select type(data => gen_data%mydata)
  type is (data_type2)
write(*,*) data(1:nn)%data1(1)
write(*,*) data(1:nn)%data1(2)
  end select

end program test

[Bug sanitizer/81094] New: -fsanitize=object-size does not instrument aggregate call arguments

[jakub at gcc dot gnu.org]

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

Bug ID: 81094
   Summary: -fsanitize=object-size does not instrument aggregate
call arguments
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

#define N 20

struct S { int i; };

__attribute__((noinline, noclone)) void
f0 (struct S s)
{
  asm volatile ("" : : "r" (s.i) : "memory");
}

__attribute__((noinline, noclone)) void
f1 (int i)
{
  char *orig;
  struct S *p;
  orig = (char *) __builtin_calloc (N, sizeof (struct S));
  p = (struct S *) orig;
  f0 (*(p + i));
  f0 (p[i]);
  p++;
  f0 (p[i - 1]);
  f0 (*(p + i - 1));
  __builtin_free (orig);
}

does not instrument the aggregate arguments of calls, similarly to PR81005.

[Bug sanitizer/81094] -fsanitize=object-size does not instrument aggregate call arguments

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-14
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/81095] New: fcheck=bounds and empty forall

[guez at lmd dot ens.fr]

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

Bug ID: 81095
   Summary: fcheck=bounds and empty forall
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guez at lmd dot ens.fr
  Target Milestone: ---

$ uname -a 
Linux curie91 2.6.32-642.15.1.el6.Bull.110.x86_64 #1 SMP Wed Mar 1 14:13:44 CET
2017 x86_64 x86_64 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/ccc/products2/gcc-7.1.0/BullEL_6__x86_64/default/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran --enable-lto
--enable-checking=release --disable-multilib --enable-shared=yes
--enable-static=yes --enable-threads=posix --enable-gold=default
--enable-plugins --enable-ld --with-plugin-ld=ld.gold --enable-bootstrap
--prefix=/ccc/products/gcc-7.1.0/default
--with-local-prefix=/ccc/products/gcc-7.1.0/default
Thread model: posix
gcc version 7.1.0 (GCC) 

$ gfortran --version
GNU Fortran (GCC) 7.1.0

Here is the test program:

$ cat test_empty_forall.f
program test_empty_forall
  implicit none
  integer contours(0)
  integer a(10, 10)
  integer i, j
  forall (i = 1:size(contours))
 forall (j = 1:contours(i)) a(i, j) = i + j
  end forall
end program test_empty_forall

$ gfortran -ffree-form -fcheck=bounds test_empty_forall.f

$ ./a.out
At line 7 of file test_empty_forall.f
Fortran runtime error: Index '0' of dimension 1 of array 'contours' below lower
bound of 1

Error termination. Backtrace:
#0  0x4006da in ???
#1  0x40081f in ???
#2  0x2b61c2fabd1c in ???
#3  0x400588 in ???

This is wrong. There is no error. As size(contours) is 0, the set of values for
i is empty and the body of the outer forall should not be executed. Cf. Adams
(2009, "Fortran 2003 Handbook", § 7.5.7.2, page 253).

[Bug other/81096] New: [8 regression] test case ttest in libbacktrace fail starting with r249111

[seurer at gcc dot gnu.org]

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

Bug ID: 81096
   Summary: [8 regression] test case ttest in libbacktrace fail
starting with r249111
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This started failing on powerpc64 LE with r249111.  It also fails with the same
error for BE though note that on BE some of the other tests here (like btest)
have not worked properly for some time.

seurer@genoa:~/gcc/build/gcc-test3$ cd libbacktrace/
seurer@genoa:~/gcc/build/gcc-test3/libbacktrace$ make check
true  DO=all multi-do # make
make  btest stest edtest ttest
make[1]: Entering directory `/home/seurer/gcc/build/gcc-test3/libbacktrace'
make[1]: `stest' is up to date.
make[1]: `ttest' is up to date.
make[1]: Leaving directory `/home/seurer/gcc/build/gcc-test3/libbacktrace'
make  check-TESTS
make[1]: Entering directory `/home/seurer/gcc/build/gcc-test3/libbacktrace'
PASS: backtrace_full noinline
PASS: backtrace_full inline
PASS: backtrace_simple noinline
PASS: backtrace_simple inline
PASS: backtrace_syminfo variable
PASS: btest
PASS: stest
PASS: backtrace_full alloc stress
PASS: edtest
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
FAIL: threaded backtrace_full noinline
FAIL: ttest
===
1 of 4 tests failed
===
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory `/home/seurer/gcc/build/gcc-test3/libbacktrace'
make: *** [check-am] Error 2

[Bug other/81096] [8 regression] test case ttest in libbacktrace fail starting with r249111

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #1 from Ian Lance Taylor  ---
Revision 249111 introduced the test, so evidently the test never worked on
PPC64.  But I don't know why.  You should find a ttest program in your working
directory, and presumably running that program will fail as shown below.  Can
you disassemble the functions test1_thread, f2, and f3 from that program and
post the disassembly here?

[Bug other/81096] [8 regression] test case ttest in libbacktrace fail starting with r249111

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---

10001510 :
10001510:   03 10 40 3c lis r2,4099
10001514:   00 7f 42 38 addir2,r2,32512
10001518:   a6 02 08 7c mflrr0
1000151c:   10 00 01 f8 std r0,16(r1)
10001520:   e1 ff 21 f8 stdur1,-32(r1)
10001524:   b5 ff ff 4b bl  100014d8 
10001528:   20 00 21 38 addir1,r1,32
1000152c:   10 00 01 e8 ld  r0,16(r1)
10001530:   fe ff 63 38 addir3,r3,-2
10001534:   b4 07 63 7c extsw   r3,r3
10001538:   a6 03 08 7c mtlrr0
1000153c:   20 00 80 4e blr
10001540:   00 00 00 00 .long 0x0
10001544:   00 00 00 01 .long 0x100
10001548:   80 00 00 00 .long 0x80
1000154c:   00 00 00 60 nop

100014d0 :
100014d0:   03 10 40 3c lis r2,4099
100014d4:   00 7f 42 38 addir2,r2,32512
100014d8:   a6 02 08 7c mflrr0
100014dc:   10 00 01 f8 std r0,16(r1)
100014e0:   e1 ff 21 f8 stdur1,-32(r1)
100014e4:   65 fe ff 4b bl  10001348 
100014e8:   20 00 21 38 addir1,r1,32
100014ec:   10 00 01 e8 ld  r0,16(r1)
100014f0:   02 00 63 38 addir3,r3,2
100014f4:   b4 07 63 7c extsw   r3,r3
100014f8:   a6 03 08 7c mtlrr0
100014fc:   20 00 80 4e blr
10001500:   00 00 00 00 .long 0x0
10001504:   00 00 00 01 .long 0x100
10001508:   80 00 00 00 .long 0x80
1000150c:   00 00 42 60 ori r2,r2,0

10001340 :
10001340:   03 10 40 3c lis r2,4099
10001344:   00 7f 42 38 addir2,r2,32512
10001348:   a6 02 08 7c mflrr0
1000134c:   f8 ff e1 fb std r31,-8(r1)
10001350:   e8 ff a1 fb std r29,-24(r1)
10001354:   14 00 40 39 li  r10,20
10001358:   f0 ff c1 fb std r30,-16(r1)
1000135c:   00 00 00 60 nop
10001360:   d0 84 22 39 addir9,r2,-31536
10001364:   fd ff a2 3c addis   r5,r2,-3
10001368:   00 99 a5 38 addir5,r5,-26368
1000136c:   00 00 80 38 li  r4,0
10001370:   fd ff c2 3c addis   r6,r2,-3
10001374:   a0 9a c6 38 addir6,r6,-25952
10001378:   10 00 01 f8 std r0,16(r1)
1000137c:   81 fd 21 f8 stdur1,-640(r1)
10001380:   00 00 69 e8 ld  r3,0(r9)
10001384:   60 00 e1 3b addir31,r1,96
10001388:   00 00 20 39 li  r9,0
1000138c:   50 02 41 f9 std r10,592(r1)
10001390:   40 02 e1 38 addir7,r1,576
10001394:   40 02 e1 fb std r31,576(r1)
10001398:   48 02 21 f9 std r9,584(r1)
1000139c:   58 02 21 91 stw r9,600(r1)
100013a0:   19 0c 00 48 bl  10001fb8 
100013a4:   00 00 00 60 nop
100013a8:   79 1b 65 7c mr. r5,r3
100013ac:   e4 00 82 40 bne 10001490 
100013b0:   48 02 a1 e8 ld  r5,584(r1)
100013b4:   02 00 a5 2b cmpldi  cr7,r5,2
100013b8:   28 00 9d 41 bgt cr7,100013e0 
100013bc:   00 00 00 60 nop
100013c0:   e0 80 22 e9 ld  r9,-32544(r2)
100013c4:   fe ff 82 3c addis   r4,r2,-2
100013c8:   b0 95 84 38 addir4,r4,-27216
100013cc:   00 00 69 e8 ld  r3,0(r9)
100013d0:   a1 fa ff 4b bl  1e70
<003a.plt_call.fprintf@@GLIBC_2.17>
100013d4:   18 00 41 e8 ld  r2,24(r1)
100013d8:   01 00 20 39 li  r9,1
100013dc:   58 02 21 91 stw r9,600(r1)
100013e0:   fe ff a2 3f addis   r29,r2,-2
100013e4:   fe ff c2 3f addis   r30,r2,-2
100013e8:   e8 95 bd 3b addir29,r29,-27160
100013ec:   f8 95 de 3b addir30,r30,-27144
100013f0:   fe ff e2 3c addis   r7,r2,-2
100013f4:   78 fb e5 7f mr  r5,r31
100013f8:   f0 95 e7 38 addir7,r7,-27152
100013fc:   78 f3 c3 7f mr  r3,r30
10001400:   58 02 21 39 addir9,r1,600
10001404:   78 eb a8 7f mr  r8,r29
10001408:   53 00 c0 38 li  r6,83
1000140c:   00 00 80 38 li  r4,0
10001410:   c9 01 00 48 bl  100015d8 
10001414:   00 00 00 60 nop
10001418:   fe ff e2 3c addis   r7,r2,-2
1000141c:   58 02 21 39 addir9,r1,600
10001420:   78 eb a8 7f mr  r8,r29
10001424:   00 96 e7 38 addir7,r7,-27136
10001428:   78 fb e5 7f mr  r5,r31
1000142c:   78 f3 c3 7f mr  r3,r30
10001430:   42 00 c0 38 li  r6,66
10001434:   01 00 80 38 li  r4,1
10001438:   a1 01 00 48 bl  100015d8 
1000143c:   00 00 00 60 nop
10001440:   fe ff e2 3c addis   r7,r2,-2
10001444:   58 02 21 39 addir9,r1,600
10001448:   78 eb a8 7f mr  r8,r29
1000144c:   78 f3 c3 7f mr  r3,r30
10001450: 

[Bug sanitizer/81097] New: UBSAN: false positive for not existing negation operator and a bogus message

[babokin at gmail dot com]

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

Bug ID: 81097
   Summary: UBSAN: false positive for not existing negation
operator and a bogus message
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev249202.

Test case doesn't contain negations, but ubsan claims that negation has a
problem.

Error message also contains reference to '' type. Though problems seem
to be related.

> cat f.cpp
unsigned int a = 3309568;
unsigned int b = -1204857327;
short c = -10871;
short x;
int main() {
  x = (short(~a) | ~c) +  (short(~b) | ~c);
  return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp -o out
> ./out
f.cpp:6:18: runtime error: negation of -32768 cannot be represented in type
''; cast to an unsigned type to negate this value to itself

[Bug target/79799] Improve vec_insert of float on Power9

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-14
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug other/81098] New: backtrace_pcinfo initialization not thread safe

[bernard at zeroc dot com]

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

Bug ID: 81098
   Summary: backtrace_pcinfo initialization not thread safe
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernard at zeroc dot com
  Target Milestone: ---

Created attachment 41552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41552&action=edit
test case

The first call to backtrace_pcinfo performs a one-time initialization which
does not appear to be thread safe, even when initializing libbacktrace in
threaded mode.

With the attached test case, you should get a SEGV and core dump with every
run.

Compile with:
c++ -g --std=c++11 bt-test.cpp -o bt-test -lbacktrace -pthread

Tested on Ubuntu 16.04 x86_64 with gcc 5.4.0 and Debian stretch x86_64 with gcc
6.3.0.

Compile with -DWORKAROUND to "pre initialize" backtrace_pcinfo and work-around
this issue.

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  ---
Jan,

can you *please* have a look at this bug?  Darwin bootstrap is broken for
almost
a week with no signs of activity to fix this!

Thanks.
  Rainer

[Bug c++/81099] New: A single `decltype(this)` at top level triggers 2 identical error messages

[iamsupermouse at mail dot ru]

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

Bug ID: 81099
   Summary: A single `decltype(this)` at top level triggers 2
identical error messages
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamsupermouse at mail dot ru
  Target Milestone: ---

If `decltype(this)` is used at top level, it triggers *two* identical error
messages. For example:

using T = decltype(this);

Results in:

:1:20: error: invalid use of 'this' at top level
 using T = decltype(this);
^~~~
:1:20: error: invalid use of 'this' at top level


On the other hand, following:

auto x = this;
// al well as `using T = decltype(*this);`

triggers a *single* error message:

:1:10: error: invalid use of 'this' at top level
 auto x = this;
  ^~~~

[Bug c/81100] New: ICE from x86 __asm__() statck manipulation

[lindsay at arista dot com]

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

Bug ID: 81100
   Summary: ICE from x86  __asm__() statck manipulation
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lindsay at arista dot com
  Target Milestone: ---

Created attachment 41553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41553&action=edit
Preprocessed source left when ICE occurred

Using gcc-6.3.1-1.fc25.x86_64, the command:

   /usr/bin/gcc -g -pipe -fPIC -march=i686 -m32 -c test2.c

resulted in:

test2.c: In function ‘main’:
test2.c:31:1: internal compiler error: in print_reg, at
config/i386/i386.c:16601
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}: Warning: end of file not at end of a line; newline inserted
{standard input}:45: Error: unbalanced parenthesis in operand 2.
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
Preprocessed source stored into /tmp/cc48P0WJ.out file, please attach this to
your bugreport.
--

I attach the .out file. As you can see, this is already a cutdown, which mostly
consists of an __asm__() that plays games with the x86 stack pointer. The full
original was working code, but we hit the ICE when we tried to upgrade to a
newer GCC.

This might be related to bug 80367. A quick look didn't find any other
candidates.

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Yuri Gribov from comment #4)
> Created attachment 41551 [details]
> Draft patch
> 
> Here's a draft patch. It fixes the repro but bootstrapping will take some
> time on my notebook.

There is no need to use your notebook for bootstrapping and testing.
Why not simply use the GCC Compile Farm?
https://cfarm.tetaneutral.net/machines/list/

[Bug tree-optimization/81089] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in register_edge_assert_for_2, at tree-vrp.c:5023

[tetra2005 at gmail dot com]

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

--- Comment #6 from Yuri Gribov  ---
(In reply to Markus Trippelsdorf from comment #5)
> (In reply to Yuri Gribov from comment #4)
> > Created attachment 41551 [details]
> > Draft patch
> > 
> > Here's a draft patch. It fixes the repro but bootstrapping will take some
> > time on my notebook.
> 
> There is no need to use your notebook for bootstrapping and testing.
> Why not simply use the GCC Compile Farm?
> https://cfarm.tetaneutral.net/machines/list/

That would be lovely but I tried once (by sending mail to laur...@guerby.net)
and got no reply...

In any case, the patch has been posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01092.html