[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[marxin at gcc dot gnu.org]

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

--- Comment #31 from Martin Liška  ---
Created attachment 43781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43781=edit
Partially reduced test-case

I've got 120KB partially reduced test-case. Any further reduction is not much
possible. I'm able to reproduce that with -O1 -Woverloaded-virtual.
It's super-weird issue, any ggc parameters adjustments do not make any change.
I would recommend to create Debian-specific issue and somebody will need to
investigate which patch is responsible for that.

[Bug c++/84973] [8 Regression] ICE: Segmentation fault (tree_check()/ultimate_transparent_alias_target())

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Fixed

[Bug c++/84968] [8 Regression] ICE in strip_typedefs_expr, at cp/tree.c:1792

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Fixed

[Bug c++/84789] [6/7 Regression] ICE with broken variable declaration in template class

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Mar 28 05:05:30 2018
New Revision: 258915

URL: https://gcc.gnu.org/viewcvs?rev=258915=gcc=rev
Log:
[PR c++/84789] adjust testcase for -fconcepts

When compiling with -fconcepts,
cp_parser_template_declaration_after_export calls
cp_parser_template_introduction and that preparses qualified-ids not
preceded by typename in such a way that, when we get to
cp_parser_parse_and_diagnose_invalid_type_name and then
cp_parser_diagnose_invalid_type_name, the nested name specifier no
longer carries the previous template-dependent context, so we don't
stand a chance to suggest the use of 'typename' any more.  Thus,
tolerate in the testcase the poorer error messages we get.

for  gcc/testsuite/ChangeLog

PR c++/84789
* g++.dg/template/pr84789.C: Adjust for testing with
-fconcepts too.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/pr84789.C

[Bug c++/84973] [8 Regression] ICE: Segmentation fault (tree_check()/ultimate_transparent_alias_target())

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Mar 28 05:05:14 2018
New Revision: 258914

URL: https://gcc.gnu.org/viewcvs?rev=258914=gcc=rev
Log:
[PR c++/84973] don't defer output of uninstantiated templates

When an anon struct gets a name through a typedef, we reset its
linkage and that of its members.  Member functions may get vague
linkage, which schedules them for deferred output, but we don't want
to add them to the queue if they're uninstantiated templates,
e.g. because the enclosing function is a template.  They will be added
as needed when the enclosing template is instantiated.


for  gcc/cp/ChangeLog

PR c++/84973
* decl2.c (note_vague_linkage_fn): Don't defer uninstantiated
templates.

for  gcc/testsuite/ChangeLog

PR c++/84973
* g++.dg/template/pr84973.C: New.
* g++.dg/template/pr84973-2.C: New.
* g++.dg/template/pr84973-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/pr84973-2.C
trunk/gcc/testsuite/g++.dg/template/pr84973-3.C
trunk/gcc/testsuite/g++.dg/template/pr84973.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84968] [8 Regression] ICE in strip_typedefs_expr, at cp/tree.c:1792

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Mar 28 05:04:59 2018
New Revision: 258913

URL: https://gcc.gnu.org/viewcvs?rev=258913=gcc=rev
Log:
[PR c++/84968] reject stmt-exprs in noexcept constexprs

We reject extended statement-expressions in template parameters, so we
might as well reject them in constant expressions used in noexcept
specifications.

for  gcc/cp/ChangeLog

PR c++/84968
* tree.c (strip_typedefs_expr): Reject STATEMENT_LISTs.

for  gcc/testsuite/ChangeLog

PR c++/84968
* g++.dg/eh/pr84968.C: New.

Added:
trunk/gcc/testsuite/g++.dg/eh/pr84968.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85100] __builtin_cpu_supports avx does not verify OS supports it

[njs at pobox dot com]

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

Nathaniel J. Smith  changed:

   What|Removed |Added

 CC||njs at pobox dot com

--- Comment #1 from Nathaniel J. Smith  ---
For context here: NumPy currently uses __builtin_cpu_supports("avx") to decide
whether it can use AVX-accelerated numerical kernels. We've been getting
regular bug reports from users where this __builtin_cpu_supports("avx")
returned true, but then NumPy crashes with a SIGILL when it tries to use AVX.
(It seems to be related to some kind of relatively common virtualization
configurations.)

Examples:

https://github.com/numpy/numpy/issues/10787
https://github.com/numpy/numpy/issues/9532
https://github.com/numpy/numpy/issues/10330
https://github.com/numpy/numpy/issues/9534

Now that Julian finally figured it out, I guess we'll work around it by calling
xgetbv ourselves:

https://github.com/numpy/numpy/pull/10814

but it really seems like it would be better if __builtin_cpu_supports would
check this itself.

[Bug c++/85105] New: missing -Wignored-qualifiers with const decltype

[msebor at gcc dot gnu.org]

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

Bug ID: 85105
   Summary: missing -Wignored-qualifiers with const decltype
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Both const qualifiers in the program below are ignored but GCC only issues
-Wignored-qualifiers for the first.  A warning for the second instance would be
even more useful since the author may be assuming that r2 declares a const
reference to int when it in fact declares a non-const reference.

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic -Wuseless-cast u.C
const int f ();   // -Wignored-qualifiers (good)

extern int 

const decltype (r1) r2 = r1;   // missing -Wignored-qualifiers
u.C:1:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
 const int f ();   // -Wignored-qualifiers (good)
 ^

[Bug target/82411] const is not always read-only

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #10 from Segher Boessenkool  ---
All done.

[Bug target/82411] const is not always read-only

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
Author: segher
Date: Tue Mar 27 23:28:25 2018
New Revision: 258909

URL: https://gcc.gnu.org/viewcvs?rev=258909=gcc=rev
Log:
rs6000: -mreadonly-in-sdata (PR82411)

This adds a new option -mreadonly-in-sdata (on by default) that
controls whether readonly data can be put in sdata.  (For EABI this
does nothing, readonly data is put in sdata2 as usual).


Backport from mainline
2018-03-08  Segher Boessenkool  

PR target/82411
* config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Don't put
readonly data in sdata, if that is disabled.
* config/rs6000/sysv4.opt (mreadonly-in-sdata): New option.
* doc/invoke.texi (RS/6000 and PowerPC Options): Document
-mreadonly-in-sdata option.


gcc/testsuite/
Backport from mainline
2018-03-08  Segher Boessenkool  

PR target/82411
* gcc.target/powerpc/ppc-sdata-2.c: Skip if -mno-readonly-in-sdata.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/config/rs6000/sysv4.opt
branches/gcc-6-branch/gcc/doc/invoke.texi
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/ppc-sdata-2.c

[Bug target/84914] PowerPC complex multiply/divide calls the wrong function when -mabi=ieeelongdouble

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Tue Mar 27 23:14:22 2018
New Revision: 258908

URL: https://gcc.gnu.org/viewcvs?rev=258908=gcc=rev
Log:
[gcc]
2018-03-27  Michael Meissner  

PR target/84914
* config/rs6000/rs6000.c (create_complex_muldiv): New helper
function to create the function decl for complex long double
multiply and divide for -mabi=ieeelongdouble.
(init_float128_ieee): Call it.

[gcc/testsuite]
2018-03-27  Michael Meissner  

PR target/84914
* gcc.target/powerpc/mulkc-2.c: New tests to make sure complex
long double multiply/divide uses the correct function.
* gcc.target/powerpc/mulkc-3.c: Likewise.
* gcc.target/powerpc/divkc-2.c: Likewise.
* gcc.target/powerpc/divkc-3.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/divkc3-2.c
trunk/gcc/testsuite/gcc.target/powerpc/divkc3-3.c
trunk/gcc/testsuite/gcc.target/powerpc/mulkc3-2.c
trunk/gcc/testsuite/gcc.target/powerpc/mulkc3-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82411] const is not always read-only

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Author: segher
Date: Tue Mar 27 23:13:02 2018
New Revision: 258907

URL: https://gcc.gnu.org/viewcvs?rev=258907=gcc=rev
Log:
rs6000: -mreadonly-in-sdata (PR82411)

This adds a new option -mreadonly-in-sdata (on by default) that
controls whether readonly data can be put in sdata.  (For EABI this
does nothing, readonly data is put in sdata2 as usual).


Backport from mainline
2018-03-08  Segher Boessenkool  

PR target/82411
* config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Don't put
readonly data in sdata, if that is disabled.
* config/rs6000/sysv4.opt (mreadonly-in-sdata): New option.
* doc/invoke.texi (RS/6000 and PowerPC Options): Document
-mreadonly-in-sdata option.


Backport from mainline
2018-03-08  Segher Boessenkool  

PR target/82411
* gcc.target/powerpc/ppc-sdata-2.c: Skip if -mno-readonly-in-sdata.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/config/rs6000/sysv4.opt
branches/gcc-7-branch/gcc/doc/invoke.texi
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/ppc-sdata-2.c

[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304

[munroesj at gcc dot gnu.org]

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

--- Comment #11 from Steven Munroe  ---
The requirement was to reduce the use of (in-line) assembler in libraries. Asm
is error prone in the light of 32/64-bit ABI difference and the compiler
(usual) generates the correct code for the target.

Float <-> int/long conversion is common operation and builtin instructions are
preferred where the Posix functions are unnecessarily heavy.

[Bug c++/85104] New: double underline in a C++ error: duplicate const

[msebor at gcc dot gnu.org]

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

Bug ID: 85104
   Summary: double underline in a C++ error: duplicate const
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The redundant const keyword in the error below is underlined twice in GCC 8. 
GCC 7 underlines it just once so it seems like something is amiss.

$ cat u.C && gcc -S u.C
const int const i = 0;
u.C:1:11: error: duplicate ‘const’
 const int const i = 0;
   ^
   -

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

[pthaugen at gcc dot gnu.org]

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

--- Comment #18 from Pat Haugen  ---
(In reply to Richard Biener from comment #17)
> Pat, please open a new bug for the regression caused by the fix.

Done, pr85103.

[Bug ipa/85103] New: Performance regressions on SPEC with r257582

[pthaugen at gcc dot gnu.org]

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

Bug ID: 85103
   Summary: Performance regressions on SPEC with r257582
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: dje at gcc dot gnu.org, hubicka at gcc dot gnu.org,
marxin at gcc dot gnu.org, segher at kernel dot 
crashing.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

r257582 is responsible for a 6% degradation in CPU2000 175.vpr and a 12%
degradation in CPU2006 401.bzip2. Both run on a Power7 box.

Very initial look at profile of bzip2 shows degradation is contained to
mainSort(), which showed a 54% increase in run cycles. Appears one of the calls
to mainGtU() is inlined into mainSort in the slow version, but the drop in
cycle counts on mainGtu is no where close to the increase on mainSort.

[Bug c++/85093] [7/8 Regression] wrong number of template arguments does not trigger error when one argument is variadic

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85060] [7/8 Regression] Object cannot call its inherited member function "without object"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/85067] [8 Regression] ICE with volatile parameter in defaulted copy-constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #5 from Paolo Carlini  ---
Fixed.

[Bug c++/85067] [8 Regression] ICE with volatile parameter in defaulted copy-constructor

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Mar 27 21:19:25 2018
New Revision: 258904

URL: https://gcc.gnu.org/viewcvs?rev=258904=gcc=rev
Log:
/cp
2018-03-27  Paolo Carlini  

PR c++/85067
* method.c (defaulted_late_check): Partially revert r253321 changes,
do not early return upon error.

/testsuite
2018-03-27  Paolo Carlini  

PR c++/85067
* g++.dg/cpp0x/defaulted51.C: New.
* g++.dg/cpp0x/constexpr-68754.C: Adjust.

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

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #9 from Harald Anlauf  ---
Playing around with the code in comment #6, with default initialization
within the type:

program p
  implicit none
  type t
!character(3) :: c2(2) = ['b', 'c'] // 'a'   ! lacks padding? / ICE
 character(3) :: c3(2) = ['b', 'c'] // 'ax'  ! OK
 character(3) :: c4(2) = ['b', 'c'] // 'axy' ! only partially OK
   end type
   type(t)  :: z
   character(3) :: c
   c = z%c3(1) ! OK
   print *, c
   c = z%c3(2) ! OK
   print *, c
   c = z%c4(1) ! OK
   print *, c
   c = z%c4(2) ! truncated
   print *, c
end

This prints:

 bax
 cax
 bax
 ca

The dump tree starts with:

p ()
{
  character(kind=1) c[1:3];
  static struct t z = {.c3={"bax", "cax"}, .c4={"bax ", "cax "}};

  __builtin_memmove ((void *) , (void *) [0], 3);
[...]
  __builtin_memmove ((void *) , (void *) [1], 3);
[...]

I do not see from the dump tree what could be wrong with the character
lengths, but somehow the truncation in the last print needs to be
understood.

Enabling the line with c2 and adding a line

   c = z%c2(1)

to the main produces in the dump

  static struct t z = {.c2={"ba", "ca"}, .c3={"bax", "cax"}, .c4={"bax ", "cax
"}};

  __builtin_memmove ((void *) , (void *) [0], 3);

which should not happen.

[Bug fortran/85102] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4464

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-27
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[marxin at gcc dot gnu.org]

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

--- Comment #30 from Martin Liška  ---
(In reply to Martin Liška from comment #29)
> Thanks. I can't reproduce that on my openSUSE package nor on my build
> gcc-7-branch. However I downloaded Debian binary and I can confirm that.
> I'm bisecting now...

... reducing :)

[Bug fortran/85088] improve diagnostic for bad INTENT declaration ('Invalid character in name at')

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> (In reply to Dominique d'Humieres from comment #4)
> > It seems that there is some inconsistencies
> 
> Right, in particular regarding INTENT_INOUT vs DECL_INOUT etc. Therefore the
> patch in comment #2 is much too naive (and produces a huge amount of
> regressions).

These regressions can actually be fixed by making sure that the DECL_* values
correspond to INTENT_*:

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 258893)
+++ gcc/fortran/decl.c  (working copy)
@@ -4674,9 +4674,10 @@ match_attr_spec (void)
 {
   /* Modifiers that can exist in a type statement.  */
   enum
-  { GFC_DECL_BEGIN = 0,
-DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
-DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
+  { GFC_DECL_BEGIN = 0, DECL_ALLOCATABLE = GFC_DECL_BEGIN,
+DECL_IN = INTENT_IN, DECL_OUT = INTENT_OUT, DECL_INOUT = INTENT_INOUT,
+DECL_DIMENSION, DECL_EXTERNAL,
+DECL_INTRINSIC, DECL_OPTIONAL,
 DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
 DECL_STATIC, DECL_AUTOMATIC,
 DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,

[Bug c++/85077] [8 Regression] V[248][SD]F abs not optimized to

[kretz at kde dot org]

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

--- Comment #8 from Matthias Kretz  ---
Thanks! FWIW my abs implementation now uses:

template 
[[gnu::optimize("finite-math-only,no-signed-zeros")]]
constexpr Storage abs(Storage v)
{
return v.d < 0 ? -v.d : v.d;
}

[Bug c++/85076] [6/7 Regression] ICE with invalid template used as lambda argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |invalid template used as|invalid template used as
   |lambda argument |lambda argument

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/85077] [8 Regression] V[248][SD]F abs not optimized to

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/85077] [8 Regression] V[248][SD]F abs not optimized to

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 27 20:00:56 2018
New Revision: 258903

URL: https://gcc.gnu.org/viewcvs?rev=258903=gcc=rev
Log:
PR c++/85077
* cp-gimplify.c (cp_fold) : For ctors with vector
type call fold to generate VECTOR_CSTs when possible.

* g++.dg/ext/vector35.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/vector35.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85061] ICE with __builtin_offsetof applied to static member

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 27 19:59:30 2018
New Revision: 258902

URL: https://gcc.gnu.org/viewcvs?rev=258902=gcc=rev
Log:
PR c++/85061
* c-common.c (fold_offsetof_1) : Assert that
get_base_address of the second operand is a VAR_P, rather than the
operand itself, and use gcc_checking_assert instead of gcc_assert.

* g++.dg/ext/builtin-offsetof3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/builtin-offsetof3.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85076] [6/7/8 Regression] ICE with invalid template used as lambda argument

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 27 19:58:30 2018
New Revision: 258901

URL: https://gcc.gnu.org/viewcvs?rev=258901=gcc=rev
Log:
PR c++/85076
* tree.c (cp_build_reference_type): If to_type is error_mark_node,
return it right away.

* g++.dg/cpp1y/pr85076.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr85076.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85043] -Wuseless-cast false positive for temporary objects

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  ---
That approach would be definitely Ok with me, Eric.

[Bug fortran/85083] [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Hi Thomas - I have closed it for you :-)

Paul

[Bug c++/85043] -Wuseless-cast false positive for temporary objects

[egallager at gcc dot gnu.org]

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

--- Comment #10 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #2)
> Thanks. I'm seriously wondering if this is also a problem with the name of
> the warning, because, I suppose, the same warning named
> -Wcast-to-the-same-type would generate different expectations in terms of
> false positives, etc, right? 

Instead of renaming -Wuseless-cast to -Wcast-to-the-same-type how about
splitting the 2 into separate warnings? -Wuseless-cast for actually useless
ones and -Wcast-to-the-same-type for ones that are just to the same type but
not necessarily useless. That's kind of the same as adding levels, but
addresses some of my usual complaints about numerical warnings levels, such as
having them be separately controllable.

[Bug c++/85079] Segfault While Compiling DXX-Rebirth Project

[afuturepilotis at gmail dot com]

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

--- Comment #3 from John Ackerman  ---
I thought I had attached it, but apparently the file was too big. It's now
attached. Let me know if you need anything else!

[Bug c++/85079] Segfault While Compiling DXX-Rebirth Project

[afuturepilotis at gmail dot com]

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

--- Comment #2 from John Ackerman  ---
Created attachment 43780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43780=edit
Prepocessed Source

[Bug c++/85043] -Wuseless-cast false positive for temporary objects

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|paolo.carlini at oracle dot com|

--- Comment #9 from Paolo Carlini  ---
Martin, my point in the previous comment was simple: it's been a while since I
implemented the warning and today it finally occurred to me that I really
intended to implement a very simple warning for cast to its own type, as
consistently documented. Unfortunately the name is misleading. Personally, I
don't have any short/mid term plans to implement something much more complex
and sophisticated which goes beyond that. I'm pretty confident that will not
cause major problems to anybody because the warning isn't part of any set
enabled by default (if I'm misremembering that should definitely be changed).
Also, I would personally not object if somebody wants to deprecate the name of
the current warning, rename it to something really straightforward matching the
docs and then proceed to implement under "useless" something doing "the right
thing".

[Bug c++/85043] -Wuseless-cast false positive for temporary objects

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
It sounds like the report is not about the documentation but about the term
"useless" in the text of the warning.  Useless implies the cast serves no
useful purpose which is not true in the test case.  If we wanted to go by the
documentation then the warning should say something like "object cast to its
own type" but I don't think that would be helpful or reflect the intended
purpose of the warning: to point out casts that do, in fact, serve no useful
purpose.  I would think that changing both when the warning is issued and how
it's documented is the appropriate solution.

That said, I don't think the distinction between class types and non-class
types is essential.  The warning also triggers for casts that create a
(temporary) rvalue from an lvalue, as in:

  extern int i;
  const int  = (int)i;   // bogus -Wuseless-cast

even though these casts are also not useless.  (Ditto when i itself is a
reference.)

Fixing this shouldn't require introducing levels.

[Bug fortran/85088] improve diagnostic for bad INTENT declaration ('Invalid character in name at')

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #4)
> It seems that there is some inconsistencies

Right, in particular regarding INTENT_INOUT vs DECL_INOUT etc. Therefore the
patch in comment #2 is much too naive (and produces a huge amount of
regressions).

However, the following works well (and is free of regressions):


Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 258893)
+++ gcc/fortran/decl.c  (working copy)
@@ -4811,6 +4811,8 @@ match_attr_spec (void)
d = DECL_IN;
  else if (gfc_match (" ( out )") == MATCH_YES)
d = DECL_OUT;
+ else
+   gfc_error ("Bad INTENT specification at %C");
}
}
  else if (ch == 'r')



With this ones gets the following:


c0.f90:2:18:

integer, intent(int) :: x
  1
Error: Bad INTENT specification at (1)
c0.f90:3:18:

integer, intent :: y
  1
Error: Bad INTENT specification at (1)
c0.f90:4:11:

integer, inten  :: z
   1
Error: Invalid character in name at (1)

[Bug fortran/85102] New: ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4464

[gs...@t-online.de]

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

Bug ID: 85102
   Summary: ICE in gfc_conv_intrinsic_dot_product, at
fortran/trans-intrinsic.c:4464
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Follow-up of pr83998, but gives an ICE down to at least 4.8 :


$ cat z1.f90
program p
   integer, parameter :: a((2)) = 1
   integer, parameter :: b = dot_product(a, a)
   print *, b
end


$ cat z2.f90
program p
   integer, parameter :: a((0)) = 1
   integer, parameter :: b = dot_product(a, a)
   print *, b
end


$ gfortran-8-20180325 -c z1.f90
z1.f90:4:0:

print *, b

internal compiler error: in gfc_conv_intrinsic_dot_product, at
fortran/trans-intrinsic.c:4464
0x78a94d gfc_conv_intrinsic_dot_product
../../gcc/fortran/trans-intrinsic.c:4464
0x79e0ba gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9057
0x77db95 gfc_conv_function_expr
../../gcc/fortran/trans-expr.c:6788
0x77e132 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7922
0x784858 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8057
0x7a4646 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2585
0x74a487 trans_code
../../gcc/fortran/trans.c:2044
0x7a20f7 build_dt
../../gcc/fortran/trans-io.c:2027
0x74a4a7 trans_code
../../gcc/fortran/trans.c:2016
0x771a79 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x700cc0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x700cc0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74791f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149

[proski at gnu dot org]

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

--- Comment #1 from Pavel Roskin  ---
Created attachment 43779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43779=edit
Preprocessed source

[Bug c++/85101] New: C++17 ICE in build_over_call, at cp/call.c:8149

[proski at gnu dot org]

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

Bug ID: 85101
   Summary: C++17 ICE in build_over_call, at cp/call.c:8149
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: proski at gnu dot org
  Target Milestone: ---

Today's gcc source from git. C++17 and C++2a are affected, C++14 is not. I was
able to compile that code with the latest (at the time) gcc snapshot about a
month ago, so it's probably a recent regression. gcc 7.3.1 can compile the
code.

Fedora 27 x86_64, all up-to-date, gcc compiled from git and installed to
/opt/gcc

$ /opt/gcc/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/roskinp/src/gcc/configure --enable-languages=c++
--disable-multilib --prefix=/opt/gcc : (reconfigured)
/home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib
--prefix=/opt/gcc : (reconfigured) /home/roskinp/src/gcc/configure
--enable-languages=c++ --disable-multilib --prefix=/opt/gcc : (reconfigured)
/home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib
--prefix=/opt/gcc : (reconfigured) /home/roskinp/src/gcc/configure
--enable-languages=c++ --disable-multilib --prefix=/opt/gcc : (reconfigured)
/home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib
--prefix=/opt/gcc
Thread model: posix
gcc version 8.0.1 20180327 (experimental) (GCC)

$ /opt/gcc/bin/g++ -c Chrono.ii -std=c++17
/home/roskinp/chrono/Source/Utility/Chrono.cpp: In function
‘std::__cxx11::string VG::Utility::to_string(VG::Utility::Milliseconds)’:
/home/roskinp/chrono/Source/Utility/Chrono.cpp:63:73: internal compiler error:
in build_over_call, at cp/call.c:8149
   "00" + to_string(milliseconds.count() % milliseconds::period::den)};
 ^
0x5a84d1 build_over_call
/home/roskinp/src/gcc/gcc/cp/call.c:8143
0x7fa263 build_new_method_call_1
/home/roskinp/src/gcc/gcc/cp/call.c:9363
0x7fa263 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
/home/roskinp/src/gcc/gcc/cp/call.c:9438
0x7fadc3 build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, tree_node*, int, int)
/home/roskinp/src/gcc/gcc/cp/call.c:8966
0x8a99e3 expand_default_init
/home/roskinp/src/gcc/gcc/cp/init.c:1887
0x8a99e3 expand_aggr_init_1
/home/roskinp/src/gcc/gcc/cp/init.c:2002
0x8aa349 build_aggr_init(tree_node*, tree_node*, int, int)
/home/roskinp/src/gcc/gcc/cp/init.c:1742
0x85eebf build_aggr_init_full_exprs
/home/roskinp/src/gcc/gcc/cp/decl.c:6273
0x85eebf check_initializer
/home/roskinp/src/gcc/gcc/cp/decl.c:6422
0x876cbc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/roskinp/src/gcc/gcc/cp/decl.c:7127
0x91331b cp_parser_init_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:19741
0x91a788 cp_parser_simple_declaration
/home/roskinp/src/gcc/gcc/cp/parser.c:13059
0x91b598 cp_parser_block_declaration
/home/roskinp/src/gcc/gcc/cp/parser.c:12884
0x91bfc9 cp_parser_declaration_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:12478
0x8fa533 cp_parser_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:10927
0x8fb4a0 cp_parser_statement_seq_opt
/home/roskinp/src/gcc/gcc/cp/parser.c:11276
0x8fb577 cp_parser_compound_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:11230
0x91c615 cp_parser_implicitly_scoped_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:12533
0x8fae5a cp_parser_selection_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:11416
0x8fae5a cp_parser_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:10818

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #29 from Martin Liška  ---
Thanks. I can't reproduce that on my openSUSE package nor on my build
gcc-7-branch. However I downloaded Debian binary and I can confirm that.
I'm bisecting now...

[Bug target/85100] New: __builtin_cpu_supports avx does not verify OS supports it

[jtaylor.debian at googlemail dot com]

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

Bug ID: 85100
   Summary: __builtin_cpu_supports avx does not verify OS supports
it
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com
  Target Milestone: ---

__builtin_cpu_supports("avx") checks that the cpu supports avx instructions,
but without OS support the instructions cannot be used.

To reproduce launch linux with the noxsave boot option. The function will
return nonzero as the feature is there but programs using avx will crash with
SIGILL.

This makes this function significantly less useful as you need to add
additional checks (using xgetbv) to verify operating system support.

At least this behavior it should be more clearly documented. Not everybody is
aware the operating system may not support or that you can disable it in linux
with a boot option.

[Bug sanitizer/85081] [7/8 Regression] Sanitizer error with references in vectorized/parallel for-loop

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug fortran/85084] [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Mar 27 18:42:02 2018
New Revision: 258900

URL: https://gcc.gnu.org/viewcvs?rev=258900=gcc=rev
Log:
2018-03-27  Thomas Koenig  

PR fortran/85084
* frontend-passes.c (gfc_run_passes): Do not run front-end
optimizations if a previous error occurred.

2018-03-27  Thomas Koenig  

PR fortran/85084
* gfortran.dg/matmul_rank_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/matmul_rank_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/85081] [7/8 Regression] Sanitizer error with references in vectorized/parallel for-loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-27
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Martin, this is because of:
  /* When within an OMP context, do not emit ASAN_MARK internal fns.  */
  if (gimplify_omp_ctxp)
return;
in asan_poison_variable.  Not really sure why exactly it has been added, but if
we can't emit the ASAN_UNPOISON, we can't emit the corresponding ASAN_POISON
either.

So something like:
--- gcc/gimplify.c.jj   2018-03-16 13:43:14.831910333 +0100
+++ gcc/gimplify.c  2018-03-27 20:11:27.680195380 +0200
@@ -1689,7 +1689,8 @@ gimplify_decl_expr (tree *stmt_p, gimple
  && !TREE_STATIC (decl)
  && !DECL_HAS_VALUE_EXPR_P (decl)
  && DECL_ALIGN (decl) <= MAX_SUPPORTED_STACK_ALIGNMENT
- && dbg_cnt (asan_use_after_scope))
+ && dbg_cnt (asan_use_after_scope)
+ && !gimplify_omp_ctxp)
{
  asan_poisoned_variables->add (decl);
  asan_poison_variable (decl, false, seq_p);
@@ -6614,7 +6615,8 @@ gimplify_target_expr (tree *expr_p, gimp
}
  if (asan_poisoned_variables
  && DECL_ALIGN (temp) <= MAX_SUPPORTED_STACK_ALIGNMENT
- && dbg_cnt (asan_use_after_scope))
+ && dbg_cnt (asan_use_after_scope)
+ && !gimplify_omp_ctxp)
{
  tree asan_cleanup = build_asan_poison_call_expr (temp);
  if (asan_cleanup)

fixes it from me, but not really sure about the reasons why the above check is
in there.  Martin?

[Bug target/85095] [6/7/8 Regression] worse code generated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  What happens is that combine uses simplify-rtx.c which optimizes
away the useless outer (plus with const0_rtx), and we don't have a pattern that
matches that.

[Bug fortran/85084] [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #2)
> I cannot reproduce this on my system.

Actually, I can.

Let's see how this survives regression-testing.

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[vz-gcc at zeitlins dot org]

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

--- Comment #28 from Vadim Zeitlin  ---
(In reply to Martin Liška from comment #26)
> complete output of:
> diff -u nowarn.s warn.s

Attached, but most of it is just noise from the label renumbering due to the
extra label being created, as previously mentioned.

[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #12 from Segher Boessenkool  ---
Patch for the original problem went in as r258452:
(I accidentally deleted the changelog from the commit message, so BZ didn't
pick this up).

combine: Fix PR84780 (more LOG_LINKS trouble)

There still are situations where we have stale LOG_LINKS.  This causes
combine to try two-insn combinations I2->I3 where the register set by
I2 is used before I3 as well.  Not good.

This patch fixes it by checking for this situation in can_combine_p
(similar to what we already do for three and four insn combinations).




Patch for #c10 went in as r258523.

combine: Don't make log_links for pc_rtx (PR84780 #c10)

distribute_links tries to place a log_link for whatever the destination
of the modified instruction is.  It shouldn't do that when that dest
is pc_rtx, which isn't actually a register.


* combine.c (distribute_links): Don't make a link based on pc_rtx.


Closing as fixed.

[Bug fortran/85084] [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[vz-gcc at zeitlins dot org]

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

--- Comment #27 from Vadim Zeitlin  ---
Created attachment 43777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43777=edit
Diff between assembly generated with and without the warning options

[Bug fortran/85084] [6/7/8 Regression] ICE: out of memory allocating 18446744073709551600 bytes ...

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
I cannot reproduce this on my system.

However, could you check if

Index: frontend-passes.c
===
--- frontend-passes.c   (revision 258845)
+++ frontend-passes.c   (working copy)
@@ -156,6 +156,10 @@
   check_locus (ns);
 #endif

+  gfc_get_errors (, );
+  if (e > 0)
+return;
+
   if (flag_frontend_optimize || flag_frontend_loop_interchange)
 optimize_namespace (ns);

@@ -168,10 +172,6 @@
   expr_array.release ();
 }

-  gfc_get_errors (, );
-  if (e > 0)
-   return;
-
   if (flag_realloc_lhs)
 realloc_strings (ns);


would fix this?  There is no sense in running any sort of
front-end optimization if the program has errors...

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[marxin at gcc dot gnu.org]

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

--- Comment #26 from Martin Liška  ---
complete output of:
diff -u nowarn.s warn.s

[Bug fortran/85083] [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[vz-gcc at zeitlins dot org]

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

--- Comment #25 from Vadim Zeitlin  ---
(In reply to Martin Liška from comment #24)
> > Please let me know if I can do anything else.
> 
> Can you please attach full diff?

Sorry, diff between what and what?

> Am I correct that your native compiler is on x86_64?

Yes.

> Please attach output of --verbose.

Here it is:

% g++-7 --verbose -S -std=c++17 -O2 -Wnonnull -Woverloaded-virtual
gcc-7.3-x86_64-linux.cpp -o warn.s
Using built-in specs.
COLLECT_GCC=g++-7
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-12'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-12)
COLLECT_GCC_OPTIONS='-v' '-S' '-std=c++1z' '-O2' '-Wnonnull'
'-Woverloaded-virtual' '-o' 'warn.s' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE 14881.cpp -quiet -dumpbase 14881.cpp -mtune=generic -march=x86-64
-auxbase-strip warn.s -O2 -Wnonnull -Woverloaded-virtual -std=c++1z -version -o
warn.s
GNU C++14 (Debian 7.3.0-12) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/7
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++14 (Debian 7.3.0-12) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6054b92b0b90c9db1f26de9c9b53361c
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-S' '-std=c++1z' '-O2' '-Wnonnull'
'-Woverloaded-virtual' '-o' 'warn.s' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

[Bug fortran/85083] [8 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:2915

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Mar 27 17:28:35 2018
New Revision: 258899

URL: https://gcc.gnu.org/viewcvs?rev=258899=gcc=rev
Log:
2018-03-27  Thomas Koenig  
Harald Anlauf  

PR fortran/85083
* primary.c (gfc_convert_to_structure_constructor): Check
conformance of argument types in structure constructor.

2018-03-27  Thomas Koenig  
Harald Anlauf  

* gfortran.dg/structure_constructor_15.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/structure_constructor_15.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84514] powerpc sub optimal condition register reuse with extended inline asm

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc-*-* |powerpc*-*-*

--- Comment #1 from Segher Boessenkool  ---
If you do not use a volatile asm (it has no outputs so it is always volatile),
you get:

(replace the asm with
  long dum;
  asm("#asm input register %0" : "=r"(dum) : "r"(lr));
):

cmpdi 7,3,5
bnelr 7
addis 8,2,.LC0@toc@ha
ld 8,.LC0@toc@l(8)
addis 9,2,.LC1@toc@ha
ld 9,.LC1@toc@l(9)
#APP
 # 7 "84514.c" 1
mflr 7
 # 0 "" 2
 # 16 "84514.c" 1
mfctr 10
 # 0 "" 2
#NO_APP
std 7,0(8)
std 10,0(9)
blr

so everything is fine then.  The difference already happens at tree level,
many things do not know how to optimise in the presence of volatile asm.

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[marxin at gcc dot gnu.org]

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

--- Comment #24 from Martin Liška  ---
> Please let me know if I can do anything else.

Can you please attach full diff? Am I correct that your native compiler is on
x86_64? Please attach output of --verbose.

[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs

[hjl.tools at gmail dot com]

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

Bug 85044 Summary: ENDBR is missing in ix86_trampoline_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85044

   What|Removed |Added

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

[Bug target/85044] ENDBR is missing in ix86_trampoline_init

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 8.

[Bug target/85044] ENDBR is missing in ix86_trampoline_init

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Mar 27 17:18:51 2018
New Revision: 258897

URL: https://gcc.gnu.org/viewcvs?rev=258897=gcc=rev
Log:
i386: Insert ENDBR to trampoline for -fcf-protection=branch -mibt

When -fcf-protection=branch -mibt are used, we need to insert ENDBR
to trampoline.  TRAMPOLINE_SIZE is creased by 4 bytes to accommodate
4-byte ENDBR instruction.

gcc/

PR target/85044
* config/i386/i386.c (ix86_trampoline_init): Insert ENDBR for
-fcf-protection=branch -mibt.
* config/i386/i386.h (TRAMPOLINE_SIZE): Increased by 4 bytes.

gcc/testsuite/

PR target/85044
* gcc.target/i386/pr85044.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr85044.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/83462] [8 regression] c-c++-common/Warray-bounds-3.c fails on arm-none-eabi

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Sebor  ---
The failures should be gone with r258896.

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[vz-gcc at zeitlins dot org]

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

--- Comment #23 from Vadim Zeitlin  ---
Just to confirm that this is not specific to MinGW-w64, I've attached the test
case (and a preprocessed version of it) allowing to reproduce the same problem
with Linux x86_64 version of g++ 7.3 (7.3.0-12 from Debian/Sid).

Unlike the other test case, this one really requires both -Wnonnull and
-Woverloaded-virtual to be specified to see the problem, so the commands to use
are (I also switched to assembly because I figured this was simpler to compare
than disassembling object files, but this is not significant):

% g++-7 -S -std=c++17 -O2 gcc-7.3-x86_64-linux.cpp -o nowarn.s
% g++-7 -S -std=c++17 -O2 gcc-7.3-x86_64-linux.cpp -Wnonnull
-Woverloaded-virtual -o warn.s
% diff -u nowarn.s warn.s|head
--- nowarn.s2018-03-27 17:11:31.841485730 +
+++ warn.s  2018-03-27 17:11:41.961553404 +
@@ -616,17 +616,15 @@
 .LEHB19:
call   
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l@PLT
 .LEHE19:
-.L89:
-   lock addl   $1, _ZN8lmi_test4test20test_tools_successesE(%rip)
popq%rbx
.cfi_remember_state

("head" is used because there are plenty of other insignificant differences due
to the labels renumbering later).

Please let me know if I can do anything else.

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P1  |P4

--- Comment #6 from Jakub Jelinek  ---
After the change this is only error-recovery it seems, so P4.

[Bug testsuite/83462] [8 regression] c-c++-common/Warray-bounds-3.c fails on arm-none-eabi

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Author: msebor
Date: Tue Mar 27 17:08:41 2018
New Revision: 258896

URL: https://gcc.gnu.org/viewcvs?rev=258896=gcc=rev
Log:
PR testsuite/83462 - c-c++-common/Warray-bounds-3.c fails on arm-none-eabi

gcc/testsuite/ChangeLog:
* c-c++-common/Warray-bounds-4.c: Disable assertion for targets
other than x86.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-4.c

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[jakub at gcc dot gnu.org]

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

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

Variant fix, instead of trying to optimize it some way (which is even less
precise than what we do right now), this just reverts to GCC 7 behavior if we
detect a SPEC2k17-like pow call.  If/once glibc has a fast exp10, we can use
exp10 in that case instead of leaving pow around.

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[vz-gcc at zeitlins dot org]

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

--- Comment #22 from Vadim Zeitlin  ---
Created attachment 43775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43775=edit
Compressed preprocessed test case for native Linux gcc 7.3

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[vz-gcc at zeitlins dot org]

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

--- Comment #21 from Vadim Zeitlin  ---
Created attachment 43774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43774=edit
Reduced test case showing the problem with native g++ 7.3

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[mathieu.malaterre at gmail dot com]

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

--- Comment #20 from Mathieu Malaterre  ---
(In reply to Martin Liška from comment #19)
> (In reply to Mathieu Malaterre from comment #18)
> > The first diff seems to be here:
> > 
> > +Use of uninitialised value of size 8
> > +   at 0x98CBD7: sparseset_bit_p (sparseset.h:147)
> > +   by 0x98CBD7: process_bb_node_lives(ira_loop_tree_node*)
> > (ira-lives.c:1226)
> > +   by 0x97189E: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
> > (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806)
> > +   by 0x98D231: ira_create_allocno_live_ranges() (ira-lives.c:1564)
> > +   by 0x97345C: ira_build() (ira-build.c:3422)
> > +   by 0x96ACCB: ira (ira.c:5308)
> > +   by 0x96ACCB: (anonymous namespace)::pass_ira::execute(function*)
> > (ira.c:5619)
> > +   by 0xA30676: execute_one_pass(opt_pass*) (passes.c:2465)
> > +   by 0xA30E80: execute_pass_list_1(opt_pass*) (passes.c:2554)
> > +   by 0xA30E92: execute_pass_list_1(opt_pass*) (passes.c:2555)
> > +   by 0xA30ED4: execute_pass_list(function*, opt_pass*) (passes.c:2565)
> > +   by 0x7ABC51: cgraph_node::expand() (cgraphunit.c:2042)
> > +   by 0x7ACFF8: expand_all_functions (cgraphunit.c:2178)
> > +   by 0x7ACFF8: symbol_table::compile() [clone .part.50] 
> > (cgraphunit.c:2536)
> > +   by 0x7AECE6: compile (cgraphunit.c:2629)
> > +   by 0x7AECE6: symbol_table::finalize_compilation_unit()
> > (cgraphunit.c:2626)
> 
> This should be fine, please take a look here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78454

Ooops :( Sorry false alarm. So I meant to say "This must be somewhere before
[insert block quote]".

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #19 from Martin Liška  ---
(In reply to Mathieu Malaterre from comment #18)
> The first diff seems to be here:
> 
> +Use of uninitialised value of size 8
> +   at 0x98CBD7: sparseset_bit_p (sparseset.h:147)
> +   by 0x98CBD7: process_bb_node_lives(ira_loop_tree_node*)
> (ira-lives.c:1226)
> +   by 0x97189E: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
> (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806)
> +   by 0x98D231: ira_create_allocno_live_ranges() (ira-lives.c:1564)
> +   by 0x97345C: ira_build() (ira-build.c:3422)
> +   by 0x96ACCB: ira (ira.c:5308)
> +   by 0x96ACCB: (anonymous namespace)::pass_ira::execute(function*)
> (ira.c:5619)
> +   by 0xA30676: execute_one_pass(opt_pass*) (passes.c:2465)
> +   by 0xA30E80: execute_pass_list_1(opt_pass*) (passes.c:2554)
> +   by 0xA30E92: execute_pass_list_1(opt_pass*) (passes.c:2555)
> +   by 0xA30ED4: execute_pass_list(function*, opt_pass*) (passes.c:2565)
> +   by 0x7ABC51: cgraph_node::expand() (cgraphunit.c:2042)
> +   by 0x7ACFF8: expand_all_functions (cgraphunit.c:2178)
> +   by 0x7ACFF8: symbol_table::compile() [clone .part.50] (cgraphunit.c:2536)
> +   by 0x7AECE6: compile (cgraphunit.c:2629)
> +   by 0x7AECE6: symbol_table::finalize_compilation_unit()
> (cgraphunit.c:2626)

This should be fine, please take a look here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78454

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P1  |P3
   Target Milestone|8.0 |9.0
Summary|[8 regression]  |gcc.target/aarch64/store_v2
   |gcc.target/aarch64/store_v2 |vec_lanes.c fails with
   |vec_lanes.c fails with  |-mabi=ilp32
   |-mabi=ilp32 |

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Test is XFAILed.
Codegen improvement for ILP32 is not a blocker for GCC 8

[Bug target/67297] PowerPC does not support all vector interfaces from the ELFv2 1.1 ABI

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #2 from Bill Schmidt  ---
Carl Love and Will Schmidt have ensured the built-in support is now up to date.
 Closing.

[Bug target/83009] [8 regression] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Mar 27 16:52:10 2018
New Revision: 258894

URL: https://gcc.gnu.org/viewcvs?rev=258894=gcc=rev
Log:
[AArch64] XFAIL gcc.target/aarch64/store_v2vec_lanes.c for ILP32

The test in question fails for ilp32. The initial analysis I did in the PR for
it
is that for ILP32 we generate somewhat different address forms that we'd need
to adjust aarch64_classify_address to catch.
Given the optimisation this test checks for was added for GCC 8 it is not a
regression, and improving the codegen on ILP32
would be an enhancement rather than a fix. So Richi has asked for it to be
marked as XFAIL on ILP32, which is what this
patch does.
Checked that the test still passes on LP64 and appears as XFAIL on -mabi=ilp32.

PR target/83009
* gcc.target/aarch64/store_v2vec_lanes.c: XFAIL for ilp32.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[mathieu.malaterre at gmail dot com]

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

--- Comment #18 from Mathieu Malaterre  ---
The first diff seems to be here:

+Use of uninitialised value of size 8
+   at 0x98CBD7: sparseset_bit_p (sparseset.h:147)
+   by 0x98CBD7: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1226)
+   by 0x97189E: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806)
+   by 0x98D231: ira_create_allocno_live_ranges() (ira-lives.c:1564)
+   by 0x97345C: ira_build() (ira-build.c:3422)
+   by 0x96ACCB: ira (ira.c:5308)
+   by 0x96ACCB: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5619)
+   by 0xA30676: execute_one_pass(opt_pass*) (passes.c:2465)
+   by 0xA30E80: execute_pass_list_1(opt_pass*) (passes.c:2554)
+   by 0xA30E92: execute_pass_list_1(opt_pass*) (passes.c:2555)
+   by 0xA30ED4: execute_pass_list(function*, opt_pass*) (passes.c:2565)
+   by 0x7ABC51: cgraph_node::expand() (cgraphunit.c:2042)
+   by 0x7ACFF8: expand_all_functions (cgraphunit.c:2178)
+   by 0x7ACFF8: symbol_table::compile() [clone .part.50] (cgraphunit.c:2536)
+   by 0x7AECE6: compile (cgraphunit.c:2629)
+   by 0x7AECE6: symbol_table::finalize_compilation_unit() (cgraphunit.c:2626)

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[mathieu.malaterre at gmail dot com]

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

--- Comment #17 from Mathieu Malaterre  ---
Here is what I did over here:

# debootstrap --arch amd64 sid /srv/chroot/sid-amd64
http://httpredir.debian.org/debian
# mount -t proc proc /srv/chroot/sid-amd64/proc
# chroot /srv/chroot/sid-amd64 apt install g++-mingw-w64-i686

Then (https://wiki.debian.org/AutomaticDebugPackages):

# apt install g++-mingw-w64-i686-dbgsym

And eventually ran valgrind on both:

# valgrind --trace-children=yes i686-w64-mingw32-g++ -c -std=c++17 -O2
-Wnonnull -Woverloaded-virtual -v tmp1/16795.cpp -o warn.o >& /tmp/ok
# valgrind --trace-children=yes i686-w64-mingw32-g++ -c -std=c++17 -O2
-Wnonnull -Woverloaded-virtual -v 16795.cpp -o warn.o >& /tmp/notok

The valgrind output seems rather different, so I suspect the issue is indeed an
invalid read/write which should be somewhere in the diff of ok vs notok.

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[vz-gcc at zeitlins dot org]

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

--- Comment #16 from Vadim Zeitlin  ---
(In reply to Alexander Monakov from comment #13)
> It corresponds to
> 
> if(!(!std::signbit(bourn_cast( From(0) {
> lmi_test::record_error(); };
> if(!(std::signbit(bourn_cast(-From(0) {
> lmi_test::record_error(); };
> 
> in template instantiation test_floating_conversions.
> Essentially, with -Wnonnull the second condition seems to be folded to truth
> value.

This is reassuring because this pinpoints the problem I had had originally: the
unit test failed because the signbit() check didn't pass. I thought this wasn't
relevant as the difference in the generated code (i.e. "lock addl $0x1,0x4c"
instead of "xor %eax, %eax") didn't seem to be related to it, but apparently it
still is.

And I can also confirm that -Wnonnull is sufficient for the output to change
with the final test case. It wasn't for the original program, but apparently
delta simplified things enough for -Woverloaded-virtual to become unnecessary
at some point (would it be important to find when? If so, I could try doing
this...).

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[mathieu.malaterre at gmail dot com]

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

Mathieu Malaterre  changed:

   What|Removed |Added

 CC||mathieu.malaterre at gmail dot 
com

--- Comment #14 from Mathieu Malaterre  ---
Created attachment 43772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43772=edit
valgrind output (ok)

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[mathieu.malaterre at gmail dot com]

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

--- Comment #15 from Mathieu Malaterre  ---
Created attachment 43773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43773=edit
valgrind output (not ok)

[Bug rtl-optimization/85099] New: [meta-bug] selective scheduling issues

[marxin at gcc dot gnu.org]

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

Bug ID: 85099
   Summary: [meta-bug] selective scheduling issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: abel at gcc dot gnu.org, amonakov at gcc dot gnu.org
  Target Milestone: ---

[Bug fortran/85088] improve diagnostic for bad INTENT declaration ('Invalid character in name at')

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
It seems that there is some inconsistencies between

  /* TODO: Call match_intent_spec from here.  */
  if (gfc_match (" ( in out )") == MATCH_YES)
d = DECL_INOUT;
  else if (gfc_match (" ( in )") == MATCH_YES)
d = DECL_IN;
  else if (gfc_match (" ( out )") == MATCH_YES)
d = DECL_OUT;

and

match
gfc_match_intent (void)
{
  sym_intent intent;

  /* This is not allowed within a BLOCK construct!  */
  if (gfc_current_state () == COMP_BLOCK)
{
  gfc_error ("INTENT is not allowed inside of BLOCK at %C");
  return MATCH_ERROR;
}

  intent = match_intent_spec ();
  if (intent == INTENT_UNKNOWN)
return MATCH_ERROR;

  gfc_clear_attr (_attr);
  current_attr.intent = intent;

  return attr_decl ();
}

and

static sym_intent
match_intent_spec (void)
{

  if (gfc_match (" ( in out )") == MATCH_YES)
return INTENT_INOUT;
  if (gfc_match (" ( in )") == MATCH_YES)
return INTENT_IN;
  if (gfc_match (" ( out )") == MATCH_YES)
return INTENT_OUT;

  gfc_error ("Bad INTENT specification at %C");
  return INTENT_UNKNOWN;
}

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[amonakov at gcc dot gnu.org]

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

--- Comment #13 from Alexander Monakov  ---
> (in the diffs, plus-lines correspond to -Wnonnull added to command line)

No, sorry, it was the other way around. Here's the reverse diff with more
context:

   if (0)
 {
   <;
 }
-  if (0)
-{
-  <;
-}
 }

It corresponds to

if(!(!std::signbit(bourn_cast( From(0) { lmi_test::record_error();
};
if(!(std::signbit(bourn_cast(-From(0) { lmi_test::record_error();
};

in template instantiation test_floating_conversions.
Essentially, with -Wnonnull the second condition seems to be folded to truth
value.

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[jakub at gcc dot gnu.org]

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

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

Untested hack.  With this it works even with -flto.  Though, the rounding
errors because we do 400 multiplications get perhaps way too high even for
-Ofast (the benchmark doesn't care that much except for the first iteration,
but I think it is too much).  So, as an alternative I'll just try to something
different.

[Bug fortran/85088] improve diagnostic for bad INTENT declaration ('Invalid character in name at')

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The block

/* TODO: Call match_intent_spec from here.  */
...

has been introduced at revision r128028, September 2 2007, by Roger Sayle, see

https://gcc.gnu.org/ml/fortran/2007-08/msg00655.html

[Bug libstdc++/83860] [6/7/8 Regression] valarray replacement type breaks with auto and more than one operation

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  Works with GCC 5

Well, it doesn't segfault, but ASan still shows the problem:



ASAN:SIGSEGV
=
==8343==ERROR: AddressSanitizer: SEGV on unknown address 0x0018 (pc
0x004017e9 bp 0x7ffc01d53a90 sp 0x7ffc01d53a80 T0)
#0 0x4017e8 in std::valarray::operator[](unsigned long) const
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/valarray:571
#1 0x401792 in std::_BinBase::operator[](unsigned long) const
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/bits/valarray_before.h:534
#2 0x4016b5 in std::_BinBase, std::valarray
>::operator[](unsigned long) const
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/bits/valarray_before.h:534
#3 0x4015ea in std::_Expr, int>, int>::operator[](unsigned long) const
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/bits/valarray_after.h:216
#4 0x4013fd in void std::__valarray_copy_construct, int>
>(std::_Expr, int>,
int> const&, unsigned long, std::_Array)
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/bits/valarray_array.tcc:219
#5 0x4011a9 in std::valarray::valarray, int> >(std::_Expr, int>, int> const&)
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/valarray:696
#6 0x400d1c in main /tmp/val.cc:6
#7 0x7f025472a889 in __libc_start_main (/lib64/libc.so.6+0x20889)
#8 0x400ae9 in _start (/tmp/val5+0x400ae9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/valarray:571
std::valarray::operator[](unsigned long) const
==8343==ABORTING


The root cause is that binary operators for valarray return expression
templates that have reference semantics, not value semantics. The result of
va+vb+vc refers to a temporary object that goes out of scope at the end of the
full expression. When that result is stored in a valarray it works OK:

  std::valarray sum = va + vb + vc;

but when you use 'auto' you get an object of the expression template type,
which holds a dangling reference to an expired temporary.

Solution: Don't use 'auto' with expression templates.

I'll see if there's anything the library can do to make this less error-prone.

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
The problem lies in:

(insn 4214 4213 4219 2 (parallel [
(set (subreg:DI (reg:V32HI 4037 [ i ]) 0)
(ior:DI (reg:DI 4040)
(reg:DI 4038 [ _7 ])))
(clobber (reg:CC 17 flags))
]) "pr85090.c":13 442 {*iordi_1}
 (expr_list:REG_DEAD (reg:DI 4040)
(expr_list:REG_DEAD (reg:DI 4038 [ _7 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

(insn 4219 4214 4220 2 (set (reg/i:V32HI 21 xmm0)
(reg:V32HI 4037 [ i ])) "pr85090.c":16 1254 {movv32hi_internal}
 (expr_list:REG_DEAD (reg:V32HI 4037 [ i ])

where (insn 4214) reloads with:

(insn 4214 4213 5658 2 (parallel [
(set (reg:DI 0 ax [4040])
(ior:DI (reg:DI 0 ax [4040])
(reg:DI 1 dx [orig:4038 _7 ] [4038])))
(clobber (reg:CC 17 flags))
]) "pr85090.c":13 442 {*iordi_1}
 (nil))
(insn 5658 4214 5812 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 264 [0x108])) [4 %sfp+-64 S8 A512])
(reg:DI 0 ax [4040])) "pr85090.c":13 85 {*movdi_internal}
 (nil))
(insn 5812 5658 4219 2 (set (reg:DI 57 xmm20 [orig:422 i ] [422])
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 264 [0x108])) [4 %sfp+-64 S8 A512])) "pr85090.c":13
85 {*movdi_internal}
 (nil))
(insn 4219 5812 4220 2 (set (reg/i:V32HI 21 xmm0)
(reg/v:V32HI 57 xmm20 [orig:422 i ] [422])) "pr85090.c":16 1254
{movv32hi_internal}
 (nil))

Using a subreg is not enough to change only part of the register.

[Bug c++/85068] [6/7 Regression] ICE with invalid covariant return type hierarchy

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |invalid covariant return|invalid covariant return
   |type hierarchy  |type hierarchy

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/85097] ICE in double parameter pack

[boldizsar.palotas at gmail dot com]

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

--- Comment #2 from Boldizsár Palotás  ---
More specifically, this seems to fail on every version of GCC that supports
"-std=c++11" -- since 4.7.1, based on testing on Compiler Explorer. It is
compiled (I assume correctly) by Clang and MSVC.

A simplified version of the code is below:
template 
struct X {};

template  // Note the omitted bogus typename parameter
struct S
{
template 
void function(X...)
{ }
};

void test_case() {
S s; // Note the omitted void parameter
s.function(X());
}

This seems to fail in the same situations, but instead of ICE, it gives the
following error:
: In function 'void test_case()':
:14:31: error: no matching function for call to
'S::function(X)'
 s.function(X());
   ^
:8:10: note: candidate: template void
S::function(X...) [with TInner = {TInner ...}; TOuter =
{int}]
 void function(X...)
  ^~~~
:8:10: note:   template argument deduction/substitution failed:
:14:31: note:   mismatched types 'TInner' and 'short int'
 s.function(X());
   ^

The examples above can be checked here: https://godbolt.org/g/dNkjSk
This could be a duplicate of #84796 or #77731

[Bug libstdc++/85098] New: undefined reference to std::regex::extended

[john.salmon at deshaw dot com]

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

Bug ID: 85098
   Summary: undefined reference to std::regex::extended
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.salmon at deshaw dot com
  Target Milestone: ---

When I compile with -std=c++11 or -std=c++14 and with -O0, I get this undefined
reference.  With -std=c++17, there's no problem.  With -O1 and higher, there's
no problem.  Note that with -std=c++14 and 17, 'mu' is just plain-old
std::make_unique.  To demonstrate the problem with -std=c++11, I had to define
"my own" make_unique.

drdws0134$ cat foo.cpp
#include 
#include 

#if __cplusplus >= 201402L
#define mu std::make_unique
#else
template 
std::unique_ptr mu(Args&& ... args){
return std::unique_ptr(new T(std::forward(args)...));
}
#endif

auto re = mu("hello", std::regex::extended);

int main(int, char **){
return 0;
}

drdws0134$ 
drdws0134$ garden with -m gcc/7.3.0-01c7/bin g++ -std=c++11 -O0 foo.cpp
/tmp/ccJeBOid.o: In function `__static_initialization_and_destruction_0(int,
int)':
foo.cpp:(.text+0xd9): undefined reference to `std::__cxx11::basic_regex::extended'
collect2: error: ld returned 1 exit status
drdws0134$ garden with -m gcc/7.3.0-01c7/bin g++ -std=c++14 -O0 foo.cpp
/tmp/cc2NKXJx.o: In function `__static_initialization_and_destruction_0(int,
int)':
foo.cpp:(.text+0xd9): undefined reference to `std::__cxx11::basic_regex::extended'
collect2: error: ld returned 1 exit status
drdws0134$ garden with -m gcc/7.3.0-01c7/bin g++ -std=c++17 -O0 foo.cpp
drdws0134$

[Bug testsuite/83462] [8 regression] c-c++-common/Warray-bounds-3.c fails on arm-none-eabi

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Sebor  ---
I plan to fix the underlying problem (pr83543) for GCC 9.  Until then, the only
way to avoid the test failures at this stage is to disable or xfail the tests
for the affected targets.

[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not

[amonakov at gcc dot gnu.org]

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

--- Comment #12 from Alexander Monakov  ---
I can reproduce it with downloaded Debian's cc1plus, and for me -Wnonnull alone
is sufficient to cause diverging codegen. It diverges very early, in the
frontend: diff of .tu dumps starts with:

--- a/1/16795.cpp.001t.tu
+++ b/2/16795.cpp.001t.tu
@@ -110354,336 +110354,337 @@
 @56158  bind_exprtype: @27  body: @59125
 @56159  cond_exprtype: @27  op 0: @5106op 1: @59126
  op 2: @59127
-@56160  cleanup_point_expr type: @27  op 0: @59128
-@56161  convert_expr type: @27  op 0: @59129
-@56162  call_exprtype: @109 fn  : @59130   0   : @59131
- 1   : @59132
-@56163  expr_stmttype: @27  line: 732  expr: @59133
-@56164  cleanup_point_expr type: @109 op 0: @59134
+@56160  cond_exprtype: @27  op 0: @5106op 1: @59128
+ op 2: @59129
+@56161  convert_expr type: @27  op 0: @59130
+@56162  call_exprtype: @109 fn  : @59131   0   : @59132
+ 1   : @59133
+@56163  expr_stmttype: @27  line: 732  expr: @59134
+@56164  cleanup_point_expr type: @109 op 0: @59135

and .original diff has the following hunk:

@@ -17695,8 +17695,11 @@ return  = __out;
   <;
 }
-  <;
+}
 }


(in the diffs, plus-lines correspond to -Wnonnull added to command line)

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jakub at redhat dot com,
   ||ubizjak at gmail dot com
   Target Milestone|--- |8.0

[Bug rtl-optimization/85096] [6/7/8 Regression] Unnecessary(?) MOV instructions for int128 addition

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-27
 CC||jakub at gcc dot gnu.org
  Component|c   |rtl-optimization
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Maybe related to PR84757.

[Bug c++/85097] ICE in double parameter pack

[boldizsar.palotas at gmail dot com]

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

Boldizsár Palotás  changed:

   What|Removed |Added

Summary|ICE in doub |ICE in double parameter
   ||pack

--- Comment #1 from Boldizsár Palotás  ---
// Code
template 
struct X {};

template 
struct S
{
template 
void function(X...)
{ }
};

void test_case() {
S s;
s.function(X());
}

// Reported error with -std=c++11 -Wall -Wextra -Wpedantic
: In substitution of 'template void S::function(X...) [with TInner = ]':
:14:31:   required from here
:14:31: internal compiler error: tree check: accessed elt 2 of tree_vec
with 1 elts in unify, at cp/pt.c:21107
 s.function(X());
   ^
mmap: Invalid argument
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler returned: 1

[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Hmm, I don't have access to AVX512F hardware so I can't reproduce the runtime
failure.
The vector simplifications that my patch introduces look correct to me from
looking at the dumps.

I'm not very familiar with i386.md but the *movdi_internal pattern that
produces the vmovq that zeroes out the top of the z register doesn't seem to
represent that in RTL.

So GCC ends up loading a DImode register xmm20 but then stores it as a
V32HImode register, the zero-extending effects of the DImode load are not
represented at RTL.

Any ideas?

[Bug target/85095] [6/7/8 Regression] worse code generated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-27
 CC||jakub at gcc dot gnu.org
  Component|ipa |target
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
That is much more likely r230856 than Honza's change actually.
I'll have a look.

[Bug c++/85097] New: ICE in doub

[boldizsar.palotas at gmail dot com]

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

Bug ID: 85097
   Summary: ICE in doub
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boldizsar.palotas at gmail dot com
  Target Milestone: ---

[Bug c/85096] [6/7/8 Regression] Unnecessary(?) MOV instructions for int128 addition

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.8.5
  Known to fail||4.9.4, 5.5.0, 6.3.0, 7.3.0,
   ||8.0.1

--- Comment #1 from Jonathan Wakely  ---
This regressed with r204212

commit 284f069678f0b28c57e62b5da9b6dfed77d4d700
Author: vmakarov 
Date:   Wed Oct 30 14:27:25 2013 +

2013-10-30  Vladimir Makarov  

* regmove.c: Remove.
* tree-pass.h (make_pass_regmove): Remove.
* timevar.def (TV_REGMOVE): Remove.
* passes.def (pass_regmove): Remove.
* opts.c (default_options_table): Remove entry for regmove.
* doc/passes.texi: Remove regmove pass description.
* doc/invoke.texi (-foptimize-register-move, -fregmove): Remove
options.
(-fdump-rtl-regmove): Ditto.
* common.opt (foptimize-register-move, fregmove): Ignore.
* Makefile.in (OBJS): Remove regmove.o.
* regmove.c: Remove.
* ira-int.h (struct ira_allocno_pref, ira_pref_t): New structure
and type.
(struct ira_allocno) New member allocno_prefs.
(ALLOCNO_PREFS): New macro.
(ira_prefs, ira_prefs_num): New external vars.
(ira_setup_alts, ira_get_dup_out_num, ira_debug_pref): New
prototypes.
(ira_debug_prefs, ira_debug_allocno_prefs, ira_create_pref):
Ditto.
(ira_add_allocno_pref, ira_remove_pref, ira_remove_allocno_prefs):
Ditto.
(ira_add_allocno_copy_to_list): Remove prototype.
(ira_swap_allocno_copy_ends_if_necessary): Ditto.
(ira_pref_iterator): New type.
(ira_pref_iter_init, ira_pref_iter_cond): New functions.
(FOR_EACH_PREF): New macro.
* ira.c (commutative_constraint_p): Move from ira-conflicts.c.
(ira_get_dup_out_num): Ditto. Rename from get_dup_num.  Modify the
code.
(ira_setup_alts): New function.
(decrease_live_ranges_number): New function.
(ira): Call the above function.
* ira-build.c (ira_prefs, ira_prefs_num): New global vars.
(ira_create_allocno): Initialize allocno prefs.
(pref_pool, pref_vec): New static vars.
(initiate_prefs, find_allocno_pref, ira_create_pref): New
functions.
(add_allocno_pref_to_list, ira_add_allocno_pref, print_pref):
Ditto.
(ira_debug_pref, print_prefs, ira_debug_prefs): Ditto.
(print_allocno_prefs, ira_debug_allocno_prefs, finish_pref): Ditto.
(ira_remove_pref, ira_remove_allocno_prefs, finish_prefs): Ditto.
(ira_add_allocno_copy_to_list): Make static.  Rename to
add_allocno_copy_to_list.
(ira_swap_allocno_copy_ends_if_necessary): Make static.  Rename to
swap_allocno_copy_ends_if_necessary.
(remove_unnecessary_allocnos, remove_low_level_allocnos): Call
ira_remove_allocno_prefs.
(ira_flattening): Ditto.
(ira_build): Call initiate_prefs, print_prefs.
(ira_destroy): Call finish_prefs.
* ira-color.c (struct update_cost_record): New.
(struct allocno_color_data): Add new member update_cost_records.
(update_cost_record_pool): New static var.
(init_update_cost_records, get_update_cost_record): New functions.
(free_update_cost_record_list, finish_update_cost_records): Ditto.
(struct update_cost_queue_elem): Add member from.
(initiate_cost_update): Call init_update_cost_records.
(finish_cost_update): Call finish_update_cost_records.
(queue_update_cost, get_next_update_cost): Add new param from.
(Update_allocno_cost, update_costs_from_allocno): New functions.
(update_costs_from_prefs): Ditto.
(update_copy_costs): Rename to update_costs_from_copies.
(restore_costs_from_copies): New function.
(update_conflict_hard_regno_costs): Don't go back.
(assign_hard_reg): Call restore_costs_from_copies.  Add printing
more debug info.
(pop_allocnos): Add priniting more debug info.
(color_allocnos): Remove prefs for conflicting hard regs.
Call update_costs_from_prefs.
* ira-conflicts.c (commutative_constraint_p): Move to ira.c
(get_dup_num): Rename, modify, and move to ira.c
(process_regs_for_copy): Add prefs.
(add_insn_allocno_copies): Put src as first arg of
process_regs_for_copy.  Remove dead 

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Actually it appears that the IVOPTS change results in worse code going into
SMS, regardless of whether SMS can succeed on the loop.  It comes down to the
fact that IVOPTS formerly pulled a multiply (left-shift) out of the loop, but
now the multiply remains in the loop.

After all the do_loop work and so forth, we end up with the following going
into SMS.  The r247884 loop is on the left, r247885 on the right:

lab27:lab20:
  r162, ca = r162 >> 1  r157, ca = r157 >> 1
  r169 = r162 << 3  r163 = r157 << 3
r166 = (r160 << 3) & 0xfff8
  r171 = r177 + r164r167 = r172 + r166
  *(r177 + r169) = r171 *(r172 + r163) = r167
  r174 = (SI)r164 + 32  r169 = (SI)r160 + 4
  r164 = zext(r174) r164 = sext(r169)
  bdnz r178, lab27  bdnz r173, lab20

The loss of hoisting of the multiply/shift shows up in the optimized and vregs
dumps as well; RTL optimizations aren't able to recover from this.

So I think this still comes down to an unfortunate choice made in IVOPTS.

[Bug c/85096] New: [6/7/8 Regression] Unnecessary(?) MOV instructions for int128 addition

[redi at gcc dot gnu.org]

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

Bug ID: 85096
   Summary: [6/7/8 Regression] Unnecessary(?) MOV instructions for
int128 addition
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: uros at gcc dot gnu.org, vmakarov at gcc dot gnu.org
  Target Milestone: ---

__uint128_t add128(__uint128_t a, __uint128_t b) {
  return a + b;
}

GCC with -O3 produces:

mov r9, rdi   # a, a
mov r10, rsi  # a, a
add r9, rdx   # a, b
adc r10, rcx  # a, b
mov rax, r9   # tmp93, a
mov rdx, r10  #, a
ret

GCC 4.8.5 produced:

mov rax, rdx  # D.1732, b
mov rdx, rcx  # D.1732, b
add rax, rdi  # D.1732, a
adc rdx, rsi  # D.1732, a
ret

Clang produces:

add rdi, rdx
adc rsi, rcx
mov rax, rdi
mov rdx, rsi
ret

and ICC:

  add rdi, rdx #3.14
  mov rax, rdi #3.14
  adc rsi, rcx #3.14
  mov rdx, rsi #3.14
  ret #3.14


I don't know which component this should be, but Jakub suggested to CC Vlad and
Uros, so maybe one of you can re-assign it to the right component.