[Bug c++/80950] GCC about template bug

[kmp53 at sina dot com]

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

--- Comment #3 from 陈林熙  ---
You're right. ISO IEC 14882 explicitly illustrates this. 
In GCC5.3, you can write a global function:
template int (get) {}
Cheat the compiler.

[Bug c/80892] [8 regression] -Wfloat-conversion now warns about non-floats

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r248852.

[Bug c/80892] [8 regression] -Wfloat-conversion now warns about non-floats

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Sat Jun  3 02:49:30 2017
New Revision: 248852

URL: https://gcc.gnu.org/viewcvs?rev=248852=gcc=rev
Log:
PR c/80892 - -Wfloat-conversion now warns about non-floats

gcc/c-family/ChangeLog:

PR c/80892
* c-warn.c (conversion_warning): Use -Wconversion for integer
conversion and -Wfloat-conversion for floating one.

gcc/testsuite/ChangeLog:

PR c/80892
* c-c++-common/Wfloat-conversion-2.c: New test.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/testsuite/ChangeLog

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Marek Polacek from comment #3)
> This is x86_64-pc-linux-gnu.  I tried various combinations of the above
> options but I'm always seeing some errors.  Perhaps it would be possible to
> isolate the function where the crash occurs and thus get rid of
> target-dependent stuff?
> 
> I'd be interested in seeing a better backtrace, too.

I looked into creduce but apparently it doesn't work with objc yet:
https://github.com/csmith-project/creduce/issues/31

Anyways here's a better backtrace:


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x00135430 in do_warn_duplicated_branches (expr=0x560ba10) at
../../gcc/c-family/c-warn.c:2362
2362  if (TREE_CODE (thenb) == NOP_EXPR
(gdb) bt
#0  0x00135430 in do_warn_duplicated_branches (expr=0x560ba10) at
../../gcc/c-family/c-warn.c:2362
#1  0x001355ff in do_warn_duplicated_branches_r (tp=0x55fdaa0) at
../../gcc/c-family/c-warn.c:2401
#2  0x01751efd in walk_tree_1 (tp=0x55fdaa0, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11838
#3  0x017522a2 in walk_tree_1 (tp=0x56149a4, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
#4  0x017522a2 in walk_tree_1 (tp=0x560b960, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
#5  0x017522a2 in walk_tree_1 (tp=0x560ba5c, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, pset=0xbfff6f4c,
lh=0) at ../../gcc/tree.c:11943
#6  0x01751b3b in walk_tree_without_duplicates_1 (tp=0x53a7bec, func=0x1355de
<_Z29do_warn_duplicated_branches_rPP9tree_nodePiPv>, data=0x0, lh=0) at
../../gcc/tree.c:12181
#7  0x001091ba in c_genericize (fndecl=0x53a7b80) at
../../gcc/c-family/c-gimplify.c:129
#8  0x0003f382 in finish_function () at ../../gcc/c/c-decl.c:9350
#9  0x00081370 in c_parser_declaration_or_fndef (parser=0x436a60a8,
fndef_ok=true, static_assert_ok=true, empty_ok=true, nested=false,
start_attr_ok=true, objc_foreach_object_declaration=0x0,
omp_declare_simd_clauses={m_vec = 0x0}, oacc_routine_data=0x0,
fallthru_attr_p=0x0) at ../../gcc/c/c-parser.c:2147
#10 0x000ab4fd in c_parser_external_declaration (parser=0x436a60a8) at
../../gcc/c/c-parser.c:1469
#11 0x000ab650 in c_parser_translation_unit (parser=0x436a60a8) at
../../gcc/c/c-parser.c:1349
#12 0x000ab7ca in c_parse_file () at ../../gcc/c/c-parser.c:18112
#13 0x0011349f in c_common_parse_file () at ../../gcc/c-family/c-opts.c:1104
#14 0x01468198 in compile_file () at ../../gcc/toplev.c:468
#15 0x01469d18 in do_compile () at ../../gcc/toplev.c:2021
#16 0x01469fcf in toplev::main (this=0xbfff741e, argc=257, argv=0xbfff7450) at
../../gcc/toplev.c:2155
#17 0x018a42ab in main (argc=257, argv=0xbfff7450) at ../../gcc/main.c:39
Current language:  auto; currently c++


I'll leave the debug session open; let me know if you need any more info...

[Bug c++/68754] Explicitly defaulted constexpr assignment operator fails to compile

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Testcase committed. Before resolving, however, I'm going to double check that
we are already tracking the diagnostic issue in C++11 mode noticed by Andrew
(for sure isn't new to me!).

[Bug c++/68754] Explicitly defaulted constexpr assignment operator fails to compile

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Jun  2 23:27:22 2017
New Revision: 248847

URL: https://gcc.gnu.org/viewcvs?rev=248847=gcc=rev
Log:
2017-06-02  Paolo Carlini  

PR c++/68754
* g++.dg/cpp1y/constexpr-68754.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-68754.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80960] [5/6/7/8 Regression] Huge memory use when compiling a very large test case

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Dominique d'Humieres  ---
The most important change (a factor ~10) occurred between revisions r190586
(229Mb) and r190619 (1988Mb).

% time /opt/gcc/gcc4.8p-190586/bin/gfortran -c pr80960.f90 -fdefault-integer-8
-O2 -ftime-report

Execution times (seconds)
 phase setup :   0.03 ( 0%) usr   0.02 ( 1%) sys   0.27 ( 0%) wall 
   192 kB ( 0%) ggc
 phase parsing   :   0.53 ( 0%) usr   0.06 ( 3%) sys   0.74 ( 0%) wall 
  9890 kB ( 4%) ggc
 phase opt and generate  : 156.19 (100%) usr   1.80 (95%) sys 158.35 (99%) wall
 218850 kB (95%) ggc
...
 alias analysis  :   0.15 ( 0%) usr   0.00 ( 0%) sys   0.16 ( 0%) wall 
 11577 kB ( 5%) ggc
 alias stmt walking  :  70.08 (45%) usr   0.24 (13%) sys  70.61 (44%) wall 
 0 kB ( 0%) ggc
...
 tree PRE:   0.74 ( 0%) usr   0.04 ( 2%) sys   0.66 ( 0%) wall 
  6401 kB ( 3%) ggc
 tree FRE:  12.30 ( 8%) usr   0.26 (14%) sys  12.33 ( 8%) wall 
 20878 kB ( 9%) ggc
...
 dead store elim1:   1.61 ( 1%) usr   0.03 ( 2%) sys   1.63 ( 1%) wall 
  2235 kB ( 1%) ggc
 dead store elim2:  16.73 (11%) usr   0.01 ( 1%) sys  16.74 (11%) wall 
  3902 kB ( 2%) ggc
...
 integrated RA   :  24.05 (15%) usr   0.06 ( 3%) sys  24.11 (15%) wall 
 32565 kB (14%) ggc
 reload  :   7.82 ( 5%) usr   0.22 (12%) sys   8.04 ( 5%) wall 
 11106 kB ( 5%) ggc
 reload CSE regs :   5.41 ( 3%) usr   0.01 ( 1%) sys   5.42 ( 3%) wall 
  6071 kB ( 3%) ggc
...
 TOTAL : 156.78 1.90   159.42
229270 kB


% time /opt/gcc/gcc4.8a-190619/bin/gfortran -c pr80960.f90 -fdefault-integer-8
-O2 -ftime-report

Execution times (seconds)
 phase setup :   0.03 ( 0%) usr   0.02 ( 0%) sys   0.30 ( 0%) wall 
   192 kB ( 0%) ggc
 phase parsing   :   0.53 ( 0%) usr   0.06 ( 0%) sys   0.77 ( 0%) wall 
  9866 kB ( 0%) ggc
 phase opt and generate  : 446.51 (100%) usr  14.64 (99%) sys 697.47 (100%)
wall 1978039 kB (99%) ggc
...
 alias analysis  :   0.20 ( 0%) usr   0.00 ( 0%) sys   0.25 ( 0%) wall 
 11577 kB ( 1%) ggc
 alias stmt walking  :  23.37 ( 5%) usr   0.40 ( 3%) sys  22.98 ( 3%) wall 
 0 kB ( 0%) ggc
...
 tree PRE:   8.44 ( 2%) usr   0.06 ( 0%) sys   8.84 ( 1%) wall 
 10424 kB ( 1%) ggc
 tree FRE:  17.99 ( 4%) usr   0.25 ( 2%) sys  18.79 ( 3%) wall 
 26063 kB ( 1%) ggc
...
 dead code elimination   :   0.12 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%) wall 
 0 kB ( 0%) ggc
 dead store elim1:   2.25 ( 1%) usr   0.01 ( 0%) sys   2.25 ( 0%) wall 
  2630 kB ( 0%) ggc
 dead store elim2:  15.55 ( 3%) usr   0.02 ( 0%) sys  15.56 ( 2%) wall 
  3329 kB ( 0%) ggc
 CPROP   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 4 kB ( 0%) ggc
 CSE 2   :   0.84 ( 0%) usr   0.01 ( 0%) sys   0.83 ( 0%) wall 
 1 kB ( 0%) ggc
 branch prediction   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
10 kB ( 0%) ggc
 combiner: 328.61 (73%) usr   9.14 (62%) sys 519.94 (74%) wall
1754285 kB (88%) ggc
 regmove :  16.52 ( 4%) usr   0.01 ( 0%) sys  16.54 ( 2%) wall 
 0 kB ( 0%) ggc
 integrated RA   :  10.49 ( 2%) usr   0.21 ( 1%) sys  15.92 ( 2%) wall 
 32785 kB ( 2%) ggc
 reload  :   5.88 ( 1%) usr   0.40 ( 3%) sys  22.38 ( 3%) wall 
  9546 kB ( 0%) ggc
 reload CSE regs :   4.90 ( 1%) usr   0.00 ( 0%) sys   4.90 ( 1%) wall 
  6073 kB ( 0%) ggc
...
 TOTAL : 447.1014.81   698.71   
1988307 kB

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #3)
> Really strange - the tree dumps look OK at first glance.
> 

Maybe missing something in a backend declaration?

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
> BTW, although I am now able to build the DLLs, install-strip does not strip
> the installed copies; should it?

Probably, but in my experience stripping can have unexpected fallout.

[Bug c++/68754] Explicitly defaulted constexpr assignment operator fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Fixed in 5.4.0. To be safe, I'm adding the testcase before resolving the bug.

[Bug fortran/80904] [6/7 Regression] Matmul result allocated to wrong size

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
Fixed everywhere it was broken, closing.

[Bug fortran/80904] [6/7 Regression] Matmul result allocated to wrong size

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Fri Jun  2 19:29:29 2017
New Revision: 248845

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

PR fortran/80904
Backport from trunk
* frontend-passes.c (matmul_lhs_realloc):  Correct
allocation size for case A1B2.

2017-06-02  Thomas Koenig  

PR fortran/80904
Backport from trunk
* gfortran.dg/matmul_bounds_12.f90:  New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/matmul_bounds_12.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/frontend-passes.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug ada/80921] cross compiling fails to build Ada shared libraries

[keith.marshall at mailinator dot com]

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

--- Comment #15 from Keith Marshall  ---
Created attachment 41464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41464=edit
Patch to create gnatlib import libraries for Win32

(In reply to Eric Botcazou from comment #14)
> In any case, the Windows GNAT folks are happy with the current situation.

Fair enough.  FWIW, I've applied the attached (trivial) patch, for my MinGW.org
build of GCC-6.3.0, so we do get the import libraries.  Feel free to adopt it,
or not, as you please.

BTW, although I am now able to build the DLLs, install-strip does not strip the
installed copies; should it?

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[david.abdurachmanov at gmail dot com]

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

--- Comment #13 from David Abdurachmanov  
---
Created attachment 41463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41463=edit
This is just minimized *.ii file

I am also adding PGOInstrumentation2.cpp.xz, which is just slightly minimized
original code. The previous one was minimized with C-Reduce.

[Bug c++/80962] No more access violation control after certain declarations using concepts

[okannen at gmail dot com]

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

--- Comment #1 from Olivier Kannengieser  ---
Inside the comment section BUGGY CODE, the second commented line should be
uncommented to see that gcc does not complaning for private access violation.

The attached file is the version which causes gcc to bug.

[Bug c++/68374] G++ -Wshadow doesn't warn about static member shadowing

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Uhm, the diagnostic is suboptimal however: talks about a local instead of a
static member. Looking into it.

[Bug c++/80962] New: No more access violation control after certain declarations using concepts

[okannen at gmail dot com]

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

Bug ID: 80962
   Summary: No more access violation control after certain
declarations using concepts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: okannen at gmail dot com
  Target Milestone: ---

Created attachment 41462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41462=edit
The buggy code as described in the comment.

GCC VERSION: (gcc -v)
Utilisation des specs internes.
COLLECT_GCC=3Dgcc
   
COLLECT_LTO_WRAPPER=3D/usr/local/gcc7/libexec/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Cible : x86_64-pc-linux-gnu
Configur=C3=A9 avec: ../configure --prefix=3D/usr/local/gcc7
--disable-=multilib
Mod=C3=A8le de thread: posix
gcc version 7.1.1 20170503 (GCC)

BUG DESCRIPTION:
gcc stops to perform member access violation rule checking:
If in a compound requirement using a partialy specialized concept as
placeholder, then gcc stop any access schecking test (one can have access
to private member of classes).

COMMAND LINE:
c++ -fconcepts file.cpp

BUGGY CODE:
This code should not compile, but it does (no access violation performed).

class a_class
   {
   int f(int){return 33;} //private member
   };

template
concept bool AnyConcept =true;

template
concept bool OtherConcept = 
  requires(const T& a)
  {
  //Gcc do not bug without the the following line.
  //{a && a} -> AnyConcept;
  {a && a} -> bool;
  };

int main()
  {
  a_class obj;
  obj.f(10);  //Error not reported by gcc.
  }


BUGGY CODE:
This code shows normal gcc behavior, an error is reported:
"int a_class::f(int) is private in this context"

class a_class
   {
   int f(int){return 33;} //private member
   };

template
concept bool AnyConcept =true;

template
concept bool OtherConcept = 
  requires(const T& a)
  {
  //Gcc do not bug without the the following line.
  //{a && a} -> AnyConcept;
  {a && a} -> bool;
  };


int main()
  {
  a_class obj;
  obj.f(10);  //Error not reported by gcc.
  }


OTHER PROBABLY RELATED ISSUES:
   with larger code I have observed that the same issue
   could happen if any of the following code line occurs:
 1. partialy specialized concept used as placeholder inside function
argument list
  template
  concept bool Same = std::is_same::value;
  int afunc(Same&& x);
 2. partialy specialized concept used as placeholder inside template
argument list
  template
  void afunc(T&&);
 3. concept inside if constexpr (not sure it is inside the concept TS, but
it causes the exact same trouble, + command line option -std=c++17)
  template
  concept bool Constructible = std::is_constructible::value;
  ...
  if constexpr(Constructible)

[Bug libstdc++/80624] char_traits::eof() doesn't meet requirements

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Jun  2 18:35:37 2017
New Revision: 248843

URL: https://gcc.gnu.org/viewcvs?rev=248843=gcc=rev
Log:
PR libstdc++/80624 satisfy invariant for char_traits::eof()

PR libstdc++/80624
* doc/xml/manual/status_cxx2011.xml: Document to_int_type behaviour.
* include/bits/char_traits.h (char_traits::to_int_type):
Transform eof value to U+FFFD.
* testsuite/21_strings/char_traits/requirements/char16_t/eof.cc: New.
* testsuite/27_io/basic_streambuf/sgetc/char16_t/80624.cc: New.
* testsuite/27_io/basic_streambuf/sputc/char16_t/80624.cc: New.

Added:
   
trunk/libstdc++-v3/testsuite/21_strings/char_traits/requirements/char16_t/eof.cc
trunk/libstdc++-v3/testsuite/27_io/basic_streambuf/sgetc/char16_t/
trunk/libstdc++-v3/testsuite/27_io/basic_streambuf/sgetc/char16_t/80624.cc
trunk/libstdc++-v3/testsuite/27_io/basic_streambuf/sputc/char16_t/
trunk/libstdc++-v3/testsuite/27_io/basic_streambuf/sputc/char16_t/80624.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
trunk/libstdc++-v3/include/bits/char_traits.h

[Bug c++/68374] G++ -Wshadow doesn't warn about static member shadowing

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|xyzdragon at fastmail dot fm   |

--- Comment #1 from Paolo Carlini  ---
This is already fixed in trunk. I'm adding a testcase and closing the bug.

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[david.abdurachmanov at gmail dot com]

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

--- Comment #12 from David Abdurachmanov  
---
I have attached minimized file (PGOInstrumentation.cpp) from LLVM.

Compile line: g++ -c PGOInstrumentation.cpp

Result:
PGOInstrumentation.cpp: In constructor
'{anonymous}::PGOInstrumentationUseLegacyPass::PGOInstrumentationUseLegacyPass(std::__cxx11::string)':
PGOInstrumentation.cpp:105:25: error: 'llvm::cl::opt::opt(const llvm::cl::opt&)
[with DataType = std::__cxx11::basic_string; bool ExternalStorage =
false; ParserClass = llvm::cl::parser]' is
private within this context
   ProfileFileName = PGOTestProfileFile;
 ^~
PGOInstrumentation.cpp:92:3: note: declared private here
   opt(const opt &) = delete;
   ^~~
PGOInstrumentation.cpp:105:25: error: use of deleted function
'llvm::cl::opt::opt(const
llvm::cl::opt&) [with DataType =
std::__cxx11::basic_string; bool ExternalStorage = false; ParserClass =
llvm::cl::parser]'
   ProfileFileName = PGOTestProfileFile;
 ^~
PGOInstrumentation.cpp:92:3: note: declared here
   opt(const opt &) = delete;
   ^~~
PGOInstrumentation.cpp:72:2: note:   initializing argument 1 of
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_If_sv<_Tp,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&>
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(_Tp) [with _Tp =
llvm::cl::opt; _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator;
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_If_sv<_Tp,
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&> =
std::__cxx11::basic_string&]'
  operator=(_Tp __sv)
  ^~~~

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[david.abdurachmanov at gmail dot com]

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

--- Comment #11 from David Abdurachmanov  
---
Created attachment 41461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41461=edit
Minimized file from LLVM

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #27198|0   |1
is obsolete||
  Attachment #27199|0   |1
is obsolete||

--- Comment #21 from H.J. Lu  ---
Created attachment 41460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41460=edit
An updated patch

Please take a look at this updated patch against r248831. I got

[hjl@gnu-6 pr53037]$ cat z.i 
struct __attribute__ ((aligned (8))) S8 { char a[8]; };
struct __attribute__ ((packed)) S {
  struct S8 s8;
};
[hjl@gnu-6 pr53037]$ make z.s
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -mx32 -Wall -O2 -S z.i
z.i:4:1: warning: alignment 1 of ‘struct S’ is less than 8
 };
 ^
[hjl@gnu-6 pr53037]$

[Bug fortran/80904] [6/7 Regression] Matmul result allocated to wrong size

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Fri Jun  2 17:44:19 2017
New Revision: 248842

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

PR fortran/80904
* frontend-passes.c (matmul_lhs_realloc):  Correct
allocation size for case A1B2.

2017-06-02  Thomas Koenig  

PR fortran/80904
* gfortran.dg/matmul_bounds_12.f90:  New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/matmul_bounds_12.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/frontend-passes.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> Richard also says the overload shouldn't exist and is a bug, but the
> overload has to exist, because the C++17 draft is defective.

That's https://wg21.link/lwg2946

[Bug jit/80954] JIT make check regression for GCC 8.0

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by r248841.

See https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00152.html for details.

[Bug middle-end/80960] [5/6/7/8 Regression] Huge memory use when compiling a very large test case

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug middle-end/80960] [5/6/7/8 Regression] Huge memory use when compiling a very large test case

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Target|amd64 Linux |
 Status|UNCONFIRMED |NEW
   Keywords||memory-hog
   Last reconfirmed||2017-06-02
  Component|fortran |middle-end
   Host|amd64 Linux |
 Ever confirmed|0   |1
Summary|[regression since 4.9.2]|[5/6/7/8 Regression] Huge
   |gfortran crashes when   |memory use when compiling a
   |compiling f90 file with msg |very large test case
   |"Out of memory: Kill|
   |process 538 (f951)" |

[Bug fortran/80960] [regression since 4.9.2] gfortran crashes when compiling f90 file with msg "Out of memory: Kill process 538 (f951)"

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
I thought I recognized the Maple style here :-)

Compiling with 6.3.0 on a machine with enough memory gives

(gdb) r -fdefault-integer-8 -O2 tst.f90
Starting program: /usr/lib/gcc/x86_64-linux-gnu/6/f951 -fdefault-integer-8 -O2
tst.f90
 getparams setparams describemodel getfhess getfgrad getf computegammas
setparams_fe describemodel_fe initmodel_fe
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   

 
Assembling functions:
  getparams setparams describemodel getfhess {GC 2644206k -> 46376k}
{GC 1438844k -> 59615k} getfgrad {GC 446867k -> 22490k} getf computegammas
setparams_fe describemodel_fe initmodel_fe
Execution times (seconds)
 phase setup :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
   179 kB ( 0%) ggc
 phase parsing   :   0.28 ( 0%) usr   0.26 (16%) sys   0.55 ( 0%) wall 
  9876 kB ( 0%) ggc
 phase opt and generate  : 134.86 (100%) usr   1.40 (84%) sys 136.35 (100%)
wall 4511154 kB (100%) ggc
 phase last asm  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
   208 kB ( 0%) ggc
 garbage collection  :   0.19 ( 0%) usr   0.23 (14%) sys   0.41 ( 0%) wall 
 0 kB ( 0%) ggc
 callgraph construction  :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
 16005 kB ( 0%) ggc
 callgraph optimization  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
14 kB ( 0%) ggc
 ipa dead code removal   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa inlining heuristics :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
23 kB ( 0%) ggc
 ipa profile :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa pure const  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
 1 kB ( 0%) ggc
 ipa icf :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 cfg cleanup :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 trivially dead code :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
 0 kB ( 0%) ggc
 df scan insns   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
 0 kB ( 0%) ggc
 df multiple defs:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 df reaching defs:   0.06 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall 
 0 kB ( 0%) ggc
 df live regs:   0.32 ( 0%) usr   0.00 ( 0%) sys   0.32 ( 0%) wall 
 0 kB ( 0%) ggc
 df live regs:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall 
 0 kB ( 0%) ggc
 df must-initialized regs:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 df use-def / def-use chains:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%)
wall   0 kB ( 0%) ggc
 df reg dead/unused notes:   0.16 ( 0%) usr   0.00 ( 0%) sys   0.14 ( 0%) wall 
  3359 kB ( 0%) ggc
 register information:   0.05 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall 
 0 kB ( 0%) ggc
 alias analysis  :   0.11 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%) wall 
 18870 kB ( 0%) ggc
 alias stmt walking  :  13.30 (10%) usr   0.09 ( 5%) sys  13.28 (10%) wall 
 3 kB ( 0%) ggc
 register scan   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
  1056 kB ( 0%) ggc
 rebuild jump labels :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 parser (global) :   0.28 ( 0%) usr   0.26 (16%) sys   0.55 ( 0%) wall 
  8744 kB ( 0%) ggc
 inline parameters   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
15 kB ( 0%) ggc
 tree gimplify   :   0.14 ( 0%) usr   0.01 ( 1%) sys   0.13 ( 0%) wall 
 25267 kB ( 1%) ggc
 tree CFG cleanup:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 0 kB ( 0%) ggc
 tree VRP:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%) wall 
51 kB ( 0%) ggc
 tree copy propagation   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 tree PTA:   0.25 ( 0%) usr   0.00 ( 0%) sys   0.25 ( 0%) wall 
 7 kB ( 0%) ggc
 tree SSA rewrite:   0.01 ( 0%) usr   0.01 ( 1%) sys   0.02 ( 0%) wall 
 10619 kB ( 0%) ggc
 tree SSA other  :   0.04 ( 0%) usr   0.01 ( 1%) sys   0.05 ( 0%) wall 
 1 kB ( 0%) ggc
 tree operand scan   :   0.03 ( 0%) usr   0.01 ( 1%) sys   0.05 ( 0%) wall 
  6330 kB ( 0%) ggc
 dominator optimization  :   0.08 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall 
  3184 kB ( 0%) ggc
 tree CCP:   0.08 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%) wall 
 3 kB ( 0%) ggc
 tree split crit edges   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 7 kB ( 0%) ggc
 tree reassociation  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
 0 kB ( 0%) ggc
 tree PRE:   1.85 ( 1%) usr   0.00 ( 0%) sys   1.98 ( 1%) wall 
  2938 kB ( 0%) ggc
 tree FRE: 

[Bug jit/80954] JIT make check regression for GCC 8.0

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Fri Jun  2 17:07:37 2017
New Revision: 248841

URL: https://gcc.gnu.org/viewcvs?rev=248841=gcc=rev
Log:
Fix segfault in free_growth_caches (PR jit/80954)

gcc/ChangeLog:
PR jit/80954
* ipa-inline-analysis.c (free_growth_caches): Set
edge_removal_hook_holder to NULL after removing it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c

[Bug fortran/80960] [regression since 4.9.2] gfortran crashes when compiling f90 file with msg "Out of memory: Kill process 538 (f951)"

[nick_kuz at deom dot chph.ras.ru]

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

--- Comment #3 from Nikolay Kuzminykh  ---
Yes, this code is somewhat artificial. Large part of the code is
machine-generated using computer algebra system (commercial Maplesoft Maple).

As for memory limits, it is Virtualbox machine with following resources: 2G
RAM, 20G Hdd (16 Gb is now free), 1G swap file.

During compilation, HDD activity is abnormally high, showing that RAM is
exceeded and swap is intensively used.

[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

simon at pushface dot org changed:

   What|Removed |Added

 CC||simon at pushface dot org

--- Comment #28 from simon at pushface dot org ---
(In reply to Iain Sandoe from comment #25)

> NOTE: AFAIR clang doesn't support that option anyway, so it would not be
> available at stage 1 where clang is the bootstrap compiler.

clang doesn’t support Ada, so the stage 1 compiler has to be a (fairly 
recent, AFAICR) GCC.

[Bug fortran/80960] [regression since 4.9.2] gfortran crashes when compiling f90 file with msg "Out of memory: Kill process 538 (f951)"

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
That is highly obfuscated code. Did you do that for a reason. I doubt it is
real.

You are running out of memory. Have you checked your ulimits. How much memory
do you have?

[Bug fortran/80960] [regression since 4.9.2] gfortran crashes when compiling f90 file with msg "Out of memory: Kill process 538 (f951)"

[nick_kuz at deom dot chph.ras.ru]

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

--- Comment #1 from Nikolay Kuzminykh  ---
compiling with options "-g0 -O0" is OK.
-O1 and -O2  options lead to problems.

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
This is x86_64-pc-linux-gnu.  I tried various combinations of the above options
but I'm always seeing some errors.  Perhaps it would be possible to isolate the
function where the crash occurs and thus get rid of target-dependent stuff?

I'd be interested in seeing a better backtrace, too.

[Bug c++/80961] New: Constructor preferred over conversion operator, when should be ambiguous

[barry.revzin at gmail dot com]

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

Bug ID: 80961
   Summary: Constructor preferred over conversion operator, when
should be ambiguous
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

In the following example:

struct S;

struct T { 
#ifdef BUG
T(S const& );
#else
T(S& );
#endif
};

struct S { 
#ifdef BUG
operator T() const;
#else
operator T();
#endif
};

int main() {
S s;
T t = s;
}

Without BUG defined, the code correctly fails to compile due to the conversion
from S to T being ambiguous. With BUG defined, the conversion should still be
ambiguous for the same reason, but compiles - choosing T(S const&).

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[egall at gwmail dot gwu.edu]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Marek Polacek from comment #1)
> I can't reproduce; I get some errors:
> 
> $ ./cc1obj -quiet nsselect.mi  -fobjc-exceptions
> In file included from lisp.h:39:0,
>  from nsselect.m:32:
> ../lib/intprops.h:91:1: error: static assertion failed: "verify
> (TYPE_MINIMUM (long int) == LONG_MIN)"
> In file included from lisp.h:39:0,
>  from nsselect.m:32:
> ../lib/intprops.h:92:1: error: static assertion failed: "verify
> (TYPE_MAXIMUM (long int) == LONG_MAX)"
> In file included from nsselect.m:32:0:
> lisp.h:197:1: error: static assertion failed: "verify (BITS_WORD_MAX >>
> (BITS_PER_BITS_WORD - 1) == 1)"
> nsselect.m: In function ‘ns_string_from_pasteboard’:
> nsselect.m:274:7: error: cannot find interface declaration for
> ‘NXConstantString’

I'm guessing those are due to target differences; first 2 look like 32bit vs.
64bit issues, while the 3rd looks like a difference between -fgnu-runtime vs.
-fnext-runtime. What's the target for the compiler you're using? Also I'm
guessing that since the ICE was in do_warn_duplicated_branches_r that the
-Wduplicated-branches flag will be necessary to trigger it

[Bug fortran/80960] New: [regression since 4.9.2] gfortran crashes when compiling f90 file with msg "Out of memory: Kill process 538 (f951)"

[nick_kuz at deom dot chph.ras.ru]

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

Bug ID: 80960
   Summary: [regression since 4.9.2] gfortran crashes when
compiling f90 file with msg "Out of memory: Kill
process 538 (f951)"
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nick_kuz at deom dot chph.ras.ru
  Target Milestone: ---

Created attachment 41459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41459=edit
f90 source code for reproducing bug

When compiling large f90 (see attach), compiler crashes with following message:
"Out of memory: Kill process 538 (f951) score 962 or sacrifice child"
REGRESSION: Older gfortran 4.9 at Debian Jessie 8 compiles this file without
problem.

reproduce bug condition: use attached f90 file and run options:
gfortran -g0 -O2 -fdefault-integer-8 -c  'fe_objective.f90'

SYSTEM details:
gfortran: gcc version 6.3.0 20170516 (Debian 6.3.0-18)

Linux System: Debian Stretch 9, latest updates 2017-06-02
 uname -a:
Linux deb9virt 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 (2017-05-02) x86_64
GNU/Linux

HW:
guest linux box in virtualbox 4.3 
host system: intel i5-4xxx, debian 8 Jessie

[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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Testing a patch for this.

[Bug tree-optimization/80944] redundant memcpy/memset with non-constant size not eliminated

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Good point!  It never occurred to me.  That explains why no compiler does it.

That suggests that the optimization opportunity is up to the user.  I.e., a
class like std::string could optimize this case by adding a constraint/assert
that s->s doesn't point at s.  Let me look into that.

[Bug tree-optimization/80948] [8 regression] test case gcc.dg/torture/pr68017.c fails with ICE starting with r248771

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from seurer at gcc dot gnu.org ---
Looks like you fixed it.  Thanks!

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[seurer at gcc dot gnu.org]

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

Bug 80948 Summary: [8 regression] test case gcc.dg/torture/pr68017.c fails with 
ICE starting with r248771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80948

   What|Removed |Added

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

[Bug c/80959] -Wreturn-type "control reaches end of non-void function" false positive with -fsanitize=address

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Hm, is the GIMPLE instrumentation w/ ASAN_MARK properly done or is it issues in
tree-cfg pass? I'm bit confused here.

[Bug ipa/80882] [8 regression] test case gfortran.dg/pr48636.f90 fails starting with r248375

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from seurer at gcc dot gnu.org ---
I believe this was fixed by r248460.

[Bug jit/80954] JIT make check regression for GCC 8.0

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-02
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks.  Confirmed.  Am testing a fix.

[Bug c/80959] -Wreturn-type "control reaches end of non-void function" false positive with -fsanitize=address

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-02
 CC||mliska at suse dot cz
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Looks like it is caused by

  try
{
...
}
  finally
{
  ASAN_MARK (POISON, , 4);
}

which eventually gets to

   [0.00%]:
  ASAN_MARK (POISON, , 4);
  switch (finally_tmp.2)  [0.00%], case 1:  [0.00%]>

 [0.00%]:

   [0.00%]:
  return;

 [0.00%]:
  return D.2131;

thus it lacks a return.  That's also visible in .original:

{
  int n;

int n;
  bar ();
  switch (i)
{
  case 1:;
  switch (i)
{
  default:;
  return 0;
}
  goto ;
  default:;
  return 0;
}
  :;
}

but I guess that "dead" break; after the inner switch was previously
CFG cleaned-up.

[Bug c/80959] -Wreturn-type "control reaches end of non-void function" false positive with -fsanitize=address

[simon.marchi at polymtl dot ca]

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

--- Comment #1 from Simon Marchi  ---
Forgot to mention, the initial problem I stumbled on was this function:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/mach-o-i386.c;h=b2f02415c3ae019224b25184539237d530c5bc7e;hb=HEAD#l114

[Bug c/80959] New: -Wreturn-type "control reaches end of non-void function" false positive with -fsanitize=address

[simon.marchi at polymtl dot ca]

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

Bug ID: 80959
   Summary: -Wreturn-type "control reaches end of non-void
function" false positive with -fsanitize=address
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

Created attachment 41458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41458=edit
Reproducer

I stumbled on this while building the binutils-gdb repo with -fsanitize=address
with gcc 7.1.0 and reproduced it with gcc master from today.  It doesn't happen
with my distro compiler (5.4.0-6ubuntu1~16.04.4).

gcc reports that the control can reach the end of the function, but I think
it's not the case.  This is the smallest reproducer I managed to find.  Note
that the problem disappears if you enable optimizations (-O > 0) or remove
-fsanitize=address.

Compile the attached file with:

$ /opt/gcc/git/bin/gcc -Wreturn-type -Werror -O0 -fsanitize=address -c test.c
test.c: In function 'foo':
test.c:23:1: error: control reaches end of non-void function
[-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #6)
> Created attachment 41456 [details]
> sparc-sun-solaris2.12 pr80815-3.c.156t.vect

Thanks for reporting, I will investigate it and disable on targets if it's not
a general case.

Thanks.

[Bug c++/80957] internal compiler error when building Qt 5.9 source

[bokorn at tvn dot hu]

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

--- Comment #2 from bokorn at tvn dot hu ---
tried to attach preprocessed source, but I kept getting server errors :-/

[Bug tree-optimization/80948] [8 regression] test case gcc.dg/torture/pr68017.c fails with ICE starting with r248771

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Jun  2 12:34:32 2017
New Revision: 248824

URL: https://gcc.gnu.org/viewcvs?rev=248824=gcc=rev
Log:
2017-06-02  Richard Biener  

PR tree-optimization/80948
* tree-tailcall.c (find_tail_calls): Track stmts to move in
stmt order as well.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-tailcall.c

[Bug c++/80957] internal compiler error when building Qt 5.9 source

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
GCC 4.7 is no longer supported, please try a newer version, at least GCC 5.4.

Also you need to attach preprocessed source as a testcase, otherwise it's
impossible to reproduce the bug.

[Bug translation/80958] [8 regression] gcc.target/i386/pr70021.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Note the loop in question does very sparse accesses which have high load/store
cost (in the attached dump), it also contains conditionals so the more precise
accounting might have just pushed the cost over the boundary, not changing it
by much.

[Bug translation/80958] [8 regression] gcc.target/i386/pr70021.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-02
 CC||jgreenhalgh at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The first loop is no longer vectorized because of cost issues.  Likely because
of

2017-05-16  James Greenhalgh  
Bill Schmidt  

PR tree-optimization/80457
* tree-vect-stmts.c (vect_model_simple_cost): Model the cost
of all arguments to a statement as scalar_to_vec operations.
(vectorizable_call): Adjust call to vect_model_simple_cost for
new parameter.
(vectorizable_conversion): Likewise.
(vectorizable_assignment): Likewise.
(vectorizable_shift): Likewise.
(vectorizable_operation): Likewise.
(vectorizable_comparison): Likewise.
(vect_is_simple_cond): Record the def types for operands.
(vectorizable_condition): Likewise, call vect_model_simple_cost.
* tree-vectorizer.h (vect_model_simple_cost): Add new parameter
for statement argument count.

[Bug translation/80958] [8 regression] gcc.target/i386/pr70021.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug translation/80958] New: [8 regression] gcc.target/i386/pr70021.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 80958
   Summary: [8 regression] gcc.target/i386/pr70021.c FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.*, x86_64-pc-linux-gnu,
i686-pc-linux-gnu

Created attachment 41457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41457=edit
i386-pc-solaris2.12 pr70021.c.156t.vect

Between 20170517 and 20170518, the gcc.target/i386/pr70021.c testcase started
to FAIL

FAIL: gcc.target/i386/pr70021.c scan-tree-dump-times vect "vectorized 1 loops"
2

on Solaris/x86 and Linux/x86_64, both 32 and 64-bit.  Attaching the dump.

  Rainer

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
Created attachment 41456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41456=edit
sparc-sun-solaris2.12 pr80815-3.c.156t.vect

[Bug tree-optimization/80948] [8 regression] test case gcc.dg/torture/pr68017.c fails with ICE starting with r248771

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|powerpc*-*-*|powerpc*-*-*, sparc*-*-*
 CC||ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
Same on Solaris/SPARC.

[Bug c++/80957] New: internal compiler error when building Qt 5.9 source

[bokorn at tvn dot hu]

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

Bug ID: 80957
   Summary: internal compiler error when building Qt 5.9 source
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bokorn at tvn dot hu
  Target Milestone: ---

I'm trying to build Qt5.9 sources, but get Internal compiler error at the same
location
platform: Debian 7 running in docker

failing command line:

g++ -c -include .pch/Qt5Qml -m32 -pipe -Wno-c++0x-compat -msse2 -mfpmath=sse
-O2 -std=c++11 -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions
-Wall -W -Wno-c++0x-compat -Wvla -D_REENTRANT -fPIC
-DQT_NO_URL_CAST_FROM_STRING -DQT_NO_INTEGER_EVENT_COORDINATES -DQT_NO_FOREACH
-DWTF_EXPORT_PRIVATE= -DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportBacktrace=qmlWTFReportBacktrace
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0
-DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0
-DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG -DQT_NO_QML_DEBUGGER
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_QML_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_NETWORK_LIB
-DQT_CORE_LIB -I/tmp/qt5/tmp/qtdeclarative/src/qml -I.
-I/tmp/qt5/tmp/qtdeclarative/src/qml/memory -I.
-I/tmp/qt5/tmp/qtdeclarative/src/qml/compiler -I.
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/jit
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/assembler
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/runtime
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/wtf
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/stubs
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/stubs/wtf
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/disassembler
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/disassembler/udis86
-I/tmp/qt5/tmp/qtdeclarative/src/qml/jit -I. -I.generated
-I/tmp/qt5/tmp/qtdeclarative/src/qml/jsruntime -I.
-I/tmp/qt5/tmp/qtdeclarative/src/qml/debugger
-I/tmp/qt5/tmp/qtdeclarative/src/qml/animations
-I/tmp/qt5/tmp/qtdeclarative/include -I/tmp/qt5/tmp/qtdeclarative/include/QtQml
-I../../include -I../../include/QtQml
-I/tmp/qt5/tmp/qtdeclarative/include/QtQml/5.9.0
-I/tmp/qt5/tmp/qtdeclarative/include/QtQml/5.9.0/QtQml
-I../../include/QtQml/5.9.0 -I../../include/QtQml/5.9.0/QtQml
-I/tmp/qt5/tmp/qtbase/include/QtCore/5.9.0
-I/tmp/qt5/tmp/qtbase/include/QtCore/5.9.0/QtCore
-I/tmp/qt5/tmp/build/qtbase/include/QtCore/5.9.0
-I/tmp/qt5/tmp/build/qtbase/include/QtCore/5.9.0/QtCore
-I/tmp/qt5/tmp/qtbase/include -I/tmp/qt5/tmp/qtbase/include/QtNetwork
-I/tmp/qt5/tmp/build/qtbase/include
-I/tmp/qt5/tmp/build/qtbase/include/QtNetwork
-I/tmp/qt5/tmp/qtbase/include/QtCore -I/tmp/qt5/tmp/build/qtbase/include/QtCore
-I.moc -I/tmp/qt5/tmp/qtbase/mkspecs/linux-g++-32 -o .obj/qqmladaptormodel.o
/tmp/qt5/tmp/qtdeclarative/src/qml/util/qqmladaptormodel.cpp
g++ -c -include .pch/Qt5Qml -m32 -pipe -Wno-c++0x-compat -msse2 -mfpmath=sse
-O2 -std=c++11 -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions
-Wall -W -Wno-c++0x-compat -Wvla -D_REENTRANT -fPIC
-DQT_NO_URL_CAST_FROM_STRING -DQT_NO_INTEGER_EVENT_COORDINATES -DQT_NO_FOREACH
-DWTF_EXPORT_PRIVATE= -DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1
-DWTFReportAssertionFailure=qmlWTFReportAssertionFailure
-DWTFReportBacktrace=qmlWTFReportBacktrace
-DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0
-DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0
-DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG -DQT_NO_QML_DEBUGGER
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_QML_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_NETWORK_LIB
-DQT_CORE_LIB -I/tmp/qt5/tmp/qtdeclarative/src/qml -I.
-I/tmp/qt5/tmp/qtdeclarative/src/qml/memory -I.
-I/tmp/qt5/tmp/qtdeclarative/src/qml/compiler -I.
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/jit
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/assembler
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/runtime
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/wtf
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/stubs
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/stubs/wtf
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/disassembler
-I/tmp/qt5/tmp/qtdeclarative/src/3rdparty/masm/disassembler/udis86
-I/tmp/qt5/tmp/qtdeclarative/src/qml/jit -I. -I.generated

[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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to TC from comment #0)
> The following are technically valid - because __ref_cast is subject to ADL -

That should be fixed too.

[Bug target/71607] [5/6/7/8 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands

[prakhar at gcc dot gnu.org]

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

--- Comment #15 from prakhar at gcc dot gnu.org ---
Author: prakhar
Date: Fri Jun  2 11:19:16 2017
New Revision: 248822

URL: https://gcc.gnu.org/viewcvs?rev=248822=gcc=rev
Log:
PR71607: Fix ICE when loading constant

2017-06-02  Prakhar Bahuguna  

Backport from mainline
2017-05-05  Andre Vieira  
Prakhar Bahuguna  

gcc/
PR target/71607
* config/arm/arm.md (use_literal_pool): Remove.
(64-bit immediate split): No longer takes cost into consideration
if arm_disable_literal_pool is enabled.
* config/arm/arm.c (arm_tls_referenced_p): Add diagnostic if TLS is
used when arm_disable_literal_pool is enabled.
(arm_max_const_double_inline_cost): Remove use of
arm_disable_literal_pool.
(push_minipool_fix): Add assert.
(arm_reorg): Add return if arm_disable_literal_pool is enabled.
* config/arm/vfp.md (no_literal_pool_df_immediate): New.
(no_literal_pool_sf_immediate): New.

2017-05-05  Andre Vieira  
Thomas Preud'homme  
Prakhar Bahuguna  

gcc/testsuite/
PR target/71607
* gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
* gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
* gcc.target/arm/thumb2-slow-flash-data-2.c: New.
* gcc.target/arm/thumb2-slow-flash-data-3.c: New.
* gcc.target/arm/thumb2-slow-flash-data-4.c: New.
* gcc.target/arm/thumb2-slow-flash-data-5.c: New.
* gcc.target/arm/tls-disable-literal-pool.c: New.

Added:
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-2.c
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-3.c
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-4.c
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-5.c
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/tls-disable-literal-pool.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/arm/arm.c
branches/gcc-7-branch/gcc/config/arm/arm.md
branches/gcc-7-branch/gcc/config/arm/vfp.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/80951] Deducing noexcept only works when also deducing something else

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/80950] GCC about template bug

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
See https://womble.decadent.org.uk/c++/template-faq.html#disambiguation

[Bug c++/80955] Macros expanded in definition of user-defined literals

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/80955] New: Macros expanded in definition of user-defined literals

[redi at gcc dot gnu.org]

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

Bug ID: 80955
   Summary: Macros expanded in definition of user-defined literals
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This is valid, but fails to compile:


using size_t = decltype(sizeof(0));
#define _zero
int operator""_zero(const char*, size_t) { return 0; }
int main() { return ""_zero; }


The preprocessor should not expand the macro in ""_zero because it's a literal
suffix. They are not expanded at the point of use, but are incorrectly expanded
in the definition of the literal operator.


suf.cc:3:13: warning: invalid suffix on literal; C++11 requires a space between
literal and string macro [-Wliteral-suffix]
 int operator""_zero(const char*, size_t) { return 0; }
 ^
suf.cc:4:21: warning: invalid suffix on literal; C++11 requires a space between
literal and string macro [-Wliteral-suffix]
 int main() { return ""_zero; }
 ^
suf.cc:3:13: error: expected suffix identifier
 int operator""_zero(const char*, size_t) { return 0; }
 ^~
suf.cc: In function ‘int main()’:
suf.cc:4:21: error: invalid conversion from ‘const char*’ to ‘int’
[-fpermissive]
 int main() { return ""_zero; }
 ^~


N.B. It would be correct to expand the macro if it was defined like so:

int operator"" _zero(unsigned long long, size_t) { return 0; }

[Bug jit/80954] New: JIT make check regression for GCC 8.0

[andrey.y.guskov at intel dot com]

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

Bug ID: 80954
   Summary: JIT make check regression for GCC 8.0
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

Created attachment 41454
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41454=edit
JIT make check fails

Revision r248336 made GCC JIT make check start reporting mass fails; see
fails.log

./configure line:
--enable-languages=c,c++,jit --enable-clocale=gnu --enable-cloog-backend=isl
--enable-shared --enable-host-shared --disable-libsanitizer --disable-bootstrap
--disable-nls --with-system-zlib --with-demangler-in-ld --with-arch=corei7
--with-cpu=corei7 --with-fpmath=sse

[Bug gcov-profile/80952] gcc 7.1.1 has a drastic performance downgrade using "-fprofile-arcs" compared to 6.3.1 version

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
I was actually talking about generic atomic add and fetch optimization and not
one directly related to profiling data.

[Bug gcov-profile/80952] gcc 7.1.1 has a drastic performance downgrade using "-fprofile-arcs" compared to 6.3.1 version

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Yep, there's my initial attempt to do that:
https://patchwork.ozlabs.org/patch/685796/

But as I discussed with Richi, he prefers more generic approach to have local
counters being updated at function exits.

[Bug gcov-profile/80952] gcc 7.1.1 has a drastic performance downgrade using "-fprofile-arcs" compared to 6.3.1 version

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
I think it might be interesting to optimize relaxed atomic adds such that we
can pull the add out if the loop.

[Bug gcov-profile/80952] gcc 7.1.1 has a drastic performance downgrade using "-fprofile-arcs" compared to 6.3.1 version

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|missed-optimization |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-02
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed, it's caused by adding -fprofile-update option in GCC 7.1:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

Where by default (when one uses -pthread), it's -fprofile-update=atomic.
The option guarantees that collected profile is not corrupted as updating is
racy.

Using -fprofile-generate and -fprofile-update=single causes:

pr80952.cpp: In function ‘main._omp_fn.0’:
pr80952.cpp:40:1: error: corrupted profile info: profile data is not
flow-consistent
 }
 ^
pr80952.cpp:40:1: error: corrupted profile info: number of executions for edge
3-4 thought to be 32
pr80952.cpp:40:1: error: corrupted profile info: number of executions for edge
3-13 thought to be -2
pr80952.cpp:40:1: error: corrupted profile info: number of executions for edge
11-8 thought to be -239929
pr80952.cpp:40:1: error: corrupted profile info: number of executions for edge
11-12 thought to be 247808373

Running perf confirms that locking is bottleneck:


0.00 :4014a3:   lock addq $0x1,0x204024(%rip)# 6054d0
<__gcov0.main._omp_fn.0+0x30>
   49.28 :4014ac:   cmp%ecx,%r8d
0.00 :4014af:   jl 4014c3 
0.00 :4014b1:   lock addq $0x1,0x203ffe(%rip)# 6054b8
<__gcov0.main._omp_fn.0+0x18>
 :  {
 :  if (dividend % divisor == 0) {
   50.12 :4014ba:   mov%esi,%eax
0.01 :4014bc:   cltd   

Well, I planned to provide profile update method where there will be function
local counters that will be merged to global at function exit.
That would definitely help in this example.

[Bug gcov-profile/80952] gcc 7.1.1 has a drastic performance downgrade using "-fprofile-arcs" compared to 6.3.1 version

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I suspect this is due to using atomic increments for the profile data now.
Before there were many race conditions and profile arch would produce incorrect
values for threaded (openmp is such) code.

[Bug gcov-profile/80952] gcc 7.1.1 has a drastic performance downgrade using "-fprofile-arcs" compared to 6.3.1 version

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
I believe threadsafe counters are now used by default when you use -pthread
(which -fopenmp enables IIRC).  For counters in loops that is quite harmful,
mitigation was discussed but final implementation did not happen (yet).  You
can override
this by adding

-fprofile-update=single

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  ---
Created attachment 41453
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41453=edit
Add SPARC ASan support in GCC

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  ---
Created attachment 41452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41452=edit
Adapt c-c++-common/ubsan/float-cast-overflow-1.c for Solaris

[Bug tree-optimization/80948] [8 regression] test case gcc.dg/torture/pr68017.c fails with ICE starting with r248771

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #3 from Renlin Li  ---
saw this ICE on arm and aarch64 target as well.

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  ---
Created attachment 41451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41451=edit
Basic libsanitizer Solaris support: x86 GCC side

[Bug sanitizer/80953] Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 41450
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41450=edit
Basic libsanitizer Solaris support

[Bug sanitizer/80953] New: Support libsanitizer on Solaris

[ro at gcc dot gnu.org]

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

Bug ID: 80953
   Summary: Support libsanitizer on Solaris
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.*

Created attachment 41449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41449=edit
Use SANITIZER_* macros in libsanitizer/interception

As I've just reported in LLVM bugzilla

https://bugs.llvm.org//show_bug.cgi?id=33274

I've made quite some progress with a libsanitizer port to Solaris, to the point
where 32-bit x86 results are good and 32-bit sparc results decent.

While most of the issues need to be fleshed out upstream to get this support
into gcc, some are gcc specific and I'm filing this PR to keep track of them.

I'm again attaching the patches that are common with LLVM because the ones
attached
to the LLVM bug will be superceded by trunk versions in due time, while those
here should apply to the version of libsanitizer in gcc.

On top of the interception macros and basic support patches, there are those
for the gcc side (libsanitizer build system, driver stuff etc.), one for a
testsuite
issue and the first cut at the sparc support patch.

  Rainer

[Bug rtl-optimization/80930] REE pass causes high memory usage via df_mir_alloc() with ASAN+UBSAN turned on

[sirl at gcc dot gnu.org]

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

--- Comment #2 from Franz Sirl  ---
Further investigation shows that "-O2 -fsanitize=undefined" is enough to
trigger the excessive memory usage.
The big difference between GCC-6 and GCC-7 is that the function causing this
has ~20 blocks in GCC-6 and ~30 blocks in GCC-7. I'll try to
investigate the reason for this 50% increase a bit.

[Bug tree-optimization/80948] [8 regression] test case gcc.dg/torture/pr68017.c fails with ICE starting with r248771

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-02
 Blocks||66313
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Ouch.  Stupid mistake when converting a vec to bitmap :/  Testing a patch.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
[Bug 66313] Unsafe factorization of a*b+a*c

[Bug c++/80952] New: gcc 7.1.1 has a drastic performance downgrade using "-fprofile-arcs" compared to 6.3.1 version

[xiaonan830818 at gmail dot com]

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

Bug ID: 80952
   Summary: gcc 7.1.1 has a drastic performance downgrade using
"-fprofile-arcs" compared to 6.3.1 version
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiaonan830818 at gmail dot com
  Target Milestone: ---

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

Hi all,

My testbed is ArchLinux, X86_64, 32 cores, and I use the attached file to test
performance.

(1) Use the newest gcc 7.1.1, and build without "-fprofile-arcs" compile option
and run program:

$ g++ -fopenmp -g -O2 parallel.cpp
$ ./a.out
Function consume: 0.743077 s.

Then build with "-fprofile-arcs" compile option:

$ g++ -fopenmp -fprofile-arcs -g -O2 parallel.cpp
$ ./a.out
Function consume: 208 s.

We can see the performance gap is too large.

(2) While use gcc 6.3.1, without "-fprofile-arcs":  

$ g++ -fopenmp -g -O2 parallel.cpp
$ ./a.out
Function consume: 0.77169 s.

use it:  

$ g++ -fopenmp -fprofile-arcs -g -O2 parallel.cpp
$ ./a.out
Function consume: 0.746134 s.

We can see the performance is very near.

[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 #27 from Eric Botcazou  ---
> Still present at revision r248811. Any chance to get this fixed?

Did you try what I suggested in comment #16 as a stopgap measure?  No GNAT
developer builds the mainline compiler on Darwin regularly so this may take a
while to sort out otherwise.

[Bug c++/80950] GCC about template bug

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I think you need to write this->template get<1>();

I get the same error with GCC 5.3 btw.

[Bug testsuite/80946] [8 regression] test cases gfortran.dg/vect/vect-2.f90 and gfortran.dg/vect/vect-5.f90 fail starting with r247544

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64le-*-*
  Component|other   |testsuite
   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
It's interesting that those fails do not happen on x86_64 ... I'm also curious
as of what the testcase is supposed to test.

Whether we peel or not really depends on cost modeling which now changed to
not peel to align a single store if aligned stores have the same cost as
unaligned stores.  I see one issue with the patch but that has been rectified
with the rewrite I think (not using unaligned_store vs. vector_store).

Index: gcc/testsuite/gfortran.dg/vect/vect-2.f90
===
--- gcc/testsuite/gfortran.dg/vect/vect-2.f90   (revision 248814)
+++ gcc/testsuite/gfortran.dg/vect/vect-2.f90   (working copy)
@@ -8,14 +8,8 @@ A = LOG(X); B = LOG(Y); C = A + B
 PRINT*, C(50)
 END

-! First loop (A=LOG(X)) is vectorized using peeling to align the store.
-! Same for the second loop (B=LOG(Y)).
-! Third loop (C = A + B) is vectorized using versioning (for targets that
don't
-! support unaligned loads) or using peeling to align the store (on targets
that 
-! support unaligned loads).
+! First loop (A=LOG(X)) may be vectorized using peeling to align the store
+! or using unaligned accesses or versioning.
+! Same for the second loop (B=LOG(Y)) and the third loop.

 ! { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" } }
-! { dg-final { scan-tree-dump-times "Alignment of access forced using peeling"
3 "vect" { xfail { { vect_no_align && { ! vect_hw_misalign } } || { !
vector_alignment_reachable } } } } }
-! { dg-final { scan-tree-dump-times "Alignment of access forced using peeling"
2 "vect" { target { { vect_no_align && { ! vect_hw_misalign } } && { !
vector_alignment_reachable } } } } }
-! { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect"
{ xfail { vect_no_align && { ! vect_hw_misalign } } } } }
-! { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning." 3 "vect" {target { { vect_no_align && { ! vect_hw_misalign } } ||
{ { ! vector_alignment_reachable  } && { ! vect_hw_misalign } } } } } }

[Bug tree-optimization/80944] redundant memcpy/memset with non-constant size not eliminated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Indeed.

[Bug debug/80938] [8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug rtl-optimization/80903] [8 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun  2 08:12:33 2017
New Revision: 248817

URL: https://gcc.gnu.org/viewcvs?rev=248817=gcc=rev
Log:
PR rtl-optimization/80903
* loop-doloop.c (add_test): Unshare sequence.

* gcc.dg/pr80903.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr80903.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/loop-doloop.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

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

[dominiq at lps dot ens.fr]

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

--- Comment #26 from Dominique d'Humieres  ---
Still present at revision r248811. Any chance to get this fixed?

[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Jun  2 08:10:48 2017
New Revision: 248816

URL: https://gcc.gnu.org/viewcvs?rev=248816=gcc=rev
Log:
2017-06-02  Richard Biener  
Markus Eisenmann  

PR libstdc++/80721
* libsupc++/eh_alloc.cc (pool::free): Keep list properly
sorted and add missing freelist item merging cases.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_alloc.cc

[Bug libstdc++/80721] Sorting/Merging of free EH-emergency buffer may wrong or uncomplete

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk.

[Bug rtl-optimization/80903] [8 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun  2 08:07:15 2017
New Revision: 248815

URL: https://gcc.gnu.org/viewcvs?rev=248815=gcc=rev
Log:
PR rtl-optimization/80903
* loop-doloop.c (add_test): Unshare sequence.

* gcc.dg/pr80903.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80903.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-doloop.c
trunk/gcc/testsuite/ChangeLog

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

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #9 from rdapp at linux dot vnet.ibm.com ---
I built --with-cpu=power7 and still see TARGET_EFFICIENT_UNALIGNED_VSX == true
in the backend which causes unaligned stores to have costs of 1.  On my power7
system, TARGET_EFFICIENT_UNALIGNED_VSX is never true.

I stepped through rs6000_override_internal and TARGET_EFFICIENT_UNALIGNED_VSX
is properly unset via the options defined by --with-cpu=power7 (or power6).

Afterwards, however, it is overwritten again by TARGET_P8_VECTOR which, in
turn, is set automatically by the vector test suite depending on the current
CPU:

  [...]
  } elseif [check_p8vector_hw_available] {
lappend DEFAULT_VECTCFLAGS "-mpower8-vector" 

Therefore, whenever the vector tests are run on a power8 CPU,
TARGET_EFFICIENT_UNALIGNED_VSX = 1, no matter the --with-cpu. This would also
explain why I didn't see the fails on my machine, all vect tests are only
called with -maltivec which doesn't override TARGET_EFFICIENT_UNALIGNED_VSX.

So, the way the vect test suite is currently set up, this is kind of expected.

[Bug c++/80951] New: Deducing noexcept only works when also deducing something else

[rs2740 at gmail dot com]

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

Bug ID: 80951
   Summary: Deducing noexcept only works when also deducing
something else
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Another issue (compare bug 80384 and bug 80908) with the extension making
noexcept(E) to be a deduced context
(https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00665.html).

The following works:

void f() noexcept;

template
void g(R (*)() noexcept(E));

using t1 = decltype(g(f)); // OK

But not when the only thing being deduced is E:

template
void h(void (*)() noexcept(E));

using t2 = decltype(h(f)); // error

:12:24: error: no matching function for call to 'h(void (&)()
noexcept)'
 using t2 = decltype(h(f)); // error
^
:10:6: note: candidate: 'template void h(void (*)() noexcept
(E))'
 void h(void (*)() noexcept(E));
  ^
:10:6: note:   template argument deduction/substitution failed:
:12:24: note:   couldn't deduce template parameter 'E'
 using t2 = decltype(h(f)); // error
^
:12:24: error: no matching function for call to 'h(void (&)()
noexcept)'
:10:6: note: candidate: 'template void h(void (*)() noexcept
(E))'
 void h(void (*)() noexcept(E));
  ^
:10:6: note:   template argument deduction/substitution failed:
:12:24: note:   couldn't deduce template parameter 'E'
 using t2 = decltype(h(f)); // error
^

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun  2 07:27:49 2017
New Revision: 248814

URL: https://gcc.gnu.org/viewcvs?rev=248814=gcc=rev
Log:
Backported from mainline
2017-05-30  Jakub Jelinek  

PR libgomp/80822
* config/linux/affinity.c (gomp_affinity_init_level_1): New function.
(gomp_affinity_init_level): Use it.  Always analyze the core and thread
sibling lists, depending on level just pick up what CPUs to put
together into a place vs. whether add multiple ordered places.

Modified:
branches/gcc-7-branch/libgomp/ChangeLog
branches/gcc-7-branch/libgomp/config/linux/affinity.c

[Bug c++/80950] New: GCC about template bug

[kmp53 at sina dot com]

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

Bug ID: 80950
   Summary: GCC about template bug
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kmp53 at sina dot com
  Target Milestone: ---

There's no problem around GCC5.3, and now GCC6 can't compile the code until the
latest GCC7.1.
templatestruct Cn{
  template int get(){return N;}
};
template
struct Pr:Cn {
  void fn(){
this->get<1>();//①
  }
};
GCC7.1 prompt:
'expected, primary-expression, before') 'token.  in line ①
The GCC6 prompt is different,but there is an error.
And I used the latest VS2017 compiler is no problem.

[Bug fortran/80918] [6/7/8 Regression] Assumed size whole array rejected in depend clause

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun  2 07:10:10 2017
New Revision: 248813

URL: https://gcc.gnu.org/viewcvs?rev=248813=gcc=rev
Log:
PR fortran/80918
* openmp.c (resolve_omp_clauses): Fix a typo.

* gfortran.dg/gomp/pr80918.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/gomp/pr80918.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/openmp.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/80918] [6/7/8 Regression] Assumed size whole array rejected in depend clause

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun  2 07:07:29 2017
New Revision: 248812

URL: https://gcc.gnu.org/viewcvs?rev=248812=gcc=rev
Log:
PR fortran/80918
* openmp.c (resolve_omp_clauses): Fix a typo.

* gfortran.dg/gomp/pr80918.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr80918.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug objc/80949] ICE in do_warn_duplicated_branches_r

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I can't reproduce; I get some errors:

$ ./cc1obj -quiet nsselect.mi  -fobjc-exceptions
In file included from lisp.h:39:0,
 from nsselect.m:32:
../lib/intprops.h:91:1: error: static assertion failed: "verify (TYPE_MINIMUM
(long int) == LONG_MIN)"
In file included from lisp.h:39:0,
 from nsselect.m:32:
../lib/intprops.h:92:1: error: static assertion failed: "verify (TYPE_MAXIMUM
(long int) == LONG_MAX)"
In file included from nsselect.m:32:0:
lisp.h:197:1: error: static assertion failed: "verify (BITS_WORD_MAX >>
(BITS_PER_BITS_WORD - 1) == 1)"
nsselect.m: In function ‘ns_string_from_pasteboard’:
nsselect.m:274:7: error: cannot find interface declaration for
‘NXConstantString’