[Bug c++/81124] [8 Regression] internal compiler error: in operator*, at cp/cp-tree.h:726

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-19
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|internal compiler error: in |[8 Regression] internal
   |operator*, at   |compiler error: in
   |cp/cp-tree.h:726|operator*, at
   ||cp/cp-tree.h:726
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r248517.  Let me attach the preprocessed source, if you compress
it, it will fit just fine.

[Bug c++/81124] internal compiler error: in operator*, at cp/cp-tree.h:726

[hunter at openrobotics dot org]

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

--- Comment #1 from Hunter L. Allen  ---
preprocessed file was too large to be an attachment, so I made a gist for it: 

https://gist.github.com/allenh1/b5a3119e0c9322b50a7b2810411f9037

[Bug c++/81124] New: internal compiler error: in operator*, at cp/cp-tree.h:726

[hunter at openrobotics dot org]

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

Bug ID: 81124
   Summary: internal compiler error: in operator*, at
cp/cp-tree.h:726
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hunter at openrobotics dot org
  Target Milestone: ---

Got an internal compiler error, seems to be a regression.


/home/allenh1/ros2_ws/src/ros2/rclcpp/rclcpp/src/rclcpp/parameter.cpp:254:65:  
  internal compiler error: in operator*, at cp/cp-tree.h:726
std::to_string(const rclcpp::parameter::ParameterVariant & param)

Here's the backtrace:

0x5e48d9 ovl_iterator::operator*() const
../../gcc-dev/gcc/cp/cp-tree.h:726
0x8c6a3e ovl_iterator::operator*() const
../../gcc-dev/gcc/cp/cp-tree.h:726
0x8c6a3e set_decl_namespace(tree_node*, tree_node*, bool)
../../gcc-dev/gcc/cp/name-lookup.c:4341
0x5c4f18 grokfndecl
../../gcc-dev/gcc/cp/decl.c:8605
0x8654a4 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc-dev/gcc/cp/decl.c:12220
0x868e46 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../gcc-dev/gcc/cp/decl.c:15139
0x8e5e6f cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-dev/gcc/cp/parser.c:26162
0x8e5e6f cp_parser_init_declarator
../../gcc-dev/gcc/cp/parser.c:19172
0x90280c cp_parser_simple_declaration
../../gcc-dev/gcc/cp/parser.c:12804
0x903535 cp_parser_block_declaration
../../gcc-dev/gcc/cp/parser.c:12629
0x8d9144 cp_parser_declaration
../../gcc-dev/gcc/cp/parser.c:12527
0x909b2b cp_parser_declaration_seq_opt
../../gcc-dev/gcc/cp/parser.c:12403
0x909e52 cp_parser_translation_unit
../../gcc-dev/gcc/cp/parser.c:4364
0x909e52 c_parse_file()
../../gcc-dev/gcc/cp/parser.c:38477
0xa09926 c_common_parse_file()
../../gcc-dev/gcc/c-family/c-opts.c:1104

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

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

--- Comment #5 from Vincent Lefèvre  ---
I'm reopening this PR since it is actually not solved. There are two remaining
issues.

The first issue is no longer the formula, but the fact that LDBL_MAX is
strictly less than the maximum normalized number in the floating-point model. I
think that either LDBL_MAX_EXP should be reduced to 1023 (thus any
representable value with exponent 1024 would be regarded as unnormalized), or
the standard should be corrected in some other way, e.g. to allow an incomplete
binade for the largest exponent.

The second issue is that one can get a finite value
0x1.f7cp+1023 that is strictly larger than LDBL_MAX =
0x1.f78p+1023 (see the first and third numbers output
by my program given in comment 0). Thus LDBL_MAX is not the maximum
representable finite number as required by the standard.

[Bug c++/68070] Undefined reference to default constructor of member template class

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

 CC||db0451 at gmail dot com

--- Comment #1 from DB  ---
Confirmed and discussed on Stack Overflow:

https://stackoverflow.com/questions/44588166/default-value-of-function-parameter-initialized-by-list-initialization

[Bug middle-end/40748] simple switch/case, if/else and arithmetics result in different code

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
We also miss the even simpler case that should be optimized to "return n;"

int foo(int n){
switch(n){
case 0:
return 0;
case 1:
return 1;
case 2:
return 2;
case 3:
return 3;
default:
__builtin_unreachable();
}
}

llvm performs the expected optimization in both cases.

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

[hjl at gcc dot gnu.org]

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

--- Comment #10 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sun Jun 18 19:00:49 2017
New Revision: 249351

URL: https://gcc.gnu.org/viewcvs?rev=249351=gcc=rev
Log:
x32: Update baseline_symbols.txt

PR libstdc++/81092
* config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
   
branches/gcc-7-branch/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt

[Bug rtl-optimization/81123] ICE while compiling with -O1 -fstrict-overflow -floop-nest-optimize

[ziebell_marco at posteo dot de]

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

--- Comment #1 from ziebell_marco at posteo dot de ---
Created attachment 41580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41580=edit
the log file of the build

[Bug rtl-optimization/81123] New: ICE while compiling with -O1 -fstrict-overflow -floop-nest-optimize

[ziebell_marco at posteo dot de]

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

Bug ID: 81123
   Summary: ICE while compiling with -O1 -fstrict-overflow
-floop-nest-optimize
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ziebell_marco at posteo dot de
  Target Milestone: ---

Created attachment 41579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41579=edit
the output of report-bug output file

When compiling VLC version 2.2.6 with following CFLAGS:
-O1 -fstrict-overflow -floop-nest-optimize

I hit an ICE:
config/getopt.c: In function ‘exchange’:
config/getopt.c:41:13: internal compiler error: in add_loop_constraints, at
graphite-sese-to-poly.c:933
 static void exchange(char **argv, vlc_getopt_t *restrict state)
 ^~~~
gcc 6.3.0
isl 0.15

[Bug fortran/52473] CSHIFT slow - inline it?

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Jun 18 18:04:19 2017
New Revision: 249350

URL: https://gcc.gnu.org/viewcvs?rev=249350=gcc=rev
Log:
2017-06-18  Thomas Koenig  

PR fortran/52473
* m4/cshift0.m4:  For arrays that are contiguous up to
shift, implement blocked algorighm for cshift.
* generated/cshift0_c10.c:  Regenerated.
* generated/cshift0_c16.c:  Regenerated.
* generated/cshift0_c4.c:  Regenerated.
* generated/cshift0_c8.c:  Regenerated.
* generated/cshift0_i1.c:  Regenerated.
* generated/cshift0_i16.c:  Regenerated.
* generated/cshift0_i2.c:  Regenerated.
* generated/cshift0_i4.c:  Regenerated.
* generated/cshift0_i8.c:  Regenerated.
* generated/cshift0_r10.c:  Regenerated.
* generated/cshift0_r16.c:  Regenerated.
* generated/cshift0_r4.c:  Regenerated.
* generated/cshift0_r8.c:  Regenerated.

2017-06-18  Thomas Koenig  

PR fortran/52473
* gfortran.dg/cshift_1.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/cshift_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/cshift0_c10.c
trunk/libgfortran/generated/cshift0_c16.c
trunk/libgfortran/generated/cshift0_c4.c
trunk/libgfortran/generated/cshift0_c8.c
trunk/libgfortran/generated/cshift0_i1.c
trunk/libgfortran/generated/cshift0_i16.c
trunk/libgfortran/generated/cshift0_i2.c
trunk/libgfortran/generated/cshift0_i4.c
trunk/libgfortran/generated/cshift0_i8.c
trunk/libgfortran/generated/cshift0_r10.c
trunk/libgfortran/generated/cshift0_r16.c
trunk/libgfortran/generated/cshift0_r4.c
trunk/libgfortran/generated/cshift0_r8.c
trunk/libgfortran/m4/cshift0.m4

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

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sun Jun 18 16:43:53 2017
New Revision: 249349

URL: https://gcc.gnu.org/viewcvs?rev=249349=gcc=rev
Log:
x32: Update baseline_symbols.txt

PR libstdc++/81092
* config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt: Updated.

Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt

[Bug libstdc++/81122] New: parsing f stopped after '0' when reading std::hexfloat >> f;

[koh...@t-online.de]

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

Bug ID: 81122
   Summary: parsing f stopped after '0' when reading std::hexfloat
>> f;
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koh...@t-online.de
  Target Milestone: ---

Created attachment 41578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41578=edit
commented example showing the effect

Any reading of hexfloat values is stopping after '0',
e.g. 
  std::istringstream("0x1P-1022") >> std::hexfloat >> f;
yields f = 0, next char to read is 'x'.

I'm not knowing the standard reaction, but found an example source giving the
expected result.
My source taken in parts from this source:
http://naipc.uchicago.edu/2014/ref/cppreference/en/cpp/io/manip/fixed.html

[Bug target/81121] New: [7/8 Regression] ICE: in extract_insn, at recog.c:2311

[trippels at gcc dot gnu.org]

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

Bug ID: 81121
   Summary: [7/8 Regression] ICE: in extract_insn, at recog.c:2311
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

% cat arithm.ii
void foo(short *p1, short *p2) {
  float a = 0;
  p2[0] = p1[0] * a;
}

 % g++ -march=amdfam10 -mno-sse2 -c arithm.ii
arithm.ii: In function ‘void foo(short int*, short int*)’:
arithm.ii:4:1: error: unrecognizable insn:
 }
 ^
(insn 25 24 13 2 (set (reg:V4SF 21 xmm0 [orig:88 _2 ] [88])
(float:V4SF (reg:V4SI 21 xmm0 [orig:88 _2 ] [88]))) "arithm.ii":3 -1
 (nil))
arithm.ii:4:1: internal compiler error: in extract_insn, at recog.c:2311

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

[schwab at gcc dot gnu.org]

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

--- Comment #8 from Andreas Schwab  ---
Author: schwab
Date: Sun Jun 18 14:36:02 2017
New Revision: 249348

URL: https://gcc.gnu.org/viewcvs?rev=249348=gcc=rev
Log:
PR libstdc++/81092
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt