[Bug libstdc++/81835] cxxabi.h has invalid link in comment.

[chrisj at rtems dot org]

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

--- Comment #3 from Chris Johns  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Chris Johns from comment #0)
> > Tiny issue.
> > 
> > Looking over cxxabi.h I noticed a link in a comment about __cxa_demangle is
> > not valid anymore:
> > 
> >*  See http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch39.html
> >*  for other examples of use.
> 
> I'll fix the link.

Thank you.

> > I am looking for the implementation of the demangler code we have on our
> > mebedded targets in RTEMS. A pointer to that location would be most 
> > welcomed.
> 
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_demangling.html is the
> new location.

I clicked on the link and that page states:

 "If you have read the [source documentation for namespace abi] then you are
aware .."

I clicked on that link and the page is titled:

 bin_search_tree_/debug_fn_imps.hpp File Reference

This does not seem to correct or point me to the demangler code. 

I have located the code in libiberty however I am unsure if this is the code in
the RTEMS targets.

[Bug libstdc++/81835] cxxabi.h has invalid link in comment.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
That should point back to the cxxabi.h file, where you started.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
So I think what safelen > 1 (and thus ivdep) guarantees is that (even if the
loop doesn't iterate) we can peel any iteration before or after the loop which
effectively means all references in one iteration are independent of all refs
in another iteration.  It also allows unrolling and interleaving the unrolled
iterations arbitrarily.  But we have to preserve ordering of stmts in a single
iteration.

Now - for refs that have an invariant address in such loop the interleaving
effectively means that they are independent even in the same iteration.  Which
of course raises the question of whether ivdep or safelen specifications say
anything about must-aliases or if they really allow

 # safele = 2 / ivdep
 for (i = 0; i < 2; ++i)
  {
   tem = c;
   c = tem + 1;
  }

to be re-written as (unroll, interleave):

  tem0 = c;
  tem1 = c;
  c = tem1 + 1;
  c = tem0 + 1;

for example.  I suppose it's not their intent.  So maybe there's an additional
restriction on the interleaving?  Preserve iteration order of individual
stmts?  That would prevent autopar in face of just ivdep for example.

Note that any "handle must-defs 'correctly'" writing is inherently fishy.

[Bug c++/81884] New: Invalid code generation with zero size arrays or flexible array members

[v at vsamko dot com]

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

Bug ID: 81884
   Summary: Invalid code generation with zero size arrays or
flexible array members
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v at vsamko dot com
  Target Milestone: ---

Code below prints 
1 2 13 14
BUG DETECTED
when compiled with "-Wfatal-errors -O3 bug2.cpp -o bug2 --save-temps -Wall",
but outputs correct results when compiled with -O0, or if we comment out "   
x->eventTime = value_t(10);", or typedef "value_t" to uint64_t.

Same problem if we use flexible array member (e.g. "uint64_t arr[]") instead of
the zero length array.

===
typedef unsigned long uint64_t;

struct value_t {
uint64_t _count;
value_t(uint64_t c) : _count(c) {}
};

struct X {
value_t eventTime;
uint64_t arr[0];
};

X* x;

__attribute__((noclone, noinline))
void initialize() {
x->arr[0] = 11;
x->arr[1] = 12;
x->eventTime = value_t(10);
x->arr[2] = 13;
x->arr[3] = 14;
}

int main() {
char buffer[sizeof(X) + sizeof(uint64_t)*4];
x = (X*)buffer;
x->eventTime = value_t(999);
x->arr[0] = 1;
x->arr[1] = 2;
x->arr[2] = 3;
x->arr[3] = 4;
initialize();
__builtin_printf("%lu %lu %lu %lu\n", x->arr[0], x->arr[1], x->arr[2],
x->arr[3]);
if (x->arr[0] != 11 || x->arr[1] != 12 || x->arr[2] != 13 || x->arr[3] !=
14) {
__builtin_printf("BUG DETECTED\n");
}
else {
__builtin_printf("NO BUG\n");
}
}

[Bug libstdc++/81885] New: operator-> not checked by -D_GLIBCXX_ASSERTIONS

[joerg.rich...@pdv-fs.de]

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

Bug ID: 81885
   Summary: operator-> not checked by -D_GLIBCXX_ASSERTIONS
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

unique_ptr::operator* is checked with __glibcxx_assert. But
unique_ptr::operator-> uses only _GLIBCXX_DEBUG_PEDASSERT. I think the later
can use __glibcxx_assert too.

Same for the other pointer templates.

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[benni.buch at gmail dot com]

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

--- Comment #11 from Benjamin Buch  ---
Also test case #3 doesn't work if you declare the function return type auto:

constexpr auto foo ()
{
  static_assert (0 == __builtin_strcmp (__func__, "foo"), "#1");
  static_assert (0 == __builtin_strcmp (__FUNCTION__, "foo"), "#2");
  static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "constexpr int
foo()"), "#3");

  return 1;
}

static_assert (foo (), "#4");

void bar ()
{
  static_assert (0 == __builtin_strcmp (__func__, "bar"), "#5");
  static_assert (0 == __builtin_strcmp (__FUNCTION__, "bar"), "#6");
  static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "void bar()"),
"#7");
}


$ g++ -std=c++17 gcc-test.cpp
gcc-test.cpp: In Funktion »constexpr auto foo()«:
gcc-test.cpp:5:3: Fehler: statische Erklärung gescheitert: #3
   static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "constexpr int
foo()"), "#3");
   ^
bebuch@pcbebuch:~/media/projekte/test$ g++ -std=c++17 gcc-test.cpp  
gcc-test.cpp: In Funktion »constexpr auto foo()«:
gcc-test.cpp:5:3: Fehler: statische Erklärung gescheitert: #3
   static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "constexpr int
foo()"), "#3");
   ^
gcc-test.cpp: In Funktion »void bar()«:
gcc-test.cpp:14:3: Fehler: Nicht-konstante Bedingung für statische Behauptung
   static_assert (0 == __builtin_strcmp (__func__, "bar"), "#5");
   ^
gcc-test.cpp:14:40: Fehler: »__builtin_strcmp(((const char*)(& __func__)),
((const char*)"bar"))« ist kein Konstantenausdruck
   static_assert (0 == __builtin_strcmp (__func__, "bar"), "#5");
   ~^
gcc-test.cpp:15:3: Fehler: Nicht-konstante Bedingung für statische Behauptung
   static_assert (0 == __builtin_strcmp (__FUNCTION__, "bar"), "#6");
   ^
gcc-test.cpp:15:40: Fehler: »__builtin_strcmp(((const char*)(& __FUNCTION__)),
((const char*)"bar"))« ist kein Konstantenausdruck
   static_assert (0 == __builtin_strcmp (__FUNCTION__, "bar"), "#6");
   ~^
gcc-test.cpp:16:3: Fehler: Nicht-konstante Bedingung für statische Behauptung
   static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "void bar()"),
"#7");
   ^
gcc-test.cpp:16:40: Fehler: »__builtin_strcmp(((const char*)(&
__PRETTY_FUNCTION__)), ((const char*)"void bar()"))« ist kein
Konstantenausdruck
   static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "void bar()"),
"#7");
   ~^~~

$ g++ --version
g++ (GCC) 8.0.0 20170816 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug tree-optimization/81884] Invalid code generation with zero size arrays or flexible array members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-18
  Component|c++ |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Mine.  DSE is optimizing

void initialize() ()
{
  long unsigned int SR.19;
  struct value_t D.2321;
  struct X * x.0_1;
  struct X * x.3_4;

   [100.00%]:
  x.0_1 = x;
  x.0_1->arr[0] = 11;
  x.0_1->arr[1] = 12;
  MEM[(struct X *)x.0_1] = 10;
  x.3_4 = x;
  x.3_4->arr[2] = 13;
  x.3_4->arr[3] = 14;
  return;

to

__attribute__((noinline, noclone))
void initialize() ()
{
  long unsigned int SR.19;
  struct value_t D.2321;
  struct X * x.0_1;
  struct X * x.3_4;

   [100.00%]:
  x.0_1 = x;
  MEM[(struct X *)x.0_1] = 10;
  x.3_4 = x;
  x.3_4->arr[2] = 13;
  x.3_4->arr[3] = 14;
  return;

so it appears that it treats the "aggregate" assignment as a must-def.

[Bug tree-optimization/81884] [6/7/8 Regression] Invalid code generation with zero size arrays or flexible array members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2
  Known to work||5.4.0
   Target Milestone|--- |6.5
Summary|Invalid code generation |[6/7/8 Regression] Invalid
   |with zero size arrays or|code generation with zero
   |flexible array members  |size arrays or flexible
   ||array members

[Bug libgomp/81886] New: Means to determine at runtime foffload targets specified at compile time

[vries at gcc dot gnu.org]

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

Bug ID: 81886
   Summary: Means to determine at runtime foffload targets
specified at compile time
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02670.html :
...
 currently, the whole offload machinery will not be
run unless we actually have any offloaded data.  This means that the
configured mkoffload programs (-foffload=[...], defaulting to
configure-time --enable-offload-targets=[...]) will not be invoked unless
we actually have any offloaded data.  This means that we will not
actually generate constructor code to call libgomp's
GOMP_offload_register unless we actually have any offloaded data.  At
runtime, in libgomp, we then cannot reliably tell which -foffload=[...]
targets have been specified during compilation.

But: at runtime, I'd like to know which -foffload=[...] targets have been
specified during compilation, so that we can, for example, reliably
resort to host fallback execution for -foffload=disable instead of
getting error message that an offloaded function is missing.  On the
other hand, for example, for -foffload=nvptx-none, even if user program
code doesn't contain any offloaded data (and thus the offload machinery
has not been run), the user program might still contain any executable
directives or OpenACC runtime library calls, so we'd still like to use
the libgomp nvptx plugin.  However, we currently cannot detect this
situation.
...

[Bug tree-optimization/81884] [6/7/8 Regression] Invalid code generation with zero size arrays or flexible array members

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 42000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42000&action=edit
patch in testing

[Bug libgomp/81886] Means to determine at runtime foffload targets specified at compile time

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
This is the initial commit to gomp-4_0-branch :
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01264.html .

[Bug c/53037] warn_if_not_aligned(X)

[hjl at gcc dot gnu.org]

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

--- Comment #24 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Aug 18 09:38:38 2017
New Revision: 251180

URL: https://gcc.gnu.org/viewcvs?rev=251180&root=gcc&view=rev
Log:
Add warn_if_not_aligned attribute

Add warn_if_not_aligned attribute as well as  command line options:
-Wif-not-aligned and -Wpacked-not-aligned.

__attribute__((warn_if_not_aligned(N))) causes compiler to issue a
warning if the field in a struct or union is not aligned to N:

typedef unsigned long long __u64
  __attribute__((aligned(4),warn_if_not_aligned(8)));

struct foo
{
  int i1;
  int i2;
  __u64 x;
};

__u64 is aligned to 4 bytes.  But inside struct foo, __u64 should be
aligned at 8 bytes.  It is used to define struct foo in such a way that
struct foo has the same layout and x has the same alignment when __u64
is aligned at either 4 or 8 bytes.

Since struct foo is normally aligned to 4 bytes, a warning will be issued:

warning: alignment 4 of 'struct foo' is less than 8

Align struct foo to 8 bytes:

struct foo
{
  int i1;
  int i2;
  __u64 x;
} __attribute__((aligned(8)));

silences the warning.  It also warns the field with misaligned offset:

struct foo
{
  int i1;
  int i2;
  int i3;
  __u64 x;
} __attribute__((aligned(8)));

warning: 'x' offset 12 in 'struct foo' isn't aligned to 8

This warning is controlled by -Wif-not-aligned and is enabled by default.

When -Wpacked-not-aligned is used, the same warning is also issued for
the field with explicitly specified alignment in a packed struct or union:

struct __attribute__ ((aligned (8))) S8 { char a[8]; };
struct __attribute__ ((packed)) S {
  struct S8 s8;
};

warning: alignment 1 of 'struct S' is less than 8

This warning is disabled by default and enabled by -Wall.

gcc/

PR c/53037
* print-tree.c (print_node): Support DECL_WARN_IF_NOT_ALIGN
and TYPE_WARN_IF_NOT_ALIGN.
* stor-layout.c (do_type_align): Merge DECL_WARN_IF_NOT_ALIGN.
(handle_warn_if_not_align): New.
(place_union_field): Call handle_warn_if_not_align.
(place_field): Call handle_warn_if_not_align.  Copy
TYPE_WARN_IF_NOT_ALIGN.
(finish_builtin_struct): Copy TYPE_WARN_IF_NOT_ALIGN.
(layout_type): Likewise.
* tree-core.h (tree_type_common): Add warn_if_not_align.  Set
spare to 18.
(tree_decl_common): Add warn_if_not_align.
* tree.c (build_range_type_1): Copy TYPE_WARN_IF_NOT_ALIGN.
* tree.h (TYPE_WARN_IF_NOT_ALIGN): New.
(SET_TYPE_WARN_IF_NOT_ALIGN): Likewise.
(DECL_WARN_IF_NOT_ALIGN): Likewise.
(SET_DECL_WARN_IF_NOT_ALIGN): Likewise.
* doc/extend.texi: Document warn_if_not_aligned attribute.
* doc/invoke.texi: Document -Wif-not-aligned and
-Wpacked-not-aligned.

gcc/c-family/

PR c/53037
* c-attribs.c (handle_warn_if_not_aligned_attribute): New.
(c_common_attribute_table): Add warn_if_not_aligned.
(handle_aligned_attribute): Renamed to ...
(common_handle_aligned_attribute): Remove argument, name, and add
argument, warn_if_not_aligned.  Handle warn_if_not_aligned.
(handle_aligned_attribute): New.
* c.opt: Add -Wif-not-aligned and -Wpacked-not-aligned.

gcc/c/

PR c/53037
* c-decl.c (merge_decls): Also merge DECL_WARN_IF_NOT_ALIGN.
(check_bitfield_type_and_width): Don't allow bit-field with
warn_if_not_aligned type.

gcc/cp/

PR c/53037
* decl.c (duplicate_decls): Also merge DECL_WARN_IF_NOT_ALIGN.
* decl2.c (grokbitfield): Don't allow bit-field with
warn_if_not_aligned type.

gcc/testsuite/

PR c/53037
* c-c++-common/pr53037-5.c: New test.
* g++.dg/pr53037-1.C: Likewise.
* g++.dg/pr53037-2.C: Likewise.
* g++.dg/pr53037-3.C: Likewise.
* g++.dg/pr53037-4.C: Likewise.
* gcc.dg/pr53037-1.c: Likewise.
* gcc.dg/pr53037-2.c: Likewise.
* gcc.dg/pr53037-3.c: Likewise.
* gcc.dg/pr53037-4.c: Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/pr53037-5.c
trunk/gcc/testsuite/g++.dg/pr53037-1.C
trunk/gcc/testsuite/g++.dg/pr53037-2.C
trunk/gcc/testsuite/g++.dg/pr53037-3.C
trunk/gcc/testsuite/g++.dg/pr53037-4.C
trunk/gcc/testsuite/gcc.dg/pr53037-1.c
trunk/gcc/testsuite/gcc.dg/pr53037-2.c
trunk/gcc/testsuite/gcc.dg/pr53037-3.c
trunk/gcc/testsuite/gcc.dg/pr53037-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/print-tree.c
trunk/gcc/stor-layout.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #25 from H.J. Lu  ---
Fixed.

[Bug libgomp/81886] Means to determine at runtime foffload targets specified at compile time

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Created attachment 42001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42001&action=edit
trunk patch

This is a version of the patch for trunk.

It introduces some failures for c and c++, but that might be due to allowing
more testing:
...
FAIL: libgomp.oacc-c-c++-common/lib-74.c -foffload=nvptx-none  -O0  execution
test
FAIL: libgomp.oacc-c-c++-common/lib-74.c -foffload=nvptx-none  -O2  execution
test
FAIL: libgomp.oacc-c-c++-common/lib-78.c -foffload=nvptx-none  -O0  execution
test
FAIL: libgomp.oacc-c-c++-common/lib-78.c -foffload=nvptx-none  -O2  execution
test
FAIL: libgomp.oacc-c-c++-common/lib-83.c -foffload=nvptx-none  -O0  execution
test
FAIL: libgomp.oacc-c-c++-common/lib-83.c -foffload=nvptx-none  -O2  execution
test
FAIL: libgomp.oacc-c-c++-common/parallel-dims.c -foffload=nvptx-none  -O0 
(test for excess errors)
FAIL: libgomp.oacc-c-c++-common/parallel-dims.c -foffload=nvptx-none  -O2 
(test for excess errors)
...

[Bug libgomp/81886] Means to determine at runtime foffload targets specified at compile time

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)

These are all related to timing issues. Maybe not related to the patch.

> FAIL: libgomp.oacc-c-c++-common/lib-74.c -foffload=nvptx-none  -O0 
> execution test
> FAIL: libgomp.oacc-c-c++-common/lib-74.c -foffload=nvptx-none  -O2 
> execution test

'./lib-74.exe'; echo XYZ$?ZYX^M
actual time < delay time^M
Aborted (core dumped)^M

> FAIL: libgomp.oacc-c-c++-common/lib-78.c -foffload=nvptx-none  -O0 
> execution test
> FAIL: libgomp.oacc-c-c++-common/lib-78.c -foffload=nvptx-none  -O2 
> execution test

'./lib-78.exe'; echo XYZ$?ZYX^M
actual time < delay time^M
Aborted (core dumped)^M

> FAIL: libgomp.oacc-c-c++-common/lib-83.c -foffload=nvptx-none  -O0 
> execution test
> FAIL: libgomp.oacc-c-c++-common/lib-83.c -foffload=nvptx-none  -O2 
> execution test

'./lib-83.exe'; echo XYZ$?ZYX^M
actual time too long^M
Aborted (core dumped)^M

[Bug lto/81847] ICE with LTO enabled

[v at vsamko dot com]

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

--- Comment #4 from Valentine  ---
Created attachment 42002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42002&action=edit
code to reproduce ICE

I reduced (thanks to suggestions above and CReduce) this to the attached
example.

g++ -w -flto -O3  -c gccbug.ii -o gccbug.ii.o

g++ -flto -O3 -Wl,-r gccbug.ii.o -o gccbug.ii.merged.o -nostdlib -Wl,-r
-flto-partition=one

Second command crashes with 

lto1: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:203
0x1317e97 add_symbol_to_partition_1
../../gcc-7.1.0/gcc/lto/lto-partition.c:203
0x1317723 add_references_to_partition
../../gcc-7.1.0/gcc/lto/lto-partition.c:93
0x1317b8e add_symbol_to_partition_1
../../gcc-7.1.0/gcc/lto/lto-partition.c:176
0x1317723 add_references_to_partition
../../gcc-7.1.0/gcc/lto/lto-partition.c:93
0x1317b8e add_symbol_to_partition_1
../../gcc-7.1.0/gcc/lto/lto-partition.c:176
0x1317cab add_symbol_to_partition_1
../../gcc-7.1.0/gcc/lto/lto-partition.c:163
0x1318e63 lto_balanced_map(int, int)
../../gcc-7.1.0/gcc/lto/lto-partition.c:550
0x1312b8d do_whole_program_analysis
../../gcc-7.1.0/gcc/lto/lto.c:3123
0x1312b8d lto_main()
../../gcc-7.1.0/gcc/lto/lto.c:3320
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[amonakov at gcc dot gnu.org]

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

--- Comment #11 from Alexander Monakov  ---
(In reply to Richard Biener from comment #10)
> Now - for refs that have an invariant address in such loop the interleaving
> effectively means that they are independent even in the same iteration. 

Not if there's no "other iteration", i.e. runtime iteration count is 1.

[...]
> for example.  I suppose it's not their intent.  So maybe there's an
> additional
> restriction on the interleaving?  Preserve iteration order of individual
> stmts?  That would prevent autopar in face of just ivdep for example.
> 
> Note that any "handle must-defs 'correctly'" writing is inherently fishy.

I think you're saying that pragma-ivdep and do-concurrent are too hand-wavy
about how the compiler may or must privatize variables, whether it must detect
and handle reductions/inductions etc. But note that LIM is keying on 'simdlen',
and simdlen is also set by OpenMP-SIMD which is more rigorous in that regard,
i.e. privatization is explicit in GIMPLE. And there I believe LIM does not have
the license to disregard may-alias relations *unless* it verifies that loop
iterates at least twice and repeated writes are UB. On this example:

void g(int p, int *out)
{
  int x, y = 0, *r = p ? &x : &y;
  unsigned n = 0;
  asm("" : "+r" (n));
#pragma omp simd
  for (int i = 0; i <= n; i++)
{
//#pragma omp ordered simd
  x = 42;
  out[i] = *r;
}
}

I believe LSM is wrong for n=0, and for any n if the pragma-ordered is
uncommented.

[Bug libgomp/81886] Means to determine at runtime foffload targets specified at compile time

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> FAIL: libgomp.oacc-c-c++-common/parallel-dims.c -foffload=nvptx-none  -O0 
> (test for excess errors)
> FAIL: libgomp.oacc-c-c++-common/parallel-dims.c -foffload=nvptx-none  -O2 
> (test for excess errors)

Failure in more detail:
...
FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/parallel-dims.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test
for excess errors)
Excess errors:
libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/parallel-dims.c:168:9:
warning: using vector_length (32), ignoring 1
...

At line 168, we find:
...
#pragma acc parallel copy (vectors_actual) /* { dg-warning "using vector_length
\\(32\\), ignoring 1" "" { target openacc_nvidia_accel_configured } } */ \
  vector_length (VECTORS) /* { dg-warning "'vector_length' value must be
positive" "" { target c++ } } */
...

AFAICT, openacc_nvidia_accel_configured returns false with the patch because
offload_targets is now nvptx-none instead of nvptx:
...
proc check_effective_target_openacc_nvidia_accel_configured { } {
global offload_targets
if { ![string match "*,nvptx,*" ",$offload_targets,"] } {
return 0
}
...
Note: the gomp-4_0-branch uses openacc_nvidia_accel_selected instead in the
test-case.

[Bug target/81268] [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  ---
(In reply to Eric Gallager from comment #3)
> Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01469.html

I guess due to some server crash / glitch?

> New Revision: 251085
> 
> URL: https://gcc.gnu.org/viewcvs?rev=251085&root=gcc&view=rev
> Log:
> gcc/
> PR target/81754
> PR target/81268

Shouldn't this also result in a respective auto-comment to PR81754?

[Bug target/81754] Building of cross compiler avr-elf is broken

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P4
 Status|UNCONFIRMED |RESOLVED
   Host|x86_64-linux-gnu|
Version|7.0 |8.0
 Resolution|--- |FIXED

--- Comment #1 from Georg-Johann Lay  ---
Fixed by r251085.

[Bug lto/81847] ICE with LTO enabled

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---
Confirmed, disappeared on trunk in r248334 which probably only makes it latent.
The revision changes inlining decisions. Let me take a look.

[Bug target/81268] [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Georg-Johann Lay from comment #4)
> (In reply to Eric Gallager from comment #3)
> > Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01469.html
> 
> I guess due to some server crash / glitch?
> 

Yeah, see the mailing lists about it.

> > New Revision: 251085
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=251085&root=gcc&view=rev
> > Log:
> > gcc/
> > PR target/81754
> > PR target/81268
> 
> Shouldn't this also result in a respective auto-comment to PR81754?

That one must have gotten lost, too...

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #11 from Tom de Vries  ---
(In reply to Tom de Vries from comment #10)
> [ Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01333.html, using
> PR81875 instead of PR81844, since PR81844 was overwritten ]
> 
> Filed comment 3 as PR81875 - omp for loop optimized away
> 
> This PR remains for the analysis of the test-case from comment 0.

My current hypothesis is that this is a cuda bug.

Filed bug report at nvidia, waiting for confirmation.

[Bug libgomp/81805] Another libgomp.c/for-5.c failure on nvptx -- illegal memory access

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
   Last reconfirmed||2017-08-18
 Resolution|FIXED   |---
 Ever confirmed|0   |1

[Bug c++/45033] "delete" does overload resolution for class operands, but shouldn't.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that g++ accepts the code, while clang++ rejects it.

[Bug c++/81533] g++ pops up a constructor for objects that could be initialized at load-time

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1

[Bug c/81887] New: pragma omp ordered simd ignored under -fopenmp-simd

[amonakov at gcc dot gnu.org]

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

Bug ID: 81887
   Summary: pragma omp ordered simd ignored under -fopenmp-simd
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Under -fopenmp-simd, OpenMP pragma 'ordered' is not added to IR, but it should
be.

void f(int *out)
{
#pragma omp simd
  for (int i = 0; i < 100; i++)
#pragma omp ordered simd
out[i/2] = i;
}

$ gcc/cc1 -O2 -fopenmp-simd -fdump-tree-gimple t.c
$ cat t.c.004t.gimple

void f(int*) (int * out)
{
  {
int i;

#pragma omp simd linear(i:1)
for (i = 0; i < 100; i = i + 1)
  {
_1 = i / 2;
_2 = (long unsigned int) _1;
_3 = _2 * 4;
_4 = out + _3;
*_4 = i;
  }
  }
}

[Bug c++/50169] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Johannes Schaub from comment #0)
> The following looks like valid code:
> 
>  struct A { int a; }; 
>  int main() { 
>new struct A {{ }}; 
>  }
> 
> The type-specifier-seq "struct A" is followed by a braced-init-list "{{}}".
> But GCC says:
> 
> main1.cpp: In function 'int main()':
> main1.cpp:3:16: error: types may not be defined in a new-type-id
> main1.cpp:3:17: error: expected unqualified-id before '{' token
> 
> As far as I can see, I would only define a new type if I would say:
> 
> new struct A { };
> 
> But the two-braces disambiguates it.

Confirmed that g++ rejects it, but clang++ rejects it too:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 50169.cc
50169.cc: In function ‘int main()’:
50169.cc:3:15: error: types may not be defined in a new-type-id
  new struct A {{ }};
   ^
50169.cc:3:16: error: expected unqualified-id before ‘{’ token
  new struct A {{ }};
^
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic 50169.cc
50169.cc:3:16: error: expected member name or ';' after declaration specifiers
new struct A {{ }}; 
  ^
50169.cc:3:13: error: 'A' can not be defined in a type specifier
new struct A {{ }}; 
   ^
2 errors generated.
$

...so I'm not sure if it's an incorrect treatment or not...

(In reply to Ville Voutilainen from comment #1)
> Trying
> 
> struct A { int a; }; 
>  int main() { 
>new (struct A) {{ }}; 
>  }
> 
> gives
> 
> internal compiler error: in cxx_eval_bare_aggregate, at cp/semantics.c:6601
> 

I can't reproduce this ICE with gcc8...

I guess I'll leave this in UNCONFIRMED for now.

[Bug c++/50445] Rejects use of constant expression using a pointer non-type template parameter

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
The error message is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 50445.cc
50445.cc: In instantiation of ‘const int X<(& values)>::val0’:
50445.cc:7:22:   required from here
50445.cc:4:19: error: the value of ‘values’ is not usable in a constant
expression
  static int const val0 = values[0];
   ^~~~
50445.cc:1:18: note: ‘values’ was not declared ‘constexpr’
 extern int const values[] = { 1, 2, 3 };
  ^~
50445.cc:7:26: error: size of array ‘array’ is not an integral
constant-expression
 int array[X::val0];
  ^
$

...which I think clears things up. Although maybe the note saying 'values' was
not declared 'constexpr' could have a fix-it hint added to it showing where to
insert the 'constexpr'? Putting in WAITING to see what the reporter thinks.

[Bug libstdc++/81885] operator-> not checked by -D_GLIBCXX_ASSERTIONS

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
No, because there's nothing wrong with calling operator-> on a null unique_ptr:

std::unique_ptr p;
int* pp = p.operator->();

I'd be more inclined to remove the pedantic assertion in debug mode.

[Bug c++/45033] "delete" does overload resolution for class operands, but shouldn't.

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Clang only rejects it in C++98 or C++11 mode, it accepts it for C++14.

EDG accepts it unconditionally.

[Bug libstdc++/81885] operator-> not checked by -D_GLIBCXX_ASSERTIONS

[joerg.rich...@pdv-fs.de]

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

--- Comment #2 from Jörg Richter  ---
Okay, I see your point. But I think calling operator->() to get the pointer is
not a very common use-case. Its more like get() is the right function for this
task.

[Bug c++/81888] New: Structured bindings stopped working

[antoshkka at gmail dot com]

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

Bug ID: 81888
   Summary: Structured bindings stopped working
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The following code worked well on GCC-7.1, but fails on GCC-7.2 with
-std=c++17:



struct do_not_define_std_tuple_size_for_me {
  bool test1 = true;
};

template 
bool is_structured_bindings_work() noexcept {
  auto [a] = T{};
  return a;
}

const bool do_not_use =
is_structured_bindings_work();



Error message:
error: invalid initializer for structured binding declaration
   auto [a] = T{};
^~~

Fix from Bug 78939 does not resolves the issue. Clang-4.0 and GCC-7.1 compile
the code well.

[Bug tree-optimization/81884] [6/7/8 Regression] Invalid code generation with zero size arrays or flexible array members

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Regresses gfortran.dg/reassoc_4.f because we no longer DSE

@@ -207,6 +207,7 @@
   _28 = *weight_94(D);
   _29 = _27 * _28;
   _30 = _10 + _29;
+  *s_91(D)[_9] = _30;
   _173 = _12 + 9;
   _174 = _17 + _173;
   _175 = _19 + _174;
@@ -226,6 +227,7 @@
   _193 = _189 * _192;
   _194 = _28 * _193;
   _195 = _185 + _194;
+  *s_91(D)[_9] = _195;
...

so the restriction is too broad.  Now the question is if we want to allow

struct S { int a[0]; };
struct S (*p)[1];

and (*p)[0].a[4].  Or array of size n and (*p)[n-1].a[4]...

[Bug tree-optimization/81884] [6/7/8 Regression] Invalid code generation with zero size arrays or flexible array members

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #42000|0   |1
is obsolete||

--- Comment #4 from Richard Biener  ---
Created attachment 42003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42003&action=edit
updated patch

[Bug c++/50169] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
EDG rejects it too:

"gr.cc", line 3: error: expected a declaration
 new struct A {{ }}; 
   ^

"gr.cc", line 3: error: type definition is not allowed
 new struct A {{ }}; 
 ^

2 errors detected in the compilation of "gr.cc".


VC++ accepts it though.

I suggest taking it to WG21 as a core issue.

[Bug libstdc++/81885] operator-> not checked by -D_GLIBCXX_ASSERTIONS

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
In fact it's the idiomatic way to get a real pointer from any kind of smart
pointer, e.g. fancy pointers used by allocators (which don't necessarily have a
get member function).

There's even a proposal to standardize a helper utility for doing it, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0653r1.html

It might not be so common for unique_ptr but it's still not dangerous, or
deserving of an assertion. If the returned pointer is dereferenced you'll get a
segfault anyway, so the benefit of an assertion is minimal. It doesn't prevent
any bugs.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 18 Aug 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
> 
> --- Comment #11 from Alexander Monakov  ---
> (In reply to Richard Biener from comment #10)
> > Now - for refs that have an invariant address in such loop the interleaving
> > effectively means that they are independent even in the same iteration. 
> 
> Not if there's no "other iteration", i.e. runtime iteration count is 1.

Not sure about this, I interpret 'ivdep' as there's no dependence for
any number of iterations.

> [...]
> > for example.  I suppose it's not their intent.  So maybe there's an
> > additional
> > restriction on the interleaving?  Preserve iteration order of individual
> > stmts?  That would prevent autopar in face of just ivdep for example.
> > 
> > Note that any "handle must-defs 'correctly'" writing is inherently fishy.
> 
> I think you're saying that pragma-ivdep and do-concurrent are too hand-wavy
> about how the compiler may or must privatize variables, whether it must detect
> and handle reductions/inductions etc. But note that LIM is keying on 
> 'simdlen',
> and simdlen is also set by OpenMP-SIMD which is more rigorous in that regard,
> i.e. privatization is explicit in GIMPLE. And there I believe LIM does not 
> have
> the license to disregard may-alias relations *unless* it verifies that loop
> iterates at least twice and repeated writes are UB. On this example:

Yeah, the middle-end uses safelen which is also used for simdlen.  It has
to adhere to the most conservative definition.

> void g(int p, int *out)
> {
>   int x, y = 0, *r = p ? &x : &y;
>   unsigned n = 0;
>   asm("" : "+r" (n));
> #pragma omp simd
>   for (int i = 0; i <= n; i++)
> {
> //#pragma omp ordered simd
>   x = 42;
>   out[i] = *r;
> }
> }
> 
> I believe LSM is wrong for n=0, and for any n if the pragma-ordered is
> uncommented.

I see.  I wonder if we handle pramga-ordered correctly in vectorization
for say

#pragma omp simd
  for (int i = 0; i <= n; i++)
{
#pragma omp ordered simd
  out[i+2] = 0;
  out[i+1] = 1;
  out[i] = 2;
}

I believe we vectorize this with SLP and unrolling with VF 12 as

   out[i..i+3] = {2, 1, 0, 2};
   out[i+4..i+7] = {1, 0, 2, 1};
   out[i+8..i+11] = {0, 2, 1, 0};

I guess "at the same time" fulfils 'ordered' but does splitting
like above do?  That moves out[i+3] store before out[i+5].

The safest thing would be to remove safelen handling from invariant
motion.

More rigorously defining the semantic of loop->safelen (the
middle-end term) is necessary nevertheless.  I believe omp ordered
doesn't have any middle-end representation?

[Bug c++/81888] [7/8 Regression] Structured bindings stopped working

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.1.0
   Keywords||rejects-valid
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1
Summary|Structured bindings stopped |[7/8 Regression] Structured
   |working |bindings stopped working
   Target Milestone|--- |7.3
  Known to fail||7.2.0

--- Comment #1 from Richard Biener  ---
Confirmed.  The feature was new in GCC 7.

[Bug c/81887] pragma omp ordered simd ignored under -fopenmp-simd

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
See also PR81877 for some discussion and an example where SLP vectorization can
break 'ordered'.

[Bug c++/50456] attributes ignored on member templates

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
It errors for me:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -O2 50456.cc
50456.cc: In function ‘int main(int, char**)’:
50456.cc:8:15: warning: unused parameter ‘argc’ [-Wunused-parameter]
 int main (int argc, char *argv[]) {
   ^~~~
50456.cc:8:32: warning: unused parameter ‘argv’ [-Wunused-parameter]
 int main (int argc, char *argv[]) {
^
50456.cc:10:28: error: call to ‘Object::should_error’ declared with
attribute error: Calling this function should trigger a compiler error
  FloatObject::should_error (7);
  ~~^~~
$

[Bug c++/49224] [C++0x] Scoped enumeration instantiated even if not required

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Johannes Schaub from comment #0)
> GCC should not instantiate the definition of the scoped enumeration:
> 
> template
> struct A {
>   enum class B {
> X = T::value
>   };
> };
> 
> int main() {
>   A a;
> }
> 
> GCC error:
> 
> main1.cpp: In instantiation of ‘A’:
> main1.cpp:9:10:   instantiated from here
> main1.cpp:3:14: error: ‘value’ is not a member of ‘int’
> 
> This code looks well-formed. Only if we look into the enumeration, as
> "A::B::X", the definition of the enumeration is required to exist and
> thus implicitly instantiated. This is specified at 14.7.1p1 and p2.

Confirmed that g++ rejects it, but clang rejects it too:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 49224.cc
49224.cc: In instantiation of ‘struct A’:
49224.cc:9:9:   required from here
49224.cc:3:13: error: ‘value’ is not a member of ‘int’
  enum class B {
 ^
49224.cc: In function ‘int main()’:
49224.cc:9:9: warning: unused variable ‘a’ [-Wunused-variable]
  A a;
 ^
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic 49224.cc
49224.cc:3:7: error: expected identifier or '{'
enum class B {
 ^
49224.cc:3:2: warning: declaration does not declare anything
[-Wmissing-declarations]
enum class B {
^~~~
49224.cc:9:9: warning: unused variable 'a' [-Wunused-variable]
A a;
   ^
2 warnings and 1 error generated.
$

Since I'm not sure if this is intentional or not, I'm leaving it UNCONFIRMED.

[Bug c++/49224] [C++0x] Scoped enumeration instantiated even if not required

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Actually scratch that, my version of clang is old so it doesn't default to
c++11. When I manually force -std=c++0x, clang accepts the code, while g++
still rejects it:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++0x 49224.cc
49224.cc: In instantiation of ‘struct A’:
49224.cc:9:9:   required from here
49224.cc:3:13: error: ‘value’ is not a member of ‘int’
  enum class B {
 ^
49224.cc: In function ‘int main()’:
49224.cc:9:9: warning: unused variable ‘a’ [-Wunused-variable]
  A a;
 ^
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -std=c++0x 49224.cc
49224.cc:9:9: warning: unused variable 'a' [-Wunused-variable]
A a;
   ^
1 warning generated.
$

So confirming then.

[Bug c++/26748] gimplify_expr_stmt in cp-gimplifer.c does warnings

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #0)
> I don't have a testcase but gimplify_expr_stmt produces warnings:
> warning (OPT_Wextra, "statement with no effect");
> ...
>   else if (warn_unused_value)
> warn_if_unused_value (stmt, input_location);

WAITING on a testcase

[Bug middle-end/81889] New: [7 Regression] bogus warnings with -Wmaybe-uninitialized -O3

[janus at gcc dot gnu.org]

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

Bug ID: 81889
   Summary: [7 Regression] bogus warnings with
-Wmaybe-uninitialized -O3
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Please consider this simple Fortran test case:


module m

   type t
  integer, dimension(:), pointer :: list
   end type

contains

   subroutine s(n, p, Y)
  integer, intent(in) :: n
  type(t) :: p
  real, dimension(:) :: Y

  real, dimension(1:16) :: xx

  if (n > 3) then
 xx(1:n) = 0.
 print *, xx(1:n)
  else
 xx(1:n) = Y(p%list(1:n))
 print *, sum(xx(1:n))
  end if

   end subroutine

end module



When compiled with "gfortran-7 -Wmaybe-uninitialized -O3 -c", it yields:

maybe_uninit.f90:21:0:

  print *, sum(xx(1:n))

Warning: ‘xx[3]’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[4]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[5]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[6]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[7]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[8]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[9]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[10]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[11]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[12]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[13]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[14]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
maybe_uninit.f90:21:0: Warning: ‘xx[15]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]


Obviously no value that is used is actually uninitialized. gfortran 6 and
earlier does not show these warnings. Also decreasing the optimization level
makes them disappear.

[Bug c++/47256] "--sysroot" option is not passed to COLLECT_GCC_OPTIONS

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #3)
> Patches go to gcc-patches...

WAITING until patch is submitted

[Bug middle-end/81889] [7 Regression] bogus warnings with -Wmaybe-uninitialized -O3

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67679

--- Comment #1 from janus at gcc dot gnu.org ---
This may be related to other -Wmaybe-uninitialized regressions like PR 67679.

[Bug c++/49531] Doesn't resolve to conversion function template specialization in expressions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, clang accepts it with both standards:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++03 49531.cc
49531.cc: In function ‘void f()’:
49531.cc:5:12: error: statement cannot resolve address of overloaded function
 void f() { &A::operator int; }
^~
$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++0x 49531.cc
49531.cc: In function ‘void f()’:
49531.cc:5:12: error: statement cannot resolve address of overloaded function
 void f() { &A::operator int; }
^~
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -std=c++03 49531.cc
49531.cc:5:12: warning: expression result unused [-Wunused-value]
void f() { &A::operator int; }
   ^~~~
1 warning generated.
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -std=c++0x 49531.cc
49531.cc:5:12: warning: expression result unused [-Wunused-value]
void f() { &A::operator int; }
   ^~~~
1 warning generated.
$

(although in my opinion the code still just looks weird...)

[Bug c++/51234] ambiguity in mangling function attribute

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
Compiles successfully for me with no warnings or errors with gcc8.

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 51234.cc
$

[Bug c++/51545] missing -Wparentheses diagnostic with compound assignment used as condition

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirmed.

[Bug ipa/81877] [7/8 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone

[amonakov at gcc dot gnu.org]

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

--- Comment #13 from Alexander Monakov  ---
> More rigorously defining the semantic of loop->safelen (the
> middle-end term) is necessary nevertheless.  I believe omp ordered
> doesn't have any middle-end representation?

Except on nvptx, 'omp ordered' in omp-simd context becomes a stmt sequence
bracketed with IFN_GOMP_SIMD_ORDERED_{START,END}, which completely disables
cross-iteration vectorization aiui. So your example doesn't get vectorized (not
even with SLP).

(on omp/ptx the approach is different)

[Bug inline-asm/81890] New: asm memory constraints are difficult and not well documented

[amodra at gmail dot com]

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

Bug ID: 81890
   Summary: asm memory constraints are difficult and not well
documented
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

gcc doesn't have a simple way to say that a pointer passed to an inline asm is
used to address an array.  "m" (*p) unfortunately only makes the asm depend on
the first element of an array.

The following came about from a discussion starting at
https://gcc.gnu.org/ml/gcc/2017-08/msg00116.html

Compiling with -DTRY=4 or -DTRY=6 give good results, and I believe are
reasonable to extend to types other than char without falling foul of aliasing
rules, but these tricks are a little contrived and not documented.  

-DTRY=5 is no doubt what should be used but this does not appear to be
documented.


/* -O3 */
#include 

#if TRY == 1
int get_string_length (const char *p)
{
  int count;

  /* Unfortunately the "m" here only makes the asm depend on p[0], so
 this is not safe.  The initialization of buff in main can be
 partly moved past the get_string_length call.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 2
/* No better than the above.  */
int get_string_length (const char p[])
{
  int count;

  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 3
int get_string_length (const char *p)
{
  int count;

  /* Warns unfortunately, but works, at least on some versions of gcc.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*(const void *)p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 4
int get_string_length (const char *p)
{
  int count;

  /* A way of saying that p points to an array of indeterminate
 length, near enough.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*(const struct {char a; char x[];} *) p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 5
int get_string_length (const char *p)
{
  int count;

  /* The right way to say that p points to an array of char of
 indeterminate length.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*(const char (*)[]) p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 6
int get_string_length (const char *p)
{
  int count;

  /* Make gcc lose detailed information regarding the memory pointed
 to by p.  This, in conjuction with "m" (*p) as an input below
 will act similarly to a "memory" clobber, but is more precise in
 that it doesn't say all memory may be written.  */
  __asm__ ("#%0" : "+X" (p));

  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#elif TRY == 7
int get_string_length (const char *p)
{
  int count;

  /* As recommended by the gcc info doc.  Suffers from needing to know
 the size of the array.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "m" (*(const struct {char x[48];} *) p), "0" (-1), "a" (0)
   );
  return -2 - count;
}
#else
int get_string_length (const char *p)
{
  int count;

  /* Bog standard, but unfortunately says to gcc that memory might be
 written by the asm.  As can be seen by inspecting the code
 produced, this means "expected" below must be read before calling
 get_string_length, using an extra register.  This may result in
 less optimized code in real-world examples.  */
  __asm__ ("repne scasb"
   : "=c" (count), "+D" (p)
   : "0" (-1), "a" (0)
   : "memory"
   );
  return -2 - count;
}
#endif

int expected = 4;

int
main ()
{
  char buff[48] = "hello world";
  buff[4] = 0;
  int b = expected;
  int a = get_string_length (buff);
  printf ("%s: %d %d\n", buff, a, b);
  return 0;
}

[Bug inline-asm/81890] asm memory constraints are difficult and not well documented

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1

[Bug c++/71527] wrong type mismatch while template argument deduction/substitution

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

 CC||benni.buch at gmail dot com

--- Comment #2 from Benjamin Buch  ---
Bug does still exist in:

$ g++ --version
g++ (GCC) 8.0.0 20170818 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug lto/81847] ICE with LTO enabled

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Created attachment 42004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42004&action=edit
A bit smaller test-case

Smaller test-cast which needs to add --param lto-min-partition=1.

Problem is following, we create an isra clone and we'll put it into a comdat
group:

_Z11format_packIJiiN1a1b1fIcccvDpT_.isra.37/2088
(_Z11format_packIJiiN1a1b1fIcccvDpT_.isra.37) @0x2b2b65795b80
  Type: function definition analyzed
  Visibility: prevailing_def_ironly
comdat_group:_ZN3PigC5IiJiN1a1b1fIcccET_DpT0_ artificial
  Same comdat group as: _ZN3PigC2IiJiN1a1b1fIcccET_DpT0_/371
  References: __gxx_personality_v0/1347 (addr)
  Referring: 
  Read from file: gccbug.o
  Availability: local
  First run: 0
  Function flags: local
  Called by: _ZN3PigC2IiJiN1a1b1fIcccET_DpT0_/371 (1.00 per call) 
  Calls: _ZN1a1b1fIcccE2crEl/1473 _ZN1a5tupleIJiiNS_1b1fIcccD1Ev/607
_ZN1a1b1fIcccE2crEl/1473 (0.37 per call)
_ZN1a5tupleIJiiNS_1b1fIcccD2Ev/2938 (inlined) (1.00 per call)
_Z12format_tupleIN1a5tupleIJiiNS0_1b1fIcccELi3EEvT_NS0_1lIiXT0_EEE.isra.10/1803
(inlined) (1.00 per call)
_ZN1a5tupleIJiiNS_1b1fIcccC2IJiiS3_ELj1EEEDpT_/798 (inlined) (1.00 per
call) _ZN1a1b1fIcccE2coC1EPcNS_9allocatorIcEE/1471 (1.00 per call) (can throw
external) _ZN1a1b1fIcccE2csEv/1470 (1.00 per call) (can throw external) 

Then we start partitioning and following symbols are put to a partition:

add_symbol_to_partition: __base_ctor /371
Step 1: added _Z11format_packIJiiN1a1b1fIcccvDpT_.isra.37/2088, size 931,
cost 3013/1012 best 3013/1012, step 1

the partition is finished and in a next partition:
Symbol node __base_ctor /371 now used in multiple partitions

and then we attempt to add again the isra clone and we fail. That triggers the
assert.
We have:

   113  static bool
   114  add_symbol_to_partition_1 (ltrans_partition part, symtab_node *node)
   115  {
...
   124/* non-duplicated aliases or tunks of a duplicated symbol needs to be
output
   125   just once.
   126  
   127   Be lax about comdats; they may or may not be duplicated and we may
   128   end up in need to duplicate keyed comdat because it has unkeyed
alias.  */
   129if (c == SYMBOL_PARTITION && !DECL_COMDAT (node->decl)
   130&& symbol_partitioned_p (node))
   131  return false;

Shouldn't be this place somehow adjusted in order to handle symbols in comdat
group that are actually
not DECL_COMDATs? Honza?

[Bug libstdc++/81891] New: heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[pdziepak at quarnos dot org]

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

Bug ID: 81891
   Summary: heap-use-after-free if inserting element in
std::unordered_map(InputIt, InputIt) throws
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdziepak at quarnos dot org
  Target Milestone: ---

GCC 7.1.1 from Fedora 26 (gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC))

Reproducer:
--snip--
#include 
#include 

struct fails_on_copy {
fails_on_copy() = default;
fails_on_copy(const fails_on_copy&) {
throw 0;
};
};

int main()
{
std::array, 128> range;
try {
std::unordered_map umap(range.begin(),
range.end());
} catch(...) { }
}
--snip--

When built with AddressSanitizer:

g++ -fsanitize=address -g test.cc -o test

The following error is reported:

$ ./test
=
==18550==ERROR: AddressSanitizer: heap-use-after-free on address 0x61900080
at pc 0x7f3ae4dbca1a bp 0x7ffc9cfc6fc0 sp 0x7ffc9cfc6768
WRITE of size 1096 at 0x61900080 thread T0
#0 0x7f3ae4dbca19  (/lib64/libasan.so.4+0x5ea19)
#1 0x401c62 in std::_Hashtable,
std::allocator >,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::clear() /usr/include/c++/7/bits/hashtable.h:2039
#2 0x4019b7 in std::_Hashtable,
std::allocator >,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::~_Hashtable() /usr/include/c++/7/bits/hashtable.h:1364
#3 0x40205b in std::_Hashtable,
std::allocator >,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_Hashtable*>(std::pair*, std::pair*, unsigned long, std::hash
const&, std::__detail::_Mod_range_hashing const&,
std::__detail::_Default_ranged_hash const&, std::equal_to const&,
std::__detail::_Select1st const&, std::allocator > const&) /usr/include/c++/7/bits/hashtable.h:962
#4 0x401b27 in std::_Hashtable,
std::allocator >,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_Hashtable*>(std::pair*, std::pair*, unsigned long, std::hash
const&, std::equal_to const&, std::allocator > const&) /usr/include/c++/7/bits/hashtable.h:444
#5 0x401960 in std::unordered_map,
std::equal_to, std::allocator >
>::unordered_map*>(std::pair*, std::pair*, unsigned long, std::hash
const&, std::equal_to const&, std::allocator > const&) /usr/include/c++/7/bits/unordered_map.h:176
#6 0x40138b in main /home/pdziepak/gcc/test.cc:15
#7 0x7f3ae40f84d9 in __libc_start_main (/lib64/libc.so.6+0x204d9)
#8 0x401119 in _start (/home/pdziepak/gcc/test+0x401119)

0x61900080 is located 0 bytes inside of 1096-byte region
[0x61900080,0x619004c8)
freed by thread T0 here:
#0 0x7f3ae4e3efd0 in operator delete(void*) (/lib64/libasan.so.4+0xe0fd0)
#1 0x403cfb in
__gnu_cxx::new_allocator::deallocate(std::__detail::_Hash_node_base**,
unsigned long) /usr/include/c++/7/ext/new_allocator.h:125
#2 0x403145 in
std::allocator_traits
>::deallocate(std::allocator&,
std::__detail::_Hash_node_base**, unsigned long)
/usr/include/c++/7/bits/alloc_traits.h:462
#3 0x402963 in
std::__detail::_Hashtable_alloc, false> >
>::_M_deallocate_buckets(std::__detail::_Hash_node_base**, unsigned long)
/usr/include/c++/7/bits/hashtable_policy.h:2121
#4 0x40218d in std::_Hashtable,
std::allocator >,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_deallocate_buckets(std::__detail::_Hash_node_base**,
unsigned long) /usr/include/c++/7/bits/hashtable.h:363
#5 0x401d37 in std::_Hashtable,
std::allocator >,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_deallocate_buckets() /usr/include/c++/7/bits/hashtable.h:368
#6 0x402035 in std::_Hashtable,
std::allocator >,
std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_Hashtable*>(std::pair*, std::pair*, unsigned long, std::hash
const&, std::__detail::_Mod_range_hashin

[Bug c++/50169] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
I have sent this to Core for consideration.

[Bug c++/81327] cast to void* does not suppress -Wclass-memaccess

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
Note that this currently blocks building Qt with gcc 8. We could work around it
by turning our void* casts to char* casts, but we have a preference for fixing
this problem in the compiler.

[Bug c++/71003] __extension__ silences pedwarn for "\e" in C but not in C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The manual says clearly that it should work so this is a G++ bug.

'-Wpedantic' does not cause warning messages for use of the alternate keywords
whose names begin and end with '__'.  Pedantic warnings are also disabled in
the expression that follows __extension__.

[Bug c++/51789] GCC does not consider SFINAE in template parameter list of template parameter pack

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
g++ errors on the code for me:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 51789.cc
51789.cc:4:28: error: ‘enable_if’ in namespace ‘std’ does not name a template
type
 template’ before ‘<’ token
 template’ before ‘<’ token
51789.cc:7:12: error: expected identifier before ‘...’ token
 > class...
^~~
51789.cc:7:12: error: expected unqualified-id before ‘...’ token
51789.cc:12:17: error: too many initializers for ‘A’
 A a = {1, 2.0, 3};
 ^
$ 

Is it missing an include of a header or something?

[Bug c++/52130] missing check for matching underlying type during instantiation of enum member of class template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
You can make g++ reject it with -pedantic-errors:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic-errors -std=c++11 52130.cc
52130.cc:2:27: error: ‘enum S::E’ is an enumeration template [-Wpedantic]
 template enum S::E : T { e };
   ^~~~
$

Is that sufficient?

[Bug c++/51789] GCC does not consider SFINAE in template parameter list of template parameter pack

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|WAITING |NEW

--- Comment #2 from Jonathan Wakely  ---
Yes, it is not a complete testcase. It should have #include , or
here's a complete version:

namespace std {
template struct is_same { static const bool value =
false; };
template struct is_same { static const bool value = true; };
template struct enable_if { };
template struct enable_if { using type = T; };
}

struct A {  
  template<
typename ...T, 
template::value, int
  >::type ...
> class...
  >
  A(T...); 
}; 

A a = {1, 2.0, 3};

[Bug c/80528] reimplement gnulib's "useless-if-before-free" script as a compiler warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I think a warning like this might be useful, although I probably wouldn't want
to enable under -Wall or -Wextra.   (GCC could also use branch probabilities to
decide whether or not to warn.)

That said, I would expect GCC to get rid of the tests with
-fdelete-null-pointer-checks.  As it is, it eliminates the call to free when
the pointer is known to be null but not the test itself (see below).  That
seems quite suboptimal to me since in the absence of any other information a
pointer being passed to free is far more likely to be non-null than not.  Clang
and ICC both optimize the function below into an unconditional jump to free. 
So while I think implementing the optimization is the better solution here, the
warning could also help improve the efficiency of the emitted code in its
absence.

$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout  b.c
void free (void*);

void g (void *p)
{
  if (p)// test retained
free (p);
  else
free (p);   // eliminated
}


;; Function g (g, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=0)

Removing basic block 5
g (void * p)
{
   [100.00%] [count: INV]:
  if (p_2(D) != 0B)
goto ; [53.47%] [count: INV]
  else
goto ; [46.53%] [count: INV]

   [53.47%] [count: INV]:
  free (p_2(D)); [tail call]

   [100.00%] [count: INV]:
  return;

}

[Bug target/80689] 128 bit loads generated for structure copying with gcc 7.1.0 and leads to STLF stalls in avx2 targets.

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-18
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #8 from Martin Jambor  ---
I have a prototype patch and will start testing and benchmarking it soon.

[Bug c++/48829] g++ no warning initializing a variable using itself

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to matferib from comment #0)
> This code issues a warning:
> 
> g++ -Wall
> int i = 5 + i;
> warning: ‘i’ may be used uninitialized in this function
> 
> This code does not:
> string s = string("str") + s;
> 
> Neither this:
> string s(string("str") + s);
> 
> Shouldnt the 2 last ones issue warnings too?

(In reply to Jonathan Wakely from comment #1)
> The string case calls a function (the overloaded operator+ or std::string)
> so is actually closer to:
> 
>   int f(int);
>   int i = f(i);
> 
> which doesn't warn either (although it should do, ideally)
> 
> This is similar to PR 48483, maybe even a dup.

So, I combined all the snippets into a single testcase, and g++ doesn't even
warn on the first one anymore:

$ cat 48829.cc
#include 

using namespace std;

int i = 5 + i;

string s = string("str") + s;

string ss(string("str") + ss);

int f(int);
int ii = f(ii);
$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Wuninitialized -Winit-self
-Weffc++ -O2 48829.cc
$ 

Same with all other optimization levels I tried. So, confirmed.

[Bug tree-optimization/81673] Harmful SLP vectorization

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Depends on||80689

--- Comment #5 from Martin Jambor  ---
Benchmarking the patch revealed that without addressing PR 80689
first, it severely harms -Ofast performance of 538.imagick_r.  With PR
80689 addressed, it helps as intended.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
[Bug 80689] 128 bit loads generated for structure copying with gcc 7.1.0 and
leads to STLF stalls in avx2 targets.

[Bug tree-optimization/81892] New: suboptimal code for a if (p) free(p) else free(p)

[msebor at gcc dot gnu.org]

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

Bug ID: 81892
   Summary: suboptimal code for a if (p) free(p) else free(p)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As mentioned in bug 80528, comment 2, GCC generates suboptimal code for the
following test case.  It would be more optimal to emit an unconditional jump to
free as Clang and ICC do.

Separately it might also be worth considering eliminating the 'if (p)' test
altogether, even in cases with no else clause.  I.e., using
-fdelete-null-pointer-checks to transform 'if (p) free (p)' to a call to an
unconditional free (p).  Since (in the absence of any information to the
contrary) a pointer passed to free() is far less likely to be null than not,
keeping the test only makes the code bigger and slower.

$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout  b.c
void free (void*);

void g (void *p)
{
  if (p)
free (p);
  else
free (p);
}


;; Function g (g, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=0)

Removing basic block 5
g (void * p)
{
   [100.00%] [count: INV]:
  if (p_2(D) != 0B)
goto ; [53.47%] [count: INV]
  else
goto ; [46.53%] [count: INV]

   [53.47%] [count: INV]:
  free (p_2(D)); [tail call]

   [100.00%] [count: INV]:
  return;

}

[Bug tree-optimization/81892] suboptimal code for a if (p) free(p) else free(p)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80528

--- Comment #1 from Martin Sebor  ---
See bug 80528 for a related request.

[Bug c++/52130] missing check for matching underlying type during instantiation of enum member of class template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|WAITING |NEW

--- Comment #2 from Jonathan Wakely  ---
I don't know what an "enumeration template" is, but I would say no. The code
should be rejected because S::E is declared with an underlying type of int,
then redeclared with an underlying type that depends on the template parameter.

The pedwarn about enumeration types is something unrelated, and predates fixed
underlying types by more than a decade.

[Bug tree-optimization/81892] suboptimal code for a if (p) free(p) else free(p)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80519
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Related to bug 80519 but I'll leave this one separate because this one mentions
the "else" case and 80519 doesn't

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 Ever confirmed|0   |1

[Bug c++/52320] missing destructor call after thrown exception in initializer

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to Daniel Krügler from comment #1)
> Confirmed for 4.7.0 20120218 (experimental).
> 

(In reply to Daniel Krügler from comment #3)
> (In reply to comment #2)
> 
> Agreed. It seems that the fix did not solve some array-related corner cases
> like this one.

Changing status to NEW then.

[Bug c++/52801] improve selective typedef unwrapping

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic, error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that the notes could ease up on the template spew; g++ output is now:

$ /usr/local/bin/g++ -fsyntax-only 52801.cc
52801.cc: In function ‘void foo()’:
52801.cc:9:8: error: no match for ‘operator=’ (operand types are
‘std::__cxx11::string {aka std::__cxx11::basic_string}’ and
‘std::vector’)
  str = vec;
^~~
In file included from /usr/local/include/c++/8.0.0/string:52:0,
 from 52801.cc:2:
/usr/local/include/c++/8.0.0/bits/basic_string.h:627:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]’
   operator=(const basic_string& __str)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:627:7: note:   no known
conversion for argument 1 from ‘std::vector’ to ‘const
std::__cxx11::basic_string&’
/usr/local/include/c++/8.0.0/bits/basic_string.h:666:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const _CharT*)
[with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’
   operator=(const _CharT* __s)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:666:7: note:   no known
conversion for argument 1 from ‘std::vector’ to ‘const char*’
/usr/local/include/c++/8.0.0/bits/basic_string.h:677:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’
   operator=(_CharT __c)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:677:7: note:   no known
conversion for argument 1 from ‘std::vector’ to ‘char’
/usr/local/include/c++/8.0.0/bits/basic_string.h:695:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’
   operator=(basic_string&& __str)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:695:7: note:   no known
conversion for argument 1 from ‘std::vector’ to
‘std::__cxx11::basic_string&&’
/usr/local/include/c++/8.0.0/bits/basic_string.h:749:7: note: candidate:
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::initializer_list<_Tp>) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’
   operator=(initializer_list<_CharT> __l)
   ^~~~
/usr/local/include/c++/8.0.0/bits/basic_string.h:749:7: note:   no known
conversion for argument 1 from ‘std::vector’ to
‘std::initializer_list’
$

[Bug c++/80763] [7/8 Regression] -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #7)
> Still seems to be broken, over a month later.

Still broken, a couple of months even later ...

[Bug go/81893] New: [8 regression] compilation error in libgo starting with r251127

[seurer at gcc dot gnu.org]

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

Bug ID: 81893
   Summary: [8 regression] compilation error in libgo starting
with r251127
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: seurer at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

I only saw this on powerpc64 big endian.

/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c: In function 'dumpregs':
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:349:19: error:
initialization of 'mcontext_t * {aka struct  *}' from incompatible
pointer type 'union uc_regs_ptr *' [-Werror=incompatible-pointer-types]
   mcontext_t *m = &((ucontext_t*)(context))->uc_mcontext;
   ^
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:353:37: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
runtime_printf("r%d %X\n", i, m->regs->gpr[i]);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:354:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("pc  %X\n", m->regs->nip);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:355:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("msr %X\n", m->regs->msr);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:356:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("cr  %X\n", m->regs->ccr);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:357:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("lr  %X\n", m->regs->link);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:358:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("ctr %X\n", m->regs->ctr);
 ^~~~
 gregs
/home/seurer/gcc/gcc-trunk/libgo/runtime/go-signal.c:359:33: error: 'mcontext_t
{aka struct }' has no member named 'regs'; did you mean 'gregs'?
   runtime_printf("xer %X\n", m->regs->xer);
 ^~~~
 gregs

[Bug preprocessor/81419] GCC wrongly suggests function-like macro as fixit hint for undefined object-like macro

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80567,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80684
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  There are few other similar bugs for these fix-it hints (e.g.,
pr80567 or pr80684).  I haven't looked at the implementation but from the
symptoms it feels like the problem is that the search doesn't fully consider
the context in which the undeclared is used.   I.e., it doesn't distinguish
between a function call, other kinds of expressions, a type, or even a keyword,
etc.

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The problem is that the _Hashtable constructor delegates to another
constructor, so if an exception happens in the delegating constructor the
object has been constructed and its destructor will run. The delegating
constructor calls _M_deallocate_buckets() but doesn't zero the _M_buckets
pointer, so the destructor tries to deallocate them again.

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
The regression started with r214986 which introduced the constructor
delegation, but didn't change the logic to account for the destructor running.

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I think this might be all we need to do to fix it:

--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -973,17 +973,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_bucket_count = __bkt_count;
  }

-   __try
- {
-   for (; __f != __l; ++__f)
- this->insert(*__f);
- }
-   __catch(...)
- {
-   clear();
-   _M_deallocate_buckets();
-   __throw_exception_again;
- }
+   for (; __f != __l; ++__f)
+ this->insert(*__f);
   }

   template

[Bug go/81893] [8 regression] compilation error in libgo starting with r251127

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Did you test powerpc64 little endian?

[Bug web/81894] New: Typo in x86 built-in function list

[lh_mouse at 126 dot com]

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

Bug ID: 81894
   Summary: Typo in x86 built-in function list
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions
  says:

```
The following built-in functions are available when -mlzcnt is used. All of
them generate the machine instruction that is part of the name.

unsigned short __builtin_ia32_lzcnt_16(unsigned short);
unsigned int __builtin_ia32_lzcnt_u32(unsigned int);
unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long);
```

The first function `__builtin_ia32_lzcnt_16()` doesn't exist. It is
`__builtin_ia32_lzcnt_u16()` that exists.

[Bug c++/80567] bogus fixit hint for undeclared memset: else

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug c/80529] Split "C++ style comments are not allowed in ISO C90" pedwarn into its own warning flag

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
I also don't think that adding a pure style warning for // comments is in line
with GCC philosophy.  Quoting from the GCC manual:

  Warnings are diagnostic messages that report constructions that are not
  inherently erroneous but that are risky or suggest there may have been
  an error. 

Unlike with the traditional C-style comments, I don't know of any problems due
to C++-style comments, so I don't think adding a warning option for them would
be appropriate.

Regarding the exceptions cited in comment #2, I believe those exist not so much
to help enforce particular coding styles but rather to avoid relying on C++
features that, at the time they were made available in G++, either weren't
universally supported or weren't implemented efficiently enough to be suitable
for all projects (e.g., embedded code would avoid some of these C++ features to
minimize code bloat).

[Bug c++/80684] poor error message and fix-it hint for a function with an argument of undeclared type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
For me the fix-it is just:

$ /usr/local/bin/g++ -S -Wall -Wextra -pedantic 80684.cc
80684.cc:1:15: error: variable or field ‘f’ declared void
 void f (string);
   ^
80684.cc:1:9: error: ‘string’ was not declared in this scope
 void f (string);
 ^~
80684.cc:1:9: note: suggested alternative: ‘__strong’
 void f (string);
 ^~
 __strong
$

When I include the header, the message is:

$ /usr/local/bin/g++ -S -Wall -Wextra -pedantic 80684.cc
80684.cc:3:15: error: variable or field ‘f’ declared void
 void f (string);
   ^
80684.cc:3:9: error: ‘string’ was not declared in this scope
 void f (string);
 ^~
80684.cc:3:9: note: suggested alternative:
In file included from /usr/local/include/c++/8.0.0/string:39:0,
 from 80684.cc:1:
/usr/local/include/c++/8.0.0/bits/stringfwd.h:74:33: note:  
‘std::__cxx11::string’
   typedef basic_stringstring;
 ^~
$

It seems like in this second case where  is already included, the ideal
fix-it would be to suggest inserting the 'std::' prefix before 'string', or
adding a "using namespace std;" directive earlier in the file. Thus,
confirming.

[Bug c++/81895] New: gcc rejects out-of-line definition of enum member of class template under -pedantic-errors

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 81895
   Summary: gcc rejects out-of-line definition of enum member of
class template under -pedantic-errors
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

g++ -std=c++11 -pedantic-errors has a rejects-valid on this:

template struct S { enum class E : int; };
template enum class S::E : int { e };
S::E x = S::E::e;

The bogus error is:

error: 'enum S::E' is an enumeration template [-Wpedantic]

[Bug c++/52130] missing check for matching underlying type during instantiation of enum member of class template

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #3 from Richard Smith  ---
The diagnostic in #1 is not only wrong for this case, it's also a rejects-valid
in the case where the underlying types match. I've filed
https://gcc.gnu.org/PR81895 for that.

[Bug c/80529] Split "C++ style comments are not allowed in ISO C90" pedwarn into its own warning flag

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Sebor from comment #5)
> I also don't think that adding a pure style warning for // comments is in
> line with GCC philosophy.  Quoting from the GCC manual:
> 
>   Warnings are diagnostic messages that report constructions that are not
>   inherently erroneous but that are risky or suggest there may have been
>   an error. 
> 
> Unlike with the traditional C-style comments, I don't know of any problems
> due to C++-style comments, so I don't think adding a warning option for them
> would be appropriate.
> 
> Regarding the exceptions cited in comment #2, I believe those exist not so
> much to help enforce particular coding styles but rather to avoid relying on
> C++ features that, at the time they were made available in G++, either
> weren't universally supported or weren't implemented efficiently enough to
> be suitable for all projects (e.g., embedded code would avoid some of these
> C++ features to minimize code bloat).

Actually I guess a better comparison would be -Wdeclaration-after-statement,
which you can get as part of -std=c89 -pedantic, but which you can also get
separately for other standards. Remember, gcc already warns for // comments
with
-std=gnu89 -pedantic, so splitting it into a new option wouldn't be so much
adding a warning option as it would be enabling an existing warning option for
other standards.

[Bug preprocessor/81794] "would be stringified in traditional C" warning should be controlled by -Wtraditional

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Please keep pinging the patch weekly until it's reviewed.

[Bug c++/44283] bad error recovery for explicit template instantiation in wrong namespace

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #0)
> namespace NS
> {
> typedef int X;
> 
> template void f(X f, T t) { }
> }
> 
> template void f(X, int); // (1)
> 
> template void f(int, char);  // (2)
> 
> 
> The code is invalid, the explicit instantiations should be inside NS or
> should be qualified e.g.
> template void NS::func(X, int);
> 
> But the diagnostic for instantiation (1) is unhelpful:
> 
> bug.cc:8:17: error: variable or field 'f' declared void
> bug.cc:8:16: error: expected ';' before '(' token
> 
> This is closely related to Bug 16663 but the diagnostic for (2) implies it
> might be possible to improve things without fixing bug 16663, as this is
> much better:
> 
> bug.cc:10:26: error: 'f' is not a template function
> 
> Is it possible to give the same "is not a template function" diagnostic for
> (1)?

The message is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44283.cc
44283.cc:8:17: error: variable or field ‘f’ declared void
 template void f(X, int); // (1)
 ^
44283.cc:8:16: error: expected ‘;’ before ‘(’ token
 template void f(X, int); // (1)
^
44283.cc:10:26: error: ‘f’ is not a template function
 template void f(int, char);  // (2)
  ^
$

so it has the "is not a template function" diagnostic now, but it could still
probably be improved.

> 
> Comeau does significantly better, reporting:
>identifier "X" is undefined
> and 
>"f" is not a class or function template name in the current scope
> 
> 
> 
> If the invalid instantiation is for a class template the diagnostic is fine:
> 
> namespace NS
> {
> template struct S;
> }
> 
> template struct S;
> 
> bug2.cc:6:17: error: 'S' is not a template
> bug2.cc:6:19: error: 'X' was not declared in this scope
> bug2.cc:6:17: error: explicit instantiation of non-template type 'S'
> 
> The only improvement I would make would be to add something like "in this
> scope" to the first error.
> 

With carets, this is now:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44283_2.cc
44283_2.cc:6:17: error: ‘S’ is not a class template
 template struct S;
 ^
44283_2.cc:6:19: error: ‘X’ was not declared in this scope
 template struct S;
   ^
44283_2.cc:6:17: error: explicit instantiation of non-template type ‘S’
 template struct S;
 ^
$

(note the addition of the word 'class')

> 
> Here's another bad diagnostic for instantiating a template function, which
> doesn't have any undeclared type:
> 
> namespace NS
> {
> template void g() { }
> }
> 
> template void g<0>();
> 
> bug3.cc:6:15: error: variable or field 'g' declared void
> bug3.cc:6:16: error: expected ';' before '<' token
> 
> Surely it's possible to say "g is not a template function" when the compiler
> sees "template ... g<...>" ?
> 

This is still bad even with carets:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 44283_3.cc
44283_3.cc:6:15: error: variable or field ‘g’ declared void
 template void g<0>();
   ^
44283_3.cc:6:16: error: expected ‘;’ before ‘<’ token
 template void g<0>();
^
$

> Comeau is much better again:
> 
> "ComeauTest.c", line 6: error: g is not a template,
>   Should it be XX::g?, where XX is some namespace?
>   Did you #include the right header?
>   template void g<0>();
> ^
> 
> "ComeauTest.c", line 6: error: invalid explicit instantiation declaration
>   template void g<0>();
>^

So, confirmed that the errors could be improved.

[Bug c++/50169] "new struct X {{}};" incorrectly treated as an invalid struct-definition

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-18
 CC||jason at redhat dot com
 Ever confirmed|0   |1

--- Comment #5 from Ville Voutilainen  ---
This is DR 2141:
http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#2141

The original code is supposed to be valid, so confirming this as an actual bug.

[Bug libstdc++/81891] [5/6/7/8 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Aug 18 17:46:57 2017
New Revision: 251185

URL: https://gcc.gnu.org/viewcvs?rev=251185&root=gcc&view=rev
Log:
PR libstdc++/81891 fix double-free in hashtable constructor

PR libstdc++/81891
* include/bits/hashtable.h (_Hashtable(_InputIterator, _InputIterator,
size_type, const _H1&, const _H2&, const _Hash&, const _Equal&,
const _ExtractKey&, const allocator_type&)): Let destructor do clean
up if an exception is thrown.
* testsuite/23_containers/unordered_map/cons/81891.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/cons/81891.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h

[Bug preprocessor/81794] "would be stringified in traditional C" warning should be controlled by -Wtraditional

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Please can you turn it into a patch that contains both the fix *and* the new
testcase?  (e.g. gcc.dg/pragma-diag-8.c)

[Bug libstdc++/81891] [5/6/7 Regression] heap-use-after-free if inserting element in std::unordered_map(InputIt, InputIt) throws

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.0
   Target Milestone|--- |5.5
Summary|[5/6/7/8 Regression]|[5/6/7 Regression]
   |heap-use-after-free if  |heap-use-after-free if
   |inserting element in|inserting element in
   |std::unordered_map(InputIt, |std::unordered_map(InputIt,
   |InputIt) throws |InputIt) throws
  Known to fail|8.0 |

--- Comment #5 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug fortran/81827] Large compile time with derived-type rrays

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |pault at gcc dot gnu.org

--- Comment #8 from Paul Thomas  ---
I have taken a brief look at this but have to postpone completion of a fix for
a couple of weeks because I will be on vacation.

Index: ../trunk/gcc/fortran/trans-expr.c
===
*** ../trunk/gcc/fortran/trans-expr.c   (revision 250712)
--- ../trunk/gcc/fortran/trans-expr.c   (working copy)
*** gfc_trans_assignment_1 (gfc_expr * expr1
*** 10075,10083 
  }
else
  tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
!  gfc_expr_is_variable (expr2)
   || scalar_to_array
!  || expr2->expr_type == EXPR_ARRAY,
   !(l_is_temp || init_flag) && dealloc,
   expr1->symtree->n.sym->attr.codimension);
/* Add the pre blocks to the body.  */
--- 10075,10086 
  }
else
  tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
!  !(init_flag
!&& flag_coarray != GFC_FCOARRAY_LIB
!&& expr2->expr_type == EXPR_STRUCTURE)
!  && (gfc_expr_is_variable (expr2)
   || scalar_to_array
!  || expr2->expr_type == EXPR_ARRAY),
   !(l_is_temp || init_flag) && dealloc,
   expr1->symtree->n.sym->attr.codimension);
/* Add the pre blocks to the body.  */

apart from a few regressions associated with tree dump counts of malloc.

The blanket exclusion of GFC_COARRAY_LIB is clearly not right or if it is,
I have not yet understood why.

I think that the problem lies in the default initializer for these derived
types. The suppression of the deep copy that the above patch provides can only
be necessary because the field in the initializer for the allocatable
components is not a null expression, as it should be. Otherwise, the deep copy
would stop dead in its tracks at the first level.

I have taken the bug.

Paul

[Bug c++/81514] g++.dg/lookup/missing-std-include-2.C FAILs on Solaris

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Fri Aug 18 18:12:47 2017
New Revision: 251186

URL: https://gcc.gnu.org/viewcvs?rev=251186&root=gcc&view=rev
Log:
C++: fix ordering of missing std #include suggestion (PR c++/81514)

gcc/cp/ChangeLog:
PR c++/81514
* name-lookup.c (maybe_suggest_missing_header): Convert return
type from void to bool; return true iff a suggestion was offered.
(suggest_alternative_in_explicit_scope): Move call to
maybe_suggest_missing_header to before use of best_match, and
return true if the former offers a suggestion.

gcc/testsuite/ChangeLog:
PR c++/81514
* g++.dg/lookup/empty.h: New file.
* g++.dg/lookup/missing-std-include-2.C: Replace include of
stdio.h with empty.h and a declaration of a "std::sprintf" not based
on a built-in.


Added:
trunk/gcc/testsuite/g++.dg/lookup/empty.h
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lookup/missing-std-include-2.C

[Bug c++/81514] g++.dg/lookup/missing-std-include-2.C FAILs on Solaris

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by r251186.

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #9 from Jerry DeLisle  ---
(In reply to Eric Gallager from comment #8)
> Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01290.html which was lost:
> 
> --- Comment #8 from neil.n.carlson at gmail dot com ---
> Ping.  Is there any interest in fixing this regression?

Yes, anything that is a failure on valid code we want to fix. We are simply
very short handed. What is the pain level on this one?

[Bug fortran/69834] [OOP] Collision in derived type hashes

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||jvdelisle at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #15 from Jerry DeLisle  ---
(In reply to Jakub Jelinek from comment #14)
> GCC 7.1 has been released.

This is already in 7. I see no need for 6.

[Bug go/81893] [8 regression] compilation error in libgo starting with r251127

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Yes, it compiles OK on LE.

Note that I saw the errors on both power7 and power8 BE systems and using
different versions of gcc to build.

[Bug tree-optimization/81488] [8 Regression] gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Patch submitted:  https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01145.html