[Bug target/82941] Missing vzeroupper with -march=skylake-avx512 -O2

[hjl.tools at gmail dot com]

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

Bug 82942 Summary: Generate vzeroupper with -mavx512f -mno-avx512er -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82942

   What|Removed |Added

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

[Bug target/82942] Generate vzeroupper with -mavx512f -mno-avx512er -O2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #10 from H.J. Lu  ---
Fixed for GCC 8 and on GCC 6/7 branches.

[Bug ipa/82256] [6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
I am going to test the patch against mainline and commit it.  However about
backporting, can you produce some issue with this bug?

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[polyakova.marina69 at gmail dot com]

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

--- Comment #2 from Марина Полякова  ---
No, I can't because pkgutil has only gcc 4 or 5 :-(

[Bug c++/81013] [7/8 Regression] ICE with invalid union in class hierarchy

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org

--- Comment #1 from Will Schmidt  ---
Created attachment 43172
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43172=edit
ira dump

ira dump.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[polyakova.marina69 at gmail dot com]

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

--- Comment #3 from Марина Полякова  ---
(In reply to Richard Biener from comment #1)
> Note GCC 5 is no longer maintained - can you test a newer version?

No, I can't because pkgutil has only gcc 4 or 5 :-(

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #2)
> So, one problem here is that the debug marker for line 33 is moved by sched2
> too early (unnecessarily), before the prologue, before statement frontiers
> introduction we'd break only after the prologue.
> Perhaps we should tweak the scheduler so that it attempts harder not to move
> debug markers before the prologue, unless really necessary?
> 
> And another bug which I'll try to fix is that the .debug_frame generated
> with -fdwarf2-cfi-asm is wrong on the very first insn in the interrupt
> function, for -fno-dwarf2-cfi-asm it is right.  Apparently the interrupt
> attribute functions have CFI with a different initial offset, the CIE with
> -fdwarf2-cfi-asm has initial offset of cfa-8 like normal functions, and
> right after the very first insn in the interrupt function fn, which is a
> push, the offset becomes cfa-24,
> while with -fno-dwarf2-cfi-asm we start with cfa-16 in the CIE and after the
> push get cfa-16.

Is this related to PR 81570?

[Bug libgomp/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Using the patch from PR83920 comment 3 and testing libgomp.oacc-c/c.exp makes
the  libgomp.oacc-c/c.exp failures of this PR go away.

So, this might be a duplicate.

[Bug fortran/83927] New: Type-Bound Procedure on element of Derived Type PARAMETER Array

[adam at aphirst dot karoo.co.uk]

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

Bug ID: 83927
   Summary: Type-Bound Procedure on element of Derived Type
PARAMETER Array
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at aphirst dot karoo.co.uk
  Target Milestone: ---

Created attachment 43173
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43173=edit
short program demonstrating the issue

I've tried to minimise the code sample as much as possible.
https://gist.github.com/aphirst/5028d3a0ec1c15011e2b1181e4f1a7b5

I have some arrays (one a variable, one a PARAMETER) of Type(MyType), and a
bound procedure %MyFunc() on that type.

Calls to that procedure using specific elements of that array, say
v(1)%MyFunc(), fail, complaining:

Error: Can't convert TYPE(mytype) to REAL(4) at (1)

However, if I replace those calls with identical ones to a parameter which is
scalar but otherwise identical (shown in the code in comments), it compiles and
runs just fine.

It strikes me as odd that a single element of an array works differently to a
scalar. The same array syntax DOES work when used on a variable array, and also
on a PARAMETER scalar, so the issue seems to be somehow related to the
combination of PARAMETER and array for the type-bound procedure logic.

I'm aware that there are other issues regarding PARAMETER arrays, including
#59298 which I reported quite a while ago.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298

gcc version 7.2.1 20171224 (GCC), Arch Linux (x86_64)

If there's any further info which would be useful, please don't hesitate to
ask.

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
That latter bug has been introduced with PR79793.

[Bug target/82941] Missing vzeroupper with -march=skylake-avx512 -O2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 8 and GCC 6/7 branches,

[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()

[boris at gcc dot gnu.org]

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

--- Comment #16 from boris at gcc dot gnu.org ---
Author: boris
Date: Thu Jan 18 13:17:37 2018
New Revision: 256847

URL: https://gcc.gnu.org/viewcvs?rev=256847=gcc=rev
Log:
Add ability to remap file names in __FILE__, etc (PR other/70268)

This commit adds the -fmacro-prefix-map option that allows remapping of file
names in __FILE__, __BASE_FILE__, and __builtin_FILE(), similar to how
-fdebug-prefix-map allows to do the same for debug information.

Additionally, it adds -ffile-prefix-map which can be used to specify both
mappings with a single option (and, should we need to add more -f*-prefix-map
options in the future, those as well).

libcpp/ChangeLog:

2018-01-18  Boris Kolpackov  

PR other/70268
* include/cpplib.h (cpp_callbacks::remap_filename): New callback.
* libcpp/macro.c (_cpp_builtin_macro_text): Call remap_filename for
__FILE__ and __BASE_FILE__.


gcc/ChangeLog:

2018-01-18  Boris Kolpackov  

PR other/70268
* common.opt: (-ffile-prefix-map): New option.
* opts.c (common_handle_option): Defer it.
* opts-global.c (handle_common_deferred_options): Handle it.
* debug.h (remap_debug_filename, add_debug_prefix_map): Move to...
* file-prefix-map.h: New file.
(remap_debug_filename, add_debug_prefix_map): ...here.
(add_macro_prefix_map, add_file_prefix_map, remap_macro_filename): New.
* final.c (debug_prefix_map, add_debug_prefix_map
remap_debug_filename): Move to...
* file-prefix-map.c: New file.
(file_prefix_map, add_prefix_map, remap_filename) ...here and rename,
generalize, get rid of alloca(), use strrchr() instead of strchr().
(add_macro_prefix_map, add_debug_prefix_map, add_file_prefix_map):
Implement in terms of add_prefix_map().
(remap_macro_filename, remap_debug_filename): Implement in term of
remap_filename().
* Makefile.in (OBJS, PLUGIN_HEADERS): Add new files.
* builtins.c (fold_builtin_FILE): Call remap_macro_filename().
* dbxout.c: Include file-prefix-map.h.
* varasm.c: Likewise.
* vmsdbgout.c: Likewise.
* xcoffout.c: Likewise.
* dwarf2out.c: Likewise plus omit new options from DW_AT_producer.
* doc/cppopts.texi (-fmacro-prefix-map): Document.
* doc/invoke.texi (-ffile-prefix-map): Document.
(-fdebug-prefix-map): Update description.


gcc/c-family/ChangeLog:

2018-01-18  Boris Kolpackov  

PR other/70268
* c-family/c.opt (-fmacro-prefix-map): New option.
* c-family/c-opts.c (c_common_handle_option): Handle it.
* c-family/c-lex.c (init_c_lex): Set remap_filename cpp callback.
* c-family/c-ppoutput.c (init_pp_output): Likewise.


gcc/testsuite/ChangeLog:

2018-01-18  Boris Kolpackov  

PR other/70268
* c-c++-common/ffile-prefix-map.c: New test.
* c-c++-common/fmacro-prefix-map.c: New test.
* c-c++-common/cpp/ffile-prefix-map.c: New test.
* c-c++-common/cpp/fmacro-prefix-map.c: New test.


Added:
trunk/gcc/file-prefix-map.c
trunk/gcc/file-prefix-map.h   (with props)
trunk/gcc/testsuite/c-c++-common/cpp/ffile-prefix-map.c
trunk/gcc/testsuite/c-c++-common/cpp/fmacro-prefix-map.c
trunk/gcc/testsuite/c-c++-common/ffile-prefix-map.c
trunk/gcc/testsuite/c-c++-common/fmacro-prefix-map.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-lex.c
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c-ppoutput.c
trunk/gcc/c-family/c.opt
trunk/gcc/common.opt
trunk/gcc/dbxout.c
trunk/gcc/debug.h
trunk/gcc/doc/cppopts.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/dwarf2out.c
trunk/gcc/final.c
trunk/gcc/opts-global.c
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c
trunk/gcc/vmsdbgout.c
trunk/gcc/xcoffout.c
trunk/libcpp/ChangeLog
trunk/libcpp/include/cpplib.h
trunk/libcpp/macro.c

Propchange: trunk/gcc/file-prefix-map.h
('svn:eol-style' added)

Propchange: trunk/gcc/file-prefix-map.h
('svn:keywords' added)

[Bug target/83926] New: ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

[willschm at gcc dot gnu.org]

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

Bug ID: 83926
   Summary: ICE during RTL pass: ira, in
elimination_costs_in_insn, at reload1.c:3633
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43171=edit
simplified testcase

Failure seen on Power8 BE, discovered while reworking some tests to disable
gimple-folding.   

/home/willschm/gcc/build/gcc-mainline-baseline/gcc/xgcc
-B/home/willschm/gcc/build/gcc-mainline-baseline/gcc/
/home/willschm/gcc/testme.c  -fno-diagnostics-show-caret
-fdiagnostics-color=never -mcpu=power8 -O0 -ffat-lto-objects -S -m32  -o
testme.s -dap -mno-fold-gimple
gimple folding of rs6000 builtins has been disabled.
during RTL pass: ira
dump file: testme.c.278r.ira
/home/willschm/gcc/testme.c: In function ‘main’:
/home/willschm/gcc/testme.c:19:1: internal compiler error: in
elimination_costs_in_insn, at reload1.c:3633
0x108a05af elimination_costs_in_insn
/home/willschm/gcc/gcc-mainline-baseline/gcc/reload1.c:3630
0x108a8be7 calculate_elim_costs_all_insns()
/home/willschm/gcc/gcc-mainline-baseline/gcc/reload1.c:1607
0x106f79b7 ira_costs()
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira-costs.c:2249
0x106ef2d3 ira_build()
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira-build.c:3421
0x106e30af ira
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira.c:5292
0x106e30af execute
/home/willschm/gcc/gcc-mainline-baseline/gcc/ira.c:5603
Please submit a full bug report,

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, one problem here is that the debug marker for line 33 is moved by sched2
too early (unnecessarily), before the prologue, before statement frontiers
introduction we'd break only after the prologue.
Perhaps we should tweak the scheduler so that it attempts harder not to move
debug markers before the prologue, unless really necessary?

And another bug which I'll try to fix is that the .debug_frame generated with
-fdwarf2-cfi-asm is wrong on the very first insn in the interrupt function, for
-fno-dwarf2-cfi-asm it is right.  Apparently the interrupt attribute functions
have CFI with a different initial offset, the CIE with -fdwarf2-cfi-asm has
initial offset of cfa-8 like normal functions, and right after the very first
insn in the interrupt function fn, which is a push, the offset becomes cfa-24,
while with -fno-dwarf2-cfi-asm we start with cfa-16 in the CIE and after the
push get cfa-16.

[Bug bootstrap/48879] Compilation cannot find file asm/errno.h

[gjl at gcc dot gnu.org]

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

--- Comment #9 from Georg-Johann Lay  ---
Hi, installing linux-libc-dev:i386 resolved this issue for me (linux-libc-dev
was already installed).

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to cesar from comment #0)
> I think there
> might be other PTX JIT bugs lurking here, because the test program still
> works as intended.

I can make it fail on trunk, by changing the workaround to initialize with one
instead of zero:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 86fc13f4fc0..ab03f3b5fe7 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4097,7 +4097,7 @@ nvptx_single (unsigned mask, basic_block from,
basic_block to)
 There is nothing in the PTX spec to suggest that this is wrong, or
 to explain why the extra initialization is needed.  So, we
classify
 it as a JIT bug, and the extra initialization as workaround.  */
- emit_insn_before (gen_movbi (pvar, const0_rtx),
+ emit_insn_before (gen_movbi (pvar, constm1_rtx),
bb_first_real_insn (from));
 #endif
  emit_insn_before (nvptx_gen_vcast (pvar), tail);
...
[ Note that there are no regressions with this patch, so the test-case triggers
something not present in the current trunk test set. ]


Likewise, reversing the if-then-else order in gemm.f90 makes the testcase fail
on trunk without this patch.


So, this has nothing to do with PTX JIT bugs.

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to cesar from comment #0)
> the underlying problem is present
> in og7 and impacts da-1.c). 

That's a failure I did not manage to reproduce. For me, at commit
b4dd21b9a1f9f499c613b55225cad689b7928a7f "Use functional parameters for data
mappings in OpenACC child functions", that test passes, also when using -O3.

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
Worth returning to this issue now that -Wreturn-type is enabled by default for
gcc8.

[Bug lto/83816] [6/7 Regression] lto1: internal compiler error: compressed stream: data error

[olegendo at gcc dot gnu.org]

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

--- Comment #17 from Oleg Endo  ---
(In reply to Richard Biener from comment #15)
> 
> I can reproduce it:
> 

Nice.

(In reply to Richard Biener from comment #16)
> Note your testcase only reproduces on the GCC 6 branch.  It is expected that
> the issue happens because of some exact length of the uncompressed or
> compressed section or maybe even the actual contents...

This particular case, yes.  However, I ran into this originally with GCC 7. 
During app development GCC 7 started to bail out while GCC 6 was working OK. 
So I switched back to GCC 6 and after some more app development, that one
started bailing out and GCC 7 does not on that case.

So I'd assume the issue is present in all versions.


> 
> Do you run into this very often?
> 

No, I can't say often.  But it surely is very annoying.  And when it happens
the only practical fix is to turn off LTO, which has a significant negative
impact on the code size.


> It may be possible to extract a "zlib testcase" ... maybe it is a genuine
> bug in it?  (however unlikely that is...)

Somehow I doubt that.
I'm now adding some logging around the code in lto-compress.c but so far I'm
not getting any useful info out of it.  The decompression fails right at the
first block in the stream.

[Bug c/83925] New: [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[polyakova.marina69 at gmail dot com]

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

Bug ID: 83925
   Summary: [SPARC/Solaris] __int128 aligned(8) as function
argument is passed in wrong register
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: polyakova.marina69 at gmail dot com
  Target Milestone: ---

Created attachment 43170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43170=edit
preprocessed file for PG_ALIGN_128=8

If we define a new type int128a as __int128 __attribute__((aligned(8))), and
you pass it as not the first function argument, its value in the function may
be incorrect. See the output of the test program:

$ gcc -D PG_ALIGN_128=8 -m64 -o int128test2 int128test2.c
$ ./int128test2
basic aritmetic OK
pass int 16 FAILED
pass uint 16 FAILED
pass int 32 FAILED
pass int 64 FAILED
pass int 128 OK

(see its preprocessed file int128test2_8.i as an attachment)

When the alignment is 16, everything is fine:

$ gcc -D PG_ALIGN_128=16 -m64 -o int128test2 int128test2.c
$ ./int128test2
basic aritmetic OK
pass int 16 OK
pass uint 16 OK
pass int 32 OK
pass int 64 OK
pass int 128 OK

As it turns out, Sparc GCC passes function arguments via register ring which is
referenced as %on in the calling code and as %in in function. And somehow it
happens that alignment attribute of typedef affects access to arguments in the
function, but doesn't affect how regiser ring is filled before call.

the system type: sparc-sun-solaris2.10

the options given when GCC was configured/built:
/home/dam/mgar/pkg/gcc5/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-5.5.0/configure
--prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin
--sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share
--sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share
--localstatedir=/var/opt/csw --libdir=/opt/csw/lib
--infodir=/opt/csw/share/info --includedir=/opt/csw/include
--mandir=/opt/csw/share/man --enable-cloog-backend=isl --enable-java-awt=xlib
--enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada
--enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix
--program-suffix=-5.5 --with-cloog=/opt/csw --with-gmp=/opt/csw
--with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw
--with-system-zlib=/opt/csw --with-as=/usr/ccs/bin/as --without-gnu-as

[Bug c++/83875] [feature request] target_clones compatible SIMD capability/length check

[roland at rschulz dot eu]

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

--- Comment #8 from Roland Schulz  ---
I would suggest that:
- inside multi-versioned (target_clones/target) function it depends on the
active target
- inside a constexpr context (function/variable, your examples) or
always_inline function it depends on the caller
- otherwise returns the default target

I assume that this should result in always returning the target being used.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #12 from Eric Botcazou  ---
I can reproduce with a cross-compiler on x86-64/Linux.

[Bug c++/83929] New: implicit conversion of literal class type can not be used as bit-field length

[smw at gcc dot gnu.org]

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

Bug ID: 83929
   Summary: implicit conversion of literal class type can not be
used as bit-field length
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

[expr.const]/3 says "An integral constant expression is an expression of
integral or unscoped enumeration type, implicitly converted to a prvalue, where
the converted expression is a core constant expression. [ Note: Such
expressions
may be used as array bounds (8.3.4, 5.3.4), as bit-field lengths (9.6), as
enumerator initializers if the underlying type is not fixed (7.2), and as
alignments (7.6.2). — end note ]"

[expr.const]/6 says "If an expression of literal class type is used in a
context where an integral constant expression is required, then that expression
is contextually implicitly converted (Clause 4) to an integral or unscoped
enumeration type and the selected conversion function shall be constexpr."

That works on ICC, LLVM, MSVC, and other compilers, but


struct LiteralClassType
{
  constexpr LiteralClassType(int i) : val(i) { }
  constexpr operator int() const { return val; }
private:
  int val;
};

constexpr LiteralClassType field_width(3);

struct StructWithBitfields
{
int f1:field_width;
};

will give the following error under GCC (all versions tested).

14 : :14:16: error: width of bit-field 'f1' has non-integral type
'const LiteralClassType'
 int f1:field_width;
^~~
Compiler returned: 1

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Created attachment 43175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43175=edit
unpreprocessed input

[Bug ipa/82107] [6/7/8 Regression] O2 optimisation on amd64 leads to error

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Jan Hubicka  ---
Hmm, so the problem is not merging two comdat functions, but merging a function
inlined into comdat into call to different comdat.
This would suggest that merging non-comdat into comdat is not a safe thing to
do?

Honza

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

--- Comment #6 from Arnd Bergmann  ---
Created attachment 43177
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43177=edit
Single-file version of aes benchmark

I've managed to condense the 'openssl speed aes-256-cbc' test into a single
file now:

$ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_test.c -o aes_test
$ time ./aes_test
real0m4.499s
user0m4.498s
sys 0m0.000s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_test.c -o aes_test -fno-code-hoisting
$ time ./aes_test
real0m4.135s
user0m4.134s
sys 0m0.000s

The test is hardcoded to do 10 runs of of 8192 bytes, so on my 3.1GHz CPU
that translates cyles:
$ echo $[4999 * 31000  / 81920]
1891 # 18.91 cycles
$ echo $[4135 * 31000  / 81920]
1564 # 15.6 cycles

Similar results with gcc-8.0.0:

$ x86_64-linux-gcc-8.0.0 -Wall -O2 aes_test.c -o aes_test
$ time ./aes_test
real0m4.471s
user0m4.470s
sys 0m0.000s

$ x86_64-linux-gcc-8.0.0 -Wall -O2 aes_test.c -o aes_test -fno-code-hoisting
$ time ./aes_test
real0m4.052s
user0m4.052s
sys 0m0.000s

Hope that helps

[Bug middle-end/61037] array-bounds false positive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
  Known to work||5.1.0, 6.3.0, 7.2.0
  Known to fail||4.9.3

--- Comment #2 from Martin Sebor  ---
It was fixed by r209862 in GCC 4.10.0 (or 5.1.0).

[Bug c++/80956] [7/8 Regression] ICE with abstract class vector

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
namespace std {
template  class initializer_list;
}
template  struct B { B (std::initializer_list); };
struct C { virtual int foo (); };
struct D : C {} d { B { D {} } };

Perhaps related to PR83227?

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> (In reply to Tom de Vries from comment #3)
> > Likewise, reversing the if-then-else order in gemm.f90 makes the testcase
> > fail on trunk without this patch.
> 
> Minimal version:

An even more minimal c version:
...
/* { dg-do run } */

extern void abort (void);

#define n 10

static void __attribute__((noinline)) __attribute__((noclone))
gemm (int beta, int *c)
{
  #pragma acc parallel copy(c[0:(n * n) - 1]) num_gangs(2)
  #pragma acc loop gang
  for (int j = 0; j < n; ++j)
if (beta != 1)
  {
#pragma acc loop vector
for (int i = 0; i < n; ++i)
  c[i + (j * n)] = 0;
  }
}

int
main (void)
{
  int c[n * n];
  c[0] = 1;
  gemm (0.0, c);
  if (c[0] != 0)
abort ();
}
...

Passes at O0, fails at O2.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Rainer Orth  ---
The failure still happens indeed, but only at -O0, -O and -O2 are fine.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[tgl at sss dot pgh.pa.us]

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

Tom Lane  changed:

   What|Removed |Added

 CC||tgl at sss dot pgh.pa.us

--- Comment #8 from Tom Lane  ---
(In reply to Eric Botcazou from comment #7)
> 128-bit types requite 128-bit alignment on SPARC64 so we cannot support that.

Fair enough, but wouldn't it be a good idea to throw an error for the alignment
atttribute, rather than silently generating incorrect code?

[Bug target/83930] New: [7/8 Regression] ICE: RTL check: expected code 'const_int', have 'mem' in simplify_binary_operation_1, at simplify-rtx.c:3302

[zsojka at seznam dot cz]

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

Bug ID: 83930
   Summary: [7/8 Regression] ICE: RTL check: expected code
'const_int', have 'mem' in
simplify_binary_operation_1, at simplify-rtx.c:3302
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 43179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43179=edit
reduced testcase

RTL checking might be needed to reproduce this.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og -fno-tree-ccp -mavx512f testcase.c 
testcase.c:10:1: warning: always_inline function might not be inlinable
[-Wattributes]
 foo (void)
 ^~~
during RTL pass: combine
testcase.c: In function 'foo':
testcase.c:13:1: internal compiler error: RTL check: expected code 'const_int',
have 'mem' in simplify_binary_operation_1, at simplify-rtx.c:3414
 }
 ^
0x675dce rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.c:844
0x681a5b simplify_binary_operation_1
/repo/gcc-trunk/gcc/simplify-rtx.c:3414
0xdaf9e5 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/simplify-rtx.c:2171
0x166457f combine_simplify_rtx
/repo/gcc-trunk/gcc/combine.c:5682
0x1669ec7 subst
/repo/gcc-trunk/gcc/combine.c:5604
0x1669bed subst
/repo/gcc-trunk/gcc/combine.c:5542
0x1669807 subst
/repo/gcc-trunk/gcc/combine.c:5471
0x166be6e try_combine
/repo/gcc-trunk/gcc/combine.c:3354
0x1675334 combine_instructions
/repo/gcc-trunk/gcc/combine.c:1299
0x1675334 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:14856
0x1675334 execute
/repo/gcc-trunk/gcc/combine.c:14901
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-256801-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-256801-checking-yes-rtl-df-extra-amd64
Thread model: posix
gcc version 8.0.1 20180117 (experimental) (GCC)

[Bug middle-end/81443] [7/8 regression] build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
   Target Milestone|--- |7.3
Summary|gcc-7.1.0/MIPS N32: |[7/8 regression]
   |build/genrecog.o: virtual   |build/genrecog.o: virtual
   |memory exhausted: Cannot|memory exhausted: Cannot
   |allocate memory |allocate memory

--- Comment #13 from Eric Botcazou  ---
It's an unbounded recursion during combining between cached_num_sign_bit_copies
and num_sign_bit_copies1.

[Bug c++/81013] [7/8 Regression] ICE with invalid union in class hierarchy

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jan 18 17:11:43 2018
New Revision: 256856

URL: https://gcc.gnu.org/viewcvs?rev=256856=gcc=rev
Log:
/cp
2018-01-18  Paolo Carlini  

PR c++/81013
* decl.c (xref_basetypes): Early return upon error about derived
union.

/testsuite
2018-01-18  Paolo Carlini  

PR c++/81013
* g++.dg/inherit/union3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/inherit/union3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83928] New: implicit conversion of literal class type to unscoped enumeration can not be used as array size

[smw at gcc dot gnu.org]

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

Bug ID: 83928
   Summary: implicit conversion of literal class type to unscoped
enumeration can not be used as array size
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

[expr.const]/6 says "If an expression of literal class type is used in a
context where an integral constant expression is required, then that expression
is contextually implicitly converted (Clause 4) to an integral or unscoped
enumeration type and the selected conversion function shall be constexpr."

That works great, except when trying to use that constexpr value in an array
declaration.

A code example speaks louder than tortured English can scream.


  // Case 1: literal class type with implicit coversion to integral expression
  struct LiteralClassTypeInt
  {
constexpr LiteralClassTypeInt(int i) : val(i) { }
constexpr operator int() const { return val; }
  private:
int val;
  };

  template struct X { };

  constexpr LiteralClassTypeInt lct_int = 42;
  X x_int;   // OK: implicit conversion to integral expression
  int int_index[lct_int]; // OK: implicitly converted to integral expression

  // Case 2: Unscoped enumeration
  enum E { three = 3 };
  int eee[three]; // OK: unscoped enumeration is allowed here

  // Case 3: literal class type with implicit conversion to unscoped enum
  struct LiteralClassTypeEnum
  {
constexpr LiteralClassTypeEnum(E e): val(e) { }
constexpr operator E() const { return val; }
  private:
E val;
  };

  constexpr LiteralClassTypeEnum lct_enum(three);
  X x_enum;   // OK!
  int enum_index[lct_enum]; // buggerit

All of ICC, LLVM, and MSVC accept the above code as-is.  GCC (all versions
tested up to and including 8.0.1 20120117 (experimental)) give the following
error.

32 : :32:24: error: size of array 'enum_index' has non-integral type
'const LiteralClassTypeEnum'
 int enum_index[lct_enum]; // buggerit
^
Compiler returned: 1

[Bug c++/83928] implicit conversion of literal class type to unscoped enumeration can not be used as array size

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 Ever confirmed|0   |1

[Bug ipa/83619] [8 Regression] ICE in inliner: caller edge count does not match BB count

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Thu Jan 18 15:57:48 2018
New Revision: 256850

URL: https://gcc.gnu.org/viewcvs?rev=256850=gcc=rev
Log:

PR ipa/83619
* g++.dg/torture/pr83619.C: New testcase.
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Update edge
frequencies.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr83619.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
128-bit types requite 128-bit alignment on SPARC64 so we cannot support that.

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
(In reply to Tom de Vries from comment #3)
> Likewise, reversing the if-then-else order in gemm.f90 makes the testcase
> fail on trunk without this patch.

Minimal version:
...
! { dg-do run } 

subroutine gemm (BETA, C)
  real ::  C(100,100)
  integer :: i, j, l
  real, parameter :: one = 1.0
  real :: beta

  !$acc parallel copy(c(1:100,1:100)) num_gangs(2)  
  !$acc loop gang   
  do j = 1, 100
 if (beta /= one) then
!$acc loop vector   
do i = 1, 100
   C(i,j) = 0.0
end do
 end if
  end do
  !$acc end parallel
end subroutine gemm

program test_gemm
  real :: c(100,100), beta
  beta = 0.0
  c(:,:) = 1.0
  call gemm (beta, c)
  if (c(1,1) /= 0.0) call abort ()
end program test_gemm
...

Passes at O0, fails at O1 and higher.

[Bug target/82964] gfortran.dg/class_array_1.f03 regression since r254388

[wilco at gcc dot gnu.org]

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

--- Comment #5 from Wilco  ---
Author: wilco
Date: Thu Jan 18 16:37:44 2018
New Revision: 256854

URL: https://gcc.gnu.org/viewcvs?rev=256854=gcc=rev
Log:
[AArch64] Fix fp16 test failures after PR82964 fix

This fixes test failures in gcc.target/aarch64/f16_mov_immediate_*.c
after fixing PR82964.  The check for a scalar floating point constant
didn't include 16-bit floating point modes, so use GET_MODE_CLASS
instead.

gcc/
PR target/82964
* config/aarch64/aarch64.c (aarch64_legitimate_constant_p):
Use GET_MODE_CLASS for scalar floating point.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug debug/83728] [8 regression] FAIL: gcc.dg/guality/pr68037-1.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Apparently the bug is in there even with -fno-dwarf2-cfi-asm, in
short, in both cases there is just one set of initial cfi insns in the CIE(s),
and furthermore GAS has it hardcoded when using .cfi_startproc.  So, if some
function needs a different initial offset, it needs to emit a CFI insn for that
at the start of the function.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Rainer, can you please test current trunk?  Thanks.

[Bug ipa/83619] [8 Regression] ICE in inliner: caller edge count does not match BB count

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
Fixed.

[Bug ipa/82256] [6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug ipa/82256] [6/7/8 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Author: hubicka
Date: Thu Jan 18 16:26:54 2018
New Revision: 256853

URL: https://gcc.gnu.org/viewcvs?rev=256853=gcc=rev
Log:

PR ipa/82256
patch by PaX Team
* cgraphclones.c (cgraph_node::create_version_clone_with_body):
Fix call of call_cgraph_insertion_hooks.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphclones.c

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

  Attachment #43177|0   |1
is obsolete||

--- Comment #7 from Arnd Bergmann  ---
Created attachment 43178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43178=edit
Single-file version of aes benchmark (shorter)

I decided to strip the test case a bit more down by removing the decryption
side that was unused, and checked that nothing else has changed.

[Bug c++/81013] [7 Regression] ICE with invalid union in class hierarchy

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE with   |[7 Regression] ICE with
   |invalid union in class  |invalid union in class
   |hierarchy   |hierarchy

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

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Given the issues we had on ARM, AArch64 (see exempli gratia PR65956 and
associated discussions), et cetera with overaligned/underaligned scalars, I
think the right thing is not to consider alignment for the argument passing and
return value passing decisions at least for scalars.  One can always call a
function with a scalar argument expecting some alignment and callee expecting
different etc.
So, any reason why e.g. in this case the __int128_t arguments shouldn't be
passed always the same, e.g. like normally aligned __int128_t?

[Bug c++/83929] implicit conversion of literal class type can not be used as bit-field length

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Also valid (see also PR 83928)

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #5 from Wilco  ---
Note there are other optimizations which can block a tailcall, for example:

void *f (void *p) { return __builtin_strchr (p, 0); }

f:
stp x19, x30, [sp, -16]!
mov x19, x0
bl  strlen
add x0, x19, x0
ldp x19, x30, [sp], 16
ret

f:
pushq   %rbx
movq%rdi, %rbx
callstrlen
addq%rbx, %rax
popq%rbx
ret


So the question is whether a tailcall is ever better than using a faster
library call.

[Bug c++/83931] New: Add support for -nostdlib++

[thomasanderson at google dot com]

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

Bug ID: 83931
   Summary: Add support for -nostdlib++
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomasanderson at google dot com
  Target Milestone: ---

Projects that want to link their own c++ standard library must currently pass
-nostdlib or -nodefaultlibs.  This means projects must add back -lm, -lc and so
on.  -nostdlib++ should be added (analogous to -nostdlib) for this use case.

LLVM added this feature in r308997 (https://reviews.llvm.org/rL308997), so gcc
should do the same.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

--- Comment #7 from Wilco  ---
(In reply to H.J. Lu from comment #6)
> (In reply to Wilco from comment #5)
> > Note there are other optimizations which can block a tailcall, for example:
> > 
> > void *f (void *p) { return __builtin_strchr (p, 0); }
> 
> This is irrelevant since this refers to mempcpy only, nothing else.

No it is relevant as strchr is used far more often than mempcpy. There are
likely other cases too. So if we want to add a mechanism to prefer tailcalls,
it would need to be a generic one rather than something hacked just for one
function.

[Bug fortran/83927] Type-Bound Procedure on element of Derived Type PARAMETER Array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-18
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0). Why do you think it is not a duplicate of
pr59298?

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Aldy Hernandez  ---
I ran the testcase in comment #7 and can confirm that there is a 5.24%
performance regression from 6.3.1 to 7.2.1, and a 2.88% regression from 6.3.1
to 8.0.

I ran the test on my unloaded workstation, which is a:

model name  : Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz

Average user time of 15 runs: a.out.6.3.1 is 3.82
Average user time of 15 runs: a.out.7.2.1 is 4.02
Average user time of 15 runs: a.out.8.0 is 3.931333

I can also confirm that everything runs much faster with -fno-code-hoisting,
but that may or may not be related:

Average user time of 15 runs: a.out.8.0 -fno-code-hoisting is 3.734667

These regressions seem pretty small, though.

Perhaps we could find what regressed from 6.3.1 to 7.2.1, and maybe that's
still causing problems in 8 (even though other factors may be causing it to be
faster in 8).

Confirmed.

[Bug c++/83931] Add support for -nostdlib++

[thomasanderson at google dot com]

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

--- Comment #2 from Thomas Anderson  ---
From the LLVM CL description:

Alternatively, they could use clang instead
of clang++, but that already disables implicit addition of -lm on some
toolchains.

Not sure if this is the same for gcc though.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Wilco from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > That just means r240568 caused another regression.
> > Again, on various targets strchr is efficient, just on a few ones it is not
> > and the change was unfortunately done generically.
> 
> On practically all targets, including x64, strchr is not as efficient as
> strlen.

Do you have data to show that?

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
No matter what, I don't see how you could use much common infrastructure here.
Say if the tailcall pass sees strlen (something) + something being returned, it
could turn that into strchr (something, 0), because both functions are
standard.
We can't do that if we see memcpy (x, y, len) + len, because mempcpy is not a C
standard function, while memcpy is, so if the information that mempcpy was
originally used is lost, then it is completely lost.

[Bug c++/83931] Add support for -nostdlib++

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Use gcc for linking instead of g++ seems like the correct way.

[Bug fortran/83864] ICE in gfc_apply_init, at fortran/expr.c:4271

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jan 18 18:27:22 2018
New Revision: 256857

URL: https://gcc.gnu.org/viewcvs?rev=256857=gcc=rev
Log:
2018-01-18  Harald Anlauf  

Backport from mainline
PR fortran/83864
* expr.c (gfc_apply_init): Do not dereference NULL pointer.

2018-01-18  Harald Anlauf  

Backport from mainline
PR fortran/83864
* gfortran.dg/pr83864.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr83864.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/83920] [nvptx] bad predicate reset

[cesar at gcc dot gnu.org]

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

--- Comment #8 from cesar at gcc dot gnu.org ---
I tweaked your proposed fix as follows:

diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 55c7e3cbf90..24625cd303f 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4104,8 +4104,11 @@ nvptx_single (unsigned mask, basic_block from,
basic_block to)
mov.u32 %x,%tid.x;
setp.ne.u32 %rnotvzero,%x,0;
 }
+  reg.pred %rcond2; // Scratch copy of the original rcond.

+  mov.pred %rcond2, %rcond;
 @%rnotvzero bra Lskip;
+  mov.pred %rcond, %rcond2
 setp.. %rcond,op1,op2;
 Lskip:
 selp.u32 %rcondu32,1,0,%rcond;
@@ -4126,8 +4129,11 @@ nvptx_single (unsigned mask, basic_block from,
basic_block to)
 There is nothing in the PTX spec to suggest that this is wrong, or
 to explain why the extra initialization is needed.  So, we
classify
 it as a JIT bug, and the extra initialization as workaround.  */
- emit_insn_before (gen_movbi (pvar, const0_rtx),
-   bb_first_real_insn (from));
+   rtx_insn *from_insn = bb_first_real_insn (from);
+   rtx ptmp = gen_reg_rtx (GET_MODE (pvar));
+   emit_insn_before (gen_rtx_SET (ptmp, pvar), from_insn);
+   emit_insn_before (gen_movbi (pvar, const0_rtx), from_insn);
+   emit_insn_before (gen_rtx_SET (pvar, ptmp), tail);
 #endif
  emit_insn_before (nvptx_gen_vcast (pvar), tail);
}

This generates the following assembly code for gemm.f90:

$L34:
$L11:
mov.pred%r413, %r314;
setp.eq.u32 %r314, 1, 0;
@%r402  bra $L33;
$L33:
mov.pred%r314, %r413;
selp.u32%r414, 1, 0, %r314;
shfl.idx.b32%r414, %r414, 0, 31;
setp.ne.u32 %r314, %r414, 0;
@!%r314 bra.uni $L22;
bra $L3;
$L12:

I'm not sure what's going on here, because this patch causes illegal memory
access errors in lsdalton. Any thoughts?

Maybe a more involved workaround would be to leave r314 alone, and use the
scratch %r413 register as the predicate. But, then wouldn't the prevent the PRE
code hoisting optimization which moved the computation for %r314 outside of the
loop in the first place?

Is this original PTX JIT bug still present in the current Nvidia drivers? You
mentioned that this problem first appeared in 381.22. I wonder if it has been
resolved in 387.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

--- Comment #9 from Wilco  ---
(In reply to Jakub Jelinek from comment #8)
> That just means r240568 caused another regression.
> Again, on various targets strchr is efficient, just on a few ones it is not
> and the change was unfortunately done generically.

On practically all targets, including x64, strchr is not as efficient as
strlen.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Wilco from comment #5)
> Note there are other optimizations which can block a tailcall, for example:
> 
> void *f (void *p) { return __builtin_strchr (p, 0); }

This is irrelevant since this refers to mempcpy only, nothing else.

[Bug c++/83932] New: No diagnostic issued for missing default argument in lambda-expression

[smw at gcc dot gnu.org]

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

Bug ID: 83932
   Summary: No diagnostic issued for missing default argument in
lambda-expression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

This code

  void f() {
auto l = [](int i=1, int j) {};
  }

should give me a diagnostic about parameter "j" missing a default argument (or
something).  GCC (all versions tested, requires C++14 mode or later) remains
petulantly silent.

[Bug c/83433] missing signed integer overflow diagnostic for abs(INT_MIN)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||msebor at gcc dot gnu.org
Summary|Should -Wstrict-overflow=2  |missing signed integer
   |produce a diagnostic for|overflow diagnostic for
   |abs(INT_MIN)|abs(INT_MIN)
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
-Woverflow diagnoses a bare negation of INT_MIN and it would be useful to
diagnose the same negation by abs().  The folder folds abs() into the same
expression and it has all the knowledge it needs to diagnose it  With that,
confirmed.

$ cat pr83433.c && gcc -O2 -S -Wall -Wextra -Wstrict-overflow=2
-fdump-tree-optimized=/dev/stdout pr83433.c
#define INT_MIN (-__INT_MAX__ - 1)

int f (void)
{
  return -INT_MIN;
}

int g (void)
{
  return __builtin_abs (INT_MIN);
}
pr83433.c: In function ‘f’:
pr83433.c:5:10: warning: integer overflow in expression ‘-2147483648’ of type
‘int’ results in ‘-2147483648’ [-Woverflow]
   return -INT_MIN;
  ^

;; Function f (f, funcdef_no=0, decl_uid=1950, cgraph_uid=0, symbol_order=0)

f ()
{
   [local count: 1073741825]:
  return -2147483648;

}



;; Function g (g, funcdef_no=3, decl_uid=1953, cgraph_uid=1, symbol_order=1)

g ()
{
   [local count: 1073741825]:
  return -2147483648;

}

[Bug c++/81167] [8 Regression] ICE on valid C++ code in deferred_printed_type, at cp/error.c:118

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I think it is fine that %H/%I crash on bogus arguments, but we should fix here
the real bug.
+ if (! DECL_CONSTRUCTOR_P (w->fn)
+  && TREE_TYPE (source))
looks just like a workaround.  The main question is what is:
  tree source = source_type (w->convs[0]);
  if (! DECL_CONSTRUCTOR_P (w->fn))
source = TREE_TYPE (source);
code meant to do exactly, I bet it relies on the assumption that this argument
to w->fn must be a POINTER_TYPE_P, but in this case source is neither pointer
nor reference type, because source_type looked through the ck_ref_bind
conversion which had reference to bar type to the next conversion which is
ck_identity with bar type.  So, source already is a RECORD_TYPE rather than a
pointer/reference.

[Bug fortran/31237] [meta-bug] TRANSFER intrinsic

[kargl at gcc dot gnu.org]

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

Bug 83864 Summary: ICE in gfc_apply_init, at fortran/expr.c:4271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83864

   What|Removed |Added

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

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
That just means r240568 caused another regression.
Again, on various targets strchr is efficient, just on a few ones it is not and
the change was unfortunately done generically.

[Bug fortran/83864] ICE in gfc_apply_init, at fortran/expr.c:4271

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |7.3

--- Comment #7 from kargl at gcc dot gnu.org ---
Patch applied to 7-branch and trunk.
Patch does not apply to 6-branch without more effort
than I want to spend.
Thanks for the bug report.

[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

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

--- Comment #10 from Harald Anlauf  ---
Steve,
thanks for committing and the backports to 7 and 6.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Wilco from comment #12)

> > 
> > Do you have data to show that?
> 
> Yes, on x64 I get these timings for a simple function containing just the
> library call:
> 
> size  1024 - 13845 21025 14449 (rawmemchr/memchr/strlen)

On Skylake/x86-64, I got

strlen:

Length 1024, alignment  0:  178.781
Length 1024, alignment  7:  162.625
Length 1024, alignment 10:  161.969

strchr:

Length 1024, alignment in bytes  0: 83.7812
Length 1024, alignment in bytes  6: 82.0938

strchr is 2X faster.  It uses a very different algorithm. I will
check if I can fold strlen into strchr.

[Bug target/83933] New: [8 regression] gcc.target/powerpc/vsx-vector-6-le.c fails starting with r256798

[seurer at gcc dot gnu.org]

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

Bug ID: 83933
   Summary: [8 regression]  gcc.target/powerpc/vsx-vector-6-le.c
fails starting with r256798
   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: ---

Doesn't look like the test case was updated so maybe a problem in the builtin
expansion?

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mvsx -O2
-ffat-lto-objects -S -o vsx-vector-6-le.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c:
In function 'foo':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c:32:
error: expected declaration or statement at end of input
compiler exited with status 1
FAIL: gcc.target/powerpc/vsx-vector-6-le.c (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c:32:
error: expected declaration or statement at end of input

[Bug c++/83806] [6/7/8 Regression] Spurious -Wunused-but-set-parameter with nullptr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||paolo.carlini at oracle dot com

--- Comment #2 from Paolo Carlini  ---
I'm adding in CC Jakub too.

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #9 from Aldy Hernandez  ---
Original regression in 7.x started with the -fcode-hoisting pass in r238242. 
Things started improving with r254948, though that is probably unrelated.

Perhaps Richard can comment.

[Bug c++/80956] [7/8 Regression] ICE with abstract class vector

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #2)
> Reduced testcase:
> namespace std {
> template  class initializer_list;
> }
> template  struct B { B (std::initializer_list); };
> struct C { virtual int foo (); };
> struct D : C {} d { B { D {} } };
> 
> Perhaps related to PR83227?

Note the testcase also ICEs with -std=c++14, but at a different spot from
-std=c++17.

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
Still there at 8-trunk rev.256858, now line

3383  expr = ss->info->expr;

(gdb) print ss
$1 = (gfc_ss *) 0x0

[Bug target/83815] Enhance addressing for long double on PowerPC with -mabi=ieeelongdouble

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Michael Meissner  ---
I did some further research, and I can't find any place in rs6000.c where
TFmode is handled, but IFmode/KFmode are not handled, and there is a test
whether the mode targets IBM extended double or IEEE 128-bit.

I thought there were a few places, but I had previously missed that KF/IF were
also handled nearby.

[Bug target/83933] [8 regression] gcc.target/powerpc/vsx-vector-6-le.c fails starting with r256798

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

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

--- Comment #1 from Carl Love  ---
gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c contains the expected
instruction counts for the test when built for little endian.  The actual code
is in gcc/testsuite/gcc.target/powerpc/vsx-vector-6.h.  The test function foo
was missing the closing "}" resulting in the compile error.

The issue was fixed with commit 256864 by Carl Love on 2018-01-18.

[Bug target/83920] [nvptx] bad predicate reset

[cesar at gcc dot gnu.org]

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

--- Comment #9 from cesar at gcc dot gnu.org ---
I figured out why my patch does work. Here's the assembly code for your C test
case at -O0:

{
.reg.u32%x;
mov.u32 %x, %tid.x;
setp.ne.u32 %r81, %x, 0;
}
@%r81   bra $L11;
mov.u64 %r58, %ar0;
st.u64  [%frame+32], %r58;
mov.u64 %r59, %ar1;
st.u64  [%frame+40], %r59;
ld.u64  %r60, [%frame+40];
cvt.u32.u64 %r26, %r60;
st.u32  [%frame], %r26;
ld.u64  %r61, [%frame+32];
st.u64  [%frame+8], %r61;
mov.u32 %r22, 0;
mov.u32 %r28, 1;
mov.u32 %r29, 1;
$L11:
$L9:
mov.pred%r82, %r62;
setp.eq.u32 %r62, 1, 0;
@%r81   bra $L12;
mov.u32 %r55, %nctaid.x;
mov.u32 %r56, %ctaid.x;
mov.u32 %r48, 9;
add.u32 %r49, %r55, %r48;
div.s32 %r50, %r49, %r55;
mul.lo.u32  %r23, %r56, %r50;
mov.u32 %r57, %nctaid.x;
mov.u32 %r51, 9;
add.u32 %r52, %r57, %r51;
div.s32 %r53, %r52, %r57;
add.u32 %r54, %r23, %r53;
min.s32 %r30, %r54, 10;
setp.ge.s32 %r62, %r23, %r30;
$L12:
mov.pred%r62, %r82;
selp.u32%r83, 1, 0, %r62;
shfl.idx.b32%r83, %r83, 0, 31;
setp.ne.u32 %r62, %r83, 0;
@%r62   bra.uni $L2;
$L4:
mov.pred%r84, %r64;
setp.eq.u32 %r64, 1, 0;
@%r81   bra $L13;

The predicate register in question here is %r62. Notice how the JIT workaround
clobbers %r62 much earlier than it's defined. My patch just copied the register
predicate register before it was clobbered. That's fine, but when it restores
the value of %r62 in L12, r62 gets an uninitialized value.

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[wilco at gcc dot gnu.org]

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

--- Comment #12 from Wilco  ---
(In reply to H.J. Lu from comment #10)
> (In reply to Wilco from comment #9)
> > (In reply to Jakub Jelinek from comment #8)
> > > That just means r240568 caused another regression.
> > > Again, on various targets strchr is efficient, just on a few ones it is 
> > > not
> > > and the change was unfortunately done generically.
> > 
> > On practically all targets, including x64, strchr is not as efficient as
> > strlen.
> 
> Do you have data to show that?

Yes, on x64 I get these timings for a simple function containing just the
library call:

size  1024 - 13845 21025 14449 (rawmemchr/memchr/strlen)

[Bug c++/81167] [8 Regression] ICE on valid C++ code in deferred_printed_type, at cp/error.c:118

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
In gcc/testsuite/ we apparently have just g++.old-deja/g++.benjamin/16077.C
and g++.old-deja/g++.other/overcnv2.C testcases covering those and in both
cases
source is a POINTER_TYPE.
With check-c++-all RUNTESTFLAGS='--target_board=unix/-Wconversion' I managed to
get a few extras:
gcc/testsuite/g++.dg/cpp0x/initlist64.C (nofn) struct Y * vs. struct X
gcc/testsuite/g++.dg/cpp0x/initlist64.C (nofn) struct Z * vs. struct X
gcc/testsuite/g++.dg/cpp1y/context-conv1.C f struct zero_init * vs. int *
gcc/gcc/testsuite/g++.old-deja/g++.benjamin/16077.C foo struct nicaragua * vs.
struct colombia
gcc/testsuite/g++.old-deja/g++.mike/p807.C main struct AX * vs. struct B
gcc/testsuite/g++.old-deja/g++.other/overcnv2.C main struct B * vs. const char
*

[Bug libstdc++/82644] Non-standard hypergeometric special functions defined in strict modes

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Thu Jan 18 20:31:32 2018
New Revision: 256863

URL: https://gcc.gnu.org/viewcvs?rev=256863=gcc=rev
Log:
PR libstdc++/82644 document IS 29124 support

Backport from mainline
2017-10-23  Jonathan Wakely  

* doc/xml/manual/intro.xml: Include new section.
* doc/xml/manual/status_cxxis29124.xml: New section on IS 29124
status.
* doc/html/*: Regenerate.

Added:
branches/gcc-7-branch/libstdc++-v3/doc/xml/manual/status_cxxis29124.xml
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/doc/html/index.html
branches/gcc-7-branch/libstdc++-v3/doc/html/manual/bugs.html
branches/gcc-7-branch/libstdc++-v3/doc/html/manual/index.html
branches/gcc-7-branch/libstdc++-v3/doc/html/manual/intro.html
branches/gcc-7-branch/libstdc++-v3/doc/html/manual/status.html
branches/gcc-7-branch/libstdc++-v3/doc/xml/manual/intro.xml

[Bug fortran/82992] ICE in create_int_parameter_array, at fortran/module.c:6586

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
Obvious fix for the ICE:

Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 256858)
+++ gcc/fortran/module.c(working copy)
@@ -6597,7 +6597,7 @@
   gfc_symbol *sym;

   tmp_symtree = gfc_find_symtree (gfc_current_ns->sym_root, name);
-  if (tmp_symtree != NULL)
+  if (tmp_symtree != NULL && tmp_symtree->n.sym && tmp_symtree->n.sym->module)
 {
   if (strcmp (modname, tmp_symtree->n.sym->module) == 0)
return;

[Bug middle-end/81812] [7/8 Regression] Empty virtual function fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #6 from Paolo Carlini  ---
Looks like this is fixed for 8 and I'd like to updated the bug to reflect that
and possibly add the testcase. Any idea which change fixed it and whether could
be backported to 7?

[Bug target/83920] [nvptx] bad predicate reset

[cesar at gcc dot gnu.org]

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

--- Comment #10 from cesar at gcc dot gnu.org ---
And here is the working code in -O2:

{
.reg.u32%x;
mov.u32 %x, %tid.x;
setp.ne.u32 %r71, %x, 0;
}
@%r71   bra $L13;
mov.u64 %r45, %ar0;
mov.u64 %r46, %ar1;
mov.u32 %r42, %ctaid.x;
shl.b32 %r48, %r42, 2;
add.u32 %r37, %r48, %r42;
mov.u32 %r31, 5;
setp.ne.u64 %r64, %r46, 1;
mov.u32 %r66, 0;
$L13:
$L3:
mov.pred%r74, %r64;
setp.eq.u32 %r64, 1, 0;
@%r71   bra $L12;
$L12:
mov.pred%r64, %r74;
selp.u32%r75, 1, 0, %r64;
shfl.idx.b32%r75, %r75, 0, 31;
setp.ne.u32 %r64, %r75, 0;
@%r64   bra.uni $L2;
$L6:

Notice how gcse's PRE pass hoisted the initialization of %r64 early in the
entry block.

I think we should go with my patch. If the register is live, it shouldn't
require your workaround.

[Bug c++/82461] [7/8 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Jan 18 20:02:06 2018
New Revision: 256860

URL: https://gcc.gnu.org/viewcvs?rev=256860=gcc=rev
Log:
PR c++/82461 - constexpr list-initialized member

* constexpr.c (potential_constant_expression_1): Check
TARGET_EXPR_DIRECT_INIT_P.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-list2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/81167] [8 Regression] ICE on valid C++ code in deferred_printed_type, at cp/error.c:118

[jakub at gcc dot gnu.org]

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

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

Untested fix.  This assumes that the type we want as source is always some
class type, which seems to be the case at least in all the testsuite coverage
we have for this.

[Bug testsuite/83934] New: [8 regression] new test case g++.dg/torture/pr83619.C fails starting with its introduction in r256850

[seurer at gcc dot gnu.org]

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

Bug ID: 83934
   Summary: [8 regression] new test case g++.dg/torture/pr83619.C
fails starting with its introduction in r256850
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -O0
-S -o pr83619.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C: In static
member function 'static void i::j<  >::c(e*)':
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C:25:8:
warning: invalid use of incomplete type 'class e'
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C:8:7: note:
forward declaration of 'class e'
FAIL: g++.dg/torture/pr83619.C   -O0  (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C:25:8:
warning: invalid use of incomplete type 'class e'

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C   
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0  
-O1-S -o pr83619.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -O1
-S -o pr83619.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C: In static
member function 'static void i::j<  >::c(e*)':
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C:25:8:
warning: invalid use of incomplete type 'class e'
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C:8:7: note:
forward declaration of 'class e'
FAIL: g++.dg/torture/pr83619.C   -O1  (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C:25:8:
warning: invalid use of incomplete type 'class e'

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C   
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0  
-O2-S -o pr83619.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/torture/pr83619.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 18 20:30:33 2018
New Revision: 256861

URL: https://gcc.gnu.org/viewcvs?rev=256861=gcc=rev
Log:
PR sanitizer/81715
PR testsuite/83882
* function.h (gimplify_parameters): Add gimple_seq * argument.
* function.c: Include gimple.h and options.h.
(gimplify_parameters): Add cleanup argument, add CLOBBER stmts
for the added local temporaries if needed.
* gimplify.c (gimplify_body): Adjust gimplify_parameters caller,
if there are any parameter cleanups, wrap whole body into a
try/finally with the cleanups.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/function.h
trunk/gcc/gimplify.c

[Bug testsuite/83882] FAIL: g++.dg/opt/pr81715.C -std=gnu++98 (test for excess errors)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 18 20:30:33 2018
New Revision: 256861

URL: https://gcc.gnu.org/viewcvs?rev=256861=gcc=rev
Log:
PR sanitizer/81715
PR testsuite/83882
* function.h (gimplify_parameters): Add gimple_seq * argument.
* function.c: Include gimple.h and options.h.
(gimplify_parameters): Add cleanup argument, add CLOBBER stmts
for the added local temporaries if needed.
* gimplify.c (gimplify_body): Adjust gimplify_parameters caller,
if there are any parameter cleanups, wrap whole body into a
try/finally with the cleanups.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/function.h
trunk/gcc/gimplify.c

[Bug testsuite/83882] FAIL: g++.dg/opt/pr81715.C -std=gnu++98 (test for excess errors)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Should be fixed now.

[Bug c++/82461] [7/8 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Fixed for 8 so far.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[alexey.salmin at gmail dot com]

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

--- Comment #46 from Alexey Salmin  ---
Tested the latest patch, behavior looks very reasonable even in tricky cases.

1) No warning, gcd(12, 8) == 4
struct tuple_t {
char c[12];
__int128_t i;
} __attribute__((packed, aligned(8)));

typedef struct unaligned_int128_t_ {
__int128_t value;
} __attribute__((packed, aligned(4))) unaligned_int128_t;

struct tuple_t p = {0, 1};
unaligned_int128_t *addr = (unaligned_int128_t *)();

2) Gives a warning, gcd(10, 8) < 4
struct tuple_t {
char c[10];
__int128_t i;
} __attribute__((packed, aligned(8)));

typedef struct unaligned_int128_t_ {
__int128_t value;
} __attribute__((packed, aligned(4))) unaligned_int128_t;

struct tuple_t p = {0, 1};
unaligned_int128_t *addr = (unaligned_int128_t *)();

[Bug testsuite/83934] [8 regression] new test case g++.dg/torture/pr83619.C fails starting with its introduction in r256850

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-18
 CC||ro at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Rainer Orth  ---
Also on i386-pc-solaris2.11, sparc-sun-solaris2.11, i586-unknown-freebsd10.4,
i686-pc-linux-gnu,
x86_64-pc-linux-gnu (probably everywhere).

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

--- Comment #14 from acsawdey at gcc dot gnu.org ---
I've narrowed this down a bit --- copying libcommon-target.a from the working
build on willow2 makes the build on genoa work, even with -O2. So it is
something in there. I'll continue narrowing that down to figure out tomorrow.

[Bug c++/83937] New: [REGRESSION] C++17 binds braced init of a type T to default arg of a ctor instead of using T's own default ctor

[raphaelsc at scylladb dot com]

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

Bug ID: 83937
   Summary: [REGRESSION] C++17 binds braced init of a type T to
default arg of a ctor instead of using T's own default
ctor
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raphaelsc at scylladb dot com
  Target Milestone: ---

Created attachment 43181
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43181=edit
default_ctor_regression_for_default_value_ctor_argument

Unlike C++14, C++17 isn't using default ctor of a type T when it's braced
initialized, i.e. {}, and used as argument for a ctor of a type that has a
default argument for the same type T.

The following code

struct S
{
S(int i = 42);
};

void f()
{
S( {} );
} 

produces this assembly to g++ --std=c++14

  lea rax, [rbp-1]
  mov esi, 0
  mov rdi, rax
  call S::S(int)

and this one for g++ --std=c++17

  lea rax, [rbp-1]
  mov esi, 42
  mov rdi, rax
  call S::S(int)


that also works for any user-defined type, such as

struct T
{
T(int i = 10);
};

struct S
{
S(T i = T(42));
};

void f()
{
S( {} );
}

S's ctor is called with 42 instead of 10 for C++17.

but C++14 judges it ambiguous and doesn't even compile it.

Note that if I change S( {} ) to S( T{} ), it works as expected.


The code attached which resembles the first code shown produces the following
output:
$ g++ --std=c++17 ub.cc -o ub; ./ub
42
$ g++ --std=c++14 ub.cc -o ub; ./ub
0

Please find code for output above attached.

[Bug tree-optimization/83510] [8 Regression] Recent changes for -Warray-bounds trigger false positive

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01693.html

[Bug target/83920] [nvptx] bad predicate reset

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
This ( PR83589 - "[nvptx] mode-transitions.c and private-variables.{c,f90}
execution FAILs at GOMP_NVPTX_JIT=-O0" ) may be a duplicate.

[Bug target/83925] [SPARC/Solaris] __int128 aligned(8) as function argument is passed in wrong register

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ABI
 Target||sparc-solaris
  Component|c   |target

--- Comment #1 from Richard Biener  ---
Note GCC 5 is no longer maintained - can you test a newer version?

[Bug target/81959] PowerPC __float128 optimization fails with integer PRE_INC addresses

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in trunk and on the GCC 7 branch.  It was not an issue in the GCC 6
branch.