[Bug c++/81145] bogus "dereferencing type-punned pointer will break strict-aliasing rules" diagnostic with incomplete class type

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #5 from Richard Smith  ---
Yes, according to godbolt this occurs in GCC 4.4 - 7.1, but not in trunk.
Unlike PR80593, it does not appear to be a GCC 7 regression, but it sure seems
plausible that that change fixed it =)

[Bug sanitizer/81148] New: UBSAN: two more false positives

[babokin at gmail dot com]

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

Bug ID: 81148
   Summary: UBSAN: two more false positives
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev249427, x86_64.

> cat f.cpp
int x = -106;
int main() {
  // -123 - (0x8000 - -1)
  bool a = -123 - ((9223372036854775806 ^ ~(x && true)) - -1);
  return 0;
}

> gcc -fsanitize=undefined f.cpp -o out
> ./out
f.cpp:4:41: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long int'; cast to an unsigned type to negate this value
to itself
f.cpp:4:17: runtime error: signed integer overflow: -9223372036854775808 + -124
cannot be represented in type 'long int'

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #14 from Jonathan Wakely  ---
*** Bug 81145 has been marked as a duplicate of this bug. ***

[Bug c++/81145] bogus "dereferencing type-punned pointer will break strict-aliasing rules" diagnostic with incomplete class type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Indeed, the warning is gone with a current gcc-7-branch build.

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

[Bug libstdc++/81092] Missing symbols for new std::wstring constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from Jonathan Wakely  ---
Argh, I didn't commit the regenerated libstdc++-v3/configure files so the
library is still called libstdc++.so.6.0.23 when it should be 6.0.24

[Bug target/81147] New: [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[felipe at expertisesolutions dot com.br]

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

Bug ID: 81147
   Summary: [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO
when class inherits from empty base
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felipe at expertisesolutions dot com.br
  Target Milestone: ---

Created attachment 41594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41594=edit
Source file

Compilation of the attached example generates the also attached assembly. The
file was compiled with the following flags. The same file compiled for x86_64
generates optimal code and doesn't make any copies. It can be seen that many
copies happen between Z and X pointer registers in ld, st instructions that
follow r26 and r30 register setup.

avr-g++ -std=c++14  -I. -I../avr-traits/include -I../avr-add/include -DNDEBUG
-DBOOST_SPIRIT_X3_NO_RTTI -DBOOST_EXCEPTION_DISABLE -DBOOST_NO_EXCEPTIONS
-DBOOST_ASIO_USE_STD_SYSTEM_ERROR -I../../../Beast/include
-I../boost/libs/utility/include -I../boost/libs/tti/include
-I../boost/libs/spirit/include -I../boost/libs/mpl/include
-I../boost/libs/config/include -I../boost/libs/preprocessor/include
-I../boost/libs/type_traits/include -I../boost/libs/core/include
-I../boost/libs/fusion/include -I../boost/libs/utility/include
-I../boost/libs/static_assert/include -I../boost/libs/variant/include
-I../boost/libs/type_index/include -I../boost/libs/detail/include
-I../boost/libs/assert/include -I../boost/libs/move/include
-I../boost/libs/functional/include -I../boost/libs/math/include
-I../boost/libs/throw_exception/include -I../boost/libs/tti/include
-I../boost/libs/function_types/include -I../boost/libs/concept_check/include
-I../boost/libs/range/include -I../boost/libs/iterator/include
-I../boost/libs/optional/include -I../boost/libs/integer/include
-I../boost/libs/predef/include -I../boost/libs/smart_ptr/include
-I../boost/libs/intrusive/include -I../boost/libs/lexical_cast/include
-I../boost/libs/numeric/conversion/include -I../boost/libs/array/include
-I../boost/libs/container/include -I../boost/libs/system/include
-I../boost/libs/asio/include -I../boost/libs/logic/include
-I../boost/libs/regex/include -I../contiki++/include
-DBOOST_SPIRIT_STANDARD_WIDE_NOVEMBER_10_2006_0913AM
-DBOOST_SPIRIT_NO_STANDARD_WIDE -DBOOST_SPIRIT_NO_REAL_NUMBERS -fno-exceptions
-fno-rtti -Wno-unused-local-typedefs -fno-use-cxa-atexit -save-temps
-fverbose-asm -dap -fdump-tree-all-all -DCONTIKI=1
-DCONTIKI_TARGET_AVR_ATMEGA2560=1 -Wall -mmcu=atmega2560 -fno-strict-aliasing
-I../contiki/platform/avr-atmega2560 -I. -I../contiki/core -I../contiki/cpu/avr
 -DF_CPU=1600UL -DAUTO_CRC_PADDING=2 -Os -ffunction-sections
-fdata-sections  -I. -Isrc -I../contiki/platform/avr-atmega2560/.
-I../contiki/platform/avr-atmega2560/apps
-I../contiki/platform/avr-atmega2560/net
-I../contiki/platform/avr-atmega2560/loader -I../contiki/cpu/avr/.
-I../contiki/cpu/avr/dev -I../contiki/cpu/avr/radio/rf230bb
-I../contiki/core/dev -I../contiki/core/lib -I../contiki/core/net
-I../contiki/core/net/llsec -I../contiki/core/net/mac
-I../contiki/core/net/rime -I../contiki/core/net/rpl -I../contiki/core/sys
-I../contiki/core/cfs -I../contiki/core/ctk -I../contiki/core/lib/ctk
-I../contiki/core/loader -I../contiki/core/. -I../contiki/core/sys
-I../contiki/core/dev -I../contiki/core/lib
-I../contiki/platform/avr-atmega2560/ -I../contiki
-DCONTIKI_VERSION_STRING=\"Contiki-1d456a24b\" -MMD -c src/config-process.cpp

[Bug c++/81145] bogus "dereferencing type-punned pointer will break strict-aliasing rules" diagnostic with incomplete class type

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Is the version 7.0.1 correct? Unless you're still seeing this with a fairly
recent 7.1.1 build from the gcc-7-branch this is probably a dup of Bug 80593

[Bug c++/81145] bogus "dereferencing type-punned pointer will break strict-aliasing rules" diagnostic with incomplete class type

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #2 from Richard Smith  ---
I've tried a few things and not found any way to get wrong code. I think you're
right that this is just a diagnostic issue.

[Bug other/81146] Wine 2.10 cannot be compiled with -flto

[t.artem at mailcity dot com]

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

--- Comment #1 from Artem S. Tashkinov  ---
When running with `make -j4` that's what I see first:

gcc -o widl client.o expr.o hash.o header.o proxy.o register.o server.o
typegen.o typelib.o \
  typetree.o utils.o widl.o write_msft.o parser.tab.o parser.yy.o
../../libs/port/libwine_port.a \
  ../../libs/wpp/libwpp.a -m32 -Wl,-O1 -Wl,--hash-style=gnu -flto
/tmp/ccmagxOP.ltrans8.ltrans.o: In function `spawn':
:(.text+0x1029): undefined reference to `_spawnvp'
collect2: error: ld returned 1 exit status
Makefile:235: recipe for target 'winebuild' failed
make[1]: *** [winebuild] Error 1
make[1]: Leaving directory '/tmp/wine-2.10/tools/winebuild'
Makefile:20130: recipe for target 'tools/winebuild' failed
make: *** [tools/winebuild] Error 2
make[1]: Leaving directory '/tmp/wine-2.10/tools/winedump'
/tmp/ccjKNKbe.ltrans17.ltrans.o: In function `main':
:(.text.startup+0x47a): undefined reference to
`wpp_add_include_path'
:(.text.startup+0x4b9): undefined reference to
`wpp_add_cmdline_define'
:(.text.startup+0x652): undefined reference to
`wpp_add_include_path'
:(.text.startup+0x7a5): undefined reference to `wpp_set_debug'
:(.text.startup+0x890): undefined reference to `wpp_add_define'
:(.text.startup+0x8a4): undefined reference to `wpp_add_define'
:(.text.startup+0x976): undefined reference to `wpp_parse'
:(.text.startup+0xc34): undefined reference to `wpp_add_define'
:(.text.startup+0xd13): undefined reference to `wpp_parse'
/tmp/ccjKNKbe.ltrans0.ltrans.o: In function `parser_parse':
:(.text+0x15fc): undefined reference to `wpp_find_include'
:(.text+0x4d60): undefined reference to `wpp_parse'
:(.text+0x4ead): undefined reference to `wpp_find_include'
collect2: error: ld returned 1 exit status
Makefile:324: recipe for target 'widl' failed
make[1]: *** [widl] Error 1
make[1]: Leaving directory '/tmp/wine-2.10/tools/widl'
Makefile:20109: recipe for target 'tools/widl' failed
make: *** [tools/widl] Error 2

[Bug other/81146] New: Wine 2.10 cannot be compiled with -flto

[t.artem at mailcity dot com]

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

Bug ID: 81146
   Summary: Wine 2.10 cannot be compiled with -flto
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.artem at mailcity dot com
  Target Milestone: ---

I'm trying to compile Wine 2.10 with GCC 6.3.1 for the i686 target and I
cannot:

... skipped ...
gcc -c -o sfnt2fon.o sfnt2fon.c -I. -I../../include -I/usr/include/freetype2
-I/usr/include/libpng16 \
  -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
-Wempty-body \
  -Wignored-qualifiers -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \
  -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op
\
  -fno-omit-frame-pointer -O2 -march=pentium-m -m32 -pipe -flto -D__i386__
gcc -o sfnt2fon sfnt2fon.o ../../libs/port/libwine_port.a -lfreetype -m32
-Wl,-O1 -Wl,--hash-style=gnu -flto
/tmp/ccgeEnUu.ltrans0.ltrans.o: In function `main':
:(.text.startup+0x2c1): undefined reference to `wine_cp_get_table'
:(.text.startup+0x2e3): undefined reference to `wine_cp_get_table'
collect2: error: ld returned 1 exit status
Makefile:179: recipe for target 'sfnt2fon' failed
make[1]: *** [sfnt2fon] Error 1
make[1]: Leaving directory '/tmp/wine-2.10/tools/sfnt2fon'
Makefile:20099: recipe for target 'tools/sfnt2fon' failed
make: *** [tools/sfnt2fon] Error 2

These two commands were used before running ./configure && make
export CFLAGS="-O2 -march=pentium-m -m32 -pipe -flto"
export LDFLAGS="-m32 -Wl,-O1 -Wl,--hash-style=gnu -flto"

Of course I might be doing something wrong. In that case I'm sorry.

Without -flto everything works fine.

[Bug rtl-optimization/78911] [5/6 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2

[t.artem at mailcity dot com]

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

--- Comment #15 from Artem S. Tashkinov  ---
Strangely, this bug is still reproducible with GCC 6.3.1 and Wine 2.10.

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
(In reply to Andreas Krebbel from comment #0)
> Created attachment 41383 [details]
> Experimental patch

Andreas, thank you for working on the issue.  You are right.  The hard reg in
the clobber should be not be an earlyclobber one.  But, unfortunately the patch
is not fully correct.  Static data exists in one examplar for insn with the
same insn code and as consequence should not be dependent on other operands.

I'll think about the correct solution. Do you have a test case?  The patch
might be ready soon after I get the test.  Although it will take some time to
test the patch.

[Bug jit/81144] jit.dg/test-operator-overloading.cc, initial compilation

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Tue Jun 20 20:37:28 2017
New Revision: 249427

URL: https://gcc.gnu.org/viewcvs?rev=249427=gcc=rev
Log:
Fix -Werror=class-memaccess failures in jit testsuite (PR jit/81144)

gcc/testsuite/ChangeLog:
PR jit/81144
* jit.dg/test-operator-overloading.cc (make_test_quadratic): Replace
memset call with zero-initialization.
* jit.dg/test-quadratic.cc (make_test_quadratic): Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/jit.dg/test-operator-overloading.cc
trunk/gcc/testsuite/jit.dg/test-quadratic.cc

[Bug c++/80562] [7/8 Regression] ICE using if constexpr with nonconstant expression in function template

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #5 from Volker Reichelt  ---
*** Bug 80971 has been marked as a duplicate of this bug. ***

[Bug c++/81145] bogus "dereferencing type-punned pointer will break strict-aliasing rules" diagnostic with incomplete class type

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Marc Glisse  ---
Can you make it generate wrong code? I expect it is only the warning that is
broken.

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

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Volker Reichelt  ---
Fixed with Jason's patch for PR80562, so marking as duplicate.

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

[Bug jit/81144] jit.dg/test-operator-overloading.cc, initial compilation

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Thanks.  Am working on a fix.

[Bug c++/81145] New: bogus "dereferencing type-punned pointer will break strict-aliasing rules" diagnostic with incomplete class type

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 81145
   Summary: bogus "dereferencing type-punned pointer will break
strict-aliasing rules" diagnostic with incomplete
class type
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase:

struct B { int n; };
struct A
#ifndef BUG
 { B b; }
#endif
;

extern A a;
int n = reinterpret_cast()->n;

This produces a bogus "dereferencing type-punned pointer will break
strict-aliasing rules" diagnostic with -DBUG, but correctly suppresses the
warning when the definition of A is visible.

Note that under C++ P0137R1 / DR1776, the A object is pointer-interconvertible
with its b member, so the reinterpret_cast produces a usable pointer to a.b,
regardless of whether the definition of A is visible.

Perhaps GCC's TBAA should be less aggressive when comparing an incomplete type
against (at least) a standard-layout type?

[Bug jit/81144] New: jit.dg/test-operator-overloading.cc, initial compilation

[glisse at gcc dot gnu.org]

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

Bug ID: 81144
   Summary: jit.dg/test-operator-overloading.cc, initial
compilation
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

As seen for instance in
https://gcc.gnu.org/ml/gcc-testresults/2017-06/msg01884.html

In function 'void create_code(gcc_jit_context*, void*)':
/home/glisse/repos/gcc/trunk/gcc/testsuite/jit.dg/test-operator-overloading.cc:276:42:
error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial
type 'struct quadratic_test'; use assignment or value-initialization instead
[-Werror=class-memaccess]
/home/glisse/repos/gcc/trunk/gcc/testsuite/jit.dg/test-operator-overloading.cc:61:8:
note: 'struct quadratic_test' declared here
cc1plus: all warnings being treated as errors

Probably since the warning was introduced.

[Bug target/81143] New: New test case gcc.target/powerpc/pr79799-2.c fails on powerpc BE

[seurer at gcc dot gnu.org]

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

Bug ID: 81143
   Summary: New test case gcc.target/powerpc/pr79799-2.c fails on
powerpc BE
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This only fails on a big endian system:

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/pr79799-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power9 -O2
-ffat-lto-objects -S -o pr79799-2.s
PASS: gcc.target/powerpc/pr79799-2.c (test for excess errors)
PASS: gcc.target/powerpc/pr79799-2.c scan-assembler \\mxxinsertw\\M
FAIL: gcc.target/powerpc/pr79799-2.c scan-assembler-not \\mxxextractuw\\M
PASS: gcc.target/powerpc/pr79799-2.c scan-assembler-not \\mlvewx\\M
PASS: gcc.target/powerpc/pr79799-2.c scan-assembler-not \\mlvx\\M
PASS: gcc.target/powerpc/pr79799-2.c scan-assembler-not \\mvperm\\M
PASS: gcc.target/powerpc/pr79799-2.c scan-assembler-not \\mvpermr\\M
PASS: gcc.target/powerpc/pr79799-2.c scan-assembler-not \\mstfs\\M
PASS: gcc.target/powerpc/pr79799-2.c scan-assembler-not \\mstxssp\\M
PASS: gcc.target/powerpc/pr79799-2.c scan-assembler-not \\mstxsspx\\M

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

[vincent-gcc at vinc17 dot net]

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

--- Comment #10 from Vincent Lefèvre  ---
(In reply to jos...@codesourcery.com from comment #9)
> That wording defines what "normalized" is, so that values with maximum 
> exponent in this case don't count as normalized because not all values 
> with that exponent in the floating-point model are representable, and 
> defines LDBL_MAX so that it doesn't need to be normalized (and in this 
> case isn't, by that definition of normalized).  The definition of 
> LDBL_MAX_EXP is unchanged; it still just requires 2^(LDBL_MAX_EXP-1) to be 
> representable, without requiring it to be normalized.

This would be pretty useless as a definition. This would mean that emin is in
the "normalized" range (due to the LDBL_MIN_EXP definition), but one doesn't
have any guarantee for the larger exponents.

Thus a type that contains only 0, normalized values of exponent emin,
1+LDBL_EPSILON, and 2^(LDBL_MAX_EXP-1), could be a valid type (with, say, long
double = double = float). Just because you assume that emax has no relations
with normalized values.

Note that the standard doesn't specify a range for the property related to
LDBL_DIG, and this property is obviously incorrect for *any* floating-point
number with q decimal digits. In particular, the property is not satisfied in
general when the target is in the range of the subnormal numbers. So, I don't
expect it to be necessarily satisfied outside the range of the normalized
numbers.

[Bug c++/80633] [7/8 Regression] -Wstrict-aliasing false positive

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jason Merrill  ---
Then closing as fixed.

[Bug target/81142] Segmentation fault when using static __thread variables

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
This could be a glibc, binutils or gcc issue.  You have more than one page of
TLS variables here.  I don't remember the limits but it might be you are
hitting that limit.

[Bug target/81142] Segmentation fault when using static __thread variables

[tomas_paukrt at conel dot cz]

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

--- Comment #2 from tomas_paukrt at conel dot cz ---
Created attachment 41593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41593=edit
Output of gcc -v

[Bug target/81142] Segmentation fault when using static __thread variables

[tomas_paukrt at conel dot cz]

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

--- Comment #1 from tomas_paukrt at conel dot cz ---
Created attachment 41592
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41592=edit
Preprocessed source file

[Bug target/81142] New: Segmentation fault when using static __thread variables

[tomas_paukrt at conel dot cz]

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

Bug ID: 81142
   Summary: Segmentation fault when using static __thread
variables
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomas_paukrt at conel dot cz
  Target Milestone: ---

Created attachment 41591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41591=edit
C source file

If the attached C source file is cross-compiled using GCC 4.9.4 for AM335x CPU
(BeagleBone) then segmentation fault occurs.

Command line to compile: gcc -O2 -fPIC -march=armv7-a -mtune=cortex-a8
-mfloat-abi=softfp -mfpu=vfpv3 -mtls-dialect=gnu crash.c

The array size in the first function is key to causing an error.

[Bug middle-end/81030] [8 Regression] ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  Sounds like fallout of honzas reorg.

Bug seems to occur between gcc revision 248932 and 249008.

[Bug c/81141] missing warning using sizeof a/sizeof *a with a zero-length array

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
On second thought, the zero-length array misuses aren't limited to the (sizeof
P / sizeof *P) pattern.  When the type of *P is one byte wide they extend even
to sizeof P.  For example, the following call to strncpy is likely a mistake
and would benefit from being diagnosed as well.  So perhaps -Wsizeof-array
might be a better name for the new option.

$ cat z.c && gcc -O2 -S -Wall z.c
struct S { char n, a[1]; };

void h (struct S *s)
{
  __builtin_strncpy (s->a, "123", sizeof s->a);
}

There are actually two reasons for the code above to be considered buggy: one
is that the sizeof s->a expression is being applied to what is likely a
poor-man's fexible array, and another is that the call results in truncating
the copied string, leaving it unterminated.  The truncation should be diagnosed
independently of the latter problem (i.e., even if the array is not a
zero-length array or an array of size 1 that's the last member of a struct).

[Bug other/78366] target_clones does not generate resovler function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
(In reply to Martin Liška from comment #4)

> Yes, documentation should be enhanced. Thomas are you still planning to send
> patch for that? Or should I do it?

I'm currently working on something else, so if you could do it,
I would be obliged.

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
On Tue, 20 Jun 2017, vincent-gcc at vinc17 dot net wrote:

> > The current proposed wording for DR#467 
> >  changes 
> > "maximum representable finite floating-point number, [ math formula ]" to 
> > "maximum representable finite floating-point number; if that value is 
> > normalized, its value is [ math formula ],", which I think addresses the 
> > first issue without requiring any change to LDBL_MAX_EXP;
> 
> This change concerns the LDBL_MAX definition. However, there is another issue,
> related to the floating-point model 5.2.4.2.2p2 and p3. I assume that the
> intent of this definition is to require that *all* normalized floating-point
> numbers from this model are elements of the floating-point type (otherwise 
> emin
> and emax would no longer make any sense). But with the current status, some
> floating-point numbers of exponent LDBL_MAX_EXP = 1024 (those with f54 = 1, if
> I'm not mistaken) are not elements of the type "long double". The reason is
> that the first double must be the exact value rounded to nearest (with the 
> even
> rounding rule).

That wording defines what "normalized" is, so that values with maximum 
exponent in this case don't count as normalized because not all values 
with that exponent in the floating-point model are representable, and 
defines LDBL_MAX so that it doesn't need to be normalized (and in this 
case isn't, by that definition of normalized).  The definition of 
LDBL_MAX_EXP is unchanged; it still just requires 2^(LDBL_MAX_EXP-1) to be 
representable, without requiring it to be normalized.

> > LDBL_MAX should 
> > be the largest value, which in this case is not normalized, and 
> > LDBL_MAX_EXP has nothing to do with what exponents do or not not have 
> > normalized values.
> 
> But the largest value must be at least the largest normalized value, which
> equals (1−b^(−p))b^emax. Currently, LDBL_MAX is smaller than this value.

That's not a normalized value, because not all values with exponent emax 
are representable in the type, so none of them are normalized.

[Bug c/81141] New: missing warning using sizeof a/sizeof *a with a zero-length array

[msebor at gcc dot gnu.org]

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

Bug ID: 81141
   Summary: missing warning using sizeof a/sizeof *a with a
zero-length array
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC detects the common mistake of using the (sizeof P / sizeof *P) expression
to attempt to compute the length of an array when P is a pointer.  A similar
mistake  is using the same expression when P is a zero-length array because the
result is zero, or a one-element array as the last element of a struct because
such an array is often used as a substitute for a flexible array member.  This
is a enhancement request to add such a warning (either under
-Wsizeof-pointer-div or under a new option).

If this enhancement should be made available under a new warning option, since
the programming error it detects boils down to essentially the same problem
with the same conseequence, I would suggest to have the new option subsume the
-Wsizeof-pointer-div functionality as well.  A possible name for the new option
might be -Wsizeof-division: "warn about uses of sizeof that appear as if they
attempt to compute the size of an array but do not actually do so, or that may
yield the wrong number of elements."

$ cat x.c && gcc -O2 -S -Wall x.c
struct S { char n, *s, a[0]; };

void h (void *d, const struct S *s)
{
  __builtin_memcpy (d, s->s, sizeof s->s / sizeof *s->s);   // warning (good)
  __builtin_memcpy (d, s->a, sizeof s->a / sizeof *s->a);   // missing warning

  extern char a[0];

  __builtin_memcpy (d, s->a, sizeof a / sizeof *a); // missing warning
}

x.c: In function ‘h’:
x.c:5:42: warning: division ‘sizeof (char * const) / sizeof (char)’ does not
compute the number of array elements [-Wsizeof-pointer-div]
   __builtin_memcpy (d, s->s, sizeof s->s / sizeof *s->s);   // warning (good)
  ^

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

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

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Jun 20 16:47:58 2017
New Revision: 249421

URL: https://gcc.gnu.org/viewcvs?rev=249421=gcc=rev
Log:
PR c++/80972 - C++17 ICE with attribute packed.

* call.c (build_over_call): Allow a TARGET_EXPR from reference
binding.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/packed12.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/call.c

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

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Jun 20 16:47:17 2017
New Revision: 249420

URL: https://gcc.gnu.org/viewcvs?rev=249420=gcc=rev
Log:
PR c++/80972 - C++17 ICE with attribute packed.

* call.c (build_over_call): Allow a TARGET_EXPR from reference
binding.

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

[Bug c++/81139] Non-deduced return type in abbreviated function template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-20
 Ever confirmed|0   |1

[Bug ipa/81128] Function multi-versioning does not work with -O

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
the ifunc attribute is essentially slightly different syntactic sugar to the
alias attribute.  It sounds like the optimizer is treating the attribute as-if
it were an alias.

[Bug c/44943] Need documentation on the intended semantics of "volatile" (in C)

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

 CC||db0451 at gmail dot com

--- Comment #2 from DB  ---
As far as I can tell, according to P0162R0:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0612r0.html

which was adopted this month:
https://isocpp.org/blog/2017/03/2017-03-post-kona-mailing-available

the current behaviour of g++ is now Standard behaviour in C++ (if not C)

If so, then I guess the documentation needs updated:
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Volatiles.html

(I don't know yet whether this is intended as a DR to be backported to older
standards.)

[Bug c/33053] adopt accesses through a volatile-casted pointer as a GNU C extension

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

 CC||db0451 at gmail dot com

--- Comment #2 from DB  ---
As far as I can tell, according to P0162R0:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0612r0.html

which was adopted this month:
https://isocpp.org/blog/2017/03/2017-03-post-kona-mailing-available

the current behaviour of g++ is now Standard behaviour in C++ (if not C)

If so, then I guess the documentation needs updated:
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Volatiles.html

[Bug c++/81140] New: Update docs to reflect P0612R0: clarify meaning of "volatile access" + that it includes any glvalue

[db0451 at gmail dot com]

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

Bug ID: 81140
   Summary: Update docs to reflect P0612R0: clarify meaning of
"volatile access" + that it includes any glvalue
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: db0451 at gmail dot com
  Target Milestone: ---

As far as I can tell, according to P0162R0: NB comment CH 2
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0612r0.html

which was adopted earlier this year:
https://isocpp.org/blog/2017/03/2017-03-post-kona-mailing-available

the established, implementation-defined behaviour of g++ is now Standard
behaviour in C++ (if not C).

If so, then I guess this section of the documentation needs updated:

7.1 When is a Volatile C++ Object Accessed?
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Volatiles.html

I don't know whether this is intended as a DR to be backported to older
standards; my Standard-foo is not that strong.

[Bug c++/80095] [5/6 Regression] ICE with this pointer in NSDMI

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Not easily backportable, so closing.

[Bug c++/81139] New: Non-deduced return type in abbreviated function template

[andrew.n.sutton at gmail dot com]

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

Bug ID: 81139
   Summary: Non-deduced return type in abbreviated function
template
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.n.sutton at gmail dot com
  Target Milestone: ---

When a constrained-type-specifier is the same as that of a parameter type, the
return type is not deduced. 


template concept bool C = true;

C f(C) { return 0; }

void g() {
  auto x = f("x");
  static_assert(std::is_same::value);
}

The static assertion should fail.

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

[vincent-gcc at vinc17 dot net]

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

--- Comment #8 from Vincent Lefèvre  ---
It seems that the choice emin = -968, emax = 1024, p = 106 had been made
originally because all normalized values in this floating-point system (as
specified by 5.2.4.2.2p2) are representable as a sum of two double's (and even
two non-overlapping double's). However, the mistake is that not all pairs of
double's are valid in the type "long double" (as you can see with the LDBL_MAX
value). If only valid pairs are considered, then possible choices are:

* emin = -968, emax = 1024, p = 53 (but a poor choice as it would appear that
this is no better than the type double);

* emin = -968, emax = 1023, p = 106 (thus just decrease emax from the current
parameters);

* emin = -967, emax = 1023, p = 107 (I think that this would be a better
choice). The extra bit precision comes from the sign of the second double.

[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.1.0
 Resolution|--- |FIXED

--- Comment #11 from Richard Biener  ---
I would say so.  Fixed in GCC 7.

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values

[vincent-gcc at vinc17 dot net]

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

--- Comment #7 from Vincent Lefèvre  ---
(In reply to jos...@codesourcery.com from comment #6)
> The current proposed wording for DR#467 
>  changes 
> "maximum representable finite floating-point number, [ math formula ]" to 
> "maximum representable finite floating-point number; if that value is 
> normalized, its value is [ math formula ],", which I think addresses the 
> first issue without requiring any change to LDBL_MAX_EXP;

This change concerns the LDBL_MAX definition. However, there is another issue,
related to the floating-point model 5.2.4.2.2p2 and p3. I assume that the
intent of this definition is to require that *all* normalized floating-point
numbers from this model are elements of the floating-point type (otherwise emin
and emax would no longer make any sense). But with the current status, some
floating-point numbers of exponent LDBL_MAX_EXP = 1024 (those with f54 = 1, if
I'm not mistaken) are not elements of the type "long double". The reason is
that the first double must be the exact value rounded to nearest (with the even
rounding rule).

> LDBL_MAX should 
> be the largest value, which in this case is not normalized, and 
> LDBL_MAX_EXP has nothing to do with what exponents do or not not have 
> normalized values.

But the largest value must be at least the largest normalized value, which
equals (1−b^(−p))b^emax. Currently, LDBL_MAX is smaller than this value.

> It's true that GCC cannot handle IBM long double constants with more than 
> 106 mantissa bits, including the largest representable finite value.

With the current LDBL_MAX_EXP definition, GCC can handle all values with 53
mantissa bits, but this becomes wrong for 54 mantissa bits.

[Bug fortran/72743] ICE in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2958

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
What's the status of the PR? Can we close it?

[Bug ipa/79765] [CHKP] ICE in create_target_clone in multiple_target.c:211

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
I'll take a look.

[Bug ipa/81128] Function multi-versioning does not work with -O

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Well, I'm also not sure how it should behave. What happens currently is that we
have static alias and static resolver. Thus ipa-visibility finds out that call
to do_it_right_at_runtime can be replaced with resolve_do_it_right_at_runtime.
Then inlining happens. I'm adding Nathan who implemented ifunc support in GCC
and should know answer.

I suggest to not evaluate ifunc alias as not interposable. That would prevent
the problem.

[Bug other/16996] [meta-bug] code size improvements

[rearnsha at gcc dot gnu.org]

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

Bug 11824 Summary: [ARM] Parameter passing via stack could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11824

   What|Removed |Added

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

[Bug target/11824] [ARM] Parameter passing via stack could be improved

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Earnshaw  ---
I'm not sure exactly when this was fixed, but certainly it was some time ago. 
At least, gcc-4.6 appears to implement this optimization at -Os.

foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
stmfd   sp!, {r0, r1, r2, lr}
mov r3, #7
mov r2, #6
mov r0, sp
add r1, sp, #4
stmia   sp, {r2, r3}
bl  func
ldmfd   sp!, {r1, r2, r3, lr}
bx  lr

[Bug c++/67074] Name lookup ambiguity between namespace and its alias

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jun 20 12:53:11 2017
New Revision: 249408

URL: https://gcc.gnu.org/viewcvs?rev=249408=gcc=rev
Log:
PR c++/67074 - namespace aliases
* decl.c (duplicate_decls): Don't error here on mismatched
namespace alias.
* name-lookup.c (name_lookup::add_value): Matching namespaces are
not ambiguous.
(diagnose_name_conflict): Namespaces are never redeclarations.
(update_binding): An alias can match a real namespace.

PR c++/67074
* g++.dg/lookup/pr67074.C: New.
* g++.dg/parse/namespace-alias-1.C: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr67074.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/namespace-alias-1.C

[Bug sanitizer/81097] UBSAN: false positive for not existing negation operator and a bogus message

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed.  I believe latent issues remain, not 100% sure.

[Bug sanitizer/81097] UBSAN: false positive for not existing negation operator and a bogus message

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 20 12:46:46 2017
New Revision: 249407

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

PR middle-end/81097
* fold-const.c (split_tree): Fold to type before negating.

* c-c++-common/ubsan/pr81097.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr81097.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80732] target_clones does not work with dlsym

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Yichao Yu from comment #9)
> Thanks for the fix!
> 
> Does it fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78366 at the same
> time?

No as we're planning to document current behavior mentioned in PR78366 that
resolved is generated just in case a multiversioned function has a call in a
TU.

[Bug other/78366] target_clones does not generate resovler function

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Thomas Koenig from comment #3)
> OK, so this is more of a documentation issue.
> 
> Also not mentioned in the docs is that "default" has to be among
> the architectures in target_clone.
> 
> It is also not mentioned what happens if we try to compile
> for AVX on PowerPC.  I'll find out :-)
> 
> I'll submit a documentation patch.

Yes, documentation should be enhanced. Thomas are you still planning to send
patch for that? Or should I do it?

[Bug libstdc++/81138] std::money_put facet does not write '0' before decimal point

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jonathan.r.paton@googlemail
   ||.com

--- Comment #1 from Jonathan Wakely  ---
*** Bug 81137 has been marked as a duplicate of this bug. ***

[Bug c++/81137] std::put_money doesn't output zero value correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Oh, I filed it for you as PR 81138 (under the right component, libstdc++)

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

[Bug middle-end/81120] __builtin_nansl ("") generates quiet NaN

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from John David Anglin  ---
Given Joseph's comments, closing.

[Bug tree-optimization/81136] [8 Regression] ICE: in vect_update_misalignment_for_peel, at tree-vect-data-refs.c:910

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Started with r248730.

[Bug libstdc++/81138] New: std::money_put facet does not write '0' before decimal point

[redi at gcc dot gnu.org]

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

Bug ID: 81138
   Summary: std::money_put facet does not write '0' before decimal
point
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 
using namespace std;

int main() {
  cout.imbue(locale("en_US"));
  cout << showbase;
  cout << put_money(99);
  cout << '\n';
}

This prints $.99 rather than $0.99

This happens for all locales with with non-zero moneypunct<>::frac_digits().

The following untested patch fixes it, but I don't know if it breaks other
locales:


--- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc
+++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
@@ -471,6 +471,8 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL_OR_CXX11
else
  __value.assign(__beg, __paddec);
  }
+   else
+ __value.assign(1, __lit[money_base::_S_zero]);

// Deal with decimal point, decimal digits.
if (__lc->_M_frac_digits > 0)

[Bug debug/81135] Extra debug info generated for unused extern declarations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  Note that technically for

extern int j;
extern int i;
extern int bar (int);
extern int foo (int);

int main () { return foo (1) + i; }

we are still missing debuginfo for 'foo'.  If the module containing the
implementation was not built with -g then debugging experience in this
module is worse than necessary.

Note that 'foo' _is_ used here still neither GCC 5 nor GCC 6 create a DIE
for 'foo' but both generate one for 'i'.  GCC 6 now generates a DIE for 'j'
where GCC 5 didn't.  No compiler generates a DIE for 'bar'.

Same for GCC 7 + trunk.

I think we should have a mode where we generate debuginfo for all of the
extern declarations, used or not, and we should have a way to prune
unused extern decl DIEs.  Which means we should emit a DIE for 'foo' in
all cases (which will bloat info).  Otherwise why emit one for 'i'
(maybe have a mode to drop all extern DIEs which may be refered to via
the symtab).

[Bug c++/81137] New: std::put_money doesn't output zero value correctly

[jonathan.r.paton at googlemail dot com]

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

Bug ID: 81137
   Summary: std::put_money doesn't output zero value correctly
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathan.r.paton at googlemail dot com
  Target Milestone: ---

Sent from stack overflow, first report here so apologies in advance if I've
done anything incorrectly.

When using std::put_money to output a value of zero, I'd expect it to be
correctly, formatted, e.g. for GBP I'd expect "£0.00", however the actual
output is "£.00"

Personally I noticed this on version 4.9, however I've had reports that the
same behaviour is seen on 5.0, 6.3, and a handful of other versions. It also
appears that clang and the VS compiler behave differently and output the
expected string.

Code to reproduce:

#include 
#include 
using namespace std;

int main() {
cout.imbue(locale(""));
cout << showbase << put_money(0.0);
return 0;
}

[Bug tree-optimization/81136] [8 Regression] ICE: in vect_update_misalignment_for_peel, at tree-vect-data-refs.c:910

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[thopre01 at gcc dot gnu.org]

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

--- Comment #12 from Thomas Preud'homme  ---
Author: thopre01
Date: Tue Jun 20 11:19:36 2017
New Revision: 249406

URL: https://gcc.gnu.org/viewcvs?rev=249406=gcc=rev
Log:
Fix PR69866

2017-06-20  Thomas Preud'homme  

Backport from mainline
2017-06-15  Jan Hubicka  
Thomas Preud'homme  

gcc/
PR lto/69866
* lto-symtab.c (lto_symtab_merge_symbols): Drop useless definitions
that resolved externally.
2017-06-15  Thomas Preud'homme  

gcc/testsuite/
PR lto/69866
* gcc.dg/lto/pr69866_0.c: New test.
* gcc.dg/lto/pr69866_1.c: Likewise.

Backport from mainline
2017-06-18  Jan Hubicka  

gcc/testsuite/
* gcc.dg/lto/pr69866_0.c: This test needs alias.

Added:
branches/ARM/embedded-6-branch/gcc/lto/ChangeLog.arm
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.dg/lto/pr69866_0.c
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.dg/lto/pr69866_1.c
Modified:
branches/ARM/embedded-6-branch/gcc/lto/lto-symtab.c
branches/ARM/embedded-6-branch/gcc/testsuite/ChangeLog.arm

[Bug c++/81130] [6/7/8 Regression] ICE OpenMP shared clause in gimplify_var_or_parm_decl, at gimplify.c:2584

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
I think this is a different problem.  In my case the reason for adding an
invalid rematerialization appears to be that the live ranges of an hard
registers are not correctly calculated.

I've just verified with GCC head r249394:

For the two insns:

(insn 470 25077 476 10 (set (reg:CCU 33 %cc)
(compare:CCU (reg:DI 3 %r3 [orig:1277 _1997 ] [1277])
(mem/u/c:DI (reg:DI 5 %r5 [14737]) [5  S8 A64]))) "t.f90":48 1242
{*cmpdi_ccu}
 (nil))

(insn 472 27815 25079 10 (parallel [
(set (reg:SI 7 %r7 [orig:1282 _2003 ] [1282])
(plus:SI (plus:SI (gtu:SI (reg:CCU 33 %cc)
(const_int 0 [0]))
(reg:SI 7 %r7 [orig:1256 _1967 ] [1256]))
(reg:SI 2 %r2 [orig:1258 _1969 ] [1258])))
(clobber (reg:CC 33 %cc))
]) "t.f90":48 1661 {*addsi3_alc}
 (nil))

LRA records the following registers:

470:
{early_clobber_alts = 0, biggest_mode = DImode, type = OP_IN, subreg_p = 0, 
  early_clobber = 0, regno = 1277, next = 0x3cdb480}
{early_clobber_alts = 0, biggest_mode = DImode, type = OP_IN, subreg_p = 0, 
  early_clobber = 0, regno = 14737, next = 0x0}

hardregs:

{early_clobber_alts = 0, biggest_mode = CCUmode, type = OP_OUT, subreg_p = 0, 
  early_clobber = 0, regno = 33, next = 0x0}


472:

{early_clobber_alts = 0, biggest_mode = SImode, type = OP_OUT, subreg_p = 0, 
  early_clobber = 0, regno = 1282, next = 0x3cdb400}
{early_clobber_alts = 0, biggest_mode = SImode, type = OP_IN, subreg_p = 0, 
  early_clobber = 0, regno = 1256, next = 0x3cdb3e0}
{early_clobber_alts = 0, biggest_mode = SImode, type = OP_IN, subreg_p = 0, 
  early_clobber = 0, regno = 1258, next = 0x3cdb3c0}
{early_clobber_alts = 0, biggest_mode = CCUmode, type = OP_IN, subreg_p = 0, 
  early_clobber = 0, regno = 33, next = 0x0}

hardregs:
{early_clobber_alts = 18446744073709551615, biggest_mode = CCmode, type =  
OP_OUT, subreg_p = 0, early_clobber = 1, regno = 33, next = 0x0}

Marking r33 as early_clobber output makes it dead before insn 472 here:

lra-lives.c(915)
  /* Mark early clobber outputs dead.  */
  for (reg = curr_id->regs; reg != NULL; reg = reg->next)
if (reg->type == OP_OUT
&& reg_early_clobber_p (reg, n_alt) && ! reg->subreg_p)
  need_curr_point_incr
|= mark_regno_dead (reg->regno, reg->biggest_mode,
curr_point);

Reaching insn 470 with r33 being dead the reg is consequently marked as
"unused":

(insn 470 25077 476 10 (set (reg:CCU 33 %cc)
(compare:CCU (reg:DI 1277 [ _1997 ])
(mem/u/c:DI (reg:DI 14737) [5  S8 A64]))) "t.f90":48 1242
{*cmpdi_ccu}
 (expr_list:REG_UNUSED (reg:CC 33 %cc)
(expr_list:REG_DEAD (reg:DI 14737)
(nil

Since r33 is also an input operand to insn 472 it should not be marked as
early_clobber. The attached patch prevents that and fixes the problem for me.

[Bug tree-optimization/81136] New: [8 Regression] ICE: in vect_update_misalignment_for_peel, at tree-vect-data-refs.c:910

[trippels at gcc dot gnu.org]

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

Bug ID: 81136
   Summary: [8 Regression] ICE: in
vect_update_misalignment_for_peel, at
tree-vect-data-refs.c:910
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64le

trippels@gcc2-power8 linux % cat appletouch.i
struct {
  void *callback;
  _Bool open;
  int xy_acc[6];
  int smooth[];
} * a;
void fn1() {
  int i;
  int *b = a->xy_acc;
  i = 0;
  for (; i < fn1; i++)
a->smooth[i] = b[i];
}

trippels@gcc2-power8 linux % gcc -w -c -mno-altivec -mno-vsx -O3 appletouch.i
during GIMPLE pass: vect
appletouch.i: In function ‘fn1’:
appletouch.i:7:6: internal compiler error: in
vect_update_misalignment_for_peel, at tree-vect-data-refs.c:910
 void fn1() {
  ^~~
0x11255e23 vect_update_misalignment_for_peel
../../gcc/gcc/tree-vect-data-refs.c:909
0x1125607f vect_get_peeling_costs_all_drs
../../gcc/gcc/tree-vect-data-refs.c:1246
0x11264d4b vect_enhance_data_refs_alignment(_loop_vec_info*)
../../gcc/gcc/tree-vect-data-refs.c:1713
0x10c133b7 vect_analyze_loop_2
../../gcc/gcc/tree-vect-loop.c:2063
0x10c133b7 vect_analyze_loop(loop*, _loop_vec_info*)
../../gcc/gcc/tree-vect-loop.c:2403
0x10c31af7 vectorize_loops()
../../gcc/gcc/tree-vectorizer.c:614
0x10af86fb execute
../../gcc/gcc/tree-ssa-loop.c:412

[Bug target/25111] [m68k] bset is not used for A = 1 << (B & 31) on ColdFire

[sch...@linux-m68k.org]

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

Bug 80970 Summary: [7 Regression] internal compiler error in find_reloads, at 
reload.c:4077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80970

   What|Removed |Added

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

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

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #8 from Andreas Schwab  ---
Fixed.

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

[schwab at gcc dot gnu.org]

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

--- Comment #7 from Andreas Schwab  ---
Author: schwab
Date: Tue Jun 20 10:27:32 2017
New Revision: 249402

URL: https://gcc.gnu.org/viewcvs?rev=249402=gcc=rev
Log:
PR target/80970
* config/m68k/m68k.md (bsetdreg, bchgdreg, bclrdreg): Use "=d"
instead of "+d".

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr80970.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/m68k/m68k.md

[Bug debug/81135] New: Extra debug info generated for unused extern declarations

[peadar at arista dot com]

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

Bug ID: 81135
   Summary: Extra debug info generated for unused extern
declarations
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peadar at arista dot com
  Target Milestone: ---

Created attachment 41589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41589=edit
Contains trivial test program, and output from gcc-5 and gcc-6 showing old and
new behaviour

This is a follow-up to track the discussion at
https://gcc.gnu.org/ml/gcc-help/2017-06/threads.html#00086

Since version 6.1.0, gcc has produced DW_TAG_variable DIEs for variables
declared as extern, but not otherwise used in the translation unit.

For libraries with large numbers of object files compiled from source
containing a large number of extern declarations, the overhead of this can be
quite significant

I've attached a tarball including the output gcc-6 and gcc-5 from an ubuntu
17.04 system, the former of which exhibits the problem, the latter which does
not. You can see that the `fooUnused` extern declaration has a DW_TAG_variable
with gcc-6, but not gcc-5.

As per the discussion thread, this seems to be fallout from the integration of
the "debug-early" branch, and discussion at
https://gcc.gnu.org/ml/gcc/2015-05/msg00046.html seems to suggest that some
bloating of DWARF data was expected, and that later work would address the
issue.

Bisecting the git mirror on github does show the behaviour being introduced at
https://github.com/gcc-mirror/gcc/commit/3a1c9df , which is where this branch
merged in.

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

[schwab at gcc dot gnu.org]

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

--- Comment #6 from Andreas Schwab  ---
Author: schwab
Date: Tue Jun 20 10:15:47 2017
New Revision: 249401

URL: https://gcc.gnu.org/viewcvs?rev=249401=gcc=rev
Log:
PR target/80970
* config/m68k/m68k.md (bsetdreg, bchgdreg, bclrdreg): Use "=d"
instead of "+d".

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80970.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k.md

[Bug c++/81134] C++ partial template specialization issue

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is not a bug, the conditional expression using ?: instantiates both
branches, so although one branch uses the terminating case, the other one
doesn't.

You can make the code valid like this:

template 
struct GCD
{
   static const int value
 = std::conditional<(N>M), GCD, GCD>::type::value;
};

Or like this:

template 
struct GCD : std::conditional<(N>M), GCD, GCD>::type
{ };

[Bug sanitizer/81097] UBSAN: false positive for not existing negation operator and a bogus message

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 20 Jun 2017, mpolacek at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81097
> 
> --- Comment #3 from Marek Polacek  ---
> Well, my fix was
> 
> --- a/gcc/fold-const.c
> +++ b/gcc/fold-const.c
> @@ -850,7 +850,8 @@ split_tree (location_t loc, tree in, tree type, enum
> tree_code code,
>else if (TREE_CONSTANT (in))
>  *conp = in;
>else if (TREE_CODE (in) == BIT_NOT_EXPR
> -  && code == PLUS_EXPR)
> +  && code == PLUS_EXPR
> +  && negate_expr_p (TREE_OPERAND (in, 0)))
>  {
>/* -X - 1 is folded to ~X, undo that here.  Do _not_ do this
>   when IN is constant.  */
> 
> but it has some fallout it seems.
> 
> Also, the comment says
> -X - 1 is folded to ~X, undo that here.
> but there was not -X - 1, the bit not came from
> ~x | ~y -> ~(x & y)
> in match.pd.

Yeah, it's not "undoing" but trying to cleverly combine ~x + 1 to x.
Possibly the fallout testcases you've seen or some archeology will tell.

I think it's really trying to "undo" this transform AFAIR (I remember
adding this code).

Using negate_expr_p is checking for "easily negatable", you could
use a TYPE_OVERFLOW_UNDEFINED check but that would have similar
fallout.  Or just force the negation to use an unsigned type
(my patch does this for the testcase), but I'm not even sure that
will work because if the original expr is int then ~x + ~x
becomes (int)(-(unsigned)x - (unsigned)x) - 2 and supposedly we can
craft x to be so that (int)(-(unsigned)x - (unsigned)x) - 2 will
overflow.  The associate case is somewhat defensive when associating
TYPE_OVERFLOW_UNDEFINED stuff but I'm not sure what it does is enough.

I'm currentlyu testing

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 249397)
+++ gcc/fold-const.c(working copy)
@@ -853,9 +853,9 @@ split_tree (location_t loc, tree in, tre
   && code == PLUS_EXPR)
 {
   /* -X - 1 is folded to ~X, undo that here.  Do _not_ do this
- when IN is constant.  */
-  *minus_litp = build_one_cst (TREE_TYPE (in));
-  var = negate_expr (TREE_OPERAND (in, 0));
+ when IN is constant.  Convert to TYPE before negating.  */
+  *minus_litp = build_one_cst (type);
+  var = negate_expr (fold_convert_loc (loc, type, TREE_OPERAND (in, 
0)));
 }
   else
 var = in;

which is, as I said, not enough but another testcase is appreciated ;)

[Bug sanitizer/81097] UBSAN: false positive for not existing negation operator and a bogus message

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Well, my fix was

--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -850,7 +850,8 @@ split_tree (location_t loc, tree in, tree type, enum
tree_code code,
   else if (TREE_CONSTANT (in))
 *conp = in;
   else if (TREE_CODE (in) == BIT_NOT_EXPR
-  && code == PLUS_EXPR)
+  && code == PLUS_EXPR
+  && negate_expr_p (TREE_OPERAND (in, 0)))
 {
   /* -X - 1 is folded to ~X, undo that here.  Do _not_ do this
  when IN is constant.  */

but it has some fallout it seems.

Also, the comment says
-X - 1 is folded to ~X, undo that here.
but there was not -X - 1, the bit not came from
~x | ~y -> ~(x & y)
in match.pd.

[Bug sanitizer/81097] UBSAN: false positive for not existing negation operator and a bogus message

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|mpolacek at gcc dot gnu.org|rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
The negation is emitted from

#1  0x00d6fb2f in split_tree (loc=2147483652, 
in=, type=, 
code=PLUS_EXPR, conp=0x7fffc758, litp=0x7fffc750, 
minus_litp=0x7fffc748, negate_p=0)
at /space/rguenther/src/svn/early-lto-debug/gcc/fold-const.c:858
858   var = negate_expr (TREE_OPERAND (in, 0));
(gdb) l
853&& code == PLUS_EXPR)
854 {
855   /* -X - 1 is folded to ~X, undo that here.  Do _not_ do this
856  when IN is constant.  */
857   *minus_litp = build_one_cst (TREE_TYPE (in));
858   var = negate_expr (TREE_OPERAND (in, 0));

when folding

  (unsigned short) ~((signed short) a & (signed short) c)
+ (unsigned short) ~((signed short) b & (signed short) c)

so first-hand the error is obvious - we do not convert to 'type' before
negating.

But!  I think that may be not enough to fix things (it fixes this testcase)
as we generally cannot fold ~x to -x - 1 for types with undefined overflow.

[Bug ipa/81128] Function multi-versioning does not work with -O

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2017-06-20
  Component|c   |ipa
 CC||marxin at gcc dot gnu.org,
   ||mliska at suse dot cz
 Ever confirmed|0   |1
Summary|Function multi-versioning   |Function multi-versioning
   |does not work with -Ofast   |does not work with -O
  Known to fail||4.8.5, 6.3.1, 7.1.1, 8.0

--- Comment #4 from Richard Biener  ---
Confirmed.  Even -O1 breaks it, I suppose we somehow inline the resolver
improperly which means a bogus cgraph is constructed?

GCC 4.8 gets it right at -O1 but fails at -O2, so I guess this never worked
correctly.

Declaring resolve_do_it_right_at_runtime with __attribute__((noinline,noclone))
doesn't fix this though...

main () ends up calling the resolver directly, no ifunc is emitted.

I'm not 100% sure this is proper use of attribute ifunc, defering to Martin
here.

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/81130] [6/7/8 Regression] ICE OpenMP shared clause in gimplify_var_or_parm_decl, at gimplify.c:2584

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.4

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

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #5 from Andreas Schwab  ---
*** Bug 81131 has been marked as a duplicate of this bug. ***

[Bug target/81131] [m68k] internal compiler error: in find_reloads, at reload.c:4077

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #2 from Andreas Schwab  ---
.

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

[Bug c++/46476] Missing Warning about unreachable code after return

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #12 from David Binderman  ---
(In reply to Jon Grant from comment #11)
> Perhaps some new static analysis tools could be added to GCC. I'd be happy
> to contribute to costs.

I keep finding new warnings that static analysis tools emit that gcc can't,
but rarely do these new warnings get implemented in gcc.

Gcc developers seem keen to keep away from static analysis area.
If you push them, they say they are only a volunteer project.

Far more folks run compilers than static analysis tools, so popularising
new warnings would help the wider community.

In practice locally, I modify gcc compilers to also run static analysis tools.
Then developers can't avoid knowing more about their code.

[Bug tree-optimization/67886] Incomplete optimization for virtual function call into freshly constructed object

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||tetra2005 at gmail dot com

--- Comment #2 from Yuri Gribov  ---
There is a more important optimization hiding here.

Standard suggests (in 3.8.7, in n3690.pdf) that when the same source variable
is used for the instance pointer, it's dynamic type should not change. This
allows code like
  Base *p = new Derived;
  p->foo();
  p->foo();
to be optimized to
  Derived::foo(p);
  Derived::foo(p);
(which would also allow to optimize Simon's original case).

Clang currently performs this sort of optimization (see old discussion in
https://groups.google.com/forum/#!topic/llvm-dev/XPxvsEauirM and recent blog
post in http://blog.llvm.org/2017/03/devirtualization-in-llvm-and-clang.html).

This sort of optimization requires frontend knowledge so probly can't be done
solely in GIMPLE? Summon Honza to comment.

[Bug target/81131] [m68k] internal compiler error: in find_reloads, at reload.c:4077

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
*** Bug 81132 has been marked as a duplicate of this bug. ***

[Bug target/81132] [m68k] internal compiler error: in find_reloads, at reload.c:4077

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Liška  ---
Dup.

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

[Bug c++/81130] [6/7/8 Regression] ICE OpenMP shared clause in gimplify_var_or_parm_decl, at gimplify.c:2584

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-20
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|ICE OpenMP shared clause in |[6/7/8 Regression] ICE
   |gimplify_var_or_parm_decl,  |OpenMP shared clause in
   |at gimplify.c:2584  |gimplify_var_or_parm_decl,
   ||at gimplify.c:2584
 Ever confirmed|0   |1

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

[Bug c++/81134] New: C++ partial template specialization issue

[manish.baphna at citi dot com]

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

Bug ID: 81134
   Summary: C++ partial template specialization issue
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manish.baphna at citi dot com
  Target Milestone: ---

Following code going into recursive template instantiation without realizing
terminating case. Works find with clang.

template   
struct GCD
{  
   static const int value = (N>M)? GCD::value : GCD::value;  
}; 
  
template  
struct GCD<0, M>{  
   static const int value = M;  
};  
template  
struct GCD
{
 static const int value = M ; 
};  
int main()  
{
static_assert(GCD<12,15>::value == 3, "Error");
} 

Error: g++ lcd.cpp -std=c++11
fatal error: template instantiation depth exceeds maximum of 900 (use
-ftemplate-depth= to increase the maximum)
  static const int value = (N>M)? GCD::value : GCD::value;

[Bug sanitizer/81125] [7/8 Regression] -fsanitize=undefined ICE

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 20 07:10:14 2017
New Revision: 249397

URL: https://gcc.gnu.org/viewcvs?rev=249397=gcc=rev
Log:
PR sanitizer/81125
* ubsan.h (ubsan_encode_value): Workaround buggy clang++ parser
by removing enum keyword.
(ubsan_type_descriptor): Likewise.  Formatting fix.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ubsan.h

[Bug target/81121] [7/8 Regression] ICE: in extract_insn, at recog.c:2311

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 20 07:04:27 2017
New Revision: 249396

URL: https://gcc.gnu.org/viewcvs?rev=249396=gcc=rev
Log:
PR target/81121
* config/i386/i386.md (TARGET_USE_VECTOR_CONVERTS float si->{sf,df}
splitter): Require TARGET_SSE2 in the condition.

* gcc.target/i386/pr81121.c: New test.

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

[Bug target/79799] Improve vec_insert of float on Power9

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Tue Jun 20 06:26:27 2017
New Revision: 249395

URL: https://gcc.gnu.org/viewcvs?rev=249395=gcc=rev
Log:
[gcc]
2017-06-20  Michael Meissner  

PR target/79799
* config/rs6000/rs6000.c (rs6000_expand_vector_init): Add support
for doing vector set of SFmode on ISA 3.0.
* config/rs6000/vsx.md (vsx_set_v4sf_p9): Likewise.
(vsx_set_v4sf_p9_zero): Special case setting 0.0f to a V4SF
element.
(vsx_insert_extract_v4sf_p9): Add an optimization for inserting a
SFmode value into a V4SF variable that was extracted from another
V4SF variable without converting the element to double precision
and back to single precision vector format.
(vsx_insert_extract_v4sf_p9_2): Likewise.

[gcc/testsuite]
2017-06-20  Michael Meissner  

PR target/79799
* gcc.target/powerpc/pr79799-1.c: New test.
* gcc.target/powerpc/pr79799-2.c: Likewise.
* gcc.target/powerpc/pr79799-3.c: Likewise.
* gcc.target/powerpc/pr79799-4.c: Likewise.
* gcc.target/powerpc/pr79799-5.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr79799-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr79799-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr79799-3.c
trunk/gcc/testsuite/gcc.target/powerpc/pr79799-4.c
trunk/gcc/testsuite/gcc.target/powerpc/pr79799-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

[tetra2005 at gmail dot com]

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

--- Comment #8 from Yuri Gribov  ---
Alan,(In reply to Alan Modra from comment #0)
> It looks like gcc incorrectly prefers a range test.

Alan, can we close this?

[Bug ipa/81133] New: [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[trippels at gcc dot gnu.org]

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

Bug ID: 81133
   Summary: [8 Regression] PGO/LTO bootstrap: ICE: in
inline_small_functions, at ipa-inline.c:1891
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at ucw dot cz, marxin at gcc dot gnu.org
  Target Milestone: ---

PGO/LTO bootstrap fails during stagefeedback:

during IPA pass: inline
lto1: internal compiler error: in inline_small_functions, at ipa-inline.c:1891
0x7dff28 inline_small_functions
../../src-trunk/gcc/ipa-inline.c:1891
0x7dff28 ipa_inline
../../src-trunk/gcc/ipa-inline.c:2429
0x7dff28 execute
../../src-trunk/gcc/ipa-inline.c:2835