[Bug middle-end/78947] sub-optimal code for (bool)(int ? int : int)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-29
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed, this is fold-cost folding:
(bool)(a?b:c)
into a ? (bool) b : (bool)c;
early.

Rewriting the code slightly gets the code you wanted:
bool condSet(int cond, int a, int b) {
int c;
c = cond ? a : b;
return c;
}

[Bug tree-optimization/78947] New: sub-optimal code for (bool)(int ? int : int)

[peter at cordes dot ca]

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

Bug ID: 78947
   Summary: sub-optimal code for (bool)(int ? int : int)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Full version:
http://stackoverflow.com/questions/41323911/why-the-difference-in-code-generation-for-bool-bool-int-int


bool condSet(int cond, int a, int b) {
return cond ? a : b;
}

clang and icc use a cmov to select a or b, and then booleanize that.

g++6.3 -O3 decides to booleanize b, then check the condition and if necessary
booleanize a into %al.  This is pretty obviously sub-optimal, even if a branch
is better than a cmov for a predictable condition.  (And it differs from what
gcc does if the return type is int)

condSet(int, int, int):
testl   %edx, %edx# b
setne   %al   #, 
testl   %edi, %edi# cond
jne .L6   #,
rep ret
.L6:
testl   %esi, %esi# a
setne   %al   #, 
ret



Writing the function as 

  int foo = cond ? a : b;
  return foo;

gets g++ to select an operand with cmov and then booleanize it, like clang does
in the first place (looks optimal to me):

testl   %edi, %edi
cmovel  %edx, %esi
testl   %esi, %esi
setne   %al
retq

[Bug target/78946] New: optimization throws internal compiler error for uint64_t on AVR

[tho...@maier-komor.de]

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

Bug ID: 78946
   Summary: optimization throws internal compiler error for
uint64_t on AVR
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tho...@maier-komor.de
  Target Milestone: ---

Created attachment 40427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40427=edit
set of testcase files, compile testcase.cc with -O2 to reproduce ICE

The attached code produces for optimization levels -O2 an internal compiler
error while it works without an issue for -Os. this is at least with gcc-4.9.2
and 6.3.0

thomas@glaskugel:~/avr/arduino-mini/sensor1$ /opt/local/bin/avr-g++ --version
avr-g++ (GCC) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.

thomas@glaskugel:~/avr/arduino-mini/sensor1$ /opt/local/bin/avr-g++ -c
-I/usr/lib/avr/include -O2 testcase.cc
testcase.cc: In Elementfunktion »size_t Sensor_AD::fromMemory(const void*,
size_t)«:
testcase.cc:127:1: Fehler: unerkennbarer Befehl:
 }
 ^
(insn 58 57 59 6 (parallel [
(set (reg:HI 84)
(minus:HI (subreg:HI (subreg:SI (reg:DI 81) 0) 0)
(reg:HI 82)))
(clobber (scratch:QI))
]) testcase.cc:74 -1
 (nil))
testcase.cc:127:1: interner Compiler-Fehler: in extract_insn, bei recog.c:2287
0xa1abd8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-6.3.0/gcc/rtl-error.c:108
0xa1ac09 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-6.3.0/gcc/rtl-error.c:116
0x9f0c99 extract_insn(rtx_insn*)
../../gcc-6.3.0/gcc/recog.c:2287
0x84eb83 instantiate_virtual_regs_in_insn
../../gcc-6.3.0/gcc/function.c:1582
0x84eb83 instantiate_virtual_regs
../../gcc-6.3.0/gcc/function.c:1950
0x84eb83 execute
../../gcc-6.3.0/gcc/function.c:1999
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
inclusive vorverarbeitetem Quellcode, wenn es dienlich ist.
Please include the complete backtrace with any bug report.
Siehe  für nähere Anweisungen.


thomas@glaskugel:~/avr/arduino-mini/sensor1$ avr-g++ --version
avr-g++ (GCC) 4.9.2
Copyright (C) 2014 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.

thomas@glaskugel:~/avr/arduino-mini/sensor1$ avr-g++ -c -O2 testcase.cc
testcase.cc: In member function ‘size_t Sensor_AD::fromMemory(const void*,
size_t)’:
testcase.cc:127:1: error: unrecognizable insn:
 }
 ^
(insn 58 57 59 6 (parallel [
(set (reg:HI 85)
(minus:HI (subreg:HI (subreg:SI (reg:DI 82) 0) 0)
(reg:HI 83)))
(clobber (scratch:QI))
]) testcase.cc:74 -1
 (nil))
testcase.cc:127:1: internal compiler error: in extract_insn, at recog.c:2202
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op

[rin at NetBSD dot org]

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

--- Comment #11 from Rin Okuyama  ---
Thank you for your response, and sorry for the late reply.

(In reply to Segher Boessenkool from comment #10)
> > > That might or might not work; the user had better know what he is
> > > doing if he uses an assembler option.
> > 
> > Hmm, I understand. Is this documented explicitly anywhere?
> 
> Not in so many words I think, no.

It would be nice if you could document it somewhere.

> > We use -Wa,-me500 option to compile kernel on some machines. As they
> > share userland with other machines, we cannot configure GCC for a
> > powerpc-*-eabispe* target. Instead, I found a workaround to specify
> > -mcpu=powerpc option. It passes -mppc option to assembler, but as it
> > is preceding to -me500, the latter is prior to the former.
> 
> Maybe you could use -mcpu=e500mc or similar?  Or, GCC should probably
> have a -mcpu=e500 option, but someone has to write the code for it.

Yeah, I hope so. But that would be another problem.

Let me thanks again for your kind support!

[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm-*

--- Comment #1 from nsz at gcc dot gnu.org ---
building a cross compiler with --with-mode=thumb --with-arch=armv7 fails with

/tmp/ccCnEnAK.s:61: Error: selected processor does not support `uadd8 r3,r3,r3'
in Thumb mode
/tmp/ccCnEnAK.s:63: Error: selected processor does not support `sel r3,r1,r4'
in Thumb mode

because the asm in

libatomic/config/arm/exch_n.c

is not compatible with armv7-m.

[Bug target/78945] New: [arm

[nsz at gcc dot gnu.org]

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

Bug ID: 78945
   Summary: [arm
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[gccbugbjorn at fahller dot se]

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

--- Comment #4 from Björn Fahller  ---
It also only partially solves the problem. If the struct is made const, or the
decomposition declaration is changed to "auto const& [p] = s;", it still fails.

[Bug fortran/78780] [7 Regression] [Coarray] ICE in conv_caf_send, at fortran/trans-intrinsic.c:1936

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from vehre at gcc dot gnu.org ---
Closing, no regressions reported.

[Bug fortran/77785] [Coarray] ICE in gfc_get_caf_token_offset, at fortran/trans-expr.c:1990

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from vehre at gcc dot gnu.org ---
No regressions reported, closing.

[Bug demangler/78944] New: null pointer in demangler

[vanyacpp at gmail dot com]

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

Bug ID: 78944
   Summary: null pointer in demangler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Demangling the name _Z3fooAv32pM causes null pointer dereferencing:

$ valgrind c++filt _Z3fooAv32pM
==11277== Memcheck, a memory error detector
==11277== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11277== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==11277== Command: c++filt _Z3fooAv32pM
==11277== 
==11277== Invalid read of size 1
==11277==at 0x4F140D9: d_expression_1 (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F13091: cplus_demangle_type (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F13387: d_parmlist (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F137FF: d_bare_function_type (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F14E80: d_encoding (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F1534B: cplus_demangle_mangled_name (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F1597A: d_demangle_callback (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F15AE8: d_demangle (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F15C3D: cplus_demangle_v3 (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x4F07153: cplus_demangle (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/lib/libbfd-2.26.20160125.so)
==11277==by 0x402293: demangle_it (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/bin/c++filt)
==11277==by 0x401F2C: main (in
/nix/store/bxzwd8nb1jjdh9fcqpii4x7r4gl2s8qb-binutils-2.26/bin/c++filt)
==11277==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

[Bug c/78933] [7 Regression] ICE: in decode_cmdline_option, at opts-common.c:671 with -fno-strong-eval-order

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #3 from Jakub Jelinek  ---
Preapproved.

[Bug translation/78745] Truncated messages in po file

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 40426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40426=edit
gcc7-pr78745.patch

Untested fix.

For the multiple line help texts, opt-gather.awk concatenates those lines with
SUBSEP in between them, and opt-read.awk then replaces those SUBSEP separators
with spaces:
help[n_opts]  = $3
for (i = 4; i <= NF; i++)
help[n_opts] = help[n_opts] " " $i
With this patch, there are changes like:
 #: config/arm/arm.opt:231
-msgid "Print CPU tuning information as comment in assembler file.  This is"
+msgid ""
+"Print CPU tuning information as comment in assembler file.  This is an "
+"option used only for regression testing of the compiler and not intended for
"
+"ordinary use in compiling code."
 msgstr ""

in the gcc.pot file.

[Bug c++/78943] New: Generated assembler fails with symbol is already defined

[charles.frasch at gmail dot com]

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

Bug ID: 78943
   Summary: Generated assembler fails with symbol is already
defined
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: charles.frasch at gmail dot com
  Target Milestone: ---

Created attachment 40425
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40425=edit
bmbt.ii

Compiler output:
/tmp/ccYwRjuK.s: Assembler messages:
/tmp/ccYwRjuK.s:696: Error: symbol `_ZN2azlsINS_2bcEhEEvT_T0_' is already
defined


GNU assembler version 2.24 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.24


Reproduce with:
g++-6.3.0 -std=c++14 -Werror -c bmbt.ii

Build configuration:
Using built-in specs.
COLLECT_GCC=g++-6.3.0
COLLECT_LTO_WRAPPER=/home/cfrasch/local/bin/../libexec/gcc/x86_64-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-6.3.0/configure -v --enable-languages=c,c++
--disable-multilib --with-build-config=bootstrap-lto --program-suffix=-6.3.0
--enable-shared --without-included-gettext --enable-threads=posix --enable-nls
--enable-nls --enable-gnu-unique-object --with-system-zlib --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-pkgversion=Thesys 6.3.0-1 ubuntu 14.04
Thread model: posix
gcc version 6.3.0 (Thesys) 


This may be another manifestation of #78908


Thanks

[Bug translation/78745] Truncated messages in po file

[fmarchal at perso dot be]

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

--- Comment #6 from Frederic Marchal  ---
More truncated lines in gcc/config/arm/arm.opt at line 231 and 266,

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
But that goes against
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2446
So, I think GB 20 is in conflict with LWG2446, we can have just one of those.

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I think this boils down if

#include 
struct S { int s; };
std::tuple_size t;
is valid or not (with  instead of  it is invalid).
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
   // 2770. tuple_size specialization is not SFINAE compatible
   template
-struct __tuple_size_cv_impl { };
+struct __tuple_size_cv_impl /*{ }*/;

in utility makes it invalid and the decomposition then works fine.

[Bug target/78904] zero-extracts are not effective

[uros at gcc dot gnu.org]

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

--- Comment #13 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Dec 28 15:16:26 2016
New Revision: 243955

URL: https://gcc.gnu.org/viewcvs?rev=243955=gcc=rev
Log:
PR target/78904
* config/i386/constraints.md (Bn): New special memory constraint.
* config/i386/predicates.md (norex_memory_operand): New predicate.
* config/i386/i386.md (*extzvqi_mem_rex64): New insn pattern and
corresponding peephole2 pattern.

testsuite/ChangeLog:

PR target/78904
* gcc.target/i386/pr78904-4.c: New test.
* gcc.target/i386/pr78904-5.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78904-4.c
trunk/gcc/testsuite/gcc.target/i386/pr78904-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78942] New: Incorrect error message for preprocessed source

[baradi09 at gmail dot com]

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

Bug ID: 78942
   Summary: Incorrect error message for preprocessed source
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

The line number and the code shown in error messages are inconsistent, when
instead of preprocessing a file on the fly (option -cpp) the file is
preprocessed first (-cpp -E) and then compiled with gfortran.

echo 'program F,AIL' > test.F90; gfortran -cpp test.F90

yields the CORRECT error message:

test.F90:1:7:

 program F,AIL
   1
Error: Invalid form of PROGRAM statement at (1)

While

echo 'program F,AIL' > test.F90; gfortran -cpp -E test.F90 > test.f90; gfortran
test.f90

gives the WRONG error message:

test.f90:1:7:

 # 1 "test.F90"
   1
Error: Invalid form of PROGRAM statement at (1)

The preprocessed file (test.f90) looks as:

# 1 "test.F90"
# 1 ""
# 1 ""
# 1 "test.F90"
program F,AIL

which seems to be correct, though.

Actually, the issue can be cured by changing the first line marker to indicate
an include file, as running gfortran on the modified preprocessed source below
gives the correct error message again:

# 1 "test.F90" 1
# 1 ""
# 1 ""
# 1 "test.F90"
program F,AIL

Probably the error was introduced in gfortran 5, as the error messages are
consistent in 4.9, but not in 5.1 any more.

This bug may be also related to bug 78792.

[Bug translation/78745] Truncated messages in po file

[fmarchal at perso dot be]

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

--- Comment #5 from Frederic Marchal  ---
More truncated lines in gcc/config/s390/s390.opt at lines 116, 178, 195,

[Bug c/78941] New: Typo in maccumulate-args description

[fmarchal at perso dot be]

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

Bug ID: 78941
   Summary: Typo in maccumulate-args description
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

In gcc/config/avr/avr.opt at line 77, the description for maccumulate-args is

maccumulate-args
Target Report Mask(ACCUMULATE_OUTGOING_ARGS)
Accumulate outgoing function arguments and acquire/release the needed stack
space for outpoing function arguments in function prologue/epilogue.  Without
this option, outgoing arguments are pushed before calling a function and popped
afterwards.  This option can lead to reduced code size for functions that call
many functions that get their arguments on the stack like, for example printf.

Notice the "outpoing" that should very likely be "outgoing".

[Bug c++/78931] [7 Regression] ICE on C++17 structured bindings from struct with reference member

[gccbugbjorn at fahller dot se]

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

--- Comment #4 from Björn Fahller  ---
I can confirm that this works with my original program too, and not just the
condensed test case.

[Bug c++/78931] [7 Regression] ICE on C++17 structured bindings from struct with reference member

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/78931] [7 Regression] ICE on C++17 structured bindings from struct with reference member

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 40424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40424=edit
gcc7-pr78931.patch

Untested fix.

[Bug libstdc++/78939] [C++17] interferes with structured binding from struct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-28
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
  Component|c++ |libstdc++
Summary| interferes with |[C++17]  interferes
   |structured binding from |with structured binding
   |struct  |from struct
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
That is a consequence of the recent P0490R0 GB 20 change and  having:
  /// Finds the size of a given tuple type.
  template
struct tuple_size;

  // _GLIBCXX_RESOLVE_LIB_DEFECTS
  // 2770. tuple_size specialization is not SFINAE compatible
  template
struct __tuple_size_cv_impl { };

  template
struct __tuple_size_cv_impl<_Tp,
__void_t::value)>>
: integral_constant::value> { };

  // _GLIBCXX_RESOLVE_LIB_DEFECTS
  // 2313. tuple_size should always derive from integral_constant
  template
struct tuple_size : __tuple_size_cv_impl<_Tp> { };

  template
struct tuple_size : __tuple_size_cv_impl<_Tp> { };

  template
struct tuple_size : __tuple_size_cv_impl<_Tp> { };

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2770

So, either the GB 20 change has been added without considering the effect on
the existing , or there is some further  change needed, or
libstdc++ doesn't do what the DR requests.  But the current DR wording talks
about not having the value member, which is something GB 20 doesn't require any
more.

[Bug c++/78940] New: [missed optimization] Useless guard variable in thread_local defaulted constructor

[a...@cloudius-systems.com]

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

Bug ID: 78940
   Summary: [missed optimization] Useless guard variable in
thread_local defaulted constructor
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

If I write

extern thread_local std::atomic foo;

gcc will emit guard variables everywhere to ensure it is properly constructed
before use.  The workaround is to wrap foo in an inline function, so the
compiler can see its definition.  That doesn't work when the constructor is
defaulted:

 begin example 

// following libstdc++ std::atomic
template 
struct my_atomic {
  T n;
  my_atomic() = default;
  explicit constexpr my_atomic(T n) : n(n) {}
  T load() const { return n; }
};

inline
my_atomic&
a1() {
  static thread_local my_atomic v;
  return v;
}

inline
my_atomic&
a2() {
  static thread_local my_atomic v{0};
  return v;
}

int foo() {
  return a1().load() + a2().load();
}


 end example //


This compiles to

 :
   0:   64 80 3c 25 00 00 00cmpb   $0x0,%fs:0x0
   7:   00 00 
4: R_X86_64_TPOFF32 guard variable for a1()::v
   9:   75 09   jne14 
   b:   64 c6 04 25 00 00 00movb   $0x1,%fs:0x0
  12:   00 01 
f: R_X86_64_TPOFF32 guard variable for a1()::v
  14:   64 8b 04 25 00 00 00mov%fs:0x0,%eax
  1b:   00 
18: R_X86_64_TPOFF32a2()::v
  1c:   64 03 04 25 00 00 00add%fs:0x0,%eax
  23:   00 
20: R_X86_64_TPOFF32a1()::v
  24:   c3  retq  


The test for "guard variable for a1()::v" is clearly useless, since no
initialization of a1()::v takes place.  gcc correctly omits the guard variable
for a2()::v.

[Bug c++/78939] New: interferes with structured binding from struct

[gccbugbjorn at fahller dot se]

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

Bug ID: 78939
   Summary:  interferes with structured binding from struct
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugbjorn at fahller dot se
  Target Milestone: ---

Created attachment 40423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40423=edit
preprocessed source

Using a home build from rvn rev 243954, I get the following error from the
attached program.

bjorn@pteranodon /tmp $ LANG=C /opt/gcc-trunk/bin/g++ -std=c++1z t.cpp -v
-save-temps
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/gcc-trunk/configure --prefix=/opt/gcc-trunk
--with-languages=c,cpp : (reconfigured) ../src/gcc-trunk/configure
--prefix=/opt/gcc-trunk --with-languages=c,cpp : (reconfigured)
../src/gcc-trunk/configure --prefix=/opt/gcc-trunk --with-languages=c,cpp
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion :
(reconfigured) ../src/gcc-trunk/configure --prefix=/opt/gcc-trunk
--with-languages=c,cpp --enable-languages=c,c++,fortran,lto,objc --no-create
--no-recursion : (reconfigured) ../src/gcc-trunk/configure
--prefix=/opt/gcc-trunk --with-languages=c,cpp
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion :
(reconfigured) ../src/gcc-trunk/configure --prefix=/opt/gcc-trunk
--with-languages=c,cpp --enable-languages=c,c++,fortran,lto,objc --no-create
--no-recursion
Thread model: posix
gcc version 7.0.0 20161228 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-std=c++1z' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /opt/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus -E -quiet -v
-D_GNU_SOURCE t.cpp -mtune=generic -march=x86-64 -std=c++1z -fpch-preprocess -o
t.ii
ignoring nonexistent directory
"/opt/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../include/c++/7.0.0

/opt/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../include/c++/7.0.0/x86_64-pc-linux-gnu

/opt/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/7.0.0/../../../../include/c++/7.0.0/backward
 /opt/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include
 /usr/local/include
 /opt/gcc-trunk/include
 /opt/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/7.0.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++1z' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /opt/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1plus -fpreprocessed
t.ii -quiet -dumpbase t.cpp -mtune=generic -march=x86-64 -auxbase t -std=c++1z
-version -o t.s
GNU C++14 (GCC) version 7.0.0 20161228 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.0 20161228 (experimental), GMP version
6.1.0, MPFR version 3.1.3-p4, MPC version 1.0.2, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++14 (GCC) version 7.0.0 20161228 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.0 20161228 (experimental), GMP version
6.1.0, MPFR version 3.1.3-p4, MPC version 1.0.2, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 5b476c9dfff0e6f026bb8151315d0c94
t.cpp: In function 'int main()':
t.cpp:9:9: error: 'std::tuple_size::value' is not an integral constant
expression
   auto& [p] = s;


If  is not included, it compiles. It also compiles if the decomposition
declaration is changed from reference to value - "auto [p] = s;"

[Bug target/78938] [7 Regression] ICE in expand_vec_cond_expr, at optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-28
 CC||alan.hayward at arm dot com,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug fortran/78935] [7 Regression] ICE on allocating derived type coarray with allocatable components

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.5, 4.9.4, 5.4.0, 6.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2016-12-28
 CC||marxin at gcc dot gnu.org,
   ||vehre at gmx dot de
 Ever confirmed|0   |1
Summary|ICE on allocating derived   |[7 Regression] ICE on
   |type coarray with   |allocating derived type
   |allocatable components  |coarray with allocatable
   ||components
   Target Milestone|--- |7.0
  Known to fail||4.7.4, 7.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r243021. In 4.7.x times, it used to ICE too.

[Bug target/78938] New: [7 Regression] ICE in expand_vec_cond_expr, at optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1

[asolokha at gmx dot com]

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

Bug ID: 78938
   Summary: [7 Regression] ICE in expand_vec_cond_expr, at
optabs.c:5636 w/ -mavx512bw -ftree-loop-vectorize -O1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-7.0.0-alpha20161225 snapshot ICEs when compiling the following snippet w/
-mavx512bw -ftree-loop-vectorize -O1 (-O2, -O3, -Ofast):

short int y5;

void
ym (char c5)
{
  int sg = 1;

  for (;;)
{
  int *ol = (int *)

  if (sg != 0)
*ol = 0;
  while (c5 < 1)
{
  int u9 = *ol != y5;
  int ie = c5 != 0;

  sg = (u9 == ie) ? 2 : 0;
  ++c5;
}
}
}

% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20161225 -mavx512bw -O1
-ftree-loop-vectorize -c jmw6yft1.c
jmw6yft1.c: In function 'ym':
jmw6yft1.c:4:1: internal compiler error: in expand_vec_cond_expr, at
optabs.c:5636
 ym (char c5)
 ^~