[Bug debug/86064] [8/9 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}

[aoliva at gcc dot gnu.org]

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

--- Comment #12 from Alexandre Oliva  ---
Author: aoliva
Date: Sat Jun 30 04:16:16 2018
New Revision: 262268

URL: https://gcc.gnu.org/viewcvs?rev=262268=gcc=rev
Log:
[PR86064] split single cross-partition range with nonzero locviews

We didn't split cross-partition ranges in loclists to output a
whole-function location expression, but with nonzero locviews, we
force loclists, and then we have to split to avoid cross-partition
list entries.

for  gcc/ChangeLog

PR debug/86064
* dwarf2out.c (loc_list_has_views): Adjust comments.
(dw_loc_list): Split single cross-partition range with
nonzero locview.

for  gcc/testsuite/ChangeLog

PR debug/86064
* gcc.dg/pr86064.c: New.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr86064.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/42970] Missed unused function return value elimination

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Should Martin Jambor remain the assignee for this?

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
The values created for the four NaNs are

7fff8001
7fff8002ab3c
7fff8001
7fff8002ab3c

with -mabi=ieeelongdouble

and

7fff8001
7fff8002ab3c
7fff0001
7fff0002ab3c

with -mabi=ibmlongdouble (the latter is correct).

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Created attachment 44342
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44342=edit
Patch to map 'q' builtins to 'l' instead of 'f128'

This patch 'fixes' the problem by changing the __builtin_nanq and
__builtin_nansq functions to __builtin_nanl and __builtin_nansl when long
double is IEEE, but I suspect it is just papering over the problem.  If you
call __builtin_nanf128, it will still fail.

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
If I change the __builtin_nanq calls to __builtin_nanl and the __builtin_nansq
calls to __builtin_nansl when __float128 and long double use the same type, the
test works fine.

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
BTW, I compiled the same code on the x86 with both -mlong-double-80 and
-mlong-double-128 options, and FRE1 deletes the code, but returns 0 instead of
calling abort.

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-29
 Ever confirmed|0   |1

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||powerpc64le-linux
   Target Milestone|--- |9.0

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 44341
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44341=edit
Fre1 tree pass

[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 44340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44340=edit
Ealias tree pass (pass before FRE1)

[Bug tree-optimization/86367] New: FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128

[meissner at gcc dot gnu.org]

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

Bug ID: 86367
   Summary: FRE1 tree pass deletes code in
gcc.target/powerpc/nan128-1.c when long double is IEEE
128
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44339
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44339=edit
Test case

I was going through the lists of tests that behave differently when the powerpc
long double type is set to IEEE 128-bit.

The test gcc.target/powerpc/nan128-1.c fails when compiled with
-mabi=ieeelongdouble -Wno-psabi (or configuring the compiler using
--with-long-double-format=ieee).

I tracked this down, and the FRE1 tree pass is deleting all of the code, and
replacing it with a call to abort.

[Bug fortran/82865] Option -fdec collides with PDT

[foreese at gcc dot gnu.org]

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

--- Comment #12 from Fritz Reese  ---
Author: foreese
Date: Fri Jun 29 20:29:34 2018
New Revision: 262260

URL: https://gcc.gnu.org/viewcvs?rev=262260=gcc=rev
Log:
Revert r262224 (backport of r262221) as PDTs are not supported in 7-branch.

gcc/fortran/ChangeLog:
-2018-06-28  Fritz Reese  
-
-   PR fortran/82865
-   Backport from trunk.
-   * decl.c (gfc_match_type): Refactor and check for PDT declarations.
-

gcc/testsuite/ChangeLog:
-2018-06-28  Fritz Reese  
-
-   PR fortran/82865
-   Backport from trunk.
-   * gfortran.dg/dec_type_print_2.f03: New testcase.
-

Removed:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
Modified:
branches/gcc-7-branch/   (props changed)
branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb   (props changed)
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb   (props changed)

Propchange: branches/gcc-7-branch/
('svn:mergeinfo' modified)

Propchange: branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb
('svn:mergeinfo' modified)

Propchange: branches/gcc-7-branch/gcc/testsuite/gnat.dg/opt65.adb
('svn:mergeinfo' modified)

[Bug testsuite/86365] Backported fortran test case gfortran.dg/dec_type_print_2.f03 in r262224 problems

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

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

--- Comment #2 from Fritz Reese  ---
Reverted in r262260

[Bug lto/86366] New: [9 regression] gcc.dg/profile-dir-3.c fails starting with r262251

[seurer at gcc dot gnu.org]

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

Bug ID: 86366
   Summary: [9 regression] gcc.dg/profile-dir-3.c fails starting
with r262251
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

make -k check-gcc RUNTESTFLAGS=dg.exp=gcc.dg/profile-dir-3.c
. . .
# of expected passes1
# of unexpected failures1
FAIL: gcc.dg/profile-dir-3.c scan-ipa-dump cgraph " ./profile-dir-3.gcda"



r262251 | marxin | 2018-06-29 09:03:36 -0500 (Fri, 29 Jun 2018) | 11 lines

When using -fprofile-generate=/some/path mangle absolute path of file (PR
lto/85759).

2018-06-29  Martin Liska  

PR lto/85759
* coverage.c (coverage_init): Mangle full path name.
* doc/invoke.texi: Document the change.
* gcov-io.c (mangle_path): New.
* gcov-io.h (mangle_path): Likewise.
* gcov.c (mangle_name): Use mangle_path for path mangling.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ -fno-diagnostics-show-caret
-fdiagnostics-color=never -c -o uclibc58792.o uclibc58792.c
uclibc58792.c:4:3: error: #error !__UCLIBC__
compiler exited with status 1
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ profiling58792.c   
-fno-diagnostics-show-caret -fdiagnostics-color=never  -pg  -lm  -o
profiling58792.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ profiling58792.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -pg -lm -o
profiling58792.exe
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/profile-dir-3.c   
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O -fprofile-generate
-fprofile-dir=. -fdump-ipa-cgraph -S -o profile-dir-3.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/profile-dir-3.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -fprofile-generate
-fprofile-dir=. -fdump-ipa-cgraph -S -o profile-dir-3.s
PASS: gcc.dg/profile-dir-3.c (test for excess errors)
FAIL: gcc.dg/profile-dir-3.c scan-ipa-dump cgraph " ./profile-dir-3.gcda"

[Bug c++/86361] Compilation failed while other compiler(clang) able to compile code in question

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Changed in r253265 but clang++ also accepts it.

[Bug c++/86359] Internal error when compiling lambda with constexpr and function with variadic arguments

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
Fixed by r261121 which was backported to 8, too.

[Bug testsuite/86365] Backported fortran test case gfortran.dg/dec_type_print_2.f03 in r262224 problems

[foreese at gcc dot gnu.org]

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

Fritz Reese  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-29
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Fritz Reese  ---
Oops, I forgot PDTs are not implemented as of gfortran-7. I will revert this
patch on 7-branch.

[Bug c++/86208] [6/7/8/9 Regression] improper handling of an extern declared inline function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
The reason why it worked in 3.2 is I think the keeping of inline function
bodies was keyed on TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))) at
those times, so when emitting assembly for the main function
TREE_SYMBOL_REFERENCE has been set and when checking up deferred_fns later on
the function was seen as DECL_NEEDED_P.

Seems contemporary gcc replaces the call to the local extern decl with the
actual inline fn definition in:
  /* Map block scope extern declarations to visible declarations with the
 same name and type in outer scopes if any.  */
  if (cp_function_chain->extern_decl_map
  && VAR_OR_FUNCTION_DECL_P (stmt)
  && DECL_EXTERNAL (stmt))
{
  struct cxx_int_tree_map *h, in;
  in.uid = DECL_UID (stmt);
  h = cp_function_chain->extern_decl_map->find_with_hash (, in.uid);
  if (h)
{
  *stmt_p = h->to;
  *walk_subtrees = 0;
  return NULL;
}
}

Now, if I do e.g. TREE_USED (h->to) |= TREE_USED (stmt);, the textcase works.
Not really sure if we should call mark_used here instead, or if e.g. mark_used
should use the cp_function_chain->extern_decl_map and mark not just the symbol
itself, but the hash table h->to too, whatever.  I guess it matters e.g. for
deprecated attribute, if we have:
__attribute__((deprecated ("foo"))) void foo () {}
void bar ()
{
  extern void foo ();
  foo ();
}
do we want to warn or not?

[Bug testsuite/86365] New: Backported fortran test case gfortran.dg/dec_type_print_2.f03 in r262224 problems

[seurer at gcc dot gnu.org]

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

Bug ID: 86365
   Summary: Backported fortran test case
gfortran.dg/dec_type_print_2.f03 in r262224 problems
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Is this trying to do something not supported by the fortran compiler in gcc 7?

make -k check-gcc RUNTESTFLAGS=dg.exp=gfortran.dg/dec_type_print_2.f03
. . .
# of unexpected failures6
FAIL: gfortran.dg/dec_type_print_2.f03   -O0  (test for excess errors)
FAIL: gfortran.dg/dec_type_print_2.f03   -O1  (test for excess errors)
FAIL: gfortran.dg/dec_type_print_2.f03   -O2  (test for excess errors)
FAIL: gfortran.dg/dec_type_print_2.f03   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gfortran.dg/dec_type_print_2.f03   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/dec_type_print_2.f03   -Os  (test for excess errors)


r262224 | foreese | 2018-06-28 11:51:23 -0500 (Thu, 28 Jun 2018) | 15 lines

2018-06-28  Fritz Reese  

gcc/testsuite/ChangeLog:

PR fortran/82865
Backport from trunk.
* gfortran.dg/dec_type_print_2.f03: New testcase.

gcc/fortran/ChangeLog:

PR fortran/82865
Backport from trunk.
* decl.c (gfc_match_type): Refactor and check for PDT declarations.


spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-7/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-7/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-7/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fdec -fcheck=all
-B/home/seurer/gcc/build/gcc-7/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-7/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-7/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-7/powerpc64-unknown-linux-gnu/./libatomic/.libs
-lm -o ./dec_type_print_2.exe
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:12:2:
Error: Unclassifiable statement at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:13:12:
Error: Invalid character in name at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:14:12:
Error: Invalid character in name at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:15:16:
Error: Symbol 'i' at (1) already has basic type of INTEGER
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:16:17:
Error: Symbol 'a' at (1) has no IMPLICIT type
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:18:5:
Error: Expecting END PROGRAM statement at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:20:13:
Error: Derived type 'mytype' at (1) is being used before it is defined
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:21:13:
Error: Derived type 'mytype' at (1) is being used before it is defined
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:23:2:
Error: Unclassifiable statement at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:24:2:
Error: Unclassifiable statement at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:25:2:
Error: Unclassifiable statement at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:26:2:
Error: Unclassifiable statement at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:27:2:
Error: Unclassifiable statement at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:28:2:
Error: Unclassifiable statement at (1)
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:30:5:
Error: Symbol 'z2' at (1) has no IMPLICIT type
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:31:5:
Error: Symbol 'z2' at (1) has no IMPLICIT type
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:38:15:
Error: Derived type 'mytype' at (1) is being used before it is defined
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:39:12:
Error: Symbol 'arg' at (1) has no IMPLICIT type
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:40:20:
Error: Symbol 'arg' at (1) has no IMPLICIT type
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:41:24:
Error: Symbol 'arg' at (1) has no IMPLICIT type
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:42:17:
Error: Symbol 'arg' at (1) has no IMPLICIT type
/home/seurer/gcc/gcc-7/gcc/testsuite/gfortran.dg/dec_type_print_2.f03:43:20:
Error: 

[Bug c++/86355] Internal compiler error with pack expansion and fold expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
The new ICE started with r249080.

[Bug c++/86355] Internal compiler error with pack expansion and fold expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
An ICE started with r245340 but that was a different one:

internal compiler error: Segmentation fault
 using check2 = mp_all..., mp_all<>>>;
 ^
0x11217ce crash_signal
../../gcc/toplev.c:333
0x769197 standard_conversion
../../gcc/cp/call.c:1109
0x76bf97 implicit_conversion
../../gcc/cp/call.c:1839
0x77417d build_integral_nontype_arg_conv(tree_node*, tree_node*, int)
../../gcc/cp/call.c:4023
0x8088e8 convert_nontype_argument
../../gcc/cp/pt.c:6484
0x80d0c6 convert_template_argument
../../gcc/cp/pt.c:7649
0x80eb7a coerce_template_parms
../../gcc/cp/pt.c:8109
0x80f100 coerce_innermost_template_parms
../../gcc/cp/pt.c:8214
0x81180a lookup_template_class_1
../../gcc/cp/pt.c:8633
0x814422 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:8979
0x820abf tsubst_aggr_type
../../gcc/cp/pt.c:11856
0x829507 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13354
0x81c6e1 tsubst_template_arg
../../gcc/cp/pt.c:10764
0x81fb30 tsubst_template_args
../../gcc/cp/pt.c:11647
0x81f902 tsubst_template_args
../../gcc/cp/pt.c:11629
0x82b2fc tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13695
0x828e22 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13298
0x826cc1 tsubst_decl
../../gcc/cp/pt.c:12767
0x828b92 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13272
0x8439ca instantiate_template_1
../../gcc/cp/pt.c:18087
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/86355] Internal compiler error with pack expansion and fold expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Reduced:

namespace std {
template  struct integral_constant {
  static constexpr _Tp value = __v;
};
template  struct is_constructible;
template  struct is_same : integral_constant
{};
} // namespace std
template  using mp_bool = std::integral_constant;
using mp_true = mp_bool;
template  using mp_all = mp_bool<(T::value && ...)>;
template 
using check2 = mp_all..., mp_all<>>>;
static_assert(std::is_same, mp_true>::value);

[Bug libstdc++/86138] [7/8 Regression] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
(In reply to Christian Franke from comment #25)
> (In reply to Jonathan Wakely from comment #23)
> > What if you test with -D_GLIBCXX_ASSERTIONS ?
> > 
> > (I expect you'll get a crash for either c++14 or c++17)
> 
> Yes.

Good - at least things are working (or not working)  as expected :-)

> Fixed with patch from r262167.

Great, thanks again.

[Bug plugins/86358] Plugin extension not stripped on Mac OS due to use of strip_off_ending()

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed by looking in opts.c that strip_off_ending() works like that. I'm
guessing it should probably check for nul-termination rather than hardcoding a
limit.

[Bug c++/86353] g++7 -std=c++17 ICEs as internal compiler error: in gimplify_expr, at gimplify.c:12201

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
...which doesn't look like something we should backport to 7.

[Bug c++/86353] g++7 -std=c++17 ICEs as internal compiler error: in gimplify_expr, at gimplify.c:12201

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Fixed with r258755.

[Bug c++/86208] [6/7/8/9 Regression] improper handling of an extern declared inline function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I can confirm this worked fine even at -O0 in 3.2.3, but in 3.3 or as early as
r7 it was already broken again.  Can't easily bisect that old compilers
though.

Looking for Partners

[ESSE - 27 Years of Experience in Security Systems]

 Email not displaying correctly? View it in your browser | Share it
 You are seeing this Email in Plain Text Version; Switch to HTML or Click this 
link http://dits.ws/a/43002 to View it properly.

 
 
http://www.me-trk.com/url/u8nGvGl8lXiHmHF2j8vKzICxt7y5gcK3cXaPesa9wcCtrZGHiIJ8dg==
  i...@esse.me 

 Subscription Information:
 This email was sent to gcc-bugs@gcc.gnu.org because you are Subscribed to 
Kuwait List
 Click Here to permanently Unsubscribe from this List.

 Sent to you by:
 DIGITAL ITS | Tel: +961 5 464 323

 
 

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[jsberg at bnl dot gov]

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

--- Comment #11 from jsberg at bnl dot gov ---
Presumably the "repeat count too large" test fails.

The basic requirement is that the number of input values cannot exceed the
number of number of items in the designator to the left; the repeat count
contributes to the total number of input values. Thus somewhere in the parsing
logic there should be some code computing the size of the designator and some
code computing the number of input values. It appears that the problem is in
gfortran not seeing ta(1:8)%c as being an array section for the purpose of this
count. But the count check needs to happen somewhere, if that test case in
namelist_19.f90 fails then the excess number of input values is not getting
flagged. Without the count check, do the right values get loaded into the
array?

[Bug tree-optimization/86364] strnlen before strlen of same argument not folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P4
 Blocks||83819

--- Comment #1 from Martin Sebor  ---
It's probably unlikely that both strlen and strnlen will be called on the same
argument so this optimization is of minor importance (I noticed it while
analyzing a link failure in one of the strnlen tests on a Solaris 10 system
with no strnlen implementation).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug tree-optimization/86364] New: strnlen before strlen of same argument not folded

[msebor at gcc dot gnu.org]

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

Bug ID: 86364
   Summary: strnlen before strlen of same argument not folded
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When a strlen() call is followed by strnlen() with the same argument of unknown
length GCC folds the latter call into a MIN_EXPR involving the bound and the
length computed by the strlen() call.

But when the order of the two calls is reversed, GCC doesn't perform the same
optimization, even though in principle it could by reordering the two calls and
starting with strlen() instead.

$ cat c.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout c.c
char a[] = "12345";

__attribute__ ((noipa))
int f1 (void)
{
  int n0 = __builtin_strlen (a);   // call (unavoidably) emitted
  int n1 = __builtin_strnlen (a, 1);   // folded into a MIN_EXPR

  return n0 + n1;
}

__attribute__ ((noipa))
int f2 (void)
{
  int n0 = __builtin_strnlen (a, 1);   // not folded
  int n1 = __builtin_strlen (a);   // call emitted

  return n0 + n1;
}

;; Function f1 (f1, funcdef_no=0, decl_uid=1899, cgraph_uid=1, symbol_order=1)

__attribute__((noipa, noinline, noclone, no_icf))
f1 ()
{
  int n1;
  int n0;
  long unsigned int _1;
  long unsigned int _2;
  int _6;

   [local count: 1073741825]:
  _1 = __builtin_strlen ();
  n0_4 = (int) _1;
  _2 = MIN_EXPR <_1, 1>;
  n1_5 = (int) _2;
  _6 = n0_4 + n1_5;
  return _6;

}



;; Function f2 (f2, funcdef_no=1, decl_uid=1904, cgraph_uid=2, symbol_order=2)

__attribute__((noipa, noinline, noclone, no_icf))
f2 ()
{
  int n1;
  int n0;
  long unsigned int _1;
  long unsigned int _2;
  int _6;

   [local count: 1073741825]:
  _1 = __builtin_strnlen (, 1);
  n0_4 = (int) _1;
  _2 = __builtin_strlen ();
  n1_5 = (int) _2;
  _6 = n0_4 + n1_5;
  return _6;

}

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #16 from Eric Gallager  ---
(In reply to Eric Gallager from comment #15)
> In bug 55860 Jeff said he reviews all of these each release, so ASSIGNED to
> him.

...and status actually changed to ASSIGNED this time.

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #15 from Eric Gallager  ---
In bug 55860 Jeff said he reviews all of these each release, so ASSIGNED to
him.

[Bug tree-optimization/55860] Turn segmented iteration into nested loops

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Assignee|law at redhat dot com  |unassigned at gcc dot 
gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Jeffrey A. Law from comment #6)
> Doesn't matter much to me either way.  I review all the jump threading PRs
> every release.

OK, so if this is just on the same level as all the other jump threading PRs, I
don't think that sounds very ASSIGNED compared to the rest of them... removed.

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
I am back on this.  If I simply remove the check for repeat count the case
given runs fine.  The original code doing this check goes way back in history
and there is one case in namelist_19.f90 that fails without the check.

I need some feedback. Is there ever a case where a repeat count is too large?
It seems that it would be interpreted simply as more data available then needed
and if this results in a mismatch of types during a read this would just
naturally give an error elsewhere. Therefore, the check should just go away.

Feedback appreciated.

[Bug c++/86184] Conditional expression with omitted operand cannot use rvalue of type convertible to bool

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug c++/86184] Conditional expression with omitted operand cannot use rvalue of type convertible to bool

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Fri Jun 29 15:25:14 2018
New Revision: 262254

URL: https://gcc.gnu.org/viewcvs?rev=262254=gcc=rev
Log:
PR c++/86184
* tree.c (cp_save_expr): Don't call save_expr for TARGET_EXPRs.

* g++.dg/ext/cond3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/cond3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/86363] New: [9 Regression] wrong code with __builtin_memset() at -O1

[zsojka at seznam dot cz]

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

Bug ID: 86363
   Summary: [9 Regression] wrong code with __builtin_memset() at
-O1
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 44338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44338=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-262240-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-262240-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
gcc version 9.0.0 20180629 (experimental) (GCC)

[Bug ipa/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
And in the previous dump (fixup_cfg1), we have

   :
  __len = D.127713;
  __builtin_va_end (&__args);
  std::allocator::allocator ();
  _1 = (sizetype) __len;
  _2 = __s + _1;
  std::__cxx11::basic_string::basic_string (, __s, _2,
);

So I'd say that it is either gimplification or SSA creation that does
not handle this situation correctly.

[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable component and proc-ptr component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||pault at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #6 from Dominique d'Humieres  ---
> Actually the variant in comment #2 worked up to (and including) version 6.4,
> but also fails with version 7 and updward.

The ICE appeared between revisions r254227 (2017-10-30, OK) and r254498
(2017-11-07, ICE) and has been back-ported to the gcc7 branch, but not to the
gcc6 one: candidate r254427 (pr81447, pr82783)?

[Bug ipa/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
As early as the ssa dump we have, in the same function,

   :
  __len_13 = _12;
  __builtin_va_end (&__args);
  std::allocator::allocator ();
  _1 = (sizetype) __len_13;
  _2 = __s_7 + _1;
  std::__cxx11::basic_string::basic_string (_16(D), __s_7, _2,
);

i.e. construction of basic_string at an undefined address.

[Bug tree-optimization/55860] Turn segmented iteration into nested loops

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
Doesn't matter much to me either way.  I review all the jump threading PRs
every release.

[Bug ipa/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
After a more careful look: The testcase from comment #5 calls
__builtin_alloca(1) and then tries to vnsprintf into that memory, so I
decided I'd go back to the original testcase.

It indeed does segfaults when IPA-CP takes place, but it seems there
is already undefined behavior in what IPA-CP sees as its input,
looking into release_ssa tree dump:

__gnu_cxx::__to_xstring, char> (int (*)
(char *, size_t, const char *, struct  *) __convf, size_t __n, const char *
__fmt)
{
  struct forward_iterator_tag D.128814;
  struct  __args[1];
  char * __s;
  sizetype _1;
  char * _2;
  const int _11;
  char[16] * _15;

   [local count: 1073741825]:
  __s_6 = __builtin_alloca (__n_4(D));
  __builtin_va_start (&__args, 0);
  _11 = __convf_8(D) (__s_6, __n_4(D), __fmt_9(D), &__args);
  __builtin_va_end (&__args);
  _1 = (sizetype) _11;
  _2 = __s_6 + _1;
  _15 = &_13(D)->D.22460._M_local_buf;
  MEM[(struct _Alloc_hider *)_13(D)]._M_p = _15;
  std::__cxx11::basic_string::_M_construct (_13(D), __s_6, _2,
D.128814);
  __args ={v} {CLOBBER};
  return _13(D);
}

The two lines:

  _15 = &_13(D)->D.22460._M_local_buf;
  MEM[(struct _Alloc_hider *)_13(D)]._M_p = _15;

clearly take some value out of thin air and then store into it into a
random place and (in the subsequent call), the address of that random
place is passed to some constructor...  after inlining, the
default-defs proliferate even some more.

[Bug debug/78685] -Og generates too many ""s

[fredrik at dolda2000 dot com]

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

--- Comment #11 from Fredrik Tolf  ---
(In reply to Richard Biener from comment #10)
> That is, it is reasonable to lose track of z in
> 
>   int a = (x + z) + b;
> 
> but only after x + z is computed.

Just for the record, I disagree that it's okay to lose z after that. As I
explained in #85059, not having access to variable values after they've been
consumed is one of the absolute main reasons I never use -Og.

[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable component and proc-ptr component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[6/7/8/9 Regression] [OOP]  |[6/7/8/9 Regression] [OOP]
   |ICE for derived type with   |ICE for derived type with
   |allocatable class component |allocatable component and
   ||proc-ptr component

--- Comment #5 from janus at gcc dot gnu.org ---
Actually the variant in comment #2 worked up to (and including) version 6.4,
but also fails with version 7 and updward.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

--- Comment #22 from Martin Liška  ---
Author: marxin
Date: Fri Jun 29 14:03:36 2018
New Revision: 262251

URL: https://gcc.gnu.org/viewcvs?rev=262251=gcc=rev
Log:
When using -fprofile-generate=/some/path mangle absolute path of file (PR
lto/85759).

2018-06-29  Martin Liska  

PR lto/85759
* coverage.c (coverage_init): Mangle full path name.
* doc/invoke.texi: Document the change.
* gcov-io.c (mangle_path): New.
* gcov-io.h (mangle_path): Likewise.
* gcov.c (mangle_name): Use mangle_path for path mangling.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/doc/invoke.texi
trunk/gcc/gcov-io.c
trunk/gcc/gcov-io.h
trunk/gcc/gcov.c

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

[ian at airs dot com]

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

--- Comment #10 from Ian Lance Taylor  ---
Thanks.  The documentation for the syscall function say that it only sets errno
on failure, but I forgot about signal handlers.  That is definitely a problem. 
Since there is no generic way to detect whether a system call failed, this may
require libgo to provide assembly language versions of syscall.Syscall.

[Bug debug/86362] New: Members of enum class in .debug_gnu_pubnames without scope, leading to gdbindex issues

[loic.yhuel at gmail dot com]

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

Bug ID: 86362
   Summary: Members of enum class in .debug_gnu_pubnames without
scope, leading to gdbindex issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: loic.yhuel at gmail dot com
  Target Milestone: ---

Enum class values are added to .debug_gnu_pubnames without scope, which leads
to conflicts in gdbindex when there are classes with the same name (for example
WebCore::Frame class and WebCore::ObjectContentType::Frame enum class value in
WebKit). Then gdb isn't able to get the correct type info for the class.

I think .debug_gnu_pubnames in bar.o should either :
 - don't have the enum class value (gdb seems to be able to get it looking at
the enum class debuginfo)
 - have it with the class scope

foo.cpp :
class Foo {
Foo();
};
// make sure g++ will put class type in debug info
// .debug_gnu_pubtypes will contain "g,type Foo"
Foo::Foo()
{
}

bar.cpp :
enum class Bar {
Foo
};
// .debug_gnu_pubnames will contain "g,variable Foo" !
Bar var = Bar::Foo;


g++ -gsplit-dwarf -c foo.cpp -o foo.o
g++ -gsplit-dwarf -c bar.cpp -o bar.o
g++ -fuse-ld=gold -shared -o lib.so -Wl,--gdb-index bar.o foo.o

=> "readelf --debug-dump=gdb_index lib.so" shows :
[661] Foo:
0 [global, variable]
1 [global, type]

In gdb, "ptype Foo" returns "No symbol "Foo" in current context." (due to
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff;f=gdb/dwarf2read.c;h=c5c3b5c225493d52cd96ddd52d57244e02485128;hp=7e87ed9adde38402d707ac2bd7c3757ba87847a6;hb=8943b874760d9cf35b71890a70af9866e4fab2a6;hpb=6adcee1866fe6b700bc1cc5a9675479530af7205,
gdb only loads the first CU).
If I put foo.o before bar.o, it works since the CU are swapped.

With -g instead of -gsplit-dwarf, and gdb_index still generated by gold
[661] Foo:
0 [global, no info]
1 [global, no info]
=> "ptype Foo" correctly prints "class Foo ...", since symbol attributes aren't
present so the gdb loads both CUs

With -g instead of -gsplit-dwarf, and gdb_index generated by gdb
[661] Foo:
1 [global, type]
0 [global, variable]
=> "ptype Foo" correctly prints "class Foo ...", since the CU 1 is first
I don't know if it's by chance or not.

With clang, it generates .debug_pubnames/.debug_pubtypes by default, then gold
produces an empty index, and gdb loads both CU on start.
But with -ggnu-pubnames, I get .debug_gnu_pubnames/.debug_gnu_pubtypes, and an
index with only the class for "Foo".

[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable class component

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #3)
> Duplicate of/related to pr82969

Yes, I think this is the same problem.


> (pr66679?).

But this one certainly not.

[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable class component

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Duplicate of/related to pr82969 (pr66679?).

[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable class component

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Slightly reduced test case:

module test

   implicit none 

   type :: output
   end type

   type :: tester
  integer,  allocatable :: wrap
  procedure(proc1), pointer, nopass :: ptr
   end type

   abstract interface
  function proc1() result(uc)
 import :: output
 class(output), allocatable :: uc
  end function
   end interface

end

[Bug ipa/86274] [7/8/9 Regression] SEGFAULT when logging std::to_string(NAN)

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
The IPA (and first tree) dumps look all normal.  But even when I patch IPA-CP
to create a clone but not to modify it in any way, I still get the segfault. 
I'll look where we start diverging next.

[Bug fortran/86242] [6/7/8/9 Regression] [OOP] ICE for derived type with allocatable class component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-29
 CC||janus at gcc dot gnu.org
Summary|[F03] ICE for derived type  |[6/7/8/9 Regression] [OOP]
   |with allocatable class  |ICE for derived type with
   |component   |allocatable class component
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. Works for me with gfortran 4.6, but ICEs with all later versions,
thus it's a (rather old) regression.

With trunk I get:


 end module test

internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have function_type in gfc_class_data_get, at
fortran/trans-expr.c:191
0x5bb752 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/janus/gcc/trunk/gcc/tree.c:9355
0x75066b tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
/home/janus/gcc/trunk/gcc/tree.h:3157
0x75066b gfc_class_data_get(tree_node*)
/home/janus/gcc/trunk/gcc/fortran/trans-expr.c:191
0x732f06 structure_alloc_comps
/home/janus/gcc/trunk/gcc/fortran/trans-array.c:8863
0x754d67 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
/home/janus/gcc/trunk/gcc/fortran/trans-expr.c:8940
0x766cd1 gfc_trans_assignment_1
/home/janus/gcc/trunk/gcc/fortran/trans-expr.c:10275
0x717f65 trans_code
/home/janus/gcc/trunk/gcc/fortran/trans.c:1843
0x74ca15 gfc_generate_function_code(gfc_namespace*)
/home/janus/gcc/trunk/gcc/fortran/trans-decl.c:6469
0x71d119 gfc_generate_module_code(gfc_namespace*)
/home/janus/gcc/trunk/gcc/fortran/trans.c:
0x6cb8dd translate_all_program_units
/home/janus/gcc/trunk/gcc/fortran/parse.c:6112
0x6cb8dd gfc_parse_file()
/home/janus/gcc/trunk/gcc/fortran/parse.c:6328
0x714c2f gfc_be_parse_file
/home/janus/gcc/trunk/gcc/fortran/f95-lang.c:204

[Bug c++/86361] New: Compilation failed while other compiler(clang) able to compile code in question

[husen.hunedbhai.jiruwala at citi dot com]

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

Bug ID: 86361
   Summary: Compilation failed while other compiler(clang) able to
compile code in question
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: husen.hunedbhai.jiruwala at citi dot com
  Target Milestone: ---

Compilation for below code fails for all version of gcc except 8.1



#include

using namespace std;

int main()
{
   const int k = 10;

   // Capture k by value
   auto myl = [k] (int k) { cout << " ++k=" << ++k ; };
   myl(k+10);
} 


Below stackoverflow discussion suggests that it should not compile with gcc 8.1
as well.

https://stackoverflow.com/questions/51060581/why-this-code-fails-to-compile-with-gcc-4-8-5-while-it-compiles-fine-with-clang/51101002#51101002

So its either a bug in gcc 8.1 or all other version. please kindly check.

[Bug libstdc++/86138] [7/8 Regression] C++17: getline(istream, string) crashes on Cygwin because incompatible C++14 function is called

[franke at computer dot org]

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

--- Comment #25 from Christian Franke  ---
(In reply to Jonathan Wakely from comment #23)
> What if you test with -D_GLIBCXX_ASSERTIONS ?
> 
> (I expect you'll get a crash for either c++14 or c++17)

Yes.

Fixed with patch from r262167.


New Cygwin package gcc-7.3.0-3 includes r261873 but not r262167.

[Bug target/84481] [8/9 Regression] 429.mcf with -O2 regresses by ~6% and ~4%, depending on tuning, on Zen compared to GCC 7.2

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
Ahoj,
jeste jedna vec je to, ze by asi slo udelat konzervativni slejvani pro VPT -
testovat
jen jestli stejna hodnota vyhraje ve vsech runech co maji nenulovy count. To by
melo
byt stabilni vuci poradi.

Honza

[Bug target/84481] [8/9 Regression] 429.mcf with -O2 regresses by ~6% and ~4%, depending on tuning, on Zen compared to GCC 7.2

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Interesting. Do I understand that correctly that it's due to increasing
addresses of the 3 load instructions: 0x8(%rdx), 0x18(%rdx), 0x30(%rdx) vs.
0x18(%rdx) 0x30(%rdx) 0x8(%rdx) ?

[Bug debug/78685] -Og generates too many ""s

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Tom de Vries from comment #8)
> Created attachment 44333 [details]
> proof of concept patch
> 
> I ran into the same problem with guality test-case pr54200.c, which fails
> for Og.
> 
> The relevant part of the test-case is:
> ...
> int __attribute__((noinline,noclone))
> foo (int z, int x, int b)
> {
>   if (x == 1)
> {
>   bar ();
>   return z;
> }
>   else
> {
>   int a = (x + z) + b;
>   return a; /* { dg-final { gdb-test 20 "z" "3" } } */
> }
> }
> ...
> 
> The problem is that the '(x + z) + b' calculation has a temporary register
> which  gets allocated the register that holds 'z', so when we get to the
> gdb-test line, z is no longer available.
> 
> Using this patch I managed to print the correct value of z at the gdb-test
> line.
> 
> The patch uses clobbers in gimple to mark the out-of-scope point, purely
> because that's similar to what was already done for local array variables,
> and I thought that was the fastest path to getting a proof of concept
> working. It's more accurate to model this as some sort of use in gimple, and
> doing so may prevent gimple optimizations which wreck debug info, but
> perhaps that's not necessary, I suppose that depends on which optimizations
> are enabled in Og.
> 
> Anyway, at expand we emit a use for the clobber which seems to do the trick.

An interesting idea but I think this will cause excessive spilling and
come at a compile-time cost.  The idea of -Og was to have performance
closer to -O1 here and with this we approach -O0 in assigning stack slots
to all user variables?

This is a general conflict of interest of course.

Your patch shouldn't prevent any optimization at the GIMPLE level
(like completely eliding local variables) but definitely they'll keep
things live at RTL level.  Given for the testcase at hand the issue
is "suboptimal" choice of register allocation I wonder if we can
adjust the RA / DF to consider liveness to extend always up to the
next sequence point.

That is, it is reasonable to lose track of z in

  int a = (x + z) + b;

but only after x + z is computed.  So a different approach would be
to see this as an issue with the way debug consumers "step" now that
we emit column debug information?

That said, starting with GCC 8 we now have # DEBUG BEGIN_STMT
markers:

   [local count: 856416479]:
  # DEBUG BEGIN_STMT
  _1 = x_4(D) + z_7(D);
  a_9 = _1 + b_8(D);
  # DEBUG a => a_9
  # DEBUG BEGIN_STMT

they are also present on RTL as

(debug_insn 21 20 0 (debug_marker) "t.c":11 -1
 (nil))

which means we _could_ somehow use those for code-generation (in DF analysis
to extend lifetimes somehow).  Of course if we do we have to emit those
always to not get code-gen differences -g vs. -g0.

Maybe the RA could also be generally changed to use a not-LRU style
preferencing of available registers to choose from.

In the end nothing saves us from "spilling" things if we really want to
be able to access all final values of registers up to the point they
go out of scope...

So another idea would be instead of like -O0 assigning the main location
to the stack we spill no longer used vars during LRA?  We'd still have to
somehow know until when that spill slot needs to live (and afterwards can
be re-used).

[Bug tree-optimization/86263] [9 Regression] [nvptx] casesi, tablejump

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Should be fixed now.

[Bug tree-optimization/86263] [9 Regression] [nvptx] casesi, tablejump

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Fri Jun 29 10:57:00 2018
New Revision: 262247

URL: https://gcc.gnu.org/viewcvs?rev=262247=gcc=rev
Log:
Fix bit-test expansion for single cluster (PR tree-optimization/86263).

2018-06-29  Martin Liska  

PR tree-optimization/86263
* tree-switch-conversion.c
(switch_decision_tree::try_switch_expansion):
Make edge redirection.
2018-06-29  Martin Liska  

PR tree-optimization/86263
* gcc.dg/tree-ssa/pr86263.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr86263.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-switch-conversion.c

[Bug driver/86357] -falign-{functions,loops,jumps} incorrectly reported as disabled by -Q --help=optimizers

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c/86360] "inline" (and neither static nor extern) function not emitted.

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to David Woodhouse from comment #5)
> Well, it's *allowed* to emit it inline. But if it doesn't then it mustn't
> emit it out-of-line. At least, from your citation, it mustn't emit it
> out-of-line such that it can be seen from another translation unit.
> 
> I'm not sure if it would be permitted for a compiler to emit that function
> as a static (but out-of-line) function.

It's allowed to, yes. It could produce a definition with internal linkage and
make the call go to that, which would not depend on an external definition
existing elsewhere.

"An inline definition provides an alternative to an external definition, which
a translator may use to implement any call to the function in the same
translation unit. It is unspecified whether a call to the function uses the
inline definition or the external definition."

Using the inline definition doesn't actually require any code to be inlined
into the caller, it could just emit a definition with internal linkage and emit
a call to that instead.

> Perhaps if there's no extern
> definition of the same function, that might be a reasonable thing for a
> compiler to do?

Yes. It would avoid a linker error if there is no corresponding extern
definition elsewhere in the program.

I think in practice what GCC does is either inline the code into the caller
(but only when optimization is enabled) or emit a call to an extern function
(which then needs to exist).

> But frankly I don't care much either. I already submitted a patch to make
> the code that offended me use 'static inline', and although I allowed myself
> to be talked into filing this PR I'm more than happy just to point at the
> response and say "no, my initial analysis was correct".

Agreed.

[Bug c/86360] "inline" (and neither static nor extern) function not emitted.

[dwmw2 at infradead dot org]

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

--- Comment #5 from David Woodhouse  ---
Well, it's *allowed* to emit it inline. But if it doesn't then it mustn't emit
it out-of-line. At least, from your citation, it mustn't emit it out-of-line
such that it can be seen from another translation unit.

I'm not sure if it would be permitted for a compiler to emit that function as a
static (but out-of-line) function. Perhaps if there's no extern definition of
the same function, that might be a reasonable thing for a compiler to do?

But frankly I don't care much either. I already submitted a patch to make the
code that offended me use 'static inline', and although I allowed myself to be
talked into filing this PR I'm more than happy just to point at the response
and say "no, my initial analysis was correct".

Thanks again.

[Bug c/86360] "inline" (and neither static nor extern) function not emitted.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
More than that, I don't think it's allowed to. See 6.7.4 p7 in the C11
standard.

"An inline definition does not provide an external definition for the function,
and does not forbid an external definition in another translation unit."

[Bug c/86360] "inline" (and neither static nor extern) function not emitted.

[dwmw2 at infradead dot org]

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

--- Comment #3 from David Woodhouse  ---
Thanks for the prompt response.

I'll stick with my original "compiler isn't required to emit" comment in my
referenced patch submission, which everyone had questioned...

[Bug c/86360] "inline" (and neither static nor extern) function not emitted.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Use -std=gnu90 to get GNU 90 semantics, and a definition emitted.

See "Different semantics for inline functions" at
https://gcc.gnu.org/gcc-5/porting_to.html for more details.

[Bug c/86360] "inline" (and neither static nor extern) function not emitted.

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
"The remainder of this section is specific to GNU C90 inlining." and you're
compiling with the defaultoptions, which means -std=gnu99 so you get C99
inlining.

[Bug c/86360] New: "inline" (and neither static nor extern) function not emitted.

[dwmw2 at infradead dot org]

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

Bug ID: 86360
   Summary: "inline" (and neither static nor extern) function not
emitted.
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dwmw2 at infradead dot org
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc/Inline.html says:

> When an inline function is not static, then the compiler must assume
> that there may be calls from other source files; since a global symbol
> can be defined only once in any program, the function must not be defined
> in the other source files, so the calls therein cannot be integrated. 
> Therefore, a non-static inline function is always compiled on its own
> in the usual fashion. 

Either I misunderstand that, or it isn't true:

$ cat foo.c

inline int foo(int a)
{
return a+1;
}

int main(int a)
{
return foo(a);
}

$ gcc -O0 -o- -S foo.c
.file   "foo.c"
.text
.globl  bar
.type   bar, @function
bar:
.LFB1:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
movl%edi, -4(%rbp)
movl-4(%rbp), %eax
movl%eax, %edi
callfoo
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.size   bar, .-bar
.ident  "GCC: (GNU) 8.1.1 20180502 (Red Hat 8.1.1-1)"
.section.note.GNU-stack,"",@progbits


Note the 'foo' function doesn't get emitted.

cf. https://github.com/openwrt/packages/pull/6377#issuecomment-401084671
http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001791.html

[Bug c++/86359] Internal error when compiling lambda with constexpr and function with variadic arguments

[vmario1986 at gmail dot com]

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

Mariusz Chilmon  changed:

   What|Removed |Added

 CC||vmario1986 at gmail dot com

--- Comment #1 from Mariusz Chilmon  ---
In GCC 7.3.0 Marcin's code works, though it should not because `number` is not
captured. In GCC 9.0.0 compiler returns correct message: `error: 'number' is
not captured`.

[Bug c++/86359] New: Internal error when compiling lambda with constexpr and function with variadic arguments

[marcin.zielinski at ctm dot gdynia.pl]

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

Bug ID: 86359
   Summary: Internal error when compiling lambda with constexpr
and function with variadic arguments
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.zielinski at ctm dot gdynia.pl
  Target Milestone: ---

Created attachment 44337
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44337=edit
File causing the compiler error, preprocessed

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.1.0-5'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.1.0 (Debian 8.1.0-5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-O0' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++17
-Wall -Wextra -O0 -fpch-preprocess -o main.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/8
 /usr/include/x86_64-linux-gnu/c++/8
 /usr/include/c++/8/backward
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-O0' '-Wall' '-Wextra'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -O0 -Wall -Wextra
-std=c++17 -version -o main.s
GNU C++17 (Debian 8.1.0-5) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Debian 8.1.0-5) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bc8e163ce69d2a6481afa8d39350e6bc
during RTL pass: expand
main.cpp: In lambda function:
main.cpp:13:30: internal compiler error: in make_decl_rtl, at varasm.c:1322
 printSomething("%d", number);
  ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug driver/86357] -falign-{functions,loops,jumps} incorrectly reported as disabled by -Q --help=optimizers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-29
Version|unknown |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Probably the option machinery / help code doesn't properly associate FOO and
FOO=
option variants like

falign-loops
Common Report Var(align_loops,0) Optimization UInteger
Align the start of loops.

falign-loops=
Common RejectNegative Joined UInteger Var(align_loops) Optimization

[Bug c++/86355] Internal compiler error with pack expansion and fold expression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||7.3.1, 8.1.1, 9.0

--- Comment #1 from Richard Biener  ---
Trunk:

t.C: In substitution of ‘template using check2 =
mp_all, std::integral_constant(T::value)  && ...)> > [with V = void; T = {int, float}]’:
t.C:10:52:   required from here
t.C:8:156: internal compiler error: Segmentation fault
 all..., mp_all...>>>;
  ^

0x12a3285 crash_signal
/space/rguenther/src/gcc-slpcost/gcc/toplev.c:324
0x76ac693f ???
   
/usr/src/debug/glibc-2.22/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xa76272 convert_nontype_argument
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:6652
0xa7b0e7 convert_template_argument
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:7999
0xa7cb25 coerce_template_parms
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:8481
0xa7d198 coerce_innermost_template_parms
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:8603
0xa7f69b lookup_template_class_1
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:9300
0xa81a61 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:9649
0xa8d8cc tsubst_aggr_type
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:12653
0xa976b7 tsubst(tree_node*, tree_node*, int, tree_node*)
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:14268
0xa890dc tsubst_template_arg
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:11410
0xa8cc10 tsubst_template_args
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:12444
0xa8cb12 tsubst_template_args
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:12434
0xa9903d tsubst(tree_node*, tree_node*, int, tree_node*)
/space/rguenther/src/gcc-slpcost/gcc/cp/pt.c:14603
...

[Bug c++/86353] g++7 -std=c++17 ICEs as internal compiler error: in gimplify_expr, at gimplify.c:12201

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-29
  Known to work||8.1.0
 Ever confirmed|0   |1
  Known to fail||7.3.1

--- Comment #1 from Richard Biener  ---
Confirmed on the GCC 7 branch head, works with GCC 8.  GCC 6 rejects it with

t.ii:9:1: error: invalid use of template-name ‘c’ without an argument list
 c e(1);
 ^
t.ii:4:30: note: ‘template struct c’ declared here
 template  struct c {
  ^

[Bug c++/86351] Array references as arguments to ternary operator

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
THus invalid.

[Bug fortran/86350] Missed optimization with multiplication by zero

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Maybe the frontend can adjust the defaults for -ffinite-math-only /
-fsigned-zeros in case the IEEE module is not in scope (or whatever constraints
apply here from the language standard). That certainly allows for more
optimization.

[Bug go/86331] the gccgo's "go" tool looks like failing to invoke any sub go command

[sch...@linux-m68k.org]

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

--- Comment #9 from Andreas Schwab  ---
In general, the value of errno is undefined unless you know the previous system
call failed.  In this case the SIGCHLD signal handler has modified errno.  This
has nothing to do with VM or arm64 or whatever.

[Bug c++/86296] Creating a pointer class for a unique_ptr<>() deleter fails with optimizations

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Ah I tested back to 7.3 but not 5.4

The _GLIBCXX_ASSERTIONS checks were added in GCC 6.1 and I don't think ASan
diagnosed stack-use-after-return in 5.x either.

[Bug c++/86296] Creating a pointer class for a unique_ptr<>() deleter fails with optimizations

[alexis at m2osw dot com]

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

--- Comment #5 from Alexis Wilke  ---
I tested again under Ubuntu 16.04 and 18.04.

Most everything doesn't work right under 16.04.

However, when I tested under 18.04, I got the same output as you. So I guess
there were problems in 5.x that have been resolved since.