[Bug c/84531] c/c++: bogus warning for functions with different argument lengths but compatible arguments

[siddhesh at gotplt dot org]

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

--- Comment #5 from Siddhesh Poyarekar  ---
Yeah that doesn't look good.  I had not done a cpython build; I had started
with a gem5 build (which builds python modules) and only superficially looked
at cpython.

I thought about this over the weekend and agree that silencing the warning will
only hold us back indefinitely.  I'll look at the cpython build a bit closer
and try to fix it there when I have time for it.  Thanks for looking into this.

[Bug c++/81589] Possible False-Positive with decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill  ---
(In reply to Martin Liška from comment #3)
> I see the same problem (reduced from Chromium package):

Fixed.  I suspect that this doesn't address the original issue because it
mentions GCC 8 failing as well.  To address that we'll need a testcase that
fails with GCC 8.

[Bug c++/84015] [7 Regression] ICE with class template argument deduction

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/84015] [7 Regression] ICE with class template argument deduction

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Feb 26 06:09:01 2018
New Revision: 257980

URL: https://gcc.gnu.org/viewcvs?rev=257980=gcc=rev
Log:
PR c++/84015 - ICE with class deduction and auto template parm.

* pt.c (rewrite_template_parm): Use tf_partial in first tsubst.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/class-deduction49.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/81589] Possible False-Positive with decltype

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Feb 26 06:09:07 2018
New Revision: 257981

URL: https://gcc.gnu.org/viewcvs?rev=257981=gcc=rev
Log:
PR c++/81589 - error with is_trivially_constructible.

* method.c (constructible_expr): Set cp_unevaluated.

Added:
   
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/is_trivially_constructible6.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/method.c

[Bug target/70490] __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning

[nruslan_devel at yahoo dot com]

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

Ruslan Nikolaev  changed:

   What|Removed |Added

 CC||nruslan_devel at yahoo dot com

--- Comment #6 from Ruslan Nikolaev  ---
See also Bug 84563

[Bug c++/84461] [8 regression] openjdk-10 fails to build

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
(In reply to Andreas Schwab from comment #2)
> Created attachment 43467 [details]

I can't reproduce the failure with this testcase.

[Bug c/84563] New: GCC interpretation of C11 atomics (DR 459)

[nruslan_devel at yahoo dot com]

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

Bug ID: 84563
   Summary: GCC interpretation of C11 atomics (DR 459)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

I know, there are related issues already but decided to open a new issue
because it primarily relates to the interpretation of DR 459 by GCC and
response from C11/WG14.

(I also posted the same on the mailing list.)

I have read multiple bug reports (Bug 84522, Bug 80878, Bug 70490), and a past
decision regarding GCC change to redirect double-width (128-bit) atomics for
x86-64 and arm64 to libatomic. Below I mention major concerns as well as the
response from C11 (WG14) regarding DR 459 which, most likely, triggered this
change in more recent GCC releases in the first place. 

If I understand correctly, the redirection to libatomic was made for 2 reasons:

1. cmpxchg16b is not available on early amd64 processors. (However, mcx16 flag
already specifies that you use CPUs that have this instruction, so it should
not be a concern when the flag is specified.)

2. atomic_load on read-only memory. DR 459 now requires to have 'const'
qualifiers for atomic_load which probably resulted in the interpretation that
read-only memory must be supported. However, per response from C11/WG14 (see
below), it does not seem to be the case at all. Therefore, previously filed Bug
70490 does not seem to be valid.

There are several concerns with current GCC behavior:

1. Not consistent with clang/llvm which completely supports double-width
atomics for arm32, arm64, x86 and x86-64 making it possible to write portable
code (w/o specific extensions or assembly code) across all these architectures
(which is finally possible with C11!).
The behavior of clang: if mxc16 is specified, cmpxchg16b is generated for
x86-64 (without any calls to libatomic), otherwise -- redirection to libatomic.
For arm64, ldaxp/staxp are always generated. In my opinion, this is very
logical and non-confusing.

2. Oftentimes you want to have strict guarantees (by specifying mcx16 flag for
x86-64) that the generated code is lock-free, otherwise it is useless.
Double-width atomics are often used in lock-free algorithms that use tags
(stamps) for pointers to resolve the ABA problem. So, it is very useful to have
corresponding support in the compiler.

3. The behavior is inconsistent even within GCC. Older (and more limited, less
portable, etc) __sync builtins still use cmpxchg16b directly, newer __atomic
and C11 -- do not. Moreover, __sync builtins are probably less suitable for
arm/arm64.

4. atomic_load can be implemented using read-modify-write as it is the only
option for x86-64 and arm64 (see below).

For these reasons, it may be a good idea if GCC folks reconsider past decision.
And just to clarify: if mcx16 (x86-64) is not specified during compilation, it
is totally OK to redirect to libatomic, and there make the final decision if
target CPU supports a given instruction or not. But if it is specified, it
makes sense for performance reasons and lock-freedom guarantees to always
generate it directly.

-- Ruslan

Response from the WG14 (C11) Convener regarding DR 459: (I asked for a
permission to publish this response here.)
-
Ruslan,

 Thank you for your comments.  There is no normative requirement that const
objects be suitable for read-only memory.  An example and a footnote refer to
read-only memory as a way to illustrate a point, but examples and footnotes are
not normative.  The actual nature of read-only memory and how it can be used
are outside the scope of the standard, so there is nothing to prevent
atomic_load from being implemented as a read-modify-write operation.

David
--


My original email:

--

Dear David Keaton,

After reviewing the proposed change DR 459 for C11: http://www.open-std.org/
jtc1/sc22/wg14/www/docs/ summary.htm#dr_459 ,
I identified that adding const qualifier to atomic_load (C11 implements its
without it) may actually be harmful in some cases.

Particularly, for double-width (128-bit) atomics found in x86-64 (cmpxchg16b
instruction), arm64 (ldaxp/staxp instructions), it is currently only possible
to implement atomic_load for 128 bit using corresponding read-modify-write
instructions (i.e., potentially rewriting memory with the same value, but, in
essence, not changing it). But these implementations will not work on read-only
memory. Similar concerns apply to some extent to x86 and arm32 for double-width
(64-bit) atomics. Otherwise, there is no obstacle to implement all C11 atomics
for corresponding types in these architectures. Moreover, a well-known
clang/llvm compiler already implements all 

[Bug c++/84015] [7/8 Regression] ICE with class template argument deduction

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Feb 26 05:05:15 2018
New Revision: 257979

URL: https://gcc.gnu.org/viewcvs?rev=257979=gcc=rev
Log:
PR c++/84015 - ICE with class deduction and auto template parm.

* pt.c (rewrite_template_parm): Use tf_partial in first tsubst.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction49.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #17 from kargl at gcc dot gnu.org ---
After several people including have gone down rabbit
holes trying to fix this bug, I have found a patch!

[Bug c++/84015] [7/8 Regression] ICE with class template argument deduction

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[romain.geissler at amadeus dot com]

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

--- Comment #13 from Romain Geissler  ---
Hi,

It looks like that the code in #comment 11 works when you build just with -O2,
but not when you add debug symbols: -O2 -g. Do we have a way to ignore debug
statements when looking for the next statement in the next basic block ?

Cheers,
Romain

[Bug c/84562] New: -faggressive-loop-optimizations makes decisions based on weak data structures

[jnordholz at sect dot tu-berlin.de]

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

Bug ID: 84562
   Summary: -faggressive-loop-optimizations makes decisions based
on weak data structures
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jnordholz at sect dot tu-berlin.de
  Target Milestone: ---

Created attachment 43501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43501=edit
minimal example for both cases (int and array-of-char*)

(Minimal test case attached as source tar.gz, as the problem is inherently
multi-compilation-unit and doesn't involve any headers. Snippets below for
illustration.)

Compiling the following code with -c -O2...

__attribute__((weak)) const int y = 0;

void foo(void) {
for (i = 0; i < y; i++) {
write(2, "X", 1);
}
}

yields an empty foo() even though 'y' is weak (which I consider a bug, as
linking with another unit with a proper symbol 'y' with nonzero value will Do
The Wrong Thing and not even issue a warning - -fsanitize=undefined cannot help
either, as the whole loop is optimized away).

In a similar case, having

__attribute__((weak)) const char *arr[] = { NULL };
[...]
for (i = 0; arr[i]; i++) {

in one unit and overriding 'arr' in another with

const char *arr[] = { "abc", "def", NULL };

causes related problems: this time the loop doesn't disappear completely, so
-fsanitize=undefined complains about illegal array accesses - but I don't
believe this is justified, unless the different implicit array size is illegal
by the C standard; I couldn't find anything on that.

Tested with Debian gcc7 (7.3.0) and gcc8 (8.0.1) on x86_64, thus assigning to
the latest version.

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[law at redhat dot com]

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

--- Comment #30 from Jeffrey A. Law  ---
Just a note.  I'm tracking a separate problem with delay slot filling that
looks like it's related to handling of debug insns.  I doubt it's the same
problem, but if you stumble over it, be aware I'm testing a fix.

[Bug tree-optimization/84561] -Wstrinop-truncation with -O2 depends on strncpy's size type

[romain.geissler at amadeus dot com]

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

--- Comment #1 from Romain Geissler  ---
Note: I am testing with gcc snapshot from 24th February + patch from PR 84468
manually applied (at least I think I did).

[Bug c++/55881] #pragma GCC diagnostic ignored ignored when inlining

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #6 from Martin Sebor  ---
*** Bug 84555 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/84555] middle-end warnings are not ignorable with pragmas when inlined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Sebor  ---
As noted in bug 55881 comment 2, the problem has been known for some time but
it isn't easily fixable.

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

[Bug tree-optimization/84561] New: -Wstrinop-truncation with -O2 depends on strncpy's size type

[romain.geissler at amadeus dot com]

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

Bug ID: 84561
   Summary: -Wstrinop-truncation with -O2 depends on strncpy's
size type
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

There is another -Wformat-truncation that I don't understand with -O2. It looks
like I may or may not get the warning if the inlined size type used in strncpy
is 32 bits or 64 bits, and really can't figure out why that even matters wrt
warnings. Reproducer built with -Wall -Wextra -Werror -O2 on x86_64:

< class String
{
public:
String();

void set(const char* string, size_t len = N)
{
if (len > N)
{
len = N;
}

__builtin_strncpy(_string, string, len);
_string[len] = 0;
}

private:
char _string[N + 1];
};

class A
{
public:
A() {}

void setStringSize_t(const char* string, size_t len)
{
_string.set(string, len);
}

void setStringUnsignedInt(const char* string, unsigned int len)
{
_string.set(string, len);
}
private:
String<3> _string;
};

class B
{
public:
B() {}

A& getA()
{   
return _a;
}

private:
A _a;
};

void f(A& a)
{   
a.setStringUnsignedInt("123", 3); //No warning here.
a.setStringSize_t("123", 3); //No warning here.
}

void f(B& b)
{
b.getA().setStringUnsignedInt("123", 3); // Unexpected warning here.
b.getA().setStringSize_t("123", 3); // No warning here.
}
EOF

I am getting this error/warning:

error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output
truncated before terminating nul copying 3 bytes from a string of the same
length [-Werror=stringop-truncation]
 __builtin_strncpy(_string, string, len);
 ~^~

As you can see, using either "size_t" or "unsigned int" for parameter "len"
seems to influence the gcc warning, despite everything is fully inlined. Is
this expected ?

Cheers,
Romain

[Bug tree-optimization/84555] middle-end warnings are not ignorable with pragmas when inlined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-26
 CC||msebor at gcc dot gnu.org
Summary|strncpy warnings (and   |middle-end warnings are not
   |friends) are not ignorable  |ignorable with pragmas when
   |with pragmas when inlined   |inlined
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I can confirm this doesn't work as you would expect.  Unfortunately, the
problem isn't limited to just -Wstringop-truncation but affects many if not all
middle-end warnings.  Here's another example with -Wformat-truncation. 
-Wnonnull has the same problem.

$ cat b.c && gcc -O2 -S -Wall b.c
void g (char *d, unsigned n, const char *s, int i)
{
  __builtin_snprintf (d, n, "%s-%i", s, i);
}

char a[8], b[8];

void h (int i)
{
#pragma GCC diagnostic ignored "-Wformat-truncation"
  g (a, sizeof a, b, i);
}
b.c: In function ‘h’:
b.c:3:33: warning: ‘%i’ directive output may be truncated writing between 1 and
11 bytes into a region of size between 0 and 7 [-Wformat-truncation=]
   __builtin_snprintf (d, n, "%s-%i", s, i);
 ^~
b.c:3:3: note: ‘__builtin_snprintf’ output between 3 and 20 bytes into a
destination of size 8
   __builtin_snprintf (d, n, "%s-%i", s, i);
   ^~~~

[Bug c++/84560] Internal error in std::function with std::memset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-26
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed with 8.0, 7.4, and 6.4 regardless of optimization or similar options.
 I'm not sure what revision introduced the ICE but based on bisection it
doesn't seem the code was ever accepted.  It needs to be reduced to a smaller
test case to tell for sure.

[Bug c++/84559] [6/7/8 Regression] ICE with constexpr and variable-sized array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-25
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisected to r246662 (gcc 7.0.1):

r246662 | jason | 2017-04-03 17:15:36 -0400 (Mon, 03 Apr 2017) | 7 lines

PR sanitizer/79993 - ICE with VLA initialization from string

PR c++/69487 - wrong VLA initialization from string
* init.c (finish_length_check): Split out from build_vec_init.
(build_vec_init): Handle STRING_CST.
* typeck2.c (split_nonconstant_init): Handle STRING_CST.
(digest_init_r): Don't give a STRING_CST VLA type.

[Bug c++/84558] [6/7/8 Regression] ICE with invalid constexpr constructor

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-25
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE was introduced in r234439 (gcc 6.0.0):

r234439 | jakub | 2016-03-23 14:55:38 -0400 (Wed, 23 Mar 2016) | 8 lines

PR c++/70001
* constexpr.c (cxx_eval_vec_init_1): Reuse CONSTRUCTOR initializers
for 1..max even for multi-dimensional arrays.  Call unshare_expr
on it.

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
Yes, all the relevant tests pass with the patch.  There is no warning for
either the test case in comment #0 or the one in comment #11.  The change from
v1 of the patch is just the addition of test for null to avoid the ICE.

[Bug c++/84560] Internal error in std::function with std::memset

[zamazan4ik at tut dot by]

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

--- Comment #1 from Alexander Zaitsev  ---
On GCC 7.3.1 for this code I have:


internal compiler error: в expand_expr_real_1, в expr.c:9908
 memset(d[n - 1], 0, sizeof(int));
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccsFhYKj.out file, please attach this to
your bugreport.
gmake[3]: *** [CMakeFiles/test_proj.dir/build.make:63:
CMakeFiles/test_proj.dir/main.cpp.o] Ошибка 1
gmake[2]: *** [CMakeFiles/Makefile2:68: CMakeFiles/test_proj.dir/all] Ошибка 2
gmake[1]: *** [CMakeFiles/Makefile2:80: CMakeFiles/test_proj.dir/rule] Ошибка 2
gmake: *** [Makefile:118: test_proj] Ошибка 2

[Bug c++/84560] New: Internal error in std::function with std::memset

[zamazan4ik at tut dot by]

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

Bug ID: 84560
   Summary: Internal error in std::function with std::memset
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
  Target Milestone: ---

gcc(trunk) with '-O3 -march=native --std=c++11 -Wall' for this code:


#include 
#include 

using namespace std;

int main() {
int n = 1;
int m = 1;
int d[n][m];
function rec = [&]() {
memset(d[n - 1], 0, sizeof(int));
};
  return 0;
}


generates this:


: In lambda function:
:10:32: error: Local declaration from a different function
 function rec = [&]() {
^
D.34164
:11:16: note: in statement
 memset(d[n - 1], 0, sizeof(int));
^
_2 = (sizetype) D.34164;
:10:32: error: Local declaration from a different function
 function rec = [&]() {
^
D.34164
:11:16: note: in statement
 memset(d[n - 1], 0, sizeof(int));
^
_9 = (sizetype) D.34164;
:10:32: error: Local declaration from a different function
 function rec = [&]() {
^
D.34167
:11:23: note: in statement
 memset(d[n - 1], 0, sizeof(int));
~~~^
_13 = D.34167 /[ex] 4;
during GIMPLE pass: cfg
:10:32: internal compiler error: verify_gimple failed
 function rec = [&]() {
^
mmap: Cannot allocate memory
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler returned: 1


I think Internal error isn't good here.

Clang works fine.

[Bug c++/84559] New: [6/7/8 Regression] ICE with constexpr and variable-sized array

[reichelt at gcc dot gnu.org]

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

Bug ID: 84559
   Summary: [6/7/8 Regression] ICE with constexpr and
variable-sized array
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following (valid?) code snippet triggers an ICE since GCC 7.1.0:

==
void foo(int i)
{
  constexpr char x[i] = "";
}
==

bug.cc: In function 'void foo(int)':
bug.cc:5:25: internal compiler error: in cxx_eval_outermost_constant_expr, at
cp/constexpr.c:4810
   constexpr char x[i] = "";
 ^~
0x5e5bee cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4809
0x859c28 maybe_constant_init_1
../../gcc/gcc/cp/constexpr.c:5145
0x9ebcc2 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.c:833
0x881cda check_initializer
../../gcc/gcc/cp/decl.c:6384
0x899c5c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7038
0x934e63 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19703
0x93c268 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13044
0x93d078 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x93daa9 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:12463
0x91c45b cp_parser_statement
../../gcc/gcc/cp/parser.c:10912
0x91d3a0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d477 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933bf0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933bf0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
0x9344a0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26694
0x9351d4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26610
0x9351d4 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19482
0x93c268 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13044
0x93d078 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x940fd2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
Please submit a full bug report, [etc.]

The code is accepted by GCC 5 and GCC 6.

[Bug c++/84558] New: [6/7/8 Regression] ICE with invalid constexpr constructor

[reichelt at gcc dot gnu.org]

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

Bug ID: 84558
   Summary: [6/7/8 Regression] ICE with invalid constexpr
constructor
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE since GCC 6.1.0.
The code was accepted in GCC 5.x.0 (compiled with "-std=c++1y"):

==
struct A
{
  static int i;
  constexpr A() { i = 0; }
};

struct B
{
  A a[2][1][1];
};

B b;
==

bug.cc:12:3:   in 'constexpr' expansion of 'b.B::B()'
bug.cc:12:3: internal compiler error: Segmentation fault
 B b;
   ^
0xeb1ddf crash_signal
../../gcc/gcc/toplev.c:325
0x8567af contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x8567af cxx_eval_vec_init_1
../../gcc/gcc/cp/constexpr.c:2981
0x852665 cxx_eval_vec_init
../../gcc/gcc/cp/constexpr.c:3011
0x852665 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4535
0x854f1d cxx_eval_store_expression
../../gcc/gcc/cp/constexpr.c:3685
0x8525cf cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4248
0x852b6f cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4552
0x851697 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4296
0x851697 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4296
0x85162d cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4647
0x850aaf cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1689
0x85164b cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4170
0x856c97 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4819
0x859c28 maybe_constant_init_1
../../gcc/gcc/cp/constexpr.c:5145
0x8cd1ca expand_default_init
../../gcc/gcc/cp/init.c:1901
0x8cd1ca expand_aggr_init_1
../../gcc/gcc/cp/init.c:2004
0x8cd3d9 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1744
0x8820ef build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:6188
0x8820ef check_initializer
../../gcc/gcc/cp/decl.c:6337
Please submit a full bug report, [etc.]

[Bug fortran/68289] Missing diagnostic pragmas

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED
 CC||tkoenig at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #9 from Thomas Koenig  ---
I've assigned it to myself, with the understanding that
it may take some time before I do anything about this.

So, if anybody wants do do some work already, please go ahead :)

[Bug c++/84557] New: ICE with invalid firstprivate variable

[reichelt at gcc dot gnu.org]

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

Bug ID: 84557
   Summary: ICE with invalid firstprivate variable
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet (compiled with "-fopenmp") 
triggers an ICE since GCC 4.2.0:

=
template struct A {};

void foo()
{
#pragma omp parallel firstprivate (A<0>)
  ;
}
=

bug.cc: In function 'void foo()':
bug.cc:5:36: internal compiler error: in cp_parser_lookup_name, at
cp/parser.c:25974
 #pragma omp parallel firstprivate (A<0>)
^~~~
0x624d80 cp_parser_lookup_name
../../gcc/gcc/cp/parser.c:25974
0x92209a cp_parser_lookup_name_simple
../../gcc/gcc/cp/parser.c:26168
0x92209a cp_parser_omp_var_list_no_open
../../gcc/gcc/cp/parser.c:31342
0x923e5f cp_parser_omp_all_clauses
../../gcc/gcc/cp/parser.c:33723
0x93ebc8 cp_parser_omp_parallel
../../gcc/gcc/cp/parser.c:35652
0x9196bc cp_parser_omp_construct
../../gcc/gcc/cp/parser.c:38094
0x91a207 cp_parser_pragma
../../gcc/gcc/cp/parser.c:38713
0x91c7cc cp_parser_statement
../../gcc/gcc/cp/parser.c:10883
0x91d3a0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d477 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933bf0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933bf0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
0x9344a0 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26694
0x9351d4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26610
0x9351d4 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19482
0x93c268 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13044
0x93d078 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x940fd2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
0x9413e1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12643
0x9416d4 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
Please submit a full bug report, [etc.]

[Bug debug/83917] [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace

[daniel.santos at pobox dot com]

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

--- Comment #5 from Daniel Santos  ---
(In reply to Jakub Jelinek from comment #4)
> Patch posted: http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01294.html

My apologies on dropping the ball here and thanks for picking it up! :)

[Bug c++/84556] New: C++17, lambda, OpenMP simd: sorry, unimplemented: unexpected AST

[bisqwit at iki dot fi]

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

Bug ID: 84556
   Summary: C++17, lambda, OpenMP simd: sorry, unimplemented:
unexpected AST
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bisqwit at iki dot fi
  Target Milestone: ---

This code generates an AST error when compiled with -std=c++17 -fopenmp.

void foo()
{
auto keymaker = [](void)
{
#pragma omp simd
for(unsigned pos = 0; pos < 4; ++pos)
{
}
};
}

test.cc: In lambda function:
test.cc:9:5: sorry, unimplemented: unexpected AST of kind omp_simd
 };
 ^
test.cc:9: confused by earlier errors, bailing out

Compiling without -fopenmp, or using an earlier standard mode such as
-std=c++14 or -std=c++11, the error is not produced.

Tested on: g++-7 (Debian 7.2.0-19) 7.2.0
Tested on: g++-7 (Debian 7.2.0-18) 7.2.0
Tested on: g++-7.1 (GCC) 7.1.0

Problem does NOT occur on:
g++-6 (Debian 6.4.0-11) 6.4.0 20171206

Problem does NOT occur with #pragma omp parallel for.

[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues

[dominiq at lps dot ens.fr]

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

--- Comment #37 from Dominique d'Humieres  ---
Created attachment 43500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43500=edit
Failures with -fdefault-integer-8 at revision r257969

[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues

[dominiq at lps dot ens.fr]

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

--- Comment #36 from Dominique d'Humieres  ---
New summaries of failures with -fdefault-integer-8 at revision r257969

=== gfortran Summary for unix/-m32/-fdefault-integer-8 ===

# of expected passes41549
# of unexpected failures1357
# of expected failures  56
# of unresolved testcases   183
# of unsupported tests  553


=== gfortran Summary for unix/-m64/-fdefault-integer-8 ===

# of expected passes42229
# of unexpected failures936
# of expected failures  56
# of unresolved testcases   182
# of unsupported tests  432

[Bug tree-optimization/84555] strncpy warnings (and friends) are not ignorable with pragmas when inlined

[romain.geissler at amadeus dot com]

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

--- Comment #1 from Romain Geissler  ---
This example emits:

error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output
truncated before terminating nul copying 3 bytes from a string of the same
length [-Werror=stringop-truncation]
 return __builtin_strncpy(dest, source, size);
~^~~~
cc1plus: all warnings being treated as errors


while one would expect that no warning is emitted here.

[Bug tree-optimization/84555] New: strncpy warnings (and friends) are not ignorable with pragmas when inlined

[romain.geissler at amadeus dot com]

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

Bug ID: 84555
   Summary: strncpy warnings (and friends) are not ignorable with
pragmas when inlined
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

I have hit this case today. Let's consider that for any reason, you have a
wrapper around strncpy (and friends). Then it looks like that #pragma diagnotic
that are used around the call site of the wrapper are ignored in -O2 when gcc
does some inlining.

Example (built with -Wall -Werror -Wextra -O2):

<

[Bug bootstrap/84554] New: make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

[kdevel at vogtner dot de]

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

Bug ID: 84554
   Summary: make check: FAIL: tversion: ERROR! The versions of
gmp.h (5.0.5) and libgmp (4.3.1) do not match.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kdevel at vogtner dot de
  Target Milestone: ---

OS: centos 6.9 (X86_64)
expect: installed
dejagnu: NOT installed

N=3
langs=ada,c,c++,fortran,go,objc,obj-c++

tar xf $src/gcc-7.3.0.tar.xz
cd gcc-7.3.0
tar xfj $src/gmp-5.0.5.tar.bz2
mv gmp-5.0.5 gmp
tar xfz $src/mpc-1.0.1.tar.gz
mv mpc-1.0.1 mpc
tar xfj $src/mpfr-3.1.5.tar.bz2
mv mpfr-3.1.5 mpfr
tar xfj $src/isl-0.18.tar.bz2
mv isl-0.18 isl
cd ..
mkdir gcc-objdir
cd gcc-objdir
../gcc-7.3.0/configure --prefix=$inst --enable-languages=$langs

make -j$N bootstrap
make check

RESULT:

make[4]: Entering directory `/.../bld-7.3.0/gcc-objdir/mpfr/tests'
make[5]: Entering directory `/.../bld-7.3.0/gcc-objdir/mpfr/tests'
FAIL: tversion   
PASS: tinternals
PASS: tinits

:

PASS: tzeta 
PASS: tzeta_ui

Testsuite summary for MPFR 3.1.5 

# TOTAL: 160
# PASS:  158
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log

make[5]: *** [test-suite.log] Fehler 1
make[5]: Leaving directory `/bld-7.3.0/gcc-objdir/mpfr/tests'
make[4]: *** [check-TESTS] Fehler 2
make[4]: Leaving directory `/.../bld-7.3.0/gcc-objdir/mpfr/tests'
make[3]: *** [check-am] Fehler 2
make[3]: Leaving directory `/.../bld-7.3.0/gcc-objdir/mpfr/tests'
make[2]: *** [check-recursive] Fehler 1
make[2]: Leaving directory `/.../bld-7.3.0/gcc-objdir/mpfr'
make[1]: *** [check-mpfr] Fehler 2
make[1]: Leaving directory `/.../bld-7.3.0/gcc-objdir'
make: *** [do-check] Fehler 2


test-suite.log
--

==
   MPFR 3.1.5: tests/test-suite.log
==

# TOTAL: 160
# PASS:  158
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tversion
==

ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.
The possible causes are:
  * A bad configuration in your include/library search paths.
  * An inconsistency in the include/library search paths of
your development environment; an example:
  http://gcc.gnu.org/ml/gcc-help/2010-11/msg00359.html
  * GMP has been upgraded after the first "make check".
In such a case, try again after a "make clean".
  * A new or non-standard version naming is used in GMP.
In this case, a patch may already be available on the 
MPFR web site.  Otherwise please report the problem.
In the first two cases, this may lead to errors, in particular with MPFR.
If some other tests fail, please solve that problem first.
FAIL tversion (exit status: 1)

SKIP: tget_set_d64
==

SKIP tget_set_d64 (exit status: 77)

[Bug c/84553] New: -rdynamic generates TEXTREL relocations on ia64

[slyfox at inbox dot ru]

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

Bug ID: 84553
   Summary: -rdynamic generates TEXTREL relocations on ia64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

This is a trimmed-down version of gcc compiling itself with TEXTRELs on ia64:
https://bugs.gentoo.org/566118

Minimal reproducer:

  // cat lto-lang.c 
  struct a {
int (*b)(void);
int c;
  };
  int d(void) {}
  const struct a e = { , 0, };

  int main(){}
$ LANG=C ia64-unknown-linux-gnu-gcc -O0 -no-pie -fno-PIE lto-lang.c -o
lto-lang -Wl,-z,text -rdynamic
/usr/libexec/gcc/ia64-unknown-linux-gnu/ld: read-only segment has dynamic
relocations.
collect2: error: ld returned 1 exit status

Used version:
binutils-2.30 (older 2.29 is also affected), gcc-HEAD (older 6.4.0 is also
affected)

I'm not sure who exactly is at fault here: gcc or binutils.

What happens here is:
  'const struct e' (with .text pointer) is placed into '.rodata' by gcc and
later is merged into '.text'.

What I suspect should happen:
  'const struct e' (with .text pointer) is placed into '.data.rel.ro' by gcc
and later is merged into '.data'?

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[romain.geissler at amadeus dot com]

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

--- Comment #11 from Romain Geissler  ---
Hi,

Indeed this version of the patch doesn't have any segv. However it seems that
it doesn't fix anymore the initial bug report. Does it actually passes the new
tests you introduced in your patch ?

Unless I am mistaken (I am pretty sure I have applied the patch), the following
code extracted from your tests still emit a warning with -O2

a, q->a, sizeof p->a - 1);/* { dg-bogus
"\\\[-Wstringop-truncation" } */

  p->a[sizeof p->a - 1] = 0;
}
EOF

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[ebotcazou at gcc dot gnu.org]

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

--- Comment #29 from Eric Botcazou  ---
> Never mind, it seems that gcc 5.5 is doing that as hazard_nowell. I will run
> some more tests.

Yes, the nops are preexisting and counter-measures for pipeline hazards, but I
don't know the MIPS port enough to say much more than that.

[Bug fortran/68289] Missing diagnostic pragmas

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
From  pr64273:

Tobias Burnus 2014-12-11 16:29:56 UTC

Follow up to PR44054 and PR53552. See also related bugs PR28662, PR62226,
PR53934.

There are two possibilities, either to use a real
  #pragma warning
or to make it more Fortran-like and use
  !GCC$ warning directive

See PR44054 and PR53552.

Dominique d'Humieres 2014-12-11 16:40:45 UTC

> There are two possibilities, either to use a real
>   #pragma warning
> or to make it more Fortran-like and use
>   !GCC$ warning directive


Yuck!-(I think there are a lot of really more important things to do. In any
case choose the latter).

[Bug fortran/64273] Add support for "#pragma warning" or "!GCC$ warning directive"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---
Mark as duplicate of pr68289.

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

[Bug fortran/68289] Missing diagnostic pragmas

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #7 from Dominique d'Humieres  ---
*** Bug 64273 has been marked as a duplicate of this bug. ***

[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-25
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Let me take a look tomorrow.

[Bug fortran/84546] [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #3)
> > This is a rather old regression, r247548 already has it.
> 
> The change occurred between revisions r241509 (2016-10-25,OK) and r241635
> (2016-10-27, STOP), r241528 (pr72770)?

r241528 fails, r241527 does not, so rr241528 it is.

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[nbd at nbd dot name]

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

--- Comment #28 from Felix Fietkau  ---
Never mind, it seems that gcc 5.5 is doing that as well. I will run some more
tests.

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[nbd at nbd dot name]

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

--- Comment #27 from Felix Fietkau  ---
On the original test case, it generates this code:

00400690 :
  400690:   8c830008lw  v1,8(a0)
  400694:   24020001li  v0,1
  400698:   10620011beq v1,v0,4006e0 
  40069c:   nop
  4006a0:   8c83lw  v1,0(a0)
  4006a4:   nop
  4006a8:   28630002sltiv1,v1,2
  4006ac:   106abeqzv1,4006d8 
  4006b0:   nop
  4006b4:   8c82000clw  v0,12(a0)
  4006b8:   nop
  4006bc:   8c42lw  v0,0(v0)
  4006c0:   nop
  4006c4:   00a2182bsltuv1,a1,v0
  4006c8:   1467bnezv1,4006e8 
  4006cc:   nop
  4006d0:   0045102bsltuv0,v0,a1
  4006d4:   00021023neguv0,v0
  4006d8:   03e8jr  ra
  4006dc:   nop
  4006e0:   03e8jr  ra
  4006e4:   2402li  v0,-1
  4006e8:   03e8jr  ra
  4006ec:   24020001li  v0,1

It looks to me like it's generating lots of useless nop instructions after lw

[Bug c++/84461] [8 regression] openjdk-10 fails to build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.0
   Severity|normal  |critical

[Bug target/84522] GCC does not generate cmpxchg16b when mcx16 is used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Dup of bug 80878.

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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||nruslan_devel at yahoo dot com

--- Comment #10 from Andrew Pinski  ---
*** Bug 84522 has been marked as a duplicate of this bug. ***

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #43497|0   |1
is obsolete||

--- Comment #26 from Eric Botcazou  ---
Created attachment 43499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43499=edit
Second tentative fix

Adjusted for second testcase but still to be tested.

[Bug target/84547] Suboptimal code for masked shifts (ARM64)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||aarch64*-*
   Severity|normal  |enhancement

[Bug tree-optimization/84552] [8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
   Target Milestone|--- |8.0

[Bug target/45996] -falign-functions=X does not work

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Most targets check if -falign-* is already set before messing with it at -Os.

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[ebotcazou at gcc dot gnu.org]

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

--- Comment #25 from Eric Botcazou  ---
> /var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/
> reorg.c:3895
> 
> Line 1787 in reorg.c is this piece of code:
> if (REG_NOTE_KIND (link) != REG_DEAD
> || !REG_P (XEXP (link, 0)))
>   continue;

Weird, this looks like some ill-formed REG_DEAD note.  I'll try to reproduce on
SPARC tomorrow.

[Bug tree-optimization/84552] New: [8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[asolokha at gmx dot com]

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

Bug ID: 84552
   Summary: [8 Regression] Compile time hog w/ -O2
-floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre
-fno-tree-loop-ivcanon
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180218 snapshot (r257797) takes indefinite time to compile the
following snippet w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre
-fno-tree-loop-ivcanon:

int cx;

int
e6 (int pj, int xe)
{
  for (cx = 0; cx < 2; ++cx)
while (xe < 1)
  {
for (cx = 0; cx < 2; ++cx)
  pj *= 2;

if (cx != 0)
  goto o3;

++xe;
  }

 o3:
  return pj;
}

% timeout 5 gcc-8.0.0-alpha20180218 -O2 -floop-nest-optimize
-fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon -c v8gjilr7.c
zsh: exit 124   timeout 5 gcc-8.0.0-alpha20180218 -O2 -floop-nest-optimize
-fno-tree-copy-pro

Two outstanding entries captured by perf top:

  61.24%  cc1   [.] degenerate_phi_result
  38.49%  cc1   [.] follow_copies_to_constant

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[nbd at nbd dot name]

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

--- Comment #24 from Felix Fietkau  ---
Created attachment 43498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43498=edit
Test case for internal compiler error (musl source file)´

When I test it with a patched gcc 7.3.x, I get this error on compiling remquo.c
from musl with: -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc
-fno-caller-saves -fno-plt -msoft-float

remquo.c: In function 'remquo':
remquo.c:82:1: internal compiler error: Segmentation fault
 }
 ^
0x9dd06f crash_signal
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/toplev.c:337
0x9797f8 fix_reg_dead_note
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:1787
0x97e409 relax_delay_slots
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3231
0x97e409 dbr_schedule
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3723
0x97e409 rest_of_handle_delay_slots
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3864
0x97e409 execute
   
/var/nbd/lede/build_dir/toolchain-mipsel_24kc_gcc-7.3.0_musl/gcc-7.3.0/gcc/reorg.c:3895

Line 1787 in reorg.c is this piece of code:
if (REG_NOTE_KIND (link) != REG_DEAD
|| !REG_P (XEXP (link, 0)))
  continue;

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from kargl at gcc dot gnu.org ---
Fixed of 6-branch, 7-branch, and trunk.
Thanks for bug reports.

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #11)
> > *** Bug 69420 has been marked as a duplicate of this bug. ***
> 
> Yes, but what about pr69419?

What about it?  It is unrelated.

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 25 17:32:36 2018
New Revision: 257974

URL: https://gcc.gnu.org/viewcvs?rev=257974=gcc=rev
Log:
2018-02-25  Steven G. Kargl  

PR fortran/83633
* decl.c (variable_decl): Check that an explicit-shape-array with
nonconstant bounds is allowed.

2018-02-25  Steven G. Kargl  

PR fortran/83633
* gfortran.dg/explicit_shape_1.f90: New test.
* gfortran.dg/automatic_module_variable.f90: Update regex.
* gfortran.dg/bad_automatic_objects_1.f90: Ditto.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/explicit_shape_1.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
   
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/automatic_module_variable.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> *** Bug 69420 has been marked as a duplicate of this bug. ***

Yes, but what about pr69419?

[Bug fortran/69420] ICE: tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from kargl at gcc dot gnu.org ---
This is essentially a duplicate of 83633 where much more
detail is given for the fix.  Mark it as dup even though
this PR came first.

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

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #10 from kargl at gcc dot gnu.org ---
*** Bug 69420 has been marked as a duplicate of this bug. ***

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 25 17:08:51 2018
New Revision: 257972

URL: https://gcc.gnu.org/viewcvs?rev=257972=gcc=rev
Log:
2018-02-25  Steven G. Kargl  

PR fortran/83633
* decl.c (variable_decl): Check that an explicit-shape-array with
nonconstant bounds is allowed.

2018-02-25  Steven G. Kargl  

PR fortran/83633
* gfortran.dg/explicit_shape_1.f90: New test.
* gfortran.dg/automatic_module_variable.f90: Update regex.
* gfortran.dg/bad_automatic_objects_1.f90: Ditto.
* gfortran.dg/constant_shape.f90: Ditto.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/explicit_shape_1.f90
Modified:
branches/gcc-7-branch/gcc/fortran/decl.c
   
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/automatic_module_variable.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/constant_shape.f90

[Bug target/83496] [7/8 regression] wrong code generated with -Os -mbranch-cost=1

[ebotcazou at gcc dot gnu.org]

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

--- Comment #23 from Eric Botcazou  ---
Created attachment 43497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43497=edit
Tentative fix

To be tested.

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Feb 25 16:50:50 2018
New Revision: 257971

URL: https://gcc.gnu.org/viewcvs?rev=257971=gcc=rev
Log:
2018-02-25  Steven G. Kargl  

PR fortran/83633
* decl.c (variable_decl): Check that an explicit-shape-array with
nonconstant bounds is allowed.

2018-02-25  Steven G. Kargl  

PR fortran/83633
* gfortran.dg/explicit_shape_1.f90: New test.
* gfortran.dg/automatic_module_variable.f90: Update regex.
* gfortran.dg/bad_automatic_objects_1.f90: Ditto.
* gfortran.dg/constant_shape.f90: Ditto.
* gfortran.dg/dec_structure_23.f90: Ditto.
* gfortran.dg/pr78240.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/explicit_shape_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/automatic_module_variable.f90
trunk/gcc/testsuite/gfortran.dg/bad_automatic_objects_1.f90
trunk/gcc/testsuite/gfortran.dg/constant_shape.f90
trunk/gcc/testsuite/gfortran.dg/dec_structure_23.f90
trunk/gcc/testsuite/gfortran.dg/pr78240.f90

[Bug c++/84434] [8 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp/pt.c

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug fortran/84523] [8 Regression] Runtime crash deallocating allocatable array within derived type

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
For the record:

> Caused by revision r257065.

> Quite why this testcase worked before revision r257065 I cannot for the life
> of me understand.

Actually I think this was exposed by r257065 but caused by r251949.

The following variant is OK with r251946

program gfcbug148
  implicit none
  type t_spot
real, allocatable :: vm(:,:,:)
  end type t_spot
  type t_rowcol
integer   :: nh
type(t_spot), pointer :: spots(:) =>NULL()
  end type t_rowcol
  type(t_rowcol)  :: col
  call construct (col, 80)
  call destruct  (col)
  print *, "OK"
  !
contains
  !
  subroutine construct (rc, nh)
type(t_rowcol) ,intent(out) :: rc   ! row or column to set
integer,intent(in)  :: nh   ! number of spots in a row
rc% nh = nh
allocate (rc% spots (nh))
  end subroutine construct
  !
  subroutine destruct (rc)
type(t_rowcol) ,intent(inout) :: rc   ! row or column to free
integer :: k
if (associated (rc% spots)) then
  print *, "### destruct: size(rc% spots)=", size(rc% spots)
  if (size(rc% spots) > 1) then
print *, "### destruct: allocated (vm) =", allocated(rc%spots(1)%vm)
  end if
  print *, size(rc% spots)
  do k=1, size(rc% spots)
print *, k, allocated (rc% spots(k)% vm)
  end do
  print *, "before deallocate"
endif
nullify (rc% spots)
  end subroutine destruct
end program gfcbug148

but gives with r251980

 ### destruct: size(rc% spots)=  80
 ### destruct: allocated (vm) = F
  80
   1 F

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

when compiled with -fsanitize=undefined.

[Bug target/70713] msp430 interrupt attribute prevents overriding weak symbols

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Joe Seymour from comment #5)
> Thanks for chasing.
> 
> From my point of view, yes the committed patch makes all the changes
> required for this bug to be considered resolved, however I don't have
> permission to make those changes myself.
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00758.html
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00767.html

OK, closing as FIXED then.

[Bug fortran/84546] [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4
 CC||vehre at gcc dot gnu.org
  Known to work||6.4.0
  Known to fail||7.3.0, 8.0

--- Comment #3 from Dominique d'Humieres  ---
> This is a rather old regression, r247548 already has it.

The change occurred between revisions r241509 (2016-10-25,OK) and r241635
(2016-10-27, STOP), r241528 (pr72770)?

[Bug gcov-profile/84548] [8 regression] gcov ICE in process_file, at gcov.c:1154

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
r257859 build w/o --enable-checking=extra FAIL too

[Bug testsuite/70516] Regtesting acats hangs on x86_64-apple-darwin15.4

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Dominique d'Humieres  ---
> AFAICT this seems related to the current state of my system, thus I am 
> removing
> the regression marker and setting the status to SUSPENDED (allow me for
> some time before closing this PR as INVALID).

Closing as INVALID.

[Bug c++/84551] New: [8 Regression] [concepts] Compiler options "-O -g" cause valid code to be rejected

[reichelt at gcc dot gnu.org]

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

Bug ID: 84551
   Summary: [8 Regression] [concepts] Compiler options "-O -g"
cause valid code to be rejected
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet (compiled with "-fconcepts -g -O")
is wrongly rejected and triggers an ICE on trunk:

===
template concept bool C() { return true; }

template