[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #35 from Eric Gallager  ---
(In reply to Ramana Radhakrishnan from comment #34)
> I guess waiting till someone tests on iwmmxt2 or proposes an actual tested
> patch for this on trunk.

No one's done that in the last 2 years. Does it really make sense for this to
be a "blocker" when gcc's had multiple releases in the last few years that this
bug hasn't blocked?

[Bug c++/66097] Program fails to run with -O1 but runs with individual settings.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> > Not all optimizations are controlled directly by a flag.
> > Only optimizations that have a flag are listed in this section.
> 
> > Most optimizations are only enabled if an -O level is set on the command 
> > line.
> 
> So we need the testcase which fails for you when compiled with -O1 compared
> to -O0.

Testcase never provided; closing

[Bug tree-optimization/65957] Loop with if-statement yields different results for -O3 vs -O3 -fno-tree-vectorize

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Scott Brozell from comment #2)
> Ok, we shall add this to the todo list.

Is it still on your todo list, or should we close this bug?

[Bug c++/59499] Probably optimization error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #1)
> A self-contained (minimized) reproducer is always a requirement.

Reproducer not provided in time; closing

[Bug c++/61639] GCC 4.7.4 can't longer compile clang

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #6 from Eric Gallager  ---
(In reply to Marek Polacek from comment #5)
> Without a testcase there's nothing to do.

...besides close it, that is.

[Bug demangler/81684] Out of Memory in demangler

[security-tps at google dot com]

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

--- Comment #1 from Google-Autofuzz  ---
Created attachment 41910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41910=edit
Demangler PoC

[Bug demangler/81684] New: Out of Memory in demangler

[security-tps at google dot com]

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

Bug ID: 81684
   Summary: Out of Memory in demangler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: security-tps at google dot com
  Target Milestone: ---

Created attachment 41909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41909=edit
binutils docker file

Hello GCC team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
demangler (tested via git clone git://sourceware.org/git/binutils-gdb.git).  To
reproduce we are attaching a dockerfile to help compiling the project with the
LLVM taking advantage of the sanitizers that it offers.

Attached is a dockerfile that can be used for reproduction.  More information
about how to use the dockerfile can be found here: 
https://docs.docker.com/engine/reference/builder/
TL;DR instructions:
mkdir binutils
cp Dockerfile /path/to/binutils
docker build --no-cache /path/to/binutils
docker run -it 
(from another terminal, outside the container):
docker cp /path/to/attached/reproducer :/fuzzing/
https://docs.docker.com/engine/reference/commandline/cp/
(back inside the container) /fuzzing/repro.sh /fuzzing/reproducer

Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation.

The sanitizer error that we encountered is here:

==23== ERROR: libFuzzer: out-of-memory (used: 2369Mb; limit: 2048Mb)
   To change the out-of-memory limit use -rss_limit_mb=

Live Heap Allocations: 11282956931 bytes from 20 allocations; showing top 50%
11280523256 byte(s) (99%) in 1 allocation(s)
#0 0x4cd488 in __interceptor_malloc
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4cd488)
#1 0x52f179 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12
#2 0x50fb7e in demangle_template
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:2228:27
#3 0x50e30d in demangle_signature
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18
#4 0x50bc20 in internal_cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14
#5 0x50a99c in cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9
#6 0x50847d in LLVMFuzzerTestOneInput
/fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20
#7 0x535eec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x535eec)
#8 0x52f3bc in main (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x52f3bc) 

Is it expected or reasonable for an input of this size to require over 2GB of
memory, or is it possible to add a feature to cap the amount of memory the
library will attempt to use to mitigate issues like this? Additionally, do you
have any interest in these kinds of reports?

We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.

Once you have reproduced the issue, we’d appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the
report to “Google Autofuzz project”.

We are also pleased to inform you that your project is eligible for inclusion
to the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options
(https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md).

Don’t hesitate to let us know if you have any questions!

Google AutoFuzz Team

[Bug demangler/81683] Memory leak in demangler

[security-tps at google dot com]

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

--- Comment #1 from Google-Autofuzz  ---
Created attachment 41908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41908=edit
Demangler PoC

[Bug demangler/81683] New: Memory leak in demangler

[security-tps at google dot com]

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

Bug ID: 81683
   Summary: Memory leak in demangler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: security-tps at google dot com
  Target Milestone: ---

Created attachment 41907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41907=edit
binutils docker file

Hello GCC team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
demangler (tested via git clone git://sourceware.org/git/binutils-gdb.git).  To
reproduce we are attaching a dockerfile to help compiling the project with the
LLVM taking advantage of the sanitizers that it offers.

Attached is a dockerfile that can be used for reproduction.  More information
about how to use the dockerfile can be found here: 
https://docs.docker.com/engine/reference/builder/
TL;DR instructions:
mkdir binutils
cp Dockerfile /path/to/binutils
docker build --no-cache /path/to/binutils
docker run -it 
(from another terminal, outside the container):
docker cp /path/to/attached/reproducer :/fuzzing/
https://docs.docker.com/engine/reference/commandline/cp/
(back inside the container) /fuzzing/repro.sh /fuzzing/reproducer

Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation.

The sanitizer error that we encountered is here:

 ==42==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x4cd488 in __interceptor_malloc
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4cd488)
#1 0x52f179 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12
#2 0x50fb7e in demangle_template
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:2228:27
#3 0x50e30d in demangle_signature
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18
#4 0x50bc20 in internal_cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14
#5 0x50a99c in cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9
#6 0x50847d in LLVMFuzzerTestOneInput
/fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20
#7 0x535eec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x535eec)
#8 0x52f3bc in main (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x52f3bc)

Indirect leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x4cd488 in __interceptor_malloc
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4cd488)
#1 0x52f179 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12
#2 0x5100db in demangle_template
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:2327:31
#3 0x50e30d in demangle_signature
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18
#4 0x50bc20 in internal_cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14
#5 0x50a99c in cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9
#6 0x50847d in LLVMFuzzerTestOneInput
/fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20
#7 0x535eec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x535eec)
#8 0x52f3bc in main (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x52f3bc)

SUMMARY: AddressSanitizer: 9 byte(s) leaked in 2 allocation(s).

We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.

Once you have reproduced the issue, we’d appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the
report to “Google Autofuzz project”.

We are also pleased to inform you that your project is eligible for inclusion
to the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options
(https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md).

Don’t hesitate to let us know if you have any questions!

Google AutoFuzz Team

[Bug demangler/81682] New: Timeout in demangler

[security-tps at google dot com]

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

Bug ID: 81682
   Summary: Timeout in demangler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: security-tps at google dot com
  Target Milestone: ---

Created attachment 41905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41905=edit
binutils docker file

Hello GCC team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
demangler (tested via git clone git://sourceware.org/git/binutils-gdb.git).  To
reproduce we are attaching a dockerfile to help compiling the project with the
LLVM taking advantage of the sanitizers that it offers.

Attached is a dockerfile that can be used for reproduction.  More information
about how to use the dockerfile can be found here: 
https://docs.docker.com/engine/reference/builder/
TL;DR instructions:
mkdir binutils
cp Dockerfile /path/to/binutils
docker build --no-cache /path/to/binutils
docker run -it 
(from another terminal, outside the container):
docker cp /path/to/attached/reproducer :/fuzzing/
https://docs.docker.com/engine/reference/commandline/cp/
(back inside the container) /fuzzing/repro.sh /fuzzing/reproducer

Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation.

The sanitizer error that we encountered is here:

None, the program exits after a few minutes

We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.

Once you have reproduced the issue, we’d appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the
report to “Google Autofuzz project”.

We are also pleased to inform you that your project is eligible for inclusion
to the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options
(https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md).

Don’t hesitate to let us know if you have any questions!

Google AutoFuzz Team

[Bug demangler/81682] Timeout in demangler

[security-tps at google dot com]

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

--- Comment #1 from Google-Autofuzz  ---
Created attachment 41906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41906=edit
Demangler PoC

[Bug demangler/81681] Memory leak in demangler

[security-tps at google dot com]

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

--- Comment #1 from Google-Autofuzz  ---
Created attachment 41904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41904=edit
Demangler PoC

[Bug demangler/81681] New: Memory leak in demangler

[security-tps at google dot com]

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

Bug ID: 81681
   Summary: Memory leak in demangler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: security-tps at google dot com
  Target Milestone: ---

Created attachment 41903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41903=edit
binutils docker file

Hello GCC team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
demangler (tested via git clone git://sourceware.org/git/binutils-gdb.git).  To
reproduce we are attaching a dockerfile to help compiling the project with the
LLVM taking advantage of the sanitizers that it offers.

Attached is a dockerfile that can be used for reproduction.  More information
about how to use the dockerfile can be found here: 
https://docs.docker.com/engine/reference/builder/
TL;DR instructions:
mkdir binutils
cp Dockerfile /path/to/binutils
docker build --no-cache /path/to/binutils
docker run -it 
(from another terminal, outside the container):
docker cp /path/to/attached/reproducer :/fuzzing/
https://docs.docker.com/engine/reference/commandline/cp/
(back inside the container) /fuzzing/repro.sh /fuzzing/reproducer

Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation.

The sanitizer error that we encountered is here:

 ==3170==ERROR: LeakSanitizer: detected memory leaks

  Direct leak of 8 byte(s) in 1 object(s) allocated from:
  #0 0x4cd488 in __interceptor_malloc
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4cd488)
  #1 0x52f179 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12
  #2 0x50fb7e in demangle_template
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:2228:27
  #3 0x50e30d in demangle_signature
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18
  #4 0x50bc20 in internal_cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14
  #5 0x50a99c in cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9
  #6 0x50847d in LLVMFuzzerTestOneInput
/fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20
  #7 0x535eec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x535eec)
  #8 0x52f3bc in main
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x52f3bc)

  Indirect leak of 1 byte(s) in 1 object(s) allocated from:
  #0 0x4cd488 in __interceptor_malloc
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4cd488)
  #1 0x52f179 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12
  #2 0x5100db in demangle_template
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:2327:31
  #3 0x50e30d in demangle_signature
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18
  #4 0x50bc20 in internal_cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14
  #5 0x50a99c in cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9
  #6 0x50847d in LLVMFuzzerTestOneInput
/fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20
  #7 0x535eec in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x535eec)
  #8 0x52f3bc in main
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x52f3bc)

  SUMMARY: AddressSanitizer: 9 byte(s) leaked in 2 allocation(s). 

We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.

Once you have reproduced the issue, we’d appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the
report to “Google Autofuzz project”.

We are also pleased to inform you that your project is eligible for inclusion
to the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options
(https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md).

Don’t hesitate to let us know if you have any questions!

Google AutoFuzz Team

[Bug demangler/81680] Memory leak in demangle

[security-tps at google dot com]

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

--- Comment #1 from Google-Autofuzz  ---
Created attachment 41902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41902=edit
Demangle PoC

[Bug demangler/81680] New: Memory leak in demangle

[security-tps at google dot com]

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

Bug ID: 81680
   Summary: Memory leak in demangle
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: security-tps at google dot com
  Target Milestone: ---

Created attachment 41901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41901=edit
binutils docker file

Hello GCC team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
demangler (tested via git clone git://sourceware.org/git/binutils-gdb.git).  To
reproduce we are attaching a dockerfile to help compiling the project with the
LLVM taking advantage of the sanitizers that it offers.

Attached is a dockerfile that can be used for reproduction.  More information
about how to use the dockerfile can be found here: 
https://docs.docker.com/engine/reference/builder/
TL;DR instructions:
mkdir binutils
cp Dockerfile /path/to/binutils
docker build --no-cache /path/to/binutils
docker run -it 
(from another terminal, outside the container):
docker cp /path/to/attached/reproducer :/fuzzing/
https://docs.docker.com/engine/reference/commandline/cp/
(back inside the container) /fuzzing/repro.sh /fuzzing/reproducer

Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation.

The sanitizer error that we encountered is here:

==38==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x4d5c48 in malloc
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4d5c48)
#1 0x536e39 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12
#2 0x51783e in demangle_template
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:2228:27
#3 0x515fcd in demangle_signature
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18
#4 0x5138e0 in internal_cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14
#5 0x51265c in cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9
#6 0x51013d in LLVMFuzzerTestOneInput
/fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20
#7 0x53f66c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x53f66c)

Indirect leak of 3 byte(s) in 3 object(s) allocated from:
#0 0x4d5c48 in malloc
(/fuzzing/binutils-gdb/build/demangle_fuzzer+0x4d5c48)
#1 0x536e39 in xmalloc /fuzzing/binutils-gdb/libiberty/xmalloc.c:147:12
#2 0x517d9b in demangle_template
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:2327:31
#3 0x515fcd in demangle_signature
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1691:18
#4 0x5138e0 in internal_cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:1257:14
#5 0x51265c in cplus_demangle
/fuzzing/binutils-gdb/libiberty/cplus-dem.c:918:9
#6 0x51013d in LLVMFuzzerTestOneInput
/fuzzing/binutils-gdb/build/../libiberty/demangle_fuzzer.cc:11:20
#7 0x53f66c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*,
unsigned long) (/fuzzing/binutils-gdb/build/demangle_fuzzer+0x53f66c)

SUMMARY: AddressSanitizer: 27 byte(s) leaked in 4 allocation(s). 

We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.

Once you have reproduced the issue, we’d appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the
report to “Google Autofuzz project”.

We are also pleased to inform you that your project is eligible for inclusion
to the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options
(https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md).

Don’t hesitate to let us know if you have any questions!

Google AutoFuzz Team

[Bug tree-optimization/81679] use attribute unused on function arguments as an optimization hint

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
I'd want gcc to have something like clang's -Wused-but-marked-unused warning
flag if it starts doing this optimization, to catch cases where mistakenly
applying attribute unused might be harmful.

[Bug go/81617] mksigtab.sh fails to resolve NSIG with glibc 2.26

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
Created attachment 41900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41900=edit
possible patch

[Bug go/81617] mksigtab.sh fails to resolve NSIG with glibc 2.26

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Would it be possible for you to check whether the patch at
https://golang.org/cl/52611 fixes the problem?

Actually I'll attach it here.

[Bug c/81677] Can't declare pointer to array of incomplete type in struct

[chris.ol...@iti-global.com]

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

--- Comment #7 from chris.ol...@iti-global.com ---
I'm not arguing that arrays declarations should be allowed to derive from
incomplete types, nor all pointers-to-array of incomplete type be allowed; I'm
specifically arguing that a struct should be able to point to an array of
themselves. That's my interpretation and that was my expectation.

[Bug tree-optimization/81679] use attribute unused on function arguments as an optimization hint

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81009

--- Comment #2 from Martin Sebor  ---
Right, the attribute would imply a stronger guarantee on a declaration than on
a definition.

If there is a concern that the attribute could be used on declarations in
existing code that the optimization might break, then the attribute could be
specified differently (e.g., as a function attribute with an argument number
indicating which argument is unused; that would also differentiate it from the
existing function attribute).  Or the same feature could be provided under a
different attribute.  The main idea here is the ability to express the notion
that a function doesn't modify an object via its (non-const) pointer argument. 
The name for the feature is secondary (though "unused" is obviously a nice
fit).

For const pointer arguments, pr81009 points out another opportunity to rely on
restrict for a similar guarantee (i.e., read-only access to the object).

[Bug c/81677] Can't declare pointer to array of incomplete type in struct

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Wed, 2 Aug 2017, chris.ol...@iti-global.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81677
> 
> --- Comment #4 from chris.ol...@iti-global.com ---
> (In reply to jos...@codesourcery.com from comment #3)
> > Because the type doesn't exist,
> 
> I don't know what you mean by a type that "doesn't exist". A declared but

A type that is not part of the set of types defined in the language 
(whether by derivation from other types or otherwise).

Array types in C90 are constructed only by array type derivation (or by 
being a standard typedef in a system header).  Array type derivation only 
derives array types from complete types, not from incomplete types.  There 
is no such type as "array of struct s" at a point in the program where 
struct s is an incomplete type.

> > neither does a pointer to such a type, as pointer types can only be 
> > derived from types that exist, not from types that don't exist.
> 
> Are you saying that pointers can't point to incomplete types? That's expressly
> allowed by pointers. Especially in the case of a member pointing to its own
> struct.

No, the definition of array type derivation only produces array types 
derived from object types, but the definition of pointer type derivation 
also produces pointer types derived from incomplete and function types.  
But the type from which a pointer is derived has itself to exist (whether 
through being a basic type such as char, or through being itself derived 
in one of the listed ways of deriving types - which do not include 
deriving arrays from incomplete types).

[Bug c/81677] Can't declare pointer to array of incomplete type in struct

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Let me try to explain this in easier English rather than standard talk.

An array to incomplete types are invalid and cannot exist as a type as defined
by the C standard (as referenced by Joseph).  Therefor a pointer to an array to
incomplete type is invalid.

That is an array to an incomplete type is not an incomplete type but rather not
a type at all.

Does that make better sense?

[Bug c/81677] Can't declare pointer to array of incomplete type in struct

[chris.ol...@iti-global.com]

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

--- Comment #4 from chris.ol...@iti-global.com ---
(In reply to jos...@codesourcery.com from comment #3)
> Because the type doesn't exist,

I don't know what you mean by a type that "doesn't exist". A declared but
undefined struct is incomplete but exists nevertheless.

> neither does a pointer to such a type, as pointer types can only be 
> derived from types that exist, not from types that don't exist.

Are you saying that pointers can't point to incomplete types? That's expressly
allowed by pointers. Especially in the case of a member pointing to its own
struct.

[Bug tree-optimization/81679] use attribute unused on function arguments as an optimization hint

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Wed, 2 Aug 2017, msebor at gcc dot gnu.org wrote:

> 1) When attribute unused is specified on a function argument of pointer type 
> in
> a declaration of a function, GCC could use that as an indication that the
> argument is, in fact, not used by the implementation of the function and 
> assume
> that the object the pointer points to is unchanged by the function call.

It's peculiar to use the attribute on an argument in a declaration that's 
not a definition, but in definitions it very definitely means *may be 
unused* - for example, the attribute may be present unconditionally for a 
function where the argument might or might not be used, depending on 
various preprocessor conditionals, to avoid needing to replicate those 
conditionals when declaring the argument.  So this would not be a valid 
optimization.

[Bug c/81677] Can't declare pointer to array of incomplete type in struct

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
There is no such thing as an array type whose element is incomplete - you 
can't construct, or describe, such a type in C at all, and attempts to do 
so have undefined behavior in C90, are constraint violations in C99 (with 
a slight ambiguity about the case of array parameters decaying to 
pointers, but it's generally understood the constraint / undefinedness 
applies before decay in the case).  Because the type doesn't exist, 
neither does a pointer to such a type, as pointer types can only be 
derived from types that exist, not from types that don't exist.

[Bug tree-optimization/81679] New: use attribute unused on function arguments as an optimization hint

[msebor at gcc dot gnu.org]

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

Bug ID: 81679
   Summary: use attribute unused on function arguments as an
optimization hint
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is a proposal for an enhancement to attribute unused in two ways:

1) When attribute unused is specified on a function argument of pointer type in
a declaration of a function, GCC could use that as an indication that the
argument is, in fact, not used by the implementation of the function and assume
that the object the pointer points to is unchanged by the function call.

2) In addition, the attribute could also be used to issue a -Wunused-variable
warning when the variable whose address is passed to a function decorated with
it is otherwise unused.

The test case below shows examples where the possible improvements could be
made:

$ cat b.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.c
void f (void* __attribute__ ((unused)));

void g (void)
{
  int i = 1;   // issue -Wunused-variable here
  f ();
}

void h (void)
{
  int i = 1;
  f ();
  if (i != 1)   // assume this can not be true
__builtin_abort ();
}

;; Function g (g, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=0)

g ()
{
  int i;

   [100.00%] [count: INV]:
  i = 1;
  f ();
  i ={v} {CLOBBER};
  return;

}



;; Function h (h, funcdef_no=1, decl_uid=1821, cgraph_uid=1, symbol_order=1)

h ()
{
  int i;
  int i.0_1;

   [100.00%] [count: INV]:
  i = 1;
  f ();
  i.0_1 = i;
  if (i.0_1 != 1)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  i ={v} {CLOBBER};
  return;

}

[Bug c++/81678] New: Variadic template parameters containing pointer to member function fail to be parsed unless name of the parameter is specified

[Predelnik at gmail dot com]

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

Bug ID: 81678
   Summary: Variadic template parameters containing pointer to
member function fail to be parsed unless name of the
parameter is specified
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Predelnik at gmail dot com
  Target Milestone: ---

The following example is not compiling:
template 
void f (void (T::*...)())
{

}

struct C
{
void f (){}
};

int main ()
{
  f (::f);
}

Replacing
void f (void (T::*...)())
with
void f (void (T::*...a)())
makes it compile.
Think it should compile in both cases.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
Created attachment 41899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41899=edit
Patch under test

This is the patch I'm currently looking at.  I am unhappy at having to use a
tree to get maxval, but I cannot find a way to convert a wide_int into a
widest_int so that I can add them together (see the desired code that is
commented out).  Do you have a suggestion how I can do this within the wide_int
framework?

[Bug c/81677] Can't declare pointer to array of incomplete type in struct

[chris.ol...@iti-global.com]

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

--- Comment #2 from chris.ol...@iti-global.com ---
This isn't an array of incomplete type, but a pointer-to-array of incomplete
type; not just any incomplete type, but struct that is guaranteed to be
complete when the outermost } is encountered. As I interpret C90, if a member
can point to its own struct, then a member should be able to point to an array
of its own struct.

[Bug c/81677] Can't declare pointer to array of incomplete type in struct

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
In C90, arrays of incomplete types are forbidden because incomplete types 
are not (before C11) object types.  See footnote 17 in subclause 6.1.2.5.  
In C99 this becomes a constraint in 6.7.5.2#1.

[Bug target/53083] gcc bug in moving from the SSE registers back onto the heap.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #14 from Eric Gallager  ---
(In reply to Pierre Ossman from comment #11)
> Created attachment 30419 [details]
> main.c
> 
> We've also been hitting this, so here is a reduced test case to provoke the
> bug. Output in the failing case:
> 
> test_spans(nspans=36)
>   101,100 + 1
>   101,0 + 1
>   0,100 + 0
> Aborted (core dumped)
> 
> 
> And for a correct run:
> 
> test_spans(nspans=36)
>   101,100 + 1
>   101,100 + 1
>   101,100 + 1
>   101,100 + 1
>   101,101 + 1
>   101,101 + 1
>   101,99 + 1
>   101,99 + 1
>   101,102 + 1
> ...

The program runs successfully for me with both the "ok" and the "fail" sets of
CFLAGS, as well as the CFLAGS you listed in your original report. I can't
reproduce the bug with gcc8, so I'm closing this as WORKSFORME.

[Bug lto/53312] crash in materialize_cgraph (invalid free)

[philippe.waroquiers at skynet dot be]

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

--- Comment #4 from philippe.waroquiers at skynet dot be ---
(In reply to Eric Gallager from comment #3)
> (In reply to philippe.waroquiers from comment #2)
> > (In reply to comment #1)
> > > This looks like PR53214 - unable to verify without a testcase though.  
> > > Thus,
> > > please try a recent GCC 4.7 snapshot instead.  You can also simply grep 
> > > for
> > > optimization attribute usage in your sources.
> > 
> > It looks effectively the same (or least similar).
> > In my case, the offending line was:
> > # pragma GCC optimize("-fomit-frame-pointer")
> > 
> > When removing this line, the crash disappeared.
> > I suppose this is the same bug as PR53214 (even if this bug
> > was with attribute rather than pragma).
> > 
> > Thanks for the help
> 
> And that one was fixed, so I guess this is fixed too then.

I tried to compile a recent Valgrind with the lto option, but it fails
(might be related some hacks used by Valgrind based on a .o produced
during the compilation).
I have put on my list of things to do to further try -flto
but in any case, it looks reasonable to consider this bug fixed.

Thanks for the feedback

[Bug c/81677] New: Can't declare pointer to array of incomplete type in struct

[chris.ol...@iti-global.com]

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

Bug ID: 81677
   Summary: Can't declare pointer to array of incomplete type in
struct
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chris.ol...@iti-global.com
  Target Milestone: ---

Created attachment 41898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41898=edit
test.c is the original source file, test.i is the preprocessor output

The following declaration is considered erroneous on GCC 4.7.7 at the least:

struct s { struct s (*ps)[16] };

I don't see anything in the C90 standard that would forbid this and - although
Clang rejects it - MSC (Windows), XL C (AIX), Sun C (solaris) accepts this
declaration.

Attached is a source file that demonstrates the failure on GCC with this
command (and resulting error):

$ gcc -ansi test.c
test.c:4: error: array type has incomplete element type

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)

$ uname -a
Linux name.domain 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013
x86_64 x86_64 x86_64 GNU/Linux

[Bug tree-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization

--- Comment #9 from John David Anglin  ---
95% certain this is a tree optimization problem.

[Bug rtl-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[danglin at gcc dot gnu.org]

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

--- Comment #8 from John David Anglin  ---
Created attachment 41897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41897=edit
miniperl debug session

The flow and optimization of the Perl_custom_op_get_field function is quite
complex.  Two switch statements are merged and it appears that ultimately the
wrong case is selected to load the return value.

On entry, register %r3 contains the value 0x5aedb0.  %r3 is not modified
in the routine but it is eventually used to load the return value.

   0x0001ab70 :   ldw 10(r3),ret0

It seems there is some confusion as to where the variable xop resides.  When
we hit the following statement, we have

14879   if(field == XOPe_xop_ptr) {(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0x1aa28 to 0x1aa48:
   0x0001aa28 :   b,l 0x3b410,rp
   0x0001aa2c :   stw r0,0(r8)
   0x0001aa30 :   movb,<> ret0,r13,0x1aa74

   0x0001aa34 :   ldi 14,r25
=> 0x0001aa38 :   cmpib,= 0,r5,0x1ab94

   0x0001aa3c :   ldil L%186800,ret0
   0x0001aa40 :   ldo -1(r5),r5
   0x0001aa44 :   ldil L%1a800,ret0
End of assembler dump.
(gdb) info address xop
Symbol "xop" is multi-location:
  Range 0x1a988-0x1a9a4: a variable in $r3
  Range 0x1a9ac-0x1a9b8: a variable in $r3
  Range 0x1aa38-0x1aa40: a complex DWARF expression:
 0: DW_OP_addr 0x186a88
 5: DW_OP_stack_value

  Range 0x1aa44-0x1aa74: a variable in $r3
  Range 0x1aa84-0x1ab94: a variable in $r3
  Range 0x1ab94-0x1ab9c: a complex DWARF expression:
 0: DW_OP_addr 0x186a88
 5: DW_OP_stack_value

  Range 0x1ab9c-0x1abb4: a variable in $r3
.
(gdb) p/x $r3
$2 = 0x5aedb0
(gdb) p xop
$3 = (XOP *) 0x186a88 

The variable he is always 0 in this call.  So, nominally xop should point
at xop_null.

After we execute the switch statement, gdb thinks we are at line 14896:

(gdb) stepi
Perl_custom_op_get_field (my_perl=0x1e3008, o=0x5aee58, field=XOPe_xop_peep)
at op.c:14896
14896   break;
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0x1ab5c to 0x1ab7c:
   0x0001ab5c :   b,l 0x1a9b8
,r0
   0x0001ab60 :   ldw 8(r3),ret0
   0x0001ab64 :   b,l 0x1a9b8
,r0
   0x0001ab68 :   ldw 4(r3),ret0
=> 0x0001ab6c :   b,l 0x1a9b8
,r0
   0x0001ab70 :   ldw 10(r3),ret0
   0x0001ab74 :   b,l 0x1a9b8
,r0
   0x0001ab78 :   ldw c(r3),ret0

Line 14896 is in the first switch expression.  This should result in
xop->xop_peep being returned.  However, here xop is supposed in register
%r3.

However, the flags value from xop_null is 0.  So, the code should be
returning XOPd_xop_peep (ie., ((Perl_cpeep_t)0)).

[Bug target/81621] ICE in delete_insn, at cfgrtl.c:167 with s390x cross compiler

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 41896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41896=edit
gcc8-pr81621.patch

Untested fix.  The problem is that the bb-reorder pass does:
  df_set_flags (DF_DEFER_INSN_RESCAN);
but doesn't call df_finish_pass nor return TODO_df_finish to let the pass
manager to handle that.  And we enter ira with that changeable flag, where
e.g.:
delete_insn (move_insn);
while ((other_def = DF_REG_DEF_CHAIN (REGNO (other_reg
  delete_insn (DF_REF_INSN (other_def));
delete_insn (def_insn);
in move_unallocated_pseudos heavily relies on df updates not being deferred.

[Bug c++/63386] Release version of CB wont compile Bullet (-o2)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #9 from Eric Gallager  ---
(In reply to Damiano from comment #8)
> Created attachment 34623 [details]
> preprocessed source file

I can't reproduce the bug with gcc8. Lots of -fpermissive warnings, but no ICE.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[dje at gcc dot gnu.org]

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

Bug 81638 Summary: [8 Regression] AIX bootstrap failure due to Recover GOTO 
predictor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638

   What|Removed |Added

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

[Bug bootstrap/81638] [8 Regression] AIX bootstrap failure due to Recover GOTO predictor

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #10 from David Edelsohn  ---
Fixed.

[Bug c/81448] False positive -Werror=multistatement-macros in openssl

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Cool, thanks for confirming.

[Bug c/81448] False positive -Werror=multistatement-macros in openssl

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger  ---
Confirmed.
Thanks!

[Bug tree-optimization/81661] [7/8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5638

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So do we need some predicate that will tell us if it is safe to evaluate some
generic expression using force_gimple_operand* and bail out if it isn't
possible?
Even if gimplify_cond_expr tried harder around:
3865  if (gimplify_ctxp->allow_rhs_cond_expr
3866  /* If either branch has side effects or could trap, it
can't be
3867 evaluated unconditionally.  */
3868  && !TREE_SIDE_EFFECTS (then_)
3869  && !generic_expr_could_trap_p (then_)
3870  && !TREE_SIDE_EFFECTS (else_)
3871  && !generic_expr_could_trap_p (else_))
3872return gimplify_pure_cond_expr (expr_p, pre_p);
3873
3874  tmp = create_tmp_var (type, "iftmp");
and built for the case where gimplify_pure_cond_expr can't be used a SSA_NAME
and a PHI if we're in SSA, I guess the vast majority of callers of
force_gimple_operand* don't really expect that the sequence might need to be
split into several basic blocks.

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

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
vect_perm added for the the test case.  It should be bypassed now on
sparc-sun-solaris2.12?

[Bug rtl-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[danglin at gcc dot gnu.org]

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

--- Comment #7 from John David Anglin  ---
Created attachment 41895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41895=edit
Function Perl_custom_op_get_field

[Bug tree-optimization/81635] [8 Regression] nvptx SLP test cases regressions

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Testing a fix.

[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #9 from Tom de Vries  ---
Patch committed. No test-case required.

Marking resolved-fixed.

[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
(In reply to cesar from comment #4)
> I posted a patch that fixes this issue on July 13, 2017:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00750.html
> 
> It is pending review.

The patch has been reviewed, updated and committed as r250422 and r250823.

[Bug gcov-profile/81442] error: verify_flow_info: REG_BR_PROB is set but cfg probability is not during RTL pass: outof_cfglayout

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #5)
> ... the patches handle the issue in different ways:
> - handle the case that there's an edge with uninitialized probability
> - initialize probability on some edges
> 
> At first glance I'd say that one doesn't necessarily exclude the other.

Having reflected a bit further, while the point solution from comment 1 is
something that always works, it also hides the fact that we have inconsistent
edge info. It's probably better to check more aggressively for the
inconsistency: I've submitted a tentative patch at
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00194.html

[Bug c++/81676] New: Wrong warning with unused-but-set-parameter within 'if constexpr'

[benni.buch at gmail dot com]

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

Bug ID: 81676
   Summary: Wrong warning with unused-but-set-parameter within 'if
constexpr'
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

template < typename T >
int f(T v){
if constexpr(sizeof(T) == sizeof(int)){
return v;
}else{
return 0;
}
}

int main(){
f(0);
f('a');
}


This is a valid program which should not produce a warning. (Normal 'if'
doesn't produce a warning either.)


$ g++ -std=c++1z -Wunused-but-set-parameter gcc-warning.cpp
gcc-warning.cpp: In instantiation of 'int f(T) [with T = char]':
gcc-warning.cpp:12:7:   required from here
gcc-warning.cpp:2:9: warning: parameter 'v' set but not used
[-Wunused-but-set-parameter]
 int f(T v){
 ^

$ g++ --version
g++ (GCC) 7.1.1 20170724
Copyright (C) 2017 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.

[Bug fortran/66089] [6/7/8 Regression] elemental dependency mishandling when derived types are involved

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2015-05-12 00:00:00 |2017-8-2

--- Comment #23 from Thomas Koenig  ---
After reading what the standard has to say,
I think Mikael's approach is correct.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
(In reply to Jakub Jelinek from comment #12)
> I had in mind something like
> wi::eq_p (wi::ext (w, TYPE_PRECISION (type), TYPE_SIGN (type)), w)
> or so.

Ah, good, thank you.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
I had in mind something like
wi::eq_p (wi::ext (w, TYPE_PRECISION (type), TYPE_SIGN (type)), w)
or so.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
(In reply to Jakub Jelinek from comment #10)
> The TREE_INT_CST_LOW part looks suspicious.  Also, wide-int.h should provide
> enough infrastructure so that you should be able to do everything on
> wide-int, not have to create trees.

I just saw this comment now.  I think that the TREE_INT_CST_LOW is ok given
that we've already constrained bump to fit in a HOST_WIDE_INT, right?  But
anyway, your second point is well taken -- it looks like I can make use of
wi::to_uhwi and wi::to_shwi with a specified precision from the target type, so
use of trees should indeed be unnecessary.

I have a working patch that uses the trees, but I will rework that in favor of
a pure wide-int solution.  Thanks for the suggestion!

Bill

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[ubizjak at gmail dot com]

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

--- Comment #16 from Uroš Bizjak  ---
(In reply to Andy Lutomirski from comment #14)
> (In reply to H. Peter Anvin from comment #13)
> > On July 20, 2017 10:47:54 AM PDT, ubizjak at gmail dot com
> >  wrote:
> > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
> > >OTOH, we can avoid RIP relative addresses for non-default address
> > >spaces, when
> > >-mcmodel=kernel compile flag is in effect.
> > 
> > It's not just about the kernel model.  The example I have is for the
> > small-pic model.  We are considering moving away from the kernel model.
> 
> The kernel, and possibly future userspace, can use very strange relocations
> for non-standard segments.  The actual percpu space is some contiguous
> (presumably) block that starts at some offset from the actual GS base, but
> that offset is flexible.  There are several possible models:
> 
> a) Percpu data starts at %gs:0 (or %gs:small number) and access uses
> absolute addressing.  This means that percpu symbols will resolve to numbers
> between 0 and 2G and do *not* change if the kernel is relocated.
> 
> b) Percpu data starts at %gs:0 (or %gs:small number) and access uses
> rip-relative addressing.  This requires that the kernel be located at a very
> high address so that the percpu data is reachable.  Percpu symbols are
> largish numbers but still less than 2G.  The symbols do change if the kernel
> is relocated (which is totally the opposite of normal PIC addressing, where
> PIC offsets are not relocated).
> 
> (a) and (b) could plausibly coexist with appropriate magic in the symbol
> tables.

Case (a) above looks like global-pointer access. Global pointer (%gs) points to
the start (or perhaps in the middle (?) ) of the GP-accessible section. This
section can be placed anywhere, as long as all data is reachable with
GP+-offset. In x86 case, offset can be +-2GB for small model. Changing GP by
some small value would access different instance of (percpu) data block.

Case (b) is weird, since all data access is GP relative, even when absolute
offsets are used. I fail to see benefits of using relative relocations against
%rip and %gs. When kernel is relocated, GP remains the same, when GP-accessible
section is relocated, GP needs to be updated to point to new location.

To implement the case (a) above, we'd need some new relocations against
global-pointer.

> c) Percpu data starts at %gs:x where x is the kernel load address plus a
> smallish constant.  Access is like %gs:symbol(%rip).  No dynamic
> relocations.  Also no constraints on where the kernel is loaded.
> 
> d) Percpu data starts at %gs:x where x is the kernel load address plus a
> smallish constant.  Access is like %gs:symbol.  There are dynamic
> relocations.

This is the current implementation, (d) can be implemented with the patch from
comment #15, but assuming kernel text+data must fit in 2GB, there would be no
benefits. Code size will increase a bit for no benefit.

[Bug c++/81675] [6/7/8 Regression] attribute(noreturn) of destructor in :? not honored

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.3.0
   Keywords||diagnostic
   Last reconfirmed||2017-08-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|attribute(noreturn) of  |[6/7/8 Regression]
   |destructor in :? not|attribute(noreturn) of
   |honored |destructor in :? not
   ||honored
  Known to fail||6.3.0, 7.1.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The warning was introduced in r230365 (in GCC 6.0), the merge of
the delayed folding branch.

[Bug libstdc++/29366] atomics config for sh is weird

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
(In reply to Oleg Endo from comment #8)
> Author: olegendo
> Date: Sun Jan 25 16:54:33 2015
> New Revision: 220094
> 
> URL: https://gcc.gnu.org/viewcvs?rev=220094=gcc=rev
> Log:
> libstdc++-v3/
>   PR target/29366
>   * config/cpu/sh/atomicity.h (__exchange_and_add, __atomic_add): 
>   Remove SH4A inline asm and lock based implementations and use the
>   defaults from ext/atomicity.h.
> 
> Modified:
> trunk/libstdc++-v3/ChangeLog
> trunk/libstdc++-v3/config/cpu/sh/atomicity.h

Did this fix things?

[Bug c/81566] [4.9/5/6/7/8 Regression] invalid attribute aligned accepted on functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|invalid attribute aligned   |[4.9/5/6/7/8 Regression]
   |accepted on functions   |invalid attribute aligned
   ||accepted on functions

--- Comment #2 from Martin Sebor  ---
The handle_aligned_attribute() function in c-family/c-attribs.c tries to detect
and reject attribute aligned on declarations that attempt to relax a function's
alignment (see the second if statement below) but that code is never reached
apparently because of the test immediately before it.  That test was added in
r192199 (in GCC 4.9) that added C++ 11 alignas support.  Prior to that GCC
rejected a function declaration with conflicting attribute aligned.  I cannot
find any tests for the ineffective code in the test suite.

  else if (DECL_USER_ALIGN (decl)
   && DECL_ALIGN (decl) > (1U << i) * BITS_PER_UNIT)
/* C++-11 [dcl.align/4]:

   When multiple alignment-specifiers are specified for an
   entity, the alignment requirement shall be set to the
   strictest specified alignment.

  This formally comes from the c++11 specification but we are
  doing it for the GNU attribute syntax as well.  */
*no_add_attrs = true;
  else if (TREE_CODE (decl) == FUNCTION_DECL
   && DECL_ALIGN (decl) > (1U << i) * BITS_PER_UNIT)
{
  if (DECL_USER_ALIGN (decl))
error ("alignment for %q+D was previously specified as %d "
   "and may not be decreased", decl,
   DECL_ALIGN (decl) / BITS_PER_UNIT);
  else
error ("alignment for %q+D must be at least %d", decl,
   DECL_ALIGN (decl) / BITS_PER_UNIT);
  *no_add_attrs = true;
}

[Bug c/81656] incompatible _Alignas silently accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81566

--- Comment #2 from Martin Sebor  ---
See also bug 81566 for a related problem with attribute aligned on function
declarations.

[Bug middle-end/59572] Not clear error message in smallest_mode_for_size in handled case

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
(In reply to Jeffrey A. Law from comment #1)
> We would need a compilable testcase to further investigate this problem. 
> The easiest way to get a compilable testcase is to add "-save-temps" to the
> compiler's command line.  For C code that will generate a .i file, for C++ a
> .ii file.  Upload that along with the full set of options on the compiler
> command line and we can take a look.

Reporter never produced the testcase requested; closing for being stuck in
WAITING for so long.

[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails

[egallager at gcc dot gnu.org]

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

--- Comment #69 from Eric Gallager  ---
*** Bug 61440 has been marked as a duplicate of this bug. ***

[Bug bootstrap/61440] Bootstrap failure with --with-build-config=bootstrap-lto

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #6 from Eric Gallager  ---
(In reply to Jacek Sieka from comment #4)
> This looks very similar to 62077 btw.

OK, closing it as a duplicate of bug 62077 then.

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

[Bug tree-optimization/81673] Harmful SLP vectorization

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
(In reply to Andrew Pinski from comment #1)
> What happens if you use -march=intel.

With -mtune=intel, the lower half of the vector is moved directly
whereas the upper one is still done through the stack:

.cfi_startproc
leaq-56(%rsp), %rsp
.cfi_def_cfa_offset 64
movq%rdx, %xmm0
movq%rcx, (%rsp)
leaq16(%rsp), %rdi
movq%r9, 8(%rsp)
movhps  (%rsp), %xmm0
movdqa  %xmm0, 32(%rsp)
movq%r8, %xmm0
movhps  8(%rsp), %xmm0
movdqa  %xmm0, 16(%rsp)
callbar
leaq56(%rsp), %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc

...so I guess this would still incur some penalty on the benchmark,
but I am not sure.

[Bug c++/81675] New: attribute(noreturn) of destructor in :? not honored

[joerg.rich...@pdv-fs.de]

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

Bug ID: 81675
   Summary: attribute(noreturn) of destructor in :? not honored
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

cat > t.cc << EOF
struct S
{
~S() __attribute__((noreturn));
int a;
};
int foo()
{
  false ? 5 : S().a;
}
EOF
g++ -c -Wall t.cc


GCC 6.2.0 prints:
t.cc: In function 'int foo()':
t.cc:9:1: warning: control reaches end of non-void function [-Wreturn-type]

GCC 5.3.0 seems to detect correctly that foo() will never return.

[Bug fortran/53077] replace "Illegal preprocessor directive" message with "Ignoring preprocessor directive at %C. Use -cpp to enable the C preprocessor" (a patch by Tobias included)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #6)
> Is there any objection if I do the testing and packaging for the patch in
> comment 4?

No objection seen; go for it!

[Bug c++/54710] moderately large tuple, with many gets, increases compile time

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|WAITING |NEW
   Last reconfirmed|2012-09-25 00:00:00 |2017-8-2

[Bug c++/54710] moderately large tuple, with many gets, increases compile time

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
Created attachment 41894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41894=edit
result of compiling with -ftime-report -ftime-report-details -fstats

(In reply to Larry Evans from comment #10)
> Created attachment 28294 [details]
> with optimized clang, still with optimized gcc, both with -O1
> 
> Remade clang with make ENABLE_OPTIMIZED=1.  Clang times improved a lot.
> 
> Now, the degradation of relative performance of gcc w.r.t. clang
> is more dramatic.
> 
> Still, gcc does better at low LAST_LESS, but reaches break even
> at lower LAST_LESS (about 8).

Confirmed:

$ /usr/local/bin/gcc -c -O1 -time tuple.benchmark.mini.horiz.cpp
# cc1plus 4.62 0.25
# as 0.02 0.01
$

I guess 4 and a half seconds is kinda long. Attaching a more detailed time
report as a separate file.

[Bug tree-optimization/81673] Harmful SLP vectorization

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
For the record, our plan is to address this with the following patch
from Richi (after we benchmark it some more and if there are no
issues):

2017-08-01  Richard Biener  

PR tree-optimization/81673
* config/i386/i386.c (ix86_builtin_vectorization_cost): Increment
vec_construct cost for non-floats.
---
 gcc/config/i386/i386.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3caeeb0e377..1f1f4fbef72 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -46542,7 +46542,17 @@ ix86_builtin_vectorization_cost (enum
vect_cost_for_stmt type_of_cost,
 return ix86_cost->vec_stmt_cost;

   case vec_construct:
-   return ix86_cost->vec_stmt_cost * (TYPE_VECTOR_SUBPARTS (vectype) - 1);
+{
+ int cost
+   = ix86_cost->vec_stmt_cost * (TYPE_VECTOR_SUBPARTS (vectype) -
+ 1);
+ /* When the elements are integers the first insert isn't a move
+that can be eliminated via RA but might even go through
+the stack for the gpr->xmm move.  */
+ if (! FLOAT_TYPE_P (TREE_TYPE (vectype)))
+   cost += 1;
+ return cost;
+   }

   default:
 gcc_unreachable ();

[Bug target/81664] __attribute__((target("movbe"))) does not work

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Daniel Fruzynski from comment #2)
> So there is another problem here: for some reason both mentioned gcc
> versions accepts -mmovbe and -mno-movbe options. If movbe is not supported,
> gcc should complain that these options are unrecognized.

-mmovbe compile flag is a different thing that "movbe" target attribute.

> I also checked generated assembly code and there are no movbe instruction
> there. However I noticed that gcc 4.8.5 on Redhat 7 generates different code
> when -mmovbe is used - it adds extra instruction marked below with ***.

Your test is flawed:
- ntohl uses uint32_t, extra instruction is zero-extend to 64bit ulong.
- movbe works only from/to memory.

Try this test:

--cut here--
#include 
#include 

extern uint32_t val;

uint32_t
__attribute__((target("movbe")))
ntohl_movbe(void)
{
return ntohl (val);
}

uint32_t
__attribute__((target("no-movbe")))
ntohl_no_movbe(void)
{
return ntohl (val);
}
--cut here--

gcc -O2:

ntohl_movbe:
movbe   val(%rip), %eax
ret
.cfi_endproc

ntohl_no_movbe:
movlval(%rip), %eax
bswap   %eax
ret

[Bug c++/81674] New: gcc cannot detect missing initialisers for fields in constructors

[dcb314 at hotmail dot com]

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

Bug ID: 81674
   Summary: gcc cannot detect missing initialisers for fields in
constructors
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Given the following C++ source code:

struct S
{
int a, b, c;

S() : a( 0)
{
b = 1;
};
};

then I cannot get gcc to detect the missing initialiser for field c.

$ ~/gcc/results/bin/gcc -c -O2 -Wall -Wextra aug2a.cc
$

Here is static analyser cppcheck finding the problem:

$ ~/cppcheck/trunk/cppcheck --enable=all aug2a.cc
[aug2a.cc:8]: (warning) Member variable 'S::c' is not initialized in the
constructor.
$

cppcheck can find 55 examples of this problem in the gcc source code alone,
so it would appear to be of some value to gcc, to say nothing of customers
of gcc.

[Bug target/59865] gnu multiversion calculates wrong target

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu
 CC||egallager at gcc dot gnu.org
  Component|c++ |target

--- Comment #3 from Eric Gallager  ---
(In reply to mib.bugzilla from comment #2)
> Thanks. I realized after I posted that the test case isn't definitive.
> Improved test case pasted below.
> 
> Inspection of the assembly listing shows that popcnt is being checked before
> arch=corei7.  I was testing to see the precendence of arch= versus isa by
> creating foo for all isa, then seeing where a single arch= is sorted in the
> dispatch function.
> 
> cat core-pop.C
> #include 
> #include 
> #include 
> const char * __attribute__ ((target("default"))) foo(void)
> { return("default wins\n");}
> const char* __attribute__ ((target("arch=corei7"))) foo(void)
> { return("corei7 wins\n");}
> const char* __attribute__ ((target("popcnt"))) foo(void)
> { return("popcnt wins\n");}
> int main ()
> {
>   const char *result = foo ();
>   if (__builtin_cpu_is ("corei7")) puts("builtin cpu is corei7\n");
>   if (__builtin_cpu_is ("corei7"))
> assert ( 0 == strcmp(result, "corei7 wins"));
>   return 0;
> }
> -bash-4.1$ g++ core-pop.C -S
> -bash-4.1$ g++ core-pop.C
> -bash-4.1$ grep movl core-pop.s | grep foov //From dispatch function
> movl$_Z3foov.popcnt, %eax
> movl$_Z3foov.arch_corei7, %eax
> movl$_Z3foov, %eax
> -bash-4.1$ ./a.out
> builtin cpu is corei7
> 
> a.out: core-pop.C:15: int main(): Assertion `0 == strcmp(result, "corei7
> wins")' failed.
> Aborted (core dumped)

I can't reproduce this bug due to my target lacking ifunc support. Someone with
a more capable target will need to test to be able to move this bug out of
WAITING.

[Bug tree-optimization/81673] Harmful SLP vectorization

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
What happens if you use -march=intel.  Maybe the cost should have adjusted only
for the case where moving between the register set is cheap (I forgot the
internal tuning name for this case).

[Bug fortran/52387] I/O output of write after nonadvancing read

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #12 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #11)
> > Tobias, any further information on this one?
> 
> Any news after more than one year?

Guess not, closing for being stuck in WAITING for so long

[Bug tree-optimization/81673] New: Harmful SLP vectorization

[jamborm at gcc dot gnu.org]

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

Bug ID: 81673
   Summary: Harmful SLP vectorization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
  Target Milestone: ---

Revision r238364 has changes the cost of vec_construct in
ix86_builtin_vectorization_cost.  On one hand, the new code correctly
models the number of vecotr inserts, but on the other it has lead to
SLP vectorization in the following testcase which is extracted from
538.imagick_r in which it leads to run-time regressions (depending on
the HW you use) up to 6% at -O3 and -Ofast optimisation levels.

--
typedef unsigned long size_t;
typedef long ssize_t;

typedef struct _RectangleInfo
{
  size_t
width,
height;

  ssize_t
x,
y;
} RectangleInfo;

void bar (RectangleInfo *region);


void
foo (void *ua, void *ub, const ssize_t x,const ssize_t y,
 const size_t columns,const size_t rows)
{
  RectangleInfo region;

  region.x=x;
  region.y=y;
  region.width=columns;
  region.height=rows;

  bar ();
}
--

SLP2 converts this into:

  vect_cst__14 = {x_2(D), y_4(D)};
  vect_cst__12 = {columns_6(D), rows_8(D)};
  MEM[(long int *) + 16B] = vect_cst__14;
  MEM[(long unsigned int *)] = vect_cst__12;
  bar ();

which is then finally compiled to:

.cfi_startproc
subq$72, %rsp
.cfi_def_cfa_offset 80
movq%rdx, 24(%rsp)
movq%rcx, 8(%rsp)
leaq32(%rsp), %rdi
movq24(%rsp), %xmm0
movq%r9, 16(%rsp)
movhps  8(%rsp), %xmm0
movq%r8, 8(%rsp)
movaps  %xmm0, 48(%rsp)
movq8(%rsp), %xmm0
movhps  16(%rsp), %xmm0
movaps  %xmm0, 32(%rsp)
callbar
addq$72, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc

as opposed to the output of the previous revision:

.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
movq%rsp, %rdi
movq%rdx, 16(%rsp)
movq%rcx, 24(%rsp)
movq%r8, (%rsp)
movq%r9, 8(%rsp)
callbar
addq$40, %rsp
.cfi_def_cfa_offset 8
ret

The moves from GPRs into XMM registersh through stack are the thing
that can cost a lot of time (as shown by perf in the case of
538.imagick_r).

[Bug jit/81672] trunk/gcc/jit/jit-recording.c:2852: possible missing initialiser

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Probably harmless, but might benefit from some tidy up.

[Bug target/81644] ICE in rtl_verify_bb_insn, BBRO pass duplicates BB that ends with flow control insn

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #4 from Uroš Bizjak  ---
Fixed (... or worked around) for gcc-8.

[Bug jit/81672] New: trunk/gcc/jit/jit-recording.c:2852: possible missing initialiser

[dcb314 at hotmail dot com]

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

Bug ID: 81672
   Summary: trunk/gcc/jit/jit-recording.c:2852: possible missing
initialiser
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/gcc/jit/jit-recording.c:2852]: (warning) Member variable 'union_::m_loc'
is not initialized in the constructor.
[trunk/gcc/jit/jit-recording.c:2852]: (warning) Member variable
'union_::m_name' is not initialized in the constructor.

Source code is

recording::union_::union_ (context *ctxt,
   location *loc,
   string *name)
: compound_type (ctxt, loc, name)
{
}

[Bug rtl-optimization/57970] segfault in sched-deps.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Chris King from comment #5)
> Would a unit test case be acceptable?  That should be an easy way to evince
> this bug and I'd be glad to write one.

It might not've been when you wrote this, but I guess now that David Malcolm
has added unit testing capabilities to gcc, maybe...
(See gcc/selftest.h and gcc/selftest.c for info)

[Bug target/81644] ICE in rtl_verify_bb_insn, BBRO pass duplicates BB that ends with flow control insn

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Aug  2 13:58:08 2017
New Revision: 250830

URL: https://gcc.gnu.org/viewcvs?rev=250830=gcc=rev
Log:
PR target/81644
* config/i386/i386.md (unspecv): Add UNSPECV_UD2.
(ud2): New insn pattern.
* config/i386/i386.c (ix86_expand_epilogue):
Generate ud2 instead of trap insn.

testsuite/ChangeLog:

PR target/81644
* gcc.target/i386/pr81644.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr81644.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug driver/81650] gcc -m32 mishandles -Walloc-size-larger-than=9223372036854775807

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71905

--- Comment #3 from Martin Sebor  ---
Jakub's patch fixes the ILP32 problem for -Walloc-size-larger-than.  A complete
solution would also solve the related but broader problem with the other
options that accept a size as an argument.  Those are discussed in bug 71905.

[Bug c++/81636] Confusing warning message containing "#‘obj_type_ref’ not supported by expression#"

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Paolo added FIX_TRUNC_EXPR and FLOAT_EXPR to dump_expr in r143790, but I
believe we need more than just pp->expression (t);, we need to print it
similarly to CONVERT_EXPR.

[Bug target/81664] __attribute__((target("movbe"))) does not work

[bugzi...@poradnik-webmastera.com]

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

Daniel Fruzynski  changed:

   What|Removed |Added

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

--- Comment #3 from Daniel Fruzynski  ---
I also found that release notes for gcc 4.5
(https://gcc.gnu.org/gcc-4.5/changes.html) says that it is supported on
IA-32/x86-64:
"A new -mmovbe option is now available to enable GCC to use the movbe
instruction to implement __builtin_bswap32 and __builtin_bswap64.". Now this
issue looks like a regression for me.

[Bug tree-optimization/81655] [7/8 Regression] new test case gcc.dg/tree-ssa/pr81588.c fails on powerpc64

[seurer at gcc dot gnu.org]

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

--- Comment #5 from seurer at gcc dot gnu.org ---
At the time I had not seen this on trunk but indeed it does fail there too.

[Bug c++/81671] [7/8 Regression] std::nullptr_t incompatible to std::nullptr_t

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/81671] [7/8 Regression] std::nullptr_t incompatible to std::nullptr_t

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with 
commit f0474a47521090f110f67bd2a56712e324b66313
Author: jason 
Date:   Fri Oct 21 19:45:45 2016 +

PR c++/77656
* pt.c (convert_template_argument): Call convert_nontype_argument
on value-dependent but not type-dependent arguments.
(convert_nontype_argument): Handle value-dependent arguments.
(canonicalize_expr_argument): New.
(deducible_expression, unify): Skip CONVERT_EXPR.
* error.c (dump_template_argument): Likewise.
* mangle.c (write_expression): Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241425
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/81664] __attribute__((target("movbe"))) does not work

[bugzi...@poradnik-webmastera.com]

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

--- Comment #2 from Daniel Fruzynski  ---
So there is another problem here: for some reason both mentioned gcc versions
accepts -mmovbe and -mno-movbe options. If movbe is not supported, gcc should
complain that these options are unrecognized.

I also checked generated assembly code and there are no movbe instruction
there. However I noticed that gcc 4.8.5 on Redhat 7 generates different code
when -mmovbe is used - it adds extra instruction marked below with ***.

_Z11ntohl_movbel:
.LFB6:
.cfi_startproc
movl%edi, %eax
bswap   %eax
movl%eax, %eax   ***
ret
.cfi_endproc

[Bug rtl-optimization/81625] GCC v4.7 ... v8 is bloating code by > 25% compared to v3.4

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
With -Og you get a smaller binary on AVR (812 bytes, +20%).

[Bug other/81667] trunk/gcc/alloc-pool.h:239: possible missing initialiser ?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug other/81667] trunk/gcc/alloc-pool.h:239: possible missing initialiser ?

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Wed Aug  2 13:25:12 2017
New Revision: 250829

URL: https://gcc.gnu.org/viewcvs?rev=250829=gcc=rev
Log:
PR other/81667
* alloc-pool.h (base_pool_allocator): Initialize m_elt_size.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/alloc-pool.h

[Bug c++/81671] [7/8 Regression] std::nullptr_t incompatible to std::nullptr_t

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to work||6.2.0
   Target Milestone|--- |7.2
Summary|std::nullptr_t incompatible |[7/8 Regression]
   |to std::nullptr_t   |std::nullptr_t incompatible
   ||to std::nullptr_t

[Bug c++/81671] New: std::nullptr_t incompatible to std::nullptr_t

[joerg.rich...@pdv-fs.de]

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

Bug ID: 81671
   Summary: std::nullptr_t incompatible to std::nullptr_t
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

cat > t.cc << EOF
#include 
template struct Bar
{};
template struct Bar
{
template struct Bind { constexpr static int const cb = 0;
};
};
int foo()
{
  return Bar::Bind::cb;
}
EOF
g++ t.cc


Gives this:

t.cc: In instantiation of 'struct Bar':
t.cc:10:37:   required from here
t.cc:6:37: error: '' is not a valid template argument for type
'std::nullptr_t' because it is of type 'std::nullptr_t'

Works with 4.9.3, 5.3.0 and 6.2.0

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
It apparently started failing last week of January 2017.  Only 64-bit
fails, -m32 is fine.

I don't know where that missing function name is coming from.

[Bug libstdc++/81670] New: include/ext/pb_ds/detail/splay_tree_/splay_fn_imps.hpp:253: suspicious assignment ?

[dcb314 at hotmail dot com]

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

Bug ID: 81670
   Summary: include/ext/pb_ds/detail/splay_tree_/splay_fn_imps.hpp
:253: suspicious assignment ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/libstdc++-v3/include/ext/pb_ds/detail/splay_tree_/splay_fn_imps.hpp:253]:
(warning) Redundant assignment of 'base_type::m_p_head->m_p_parent' to itself.

Source code is

  if (grandparent_head)
{
  base_type::m_p_head->m_p_parent = base_type::m_p_head->m_p_parent;

[Bug driver/81650] gcc -m32 mishandles -Walloc-size-larger-than=9223372036854775807

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41893=edit
gcc8-pr81650.patch

There are multiple issues.  First on ilp32 host even specifying say 14EB will
mean multiply 14 by 0xa764ULL.  Another issue is that if you write
a bogus suffix, it will quietly use SSIZE_MAX.  Another issue is that overflow
in the computation is undetected.  And, the result of the multiplication is
then just cast to ssizetype.

Either we can treat the warning as warning if above MIN (SSIZE_MAX,
user_specified_value), this is implemented in this untested patch.
Or we could allow any values from 0 to SIZE_MAX (but then actually should
convert SSIZE_MAX to sizetype) and either treat values larger than SIZE_MAX as
infinity or SIZE_MAX, or diagnose any out of range values as errors.

[Bug c++/81668] LTO ODR warnings are not helpful

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, lto
 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Yeah, those cases are obfuscated but usually they have macros expanding to
different things.  You can debug this by looking at preprocessed source
of the two places (look at "included from" messages).

Not sure what we do with -fno-diagnostics-show-caret, maybe we dump the
actual types that mismatch.  With caret locations those would be often
redundant.

[Bug fortran/60355] [F08] constraint C519 for BIND attribute not enforced

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
I have a patch.

[Bug c/81669] New: trunk/gcc/fibonacci_heap.h:58: possible missing initialisation ?

[dcb314 at hotmail dot com]

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

Bug ID: 81669
   Summary: trunk/gcc/fibonacci_heap.h:58: possible missing
initialisation ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/gcc/fibonacci_heap.h:58]: (warning) Member variable
'fibonacci_node::m_data' is not initialized in the constructor.

Source code is

  fibonacci_node (): m_parent (NULL), m_child (NULL), m_left (this),
m_right (this), m_degree (0), m_mark (0)
  {
  }

Probably harmless, but might be safer to make sure m_data is
set to something sensible.

[Bug fortran/60355] [F08] constraint C519 for BIND attribute not enforced

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Apparently only for implicitly-typed variables.

This works as expected:

program main
  integer, bind(c) :: i
end program main
$ gfortran a.f90 
a.f90:2:23:

   integer, bind(c) :: i
   1
Error: Variable 'i' at (1) cannot be BIND(C) because it is neither a COMMON
block nor declared at the module level scope

[Bug fortran/61450] ICE in gfc_global_used()

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr

--- Comment #5 from Dominique d'Humieres  ---
> Can regtest it and submit it to the list for review? Many thanks…

I'll do the submission soon.

[Bug target/56412] [4.8] "libtool: cygpath: command not found" for mingw32 host

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Kai Tietz from comment #6)
> Yes, this is a libtool bug.  If thing is solved on libtool, then we can
> continue on that.  So long I set bug in status waiting

If there's an upstream URL for the libtool bug report, we can set it to
RESOLVED MOVED instead of WAITING.

[Bug c/81306] valgrind error for function warn_for_multistatement_macros in file c-warn.c line 2474

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Should be fixed, too.