[Bug c++/84197] Segmentation fault when setting -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-05
 Ever confirmed|0   |1
  Known to fail||7.3.1, 8.0

--- Comment #1 from Richard Biener  ---
Confirmed.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug c++/70401] [c++1z on mingw]compile variadic template failed

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jyong at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  ---
Let's add Jonathan in CC.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |7.3.1
   Target Milestone|--- |7.4

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-05
   Target Milestone|--- |7.4
Summary|[7 Regression] double   |[7/8 Regression] double
   |arithmetic on x86 no longer |arithmetic on x86 no longer
   |rounds to nearest   |rounds to nearest
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
Confirmed.  We somehow lose the volatile qualifiers.  I'll have a look.

[Bug c++/82782] ICE: nested template alias and specialized template with auto template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #3 from Paolo Carlini  ---
Fixed for 8.1.0.

[Bug c++/82782] ICE: nested template alias and specialized template with auto template parameter

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Feb  5 11:15:55 2018
New Revision: 257388

URL: https://gcc.gnu.org/viewcvs?rev=257388=gcc=rev
Log:
2018-02-05  Paolo Carlini  

PR c++/82782
* g++.dg/cpp1z/inline-var4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/inline-var4.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84188] assume non-null malloc pointers are distinct

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

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

*** This bug has been marked as a duplicate of bug 13962 ***

[Bug tree-optimization/13962] [tree-ssa] make "fold" use alias information to optimize pointer comparisons

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
*** Bug 84188 has been marked as a duplicate of this bug. ***

[Bug c/84179] -save-temps breaks implicit-fallthrough comment heuristic

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
Version|unknown |7.2.0

--- Comment #1 from Richard Biener  ---
I think we have a dup for this.

[Bug target/27855] [6/7/8 regression] reassociation causes the RA to be confused

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #58 from Aldy Hernandez  ---
(In reply to rguent...@suse.de from comment #57)

> > IMO, "manually optimized" doesn't seem to merit spending more time on this. 
> >  As
> > you mention, not real world enough :).  May I suggest WONTFIX, but willing 
> > to
> > reopen if someone cares enough to un-obfuscate the code?
> 
> I'd say FIXED - that sounds nicer ;)

My pleasure!

[Bug target/27827] [4.0 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

[aldyh at gcc dot gnu.org]

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

Bug 27855 Summary: [6/7/8 regression] reassociation causes the RA to be confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855

   What|Removed |Added

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

[Bug target/84172] option "-O3" create slower code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Indeed fixed in GCC 7.

[Bug c++/84171] [8 Regression] ICE with -Wsign-compare

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug target/27855] [6/7/8 regression] reassociation causes the RA to be confused

[rguenther at suse dot de]

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

--- Comment #57 from rguenther at suse dot de  ---
On Mon, 5 Feb 2018, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
> 
> --- Comment #56 from Aldy Hernandez  ---
> (In reply to Richard Biener from comment #55)
> 
> > Note the original report used -O and Aldhy used -O2 but we are talking
> > about a benchmark and when you use -ffast-math you also use -O3.
> 
> Thanks, I will keep a note of this for next time.  FWIW, I used the same flags
> as the last time this was reconfirmed, which was comment #52.  I also saw a
> bunch of runs at -O2 by Uros, which likely influenced me.
> 
> > The benchmark is somewhat badly written (manually "optimized") so our
> > vectorization attempts fail.
> > 
> > Overall conclusion is I'm unsure if it's worth pursuing this bug further?
> > There is a register pressure issue left but the testcase maybe not
> > real-world enough?  That is, I would usually recommend to first un-obfuscate
> > the manually optimized code.
> 
> IMO, "manually optimized" doesn't seem to merit spending more time on this.  
> As
> you mention, not real world enough :).  May I suggest WONTFIX, but willing to
> reopen if someone cares enough to un-obfuscate the code?

I'd say FIXED - that sounds nicer ;)

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

[aldyh at gcc dot gnu.org]

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

--- Comment #13 from Aldy Hernandez  ---
(In reply to Jan Hubicka from comment #12)
> Set component as IPA so it stays at my radar.  It is probably too late for
> GCC 8 but I will try to finally take a look next stage1. Inlining those
> constructions is often beneficial because things subsequently simplifies. 
> We would probably need bit more context dependent metrics than just single
> call window we do now.  This however is hard to do becuase that makes number
> of inlining decisions to explode.

Thanks Jan.

What's the protocol here, do we move the target milestone to GCC 9, or do we
leave it as is?  Thanks.

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
It's really fixed on trunk since r257023.

[Bug target/27855] [6/7/8 regression] reassociation causes the RA to be confused

[aldyh at gcc dot gnu.org]

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

--- Comment #56 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #55)

> Note the original report used -O and Aldhy used -O2 but we are talking
> about a benchmark and when you use -ffast-math you also use -O3.

Thanks, I will keep a note of this for next time.  FWIW, I used the same flags
as the last time this was reconfirmed, which was comment #52.  I also saw a
bunch of runs at -O2 by Uros, which likely influenced me.

> The benchmark is somewhat badly written (manually "optimized") so our
> vectorization attempts fail.
> 
> Overall conclusion is I'm unsure if it's worth pursuing this bug further?
> There is a register pressure issue left but the testcase maybe not
> real-world enough?  That is, I would usually recommend to first un-obfuscate
> the manually optimized code.

IMO, "manually optimized" doesn't seem to merit spending more time on this.  As
you mention, not real world enough :).  May I suggest WONTFIX, but willing to
reopen if someone cares enough to un-obfuscate the code?

[Bug sanitizer/84210] New: __ubsan_handle_builtin_unreachable shoun't be const

[ryabinin.a.a at gmail dot com]

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

Bug ID: 84210
   Summary: __ubsan_handle_builtin_unreachable shoun't be const
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryabinin.a.a at gmail dot com
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: ---

Compiling the linux kernel with gcc-8 gives this warning:

lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a
built-in function '__ubsan_handle_builtin_unreachable' because it conflicts
with attribute 'const' [-Werror=attributes]


It seems that GCC defines __ubsan_handle_builtin_unreachable with noreturn and
const attributes:

DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE,
  "__ubsan_handle_builtin_unreachable",
  BT_FN_VOID_PTR,
  ATTR_COLD_CONST_NORETURN_NOTHROW_LEAF_LIST)

And const doesn't make any sense for function that returns void or doesn't
return at all.
Shouldn't it be just ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST ?

[Bug target/84209] [avr] Don't split SP in split2

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||avr
   Priority|P3  |P4
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-05
   Assignee|unassigned at gcc dot gnu.org  |gjl at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/84209] New: [avr] Don't split SP in split2

[gjl at gcc dot gnu.org]

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

Bug ID: 84209
   Summary: [avr] Don't split SP in split2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Since r242907 there is a split for HI moved that might also split SP.  This
might lead to wrong code.

Using -fdisable-rtl-split2 might do as a work-around.

[Bug lto/70929] [6/7/8 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Mon, 5 Feb 2018, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70929
> 
> --- Comment #7 from Jan Hubicka  ---
> Hmm, this actually looks reasonable for me too.  Shall I give it a try and
> figure out what incompatibilities we get here?

That would be nice.  Maybe throw it at firefox and dump somewhere
when the two variants decide differently?

> What about K prototypes?

No idea what types_compatible_p does with them...

[Bug tree-optimization/39612] [6/7/8 Regression] LIM inserts loads from uninitialized local memory

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2009-10-05 20:09:44 |2018-2-5

--- Comment #30 from Richard Biener  ---
Yes, the warning is gone because we no longer warn in the late VRP pass... 
re-confirmed for the "missed optimization".

[Bug tree-optimization/38785] [6/7/8 Regression] huge performance regression on EEMBC bitmnp01

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|NEW
   Last reconfirmed|2010-02-19 12:17:54 |2018-2-5

--- Comment #49 from Richard Biener  ---
The testcase from comment#3 still reproduces the issue for me:

   [local count: 955630223]:
  # cstore_55 = PHI <2147483647(4), 0(5)>
  # prephitmp_87 = PHI <3221225470(4), 1073741823(5)>
  # prephitmp_88 = PHI <3937053352(4), 1789569705(5)>
... many more...
  # prephitmp_116 = PHI <2934894317(4), 787410670(5)>
  # prephitmp_117 = PHI <2505397588(4), 357913941(5)>
  MEM[(void *)_3] = cstore_55;
  _7 = *_4;
...

There's the old issue of PRE lacking a cost model (and undoing PRE
being impossible for these cases).

[Bug gcov-profile/84137] Typo in gcov online documentation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||6.4.0, 7.3.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk, queued for backports.

[Bug gcov-profile/84137] Typo in gcov online documentation

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon Feb  5 09:59:16 2018
New Revision: 257384

URL: https://gcc.gnu.org/viewcvs?rev=257384=gcc=rev
Log:
Fix GCOV documentation (PR gcov-profile/84137).

2018-02-05  Martin Liska  

PR gcov-profile/84137
* doc/gcov.texi: Fix typo in documentation.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gcov.texi

[Bug target/27855] [6/7/8 regression] reassociation causes the RA to be confused

[rguenth at gcc dot gnu.org]

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

--- Comment #55 from Richard Biener  ---
I think the original report is about x87 math vs. SSE math.  It's a bit hard to
benchmark this through the releases given changes in tuning and vector feature
sets (-march=native is out of the question).

So I use -O3 -ffast-math -DREPS=10 -m32 as base and see

  ISA4.3.6  4.6.4  4.8.5  7.2
-mno-sse  1855   6930   4618   5623
-msse2 -mfpmath=sse   1967   6945   4744   6472
-m64  2977   6917   4935   6205

note I edited the benchmark and put noinline,noclone attributes on the
gemm_atlas function.  I benchmarked on a broadwell system with minimal
CPU frequency boosting but still varying REPS varies the reported MFLOPS
_a lot_ (but individual runs are somewhat stable, for the last reported
number 6205 I also can get 6331 or 6186).  I used the attached
benchmark, the cited URL doesn't work anymore.

So there's still an appearant regression, the trunk numbers aren't very
different
from the 7.2 results, the 4.6.4 variant is still fastest and we recovered to
current levels with 4.9.4 already (just checked -m64 across all releases).

With -march=native I get to new heights obviously because we use things like
FMA, AVX, etc. if I add just -mavx to 4.6.4 it's not faster than without
but 7.2 improves to 6628 for example (4.6.4 doesn't know AVX2 and -mfma
results in bogus assembler being generated...).

If I look at the generated code for -m64 (with just SSE) we no longer
spill a lot in the inner loop (only once) and we don't vectorize.  4.6.4
manages to avoid any spilling in the computation (even in the outer loop).
So the original analysis (RA sucks) still holds.

Note the original report used -O and Aldhy used -O2 but we are talking
about a benchmark and when you use -ffast-math you also use -O3.

Note the biggest regression we still see is with x87 math - I think we
can reasonably disregard that now.

The benchmark is somewhat badly written (manually "optimized") so our
vectorization attempts fail.

Overall conclusion is I'm unsure if it's worth pursuing this bug further?
There is a register pressure issue left but the testcase maybe not
real-world enough?  That is, I would usually recommend to first un-obfuscate
the manually optimized code.

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
Weird, for me I see the problem reproducing with
$ ~/8-install/bin/g++ --version
g++ (GCC) 8.0.1 20180124 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

but not with
$ ~/8-install-slow/bin/g++ --version
g++ (GCC) 8.0.1 20180205 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

so it seems the problem went away in those few days but I do not recall
anything related being commit.  Martin, would it be possible to bisect this?
(hope it is not --enable-checking=release used to build first compiler)

[Bug c++/81917] [6/7/8 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3004

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  ---
This variant causes the same ICE and it's a tad cleaner:

template  using a = void;
template  struct b
{
  typedef int c;
}; template  class b;
template ::c> class f;
template  class g { };
template  class h
{
  class i;
  typedef g j; class i
  {
j k;
  };
}; typename h::

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #18 from Jan Hubicka  ---
Let me try to understand the problem.  In .res file we have:
328 e6522ac3d089e792 PREVAILING_DEF
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev
333 e6522ac3d089e792 PREVAILING_DEF_IRONLY
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev

We end up privatizing _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED2Ev
and keep _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev external.
This seems correct but for some reason we do not emit .globl at the time we
produce the alias. This is because TREE_PUBLIC of alias->decl is not set.
Wonder why that happens.

do_assemble_alias contains:
  /* Make name accessible from other files, if appropriate.  */ 

  if (TREE_PUBLIC (decl) || TREE_PUBLIC (orig_decl))
{   
  globalize_decl (decl);
  maybe_assemble_visibility (decl); 
}   

which looks like it is impossible to produce non-public alias of public symbol
that looks quite wrong (we do make use of local aliases to public symbols and
we do not want those exported). Perhaps we never realy set TREE_PUBLIC of those
aliases as expected?

[Bug gcov-profile/83879] __gcov_dump doesn't work with dlopen-ed libraries

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||8.0
  Known to fail||6.4.0, 7.3.0

--- Comment #7 from Martin Liška  ---
Fixed on trunk, queued for backports.

[Bug gcov-profile/83879] __gcov_dump doesn't work with dlopen-ed libraries

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Mon Feb  5 09:19:18 2018
New Revision: 257383

URL: https://gcc.gnu.org/viewcvs?rev=257383=gcc=rev
Log:
Document --dynamic-list-data option for --coverage usage.

2018-02-05  Martin Liska  

PR gcov-profile/83879
* doc/gcov.texi: Document necessity of --dynamic-list-data when
using dlopen functionality.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gcov.texi

[Bug target/68028] [6/7/8 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Nick Clifton from comment #9)
> Created attachment 43318 [details]
> Proposed patch
> 
> Hi Guys,
> 
> Richard was right - there is code that sets extra flags based upon the
> setting of -mcpu.  In fact it is just before the code he mentioned:
> 
>  /* For the E500 family of cores, reset the single/double FP flags to let us
>  check that they remain constant across attributes or pragmas.  */
> 
>   switch (rs6000_cpu)
> {
> case PROCESSOR_PPC8540:
> case PROCESSOR_PPC8548:
> case PROCESSOR_PPCE500MC:
> case PROCESSOR_PPCE500MC64:
> case PROCESSOR_PPCE5500:
> case PROCESSOR_PPCE6500:
>   rs6000_single_float = 0;
>   rs6000_double_float = 0;
>   break;
> 
> default:
>   break;
> }
> 
> This has lead me to propose the attached patch.  Basically what it does is to
> tell the rs6000 backend that when it is operating in LTO mode, it should
> trust
> the function attributes and not the command line. 
> 
> My assumption here is that if there are any discrepancies between real 
> function attributes (ie not ones generated for LTO) and the command line,
> then these will have been detected and reported during the original 
> compilation.
> 
> What do people think ?  Is the patch OK ?

If the backend doesn't support mixing of -msingle-float/-mno-single-float
within
a compilation unit then this will only work if the user didn't mix TUs
with conflicting setting at link-time.  So the following will not be diagnosed
but will instead have conflicting IL accepted silently with your
patch (with unknown effect):

> gcc -c t1.c -flto -msingle-float
> gcc -c t2.c -flto -mdouble-float
> gcc t1.o t2.o -flto

so I think it's better to have rs6000_single_float/rs6000_double_float
initialized to for example -1 and allow changing that a _single_ time,
verifying all following uses will match.

But I don't see why mixing shouldn't be possible?  Maybe the target wants
to instead limit inlining of functions with differing settings instead?
If the caller/callee uses FP? (see i386.c:ix86_can_inline_p use of
cgraph_node::get (callee))->fp_expressions to guard similar things).

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[clyon at gcc dot gnu.org]

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

--- Comment #11 from Christophe Lyon  ---
My setup uses armeb-none-linux-gnueabihf (as opposed to armeb-eabi as you
report). I have never tried armeb-eabi.

I am also using qemu as simulator (in user mode, not in system mode).

The failure in initialise_monitor_handles indicates a problem in the startup
code, while initializing the semi-hosting interface.

Can you try qemu?

[Bug gcov-profile/84137] Typo in gcov online documentation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-05
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thanks for the report, I'll fix it soon.

[Bug gcov-profile/84107] indirect call profiling broken with multiple DSOs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-05
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thanks Alexander for filling that.

[Bug tree-optimization/84106] loop distribution cost-model needs work

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-05
 CC||amker at gcc dot gnu.org
Summary|gcc is not able to  |loop distribution
   |vectorize code for 1D   |cost-model needs work
   |array, but does so for 2D   |
   |array of the same size  |
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
Confirmed.

[Bug ipa/65797] [6/7/8 regression] IPA ICF causes function to be emitted with no debug line info

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|hubicka at ucw dot cz  |unassigned at gcc dot 
gnu.org

--- Comment #16 from Jan Hubicka  ---
We need someone who understand debug info to decide what to do.  So I am
unasigning myself :)

[Bug ipa/80726] [7/8 Regression] Destructor not inlined anymore (regression)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #5 from Jan Hubicka  ---
This really looks like a conflict with function splitting and comdats.
We obviously can't introduce call to comdat local function but we indeed can
bring function out of the comdat group. For that we, of course, would need to
check how big that function is (account cross-module unsharing) into cost of
the inline decision which will need bit of work.

ipa-sra is currently bringing functions out of comdats "on wild" (i.e. without
bounds on how big the function can be). I will play with this. Probably bit too
involved for stage4 though.

[Bug lto/70929] [6/7/8 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Hmm, this actually looks reasonable for me too.  Shall I give it a try and
figure out what incompatibilities we get here?

What about K prototypes?

[Bug middle-end/84200] r256888 causes 30% performance regression of 519.lbm_r at -Ofast generic tuning on Zen

[sebastian.peryt at intel dot com]

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

Sebastian Peryt  changed:

   What|Removed |Added

 CC||sebastian.peryt at intel dot 
com

--- Comment #1 from Sebastian Peryt  ---
I'm not sure if that can be treated as duplicate but that performance
degradation looks like is related to PR84149.

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

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa

--- Comment #12 from Jan Hubicka  ---
Set component as IPA so it stays at my radar.  It is probably too late for GCC
8 but I will try to finally take a look next stage1. Inlining those
constructions is often beneficial because things subsequently simplifies.  We
would probably need bit more context dependent metrics than just single call
window we do now.  This however is hard to do becuase that makes number of
inlining decisions to explode.

[Bug sanitizer/84208] fsanitize-address-use-after-scope Not working for ARM

[akhilesh.k at samsung dot com]

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

--- Comment #2 from Akhilesh Kumar  ---
> Does it work on non-changed gcc 7.2 on arm? 
  Not yet verified because unable to cross compile gcc 7.2.  

> And with arm do mean arm-linux-gnueabi as the target or aarch64-linux-gnu?
  I am using arm-*-gnueabi target