[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[dougmencken at gmail dot com]

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

--- Comment #20 from Douglas Mencken  ---
$ git bisect good
good: [270b838d816f8a2c372eac0121adcdf570feccfa] Regenerate .pot files.
Bisecting: 90 revisions left to test after this (roughly 7 steps)
[6f2116bed6e87668a914dc27fff34c7a68576d4e]  PR libstdc++/77356  *
include/bits/regex_compiler.tcc(_M_insert_bracket_matcher,   
_M_expression_term): Modify to support dash literal.*
include/bits/regex_scanner.h: Add dash as a token type to makea
different from the mandated dash literal by escaping. *
include/bits/regex_scanner.tcc(_M_scan_in_bracket): Emit dash token in
bracket expression parsing.* testsuite/28_regex/regression.cc: Add new
testcases.
...
$ git bisect good
good: [6f2116bed6e87668a914dc27fff34c7a68576d4e]PR libstdc++/77356 
* include/bits/regex_compiler.tcc(_M_insert_bracket_matcher,   
_M_expression_term): Modify to support dash literal.*
include/bits/regex_scanner.h: Add dash as a token type to makea
different from the mandated dash literal by escaping. *
include/bits/regex_scanner.tcc(_M_scan_in_bracket): Emit dash token in bracket
expression parsing.* testsuite/28_regex/regression.cc: Add new testcases.
Bisecting: 45 revisions left to test after this (roughly 6 steps)
[304fb2e5e141baf6e9b6d4993389fc3d8acc7059] rs6000: Don't emit a use of LR in
returns and sibcalls
...
../.././libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at
recog.c:2310

This commit from Segher
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02040.html
looks very related, notably deleted instruction

“ The return_internal_ pattern can now be deleted since nothing uses it
anymore. ”

-(define_insn "*return_internal_"
-  [(simple_return)
-   (use (match_operand:P 0 "register_operand" "lc"))]
-  ""
-  "b%T0"
-  [(set_attr "type" "jmpreg")])

$ git bisect bad
bad: [304fb2e5e141baf6e9b6d4993389fc3d8acc7059] rs6000: Don't emit a use of LR
in returns and sibcalls
Bisecting: 21 revisions left to test after this (roughly 5 steps)
[17437807e9ee1d8ee95d957d31b98c3a6dadc220] selftest.h: mark failure functions
with ATTRIBUTE_NORETURN.
...
$ git bisect good
good: [17437807e9ee1d8ee95d957d31b98c3a6dadc220] selftest.h: mark failure
functions with ATTRIBUTE_NORETURN.
Bisecting: 10 revisions left to test after this (roughly 4 steps)
[77ce623298307d0d816cb8fc95728f9433a7e1e2]  PR debug/77389  *
g++.dg/debug/dwarf2/template-params-12f.C: Pass -gno-strict-dwarf in
dg-options.
$ git show
$ git bisect skip
Bisecting: 10 revisions left to test after this (roughly 4 steps)
[850c20095027d73b4cff0a1bb43dc33192d8c30c] rich_location: add convenience
overloads for adding fix-it hints
...
$ git bisect good
good: [850c20095027d73b4cff0a1bb43dc33192d8c30c] rich_location: add convenience
overloads for adding fix-it hints
Bisecting: 1 revision left to test after this (roughly 1 step)
[53187361667797547265d910db5733744288b63f] 2016-08-30  Fritz Reese 

$ git show
$ git bisect skip
Bisecting: 1 revision left to test after this (roughly 1 step)
[9a6075867d2af9ed1feaa645a81a5f80aca49150] [PATCH][Aarch64][gcc] Fix vld2/3/4
on big endian systems
...
$ git bisect good
304fb2e5e141baf6e9b6d4993389fc3d8acc7059 is the first bad commit

Yep, it is

[Bug c++/84196] [6/7/8 Regression] invalid call to a function template with a vector argument silently accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
  Known to work||4.7.4
Summary|invalid instantiation of a  |[6/7/8 Regression] invalid
   |function template on a  |call to a function template
   |vector type silently|with a vector argument
   |accepted|silently accepted
  Known to fail||4.8.4, 4.9.4, 5.5.0, 6.4.0,
   ||7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Bisection suggests this is regression introduced by r186994 in GCC 4.8.  Prior
to that, GCC rejected the test case with the following errors:

pr84196.C: In instantiation of ‘int f(T) [with T = int]’:
pr84196.C:9:21:   required from here
pr84196.C:4:34: error: subscripted value is neither array nor pointer
   return v[0] + v[1] + v[2] + v[3];
  ^
pr84196.C:4:34: error: subscripted value is neither array nor pointer
   return v[0] + v[1] + v[2] + v[3];
  ^
pr84196.C:4:34: error: subscripted value is neither array nor pointer
   return v[0] + v[1] + v[2] + v[3];
  ^
pr84196.C:4:34: error: subscripted value is neither array nor pointer
   return v[0] + v[1] + v[2] + v[3];
  ^
pr84196.C: In function ‘int f(T) [with T = int]’:
pr84196.C:5:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^

[Bug c++/84196] New: invalid instantiation of a function template on a vector type silently accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 84196
   Summary: invalid instantiation of a function template on a
vector type silently 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 rejects invalid calls to ordinary functions that take a vector argument but
it silently accepts and emits bogus code for the invalid code below.  Rather
than doing that, it should reject it similarly to how Clang does.

$ cat t.C && gcc -O2 -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.C
template 
int f (T v __attribute__ ((vector_size (16
{
  return v[0] + v[1] + v[2] + v[3];
}

int main ()
{
  return f (12345678);
}

;; Function f (_Z1fIiEiT_, funcdef_no=2, decl_uid=2359, cgraph_uid=1,
symbol_order=1)

f (vector(4) int v)
{
  int _1;
  int _2;
  int _3;
  int _4;
  int _5;
  int _6;
  int _8;

   [local count: 1073741825]:
  _1 = BIT_FIELD_REF ;
  _2 = BIT_FIELD_REF ;
  _3 = _1 + _2;
  _4 = BIT_FIELD_REF ;
  _5 = _3 + _4;
  _6 = BIT_FIELD_REF ;
  _8 = _5 + _6;
  return _8;

}



;; Function main (main, funcdef_no=1, decl_uid=2357, cgraph_uid=0,
symbol_order=0) (executed once)

main ()
{
  int _2;

   [local count: 1073741825]:
  _2 = f (12345678); [tail call]
  return _2;

}


Clang gives the following error:

t.C:2:28: error: invalid vector element type 'T'
int f (T v __attribute__ ((vector_size (16
   ^
t.C:4:10: error: subscripted value is not an array, pointer, or vector
  return v[0] + v[1] + v[2] + v[3];
 ^ ~
t.C:9:10: note: in instantiation of function template specialization 'f'
requested here
  return f (12345678);
 ^
2 errors generared

[Bug c/84195] New: newlines in deprecated diagnostics

[msebor at gcc dot gnu.org]

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

Bug ID: 84195
   Summary: newlines in deprecated diagnostics
   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 deprecated attribute makes it possible for GCC diagnostics to be broken up
by newlines introduced by the program.  I think it would better to remove
newlines and other control characters from the string before printing it so
that they don't mess up tools that parse GCC output.  If there's no limit on
the length of the string it might also be worthwhile to impose it.

$ cat t.C && gcc -O -S -Wall -Wextra t.C
#define MSG "\nThis is deprecated.\nPlease do not use it.\n"

int f (int i __attribute__ ((deprecated (MSG
{
  return 0 ? i : 0;
}

void g (int i)
{
  f (i);
}
t.C: In function ‘int f(int)’:
t.C:5:14: warning: ‘i’ is deprecated: 
This is deprecated.
Please do not use it.
[-Wdeprecated-declarations]
   return 0 ? i : 0;
  ^
t.C:3:12: note: declared here
 int f (int i __attribute__ ((deprecated (MSG
^~~~

[Bug target/84113] [7/8 Regression] libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311

[dougmencken at gmail dot com]

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

--- Comment #19 from Douglas Mencken  ---
I got repo from git://gcc.gnu.org/git/gcc.git and begun to bisect it to find
the cause of regression

"good" here means reaching build of libstdc++-v3 after than problem libgcc

$ git bisect start
$ git bisect good gcc-6_4_0-release
good: [45dd06cef49fe00a7839d7dff312b09e88910a51] Update ChangeLog and version
files for release
$ git bisect bad gcc-7_1_0-release
bad: [f9105a38249fb57f7778acf3008025f2dcac2b1f] Update ChangeLog and version
files for release
Bisecting: a merge base must be tested
...
$ git bisect good
good: [a050099a416f013bda35832b878d9a57b0cbb231]PR c++/70594*
constexpr.c (constexpr_call_table): Preserve in GC.   (struct fundef_copy,
struct fundef_copies_table_t): Delete. (fundef_copies_table):
Preserve in GC. Change to pointer to tree->tree hash.   
(maybe_initialize_fundef_copies_table): Adjust. (get_fundef_copy):
Return a TREE_LIST.  Use non-inserting search.   (save_fundef_copy): Adjust
for a TREE_LIST. (cxx_eval_call_expression): Adjust for a fundef_copy
TREE_LIST. (fini_constexpr): New.  * cp-tree.h (fini_constexpr):
Declare.  * decl2.c (c_parse_final_cleanups): Call fini_constexpr.
Bisecting: 3873 revisions left to test after this (roughly 12 steps)
[20f2fdd71e4f2acb8e4ade02c9d031c1633ec8dd] Daily bump.
...
Makefile:1642: ../.././gcc/java/Make-lang.in: No such file or directory
make[3]: *** No rule to make target `../.././gcc/java/Make-lang.in'.  Stop.
make[2]: *** [all-stage1-gcc] Error 2
...
$ git bisect skip
skip: [20f2fdd71e4f2acb8e4ade02c9d031c1633ec8dd] Daily bump.
Bisecting: 3873 revisions left to test after this (roughly 12 steps)
[4e91a07b9010003cb22c22c20c6aa6417a57333b] PR tree-optimization/71831 -
__builtin_object_size poor results with no  optimization
...
../.././libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at
recog.c:2310
...
$ git bisect bad
bad: [4e91a07b9010003cb22c22c20c6aa6417a57333b] PR tree-optimization/71831 -
__builtin_object_size poor results with no optimization
Bisecting: 1461 revisions left to test after this (roughly 11 steps)
[035778dec3d7f2895fec1259f912498f77be569a] /cp 2016-06-14  Paolo Carlini 

...
$ git bisect good
good: [035778dec3d7f2895fec1259f912498f77be569a] /cp 2016-06-14  Paolo Carlini 

Bisecting: 730 revisions left to test after this (roughly 10 steps)
[1660595b07f5f618405c23a11af6160eef5b23e2] Fix tests for targets with
sizeof(int) != 32.
...
$ git bisect good
good: [1660595b07f5f618405c23a11af6160eef5b23e2] Fix tests for targets with
sizeof(int) != 32.
Bisecting: 364 revisions left to test after this (roughly 9 steps)
[081a6ff0f79d63a83a561d8178baabcad5c7ff08] [RS6000] e500 part of pr71680
...
$ git bisect good
good: [081a6ff0f79d63a83a561d8178baabcad5c7ff08] [RS6000] e500 part of pr71680
Bisecting: 181 revisions left to test after this (roughly 8 steps)
[270b838d816f8a2c372eac0121adcdf570feccfa] Regenerate .pot files.
...

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #12 from dave.anglin at bell dot net ---
On 2018-01-31 3:17 AM, tkoenig at gcc dot gnu.org wrote:
> Is there anything than can be done to debug this?
> What happens if you compile the test with -g and
> run it under a debgger?
It's not easy.  It turns out the "system" call causes gdb to crash. 
Working around that,
we have at the end of data_transfer_init:

Breakpoint 34, data_transfer_init (dtp=0x83fffdff0ad0,
 read_flag=) at 
../../../gcc/libgfortran/io/transfer.c:3201
3201  if ((cf & (IOPARM_DT_LIST_FORMAT | 
IOPARM_DT_HAS_NAMELIST_NAME)) == 0
(gdb) p cf
$7 = 128
(gdb) p *dtp
$8 = {common = {flags = 128, unit = 6,
 filename = 0x40001860 "read_dir.f90", line = 10,
 iomsg_len = 9223376434867631712, iomsg = 0x83fffdfedbf8 "\200",
 iostat = 0x83fffdff0acc}, rec = 0, size = 0x9,
   iolength = 0x40001870, internal_unit_desc = 0x0,
   format = 0x400018a0  "", format_len = 6,
   advance_len = 4611686018427394176,
   advance = 0x1 ,
   internal_unit = 0x0, internal_unit_len = 9223376434866410515,
   namelist_name_len = 9223376434866047520,
   namelist_name = 0x4 , id 
= 0x0,
   pos = 4, asynchronous = 0x40001888 "read", asynchronous_len = 0,
   blank_len = 0, blank = 0x83fffdff07b0 "\200",
   decimal = 0x83fffde64a20 "\200", decimal_len = 3,
   delim_len = 9223376434866032944, delim = 0x83fffdff0b10 "@",
   pad = 0x318 , pad_len = 1,
   round_len = 0, round = 0x0,
   sign = 0x83fffdda4293  "\301\210\034 
\030S\302>\241S\334?\001\350@\320", sign_len = 281479271677959, u = {p = {
   transfer = 0x83fffde62260, current_unit = 0x8001a518,
   item_count = 0, mode = WRITING, blank_status = BLANK_NULL,
   sign_status = SIGN_UNSPECIFIED, scale_factor = 0, max_pos = 0,
   skips = 0, pending_spaces = 0, sf_seen_eor = 0,
---Type  to continue, or q  to quit---
   advance_status = ADVANCE_YES, reversion_flag = 0, first_item = 1,
   seen_dollar = 0, eor_condition = 0, no_leading_blank = 0, 
char_flag = 0,
   input_complete = 0, at_eol = 0, comma_flag = 0, namelist_mode = 0,
   nml_read_error = 0, sf_read_comma = 0, line_buffer_enabled = 0,
   unit_is_internal = 0, at_eof = 0, g0_no_blanks = 0,
   format_not_saved = 0, expanded_read = 0, child_saved_iostat = 0,
   nml_delim = 0, repeat_count = 0, saved_length = 0, saved_used = 0,
   saved_type = BT_UNKNOWN, saved_string = 0x0, scratch = 0x0,
   line_buffer = 0x0, fmt = 0x0, ionml = 0x0, line_buffer_pos = 0,
   value = '\000' , not_used = 0, fdtio_ptr = 0x0,
   ufdtio_ptr = 0x0, cc = {type = 0, len = 0, u = {start = 0 '\000',
   end = 0 '\000'}}},
 pad = 
"\200\000\003\377\375\346\"`\200\000\000\001\000\000\245\030\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\003",
 
'\000' , "@", '\000' ...}}

[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
In response to DR476 the C standard has been clarified (or is in the process of
being clarified, as the DR is still open) that a "volatile access" is intended
to mean an access to an object via a volatile-qualified lvalue.  I believe C++
has discussed adopting a similar clarification in response to the C DR, if it
hasn't done so yet.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_476

[Bug c++/84194] New: fails to pack structs with template members

[stsp at users dot sourceforge.net]

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

Bug ID: 84194
   Summary: fails to pack structs with template members
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

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

Hello.

Attached is a fully automated test-case
for the problem. Just run "make" and it
will compile test-case with clang and with
gcc, and will compare the output:

---
$ LC_ALL=C make 
clang++ -std=c++11 -o p_clng pod.cpp
g++ -std=c++11 -o p_gcc pod.cpp
pod.cpp:16:23: warning: ignoring packed attribute because of unpacked non-POD
field 'SymWrp lol::_n'
   SymWrp _n;
   ^~
./tst.sh
Test FAILED (sizeof returns 6 instead of 4)
---

This is somewhat similar to bug #83732, but
in #83732 it was considered a diagnostic problem.
Unfortunately it actually produces the bad code,
which is what the test-case demonstrates.

The test code is:

---
#include 
#include 

template
class SymWrp : public T {
public:
SymWrp() = default;
};

struct dhdr {
  uint16_t dh_attr;
};

struct lol {
  unsigned char _l;
  SymWrp _n;
  unsigned char _nj;
} __attribute__((packed));

int main()
{
printf("%zi\n", sizeof(struct lol));
return 0;
}
---

[Bug fortran/84122] Incorrect statement sequence in PDT definition

[neil.n.carlson at gmail dot com]

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

--- Comment #3 from Neil Carlson  ---
Here's a related invalid example that gfortran accepts:

module mod
type foo(dim)
  integer,len,public :: dim
  integer :: array(dim)
end type
end module

PUBLIC/PRIVATE attributes are not valid attributes for a type parameter
definition statement; see R431 and R433 (F08).

Gfortran does reject PRIVATE. but the error message
Error: PRIVATE attribute conflicts with LEN attribute at (1)
together with it allowing PUBLIC seems to betray that the PDT implementation
views type parameters as type components. The issue is not so much that PRIVATE
conflicts with LEN, as that type parameters do not have an accessibility
attribute.

[Bug c++/84186] nested template qualified-id not parsed correctly

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
In the way of background, although I would have said yes (the 'template'
keyword is needed), Clang, ICC, and MSVC all accept the code without it.

[Bug fortran/84122] Incorrect statement sequence in PDT definition

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
This needs to be addressed in parse.c at lines 3281-3283:

case ST_PROCEDURE:
  accept_statement (st);
  seen_component = 1;

The accepted statement needs to be checked to see if it
is a type-param-def-stmt.  If it is then seen_component
may be 0 and left unchanged.  I suspect that we'll need
to add seen_type_param_len and seen_type_param_kind to
skip the error that is printed later.

[Bug c++/84192] [7/8 Regression] ICE with statement expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-03
 CC||msebor at gcc dot gnu.org
  Known to work||4.9.4, 6.4.0
 Ever confirmed|0   |1
  Known to fail||5.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r217670 (GCC 5.0.0) as the first revision that fails. 
Before then GCC would print just:

pr84192.C: In function ‘bool foo()’:
pr84192.C:3:20: error: could not convert ‘’ from ‘void’ to ‘bool’
   return ({ return true; }) && false;
^
pr84192.C:4:1: error: control reaches end of non-void function
[-Werror=return-type]
 }
 ^

But then the ICE became latent with r230365 (Merge C++ delayed folding branch
in GCC 6), but then has started to ICE again with r238559:

[Bug other/84193] New: Document the limitations of -fcheck-pointer-bounds

[bruno at clisp dot org]

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

Bug ID: 84193
   Summary: Document the limitations of -fcheck-pointer-bounds
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

The documentation of -fcheck-pointer-bounds in
https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Instrumentation-Options.html says
  - what the option does,
  - what are the prerequisites from other tools,
  - how it can be fine-tuned.
However, it does not say what are the limitations.

=== Quoting the article "Design of Intel MPX" from Intel
:

"At the application level, the MPX-protected program may require manual changes
due to troublesome C coding patterns, multithreading issues, or potential
problems with other ISA extensions. (In some cases, it is inadvisable to use
MPX at all.)"

"the protected application will have worse cache locality"

"Intel MPX can cause issues when used together with other ISA extensions, e.g.,
Intel TSX and Intel SGX. Intel MPX may cause transactional aborts in some
corner cases when used inside an Intel TSX hardware transaction ..."

"our evaluation reveals that narrowing of bounds breaks many programs (see
Usability)..." (The entire section "Not supported C idioms" is relevant.)

=== Quoting Florian Weimer, a glibc co-maintainer
:

"-fcheck-pointer-bounds in GCC doesn't really work. The existing implementation
is barely a research prototype (for example, most string functions are not
protected by it), and I don't think anyone knows how to make it thread-safe."


Really, as a user of GCC, I would like to be made aware of these limitations
through the GCC documentation, so that I don't waste my time attempting to use
a technology that will not work with my application.

[Bug c++/84192] New: [7/8 Regression] ICE with statement expression

[reichelt at gcc dot gnu.org]

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

Bug ID: 84192
   Summary: [7/8 Regression] ICE with statement expression
   Product: gcc
   Version: unknown
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 7.1.0:


bool foo()
{ 
  return ({ return true; }) && false;
}


bug.cc: In function 'bool foo()':
bug.cc:3:29: internal compiler error: Segmentation fault
   return ({ return true; }) && false;
 ^~
0xd721af crash_signal
../../gcc-7.1.0/gcc/toplev.c:337
0x847125 cxx_eval_constant_expression
../../gcc-7.1.0/gcc/cp/constexpr.c:4103
0x84d67e cxx_eval_outermost_constant_expr
../../gcc-7.1.0/gcc/cp/constexpr.c:4640
0x850976 maybe_constant_value(tree_node*, tree_node*)
../../gcc-7.1.0/gcc/cp/constexpr.c:4855
0x82b54a cp_fully_fold(tree_node*)
../../gcc-7.1.0/gcc/cp/cp-gimplify.c:1976
0x72eb47 cp_parser_binary_expression
../../gcc-7.1.0/gcc/cp/parser.c:8937
0x72efb4 cp_parser_assignment_expression
../../gcc-7.1.0/gcc/cp/parser.c:9169
0x732df8 cp_parser_expression
../../gcc-7.1.0/gcc/cp/parser.c:9338
0x72116d cp_parser_jump_statement
../../gcc-7.1.0/gcc/cp/parser.c:12151
0x72116d cp_parser_statement
../../gcc-7.1.0/gcc/cp/parser.c:10585
0x721a0d cp_parser_statement_seq_opt
../../gcc-7.1.0/gcc/cp/parser.c:11031
0x721adf cp_parser_compound_statement
../../gcc-7.1.0/gcc/cp/parser.c:10985
0x722248 cp_parser_function_body
../../gcc-7.1.0/gcc/cp/parser.c:21432
0x722248 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-7.1.0/gcc/cp/parser.c:21470
0x722511 cp_parser_function_definition_after_declarator
../../gcc-7.1.0/gcc/cp/parser.c:26261
0x7231fd cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-7.1.0/gcc/cp/parser.c:26173
0x7231fd cp_parser_init_declarator
../../gcc-7.1.0/gcc/cp/parser.c:19159
0x74718c cp_parser_simple_declaration
../../gcc-7.1.0/gcc/cp/parser.c:12777
0x747f25 cp_parser_block_declaration
../../gcc-7.1.0/gcc/cp/parser.c:12602
0x74d3d4 cp_parser_declaration
../../gcc-7.1.0/gcc/cp/parser.c:12500
Please submit a full bug report, [etc.]

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #36 from Paul Thomas  ---
Fixed on trunk. Thanks for the report.

Thanks, Thomas, for your help too.

Paul

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[pault at gcc dot gnu.org]

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

Bug 84155 Summary: [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155

   What|Removed |Added

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

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #17 from Paul Thomas  ---
Fixed on trunk. Thanks for the report.

Thanks, Thomas, for your help too.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
The statements are removed upon conversion to gimple:

--- Falsch/a.f90.004t.gimple2018-02-03 15:08:29.370147886 +0100
+++ Korrekt/a.f90.004t.gimple   2018-02-03 15:07:16.428178637 +0100
@@ -893,6 +893,9 @@
 [a.f90:24:0] _22 = [a.f90:24:0] [a.f90:24:0]
container.array.offset;
 [a.f90:24:0] _23 = _22 + 1;
 [a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype = {};
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.elem_len = 4;
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.rank = 1;
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.type = 1;
 [a.f90:24:0] overflow.22 = 0;
 [a.f90:24:0] if (overflow.22 != 0) goto ; else goto
;
 :
--- Falsch/a.f90.006t.omplower  2018-02-03 15:08:29.370147886 +0100
+++ Korrekt/a.f90.006t.omplower 2018-02-03 15:07:16.428178637 +0100
@@ -914,6 +914,9 @@
 [a.f90:24:0] _22 = [a.f90:24:0] [a.f90:24:0]
container.array.offset;
 [a.f90:24:0] _23 = _22 + 1;
 [a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype = {};
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.elem_len = 4;
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.rank = 1;
+[a.f90:24:0] [a.f90:24:0] [a.f90:24:0] [a.f90:24:0]
[a.f90:24:0] MEM[(struct array_t[0:] *)_21][_23].child.dtype.type = 1;
 [a.f90:24:0] overflow.22 = 0;
 [a.f90:24:0] if (overflow.22 != 0) goto ; else goto
;
 :

Looks like a middle-end bug to me.

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[pault at gcc dot gnu.org]

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

--- Comment #35 from Paul Thomas  ---
Author: pault
Date: Sat Feb  3 14:06:44 2018
New Revision: 257356

URL: https://gcc.gnu.org/viewcvs?rev=257356&root=gcc&view=rev
Log:
2018-02-03  Paul Thomas  

PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Instead of gfc_get_dtype
use gfc_get_dtype_rank_type.

2018-02-03  Paul Thomas  

PR fortran/84141
PR fortran/84155
* gfortran.dg/pr84155.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr84155.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84155] [8 Regression] program hangs on valid code

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas  ---
Author: pault
Date: Sat Feb  3 14:06:44 2018
New Revision: 257356

URL: https://gcc.gnu.org/viewcvs?rev=257356&root=gcc&view=rev
Log:
2018-02-03  Paul Thomas  

PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Instead of gfc_get_dtype
use gfc_get_dtype_rank_type.

2018-02-03  Paul Thomas  

PR fortran/84141
PR fortran/84155
* gfortran.dg/pr84155.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr84155.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84155] [8 Regression] program hangs on valid code

[paul.richard.thomas at gmail dot com]

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

--- Comment #14 from paul.richard.thomas at gmail dot com  ---
Hi Dominique,

Thanks for doing that. It was to have been my final step in the process.

I will commit the patch and then will go back to diagnose why an
unchanged tree dump yields different assembler.

Cheers

Paul


On 3 February 2018 at 12:44, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
>
> --- Comment #13 from Dominique d'Humieres  ---
>> There is an important caveat to this fix, which has me very worried:
>> On top of removal of uncalled code making the bug disappear, I cannot
>> see any difference in the tree dump between the working testcase and
>> the failing version.
>
> Confirmed. However looking to the assembly for the first test, I see
>
> ...
> movq$4, (%rcx)  #, MEM[(struct array_t[0:]
> *)_21][_23].child.dtype.elem_len
> ...
> movb$1, (%rcx)  #, MEM[(struct array_t[0:]
> *)_21][_23].child.dtype.rank
> ...
> movb$1, (%rax)  #, MEM[(struct array_t[0:]
> *)_21][_23].child.dtype.type
> ...
>
> for the working case that are not present without the patch.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug c++/84191] New: Compiler ICEs when trying to resolve impossible arithmetic operations

[cjdb.ns at gmail dot com]

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

Bug ID: 84191
   Summary: Compiler ICEs when trying to resolve impossible
arithmetic operations
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

Created attachment 43332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43332&action=edit
Output from -save-temps for GCC 7.2 (Seven-point-two)

# Description

It's possible to cause an ICE on some arithmetic expressions when `T op U` is
ill-formed. The ICE goes away when this particular expression is fixed.

I've attached the ICEing temps; please let me know if you'd like the success
temps too.

# Command line

ninja test.doge.gl.uniform

# Platforms observed

* g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0
* g++.exe (Rev1, Built by MSYS2 project) 7.3.0

# Compiler flags

/usr/bin/g++-7   -I/mnt/c/Users/cjdbn/projects/doge/doge/include
-I/c/Users/cjdbn/projects/cmcstl2/include -I/c/Users/cjdbn/projects/GSL/include
-I/c/Users/cjdbn/projects/stb -std=c++17 -fconcepts -march=native -Wall -Wextra
-Wno-attributes -pedantic -Werror -ftemplate-backtrace-limit=0 -O0 -g3
-fno-inline -fstack-protector-all -fno-omit-frame-pointer
-fno-optimize-sibling-calls -fsanitize=address -fsanitize=undefined -MD -MT
test/doge/gl/CMakeFiles/test.doge.gl.uniform.dir/uniform.cpp.o -MF
test/doge/gl/CMakeFiles/test.doge.gl.uniform.dir/uniform.cpp.o.d -o
test/doge/gl/CMakeFiles/test.doge.gl.uniform.dir/uniform.cpp.o -c
/mnt/c/Users/cjdbn/projects/doge/doge/test/doge/gl/uniform.cpp

## Notes

* /c is a symlink for /mnt/c
* Same results when compiling with -fno-strict-aliasing -fwrapv

# Diagnostic

/mnt/c/Users/cjdbn/projects/doge/doge/test/doge/gl/uniform.cpp: In lambda
function:
/mnt/c/Users/cjdbn/projects/doge/doge/test/doge/gl/uniform.cpp:250:40: internal
compiler error: in expand_expr_real_1, at expr.c:9843
   check_binary_arithmetic_operation(f, a, n);
   ~^
0x867d45 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:9837
0x86ee25 expand_expr
../../src/gcc/expr.h:276
0x86ee25 expand_expr_addr_expr_1
../../src/gcc/expr.c:7782
0x8656fe expand_expr_addr_expr
../../src/gcc/expr.c:7903
0x8656fe expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:11046
0x86f6ba store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../src/gcc/expr.c:5552
0x87030e expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5321
0x781620 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3639
0x781620 expand_gimple_stmt
../../src/gcc/cfgexpand.c:3737
0x782bef expand_gimple_basic_block
../../src/gcc/cfgexpand.c:5744
0x787d76 execute
../../src/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
ninja: build stopped: subcommand failed.

[Bug fortran/84155] [8 Regression] program hangs on valid code

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> There is an important caveat to this fix, which has me very worried:
> On top of removal of uncalled code making the bug disappear, I cannot
> see any difference in the tree dump between the working testcase and
> the failing version.

Confirmed. However looking to the assembly for the first test, I see

...
movq$4, (%rcx)  #, MEM[(struct array_t[0:]
*)_21][_23].child.dtype.elem_len
...
movb$1, (%rcx)  #, MEM[(struct array_t[0:]
*)_21][_23].child.dtype.rank
...
movb$1, (%rax)  #, MEM[(struct array_t[0:]
*)_21][_23].child.dtype.type
...

for the working case that are not present without the patch.

[Bug c/84173] Support glibc multiarch interpreter names

[javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net]

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

Javier Serrano Polo  
changed:

   What|Removed |Added

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

--- Comment #8 from Javier Serrano Polo  ---
> the patch stands a chance of being accepted.

[Bug c++/81057] [6/7/8 Regression] ICE with broken default template parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
  Known to work||8.0.1
 Depends on||84125
 Resolution|--- |FIXED
   Target Milestone|6.5 |8.0

--- Comment #2 from Volker Reichelt  ---
Fixed on trunk by Marek's patch for PR84125.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84125
[Bug 84125] [8 Regression] ICE in generic lambda when static_assert argument is
implicitly converted to bool

[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> Why those are handled differently? First looks like it works, second does
> not. It was my main signal to file a bug against gcc as asymmetry looked
> fishy.

Because the problematic bitfield path is only used for fields in structures,
i.e. misaligned integers are handled by another, simpler path.

[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
IIRC, the standard provides guarantees for volatile objects. Here, you are
accessing a non-volatile object through a volatile type, and if the compiler
can find out about the underlying object, it can ignore 'volatile'. At least I
seem to remember discussions along those lines in the past.

[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest

[bruno at clisp dot org]

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

--- Comment #1 from Bruno Haible  ---
It works when I declare ys1, ys2, zs1, zs2 as 'volatile double' instead of
'double'. But I should not be needing to do this, because the only uses of
these 4 variables is as arguments to equalfn, which takes 'volatile double *'
arguments, which ought to already do the truncation from extended-double format
to double format.

[Bug middle-end/58479] [6/7/8 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #13 from Aldy Hernandez  ---
Ugh yeah, really bad.  Reconfirmed.

tor:~/bld/t/gcc$ time ./cc1 -O1 -g a.c -quiet

real4m59.125s
user4m52.388s
sys 0m1.384s

--enable-checking=yes,types,extra

[Bug c/84190] New: [7 Regression] double arithmetic on x86 no longer rounds to nearest

[bruno at clisp dot org]

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

Bug ID: 84190
   Summary: [7 Regression] double arithmetic on x86 no longer
rounds to nearest
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

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

The attached program foo.c tests whether simple 'double' arithmetic does
round-to-nearest. It uses 'volatile double' types to make sure that on x86,
x86_64, and ia64, only 53 bits of precision are used instead of the "extended"
doubles that have 64 bits of precision.

With gcc versions 4.2.4 to 6.4.0:
$ gcc -m32 -O -Wall foo.c && ./a.out
1 1 1 1

With gcc versions 7.1.0 to 7.3.0:
$ gcc -m32 -O -Wall foo.c && ./a.out
0 0 0 0

This occurs even with -frounding-math:
$ gcc -m32 -O -frounding-math -Wall foo.c && ./a.out
0 0 0 0

It does not occur when inlining is disabled:
$ gcc -m32 -O -fno-inline -Wall foo.c && ./a.out
1 1 1 1

[Bug tree-optimization/57218] [6/7/8 Regression] Excessive inlining even at -Os

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2013-05-10 00:00:00 |2018-2-3
 CC||aldyh at gcc dot gnu.org

--- Comment #11 from Aldy Hernandez  ---
Reconfirmed.

[Bug rtl-optimization/57193] [6/7/8 Regression] suboptimal register allocation for SSE registers

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed|2015-06-01 00:00:00 |2018-2-3
 CC||aldyh at gcc dot gnu.org

--- Comment #15 from Aldy Hernandez  ---
Reconfirmed.

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

[juergen.reuter at desy dot de]

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

--- Comment #34 from Jürgen Reuter  ---
So, to summarise all of our code, at least our basic and extended tests, work
again with this (second) patch by Paul Thomas, for all different kind types of
our default reals (64, 80, emulated 128 bit). Thanks for the quick fix.

[Bug target/54063] [6/7/8 regression] on powerpc64 gcc 4.9/6/7/8 generates larger code for global variable accesses than gcc 4.7

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
   Target Milestone|8.0 |9.0

--- Comment #17 from Aldy Hernandez  ---
As per a conversation with Segher.  This is still an issue, but will not be
fixed for GCC 8.  Moving target milestone.