[Bug libstdc++/83938] Speed up inplace_merge() algorithm & fix inefficient logic

[john.chang at samba dot tv]

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

WeiChungChang  changed:

   What|Removed |Added

URL||https://drive.google.com/op
   ||en?id=1MTigPFnqy7tscE-eCPiw
   ||9Y8_1blDTL6O

--- Comment #2 from WeiChungChang  ---
Or access the report via this link

https://drive.google.com/open?id=1MTigPFnqy7tscE-eCPiw9Y8_1blDTL6O

[Bug libstdc++/83938] Speed up inplace_merge() algorithm & fix inefficient logic

[john.chang at samba dot tv]

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

--- Comment #1 from WeiChungChang  ---
Created attachment 43182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43182&action=edit
report

report in detail

[Bug libstdc++/83938] New: Speed up inplace_merge() algorithm & fix inefficient logic

[john.chang at samba dot tv]

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

Bug ID: 83938
   Summary: Speed up inplace_merge() algorithm & fix inefficient
logic
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.chang at samba dot tv
  Target Milestone: ---

In this report we review the inplace merge algorithm of current GCC libstdc++.

We survey a potential issue about downgrade of performance when merging two
sorted vectors given limited buffer.

The experiment result shows at most a 49.18% gain in execution time or reduce
50 % in memory usage.

Please estimate to enhance it.

Attached is the report in detail.

Thanks.

[Bug translation/80188] calls.c: reason argument to maybe_complain_about_tail_call must be marked for translation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Eric Gallager  ---
(In reply to nik from comment #5)
> On 2018-01-17 02:15 AM, egallager at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188
> > 
> > --- Comment #4 from Eric Gallager  ---
> > (In reply to nik from comment #3)
> >> Created attachment 42372 [details]
> >> Proposed Fix Send to the GCC-Patches List
> > 
> > Link to the mailing list archives showing where/when this was sent to
> > gcc-patches?
> > 
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00420.html
> 
> Is a link to the email if you want one.
> 
> Sorry for the late follow up,
> 
> Nick

Thanks, adding the "patch" keyword

[Bug preprocessor/47047] Support for path translation in __FILE__

[boris at kolpackov dot net]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #7 from Boris Kolpackov  ---
I believe this is a duplicate of #70268 that has been fixed.

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

[Bug translation/80188] calls.c: reason argument to maybe_complain_about_tail_call must be marked for translation

[xerofoify at gmail dot com]

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

--- Comment #5 from nik  ---
On 2018-01-17 02:15 AM, egallager at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188
> 
> --- Comment #4 from Eric Gallager  ---
> (In reply to nik from comment #3)
>> Created attachment 42372 [details]
>> Proposed Fix Send to the GCC-Patches List
> 
> Link to the mailing list archives showing where/when this was sent to
> gcc-patches?
> 
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00420.html

Is a link to the email if you want one.

Sorry for the late follow up,

Nick

[Bug c++/83937] [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

--- Comment #1 from Raphael S. Carvalho  ---
another interesting example which shows the bug: https://godbolt.org/g/nMdPBF

[Bug fortran/83927] 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

--- Comment #2 from Adam Hirst  ---
I don't think this is a duplicate of pr59298 because, unlike pr59298, this
doesn't cause an ICE.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

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

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 18 23:39:26 2018
New Revision: 256867

URL: https://gcc.gnu.org/viewcvs?rev=256867&root=gcc&view=rev
Log:
PR ipa/83619
PR testsuite/83934
* g++.dg/torture/pr83619.C (e): Define before first use instead of
forward declaration.

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

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

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 18 23:39:26 2018
New Revision: 256867

URL: https://gcc.gnu.org/viewcvs?rev=256867&root=gcc&view=rev
Log:
PR ipa/83619
PR testsuite/83934
* g++.dg/torture/pr83619.C (e): Define before first use instead of
forward declaration.

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

[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 c++/83936] [feature request] Allow constexpr char* as target argument

[roland at rschulz dot eu]

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

--- Comment #2 from Roland Schulz  ---
Do you mean for the target attribute or for all attributes in general? The
following example suggests that for the alloc_align attribute it works to have
the argument depend on a template argument.

template
[[gnu::alloc_align(xx)]]
void *a(int align);

void test(int align)
{
a<1>(align);
a<2>(align);
}

$ g++ test_attr.cc -Wall -Wextra -c
test_attr.cc: In substitution of 'template void* a(int) [with int xx =
2]':
test_attr.cc:8:15:   required from here
test_attr.cc:3:7: warning: alloc_align parameter outside range [-Wattributes]
 void *a(int align);

[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&action=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 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 fortran/80768] NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #5)
> (In reply to Dominique d'Humieres from comment #4)
> > The ICE can be seen with genuine gfortran with adding the option -std=f2008
> > from gcc5 up to trunk (8.0).
> 
> Is that still true?
> 
> I do not get the ICE with 8.0 rev. 256858 on i686-pc-linux-gnu,
> but need -fcoarray=single -std=f2008ts / -std=f2018 to compile.

This was fixed by


r250734 | jakub | 2017-07-31 02:32:02 -0700 (Mon, 31 Jul 2017) | 2 lines

* check.c (gfc_check_num_images): Fix a pasto.

It is still present in 7-branch and 6-branch,

[Bug c++/83936] [feature request] Allow constexpr char* as target argument

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I doubt this can be implemented as attributes are handled in the preprocessing
stage.

Kinda like allowing _Pargma to support constexpr would be weird too.

[Bug c++/83936] New: [feature request] Allow constexpr char* as target argument

[roland at rschulz dot eu]

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

Bug ID: 83936
   Summary: [feature request] Allow constexpr char* as target
argument
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland at rschulz dot eu
  Target Milestone: ---

It would be very useful to be able to specify a "constexpr const char*const"
string as an argument to the target attribute. This would allow to specify the
target argument for templates where the target should depend on some template
argument. Example:

struct AVX
{
static constexpr const char*const target = "avx"; 
};

template
[[gnu::target(T::target)]]
void test() {}

void f() {
test();
}

[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)

[roland at rschulz dot eu]

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

Roland Schulz  changed:

   What|Removed |Added

 CC||roland at rschulz dot eu

--- Comment #25 from Roland Schulz  ---
I believe this can be closed because this has been implemented as target_clones
attribute.

[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 fortran/78797] It is time perhaps to implement -std=f2015

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #8 from Harald Anlauf  ---
As -std=f2018 will be available in 8.0 and replaces -std=f2015,
shouldn't this bug be closed?

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[hjl.tools at gmail dot com]

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

Bug 81570 Summary: create_pseudo_cfg assumes that INCOMING_FRAME_SP_OFFSET is a 
constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81570

   What|Removed |Added

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

[Bug fortran/80768] NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #5 from Harald Anlauf  ---
(In reply to Dominique d'Humieres from comment #4)
> The ICE can be seen with genuine gfortran with adding the option -std=f2008
> from gcc5 up to trunk (8.0).

Is that still true?

I do not get the ICE with 8.0 rev. 256858 on i686-pc-linux-gnu,
but need -fcoarray=single -std=f2008ts / -std=f2018 to compile.

[Bug debug/81570] create_pseudo_cfg assumes that INCOMING_FRAME_SP_OFFSET is a constant

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Dup.

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

[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 #6 from H.J. Lu  ---
*** Bug 81570 has been marked as a duplicate of this bug. ***

[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/83714] [8 Regression] ICE in build_address, at cp/typeck.c:5733

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Jan 18 22:15:32 2018
New Revision: 256866

URL: https://gcc.gnu.org/viewcvs?rev=256866&root=gcc&view=rev
Log:
Fix template/inherit4.C.

PR c++/83714
* search.c (any_dependent_bases_p): Handle null TREE_BINFO.
* pt.c (instantiation_dependent_scope_ref_p): True if
any_dependent_bases_p.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/cp/search.c
trunk/gcc/testsuite/g++.dg/torture/pr83619.C

[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 #13 from acsawdey at gcc dot gnu.org ---
one more interesting piece ... 

Copying gcc/libbackend.a and gcc/*.o from willow2 (working build) to genoa and
linking go1 does not result in a working go1 binary. But, also copying over
libiberty.a libbacktrace.a libdecnumber.a libcpp.a libcommon-target.a and
libcommon.a and then linking does result in a working go1.

[Bug ada/83935] New: DWARF for a variant part is incorrect

[tromey at gcc dot gnu.org]

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

Bug ID: 83935
   Summary: DWARF for a variant part is incorrect
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Joel Brobecker sent me an Ada test case so that I could see a real-life
example of the use of DW_TAG_variant_part (in support of some Rust
stuff I'm doing elsewhere).

For this test case, GCC emits this DWARF:

 <1><7c0>: Abbrev Number: 4 (DW_TAG_structure_type)
<7c1>   DW_AT_name: (indirect string, offset: 0xb26): pck__rec
<7c5>   DW_AT_byte_size   : 13 byte block: 97 94 1 99 95 0 0 0 23 7 9 fc 1a 
<7d3>   DW_AT_decl_file   : 2
<7d4>   DW_AT_decl_line   : 15
<7d5>   DW_AT_sibling : <0x817>
 <2><7d9>: Abbrev Number: 5 (DW_TAG_member)
<7da>   DW_AT_name: (indirect string, offset: 0xaf8): discr
<7de>   DW_AT_decl_file   : 2
<7df>   DW_AT_decl_line   : 15
<7e0>   DW_AT_type: <0x7af>
<7e4>   DW_AT_data_member_location: 0
 <2><7e5>: Abbrev Number: 6 (DW_TAG_variant_part)
<7e6>   DW_AT_discr   : <0x7d9>
 <3><7ea>: Abbrev Number: 7 (DW_TAG_variant)
<7eb>   DW_AT_discr_value : 1
<7ec>   DW_AT_sibling : <0x7fd>


However, the DWARF standard says:

> If the variant part has a discriminant, the discriminant is represented
> by a separate debugging information entry which is a child of the variant 
> part entry.

So, I think that, according to the DWARF standard, that "discr" member must be
a child (not a sibling) of the DW_TAG_variant_part.

[Bug c++/83912] [constexpr] struct with a pointer to one of its members, returned by a function, is not a constant expression

[giu.campana at gmail dot com]

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

--- Comment #3 from Giuseppe Campana  ---
The snippet showed by DR2022
(http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#2022) works fine with
gcc, but it fails to compile if the object passes through a function. As
pointed out by Jakub, in these cases clang succeeds only is the object is not a
local constexpr.

[Bug c++/83921] [7/8 Regression] GCC rejects constexpr initialization of empty aggregate.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Looking into it.

[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.

[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 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 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 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 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 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 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&root=gcc&view=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 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&root=gcc&view=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&root=gcc&view=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 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 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
-I/home/

[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 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++/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&action=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 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 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&root=gcc&view=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 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 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 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 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

[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 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 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

[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 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 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 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 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 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 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 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 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 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&root=gcc&view=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 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 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 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 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

[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 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 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&action=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 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 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++/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 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 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&root=gcc&view=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 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/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 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&action=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++/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 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 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&root=gcc&view=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 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 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&action=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 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 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&root=gcc&view=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 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 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 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

[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&action=edit
unpreprocessed input

[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 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 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 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 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 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