[Bug c++/81855] [mingw-w64] dllexport-ed explicit template instantiation has no symbol in DLL when the compile unit has non-template symbol

[lanxingcan at gmail dot com]

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

--- Comment #1 from Xingcan Lan  ---
Update: 
Even if I seperate the them into two compile unit. and link them into one DLL
together, symbols for `Template` is also missing.
So maybe it's a bug of binutils?

[Bug c++/81855] New: [mingw-w64] dllexport-ed explicit template instantiation has no symbol in DLL when the compile unit has non-template symbol

[lanxingcan at gmail dot com]

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

Bug ID: 81855
   Summary: [mingw-w64] dllexport-ed explicit template
instantiation has no symbol in DLL when the compile
unit has non-template symbol
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lanxingcan at gmail dot com
  Target Milestone: ---

I'm cross building a library for Windows, but encounterd an issue about
dllexport and explicit template instantiation.

I tested with MinGW-W64 GCC/7.1.0 cross compiler on either macOS serria (from
homebrew/core/mingw-w64) as well as Fedora 26 (from stock repository).

Here is a small reproducible.

test.cpp:
```cpp

template
struct __declspec(dllexport) Template
{
~Template() noexcept(false) { throw 1; }
};

extern template struct __declspec(dllexport) Template;
template struct Template;

#ifdef WITH_NON_TEMPLATE

struct __declspec(dllexport) NonTemplate
{
~NonTemplate();
};

NonTemplate::~NonTemplate() = default;
#endif

```

Compiles with:
x86_64-w64-mingw32-g++ test.cpp -shared -o libtest1.dll
-Wl,--out-implib,libtest1.dll.a
x86_64-w64-mingw32-g++ test.cpp -DWITH_NON_TEMPLATE -shared -o libtest2.dll
-Wl,--out-implib,libtest2.dll.a

Check exported symbol in libtest1.dll : 
```
$ x86_64-w64-mingw32-objdump -d libtest1.dll.a | x86_64-w64-mingw32-c++filt
In archive libtest1.dll.a:

d05.o: file format pe-x86-64


d02.o: file format pe-x86-64


d04.o: file format pe-x86-64


Disassembly of section .text:

 :
   0:   ff 25 00 00 00 00   jmpq   *0x0(%rip)# 6

   6:   90  nop
   7:   90  nop

d03.o: file format pe-x86-64


Disassembly of section .text:

 :
   0:   ff 25 00 00 00 00   jmpq   *0x0(%rip)# 6

   6:   90  nop
   7:   90  nop
```

Check exported symbol in libtest2.dll:
```
$ x86_64-w64-mingw32-objdump -d libtest2.dll.a | x86_64-w64-mingw32-c++filt 
In archive libtest2.dll.a:

d05.o: file format pe-x86-64


d02.o: file format pe-x86-64


d04.o: file format pe-x86-64


Disassembly of section .text:

 :
   0:   ff 25 00 00 00 00   jmpq   *0x0(%rip)# 6

   6:   90  nop
   7:   90  nop

d03.o: file format pe-x86-64


Disassembly of section .text:

 :
   0:   ff 25 00 00 00 00   jmpq   *0x0(%rip)# 6

   6:   90  nop
   7:   90  nop
```

the symbols for `Template` is anyway missing in libtest2.dll. 

I'm confusing its behavior and believe it's a bug.

[Bug target/78460] [7/8 Regression] [SH] OOM building glibc string tst-cmp.c

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.2 |7.3

--- Comment #8 from Joseph S. Myers  ---
Fixed for GCC 7.3 and GCC 8.

[Bug target/67712] [SH] __builtin_strncmp causes code bloat

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
The patch committed limits the unrolling, but not necessarily as much as
desirable (given the bug is about an 8-byte case and the limit is 32 bytes).

[Bug target/67712] [SH] __builtin_strncmp causes code bloat

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
The patch committed limits the unrolling, but not necessarily as much as
desirable (given the bug is about an 8-byte case and the limit is 32 bytes).

[Bug target/67712] [SH] __builtin_strncmp causes code bloat

[jsm28 at gcc dot gnu.org]

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

--- Comment #2 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Aug 15 23:43:11 2017
New Revision: 251109

URL: https://gcc.gnu.org/viewcvs?rev=251109=gcc=rev
Log:
Limit SH strncmp inline expansion (PR target/78460).

GCC mainline built for sh4-linux-gnu runs out of memory building a
glibc test, which calls strncmp with very large constant size
argument, resulting in the SH inline strncmp expansion trying to
inline a fully unrolled expansion of strncmp for that size.

This patch limits that fully unrolled expansion to the case of less
than 32 bytes.  This is explicitly *not* trying to be optimal in any
way (very likely a lower threshold makes sense), just to limit enough
to avoid the out-of-memory issue in the glibc testsuite.

I have *not* run the GCC testsuite for SH.  I have verified that this
allows the glibc testsuite to build OK, with both GCC mainline and GCC
7 branch (and that the included test builds quickly with patched GCC,
runs out of memory with unpatched GCC).

PR target/78460
PR target/67712
gcc:
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Only unroll for
constant count if that count is less than 32.

gcc/testsuite:
* gcc.c-torture/compile/string-large-1.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/compile/string-large-1.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sh/sh-mem.cc
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/78460] [7/8 Regression] [SH] OOM building glibc string tst-cmp.c

[jsm28 at gcc dot gnu.org]

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

--- Comment #7 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Aug 15 23:43:11 2017
New Revision: 251109

URL: https://gcc.gnu.org/viewcvs?rev=251109=gcc=rev
Log:
Limit SH strncmp inline expansion (PR target/78460).

GCC mainline built for sh4-linux-gnu runs out of memory building a
glibc test, which calls strncmp with very large constant size
argument, resulting in the SH inline strncmp expansion trying to
inline a fully unrolled expansion of strncmp for that size.

This patch limits that fully unrolled expansion to the case of less
than 32 bytes.  This is explicitly *not* trying to be optimal in any
way (very likely a lower threshold makes sense), just to limit enough
to avoid the out-of-memory issue in the glibc testsuite.

I have *not* run the GCC testsuite for SH.  I have verified that this
allows the glibc testsuite to build OK, with both GCC mainline and GCC
7 branch (and that the included test builds quickly with patched GCC,
runs out of memory with unpatched GCC).

PR target/78460
PR target/67712
gcc:
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Only unroll for
constant count if that count is less than 32.

gcc/testsuite:
* gcc.c-torture/compile/string-large-1.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/compile/string-large-1.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sh/sh-mem.cc
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/78460] [7/8 Regression] [SH] OOM building glibc string tst-cmp.c

[jsm28 at gcc dot gnu.org]

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

--- Comment #6 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Aug 15 23:42:23 2017
New Revision: 251108

URL: https://gcc.gnu.org/viewcvs?rev=251108=gcc=rev
Log:
Limit SH strncmp inline expansion (PR target/78460).

GCC mainline built for sh4-linux-gnu runs out of memory building a
glibc test, which calls strncmp with very large constant size
argument, resulting in the SH inline strncmp expansion trying to
inline a fully unrolled expansion of strncmp for that size.

This patch limits that fully unrolled expansion to the case of less
than 32 bytes.  This is explicitly *not* trying to be optimal in any
way (very likely a lower threshold makes sense), just to limit enough
to avoid the out-of-memory issue in the glibc testsuite.

I have *not* run the GCC testsuite for SH.  I have verified that this
allows the glibc testsuite to build OK, with both GCC mainline and GCC
7 branch (and that the included test builds quickly with patched GCC,
runs out of memory with unpatched GCC).

PR target/78460
PR target/67712
gcc:
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Only unroll for
constant count if that count is less than 32.

gcc/testsuite:
* gcc.c-torture/compile/string-large-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/string-large-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-mem.cc
trunk/gcc/testsuite/ChangeLog

[Bug target/67712] [SH] __builtin_strncmp causes code bloat

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Aug 15 23:42:23 2017
New Revision: 251108

URL: https://gcc.gnu.org/viewcvs?rev=251108=gcc=rev
Log:
Limit SH strncmp inline expansion (PR target/78460).

GCC mainline built for sh4-linux-gnu runs out of memory building a
glibc test, which calls strncmp with very large constant size
argument, resulting in the SH inline strncmp expansion trying to
inline a fully unrolled expansion of strncmp for that size.

This patch limits that fully unrolled expansion to the case of less
than 32 bytes.  This is explicitly *not* trying to be optimal in any
way (very likely a lower threshold makes sense), just to limit enough
to avoid the out-of-memory issue in the glibc testsuite.

I have *not* run the GCC testsuite for SH.  I have verified that this
allows the glibc testsuite to build OK, with both GCC mainline and GCC
7 branch (and that the included test builds quickly with patched GCC,
runs out of memory with unpatched GCC).

PR target/78460
PR target/67712
gcc:
* config/sh/sh-mem.cc (sh_expand_cmpnstr): Only unroll for
constant count if that count is less than 32.

gcc/testsuite:
* gcc.c-torture/compile/string-large-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/string-large-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh-mem.cc
trunk/gcc/testsuite/ChangeLog

[Bug c/81824] Warn for missing attributes with function aliases

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
The challenge here is that the alias target may not be in scope at the point of
the alias declaration, so while the test case in comment #0 could be detected
by enhancing the handle_alias_attribute function in c-family/c-attribs.c, one
where the declaration order is reversed as in the following could not be:

  void foo (void) __attribute__ ((nothrow, weak, alias ("__foo")));
  void __foo (void) { }

Bug 81854 suggests that there is a way to detect this in handle_alias_pairs()
in cgraphunit.c.

[Bug c/81854] weak alias of an incompatible symbol accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Martin Sebor  ---
The following (otherwise untested) patch detects the problem in the test case.

diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 6072c56..635170a 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1350,11 +1350,24 @@ handle_alias_pairs (void)
   if (TREE_CODE (p->decl) == FUNCTION_DECL
   && target_node && is_a  (target_node))
{
- cgraph_node *src_node = cgraph_node::get (p->decl);
- if (src_node && src_node->definition)
-   src_node->reset ();
- cgraph_node::create_alias (p->decl, target_node->decl);
- alias_pairs->unordered_remove (i);
+ tree t1 = TREE_TYPE (p->decl);
+ tree t2 = TREE_TYPE (target_node->decl);
+ if (!gimple_canonical_types_compatible_p (t1, t2, false))
+   {
+ error ("%q+D alias between functions of incompatible types",
+p->decl);
+ warning (0, "%q+D aliased declaration",
+  target_node->decl);
+ alias_pairs->unordered_remove (i);
+   }
+ else
+   {
+ cgraph_node *src_node = cgraph_node::get (p->decl);
+ if (src_node && src_node->definition)
+   src_node->reset ();
+ cgraph_node::create_alias (p->decl, target_node->decl);
+ alias_pairs->unordered_remove (i);
+   }
}
   else if (VAR_P (p->decl)
   && target_node && is_a  (target_node))

[Bug c/81854] New: weak alias of an incompatible symbol accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 81854
   Summary: weak alias of an incompatible symbol accepted
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC helpfully rejects function declarations that alias a variable but fails to
complain about similarly incorrect declarations that alias functions with an
incompatible type.

$ cat b.c && gcc -O2 -Wall -Wextra -Wpedantic b.c
const char* __attribute__ ((weak, alias ("foo")))
bar (void);   // error (good)

int foo;

const char* __attribute__ ((weak, alias ("foobar")))
baz (void);   // accepted (bad)

void foobar (int *p) { *p = 0; }
b.c:2:1: error: ‘bar’ alias in between function and variable is not supported
 bar (void);   // error (good)
 ^~~
b.c:4:5: warning: ‘foo’ aliased declaration
 int foo;
 ^~~

[Bug target/78459] [7/8 Regression] [SH] ICE in maybe_record_trace_start building glibc string tests

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers  ---
At some point this ICE disappeared, both on mainline and GCC 7 branch.  I
haven't bisected to see when it disappeared (quite possibly before the
branchpoint).

[Bug c/81851] missing -Wduplicated-branches on if and return statements with no else

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Definitely not a bug, I never intended that the warning detects the latter
case.  And it's not an easy enhancement, either.

[Bug c++/81853] New: [C++14] "using namespace" is not a constant expression in function-like macro

[t.poechtrager at gmail dot com]

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

Bug ID: 81853
   Summary: [C++14] "using namespace" is not a constant expression
in function-like macro
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.poechtrager at gmail dot com
  Target Milestone: ---

$ g++ --version
g++ (GCC) 7.1.1 20170630
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.

---

$ cat test.cpp 

namespace test {
constexpr int test_fun() { return 42; }
}

#define test_macro() \
({ \
using namespace test; \
test_fun(); \
})

int main()
{
constexpr int test_var = test_macro();
return test_var;
}

---

$ g++ test.cpp 
test.cpp: In function ‘int main()’:
test.cpp:8:19: error: statement is not a constant expression
   using namespace test; \
   ^
test.cpp:14:30: note: in expansion of macro ‘test_macro’
 constexpr int test_var = test_macro();
  ^~

---

Clang accepts this since 3.4:

$ clang++ test.cpp -std=c++14 && ./a.out ; echo $?
42

[Bug c++/81852] New: Feature request: __cpp_threadsafe_static_init

[daniel.kruegler at googlemail dot com]

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

Bug ID: 81852
   Summary: Feature request: __cpp_threadsafe_static_init
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com
  Target Milestone: ---

Since the recent update of "Feature-testing recommendations for C++",

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r4.html#recs.cpp11

the feature macro "__cpp_threadsafe_static_init" has been recommended for C++
language level c++11 on. This is extremely useful to have for code that has to
program defensively against the possibility that thread-safe static locale
initialization has been deactivated (via -fno-threadsafe-statics). With that
feature macro available, portable code can be written that always provides a
thread-safe static initialization, for example by means of std::call_once as
the following excerpt demonstrates:

Thingy& get_thing()
{
#ifndef __cpp_threadsafe_static_init
[...]
static std::once_flag flag;
std::call_once(flag, init::get);
return init::get();
#else
static Thingy result;
return result;
#endif
}

Current clang HEAD 6.0.0 (https://github.com/llvm-mirror/clang.git 43) has
already provided support for this.

A test-case would be that given the compiler flags

$ g++ prog.cc -Wall -Wextra -std=c++11 -pedantic 

the following would be well-formed:

//<
#ifndef __cpp_threadsafe_static_init
# error "__cpp_threadsafe_static_init not defined"
#endif

int main() 
{
}
//<

while given the compiler flags

$ g++ prog.cc -Wall -Wextra -std=c++11 -pedantic "-fno-threadsafe-statics"

the same code should be ill-formed:

prog.cc:2:3: error: #error "__cpp_threadsafe_static_init not defined"
 # error "__cpp_threadsafe_static_init not defined"
   ^

[Bug c/81851] New: missing -Wduplicated-branches on if and return statements with no else

[msebor at gcc dot gnu.org]

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

Bug ID: 81851
   Summary: missing -Wduplicated-branches on if and return
statements with no else
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wduplicated-branches warning triggers when the true statement and the
false statement in an if statement are the same, including when both are a
return statement.  But the warning doesn't trigger for the equivalent code with
the else statement, even though it's very common to leave out the else part
when the block controlled by the if statement ends in a return.

This could be viewed more as an enhancement request than a bug since the
documentation doesn't suggest a warning in the latter case should be expected,
but since such code is pervasive I'd be more inclined to see it as a bug. 
Either way, handling this case would make the warning obviously even more
useful than it already is.

$ cat b.c && gcc -O2 -S -Wduplicated-branches b.c
int f (int i)
{
  if (i == 0)   // -Wduplicated-branches (good)
return 0;
  else
return 0;
}

int g (int i)
{
  if (i == 0)   // no warning
return 0;
  return 0;
}

b.c: In function ‘f’:
b.c:3:6: warning: this condition has identical branches [-Wduplicated-branches]
   if (i == 0)   // -Wduplicated-branches (good)
  ^

[Bug web/81846] ViewVC Exception

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
All the missing or corrupted revprops files from last night's filesystem
problems have now been restored from backup.

[Bug target/81643] FAIL: gcc.target/aarch64/long_branch_1.c scan-assembler Ltb

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||wilco at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Wilco  ---
Fixed

[Bug c++/67650] undef reference with -fdevirtualize

[vincent.lextrait at gmail dot com]

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

--- Comment #16 from Vincent  ---
Still there in 7.2.0.

[Bug lto/81847] ICE with LTO enabled

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Valentine from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Try -flto-partition=one which might allow this to be reduced further.
> 
> Thanks, just tried -flto-partition=one, still the same ICE. Other
> -flto-partition options didn't help either, the only thing that fixes this
> ICE for me is the "none" option.

Right, the whole point of my saying:
>Try -flto-partition=one which might allow this to be reduced further.

Was that the deterministic of the ICE becomes very deterministic now and that
even adding another .cpp file, it will still crash :).

See https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs
for other tricks of reducing the testcase to something which you can provide.

[Bug lto/81847] ICE with LTO enabled

[v at vsamko dot com]

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

--- Comment #2 from Valentine  ---
(In reply to Andrew Pinski from comment #1)
> Try -flto-partition=one which might allow this to be reduced further.

Thanks, just tried -flto-partition=one, still the same ICE. Other
-flto-partition options didn't help either, the only thing that fixes this ICE
for me is the "none" option.

[Bug lto/81847] ICE with LTO enabled

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Try -flto-partition=one which might allow this to be reduced further.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Tue, 15 Aug 2017, Martin Sebor wrote:

> On 08/15/2017 10:27 AM, Joseph Myers wrote:
> > On Tue, 15 Aug 2017, Martin Sebor wrote:
> > 
> > > It looks like the data loss extends beyond 8/14.  Bug 81840
> > > was created Sunday afternoon but is not in the database:
> > > 
> > >   https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html
> > > 
> > > (Strangely, 81841 is there, as is 81839.)
> > 
> > That's another 81839 replacing the original 81839.  As I noted on
> > overseers, the cut-off for GCC Bugzilla appears to be between
> >  and
> > , early Sunday
> > morning UTC (and for sourceware Bugzilla it may well be similar).
> 
> Thanks for the update.  Can I subscribe to this list?

I believe it's open subscription.

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

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Martin Sebor]

On 08/15/2017 10:27 AM, Joseph Myers wrote:

On Tue, 15 Aug 2017, Martin Sebor wrote:


It looks like the data loss extends beyond 8/14.  Bug 81840
was created Sunday afternoon but is not in the database:

  https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html

(Strangely, 81841 is there, as is 81839.)


That's another 81839 replacing the original 81839.  As I noted on
overseers, the cut-off for GCC Bugzilla appears to be between
 and
, early Sunday
morning UTC (and for sourceware Bugzilla it may well be similar).


Thanks for the update.  Can I subscribe to this list?

(It might be helpful to post an announcement of what's going on
here for those of us who aren't subscribed to the overseers list
or even are aware of its archives.)

Martin

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Tue, 15 Aug 2017, Martin Sebor wrote:

> It looks like the data loss extends beyond 8/14.  Bug 81840
> was created Sunday afternoon but is not in the database:
> 
>   https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html
> 
> (Strangely, 81841 is there, as is 81839.)

That's another 81839 replacing the original 81839.  As I noted on 
overseers, the cut-off for GCC Bugzilla appears to be between 
 and 
, early Sunday 
morning UTC (and for sourceware Bugzilla it may well be similar).

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

[Bug target/79912] [7/8 regression] LRA unable to generate reloads after r245655

[palmer at dabbelt dot com]

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

Palmer Dabbelt  changed:

   What|Removed |Added

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

--- Comment #21 from Palmer Dabbelt  ---
(In reply to mpf from comment #20)
> Palmer: There is a commit listed for this bug, did that fix the issue and
> can the bug be marked fixed?

The actual regression is fixed but there's some cleanup left to do.  I guess I
was hoping to get to it 6 month ago but I didn't.  I'm going to mark this as
"RESOLVED FIXED" (I'm new to Bugzilla, so sorry if that's the wrong way to do
it), we'll just try to remember to clean it up eventually.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Martin Sebor]

On 08/15/2017 07:27 AM, Jonathan Wakely wrote:

On 15 August 2017 at 04:10, Martin Sebor wrote:

On 08/14/2017 04:22 PM, Eric Gallager wrote:


I'm emailing this manually to the list because Bugzilla is down and I
can't file a bug on Bugzilla about Bugzilla being down. The error
message looks like this:



Even if it were possible, there wouldn't be any point in filing a bug
that bugzilla's down, and so not much point emailing gcc-bugs either
(since that's for bugzilla mail).  Using gcc@ seems like the right
list to me.

N.B. since the server is being restored from a backup all of
yesterday's changes to bugzilla have been lost, including all Richi's
7.2 release changes, and Eric's housekeeping.

I don't suggest redoing all that work until all services are fully
restored, in case it's lost again.


It looks like the data loss extends beyond 8/14.  Bug 81840
was created Sunday afternoon but is not in the database:

  https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html

(Strangely, 81841 is there, as is 81839.)

Is there a plan to restore the lost data somehow or should
we try to do that ourselves for the bugs we know about?

Martin

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Szabolcs Nagy]

On 15/08/17 04:10, Martin Sebor wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:
> 
> Bugzilla and the rest of gcc.gnu.org have been down much of
> the afternoon/evening due to a hard drive upgrade (the old disk
> apparently failed).  You're not the only one who found out about
> it the hard way.  I (and I suspect most others) also discovered
> it when things like Git and SVN (and Bugzilla) stopped working.
> 
> I've CC'd the gcc list to let others know (not sure what list
> to subscribe to in order to get a heads up on these kinds of
> maintenance issues).
> 

i seems the database got corrupted.

at least one of my bugs was overwritten by another:

original 81846:
https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01574.html
current 81846:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81846

similarly there are two bugs on the bug mailing list
for 81845 and later bugs are missing.

[Bug target/81652] [meta-bug] -finstrument-control-flow -mcet bugs

[hjl.tools at gmail dot com]

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

Bug 81844 Summary: -finstrument-control-flow -mcet is incompatible with 
makecontext family functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81844

   What|Removed |Added

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

[Bug tree-optimization/81811] missing -Wreturn-local-addr returning strcpy result

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
(In reply to Richard Biener from comment #2)
> Wonder whether the memcpy case is because we fold the memcpy away as both
> memcpy and strcpy are marked RET1 (returns arg1).

The memcpy is eliminated in DSE and turned into a plain 'return a' statement
that  the find_explicit_erroneous_behavior() in tree-ssa-isolate-paths.c that
implements the warning knows how to handle.

DSE doesn't handle strcpy or strncpy so the calls are not eliminated and
because find_explicit_erroneous_behavior() doesn't handle calls, the 'return
strcpy(a, s)' statement isn't detected.

This suggests an opportunity to improve not just the warning but also DSE.

[Bug tree-optimization/38592] Optimize memmove / memcmp combination

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81703

--- Comment #9 from Martin Sebor  ---
The optimization should be easily doable in tree-ssa-strlen.c.  What makes it
less than straightforward is that gimple-fold.c folds constant size
memcpy/memmove into a MEM_REF which the strlen pass doesn't know how to handle.
 I think the best way is to defer the folding until after the strlen pass has
run.  That will not only make the optimization easily implementable but also
make it possible to detect past the end reads/writes in calls to the functions
because only the strlen pass knows the sizes of the source sequences.  (Bug
81703 tracks another instance of missing strlen optimization due to early
folding.  As an aside, deferring the folding is complementary to handling
MEM_REF in the strlen pass.)

[Bug target/81820] -Os may remove debug info

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Fixed by

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ac36c55f2dac2b54a657d242646d84dfd522eb55

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[urbanjost at comcast dot net]

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

--- Comment #34 from urbanjost at comcast dot net ---
It still occurs with Cygwin 2.8.2, which comes with gfortran 5.4.0, which is
the latest version of CygWin, if that is of any help.

-Original Message-
From: dominiq at lps dot ens.fr [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Sunday, August 13, 2017 6:00 AM
To: urbanj...@comcast.net
Subject: [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not
loading from library

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

--- Comment #34 from Dominique d'Humieres  ---
> So... what should we do with this bug then? I'm trying to move it out 
> of the WAITING queue. Change to SUSPENDED?

I am afraid that SUSPENDED is some kind of black hole for problems waiting
committee clarification. Here we are still waiting an answer from CygWin users
if it is still present with recent releases.

--
You are receiving this mail because:
You reported the bug.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Jonathan Wakely]

On 15 August 2017 at 04:10, Martin Sebor wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>>
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:


Even if it were possible, there wouldn't be any point in filing a bug
that bugzilla's down, and so not much point emailing gcc-bugs either
(since that's for bugzilla mail).  Using gcc@ seems like the right
list to me.

N.B. since the server is being restored from a backup all of
yesterday's changes to bugzilla have been lost, including all Richi's
7.2 release changes, and Eric's housekeeping.

I don't suggest redoing all that work until all services are fully
restored, in case it's lost again.

[Bug c++/46634] cp/typeck2.c: uses BITS_PER_UNIT in lieu of TYPE_PRECISION (char_type_node)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
(In reply to Jorn Wolfgang Rennecke from comment #0)
> 

Um... bug report missing? Would help to have something more than the title...

[Bug c++/81839] Internal compiler error (cp/typeck2.c:1264)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Guessing you probably got gateway errors when submitting to Bugzilla or
something?

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

[Bug c++/81837] Internal compiler error (cp/typeck2.c:1264)

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
*** Bug 81839 has been marked as a duplicate of this bug. ***

[Bug c++/81837] Internal compiler error (cp/typeck2.c:1264)

[egallager at gcc dot gnu.org]

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

--- Comment #1 from Eric Gallager  ---
*** Bug 81838 has been marked as a duplicate of this bug. ***

[Bug c++/81838] Internal compiler error (cp/typeck2.c:1264)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

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

[Bug c++/45963] inconsistent and poor array initialization diagnostic

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
g++'s message is now:

$ /usr/local/bin/g++ -c 45963.cc
45963.cc: In constructor ‘bar::bar()’:
45963.cc:9:13: error: incompatible types in assignment of ‘int’ to ‘int [5]’
  bar() : a(1) {}
 ^
45963.cc: In constructor ‘bar::bar(bool)’:
45963.cc:10:17: error: invalid initializer for array member ‘foo bar::b [5]’
  bar(bool) : b(1) {}
 ^
$

Which I guess is kinda better than before, but looking at the Comeau output you
posted, g++ could still probably add a fixit hint or something, so confirmed.

[Bug target/79912] [7/8 regression] LRA unable to generate reloads after r245655

[mpf at gcc dot gnu.org]

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

--- Comment #20 from mpf at gcc dot gnu.org ---
Palmer: There is a commit listed for this bug, did that fix the issue and can
the bug be marked fixed?

[Bug fortran/44350] accepts illegal fortran in BLOCK DATA

[dibr-bugzilla at daswigwam dot de]

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

dbroemmel  changed:

   What|Removed |Added

 CC||dibr-bugzilla at daswigwam dot 
de

--- Comment #9 from dbroemmel  ---
Please have a look at Bug 81841 which seems to be related to this fix.

[Bug tree-optimization/38592] Optimize memmove / memcmp combination

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2009-02-19 05:44:12 |2017-8-15
  Component|fortran |tree-optimization
Summary|eliminate some string   |Optimize memmove / memcmp
   |comparisons |combination

--- Comment #8 from Thomas Koenig  ---
I think the best place to fix this is in the middle-end.

Here is a C test case:

int yes()
{
  char a[3];
  __builtin_memmove (a, "yes", 3);
return __builtin_memcmp(a,"yes",3);
}

This generates a memcmp with current trunk:

.LC0:
.string "yes"
.text
.p2align 4,,15
.globl  yes
.type   yes, @function
yes:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl$25977, %eax
movl$3, %edx
leaq13(%rsp), %rdi
movl$.LC0, %esi
movw%ax, 13(%rsp)
movb$115, 15(%rsp)
callmemcmp
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   yes, .-yes
.ident  "GCC: (GNU) 8.0.0 20170730 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/81815] Invalid conditional reduction

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
The branch looks affected as well.

[Bug tree-optimization/81790] [8 Regression] ICE in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1738

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
FIxed.

[Bug tree-optimization/81790] [8 Regression] ICE in vn_nary_build_or_lookup_1, at tree-ssa-sccvn.c:1738

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 15 11:26:32 2017
New Revision: 251103

URL: https://gcc.gnu.org/viewcvs?rev=251103=gcc=rev
Log:
2017-08-15  Richard Biener  

PR tree-optimization/81790
* tree-ssa-sccvn.c (vn_lookup_simplify_result): Handle both
CONSTRUCTORs from simplifying and VN.

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

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

[Bug tree-optimization/81814] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Yes, it's in operand_equal_for_comparison_p, and that would also explain why it
started with r125012.  I didn't update the BZ when I found this out.  I hope to
look into this more this week.

[Bug c/81389] _mm_cmpestri segfault on -O0

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to rockeet from comment #11)
> @H.J. Lu
> 
> Have you tried your `solution`?
> 
> `_mm_cmpestri` is a C function and have no overloaded with type `__m128i_u`.

[hjl@gnu-tools-1 pr81389]$ cat y.c
#include 
#include 

int main(int argc, char* argv[]) {
__m128i key128 = { ':' };
const char data[] = "___0123456789:_:abcdefghijklmn";
const char* ptr = argc < 100 ? data : argv[1];
int idx = _mm_cmpestri(key128, 1,
*(const __m128i_u*)(ptr+3), 16, // don't require memory
align
   
_SIDD_UBYTE_OPS|_SIDD_CMP_EQUAL_ORDERED|_SIDD_LEAST_SIGNIFICANT);
printf("%zd\n", idx);
return 0;
}
[hjl@gnu-tools-1 pr81389]$ gcc -O0 -msse4 y.c
[hjl@gnu-tools-1 pr81389]$ ./a.out 
10
[hjl@gnu-tools-1 pr81389]$

[Bug tree-optimization/81811] missing -Wreturn-local-addr returning strcpy result

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Wonder whether the memcpy case is because we fold the memcpy away as both
memcpy and strcpy are marked RET1 (returns arg1).

[Bug tree-optimization/81810] unused strcpy to a local buffer not eliminated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-15
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/81814] Incorrect behaviour at -O0 (conditional operator)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-15
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
The folding obviously preserves precision changing casts, so it should be
valid.  Things must go wrong elsewhere, possibly in
operand_equal_for_comparison_p which ends up using get_narrower.

[Bug target/81813] Inefficient stack pointer adjustment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu |x86_64-*-*

--- Comment #1 from Richard Biener  ---
Interesting ;)  A peephole might help.

[Bug middle-end/81812] [7/8 Regression] Empty virtual function fails to compile

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||rguenth at gcc dot gnu.org
  Component|c++ |middle-end
   Target Milestone|--- |7.2

[Bug testsuite/81807] [8 Regression] many *.cc asan tests fail

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|many *.cc asan tests fail   |[8 Regression] many *.cc
   ||asan tests fail

[Bug c++/81837] New: Internal compiler error (cp/typeck2.c:1264)

[victor.sunye at upc dot edu]

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

Bug ID: 81837
   Summary: Internal compiler error (cp/typeck2.c:1264)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.sunye at upc dot edu
  Target Milestone: ---

template 
union Unit
{
  struct
  {
inT a, b;
  } header;
  double align;
};



int
main (void)
{
  Unit  *chunk;

  chunk = new Unit  [10] {.align = 0};
  delete [] chunk;
  return 0;
}

==> compiled with "g++ -std=c++14 -g -Wall -Wextra -o compiler_bug
compiler_bug.cpp" gives:

compiler_bug.cpp:18:42: internal compiler error: in
process_init_constructor_array, at cp/typeck2.c:1264
   chunk = new Unit  [10] {.align = 0};
  ^
==> g++ version: g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

[Bug target/81389] _mm_cmpestri segfault on -O0

[rockeet at gmail dot com]

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

rockeet  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #11 from rockeet  ---
@H.J. Lu

Have you tried your `solution`?

`_mm_cmpestri` is a C function and have no overloaded with type `__m128i_u`.