[Bug c++/80984] [5/6/7/8 Regression] ICE with label/variable ambiguity

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-06
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r220650.

[Bug c++/80985] New: -Wnoexcept-type should not produce a warning for inlined template functions

[john at jlindgren dot net]

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

Bug ID: 80985
   Summary: -Wnoexcept-type should not produce a warning for
inlined template functions
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john at jlindgren dot net
  Target Milestone: ---

This simple C++ example generates a warning with gcc 7.1.1:

template
void call (Func f)
{
f ();
}

void func () noexcept
{
}

int main ()
{
call (func);
return 0;
}

$ g++ -std=c++11 -Wall -c test.cc
test.cc:2:6: warning: mangled name for ‘void call(Func) [with Func = void (*)()
noexcept]’ will change in C++17 because the exception specification is part of
a function type [-Wnoexcept-type]
 void call (Func f)
  ^~~~

IMHO this warning is a false positive.  The mangled name of call() doesn't
matter because it is a template function which is called from the same
compilation unit in which it is defined, and it will almost certainly be
inlined.  Please consider refining the triggers for -Wnoexcept-type so that it
does not produce a warning in a case like this one.

gcc-multilib 7.1.1-3 (Arch Linux)

$ gcc --version
gcc (GCC) 7.1.1 20170528

[Bug c++/80593] [7 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[daniel.black at au dot ibm.com]

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

Daniel Black  changed:

   What|Removed |Added

 CC||daniel.black at au dot ibm.com

--- Comment #10 from Daniel Black  ---
FYI I have tested from the gcc master (x86_64-pc-linux-gnu-g++ (GCC) 8.0.0
20170605 (experimental)) and it doesn't identify the the following bit of
rocksdb code as a warning where previously it did. So fixed for me on master.

./db/write_thread.h:227:78: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
   return
*static_cast<std::mutex*>(static_cast<void*>(_mutex_bytes));

ref: https://github.com/facebook/rocksdb/issues/2382

Still fails using the gcc at the head of the gcc-7-branch however

[Bug bootstrap/80897] gnat bootstrap broken on sparc64-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #3 from Eric Botcazou  ---
OK, I'll look into it.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

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

--- Comment #38 from Eric Botcazou  ---
> I’ve worked out a patch and bootstrapped (see attachment). The patch is 
> against the gcc-8-20170558 snapshot, would that be OK?

I'm no Darwin specialist so I cannot really comment, but my understanding is
that it cannot make things worse...  Please post it on gcc-patches@ if you
don't mind.

In any case, thanks for stepping in here.

> One thing I’m not sure of is what versions of Darwin this applies to. I’ve
> tested for *-apple-darwin*.

The Darwin maintainers will probably enlighten once they see the patch.

[Bug bootstrap/80897] gnat bootstrap broken on sparc64-linux-gnu

[matorola at gmail dot com]

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

--- Comment #2 from Anatoly Pugachev  ---
...
make[7]: Entering directory '/1/mator/gcc8/gcc/ada/rts'
make[7]: 'a-assert.o' is up to date.
/1/mator/gcc8/./gcc/xgcc -B/1/mator/gcc8/./gcc/ -B/1/gcc/sparc64-linux-gnu/bin/
-B/1/gcc/sparc64-linux-gnu/lib/ -isystem /1/gcc/sparc64-linux-gnu/include
-isystem /1/gcc/sparc64-linux-gnu/sys-include-c -g -O2  -fPIC  -W -Wall
-gnatpg -nostdinc   a-btgbso.adb -o a-btgbso.o
+===GNAT BUG DETECTED==+
| 8.0.0 20170604 (experimental) (sparc64-linux-gnu) Storage_Error stack
overflow or erroneous memory access|
| Error detected at s-finroo.ads:44:4  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

system.ads
a-btgbso.adb
a-btgbso.ads
a-crbltr.ads
a-contai.ads
ada.ads
a-conhel.ads
a-finali.ads
s-finroo.ads
s-atocou.ads
a-rbtgbo.ads
a-stream.ads
a-tags.ads
s-stoele.ads
s-exctab.ads
s-stalib.ads
a-unccon.ads
s-soflin.ads
a-except.ads
s-parame.ads
s-traent.ads
s-stache.ads

compilation abandoned
../gcc-interface/Makefile:296: recipe for target 'a-btgbso.o' failed
make[7]: *** [a-btgbso.o] Error 1
make[7]: Leaving directory '/1/mator/gcc8/gcc/ada/rts'
...

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
Hopefully the issue is the same as in PR 80974, which does have a testcase.

[Bug c++/80984] New: [5/6/7/8 Regression] ICE with label/variable ambiguity

[reichelt at gcc dot gnu.org]

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

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

The following valid code snippet triggers an ICE since GCC 5.1.0:

===
struct A
{
  ~A();
};

A foo()
{
  A a;
  a:
  return a;
}
===

bug.cc: In function 'A foo()':
bug.cc:11:1: internal compiler error: tree check: expected var_decl or
parm_decl or result_decl, have label_decl in cp_genericize, at
cp/cp-gimplify.c:1594
 }
 ^
0x1028c1c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9859
0x66927a tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/gcc/tree.h:3123
0x66927a cp_genericize(tree_node*)
../../gcc/gcc/cp/cp-gimplify.c:1594
0x6a6c52 finish_function(int)
../../gcc/gcc/cp/decl.c:15708
0x765e7e cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26296
0x74f8bd cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26202
0x74f8bd cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19168
0x76e92c cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12800
0x76f6c5 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12625
0x741b74 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12523
0x77753b cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12399
0x77781a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4364
0x77781a c_parse_file()
../../gcc/gcc/cp/parser.c:38475
0x8b9066 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1104
Please submit a full bug report, [etc.]

[Bug c++/79056] [7/8 Regression] [C++17] ICE with broken deduction guide / broken template parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||error-recovery
   Last reconfirmed|2017-01-30 00:00:00 |2017-06-05
Summary|[C++17] ICE with broken |[7/8 Regression] [C++17]
   |deduction guide |ICE with broken deduction
   ||guide / broken template
   ||parameter

--- Comment #3 from Volker Reichelt  ---
While Martin's example doesn't ICE for me, the following code snippet
crashes with a very similar stack trace (when using -std=c++1z).
Btw, it only takes a single space to make it valid:

===
template struct A {};

template void foo(A=A()) {}

void bar()
{
  foo(A());
}
===

PR79056.cc:3:41: error: template argument 1 is invalid
 template void foo(A=A()) {}
 ^
PR79056.cc:3:41: error: template argument 1 is invalid
PR79056.cc:3:41: error: template argument 1 is invalid
PR79056.cc:3:41: error: template argument 1 is invalid
PR79056.cc:3:31: internal compiler error: Segmentation fault
 template void foo(A=A()) {}
   ^
0xd724ef crash_signal
../../gcc/gcc/toplev.c:337
0x736779 cp_parser_check_for_invalid_template_id
../../gcc/gcc/cp/parser.c:2986
0x7390b5 cp_parser_check_for_invalid_template_id
../../gcc/gcc/cp/parser.c:2984
0x7390b5 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:16945
0x726c8d cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16499
0x727eda cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13330
0x742d25 cp_parser_parameter_declaration
../../gcc/gcc/cp/parser.c:21183
0x7435ec cp_parser_parameter_declaration_list
../../gcc/gcc/cp/parser.c:20999
0x743a5c cp_parser_parameter_declaration_clause
../../gcc/gcc/cp/parser.c:20922
0x72a471 cp_parser_direct_declarator
../../gcc/gcc/cp/parser.c:19645
0x72a471 cp_parser_declarator
../../gcc/gcc/cp/parser.c:19521
0x72278c cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19046
0x72381a cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:26719
0x7456dc cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26323
0x745364 cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:26558
0x745364 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:26577
0x74d589 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12449
0x74f0ab cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12376
0x74f38a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4366
0x74f38a c_parse_file()
../../gcc/gcc/cp/parser.c:38431
Please submit a full bug report, [etc.]

This makes it a regression for GCC 7.

[Bug c++/62207] [5/6/7/8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in tsubst_copy, at cp/pt.c

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords||ice-checking
   Last reconfirmed|2014-12-14 00:00:00 |2017-06-05
 CC||reichelt at gcc dot gnu.org
Summary|ICE: tree check: expected   |[5/6/7/8 Regression] ICE:
   |tree that contains 'decl|tree check: expected tree
   |minimal' structure, have|that contains 'decl
   |'overload' in tsubst_copy,  |minimal' structure, have
   |at cp/pt.c  |'overload' in tsubst_copy,
   ||at cp/pt.c

--- Comment #5 from Volker Reichelt  ---
Marc's code snippet can be reduced to the following invalid code snippet
that only generates one error before the ICE:

==
template void foo(T)
{
  X;
  X;
}

void X();
void X(int);

void bar()
{
  foo(0);
}
==

PR62207.cc: In function 'void foo(T)':
PR62207.cc:3:3: error: 'X' was not declared in this scope
   X;
   ^
PR62207.cc: In instantiation of 'void foo(T) [with T = int]':
PR62207.cc:12:8:   required from here
PR62207.cc:4:3: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'overload' in tsubst_copy, at
cp/pt.c:14628
   X;
   ^
0x1029944 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:10031
0x7b04b6 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3197
0x7b04b6 tsubst_copy
../../gcc/gcc/cp/pt.c:14628
0x7b5fc5 tsubst_copy
../../gcc/gcc/cp/pt.c:14483
0x7b5fc5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17806
0x7a6128 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16521
0x7a4d1b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15785
0x7a4327 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15998
0x7a1d90 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:22963
0x7e33fb instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23084
0x6ca018 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4511
Please submit a full bug report, [etc.]

This is a regression that appeared in GCC 5.1.0.

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski  ---
These started to fail on aarch64-*-* at the same time as powerpc.

[Bug c++/62170] wrong quoting (and colors) for typedef diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Candidate patch posted for review:
  https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00242.html

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[ian at airs dot com]

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

--- Comment #26 from Ian Lance Taylor  ---
This should let you run the test binary:

cd TARGET/libgo
make GOTESTFLAGS=--keep net/check
cd gotest*/test
LD_LIBRARY_PATH=../../.libs ./a.out -test.short

The test binary is simply a.out in the gotestN/test directory.  Run it with
the command line option -test.short to see exactly what happens when you run
`make check-target-libgo`.

[Bug libstdc++/80939] Various helper function templates in incorrectly marked constexpr

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun  5 16:49:04 2017
New Revision: 248881

URL: https://gcc.gnu.org/viewcvs?rev=248881=gcc=rev
Log:
PR libstdc++/80939 Remove unmeetable constexpr specifiers

PR libstdc++/80939
* include/std/variant (__erased_ctor, __erased_assign, __erased_swap)
(__erased_hash): Remove constexpr specifier and qualify calls to
__ref_cast.
(__erased_dtor): Remove constexpr specifier and use _Destroy.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug fortran/80983] [F03] memory leak when calling procedure-pointer component with allocatable result

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-05
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 5.4.0 up to trunk (8.0). I don't see any __builtin_free if I
compile the test with 4.9.

[Bug fortran/70601] [5/6/7/8 Regression] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
The ICE has been fixed on (8-)trunk. Backports pending.


(In reply to janus from comment #7)
> However, we probably still need to deal with PPCs that have allocatable
> function results.

This is now PR 80983.

[Bug fortran/80983] [F03] memory leak when calling procedure-pointer component with allocatable result

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |8.0
  Known to fail||5.4.1, 6.3.0, 7.1.1, 8.0

[Bug fortran/80983] New: [ F03] memory leak when calling procedure-pointer component with allocatable result

[janus at gcc dot gnu.org]

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

Bug ID: 80983
   Summary: [ F03] memory leak when calling procedure-pointer
component with allocatable result
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Follow-up to PR 70601 ...

The following program is compiled fine by gfortran, but exhibits a memory leak
on the PPC call at runtime:



program test
  implicit none

  type :: concrete_type
procedure (alloc_integer), pointer, nopass :: alloc
  end type

  procedure (alloc_integer), pointer :: pp

  type(concrete_type) :: concrete

  print *, alloc_integer() ! allocated memory is freed

  pp => alloc_integer
  print *, pp()! freed as well

  concrete % alloc => alloc_integer
  print *, concrete % alloc()  ! memory leak !!!

contains

   function alloc_integer() result(res)
  integer, allocatable :: res
  allocate(res, source=13)
   end function

end


Effectively this program calls the same function three times. But while freeing
the memory works fine for the direct call and the procedure-pointer call, the
PPC call misses the memory cleanup.

[Bug target/80982] gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64-unknown-linux-gnu
 CC||carll at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc64-unknown-linux-gnu
  Build||powerpc64-unknown-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
The failures occurred on power 6, 7, and 8.

[Bug target/80982] New: gcc.target/powerpc/builtins-3-runnable.c fails starting with its introduction in r248846

[seurer at gcc dot gnu.org]

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

Bug ID: 80982
   Summary: gcc.target/powerpc/builtins-3-runnable.c fails
starting with its introduction in r248846
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This fails only on BE

Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/builtins-3-runnable.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -mvsx
-mcpu=power8  -lm-o ./builtins-3-runnable.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/builtins-3-runnable.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -mvsx -mcpu=power8
-lm -o ./builtins-3-runnable.exe
/tmp/ccYc5Gcs.s: Assembler messages:
/tmp/ccYc5Gcs.s:123: Error: operand out of range (8 is not between 0 and 3)
/tmp/ccYc5Gcs.s:142: Error: operand out of range (8 is not between 0 and 3)
compiler exited with status 1
output is:
/tmp/ccYc5Gcs.s: Assembler messages:
/tmp/ccYc5Gcs.s:123: Error: operand out of range (8 is not between 0 and 3)
/tmp/ccYc5Gcs.s:142: Error: operand out of range (8 is not between 0 and 3)

FAIL: gcc.target/powerpc/builtins-3-runnable.c (test for excess errors)
Excess errors:
/tmp/ccYc5Gcs.s:123: Error: operand out of range (8 is not between 0 and 3)
/tmp/ccYc5Gcs.s:142: Error: operand out of range (8 is not between 0 and 3)

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[seurer at gcc dot gnu.org]

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

--- Comment #14 from seurer at gcc dot gnu.org ---
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect-33-big-array.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mpower8-vector
-ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details
-S -o vect-33-big-array.s
PASS: gcc.dg/vect/vect-33-big-array.c (test for excess errors)
PASS: gcc.dg/vect/vect-33-big-array.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/vect-33-big-array.c scan-tree-dump-times vect "Vectorizing an
unaligned access" 0
FAIL: gcc.dg/vect/vect-33-big-array.c scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect-33-big-array.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -flto -ffat-lto-objects
-maltivec -mpower8-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details -S   -o vect-33-big-array.s(timeout = 300)

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[seurer at gcc dot gnu.org]

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

--- Comment #13 from seurer at gcc dot gnu.org ---
Created attachment 41475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41475=edit
Dump from -fdump-tree-vect-details for test case
gcc.dg/vect/vect-33-big-array.c

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[seurer at gcc dot gnu.org]

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

--- Comment #12 from seurer at gcc dot gnu.org ---
Hmmm, they don't all fail on power6/7 (costmodel-pr37194.c for instance).  I
attached a dump from -fdump-tree-vect-details for one that does (power6).

[Bug other/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

[daibane at sandia dot gov]

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

Dan Ibanez  changed:

   What|Removed |Added

 CC||daibane at sandia dot gov

--- Comment #15 from Dan Ibanez  ---
It has been 10 years. This is still a problem in GCC 7.1.0.

Either fix it properly or add something that causes configure to fail when that
flag is specified.

10 years.

[Bug fortran/70601] [5/6/7/8 Regression] [OOP] ICE on procedure pointer component call

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Jun  5 14:43:01 2017
New Revision: 248878

URL: https://gcc.gnu.org/viewcvs?rev=248878=gcc=rev
Log:
2017-06-05  Janus Weil  

PR fortran/70601
* trans-expr.c (gfc_conv_procedure_call): Fix detection of allocatable
function results.


2017-06-05  Janus Weil  

PR fortran/70601
* gfortran.dg/proc_ptr_comp_50.f90: New test.

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

[Bug sanitizer/80932] UBSAN: false positive as a result of distribution: c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Better testcase (C and C++):

int x = 1;

long int
foo (void)
{
  return ((long) (13801962912760474560ULL * x) - (long)
(15334142073106273231ULL * x)) * -6;
}

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

[Bug sanitizer/80932] UBSAN: false positive as a result of distribution: c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Marek Polacek  ---
Should've been in ASSIGNED.

[Bug lto/80717] LTO wrappers segfault if run with absolute path

[anatol.pomozov at gmail dot com]

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

Anatol  changed:

   What|Removed |Added

 CC||anatol.pomozov at gmail dot com

--- Comment #3 from Anatol  ---
Hi, any progress with fixing this issue?

Arch users found that 'arduino' tool crashes because of this bug.
https://bugs.archlinux.org/task/54159

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

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

--- Comment #37 from simon at pushface dot org ---
Created attachment 41474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41474=edit
Patch to top-level configure.ac, configure

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[simon at pushface dot org]

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

--- Comment #36 from simon at pushface dot org ---
(In reply to Eric Botcazou from comment #35)

> The workaround is to filter out -static-libgcc in configure.ac on Darwin but
> to leave -static-libstdc++, so why is it still looking for the shared
> libstdc++?

Because (as in comment 25) g++ linking on Darwin silently ignores 
-static-libstdc++ (if it sees -shared-libgcc). I've verified this 
with a C++ "hello world".

This PR is labelled 'target', is that right?

I’ve worked out a patch and bootstrapped (see attachment). The patch is 
against the gcc-8-20170558 snapshot, would that be OK?

One thing I’m not sure of is what versions of Darwin this applies to. I’ve
tested for *-apple-darwin*.

[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
If this patch is fixed, please remember to remove the extra
check in frontend-passes.c (traverse_io_block). Just grep
for 80945.

[Bug fortran/35339] Improve translation of implied do loop in transfer

[koenigni at gcc dot gnu.org]

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

--- Comment #12 from Nicolas Koenig  ---
Author: koenigni
Date: Mon Jun  5 12:35:11 2017
New Revision: 248877

URL: https://gcc.gnu.org/viewcvs?rev=248877=gcc=rev
Log:

2017-06-05  Nicolas Koenig  

PR fortran/35339
* frontend-passes.c (traverse_io_block): New function.
(simplify_io_impl_do): New function.
(optimize_namespace): Invoke gfc_code_walker with
simplify_io_impl_do.

2017-06-05  Nicolas Koenig  

PR fortran/35339
* gfortran.dg/implied_do_io_1.f90: New Test.
* gfortran.dg/implied_do_io_2.f90: New Test.



Added:
trunk/gcc/testsuite/gfortran.dg/implied_do_io_1.f90
trunk/gcc/testsuite/gfortran.dg/implied_do_io_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80981] [7/8 Regression] couldn't deduce template parameter for an obvious case

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Martin Liška from comment #1)
> Clang and older versions of GCC do accept that.

view-source:https://gcc.gnu.org/gcc-7/porting_to.html#hypothetical-instantiation

The error is entirely correct, there is no way a<>::b<> can ever be
instantiated to form a valid function, because b(a--) doesn't say which b it
means.

[Bug c++/80981] [7/8 Regression] couldn't deduce template parameter for an obvious case

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Thanks for the patch.

[Bug c++/80981] [7/8 Regression] couldn't deduce template parameter for an obvious case

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
For v8 you need the following patch:

diff --git a/src/objects-body-descriptors.h b/src/objects-body-descriptors.h
index 499c48a93034..3eb3bb539e4d 100644
--- a/src/objects-body-descriptors.h
+++ b/src/objects-body-descriptors.h
@@ -99,7 +99,7 @@ class FixedBodyDescriptor final : public BodyDescriptorBase {

   template 
   static inline void IterateBody(HeapObject* obj, int object_size) {
-IterateBody(obj);
+IterateBody(obj);
   }

   static inline int SizeOf(Map* map, HeapObject* object) { return kSize; }
diff --git a/src/objects-inl.h b/src/objects-inl.h
index 2eeac7f7e0bd..636be371d315 100644
--- a/src/objects-inl.h
+++ b/src/objects-inl.h
@@ -48,6 +48,27 @@
 namespace v8 {
 namespace internal {

+template 
+uint32_t HashTable::Hash(Key key) {
+  if (Shape::UsesSeed) {
+return Shape::SeededHash(key, GetHeap()->HashSeed());
+  } else {
+return Shape::Hash(key);
+  }
+}
+
+
+template 
+uint32_t HashTable::HashForObject(Key key,
+   Object* object) {
+  if (Shape::UsesSeed) {
+return Shape::SeededHashForObject(key, GetHeap()->HashSeed(), object);
+  } else {
+return Shape::HashForObject(key, object);
+  }
+}
+
+
 PropertyDetails::PropertyDetails(Smi* smi) {
   value_ = smi->value();
 }
diff --git a/src/objects/hash-table.h b/src/objects/hash-table.h
index 1a5d73eb4e30..1095d447a23d 100644
--- a/src/objects/hash-table.h
+++ b/src/objects/hash-table.h
@@ -138,22 +138,8 @@ class HashTable : public HashTableBase {
  public:
   typedef Shape ShapeT;

-  // Wrapper methods
-  inline uint32_t Hash(Key key) {
-if (Shape::UsesSeed) {
-  return Shape::SeededHash(key, GetHeap()->HashSeed());
-} else {
-  return Shape::Hash(key);
-}
-  }
-
-  inline uint32_t HashForObject(Key key, Object* object) {
-if (Shape::UsesSeed) {
-  return Shape::SeededHashForObject(key, GetHeap()->HashSeed(), object);
-} else {
-  return Shape::HashForObject(key, object);
-}
-  }
+  inline uint32_t Hash(Key key);
+  inline uint32_t HashForObject(Key key, Object* object);

   // Returns a new HashTable object.
   MUST_USE_RESULT static Handle New(

The first hunk fixes the issue. This is already fixed in node.js,
see: https://github.com/nodejs/node/issues/10388

[Bug c++/80981] [7/8 Regression] couldn't deduce template parameter for an obvious case

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
To not to forget about it, reopening. Feel free to close again if needed.

[Bug c++/80981] [7/8 Regression] couldn't deduce template parameter for an obvious case

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 41473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41473=edit
Original test-case

Attaching original test-case, where I get:

../../v8/src/objects-body-descriptors.h: In static member function ‘static void
v8::internal::FixedBodyDescriptor::IterateBody(v8::internal::HeapObject*, int)’:
../../v8/src/objects-body-descriptors.h:102:20: error: no matching function for
call to ‘v8::internal::FixedBodyDescriptor::IterateBody(v8::internal::HeapObject*&)’
../../v8/src/objects-body-descriptors.h:84:22: note: candidate: template template static
void v8::internal::FixedBodyDescriptor::IterateBody(v8::internal::HeapObject*, ObjectVisitor*)
../../v8/src/objects-body-descriptors.h:84:22: note:   template argument
deduction/substitution failed:
../../v8/src/objects-body-descriptors.h:102:20: note:   candidate expects 2
arguments, 1 provided
../../v8/src/objects-body-descriptors.h:89:22: note: candidate: template template static
void v8::internal::FixedBodyDescriptor::IterateBody(v8::internal::HeapObject*, int, ObjectVisitor*)
../../v8/src/objects-body-descriptors.h:89:22: note:   template argument
deduction/substitution failed:
../../v8/src/objects-body-descriptors.h:102:20: note:   candidate expects 3
arguments, 1 provided
../../v8/src/objects-body-descriptors.h:95:22: note: candidate: template template static
void v8::internal::FixedBodyDescriptor::IterateBody(v8::internal::HeapObject*)
../../v8/src/objects-body-descriptors.h:95:22: note:   template argument
deduction/substitution failed:
../../v8/src/objects-body-descriptors.h:102:20: note:   couldn't deduce
template parameter ‘StaticVisitor’
../../v8/src/objects-body-descriptors.h:101:22: note: candidate: template template static
void v8::internal::FixedBodyDescriptor::IterateBody(v8::internal::HeapObject*, int)
../../v8/src/objects-body-descriptors.h:101:22: note:   template argument
deduction/substitution failed:
../../v8/src/objects-body-descriptors.h:102:20: note:   candidate expects 2
arguments, 1 provided

which should point to another function.

[Bug c++/80981] [7/8 Regression] couldn't deduce template parameter for an obvious case

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Markus Trippelsdorf  ---
The error looks valid. Even clang rejects it when using a vanilla class a
(without template).

You need a forward declaration of void b() in this case.

[Bug c++/80981] New: [7/8 Regression] couldn't deduce template parameter for an obvious case

[marxin at gcc dot gnu.org]

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

Bug ID: 80981
   Summary: [7/8 Regression] couldn't deduce template parameter
for an obvious case
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Starting from r236221 we refuse probably valid code (it's reduced from
Chromium):

$ cat chrome.ii
template  class a
{
  template 
  static void b (int a)
  {
if (a > 0)
  b (a--);
  }
};

$ g++-7 chrome.ii -c
chrome.ii: In static member function ‘static void a< >::b(int)’:
chrome.ii:7:13: error: no matching function for call to ‘a<
>::b(int)’
   b (a--);
 ^
chrome.ii:4:15: note: candidate: template > template
static void a< >::b(int)
   static void b (int a)
   ^
chrome.ii:4:15: note:   template argument deduction/substitution failed:
chrome.ii:7:13: note:   couldn't deduce template parameter
‘’
   b (a--);
 ^

[Bug c++/80981] [7/8 Regression] couldn't deduce template parameter for an obvious case

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-05
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Clang and older versions of GCC do accept that.

[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497

[jamborm at gcc dot gnu.org]

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

--- Comment #25 from Martin Jambor  ---
(In reply to boger from comment #17)
> I run these tests after a build by first editing the
> src/libgo/testsuite/gotest to set keep=true and trace=true.  Then I go to my
> bld directory:
> 
> cd bld/powerpc64le-linux/libgo
> make fmt/check
> 
> That should give you output with the full gccgo command to build the test,
> the directory containing the a.out and files from the test.  The name of the
> directory is gotestx.
> 
> FAIL
> Keeping gotest32163
> FAIL: fmt
> Makefile:3331: recipe for target 'fmt/check' failed

I have tried the above on gcc112.fsffrance.org but although I can see
the backtraces, I cannot find any commands to build or run the
testcases anywhere.  Is there anything obvious that I am missing?

[Bug c++/80947] Different visibility for the lambda and its capture list members with -fvisibility=hidden

[vladz at scylladb dot com]

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

--- Comment #1 from Vlad Zolotarov  ---
Created attachment 41472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41472=edit
an ii value generated by g++-6

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
The conditions and location are probably not right, but at least the testcase
passes, so this gives an idea of where the problem is.

--- tree-ssa-sccvn.c(revision 248859)
+++ tree-ssa-sccvn.c(working copy)
@@ -3364,20 +3364,32 @@ set_ssa_val_to (tree from, tree to)
  if (! VN_INFO (to)->info.range_info)
{
  VN_INFO (to)->info.range_info = SSA_NAME_RANGE_INFO (to);
  VN_INFO (to)->range_info_anti_range_p
= SSA_NAME_ANTI_RANGE_P (to);
}
  /* Rather than allocating memory and unioning the info
 just clear it.  */
  SSA_NAME_RANGE_INFO (to) = NULL;
}
+
+ /* Restore old info.  */
+ if (TREE_CODE (currval) == SSA_NAME
+ && INTEGRAL_TYPE_P (TREE_TYPE (currval))
+ && VN_INFO (currval)->info.range_info)
+   {
+ SSA_NAME_RANGE_INFO (currval)
+   = VN_INFO (currval)->info.range_info;
+ SSA_NAME_ANTI_RANGE_P (currval)
+   = VN_INFO (currval)->range_info_anti_range_p;
+ VN_INFO (currval)->info.range_info = NULL;
+   }
}
  else if (POINTER_TYPE_P (TREE_TYPE (to))
   && SSA_NAME_PTR_INFO (to))
{
  if (SSA_NAME_IS_DEFAULT_DEF (to)
  || dominated_by_p_w_unex
(gimple_bb (SSA_NAME_DEF_STMT (from)),
 gimple_bb (SSA_NAME_DEF_STMT (to
/* Keep the info from the dominator.  */
;

[Bug tree-optimization/80980] New: -Os generates larger code than -O1 because loop is not removed

[tkoenig at gcc dot gnu.org]

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

Bug ID: 80980
   Summary: -Os generates larger code than -O1 because loop is not
removed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

$ cat foo.f90
program main
  integer :: i
  do i=1,1
print *,i
  end do
end program main
$ gfortran -o os.s -S -Os foo.f90 
$ gfortran -o o1.s -S -O1 foo.f90 
$ wc -l os.s
82 os.s
$ wc -l o1.s
63 o1.s

This is probably due to -Os not removing the loop.
The -fdump-tree-optimized dump shows for -Os

   [15.00%]:
  i = 1;

   [100.00%]:
  i.2_1 = i;
  if (i.2_1 > 1)
goto ; [15.00%]
  else
goto ; [85.00%]

and for -O1

   [15.00%]:
  i = 1;

$ gfortran -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: ../trunk/configure --prefix=/home/ig25
--enable-languages=c,c++,fortran --enable-maintainer-mode
Thread-Modell: posix
gcc-Version 8.0.0 20170525 (experimental) (GCC)

[Bug rtl-optimization/80474] [6 regression] ipa-cp wrongly adding LO(symbol) twice

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
Created attachment 41471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41471=edit
Tentative fix for 6 branch

[Bug fortran/80766] [7/8 Regression] [OOP] ICE with type-bound procedure returning an array

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from janus at gcc dot gnu.org ---
Fixed on trunk and 7-branch. Closing.

[Bug fortran/80766] [7/8 Regression] [OOP] ICE with type-bound procedure returning an array

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Jun  5 09:31:32 2017
New Revision: 248873

URL: https://gcc.gnu.org/viewcvs?rev=248873=gcc=rev
Log:
2017-06-05  Janus Weil  

Backport from trunk
PR fortran/80766
* resolve.c (resolve_fl_derived): Make sure that vtype symbols are
properly resolved.

2017-06-05  Janus Weil  

Backport from trunk
PR fortran/80766
* gfortran.dg/typebound_call_28.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/typebound_call_28.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
scc_vn_restore_ssa_info is called at the end of PRE, but we would need some
form of restoration after any iteration cycle at least (or maybe we shouldn't
have modified the information for h_11, I don't know).

[Bug c++/80979] ice in lookup_mark, at cp/tree.c:2298

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced C++ source code:

namespace a class address {  
friend bool operator==(const address &, const address &}
bool operator==(const address &, const address &;
}
class b {
  a::address address
} class h {
  typedef b c
} namespace boost struct B {
} namespace i B d;
}
}
using namespace boost : i namespace boost namespace e class f;
 template < g > void operator==(const , f ;
 }
 using e::operator==
 }
 h : c from {
   d == from.address

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
During iteration 1 on some loop, we get
Setting value number of i_10 to h_11 (changed)
which becomes
Setting value number of i_10 to i_10 (changed)
in later iterations.
But the call to set_ssa_val_to(i_10,h_11) overwrites the range info from h_11.
That info is supposedly saved, but it doesn't seem to get restored properly.

[Bug bootstrap/80978] [8 Regression] LTO/PGO bootstrap broken by r248863

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-05
 CC||hubicka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
I will take a look. This means that there is BB without profile count attached
in the profiled function.

[Bug c++/80979] New: ice in lookup_mark, at cp/tree.c:2298

[dcb314 at hotmail dot com]

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

Bug ID: 80979
   Summary: ice in lookup_mark, at cp/tree.c:2298
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 41470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41470=edit
gzipped C++ source code

The attached C++ code does this when compiled by recent gcc trunk:

../../src/upnp.cpp: In member function 'void libtorrent::upnp::on_reply(const
endpoint&, char*, std::size_t)':
../../src/upnp.cpp:392:58: internal compiler error: in lookup_mark, at
cp/tree.c:2298
, boost::bind(_route::gateway, _1) == from.address()) == routes.end())
  ^
0x81a737 lookup_mark(tree_node*, bool)
../../trunk/gcc/cp/tree.c:2298
0x7064d9 name_lookup::add_overload(tree_node*)
../../trunk/gcc/cp/name-lookup.c:431
0x70f1f9 name_lookup::adl_namespace(tree_node*)
../../trunk/gcc/cp/name-lookup.c:432
0x70f1f9 name_lookup::adl_class_only(tree_node*)
../../trunk/gcc/cp/name-lookup.c:786

The bug seems to exist between revisions 248553 and 248835. 
No special compiler flags seem to be required.
I'll have a go at reducing the code.

[Bug target/80970] [7 Regression] internal compiler error in find_reloads, at reload.c:4077

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Martin Liška  ---
Reduced test-case:

$ cat pr80970.i
int a, b, c, d, e;
void f ()
{
  long g, h;
  if (c)
e = d;
  g = d & 31;
  h = 1 << g;
  a = e | h;
  b = a;
}

m68k-suse-linux-gcc-7 pr80970.i -c -O2
pr80970.i: In function 'f':
pr80970.i:11:1: internal compiler error: in find_reloads, at reload.c:4077
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Looks it's a 7 regression as GCC 6 cross compiler works for me.

[Bug c/80919] [7 Regression] ICE: Segmentation fault with -Wall when printing address of size 0 array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE:   |[7 Regression] ICE:
   |Segmentation fault with |Segmentation fault with
   |-Wall when printing address |-Wall when printing address
   |of size 0 array |of size 0 array

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
According to the previous dump (crited1):
  # RANGE [1, 9] NONZERO 15
  h_11 = h_43 + 1;
but when we call get_nonzero_bits on h_11 in PRE, we get 7 ???

[Bug target/80970] [7 Regression] internal compiler error in find_reloads, at reload.c:4077

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to Martin Liška from comment #1)
> Can't download source files:
> You don't have permission to access /~glaubitz/cc2Vfl4Z.out.gz on this
> server.

Oops, sorry. That should be fixed now.

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Ah good, a testcase, thanks. Maybe we'll understand what was breaking spec now.
Transformation happens during PRE.

[Bug tree-optimization/80974] [8 Regression] wrong code (generated code hangs) at -O2 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-05
 CC||glisse at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|wrong code (generated code  |[8 Regression] wrong code
   |hangs) at -O2 on|(generated code hangs) at
   |x86_64-linux-gnu|-O2 on x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r248447.

[Bug c++/80972] [7/8 Regression] ICE with alignas and __attribute__((packed))

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-05
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r240845.

[Bug c++/80971] [7/8 Regression] ICE with 'if constexpr' in template function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-05
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
It's rejected by older GCC versions (5.1.0-6.3.0):

pr80971.cpp: In function ‘bool foo()’:
pr80971.cpp:8:6: error: expected ‘(’ before ‘constexpr’
   if constexpr (A())
  ^

ICE started with r239338.

[Bug target/80970] [7 Regression] internal compiler error in find_reloads, at reload.c:4077

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-05
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't download source files:
You don't have permission to access /~glaubitz/cc2Vfl4Z.out.gz on this server.

[Bug bootstrap/80978] New: [8 Regression] LTO/PGO bootstrap broken by r248863

[trippels at gcc dot gnu.org]

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

Bug ID: 80978
   Summary: [8 Regression] LTO/PGO bootstrap broken by r248863
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at ucw dot cz
  Target Milestone: ---

Since r248863:

/home/trippels/gcc_build_dir_/./prev-gcc/xg++
-B/home/trippels/gcc_build_dir_/./prev-gcc/
-B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++
-B/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home/trippels/gcc/libstdc++-v3/libsupc++
-L/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-no-pie   -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o gengtype \
gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o
errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a ../libbacktrace/.libs/libbacktrace.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
during IPA pass: inline
lto1: internal compiler error: in to_gcov_type, at profile-count.h:108
0x11f3019b profile_count::to_gcov_type() const
../../gcc/gcc/profile-count.h:108
0x11f3019b want_inline_self_recursive_call_p
../../gcc/gcc/ipa-inline.c:916
0x11f3c3db recursive_inlining
../../gcc/gcc/ipa-inline.c:1508
0x11f3c3db inline_small_functions
../../gcc/gcc/ipa-inline.c:1973
0x11f3c3db ipa_inline
../../gcc/gcc/ipa-inline.c:2433
0x11f3c3db execute
../../gcc/gcc/ipa-inline.c:2839

See also https://gcc.gnu.org/ml/gcc-regression/2017-06/msg00018.html

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

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

--- Comment #35 from Eric Botcazou  ---
> When I tried the workaround, I got
> 
> /var/gcc/regression/trunk/10.7-gcc/build/./gcc/xgcc
> -B/var/gcc/regression/trunk/10.7-gcc/build/./gcc/
> -B/vol/gcc/x86_64-apple-darwin11.4.2/bin/
> -B/vol/gcc/x86_64-apple-darwin11.4.2/lib/ -isystem
> /vol/gcc/x86_64-apple-darwin11.4.2/include -isystem
> /vol/gcc/x86_64-apple-darwin11.4.2/sys-include -c -g -O2 -fno-common -W
> -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o
> dyld: Symbol not found: __ZdaPvm
>   Referenced from: /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
>   Expected in: /usr/lib/libstdc++.6.dylib
>  in /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
> xgcc: internal compiler error: Trace/BPT trap: 5 (program gnat1)

The workaround is to filter out -static-libgcc in configure.ac on Darwin but to
leave -static-libstdc++, so why is it still looking for the shared libstdc++?