[Bug c/85310] optimization ignoring strlen() results

[dvyukov at google dot com]

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

--- Comment #6 from Dmitry Vyukov  ---
It seems to me that compiler is fine here and we just have a bug in kernel
code.
Result of strlen called on char[16] can't possibly by >15 (without causing
undefined behavior -- reading past the end of the object -- in which case
result and anything else does not matter). So the "if (res >= 16) res = 15"
check is always a no-op and can be removed (for programs without undefined
behavior).
In this program strlen returns 32, but that's because the program contains
undefined behavior -- you can't call strlen on non-zero-terminated objects.

[Bug c/85310] optimization ignoring strlen() results

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Kees Cook from comment #4)
> But it's optimizing away the check. 

That what undefined means.

> If strlen() were suddenly acting like
> strnlen(), that'd be one thing, but the return value from strlen() is being
> used by the memcpy() without the actual test in between. That's not sensible.

It is undefined if strlen reads past an array bounds, so in theory it could
have zero'ed out your whole hard drive and sent your boss an email saying you
quit.

[Bug c/85310] optimization ignoring strlen() results

[kees at outflux dot net]

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

--- Comment #4 from Kees Cook  ---
But it's optimizing away the check. If strlen() were suddenly acting like
strnlen(), that'd be one thing, but the return value from strlen() is being
used by the memcpy() without the actual test in between. That's not sensible.

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[royiavital at yahoo dot com]

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

--- Comment #19 from Royi  ---
This comment could be important:

https://stackoverflow.com/questions/30928265/mingw64-is-incapable-of-32-byte-stack-alignment-required-for-avx-on-windows-x64?noredirect=1#comment86499640_30928265.

Hopefully you'll find a way to bring AVX to Windows 64 using GCC.

Thank You.

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to René J.V. Bertin from comment #4)
> Any news on this front?

Last I heard from Iain he was still having to deal with water damage to his
office...

[Bug preprocessor/39533] [6/7/8 Regression] -MM may list a header file twice

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #21 from Eric Gallager  ---
(In reply to Eric Gallager from comment #20)
> GCC 5 branch is being closed.
> 
> (Why is this still in WAITING?)

Closing due to rule that bugs in WAITING for 3 or more months with no response
can be closed.

[Bug bootstrap/45174] Make fails in zlib

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #31 from Eric Gallager  ---
(In reply to Eric Gallager from comment #30)
> Is there a reason this bug is still in WAITING?

No response; I'm going to close this.

[Bug c/85310] optimization ignoring strlen() results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
If they want to optimize based on the size of the array then disable the
builtin (and don't use The __builtin_ specific function).

Basically this code is undefined and can do anything.  If anything maybe
strnlen should be used instead...

[Bug c/85310] optimization ignoring strlen() results

[kees at outflux dot net]

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

Kees Cook  changed:

   What|Removed |Added

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

--- Comment #2 from Kees Cook  ---
I realize the compiler would like like it to be undefined, but it's just not:
this worked before, and there's nothing about a static-sized character array
that says it will be NULL terminated. No optimization of strlen() can make that
assumption, since it's the _contents_ and not the _size_ that determine the
results of strlen().

Specifically, this breaks the Linux kernel's FORTIFY_SOURCE implementation,
which is exactly trying to protect against these kinds of unexpected memory
contents, etc. With the ? : optimized away FORITFY_SOURCE ends up becoming
actively dangerous.

[Bug c++/84221] [6/7 Regression] spurious -Wunused warning on a variable of a template type declared unused

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
As per subsequent discussion
(https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00203.html and follow-ups), the
warning in the original test case is expected and desirable.  The patch in
r259098 doesn't change that but has GCC issue a warning for uses of the primary
template.

[Bug c/85310] optimization ignoring strlen() results

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This code is undefined as the strlen of src is undefined as the you read past
the end of the src array.

[Bug c/85310] New: optimization ignoring strlen() results

[kees at outflux dot net]

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

Bug ID: 85310
   Summary: optimization ignoring strlen() results
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
  Target Milestone: ---

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

Something is gcc 8 is broken when dealing with strlen() results.


The correct behavior is seen in earlier versions of the compiler:

$ gcc --version
gcc (Ubuntu 7.3.0-14ubuntu1) 7.3.0
...
$ gcc -Wall -O2 -o testcase testcase.c
$ ./testcase 
MY_SIZE: 16
dst: 15
done...


The bad version happens in the current gcc trunk:


$ /home/kees/bin/gcc-snapshot/gcc --version
gcc (Ubuntu 20180322-1ubuntu1) 8.0.1 20180322 (experimental) [trunk revision
258755]
...
$ /home/kees/bin/gcc-snapshot/gcc -Wall -O2 -o testcase testcase.c
$ ./testcase 
MY_SIZE: 16
dst: 32
done...
Segmentation fault (core dumped)


Checking with godbolt confirms there is no test against "16" in the output:

https://godbolt.org/g/63Sbir

[Bug demangler/85309] New: demangler failed with signal 11

[lyberta at lyberta dot net]

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

Bug ID: 85309
   Summary: demangler failed with signal 11
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lyberta at lyberta dot net
  Target Milestone: ---

Try to run my C++17 application under GDB I get:

/build/gdb-uGdIdO/gdb-7.12/gdb/cp-support.c:1600: demangler-warning: unable to
demangle
'_ZSt7forwardIRZN3ftz6Engine20ClientNetworkHandler13ProcessEventsEvEUlRT_E_EOS3_RNSt16remove_referenceIS3_E4typeE'
(demangler failed with signal 11)
Unable to dump core, use `ulimit -c unlimited' before executing GDB next time.
/build/gdb-uGdIdO/gdb-7.12/gdb/cp-support.c:1615: demangler-warning: unable to
demangle
'_ZSt7forwardIRZN3ftz6Engine20ClientNetworkHandler13ProcessEventsEvEUlRT_E_EOS3_RNSt16remove_referenceIS3_E4typeE'
(demangler failed with signal 11)

It is a lambda inside ftz::Engine::ClientNetworkHandler::ProcessEvents.

[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #20 from Jonathan Wakely  ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00424.html

[Bug c++/85227] [7 Regression] ICE with structured binding of a forward declared variable

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |structured binding of a |structured binding of a
   |forward declared variable   |forward declared variable

--- Comment #4 from Paolo Carlini  ---
Fixed int trunk so far.

[Bug c++/85227] [7/8 Regression] ICE with structured binding of a forward declared variable

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Apr  9 22:33:35 2018
New Revision: 259259

URL: https://gcc.gnu.org/viewcvs?rev=259259=gcc=rev
Log:
/cp
2018-04-09  Paolo Carlini  

PR c++/85227
* decl.c (cp_finish_decomp): In a template, if the type is incomplete
issue a pedwarn and defer trying to do bindings.

/testsuite
2018-04-09  Paolo Carlini  

PR c++/85227
* g++.dg/cpp1z/decomp44.C: New.
* g++.dg/cpp1z/decomp45.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp44.C
trunk/gcc/testsuite/g++.dg/cpp1z/decomp45.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85259] [8 Regression] Missing -Wstringop-overflow= since r256683

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|8.0 |9.0

--- Comment #4 from Jeffrey A. Law  ---
So the general guidance we got earlier from Richie was to defer the missing
warnings until gcc-9.

[Bug c++/85308] Stringstream constructor fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
That's not a bug, it's how stringstream is supposed to work.

Use
std::stringstream con(BEFORE, std::ios::in|std::ios::out|std::ios::ate);
if you want insertions to happen at the end, after the initial value.

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  ---
So I went and found pr68548 which is related, but clearly different.

Just thinking out loud here, I think we can pick up this missed jump thread by
recording _1 & 1 == 0 on the false edge of the first conditional (when we know
that _1 & 3 == 0).  It doesn't scale well in the general case, but when there's
just a few bits in the mask it might be reasonable.

That ought to allow us to determine that _4 == 0 when bb4 is reached via bb2
and thread the jump.  Not planning to look at any implementation for gcc-8
though.

[Bug fortran/83064] DO CONCURRENT and auto-parallelization

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords|wrong-code  |missed-optimization
   Target Milestone|8.0 |9.0
Summary|[8 Regression] DO   |DO CONCURRENT and
   |CONCURRENT inconsistent |auto-parallelization
   |results |

--- Comment #27 from Thomas Koenig  ---
I have committed the workaround. This is no longer a regression,
removing the regression marker.

If autopar is modified so that the parallel annotation works with
DO CONCURRENT, one needs to search for the string "PR 83064" for
the part that needs to be undone to remove the workaround.

[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> Or build them in-tree, which automatically builds them that way. That avoids
> the need to install them separately at all.

You may need to control which version you build on specific platforms though so
I wouldn't recommend in-tree build.

[Bug fortran/83064] [8 Regression] DO CONCURRENT inconsistent results

[tkoenig at gcc dot gnu.org]

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

--- Comment #26 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Apr  9 21:52:05 2018
New Revision: 259258

URL: https://gcc.gnu.org/viewcvs?rev=259258=gcc=rev
Log:
2018-04-09  Thomas Koenig  

PR fortran/83064
* trans-stmt.c (gfc_trans_forall_loop): Remove annotation for
parallell processing of DO CONCURRENT -ftree-parallelize-loops
is set.

2018-04-09  Thomas Koenig  

PR fortran/83064
* gfortran.dg/do_concurrent_5.f90: New test.
* gfortran.dg/vect/vect-do-concurrent-1.f90: Adjust dg-bogus
message.


Added:
trunk/gcc/testsuite/gfortran.dg/do_concurrent_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/vect/vect-do-concurrent-1.f90

[Bug debug/65821] [6/7/8 regression] incorrect debug line # info for main

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
Fixed, closing.

[Bug c++/85308] New: Stringstream constructor fails

[cwgii_bccg at julianlocals dot com]

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

Bug ID: 85308
   Summary: Stringstream constructor fails
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cwgii_bccg at julianlocals dot com
  Target Milestone: ---

Created attachment 43888
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43888=edit
-save-temps and example

When specifying an initial value in a std::streamstring to resulting value of
the item is wrong.

[Bug c++/85279] [6/7/8 Regression] Broken diagnostic for decltype

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Mon Apr  9 21:16:05 2018
New Revision: 259257

URL: https://gcc.gnu.org/viewcvs?rev=259257=gcc=rev
Log:
PR c++/85279 - dump_expr doesn't understand decltype.

* error.c (dump_expr): Handle DECLTYPE_TYPE.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype67.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c

[Bug fortran/85307] New: Consistent handling of out-of-bounds access

[tkoenig at gcc dot gnu.org]

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

Bug ID: 85307
   Summary: Consistent handling of out-of-bounds access
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Currently, we sometimes issue errors and mostly issue
warnings for when a compile-time out-of-bounds-access is detected.

Example:

a.f90:4:30:

   integer, parameter :: x = b(4)
  1
Error: Index in dimension 1 is out of bounds at (1)
a.f90:5:12:

   print *,b(2:4)
1
Warning: Upper array reference at (1) is out of bounds (4 > 3) in dimension 1
a.f90:6:12:

   print *,b(4)
1
Warning: Array reference at (1) is out of bounds (4 > 3) in dimension 1
a.f90:8:14:

   do i=1,5
  2
 print *,b(i)
  1
Warning: Array reference at (1) out of bounds (5 > 3) in loop beginning at (2)

At the very least, the warnings about the parameter array should
be hard errors, and possibly others as well.

Let the discussions begin :-)

[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Eric Botcazou from comment #4)
> I personally build the GMP/MPFR/MPC libraries with --disable-shared.

Or build them in-tree, which automatically builds them that way. That avoids
the need to install them separately at all.

https://gcc.gnu.org/wiki/InstallingGCC

[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Apr  9 21:05:13 2018
New Revision: 259256

URL: https://gcc.gnu.org/viewcvs?rev=259256=gcc=rev
Log:
2018-04-09  Thomas Koenig  

PR fortran/51260
* resolve.c (resolve_variable): Simplify cases where access to a
parameter array results in a single constant.

2018-04-09  Thomas Koenig  

PR fortran/51260
* gfortran.dg/parameter_array_element_3.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/parameter_array_element_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10

[subscribe at teskor dot de]

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

--- Comment #7 from Michael Teske  ---
(In reply to Eric Botcazou from comment #6)
> > Why not add the directory to the RPATH of the created binaries? 
...
> > Are there any reasons against
> > doing it?
> 
> Yes, I don't think that we want to hardcode run-time paths by default.

Usually, RPATH does not hardcode the run time path library path, it is still
overridable with LD_LIBRARY_PATH, it just provides a default if LD_LIBRARY_PATH
is not set. IMHO it would be convenient to have the possibility (need not be
the default, just an option to configure) to have gcc finding it's library in
the locations where they were when gcc was built. If one needs to have
different versions of some utilities (possibly pre-built from different
sources) it can be difficult if not impossible to maintain a useful
LD_LIBRARY_PATH. Anyway, luckily the rpath tool exists for solaris so I can
"tune" the gcc binaries after the build.

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen  ---
(In reply to Jan Hubicka from comment #1)
> Pat, can you try to figure out what value of min-speedup is neeed to recover
> from this regression?

Using r257582, either of the following options restores the behavior of not
inlining the mainGtU call and eliminates the performance regression.

--param inline-min-speedup=18

--param max-inline-insns-auto=24

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

[whh8b at virginia dot edu]

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

Will Hawkins  changed:

   What|Removed |Added

 CC||whh8b at virginia dot edu

--- Comment #5 from Will Hawkins  ---
I am using this as a jumping-off point to get involved with contributing code
to gcc. I have nothing to offer yet, but I wanted to note here that I am going
to start looking into this. 

Will

[Bug c++/85285] [6/7/8 Regression] ICE with flexible array in union

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85279] [6/7/8 Regression] Broken diagnostic for decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-09
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/85262] [6/7/8 Regression] Trouble with constructor and -fpermissive

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Apr  9 20:53:31 2018
New Revision: 259255

URL: https://gcc.gnu.org/viewcvs?rev=259255=gcc=rev
Log:
PR c++/85262 - ICE with redundant qualification on constructor.

* call.c (build_new_method_call_1): Move make_args_non_dependent
after A::A() handling.

Added:
trunk/gcc/testsuite/g++.dg/parse/ctor10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Thomas Koenig  ---
I reran this with a revision that failed previously and
found nothing.

Looks like a bad case of cosmic rays, or (remotely possible)
some race condition triggered by my excessive use of "make -j".

Anyway, closing; sorry for the noise.

[Bug c++/85277] [8 Regression] Broken diagnostic for offsetof with static member function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[arnd at linaro dot org]

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

--- Comment #6 from Arnd Bergmann  ---
I found that older versions (gcc-5 and before) did not warn when the type gets
changed to bitfield of '_Bool' rather than 'unsigned int'. It seems that this
was only because they tested each bit separately in the _Bool case rather than
combining the first two comparisons into a &3 mask.

[Bug c++/85277] [8 Regression] Broken diagnostic for offsetof with static member function

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Apr  9 20:40:06 2018
New Revision: 259254

URL: https://gcc.gnu.org/viewcvs?rev=259254=gcc=rev
Log:
PR c++/85277 - ICE with invalid offsetof.

* semantics.c (finish_offsetof): Avoid passing non-DECL to %qD.
Adjust -Winvalid-offsetof diagnostic to say conditionally supported.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/g++.dg/ext/builtin-offsetof1.C
trunk/gcc/testsuite/g++.dg/other/offsetof3.C
trunk/gcc/testsuite/g++.dg/other/offsetof5.C
trunk/gcc/testsuite/g++.dg/other/offsetof8.C

[Bug c++/85194] ICE with structured binding in broken for-loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed for GCC8.  error-recovery, not backporting to release branches.

[Bug c++/85264] [7/8 Regression] ICE with extraneous template parameter list

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Apr  9 19:50:03 2018
New Revision: 259253

URL: https://gcc.gnu.org/viewcvs?rev=259253=gcc=rev
Log:
PR c++/85264 - ICE with excess template-parameter-list.

* parser.c (cp_parser_check_template_parameters): Add template_id_p
parameter.  Don't allow an extra template header if true.
(cp_parser_class_head): Pass template_id_p.
(cp_parser_elaborated_type_specifier): Likewise.
(cp_parser_alias_declaration): Likewise.
(cp_parser_check_declarator_template_parameters): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic176.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/85194] ICE with structured binding in broken for-loop

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr  9 19:48:48 2018
New Revision: 259252

URL: https://gcc.gnu.org/viewcvs?rev=259252=gcc=rev
Log:
PR c++/85194
* parser.c (cp_parser_simple_declaration): For structured bindings,
if *maybe_range_for_decl is NULL after parsing it, set it to
error_mark_node.

* g++.dg/cpp1z/decomp43.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp43.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/85306] New: [8 regression] The test cases gcc.dg/pr80463.c, g++.dg/pr80463.C, and gcc.dg/pr83972.c all fail in r259231

[seurer at gcc dot gnu.org]

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

Bug ID: 85306
   Summary: [8 regression] The test cases gcc.dg/pr80463.c,
g++.dg/pr80463.C, and gcc.dg/pr83972.c all fail in
r259231
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

These are new test cases introduced in r259231 and they all fail on powerpc64:

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments -S -o
pr80463.s
cc1plus: warning: var-tracking-assignments changes selective scheduling
output is:
cc1plus: warning: var-tracking-assignments changes selective scheduling

FAIL: g++.dg/pr80463.C  -std=gnu++98 (test for excess errors)
Excess errors:
cc1plus: warning: var-tracking-assignments changes selective scheduling

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++11 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments  -S   -o
pr80463.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++11 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments -S -o
pr80463.s
cc1plus: warning: var-tracking-assignments changes selective scheduling
output is:
cc1plus: warning: var-tracking-assignments changes selective scheduling

FAIL: g++.dg/pr80463.C  -std=gnu++11 (test for excess errors)
Excess errors:
cc1plus: warning: var-tracking-assignments changes selective scheduling

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++14 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments  -S   -o
pr80463.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/pr80463.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++14 -g -fselective-scheduling2 -O2 -fvar-tracking-assignments -S -o
pr80463.s
cc1plus: warning: var-tracking-assignments 

[Bug c++/85305] Parameter pack expression in lambda capture list fails as part of a fold expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-09
 Ever confirmed|0   |1

[Bug preprocessor/85211] -isystem automatically adds extern "C" to includes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-09
 Ever confirmed|0   |1

--- Comment #8 from Jonathan Wakely  ---
(In reply to blastrock from comment #7)
> My initial suggestion was to mention that behavior in the documentation, but
> if you think it is not worth it, I guess you can close this bug.

I'm not sure why it's no longer mentioned, so I'll confirm this as a doc bug.

[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-09
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression

[vittorio.romeo at outlook dot com]

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

--- Comment #19 from Vittorio Romeo  ---
(In reply to Jonathan Wakely from comment #18)
> (In reply to Vittorio Romeo from comment #17)
> > Was the patch merged in trunk?
> 
> It was committed to trunk: r251433
> 
> > The following still fails to compile on 20180407
> 
> Could you create a new bug for that please?

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

[Bug c++/85305] New: Parameter pack expression in lambda capture list fails as part of a fold expression

[vittorio.romeo at outlook dot com]

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

Bug ID: 85305
   Summary: Parameter pack expression in lambda capture list fails
as part of a fold expression
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

The following code snippet...

template 
void foo()
{
([i = Is]{}(), ...); 
}

...does not compile on gcc trunk 20180408 with the following error:

: In function 'void foo()':
:4:11: error: parameter packs not expanded with '...':
 ([i = Is]{}(), ...);
   ^~

:4:11: note: 'Is'
:4:16: error: operand of fold expression has no unexpanded
parameter packs
 ([i = Is]{}(), ...);
  ~~^~

Live example on godbolt.org:
https://godbolt.org/g/YBk6L6

[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
I will go back and re-bootstrap with a revision that failed earlier.

[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
There also is

  /* We don't have to handle SIGN_EXTEND here, because even in the
 case of replacing something with a modeless CONST_INT, a
 CONST_INT is already (supposed to be) a valid sign extension for
 its narrower mode, which implies it's already properly
 sign-extended for the wider mode.  Now, for ZERO_EXTEND, the
 story is different.  */


This invalid sharing was never handled before?

[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
I suppose the only way in which they are different is that those are the
only cases that anyone ran into so far.

[Bug preprocessor/85211] -isystem automatically adds extern "C" to includes

[blastrock at free dot fr]

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

--- Comment #7 from blastrock at free dot fr ---
You are right, my bad.

I managed to build it by adding the definition in gcc/config/arm/arm.h .

My initial suggestion was to mention that behavior in the documentation, but if
you think it is not worth it, I guess you can close this bug.

Thanks anyway for your help!

[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> Why not add the directory to the RPATH of the created binaries? I ended up
> doing it manually afterwards by using the rpath utility from
> https://blogs.oracle.com/solaris/changing-elf-runpaths-code-included-v2 ,
> but it could be easily done during linking. Are there any reasons against
> doing it?

Yes, I don't think that we want to hardcode run-time paths by default.

[Bug rtl-optimization/80463] [6/7 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr  9 18:21:03 2018
New Revision: 259249

URL: https://gcc.gnu.org/viewcvs?rev=259249=gcc=rev
Log:
PR rtl-optimization/80463
* g++.dg/pr80463.C: Add -w to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/pr80463.C

[Bug c++/85262] [6/7/8 Regression] Trouble with constructor and -fpermissive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Are you sure you e.g. haven't svn/git updated the tree while bootstrap was
pending?  Can you reproduce it again, or was it just one-off?  If you still
have the tree around, what are the differences in the two objects?

[Bug c++/85269] warn for referenced standard symbols that aren't guaranteed to be declared in a header

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-09
 Ever confirmed|0   |1

[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Not reproduced on gcc110.fsffrance.org again with r259240:
../configure --enable-languages=all --prefix=/home/jakub/GCC
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Comparison successful.

[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
(In reply to Vittorio Romeo from comment #17)
> Was the patch merged in trunk?

It was committed to trunk: r251433

> The following still fails to compile on 20180407

Could you create a new bug for that please?

[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
--- gcc/combine.c.jj2018-03-15 08:36:28.756776703 +0100
+++ gcc/combine.c   2018-04-09 19:33:40.782844115 +0200
@@ -5574,12 +5574,13 @@ subst (rtx x, rtx from, rtx to, int in_d
  if (! x)
x = gen_rtx_CLOBBER (mode, const0_rtx);
}
- else if (CONST_SCALAR_INT_P (new_rtx)
-  && GET_CODE (x) == ZERO_EXTEND)
+ else if (CONST_SCALAR_INT_P (new_rtx) && UNARY_P (x))
{
- x = simplify_unary_operation (ZERO_EXTEND, GET_MODE (x),
-   new_rtx, GET_MODE (XEXP (x,
0)));
- gcc_assert (x);
+ x = simplify_unary_operation (GET_CODE (x), GET_MODE (x),
+   new_rtx,
+   GET_MODE (XEXP (x, 0)));
+ if (!x)
+   return gen_rtx_CLOBBER (VOIDmode, const0_rtx);
}
  else
SUBST (XEXP (x, i), new_rtx);
fixes this, by preventing creation of the invalid RTL where the RTL sharing and
propagate_for_debug might make it reappear somewhere in the IL.
We already did this for SUBREG and ZERO_EXTEND (strangely not for SIGN_EXTEND),
wonder how are the other unary ops different.

[Bug demangler/85304] New: Segmentation fault

[mudongliangabcd at gmail dot com]

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

Bug ID: 85304
   Summary: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mudongliangabcd at gmail dot com
  Target Milestone: ---

Created attachment 43887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43887=edit
PoC to trigger segment fault

We found one segment fault in C++ Demangle Functions. From our simple analysis,
one callq instruction exceed the range of stack region and then cxxfilt
segments fault.

The triggering method is as follows:


```
mkdir obj_test
CFLAGS="-O2 -g -fstack-protector-all -fsanitize=address" ../configure
--enable-shared=no --enable-static=yes
make
cd binutils
gdb ./cxxfilt
(gdb) r < poc_test
```

The corresponding Stack Trace in the gdb:

```
Program received signal SIGSEGV, Segmentation fault.
0x74e5931d in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0
(gdb) info stack
#0  0x74e5931d in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0
#1  0x006a0126 in string_appendn (p=0x7fffe120, s=0x753f60 "(",
n=1) at ./cplus-dem.c:4986
#2  0x0068db7d in demangle_expression (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:1860
#3  0x0068e20a in demangle_integral_value (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120) at ./cplus-dem.c:1916
#4  0x0068eef5 in demangle_template_value_parm (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:2069
#5  0x0068dfac in demangle_expression (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:1895
#6  0x0068e20a in demangle_integral_value (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120) at ./cplus-dem.c:1916
#7  0x0068eef5 in demangle_template_value_parm (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:2069
#8  0x0068dfac in demangle_expression (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:1895
#9  0x0068e20a in demangle_integral_value (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120) at ./cplus-dem.c:1916
#10 0x0068eef5 in demangle_template_value_parm (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:2069
#11 0x0068dfac in demangle_expression (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120, tk=tk_integral) at ./cplus-dem.c:1895
#12 0x0068e20a in demangle_integral_value (work=0x7fffe3b0,
mangled=0x7fffe2c0, 
s=0x7fffe120) at ./cplus-dem.c:1916
..
```

We will try to analyze more deeply to give a detailed report on this bug.

[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This breaks during combine.
We have:
(gdb) p debug_rtx (i3)
(insn 68 67 69 7 (set (reg:SI 89 [ _3 ])
(fix:SI (reg/v:SF 90 [ a ]))) "pr85300.c":4 174 {fix_truncsfsi_sse}
 (expr_list:REG_DEAD (reg/v:SF 90 [ a ])
(nil)))
(gdb) p debug_rtx (i2)
(insn 63 62 64 7 (set (reg/v:SF 90 [ a ])
(float:SF (reg:SI 88 [ _2 ]))) "pr85300.c":8 203 {*floatsisf2_mixed}
 (expr_list:REG_DEAD (reg:SI 88 [ _2 ])
(nil)))
(gdb) p debug_rtx (i1)
(insn 62 61 63 7 (set (reg:SI 88 [ _2 ])
(const_int 256 [0x100])) "pr85300.c":8 86 {*movsi_internal}
 (nil))
and first subst it so that we get:
(set (reg:SI 89 [ _3 ])
(fix:SI (float:SF (reg:SI 88 [ _2 ]
and then subst r88 for 256 and get:
(set (reg:SI 89 [ _3 ])
(const_int 256 [0x100]))
That is fine.  But, during that substitution we also modify the i2 pattern,
making it invalid:
(insn 63 62 64 7 (set (reg/v:SF 90 [ a ])
(float:SF (const_int 256 [0x100]))) "pr85300.c":8 203
{*floatsisf2_mixed}
 (expr_list:REG_DEAD (reg:SI 88 [ _2 ])
(nil)))
because the FLOAT rtx was shared between PATTERN (i2) and newpat.

[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/85264] [7/8 Regression] ICE with extraneous template parameter list

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
FWIW, there's another similar bug where DOM doesn't do a particularly good job
at tracking the state of objects implied the results of logical operations
which in turn causes missed optimizations.  I've poked at it a few times but
haven't come up with anything good to address the deficiency.  It's on the
Wuninitialized tracker, so I'll certainly take a look over the coming months.

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Note, r142464 still doesn't warn, r142514 does, probably r142484 enabled the
(premature) BIT_FIELD_REF comparison optimization in fold-const.c.

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Maybe uninit just doesn't understand that in:
   [local count: 1073741825]:
  _1 = BIT_FIELD_REF ;
  _2 = _1 & 3;
  if (_2 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719407025]:
  goto ; [100.00%]

   [local count: 354334802]:
  now_11 = ktime_get ();
  pretmp_14 = BIT_FIELD_REF ;

   [local count: 1073741825]:
  # now_5 = PHI 
  # prephitmp_15 = PHI 
  _4 = prephitmp_15 & 1;
  if (_4 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719407025]:
  goto ; [100.00%]

   [local count: 354334802]:
  __tick_nohz_idle_restart_tick (now_5); [tail call]

   [local count: 1073741825]:
  return;
if (_1 & 3) != 0 it implies (_1 & 1) != 0.

Though, if I change the testcase to:
void tick_nohz_idle_exit(void) {
  long now;
  struct tick_sched t = tick_nohz_idle_exit_ts;
  if (t.idle_active || t.tick_stopped)
now = ktime_get();
  if (t.tick_stopped)
__tick_nohz_idle_restart_tick(now);
}
so that it doesn't have to reread tick_nohz_idle_exit_ts.tick_stopped after the
ktime_get call, it doesn't warn anymore.
In that case now is always initialized though, so it shouldn't matter what
value we read for the uninit warning.

[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10

[subscribe at teskor dot de]

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

Michael Teske  changed:

   What|Removed |Added

 CC||subscribe at teskor dot de

--- Comment #5 from Michael Teske  ---
Why not add the directory to the RPATH of the created binaries? I ended up
doing it manually afterwards by using the rpath utility from
https://blogs.oracle.com/solaris/changing-elf-runpaths-code-included-v2 , but
it could be easily done during linking. Are there any reasons against doing it?

[Bug c++/85277] [8 Regression] Broken diagnostic for offsetof with static member function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/84058] RTl partitioning fixup should drag very small blocks back to hot partition

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0
Summary|[8 Regression] RTl  |RTl partitioning fixup
   |partitioning fixup should   |should drag very small
   |drag very small blocks back |blocks back to hot
   |to hot partition|partition
   Severity|normal  |enhancement

--- Comment #9 from Jan Hubicka  ---
The most offending part is fixed. I am keeping the PR to track the enhancements
possible in this area (which I plan to do after GCC 8 branches).

[Bug rtl-optimization/85302] [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
That said, -gsplit-dwarf is pretty much unmaintained for more than 3 years now
already.

[Bug rtl-optimization/84058] [8 Regression] RTl partitioning fixup should drag very small blocks back to hot partition

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Mon Apr  9 16:33:51 2018
New Revision: 259244

URL: https://gcc.gnu.org/viewcvs?rev=259244=gcc=rev
Log:
PR rtl/84058
* cfgcleanup.c (try_forward_edges): Do not give up on crossing
jumps; choose last target that matches the criteria (i.e.
no partition changes for non-crossing jumps).
* cfgrtl.c (cfg_layout_redirect_edge_and_branch): Add basic
support for redirecting crossing jumps to non-crossing.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/cfgrtl.c

[Bug rtl-optimization/85302] [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce, neither on the trunk, nor on 7.x branch, in both cases native
i686-linux builds.

[Bug bootstrap/85280] [8 Regression] Bootstrap comparison failure with Objective C and Objective C++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Can't reproduce on x86_64-linux, i686-linux, powerpc64-linux nor
powerpc64le-linux either, on the former ones I'm doing pretty much daily
bootstraps with objc/obj-c++ included, on the latter from time to time,
including gcc110.fsffrance.org.

[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jason Merrill  ---
With the ICE fixed, this becomes a case of bug 70555.

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

[Bug c++/70555] lambda capture of multi-dimensional VLA

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #9 from Jason Merrill  ---
*** Bug 85256 has been marked as a duplicate of this bug. ***

[Bug c++/70555] lambda capture of multi-dimensional VLA

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Bug 79627 is a case where we would need to do some capture in unevaluated
context, just as in C VLAs make sizeof non-constant.

[Bug c++/85277] [8 Regression] Broken diagnostic for offsetof with static member function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-09
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r254712.  Before it was rejected with:
pr85277.C:5:50: error: cannot apply ‘offsetof’ to member function ‘static int
bar::baz()’
 int bv0 = __builtin_offsetof(volatile bar, baz[0]);

[Bug c++/70555] lambda capture of multi-dimensional VLA

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Created attachment 43886
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43886=edit
work in progress

Here's the beginning of work for more general variably-modified type capture,
based on the approach of capturing and remapping all the uses of outer
automatic vars in the VLA type when the VLA variable is captured.

Another approach would be to handle this later, when we actually do something
that involves the dimensions; that could avoid some unnecessary captures, but
currently the uses of the variable dimensions are hidden in ARRAY_REF, so we'd
need to lower it to pointer arithmetic in affected cases.

[Bug c++/70555] lambda capture of multi-dimensional VLA

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|ICE in expand_expr_real_1   |lambda capture of
   |accessing a |multi-dimensional VLA
   |multi-dimensional VLA via   |
   |lambda-capture  |

--- Comment #6 from Jason Merrill  ---
Let's make this bug the primary one for implementation of more general
VLA/variably-modified type capture support.

[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Mon Apr  9 15:32:05 2018
New Revision: 259240

URL: https://gcc.gnu.org/viewcvs?rev=259240=gcc=rev
Log:
PR c++/85256 - ICE capturing pointer to VLA.

* lambda.c (add_capture): Distinguish between variable-size and
variably-modified types.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-vla2.C
trunk/gcc/testsuite/g++.dg/cpp1y/vla7.C
trunk/gcc/testsuite/g++.dg/cpp1y/vla9.C

[Bug testsuite/85303] [testsuite, libgomp] dg-message not supported

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug testsuite/85303] New: [testsuite, libgomp] dg-message not supported

[vries at gcc dot gnu.org]

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

Bug ID: 85303
   Summary: [testsuite, libgomp] dg-message not supported
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

In libgomp test-cases, dg-error, dg-warning and dg-bogus can be used, but
dg-message not.

[Bug target/85291] ICE in extract_insn, at recog.c:2304

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
I'll handle it.

[Bug ipa/85103] [8 Regression] Performance regressions on SPEC with r257582

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen  ---
(In reply to Pat Haugen from comment #0)
> 
> Very initial look at profile of bzip2 shows degradation is contained to
> mainSort(), which showed a 54% increase in run cycles. Appears one of the
> calls to mainGtU() is inlined into mainSort in the slow version, but the
> drop in cycle counts on mainGtu is no where close to the increase on
> mainSort.

Appears the inlined copy of mainGtU() creates additional register pressure
which results in register spill being generated in the loop of the inlined
copy. The non-inlined copy of the loop is approx. 125 generated insns, whereas
the inlined copy is about 215 insns (90 spill references).

[Bug target/85216] Performance issue with PHP on ppc64 systems

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
(In reply to Timothy Pearson from comment #10)
> 
> It's even slow compared to P8 with mitigations applied.  Do you have a link
> to the hostboot commit that may have enabled the P9 mitigation, or to the
> register name (SCOM) that was modified to enable the mitigation?

No, I'm sorry, I don't know those details.  If you contact me offline I can
probably find someone who does.

[Bug rtl-optimization/85302] New: [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 85302
   Summary: [8 Regression] ICE in size_of_loc_descr, at
dwarf2out.c:1771 on i686-linux-gnu
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r259224 on i686-linux-gnu, trying to build clamav. not seen on
x86_64.

$ cat PointerTracking.ii
class a {
  const char *b;

public:
  a(const char *c) : b(c) {}
};
class B {
public:
  void d(a);
} e;
void f() { e.d(""); }

$ g++ -std=c++11 -c -gsplit-dwarf -O1 PointerTracking.ii 
PointerTracking.ii:11:21: internal compiler error: in size_of_loc_descr, at
dwarf2out.c:1771
 void f() { e.d(""); }
 ^
0x81bc782 size_of_loc_descr
../../src/gcc/dwarf2out.c:1771
0x845f242 size_of_locs(dw_loc_descr_node*)
../../src/gcc/dwarf2out.c:1967
0x846086d skip_loc_list_entry
../../src/gcc/dwarf2out.c:10057
0x8467471 index_location_lists
../../src/gcc/dwarf2out.c:30904
0x8467438 index_location_lists
../../src/gcc/dwarf2out.c:30912
0x8467438 index_location_lists
../../src/gcc/dwarf2out.c:30912
0x8467438 index_location_lists
../../src/gcc/dwarf2out.c:30912
0x847f518 dwarf2out_finish
../../src/gcc/dwarf2out.c:31194
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

Configured with: ../src/configure -v
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu

[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
One more instance got added to the kernel today:

In file included from /git/arm-soc/include/trace/perf.h:90,
 from /git/arm-soc/include/trace/define_trace.h:97,
 from /git/arm-soc/include/trace/events/fscache.h:537,
 from /git/arm-soc/fs/fscache/internal.h:32,
 from /git/arm-soc/fs/fscache/main.c:20:
/git/arm-soc/include/trace/events/fscache.h: In function
'perf_trace_fscache_netfs':
/git/arm-soc/include/trace/events/fscache.h:200:1261: warning: 'strncpy'
specified bound 8 equals destination size [-Wstringop-truncation]
 TRACE_EVENT(fscache_netfs,

Same as the one from comment #5, this one happen for -fsanitize=kernel-address
and is based on simple code that we don't warn for without sanitizer:

   strncpy(__entry->name, netfs->name, 8);
   __entry->name[7]= 0;

I can probably work around that by turning off -Wstringop-truncation whenever
sanitizers enabled in the kernel configuration (we already do that for
-Wmaybe-uninitialized), if this one is unlikely to get fixed before the gcc-8
release.

[Bug target/85281] [8 Regression] Assembler messages: Error: operand size mismatch for `vpbroadcastb' with -mavx512bw -masm=intel

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 43885
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43885=edit
gcc8-pr85281-assorted-fixes.patch

Other issues I've run into.  These two patches together with with
RUNTESTFLAGS='--target_board=unix\{-m32/-masm=intel,-m64/-masm=intel\}
i386.exp'
-FAIL: gcc.target/i386/avx5124vnniw-vp4dpwssd-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx5124vnniw-vp4dpwssds-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512dq-vreducesd-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512dq-vreducess-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512f-vcvtsd2usi-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512f-vcvtsd2usi64-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512f-vcvtss2usi-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512f-vcvtss2usi64-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512f-vfixupimmsd-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512f-vfixupimmss-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512f-vrndscaless-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512vl-vcvtudq2pd-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512vl-vpmovswb-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512vl-vpmovuswb-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512vl-vpmovwb-2.c (test for excess errors)
-FAIL: gcc.target/i386/avx512vl-vshufpd-2.c (test for excess errors)

[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-09
 CC||law at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/85284] [7 Regression] Loop miscompilation starting with r238367

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] Loop   |[7 Regression] Loop
   |miscompilation starting |miscompilation starting
   |with r238367|with r238367

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

[Bug tree-optimization/85284] [7 Regression] Loop miscompilation starting with r238367

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Apr  9 13:27:33 2018
New Revision: 259234

URL: https://gcc.gnu.org/viewcvs?rev=259234=gcc=rev
Log:
2018-04-09  Richard Biener  

PR tree-optimization/85284
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Only use the niter constraining form of simple_iv when the exit
is always executed.

* gcc.dg/torture/pr85284.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr85284.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug tree-optimization/85286] [8 Regression] ICE in exact_div, at poly-int.h:2139

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Starting with r252764 the ICE is instead:
no-tree-pre-pr45241.c: In function ‘foo’:
no-tree-pre-pr45241.c:5:1: internal compiler error: in vect_get_num_copies, at
tree-vectorizer.h:1088
 foo (short x)
 ^~~
0x11b11f2 vect_get_num_copies
../../gcc/tree-vectorizer.h:1087
0x11bf934 vectorizable_reduction(gimple*, gimple_stmt_iterator*, gimple**,
_slp_tree*, _slp_instance*)
../../gcc/tree-vect-loop.c:5686
0x11aa054 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
_slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:8813
0x11c4afe vect_transform_loop(_loop_vec_info*)
../../gcc/tree-vect-loop.c:7396

[Bug target/84041] [nvptx] Hang in for-3.c

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Author: vries
Date: Mon Apr  9 13:22:00 2018
New Revision: 259233

URL: https://gcc.gnu.org/viewcvs?rev=259233=gcc=rev
Log:
[nvptx] Add memory_barrier insn

2018-04-09  Tom de Vries  

PR target/84041
* config/nvptx/nvptx.md (define_c_enum "unspecv"): Add UNSPECV_MEMBAR.
(define_expand "*memory_barrier"): New define_expand.
(define_insn "memory_barrier"): New insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.md

[Bug target/85293] ICE in output_1257, at config/rs6000/vsx.md:3252

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|ppc64le-linux-gnu   |powerpc64*-*-*

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  Any 64-bit target, -mcpu=power9 -mno-direct-move .

[Bug rtl-optimization/85300] [6/7/8 Regression] ICE in exact_int_to_float_conversion_p, at simplify-rtx.c:895

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Version|unknown |8.0.1
   Target Milestone|--- |6.5

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
That is, jump-threading fails to do

  if (x & 3)
...
  else
thread -->
  if (x & 1)
...
  else
<--- here

with the extra complication of that clobbering ktime_get () call on the
true path and x being memory references where DOM sees it.  PRE "cleans"
that up on the interesting path but still late DOM doesn't perform the
threading:

   [local count: 1073741825]:
  _1 = BIT_FIELD_REF ;
  _2 = _1 & 3;
  if (_2 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334802]:
  now_11 = ktime_get ();
  pretmp_14 = BIT_FIELD_REF ;

   [local count: 1073741825]:
  # now_5 = PHI 
  # prephitmp_15 = PHI 
  _4 = prephitmp_15 & 1;
  if (_4 != 0)
goto ; [33.00%]
  else
  else
goto ; [67.00%]

   [local count: 354334802]:
  __tick_nohz_idle_restart_tick (now_5);

   [local count: 1073741825]:

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-09
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm, this looks like a missed jump threading to me - possibly DOM being
confused about the BIT_FIELD_REF and the & 3 that appears with the bitfield
test due to
my much beloved optimize_bit_field_compare:

  if ((BIT_FIELD_REF  & 3) != 0)
{
  now = ktime_get ();
}
  if ((BIT_FIELD_REF  & 1) != 0)
{
  __tick_nohz_idle_restart_tick (now);
}

vs.

  if (tick_nohz_idle_exit_ts.idle_active != 0 ||
tick_nohz_idle_exit_ts.tick_stopped != 0)
{
  now = ktime_get ();
}
  if (tick_nohz_idle_exit_ts.tick_stopped != 0)
{
  __tick_nohz_idle_restart_tick (now);
}

[Bug target/85295] ICE in extract_constrain_insn, at recog.c:2205

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||krebbel at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Shouldn't we just remove -mno-lra support for s390*?
I mean, -mlra is the default on s390* already since GCC 4.9?, so the testing
period must be over already.