[Bug other/44803] LIBRARY_PATH should work on cross-compilers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-06-02
 Ever confirmed|0   |1

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Felipe Contreras from comment #3)
> > Is this not clear?
> > 
> > It would be useful to cross-compile like this:
> > 
> > export C_INCLUDE_PATH=/opt/arm/ffmpeg/include
> > export LIBRARY_PATH=/opt/arm/ffmpeg/lib
> > 
> > But LIBRARY_PATH is ignored.
> 
> this bug showed up in my Assignee_but_not_ASSIGNED saved search. Are you
> still working on this?

WAITING on a reply

[Bug tree-optimization/33915] iv folding fails with pointer iterations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-06-02
 Ever confirmed|0   |1

--- Comment #10 from Eric Gallager  ---
(In reply to Eric Gallager from comment #9)
> (In reply to Zdenek Dvorak from comment #3)
> > It does not reproduce for me on i686-linux, either.  Do you pass any special
> > flags to configure?
> 
> If it didn't reproduce for you does it make sense for you still to be the
> assignee for this?

WAITING on a reply

[Bug c++/85764] [8/9 Regression] bogus ‘this’ was not captured for this lambda function error

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Sat Jun  2 03:14:44 2018
New Revision: 261101

URL: https://gcc.gnu.org/viewcvs?rev=261101=gcc=rev
Log:
PR c++/85764 - bogus 'this' not captured error.

* lambda.c (resolvable_dummy_lambda): Use nonlambda_method_basetype.
(nonlambda_method_basetype): Handle NSDMI.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-this2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c

[Bug c/86026] Document and/or change allowed operations on integer representation of pointers

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #4 from Rich Felker  ---
I am strongly in favor of Alexander Monakov's proposal.

[Bug libfortran/85975] Incorrect size for spread array

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |8.2

[Bug fortran/85816] [8/9 Regression] nested spread fails with "Integer overflow in xmallocarray"

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk and 8-branch.  Thanks for the bug report.

[Bug libfortran/85975] Incorrect size for spread array

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk and 8-branch.  Thanks for the bug report and the analysis.

[Bug fortran/85816] [8/9 Regression] nested spread fails with "Integer overflow in xmallocarray"

[kargl at gcc dot gnu.org]

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

Bug 85975 Summary: Incorrect size for spread array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85975

   What|Removed |Added

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

[Bug fortran/85816] [8/9 Regression] nested spread fails with "Integer overflow in xmallocarray"

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Jun  2 01:07:46 2018
New Revision: 261099

URL: https://gcc.gnu.org/viewcvs?rev=261099=gcc=rev
Log:
2018-06-01  Steven G. Kargl  

PR fortran/85816
PR fortran/85975
Backport from trunk
* libgfortran.h: Remove the GFC_DTYPE_COPY_SETRANK macro.
* m4/iforeach-s.m4: Directly set rank.
* m4/iforeach.m4: Ditto.
* m4/ifunction-s.m4: Ditto.
* m4/ifunction-s2.m4: Ditto.
* m4/ifunction.m4: Ditto.
* m4/ifunction_logical.m4: Ditto.
* m4/reshape.m4: Ditto.
* m4/spread.m4: Ditto.
* generated/all_l1.c: Regenerated.
* generated/all_l16.c: Ditto.
* generated/all_l2.c: Ditto.
* generated/all_l4.c: Ditto.
* generated/all_l8.c: Ditto.
* generated/any_l1.c: Ditto.
* generated/any_l16.c: Ditto.
* generated/any_l2.c: Ditto.
* generated/any_l4.c: Ditto.
* generated/any_l8.c: Ditto.
* generated/count_16_l.c: Ditto.
* generated/count_1_l.c: Ditto.
* generated/count_2_l.c: Ditto.
* generated/count_4_l.c: Ditto.
* generated/count_8_l.c: Ditto.
* generated/iall_i1.c: Ditto.
* generated/iall_i16.c: Ditto.
* generated/iall_i2.c: Ditto.
* generated/iall_i4.c: Ditto.
* generated/iall_i8.c: Ditto.
* generated/iany_i1.c: Ditto.
* generated/iany_i16.c: Ditto.
* generated/iany_i2.c: Ditto.
* generated/iany_i4.c: Ditto.
* generated/iany_i8.c: Ditto.
* generated/iparity_i1.c: Ditto.
* generated/iparity_i16.c: Ditto.
* generated/iparity_i2.c: Ditto.
* generated/iparity_i4.c: Ditto.
* generated/iparity_i8.c: Ditto.
* generated/maxloc0_16_i1.c: Ditto.
* generated/maxloc0_16_i16.c: Ditto.
* generated/maxloc0_16_i2.c: Ditto.
* generated/maxloc0_16_i4.c: Ditto.
* generated/maxloc0_16_i8.c: Ditto.
* generated/maxloc0_16_r10.c: Ditto.
* generated/maxloc0_16_r16.c: Ditto.
* generated/maxloc0_16_r4.c: Ditto.
* generated/maxloc0_16_r8.c: Ditto.
* generated/maxloc0_16_s1.c: Ditto.
* generated/maxloc0_16_s4.c: Ditto.
* generated/maxloc0_4_i1.c: Ditto.
* generated/maxloc0_4_i16.c: Ditto.
* generated/maxloc0_4_i2.c: Ditto.
* generated/maxloc0_4_i4.c: Ditto.
* generated/maxloc0_4_i8.c: Ditto.
* generated/maxloc0_4_r10.c: Ditto.
* generated/maxloc0_4_r16.c: Ditto.
* generated/maxloc0_4_r4.c: Ditto.
* generated/maxloc0_4_r8.c: Ditto.
* generated/maxloc0_4_s1.c: Ditto.
* generated/maxloc0_4_s4.c: Ditto.
* generated/maxloc0_8_i1.c: Ditto.
* generated/maxloc0_8_i16.c: Ditto.
* generated/maxloc0_8_i2.c: Ditto.
* generated/maxloc0_8_i4.c: Ditto.
* generated/maxloc0_8_i8.c: Ditto.
* generated/maxloc0_8_r10.c: Ditto.
* generated/maxloc0_8_r16.c: Ditto.
* generated/maxloc0_8_r4.c: Ditto.
* generated/maxloc0_8_r8.c: Ditto.
* generated/maxloc0_8_s1.c: Ditto.
* generated/maxloc0_8_s4.c: Ditto.
* generated/maxloc1_16_i1.c: Ditto.
* generated/maxloc1_16_i16.c: Ditto.
* generated/maxloc1_16_i2.c: Ditto.
* generated/maxloc1_16_i4.c: Ditto.
* generated/maxloc1_16_i8.c: Ditto.
* generated/maxloc1_16_r10.c: Ditto.
* generated/maxloc1_16_r16.c: Ditto.
* generated/maxloc1_16_r4.c: Ditto.
* generated/maxloc1_16_r8.c: Ditto.
* generated/maxloc1_16_s1.c: Ditto.
* generated/maxloc1_16_s4.c: Ditto.
* generated/maxloc1_4_i1.c: Ditto.
* generated/maxloc1_4_i16.c: Ditto.
* generated/maxloc1_4_i2.c: Ditto.
* generated/maxloc1_4_i4.c: Ditto.
* generated/maxloc1_4_i8.c: Ditto.
* generated/maxloc1_4_r10.c: Ditto.
* generated/maxloc1_4_r16.c: Ditto.
* generated/maxloc1_4_r4.c: Ditto.
* generated/maxloc1_4_r8.c: Ditto.
* generated/maxloc1_4_s1.c: Ditto.
* generated/maxloc1_4_s4.c: Ditto.
* generated/maxloc1_8_i1.c: Ditto.
* generated/maxloc1_8_i16.c: Ditto.
* generated/maxloc1_8_i2.c: Ditto.
* generated/maxloc1_8_i4.c: Ditto.
* generated/maxloc1_8_i8.c: Ditto.
* generated/maxloc1_8_r10.c: Ditto.
* generated/maxloc1_8_r16.c: Ditto.
* generated/maxloc1_8_r4.c: Ditto.
* generated/maxloc1_8_r8.c: Ditto.
* generated/maxloc1_8_s1.c: Ditto.
* generated/maxloc1_8_s4.c: Ditto.
* generated/maxval1_s1.c: Ditto.
* generated/maxval1_s4.c: Ditto.
* generated/maxval_i1.c: Ditto.
* generated/maxval_i16.c: Ditto.
* generated/maxval_i2.c: Ditto.
* generated/maxval_i4.c: Ditto.
* 

[Bug libfortran/85975] Incorrect size for spread array

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Jun  2 01:07:46 2018
New Revision: 261099

URL: https://gcc.gnu.org/viewcvs?rev=261099=gcc=rev
Log:
2018-06-01  Steven G. Kargl  

PR fortran/85816
PR fortran/85975
Backport from trunk
* libgfortran.h: Remove the GFC_DTYPE_COPY_SETRANK macro.
* m4/iforeach-s.m4: Directly set rank.
* m4/iforeach.m4: Ditto.
* m4/ifunction-s.m4: Ditto.
* m4/ifunction-s2.m4: Ditto.
* m4/ifunction.m4: Ditto.
* m4/ifunction_logical.m4: Ditto.
* m4/reshape.m4: Ditto.
* m4/spread.m4: Ditto.
* generated/all_l1.c: Regenerated.
* generated/all_l16.c: Ditto.
* generated/all_l2.c: Ditto.
* generated/all_l4.c: Ditto.
* generated/all_l8.c: Ditto.
* generated/any_l1.c: Ditto.
* generated/any_l16.c: Ditto.
* generated/any_l2.c: Ditto.
* generated/any_l4.c: Ditto.
* generated/any_l8.c: Ditto.
* generated/count_16_l.c: Ditto.
* generated/count_1_l.c: Ditto.
* generated/count_2_l.c: Ditto.
* generated/count_4_l.c: Ditto.
* generated/count_8_l.c: Ditto.
* generated/iall_i1.c: Ditto.
* generated/iall_i16.c: Ditto.
* generated/iall_i2.c: Ditto.
* generated/iall_i4.c: Ditto.
* generated/iall_i8.c: Ditto.
* generated/iany_i1.c: Ditto.
* generated/iany_i16.c: Ditto.
* generated/iany_i2.c: Ditto.
* generated/iany_i4.c: Ditto.
* generated/iany_i8.c: Ditto.
* generated/iparity_i1.c: Ditto.
* generated/iparity_i16.c: Ditto.
* generated/iparity_i2.c: Ditto.
* generated/iparity_i4.c: Ditto.
* generated/iparity_i8.c: Ditto.
* generated/maxloc0_16_i1.c: Ditto.
* generated/maxloc0_16_i16.c: Ditto.
* generated/maxloc0_16_i2.c: Ditto.
* generated/maxloc0_16_i4.c: Ditto.
* generated/maxloc0_16_i8.c: Ditto.
* generated/maxloc0_16_r10.c: Ditto.
* generated/maxloc0_16_r16.c: Ditto.
* generated/maxloc0_16_r4.c: Ditto.
* generated/maxloc0_16_r8.c: Ditto.
* generated/maxloc0_16_s1.c: Ditto.
* generated/maxloc0_16_s4.c: Ditto.
* generated/maxloc0_4_i1.c: Ditto.
* generated/maxloc0_4_i16.c: Ditto.
* generated/maxloc0_4_i2.c: Ditto.
* generated/maxloc0_4_i4.c: Ditto.
* generated/maxloc0_4_i8.c: Ditto.
* generated/maxloc0_4_r10.c: Ditto.
* generated/maxloc0_4_r16.c: Ditto.
* generated/maxloc0_4_r4.c: Ditto.
* generated/maxloc0_4_r8.c: Ditto.
* generated/maxloc0_4_s1.c: Ditto.
* generated/maxloc0_4_s4.c: Ditto.
* generated/maxloc0_8_i1.c: Ditto.
* generated/maxloc0_8_i16.c: Ditto.
* generated/maxloc0_8_i2.c: Ditto.
* generated/maxloc0_8_i4.c: Ditto.
* generated/maxloc0_8_i8.c: Ditto.
* generated/maxloc0_8_r10.c: Ditto.
* generated/maxloc0_8_r16.c: Ditto.
* generated/maxloc0_8_r4.c: Ditto.
* generated/maxloc0_8_r8.c: Ditto.
* generated/maxloc0_8_s1.c: Ditto.
* generated/maxloc0_8_s4.c: Ditto.
* generated/maxloc1_16_i1.c: Ditto.
* generated/maxloc1_16_i16.c: Ditto.
* generated/maxloc1_16_i2.c: Ditto.
* generated/maxloc1_16_i4.c: Ditto.
* generated/maxloc1_16_i8.c: Ditto.
* generated/maxloc1_16_r10.c: Ditto.
* generated/maxloc1_16_r16.c: Ditto.
* generated/maxloc1_16_r4.c: Ditto.
* generated/maxloc1_16_r8.c: Ditto.
* generated/maxloc1_16_s1.c: Ditto.
* generated/maxloc1_16_s4.c: Ditto.
* generated/maxloc1_4_i1.c: Ditto.
* generated/maxloc1_4_i16.c: Ditto.
* generated/maxloc1_4_i2.c: Ditto.
* generated/maxloc1_4_i4.c: Ditto.
* generated/maxloc1_4_i8.c: Ditto.
* generated/maxloc1_4_r10.c: Ditto.
* generated/maxloc1_4_r16.c: Ditto.
* generated/maxloc1_4_r4.c: Ditto.
* generated/maxloc1_4_r8.c: Ditto.
* generated/maxloc1_4_s1.c: Ditto.
* generated/maxloc1_4_s4.c: Ditto.
* generated/maxloc1_8_i1.c: Ditto.
* generated/maxloc1_8_i16.c: Ditto.
* generated/maxloc1_8_i2.c: Ditto.
* generated/maxloc1_8_i4.c: Ditto.
* generated/maxloc1_8_i8.c: Ditto.
* generated/maxloc1_8_r10.c: Ditto.
* generated/maxloc1_8_r16.c: Ditto.
* generated/maxloc1_8_r4.c: Ditto.
* generated/maxloc1_8_r8.c: Ditto.
* generated/maxloc1_8_s1.c: Ditto.
* generated/maxloc1_8_s4.c: Ditto.
* generated/maxval1_s1.c: Ditto.
* generated/maxval1_s4.c: Ditto.
* generated/maxval_i1.c: Ditto.
* generated/maxval_i16.c: Ditto.
* generated/maxval_i2.c: Ditto.
* generated/maxval_i4.c: Ditto.
* 

[Bug c++/85764] [8/9 Regression] bogus ‘this’ was not captured for this lambda function error

[jason at gcc dot gnu.org]

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

Paolo Carlini  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-29
 Ever confirmed|0   |1

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/85995] GCC defines __STDC__ and __STDC_VERSION__ even when used with options that break C conformance

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
On Fri, 1 Jun 2018, vincent-gcc at vinc17 dot net wrote:

>  Programmers normally use conditionals on '__STDC__' to ask whether
>  it is safe to use certain features of ISO C, such as function
>  prototypes or ISO token concatenation.
> 
> Precisely this is what I wish to do, with 2 versions of a macro: one that
> assumes C conformance (requiring -fexcess-precision=standard with GCC, in
> particular), and another one that doesn't but may be slower.

The typical features people want to test are ones for which __STDC__ gives 
the correct answer.  Likewise if they use __STDC_VERSION__ with a view to 
testing for support for VLAs or compound literals, for example.

You can test for a conformance mode by testing __STRICT_ANSI__ (though 
someone can still use -f options affecting conformance together with a 
-std option that enables a conformance mode).  You can also test 
__GCC_IEC_559 > 0 if you wish to test that no options have been used that 
specifically disable IEEE 754 floating-point features and that 
floating-point exceptions and rounding modes are supported as far as GCC 
knows (the precise rules for __GCC_IEC_559 depend on whether an option 
such as -std=c11 is used as well).

[Bug c++/67711] Memory corruption when reassigning value to initializer_list

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|wrong-code  |diagnostic
 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #3 from Jason Merrill  ---
GCC 9 will warn about this undefined code.

[Bug c++/85873] [8/9 regression] GCC omits array constant in .rodata causing a segmentation fault.

[jason at gcc dot gnu.org]

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

Bug 67445 Summary: New warning: returning std::initializer_list bound to 
temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67445

   What|Removed |Added

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

[Bug c++/67445] New warning: returning std::initializer_list bound to temporary

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #3 from Jason Merrill  ---
Implemented for GCC 9.

[Bug c++/85873] [8/9 regression] GCC omits array constant in .rodata causing a segmentation fault.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 8.2.

[Bug c/85995] GCC defines __STDC__ and __STDC_VERSION__ even when used with options that break C conformance

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  ---
(In reply to jos...@codesourcery.com from comment #3)
> See trouble.texi, "Non-bugs" / "Certain Changes We Don't Want to Make", 
> "Undefining @code{__STDC__} when @option{-ansi} is not used."

which answers my request.

 Programmers normally use conditionals on '__STDC__' to ask whether
 it is safe to use certain features of ISO C, such as function
 prototypes or ISO token concatenation.

Precisely this is what I wish to do, with 2 versions of a macro: one that
assumes C conformance (requiring -fexcess-precision=standard with GCC, in
particular), and another one that doesn't but may be slower.

 Since plain 'gcc' supports all the features of ISO C, the correct
 answer to these questions is "yes".

This sentence is wrong by default, as it would imply
-fexcess-precision=standard!

[Bug c++/85873] [8/9 regression] GCC omits array constant in .rodata causing a segmentation fault.

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jun  1 22:48:58 2018
New Revision: 261091

URL: https://gcc.gnu.org/viewcvs?rev=261091=gcc=rev
Log:
PR c++/85873 - constant initializer_list array not in .rodata.

* call.c (convert_like_real): Treat the backing array for an
initializer_list like a C99 compound literal.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-ssa/array-temp1.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/call.c

[Bug target/86011] Inefficient code generated for ldivmod with constant value

[patrick at motec dot com.au]

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

--- Comment #2 from Patrick Oppenlander  ---
Sure,

# cat test.c
struct foo { long a, b; };
struct foo test(long long x)
{
return (struct foo){x / 77, x % 77};
}
# gcc --version
gcc (GCC) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# gcc -c -O2 test.c
# objdump -d test.o

test.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   e92d40d0push{r4, r6, r7, lr}
   4:   e1a06002mov r6, r2
   8:   e1a07003mov r7, r3
   c:   e1a04000mov r4, r0
  10:   e3a0204dmov r2, #77 ; 0x4d
  14:   e3a03000mov r3, #0
  18:   e1a6mov r0, r6
  1c:   e1a01007mov r1, r7
  20:   ebfebl  0 <__aeabi_ldivmod>
  24:   e1a01007mov r1, r7
  28:   e3a0204dmov r2, #77 ; 0x4d
  2c:   e3a03000mov r3, #0
  30:   e584str r0, [r4]
  34:   e1a6mov r0, r6
  38:   ebfebl  0 <__aeabi_ldivmod>
  3c:   e1a4mov r0, r4
  40:   e5842004str r2, [r4, #4]
  44:   e8bd80d0pop {r4, r6, r7, pc}

Looks like the same problem is still there.

[Bug tree-optimization/86029] gcc -O3 make very slow product

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Tavian Barnes from comment #1)
> Maybe a dupe of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70291?  In the
> -O3 version, __mulsc3() dominates the profile.
> 
>│ for(int i=0; i<=decimate_taps_length; i++) decim +=
> samplebuf[i] * decimate_taps[i];
>   0.20 │430:┌─→vmovss 0x4(%r13,%rbx,1),%xmm1
>   3.63 ││  vmovss 0x0(%r13,%rbx,1),%xmm0
>  12.35 ││  vmovss 0x4(%r12,%rbx,1),%xmm3
>   0.31 ││  vmovss (%r12,%rbx,1),%xmm2
>   0.02 ││  add$0x8,%rbx
>  36.48 ││→ callq  __mulsc3
>   0.01 ││  vmovss -0x78(%rbp),%xmm6
>   0.00 ││  vmovss -0x80(%rbp),%xmm4
>  23.70 ││  vmovq  %xmm0,-0x68(%rbp)
>  14.25 ││  vaddss -0x68(%rbp),%xmm6,%xmm5
>   1.54 ││  vaddss -0x64(%rbp),%xmm4,%xmm7
>   0.48 ││  vmovss %xmm5,-0x78(%rbp)
>   5.92 ││  vmovss %xmm7,-0x80(%rbp)
>│├──cmp$0x2590,%rbx
>   0.01 │└──jne430
> 
> At -Ofast,
> 
>│ for(int i=0; i<=decimate_taps_length; i++) decim +=
> samplebuf[i] * decimate_taps[i];
>   9.36 │5e0:   vpermilps $0xf5,(%r12,%rax,1),%ymm0
>  15.56 │   vpermilps $0xa0,(%r12,%rax,1),%ymm1
>  11.24 │   vmulps (%rbx,%rax,1),%ymm0,%ymm0
>  17.55 │   vpermilps $0xb1,(%rbx,%rax,1),%ymm4
>   3.31 │   add$0x20,%rax
>   2.11 │   vmovaps %ymm1,%ymm3
>   6.62 │   vfmadd132ps %ymm4,%ymm0,%ymm3
>   3.79 │   vfmsub231ps %ymm4,%ymm1,%ymm0
>   2.91 │   vblendps $0xaa,%ymm0,%ymm3,%ymm0
>  10.75 │   vaddps %ymm0,%ymm6,%ymm6
>│   cmp$0x2580,%rax
>   5.59 │ ↑ jne5e0
>   0.01 │   vmovss 0x258c(%rbx),%xmm0
>   0.01 │   vmovss -0x70(%rbp),%xmm7
>   0.01 │   vmovss %xmm5,-0xd0(%rbp)
>   0.05 │   vextractf128 $0x1,%ymm6,%xmm3
>   0.01 │   vmovss 0x2588(%rbx),%xmm8
>   0.03 │   vshufps $0xff,%xmm3,%xmm3,%xmm13

Looks like so. Could you try this out with current trunk?

[Bug tree-optimization/86029] gcc -O3 make very slow product

[tavianator at gmail dot com]

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

Tavian Barnes  changed:

   What|Removed |Added

 CC||tavianator at gmail dot com

--- Comment #1 from Tavian Barnes  ---
Maybe a dupe of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70291?  In the -O3
version, __mulsc3() dominates the profile.

   │ for(int i=0; i<=decimate_taps_length; i++) decim +=
samplebuf[i] * decimate_taps[i];
  0.20 │430:┌─→vmovss 0x4(%r13,%rbx,1),%xmm1
  3.63 ││  vmovss 0x0(%r13,%rbx,1),%xmm0
 12.35 ││  vmovss 0x4(%r12,%rbx,1),%xmm3
  0.31 ││  vmovss (%r12,%rbx,1),%xmm2
  0.02 ││  add$0x8,%rbx
 36.48 ││→ callq  __mulsc3
  0.01 ││  vmovss -0x78(%rbp),%xmm6
  0.00 ││  vmovss -0x80(%rbp),%xmm4
 23.70 ││  vmovq  %xmm0,-0x68(%rbp)
 14.25 ││  vaddss -0x68(%rbp),%xmm6,%xmm5
  1.54 ││  vaddss -0x64(%rbp),%xmm4,%xmm7
  0.48 ││  vmovss %xmm5,-0x78(%rbp)
  5.92 ││  vmovss %xmm7,-0x80(%rbp)
   │├──cmp$0x2590,%rbx
  0.01 │└──jne430

At -Ofast,

   │ for(int i=0; i<=decimate_taps_length; i++) decim +=
samplebuf[i] * decimate_taps[i];
  9.36 │5e0:   vpermilps $0xf5,(%r12,%rax,1),%ymm0
 15.56 │   vpermilps $0xa0,(%r12,%rax,1),%ymm1
 11.24 │   vmulps (%rbx,%rax,1),%ymm0,%ymm0
 17.55 │   vpermilps $0xb1,(%rbx,%rax,1),%ymm4
  3.31 │   add$0x20,%rax
  2.11 │   vmovaps %ymm1,%ymm3
  6.62 │   vfmadd132ps %ymm4,%ymm0,%ymm3
  3.79 │   vfmsub231ps %ymm4,%ymm1,%ymm0
  2.91 │   vblendps $0xaa,%ymm0,%ymm3,%ymm0
 10.75 │   vaddps %ymm0,%ymm6,%ymm6
   │   cmp$0x2580,%rax
  5.59 │ ↑ jne5e0
  0.01 │   vmovss 0x258c(%rbx),%xmm0
  0.01 │   vmovss -0x70(%rbp),%xmm7
  0.01 │   vmovss %xmm5,-0xd0(%rbp)
  0.05 │   vextractf128 $0x1,%ymm6,%xmm3
  0.01 │   vmovss 0x2588(%rbx),%xmm8
  0.03 │   vshufps $0xff,%xmm3,%xmm3,%xmm13

[Bug c++/58281] Problem with explicitly instantiated constexpr template functions

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jun  1 20:49:33 2018
New Revision: 261085

URL: https://gcc.gnu.org/viewcvs?rev=261085=gcc=rev
Log:
PR c++/58281 - explicit instantiation of constexpr

* pt.c (mark_decl_instantiated): Clear DECL_EXTERNAL.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/58281] Problem with explicitly instantiated constexpr template functions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Depends on||65942

--- Comment #3 from Jason Merrill  ---
This was fixed by the patch for bug 65942, because not instantiating the
constexpr function early in mark_used meant that it went to
note_vague_linkage_fn, and therefore got fixed up properly at EOF.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
[Bug 65942] [5/6 Regression] [C++14] cannot use std::function as comparator in
algorithms

[Bug driver/86030] New: specs file processing does not create response files for input directories

[tnfchris at gcc dot gnu.org]

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

Bug ID: 86030
   Summary: specs file processing does not create response files
for input directories
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: mingw32

Similar to #45157 and #45749,

GCC does not use response files for %D and %I handling (see do_spec_1), so if
you have a project which contrains a lot of Includes or library directories cc1
or collect2 respectively will overflow the commandline limit on Windows and
error out.

It looks like a similar check/call as handling %i and %o needs to be added for
%D and %I (calling create_at_file to create response files for these).

This is causing problems for the GHC Haskell compiler when lots of packages are
used.

[Bug fortran/85816] [8/9 Regression] nested spread fails with "Integer overflow in xmallocarray"

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jun  1 20:20:35 2018
New Revision: 261081

URL: https://gcc.gnu.org/viewcvs?rev=261081=gcc=rev
Log:
2018-06-01  Steven G. Kargl  

PR fortran/85816
PR fortran/85975
* libgfortran.h: Remove the GFC_DTYPE_COPY_SETRANK macro.
* intrinsics/reshape_generic.c: Directly assign rank.
* intrinsics/spread_generic.c: Ditto.
* m4/iforeach-s.m4: Ditto.
* m4/iforeach.m4: Ditto.
* m4/ifunction-s.m4: Ditto.
* m4/ifunction-s2.m4: Ditto.
* m4/ifunction.m4: Ditto.
* m4/ifunction_logical.m4: Ditto.
* m4/reshape.m4: Ditto.
* m4/spread.m4: Ditto.
* generated/all_l1.c: Regenerated from m4 files.
* generated/all_l16.c: Ditto.
* generated/all_l2.c: Ditto.
* generated/all_l4.c: Ditto.
* generated/all_l8.c: Ditto.
* generated/any_l1.c: Ditto.
* generated/any_l16.c: Ditto.
* generated/any_l2.c: Ditto.
* generated/any_l4.c: Ditto.
* generated/any_l8.c: Ditto.
* generated/count_16_l.c: Ditto.
* generated/count_1_l.c: Ditto.
* generated/count_2_l.c: Ditto.
* generated/count_4_l.c: Ditto.
* generated/count_8_l.c: Ditto.
* generated/iall_i1.c: Ditto.
* generated/iall_i16.c: Ditto.
* generated/iall_i2.c: Ditto.
* generated/iall_i4.c: Ditto.
* generated/iall_i8.c: Ditto.
* generated/iany_i1.c: Ditto.
* generated/iany_i16.c: Ditto.
* generated/iany_i2.c: Ditto.
* generated/iany_i4.c: Ditto.
* generated/iany_i8.c: Ditto.
* generated/iparity_i1.c: Ditto.
* generated/iparity_i16.c: Ditto.
* generated/iparity_i2.c: Ditto.
* generated/iparity_i4.c: Ditto.
* generated/iparity_i8.c: Ditto.
* generated/maxloc0_16_i1.c: Ditto.
* generated/maxloc0_16_i16.c: Ditto.
* generated/maxloc0_16_i2.c: Ditto.
* generated/maxloc0_16_i4.c: Ditto.
* generated/maxloc0_16_i8.c: Ditto.
* generated/maxloc0_16_r10.c: Ditto.
* generated/maxloc0_16_r16.c: Ditto.
* generated/maxloc0_16_r4.c: Ditto.
* generated/maxloc0_16_r8.c: Ditto.
* generated/maxloc0_16_s1.c: Ditto.
* generated/maxloc0_16_s4.c: Ditto.
* generated/maxloc0_4_i1.c: Ditto.
* generated/maxloc0_4_i16.c: Ditto.
* generated/maxloc0_4_i2.c: Ditto.
* generated/maxloc0_4_i4.c: Ditto.
* generated/maxloc0_4_i8.c: Ditto.
* generated/maxloc0_4_r10.c: Ditto.
* generated/maxloc0_4_r16.c: Ditto.
* generated/maxloc0_4_r4.c: Ditto.
* generated/maxloc0_4_r8.c: Ditto.
* generated/maxloc0_4_s1.c: Ditto.
* generated/maxloc0_4_s4.c: Ditto.
* generated/maxloc0_8_i1.c: Ditto.
* generated/maxloc0_8_i16.c: Ditto.
* generated/maxloc0_8_i2.c: Ditto.
* generated/maxloc0_8_i4.c: Ditto.
* generated/maxloc0_8_i8.c: Ditto.
* generated/maxloc0_8_r10.c: Ditto.
* generated/maxloc0_8_r16.c: Ditto.
* generated/maxloc0_8_r4.c: Ditto.
* generated/maxloc0_8_r8.c: Ditto.
* generated/maxloc0_8_s1.c: Ditto.
* generated/maxloc0_8_s4.c: Ditto.
* generated/maxloc1_16_i1.c: Ditto.
* generated/maxloc1_16_i16.c: Ditto.
* generated/maxloc1_16_i2.c: Ditto.
* generated/maxloc1_16_i4.c: Ditto.
* generated/maxloc1_16_i8.c: Ditto.
* generated/maxloc1_16_r10.c: Ditto.
* generated/maxloc1_16_r16.c: Ditto.
* generated/maxloc1_16_r4.c: Ditto.
* generated/maxloc1_16_r8.c: Ditto.
* generated/maxloc1_16_s1.c: Ditto.
* generated/maxloc1_16_s4.c: Ditto.
* generated/maxloc1_4_i1.c: Ditto.
* generated/maxloc1_4_i16.c: Ditto.
* generated/maxloc1_4_i2.c: Ditto.
* generated/maxloc1_4_i4.c: Ditto.
* generated/maxloc1_4_i8.c: Ditto.
* generated/maxloc1_4_r10.c: Ditto.
* generated/maxloc1_4_r16.c: Ditto.
* generated/maxloc1_4_r4.c: Ditto.
* generated/maxloc1_4_r8.c: Ditto.
* generated/maxloc1_4_s1.c: Ditto.
* generated/maxloc1_4_s4.c: Ditto.
* generated/maxloc1_8_i1.c: Ditto.
* generated/maxloc1_8_i16.c: Ditto.
* generated/maxloc1_8_i2.c: Ditto.
* generated/maxloc1_8_i4.c: Ditto.
* generated/maxloc1_8_i8.c: Ditto.
* generated/maxloc1_8_r10.c: Ditto.
* generated/maxloc1_8_r16.c: Ditto.
* generated/maxloc1_8_r4.c: Ditto.
* generated/maxloc1_8_r8.c: Ditto.
* generated/maxloc1_8_s1.c: Ditto.
* generated/maxloc1_8_s4.c: Ditto.
* generated/maxval1_s1.c: Ditto.
* generated/maxval1_s4.c: Ditto.
* generated/maxval_i1.c: Ditto.
* generated/maxval_i16.c: Ditto.
* 

[Bug libfortran/85975] Incorrect size for spread array

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jun  1 20:20:35 2018
New Revision: 261081

URL: https://gcc.gnu.org/viewcvs?rev=261081=gcc=rev
Log:
2018-06-01  Steven G. Kargl  

PR fortran/85816
PR fortran/85975
* libgfortran.h: Remove the GFC_DTYPE_COPY_SETRANK macro.
* intrinsics/reshape_generic.c: Directly assign rank.
* intrinsics/spread_generic.c: Ditto.
* m4/iforeach-s.m4: Ditto.
* m4/iforeach.m4: Ditto.
* m4/ifunction-s.m4: Ditto.
* m4/ifunction-s2.m4: Ditto.
* m4/ifunction.m4: Ditto.
* m4/ifunction_logical.m4: Ditto.
* m4/reshape.m4: Ditto.
* m4/spread.m4: Ditto.
* generated/all_l1.c: Regenerated from m4 files.
* generated/all_l16.c: Ditto.
* generated/all_l2.c: Ditto.
* generated/all_l4.c: Ditto.
* generated/all_l8.c: Ditto.
* generated/any_l1.c: Ditto.
* generated/any_l16.c: Ditto.
* generated/any_l2.c: Ditto.
* generated/any_l4.c: Ditto.
* generated/any_l8.c: Ditto.
* generated/count_16_l.c: Ditto.
* generated/count_1_l.c: Ditto.
* generated/count_2_l.c: Ditto.
* generated/count_4_l.c: Ditto.
* generated/count_8_l.c: Ditto.
* generated/iall_i1.c: Ditto.
* generated/iall_i16.c: Ditto.
* generated/iall_i2.c: Ditto.
* generated/iall_i4.c: Ditto.
* generated/iall_i8.c: Ditto.
* generated/iany_i1.c: Ditto.
* generated/iany_i16.c: Ditto.
* generated/iany_i2.c: Ditto.
* generated/iany_i4.c: Ditto.
* generated/iany_i8.c: Ditto.
* generated/iparity_i1.c: Ditto.
* generated/iparity_i16.c: Ditto.
* generated/iparity_i2.c: Ditto.
* generated/iparity_i4.c: Ditto.
* generated/iparity_i8.c: Ditto.
* generated/maxloc0_16_i1.c: Ditto.
* generated/maxloc0_16_i16.c: Ditto.
* generated/maxloc0_16_i2.c: Ditto.
* generated/maxloc0_16_i4.c: Ditto.
* generated/maxloc0_16_i8.c: Ditto.
* generated/maxloc0_16_r10.c: Ditto.
* generated/maxloc0_16_r16.c: Ditto.
* generated/maxloc0_16_r4.c: Ditto.
* generated/maxloc0_16_r8.c: Ditto.
* generated/maxloc0_16_s1.c: Ditto.
* generated/maxloc0_16_s4.c: Ditto.
* generated/maxloc0_4_i1.c: Ditto.
* generated/maxloc0_4_i16.c: Ditto.
* generated/maxloc0_4_i2.c: Ditto.
* generated/maxloc0_4_i4.c: Ditto.
* generated/maxloc0_4_i8.c: Ditto.
* generated/maxloc0_4_r10.c: Ditto.
* generated/maxloc0_4_r16.c: Ditto.
* generated/maxloc0_4_r4.c: Ditto.
* generated/maxloc0_4_r8.c: Ditto.
* generated/maxloc0_4_s1.c: Ditto.
* generated/maxloc0_4_s4.c: Ditto.
* generated/maxloc0_8_i1.c: Ditto.
* generated/maxloc0_8_i16.c: Ditto.
* generated/maxloc0_8_i2.c: Ditto.
* generated/maxloc0_8_i4.c: Ditto.
* generated/maxloc0_8_i8.c: Ditto.
* generated/maxloc0_8_r10.c: Ditto.
* generated/maxloc0_8_r16.c: Ditto.
* generated/maxloc0_8_r4.c: Ditto.
* generated/maxloc0_8_r8.c: Ditto.
* generated/maxloc0_8_s1.c: Ditto.
* generated/maxloc0_8_s4.c: Ditto.
* generated/maxloc1_16_i1.c: Ditto.
* generated/maxloc1_16_i16.c: Ditto.
* generated/maxloc1_16_i2.c: Ditto.
* generated/maxloc1_16_i4.c: Ditto.
* generated/maxloc1_16_i8.c: Ditto.
* generated/maxloc1_16_r10.c: Ditto.
* generated/maxloc1_16_r16.c: Ditto.
* generated/maxloc1_16_r4.c: Ditto.
* generated/maxloc1_16_r8.c: Ditto.
* generated/maxloc1_16_s1.c: Ditto.
* generated/maxloc1_16_s4.c: Ditto.
* generated/maxloc1_4_i1.c: Ditto.
* generated/maxloc1_4_i16.c: Ditto.
* generated/maxloc1_4_i2.c: Ditto.
* generated/maxloc1_4_i4.c: Ditto.
* generated/maxloc1_4_i8.c: Ditto.
* generated/maxloc1_4_r10.c: Ditto.
* generated/maxloc1_4_r16.c: Ditto.
* generated/maxloc1_4_r4.c: Ditto.
* generated/maxloc1_4_r8.c: Ditto.
* generated/maxloc1_4_s1.c: Ditto.
* generated/maxloc1_4_s4.c: Ditto.
* generated/maxloc1_8_i1.c: Ditto.
* generated/maxloc1_8_i16.c: Ditto.
* generated/maxloc1_8_i2.c: Ditto.
* generated/maxloc1_8_i4.c: Ditto.
* generated/maxloc1_8_i8.c: Ditto.
* generated/maxloc1_8_r10.c: Ditto.
* generated/maxloc1_8_r16.c: Ditto.
* generated/maxloc1_8_r4.c: Ditto.
* generated/maxloc1_8_r8.c: Ditto.
* generated/maxloc1_8_s1.c: Ditto.
* generated/maxloc1_8_s4.c: Ditto.
* generated/maxval1_s1.c: Ditto.
* generated/maxval1_s4.c: Ditto.
* generated/maxval_i1.c: Ditto.
* generated/maxval_i16.c: Ditto.
* 

[Bug c/85997] Bogus -Wvla warning from function array argument with size expression

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
The requirements on array declarators apply before parameter arrays decay 
to pointers; see DR#047 (which concerns the case of an incomplete element 
type - not itself a constraint violation before C99 - but applies equally 
to the constraint in C90 that the number of elements must be an integral 
constant expression).  As the DR response says: "As an aside, array 
parameters are adjusted to pointer type (subclause 6.7.1, page 82, lines 
23-24). However, there is nothing to suggest that a 
not-strictly-conforming array type can magically be transformed into a 
strictly conforming pointer parameter via this rule.".

[Bug fortran/85840] Memory leak in write.c

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #17 from Jerry DeLisle  ---
Closing.

[Bug fortran/85840] Memory leak in write.c

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Jun  1 18:34:09 2018
New Revision: 261077

URL: https://gcc.gnu.org/viewcvs?rev=261077=gcc=rev
Log:
2018-06-01  Jerry DeLisle  

Backport from trunk.
PR libgfortran/85840
* io/write.c (write_float_0, write_real, write_real_g0,
write_complex): Use separate local variables for the float
string length.

Modified:
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/write.c

[Bug fortran/63570] [F2018] Implement 13.7.137 RANDOM INIT (REPEATABLE, IMAGE DISTINCT)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Committed to trunk.  I have no intentions of back porting
the patch to older branches.

[Bug fortran/63570] [F2018] Implement 13.7.137 RANDOM INIT (REPEATABLE, IMAGE DISTINCT)

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jun  1 17:05:02 2018
New Revision: 261075

URL: https://gcc.gnu.org/viewcvs?rev=261075=gcc=rev
Log:
2018-06-01  Steven G. Kargl  

PR fortran/63570
* check.c (gfc_check_random_init): New function. Check arguments of
RANDOM_INIT.
* gfortran.h (GFC_ISYM_RANDOM_INIT): New enum token.
* intrinsic.c (add_subroutines): Add RANDOM_INIT to list of 
subroutines.
(gfc_check_intrinsic_standard): Introduce Fortran 2018 check.
* intrinsic.h: Add prototypes for gfc_check_random_init and
gfc_resolve_random_init
* intrinsic.texi: Document new intrinsic subprogram.
* iresolve.c (gfc_resolve_random_init): Resolve routine name.
* trans-decl.c: Declare gfor_fndecl_random_init
* trans-intrinsic.c (conv_intrinsic_random_init): New function.
Translate call to RANDOM_INIT.
(gfc_conv_intrinsic_subroutine): Call it.
* trans.h: Declare gfor_fndecl_random_init

2018-06-01  Steven G. Kargl  

PR fortran/63570
* gfortran.dg/random_init_1.f90: New test.
* gfortran.dg/random_init_2.f90: New test.
* gfortran.dg/random_init_3.f90: New test.
* gfortran.dg/random_init_4.f90: New test.
* gfortran.dg/random_init_5.f90: New test.
* gfortran.dg/random_init_6.f90: New test.

2018-06-01  Steven G. Kargl  

PR fortran/63570
* libgfortran/Makefile.am: Add random_init.f90 to build.
* libgfortran/Makefile.in: Regenerated.
* libgfortran/gfortran.map: Expose symbol for _gfortran_random_init.
* libgfortran/intrinsics/random_init.f90: Implementation.

Added:
trunk/gcc/testsuite/gfortran.dg/random_init_1.f90
trunk/gcc/testsuite/gfortran.dg/random_init_2.f90
trunk/gcc/testsuite/gfortran.dg/random_init_3.f90
trunk/gcc/testsuite/gfortran.dg/random_init_4.f90
trunk/gcc/testsuite/gfortran.dg/random_init_5.f90
trunk/gcc/testsuite/gfortran.dg/random_init_6.f90
trunk/libgfortran/intrinsics/random_init.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.h
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/gfortran.map

[Bug c/85997] Bogus -Wvla warning from function array argument with size expression

[kari.nurmela at iki dot fi]

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

--- Comment #2 from Kari Nurmela  ---
There is only one array in the program, "array", and that is not a variable
length array. The syntax in print_array doesn't take any position on the kind
of the array, only that there are at least "count" elements, at least that what
C99 seems to say?

[Bug libstdc++/86015] Better handling of iterator distances

[joshua.r.marshall.1991 at gmail dot com]

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

--- Comment #4 from Josh Marshall  ---
These changes may make the stdlib implementation more robust, but there may be
an argument to stick to the more strict standard or tweak the standard.  Could
you link to the standard doc you're pulling from?  I'm not expert enough to
really figure if this report should be marked invalid or not.

[Bug c/86029] New: gcc -O3 make very slow product

[hg2ecz at ham dot hu]

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

Bug ID: 86029
   Summary: gcc -O3 make very slow product
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hg2ecz at ham dot hu
  Target Milestone: ---

I tested a signal processing sample code, and the gcc -O3 give me very slow
binary. It's a compiler error or it is good?

My CPU is i5-3337u, and I use Ubuntu-18.04 64bit OS.
gcc 7.3 and clang 6.0 and I compared with speed of Rust code (rustc 1.24.1)


My sample code and test script:

$ git clone https://github.com/hg2ecz/smallrx
$ cd smallrx/
$ ./gcc-clang-rustc-bench.sh


gcc   -Ofast -march=native rx.c -lm -o rx-gcc-Ofast
real 3.81
user 3.80
sys 0.01

clang -Ofast -march=native rx.c -lm -o rx-clang-Ofast
real 6.79
user 6.77
sys 0.02

gcc   -O3 -march=native rx.c -lm -o rx-gcc-O3
real 51.76   > very slow, clang make faster binary with [-O0, -O1, -O2,
-O3]
user 51.69
sys 0.07

clang -O3 -march=native rx.c -lm -o rx-clang-O3
real 11.05
user 11.03
sys 0.01

./Rust/target/release/smallrx
real 8.26
user 8.22
sys 0.03

[Bug c/85997] Bogus -Wvla warning from function array argument with size expression

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Well, that's a VLA before the decay to pointer type, and thus violates the 
C90 constraint referenced in the diagnostic.  So a diagnostic is obviously 
required with -std=c90 -pedantic or -Wc90-c99-compat, even if there are 
certain other uses of -Wvla for which you only want warnings about e.g. 
code that actually allocates memory for a VLA.

[Bug rtl-optimization/86028] New: Dead stores created by va_start/va_arg are not fully cleaned up

[zackw at panix dot com]

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

Bug ID: 86028
   Summary: Dead stores created by va_start/va_arg are not fully
cleaned up
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zackw at panix dot com
  Target Milestone: ---

On any ABI where arguments to a variadic function are passed in the same places
that they would be if they were arguments to a non-variadic function, it should
be possible to optimize 'foo_wrapper' in the following test program all the way
down to a tail-call to 'foo' and nothing else:

#include 

extern int a;
extern int b;
extern void *c;

int __attribute__((noinline))
foo(int x, int y, void *z)
{
  a = x;
  b = y;
  c = z;
  return 0;
}

int
foo_wrapper(int x, int y, ...)
{
  va_list ap;
  void *z;
  va_start(ap, y);
  z = va_arg(ap, void *);
  va_end(ap);
  return foo(x, y, z);
}

('foo' is included in this test program so that one can easily verify that no
argument shuffling is needed.)

gcc-8.1 targeting x86-64-linux, x86-32-linux, or aarch64-linux (all of which
meet the above ABI requirement) does not manage to do this.  It actually does
the best job for x86-32, where everything is on the stack:

foo_wrapper:
pushl   12(%esp)
pushl   12(%esp)
pushl   12(%esp)
callfoo
addl$12, %esp
ret

This is literally duplicating 'foo_wrapper's incoming arguments into a new
frame in order to call 'foo'.  The instructions are unnecessary, but they are
not dead in the formal sense.   Perhaps the issue here is just that variadic
functions aren't being considered for sibcall optimization?

For the targets where arguments are passed in registers, the code generation is
worse, e.g. aarch64:

foo_wrapper:
stp x29, x30, [sp, -64]!
add x3, sp, 48
add x4, sp, 64
mov x29, sp
stp x4, x4, [sp, 16]
str x3, [sp, 32]
stp wzr, wzr, [sp, 40]
str x2, [sp, 56]
bl  foo
ldp x29, x30, [sp], 64
ret

The actual arguments to foo_wrapper are in x0, x1, and x2, and that's also
where foo wants them, and they aren't touched at all.  All of the computation
done here is dead.

(I noticed this while messing around with glibc's syscall wrappers, which
really do things like this.  'foo_wrapper' has the type signature of 'fcntl',
for instance.)

[Bug c/85995] GCC defines __STDC__ and __STDC_VERSION__ even when used with options that break C conformance

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
See trouble.texi, "Non-bugs" / "Certain Changes We Don't Want to Make", 
"Undefining @code{__STDC__} when @option{-ansi} is not used." (and the 
description of handling of base standards in invoke.texi).  This is as 
documented since GCC 2.0.

[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences

[foom at fuhm dot net]

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

--- Comment #7 from James Y Knight  ---
(In reply to Jim Wilson from comment #6)
> On Thu, 2018-05-31 at 15:07 +, foom at fuhm dot net wrote:
> > (But also, why doesn't it implement __atomic_add_fetch inline?)
> 
> If you don't have atomic instructions, then we call an out-of-line
> function that uses locks.

Except as mentioned in the initial message, it doesn't emit calls for atomic
loads and stores too, but it needs to so that they also participate in the
locking.

> If you have atomic instructions, and it is a 32/64-bit operation, then
> we inline it.
> 
> If you have atomic instructions, and it is a 8/16-bit operation, then
> we call a lock free out-of-line function that uses a sequence of
> instructions to implement it using 32/64-bit atomic instructions.  

If you're building for rv32ia, yes, you certainly know that libatomic must
implement __atomic_fetch_add_1 lock-free. So, sure, you shouldn't have a
correctness issue by mixing the calls.

Yet even so, if you actually needed to emit a call to a known-lock-free
out-of-line function, it's better to give it a different name (e.g. __sync_*)
and include that in libgcc.a.

Emitting a call to the __atomic_* function means you require users to link
against libatomic.so, which shouldn't be required here.

> And
> as mentioned previously, I have an unfinished prototype patch to fix
> this by emitting the sequence of instructions inline.

But doing that is fine, too, and likely preferable.

[Bug c/86026] Document and/or change allowed operations on integer representation of pointers

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
Tree optimizations already manage to avoid "optimizing" f_intadd, but
unfortunately on RTL types and casts are not visible in IR and various passes
make no distinction between (char*)((uintptr_t)t + o) and (t + o).

Perhaps GCC should consider lowering pointer-to-integer casts to a
non-transparent assignment, making the result alias all for the purposes of RTL
alias analysis, akin to

char __attribute__ ((noinline)) f_intadd1(ptrdiff_t o) {
  g = 1;
  uintptr_t t1 = (uintptr_t)t;
  asm("" : "+g"(t1));
  *(char*)(t1 + o) = 2;
  return g;
}

[Bug c++/86027] New: string literals get corrupted with -O3 and gas on solaris i386

[subscribe at teskor dot de]

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

Bug ID: 86027
   Summary: string literals get corrupted with -O3 and gas on
solaris i386
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: subscribe at teskor dot de
  Target Milestone: ---

Created attachment 44224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44224=edit
source reproducing the error

GCC is Configured with: ../configure --with-cpu-32=i386 --prefix=/opt/gcc-7.3.0
--with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --with-gmp=/opt/csw --with-mpfr=/opt/csw
--with-mpc=/opt/csw ABI=32

Target is: i386-pc-solaris2.10

In this configuration, the output of the test program is corrupted. What should
be 12\n3 becomes some random 3 bytes (depending heavily on the code layout,
they changed everytime I deleted some unneeded functions from the code).

If using -O0, the problems goes away. 
Only strings literals which are used more than once in the code get garbled. 
(the "\n" and and "12", while the "3" stays correct).


Reconfiguring the compiler to use the native assembler in /usr/ccs/bin/as fixed
the problem, but unfortunately there the -pipe option ceases to work (but
that's a different issue). 

It seems to, that when configured with --with-gnu-as on solaris, the attributes
of the section containing the strings are wrongly generated in the assembler
code, but that's just a guess.

[Bug libstdc++/78870] Support std::filesystem on Windows

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #16 from Christophe Lyon  ---
Hi Jonathan,

After this patch, the aarch64_be-none-elf and aarch64-none-elf configurations
fail to configure libstdc++ because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66203

configure:80055: checking for link
configure:80055: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

[Bug tree-optimization/85964] [8/9 Regression] compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #13 from Jeffrey A. Law  ---
Yea, I was planning to take them on.  I actually have some code here that
totally revamps the backwards walk to avoid much of the duplicated work, but
it's not bootstrapping yet.

If that's the only issue left in this BZ, go ahead and assign it to me.

[Bug c/86026] Document and/or change allowed operations on integer representation of pointers

[pascal_cuoq at hotmail dot com]

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

--- Comment #2 from Pascal Cuoq  ---
Created attachment 44223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44223=edit
Complete source code for functions in the description

[Bug c++/86025] ICE with -Wduplicated-branches and OpenMP critical

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-01
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 44222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44222=edit
gcc9-pr86025.patch

Untested fix.

[Bug c++/85958] Make const qualifier error clear

[jg at jguk dot org]

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

--- Comment #6 from Jonny Grant  ---
Clang shows:

$ clang -o main main.cpp -Wall -Werror -Wconversion
main.cpp:15:5: error: no matching function for call to 'strstripspace'
strstripspace(unused, two);
^
main.cpp:5:6: note: candidate function not viable: 1st argument ('const int')
  would lose const qualifier
void strstripspace(int & value, int & two)
 ^
1 error generated.

[Bug c++/85958] Make const qualifier error clear

[jg at jguk dot org]

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

--- Comment #5 from Jonny Grant  ---
(In reply to Tavian Barnes from comment #4)
> IMHO "discards qualifiers" and even "discards const qualifier" are still
> confusing.  Making it clearly counterfactual, as in "...would discard
> (const) qualifier(s)...," would be an improvement.
> 
> But I'd further argue that "discarding qualifiers" is not really how most
> people think of this kind of error.  When a minor tries to get into a bar,
> they are not told that "entering this bar discards your age," they are told
> that "minors aren't allowed."  So I think "cannot bind 'const int' to
> non-const reference type 'int&'" would be more intuitive phrasing.

Hi Tavian

Yes, your proposal sounds good. Definitely clearer English would be very
helpful.

I personally feel "bind" is not a word any programming course teaches, we say
"passing parameters" or "passing arguments".

In addition, I feel we don't think we really need the word "reference"

Therefore, I suggest the following:

$ g++ -o main main.cpp -Wall -Werror -Wconversion
main.cpp: In function ‘int main()’:
main.cpp:11:25: error: cannot pass ‘const int’ to non-const ‘int&’

[Bug c/86026] Document and/or change allowed operations on integer representation of pointers

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
Please add full testcase source, the snippet is missing (at least) declarations
of 'g' and 't'. The Godbolt link does not work correctly for me right now, and
in general such links are not reliable long-term.

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #11 from Bill Schmidt  ---
Now fixed everywhere.

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Jun  1 13:00:57 2018
New Revision: 261067

URL: https://gcc.gnu.org/viewcvs?rev=261067=gcc=rev
Log:
2018-06-01  Bill Schmidt  

PR tree-optimization/85712
Backport from mainline:
2018-05-23  Bill Schmidt  

PR tree-optimization/85712
* gimple-ssa-strength-reduction.c (struct slsr_cand_d): Add
first_interp field.
(alloc_cand_and_find_basis): Initialize first_interp field.
(slsr_process_mul): Modify first_interp field.
(slsr_process_add): Likewise.
(slsr_process_cast): Modify first_interp field for each new
interpretation.
(slsr_process_copy): Likewise.
(dump_candidate): Dump first_interp field.
(replace_mult_candidate): Process all interpretations, not just
subsequent ones.
(replace_rhs_if_not_dup): Likewise.
(replace_one_candidate): Likewise.

Backport from mainline:
2018-05-25  Bill Schmidt  

PR tree-optimization/85712
* gimple-ssa-strength-reduction.c (replace_one_candidate): Skip if
this candidate has already been replaced in-situ by a copy.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimple-ssa-strength-reduction.c

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Jun  1 12:57:16 2018
New Revision: 261066

URL: https://gcc.gnu.org/viewcvs?rev=261066=gcc=rev
Log:
2018-06-01  Bill Schmidt  

PR tree-optimization/85712
Backport from mainline:
2018-05-23  Bill Schmidt  

PR tree-optimization/85712
* gimple-ssa-strength-reduction.c (struct slsr_cand_d): Add
first_interp field.
(alloc_cand_and_find_basis): Initialize first_interp field.
(slsr_process_mul): Modify first_interp field.
(slsr_process_add): Likewise.
(slsr_process_cast): Modify first_interp field for each new
interpretation.
(slsr_process_copy): Likewise.
(dump_candidate): Dump first_interp field.
(replace_mult_candidate): Process all interpretations, not just
subsequent ones.
(replace_rhs_if_not_dup): Likewise.
(replace_one_candidate): Likewise.

Backport from mainline:
2018-05-25  Bill Schmidt  

PR tree-optimization/85712
* gimple-ssa-strength-reduction.c (replace_one_candidate): Skip if
this candidate has already been replaced in-situ by a copy.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimple-ssa-strength-reduction.c

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Jun  1 12:55:06 2018
New Revision: 261065

URL: https://gcc.gnu.org/viewcvs?rev=261065=gcc=rev
Log:
2018-06-01  Bill Schmidt  

PR tree-optimization/85712
Backport from mainline:
2018-05-23  Bill Schmidt  

PR tree-optimization/85712
* gimple-ssa-strength-reduction.c (struct slsr_cand_d): Add
first_interp field.
(alloc_cand_and_find_basis): Initialize first_interp field.
(slsr_process_mul): Modify first_interp field.
(slsr_process_add): Likewise.
(slsr_process_cast): Modify first_interp field for each new
interpretation.
(slsr_process_copy): Likewise.
(dump_candidate): Dump first_interp field.
(replace_mult_candidate): Process all interpretations, not just
subsequent ones.
(replace_rhs_if_not_dup): Likewise.
(replace_one_candidate): Likewise.

Backport from mainline:
2018-05-25  Bill Schmidt  

PR tree-optimization/85712
* gimple-ssa-strength-reduction.c (replace_one_candidate): Skip if
this candidate has already been replaced in-situ by a copy.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/gimple-ssa-strength-reduction.c

[Bug ipa/85960] -fipa-pta and ifunc are incompatible

[gianni at scaramanga dot co.uk]

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

--- Comment #9 from Gianni Tedesco  ---
Sure, I can test it on real world cases over the weekend I think. Nice work
guys. Thanks.

[Bug middle-end/85989] [6/7/8 Regression] Incorrect result for example involving unary minus in a loop

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[6/7/8/9 Regression]|[6/7/8 Regression]
   |Incorrect result for|Incorrect result for
   |example involving unary |example involving unary
   |minus in a loop |minus in a loop

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Committed to trunk so far.  Will test and commit to the release branches over
the coming days.

[Bug middle-end/85989] [6/7/8/9 Regression] Incorrect result for example involving unary minus in a loop

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Jun  1 12:49:44 2018
New Revision: 261064

URL: https://gcc.gnu.org/viewcvs?rev=261064=gcc=rev
Log:
Fix phi backedge detection in backprop (PR85989)

This PR is a nasty wrong code bug due to my fluffing a test for a
backedge in gimple-ssa-backprop.c.  Backedges are supposed to be
from definitions in the statement we're visiting to uses in statements
that we haven't visited yet.  However, the check failed to account for
PHIs in the current block that had already been processed, so if two
PHIs in the same block referenced each other, we'd treat both
references as backedges.

In more detail:

The first phase of the pass goes through all statements in an arbitrary
order, making optimistic assumptions about any statements that haven't
been visited yet.  The second phase then calculates a correct
(supposedly maximal) fixed point.

Although the first phase order is arbitrary in principle, we still use
the CFG rpo to cut down on the backedges.  This means that the only
thing that's truly arbitrary is the order that we process the PHIs
in a block.  Any order should be OK and should eventually give the
same results.  But we have to follow whatever order we pick,
and the pass wasn't doing that.

2018-06-01  Richard Sandiford  

gcc/
PR tree-optimization/85989
* gimple-ssa-backprop.c (backprop::m_visited_phis): New member
variable.
(backprop::intersect_uses): Check it when deciding whether this
is a backedge reference.
(backprop::process_block): Add each phi to m_visited_phis
after visiting it, then clear it at the end.

gcc/testsuite/
PR tree-optimization/85989
* gcc.dg/torture/pr85989.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr85989.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-backprop.c
trunk/gcc/testsuite/ChangeLog

[Bug c/86026] New: Document and/or change allowed operations on integer representation of pointers

[pascal_cuoq at hotmail dot com]

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

Bug ID: 86026
   Summary: Document and/or change allowed operations on integer
representation of pointers
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal_cuoq at hotmail dot com
  Target Milestone: ---

This report is about GCC's handling of low-level pointer tricks such as the XOR
linked list [1]. Uses of this sort of trick are present in legacy C code and in
newly written code that push the boundaries of what is possible. If users of
GCC are going to apply GCC to this sort of code, they need to know what is
allowed. This relates to the discussion about pointer provenance, for which
Kayvan Memarian and Peter Sewell wrote a discussion draft in 2016 [3].

Consider the three functions below:

char f_ptradd(ptrdiff_t o) {
  g = 1;
  *(t + o) = 2;
  return g;
}

char f_intadd(ptrdiff_t o) {
  g = 1;
  *(char*)((uintptr_t)t + o) = 2;
  return g;
}

char f_intxor(ptrdiff_t o) {
  g = 1;
  *(char*)((uintptr_t)t ^ o) = 2;
  return g;
}

GCC 8.1 produces the following assembly for these functions [2]:

f_ptradd:
  movb $1, g(%rip)
  movl $1, %eax
  movb $2, t(%rdi)
  ret
f_intadd:
  movb $1, g(%rip)
  movl $1, %eax
  movb $2, t(%rdi)
  ret
f_intxor:
  xorq $t, %rdi
  movb $1, g(%rip)
  movb $2, (%rdi)
  movzbl g(%rip), %eax
  ret

The third function does exactly what a XOR linked list implementation does.
Sufficiently smart inlining and constant propagation would turn a generic
implementation into f_intxor.

GCC 8.1 and earlier versions compile the first two functions f_ptradd and
f_intadd as if they could never be invoked as in the following main:

int main(void) {
  f_ptradd((uintptr_t)  - (uintptr_t) t);
  f_intadd((uintptr_t)  - (uintptr_t) t);
  f_intxor((uintptr_t)  ^ (uintptr_t) t);
}

This is fair in the case of f_ptradd, which invokes undefined behavior at “t +
o”. However, I would have expected f_intadd to be compiled conservatively,
because it is possible to pass a value o that, added to the integer
representation of (char*)t, produces the integer representation of g.


Of course, it is for the GCC developers to decide exactly what is allowed and
what isn't after a pointer is converted to an integer. But without an explicit
explanation in GCC's documentation of what makes f_intadd and f_intxor
different, we have to assume that the latter is no more supported than the
former, and that programs that use XOR linked lists or similar data structures
cannot be compiled by GCC.


[1] https://en.wikipedia.org/wiki/XOR_linked_list
[2] https://godbolt.org/g/DYCpjS
[3] http://www.cl.cam.ac.uk/~pes20/cerberus/n2090.html

[Bug testsuite/86016] New tests for r260978 report excess errors

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-01
 Ever confirmed|0   |1

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

[Bug c++/86025] New: ICE with -Wduplicated-branches and OpenMP critical

[zed.three at gmail dot com]

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

Bug ID: 86025
   Summary: ICE with -Wduplicated-branches and OpenMP critical
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zed.three at gmail dot com
  Target Milestone: ---

Created attachment 44221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44221=edit
Preprocessed output

Compiling the following MVCE with "-Wduplicated-branches -fopenmp" causes an
ICE.
I've checked with 7.3.1 and 8.0.1. It's very similar to 79672, but with a
different pragma.
Dropping "(foo)" makes the ICE go away.

#include 

void foo() {
  if (false) {
#pragma omp parallel
#pragma omp critical (foo)
if (false) {
}
  }
}

Output:

Using built-in specs.
COLLECT_GCC=g++-8
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/8 --enable-ssp --disable-libssp
--disable-libvtv --disable-cet --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-8 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 8.0.1 20180425 (prerelease) [gcc-8-branch revision 259638] (SUSE
Linux) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Wduplicated-branches' '-fopenmp'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-pthread'
 /usr/lib64/gcc/x86_64-suse-linux/8/cc1plus -E -quiet -v -D_GNU_SOURCE
-D_REENTRANT gcc_crash.cxx -mtune=generic -march=x86-64 -Wduplicated-branches
-fopenmp -fpch-preprocess -o gcc_crash.ii
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/8
 /usr/include/c++/8/x86_64-suse-linux
 /usr/include/c++/8/backward
 /usr/lib64/gcc/x86_64-suse-linux/8/include
 /usr/local/include
 /usr/lib64/gcc/x86_64-suse-linux/8/include-fixed
 /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Wduplicated-branches' '-fopenmp'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-pthread'
 /usr/lib64/gcc/x86_64-suse-linux/8/cc1plus -fpreprocessed gcc_crash.ii -quiet
-dumpbase gcc_crash.cxx -mtune=generic -march=x86-64 -auxbase gcc_crash
-Wduplicated-branches -version -fopenmp -o gcc_crash.s
GNU C++14 (SUSE Linux) version 8.0.1 20180425 (prerelease) [gcc-8-branch
revision 259638] (x86_64-suse-linux)
compiled by GNU C version 8.0.1 20180425 (prerelease) [gcc-8-branch
revision 259638], GMP version 6.1.2, MPFR version 4.0.1-p6, MPC version 1.1.0,
isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (SUSE Linux) version 8.0.1 20180425 (prerelease) [gcc-8-branch
revision 259638] (x86_64-suse-linux)
compiled by GNU C version 8.0.1 20180425 (prerelease) [gcc-8-branch
revision 259638], GMP version 6.1.2, MPFR version 4.0.1-p6, 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: ca1e18c23ccd29ea8279af847a2b27d0
gcc_crash.cxx: In function ‘void foo()’:
gcc_crash.cxx:10:1: internal compiler error: in add_expr, at tree.c:7417
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/86006] compile time error generic type bound procedure

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
BTW do you expect the ambiguity to be resolved in the following test?

Module Mod_LL_DT
  Implicit None
  Private
  Type, Public :: LLCont_DT
  contains
Generic :: GetElement => GetElementByType,GetElementByPosition
Procedure, PAss :: GetElementByType => SubGetElementByType
Procedure, PAss :: GetElementByPosition => SubGetElementByPosition
  End type LLCont_DT
contains
  Subroutine SubGetElementByType(this,TSOut)
Implicit None
Class(LLCont_DT), Intent(InOut) :: this
!Class(LLCont_DT), Intent(Out), Pointer :: TSOut
integer(8), Pointer :: TSOut
  End Subroutine SubGetElementByType
  Subroutine SubGetElementByPosition(this,ISPos)
Implicit None
Class(LLCont_DT), Intent(InOut) :: this
Integer(8) :: ISPos
  End Subroutine SubGetElementByPosition
End Module Mod_LL_DT

[Bug tree-optimization/86024] Missed memcpy loop distribution with elementwise copy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-01
 CC||amker at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  loop distribution only handles stride 1 accesses and single
loads/stores for the pattern recognition.

With my ongoing work on vectorizer refactoring it might be possible to
re-use its DR group analysis and thus work on DR groups here.

Or we may want to teach this pattern to the vectorizer itself (eh...).

Or we may want to un-"SRA" such patterns, generating aggregate copies.

[Bug tree-optimization/86024] New: Missed memcpy loop distribution with elementwise copy

[glisse at gcc dot gnu.org]

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

Bug ID: 86024
   Summary: Missed memcpy loop distribution with elementwise copy
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

typedef struct A { int a, b; } A;
void*f(A*restrict p){
  A*q=__builtin_malloc(1024*sizeof(A));
  for(int i=0;i<1024;++i){
#ifdef HELP
q[i]=p[i];
#else
q[i].a=p[i].a;
q[i].b=p[i].b;
#endif
  }
  return q;
}

At -O3, with HELP, we get the expected memcpy. Without it, the loop is only
vectorized.

[Bug libstdc++/86023] New: Fake triviality test for internal purposes

[glisse at gcc dot gnu.org]

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

Bug ID: 86023
   Summary: Fake triviality test for internal purposes
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

While we cannot make std::pair or std::tuple trivial for now for ABI reasons,
it should still be safe to use memcpy-type optimizations for them when it is
safe for each member. We probably don't want to lie to the user in is_trivial
or is_trivially_copyable (?), but we could at least introduce an internal
version of those traits, specialized for a few types like pair/tuple, and use
them so _GLIBCXX_MOVE_BACKWARD3 would use memmove on std::pair for
instance.

According to some benchmark, this might (they weren't exactly testing this)
change the average performance of insert/erase in
boost::flat_map<,,std::vector<>> by a factor of 2. Of course, it won't affect
the default flat_map, which uses boost's vector and traits, so it isn't a real
solution, just a small band-aid.

The exact traits to specialize depend on PR 68350.

#include 
#include 
#ifdef FAST
struct A {
  int first,second;
  A(int a,int b):first(a),second(b){}
  A()=default;
};
#else
typedef std::pair A;
#endif
typedef std::vector V;

int main(int argc,char**){
  V v;
  for(int i=0;i<10;++i){
v.insert(v.begin(),{i,i});
  }
  return v[argc].second;
}

At -O3, I get 3.41s for std::pair, 1.00s for the struct, and an intermediate
1.99s for the struct minus the default constructor.

[Bug tree-optimization/86017] multiple consecutive calls to bzero/memset not merged

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
The testcase is now fixed.  We're still not merging adjacent memset/bzero
calls.\
Modified testcase:

void f (void*);
void h (void)
{
  char a[8];
  __builtin_memset (a, 0, 1);
  __builtin_memset (a + 1, 0, 3);
  __builtin_memset (a + 4, 0, 4);

  f (a);
}

results in

;; Function h (h, funcdef_no=1, decl_uid=1962, cgraph_uid=1, symbol_order=1)

h ()
{
  char a[8];

   [local count: 1073741825]:
  MEM[(void *)] = 0;
  __builtin_memset ([(void *) + 1B], 0, 3);
  __builtin_memset ([(void *) + 4B], 0, 4);
  f ();
  a ={v} {CLOBBER};
  return;

}

note we have to deal with merging with stores as well.  Given the
original testcase was ultimatively solved by making only stores
available to store-merging the obvious thing to do is to teach
store-merging about memset()/bzero() and consider memset() for
code-generation as well(?).

No longer mine.

[Bug sanitizer/86022] New: TCB size calculated in ThreadDescriptorSize() is wrong for glibc-2.14

[b7.10110111 at gmail dot com]

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

Bug ID: 86022
   Summary: TCB size calculated in ThreadDescriptorSize() is wrong
for glibc-2.14
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

In ThreadDescriptorSize(), I currently see:

  else if (minor <= 13)
val = FIRST_32_SECOND_64(1168, 2304);
  else
val = FIRST_32_SECOND_64(1216, 2304);

This leads to assertion failure on glibc-2.14, with the same message as in bug
60038. Actual values for glibc 2.14 are the same as for 2.13: 1168 for i386 and
2304 for x86_64.

I checked this by appending the following to glibc-2.14.1/nptl/descr.h:

typedef int TCB_SIZE_2304[sizeof(struct pthread)==2304 ? -1 : 1];
typedef int TCB_SIZE_1168[sizeof(struct pthread)==1168 ? -1 : 1];

and getting corresponding error when compiling glibc on a 32-bit and on a
64-bit x86 Kubuntu machines.


I suppose the fix should be to change "minor <= 13" to "minor <= 14".

[Bug tree-optimization/86017] multiple consecutive calls to bzero/memset not merged

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Jun  1 10:49:54 2018
New Revision: 261061

URL: https://gcc.gnu.org/viewcvs?rev=261061=gcc=rev
Log:
2018-06-01  Richard Biener  

PR middle-end/86017
* gimple-fold.c (var_decl_component_p): Also allow offsetted
vars wrapped in MEM_REFs.

* gcc.dg/tree-ssa/pr86017.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr86017.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/86006] compile time error generic type bound procedure

[karl.may0 at freenet dot de]

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

--- Comment #4 from Karl May  ---
Hi. Thanks.

here is the link:

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/779807

[Bug fortran/86006] compile time error generic type bound procedure

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> From my understanding the compiler translates the generic call
> at compile time into calls for the functions bound to the generic call.
> If this is the case, and given the fact that the compiler distinguishes
> explicitly between dummy arguments of type "integer" and of type
> "unlimited polymorphic pointer", there should be no ambiguity.

AFAICT looking at examples, intrinsics types and kinds are part 
of unlimited polymorphic. I had a quick look at the standard and saw some 
restrictions for allocatable and pointer, but nothing saying that they 
can be used to resolve ambiguities.

> I'll trigger a discussion at the intel ifort forum and let you know.

Could you please give a pointer to the thread? 
You could also do it on comp.lang.fortran.

[Bug fortran/86006] compile time error generic type bound procedure

[karl.may0 at freenet dot de]

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

--- Comment #2 from Karl May  ---
Hi.

Thank for the response

It compiles with

ifort -c -stand f08 tmp.f90
ifort -c -stand f15 tmp.f90
ifort -c -stand f03 tmp.f90

ifort version was 17.07

>From my understanding the compiler translates the generic call at compile time
into calls for the functions bound to the generic call. If this is the case,
and given the fact that the compiler distinguishes explicitly between dummy
arguments of type "integer" and of type "unlimited polymorphic pointer", there
should be no ambiguity.

I'll trigger a discussion at the intel ifort forum and let you know.

Cheers

[Bug fortran/86021] ICE when initializing a character array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
This PR (duplicate of pr61627) has been fixed at revisions r258347 for gcc
8.1.0, r258367 for 7.3.1, and r258368 for 6.4.1.

Join SciencePG as editorial board members/reviewers and submit your article

[Journal IJAAA]

Dear Professor/Scholar,
We publish peer-reviewed scientific journals devoted to the development of
innovative science and technology. Now we sincerely invite scholars and
researchers to submit papers to the journals or to join in the editorial
board/reviewer team.
Submitting Your New Manuscripts
If you have burst out some new ideas in your specialized or interested
field, welcome to submit your papers to the corresponding Journals or
Special Issues so as to share your ideas with people around the world.
Joining in the Editorial Board
For the purpose of making editorial board and reviewer group expanded, we
would like to invite you to be the editorial member or reviewer of our
journals with great sincerity. If you want to know more details of the
Benefits and Responsibilities of the editorial member or reviewer, please
visit the following link: http://www.ajtte.org/journals
Open Access (OA)
Each journal uses the Open Access policy. The papers of the authors can be
cited and read widely, which can contribute to the recognition of the
authors in the certain field and beyond.
30-60 Days Fast Publication
Fast publication promotes scientific research and saves author's time,
which will make your paper to be known by people as fast as possible. The
normal time is 40-60 days after you submit your paper to our journals.
Indexing and Abstracting
Most of journals in our platform can be searched by JournalSeek, Electronic
Journals Library (EJL), WorldCat, CrossRef, Zeitschriftendatenbank, EZB,
Academickeys, ResearchBib, Polish Scholarly Bibliography, CNKI, etc.
Peer-reviewed Policy
Papers submitted to the journals are peer-reviewed, which means reviewer
anonymity allows for impartial decisions - the reviewers will not be
influenced by the authors.
Some Recommended Journals:

   1. Science Journal of Analytical Chemistry
   2. International Journal of Education, Culture and Society
   3. International Journal of Science, Technology and Society
   4. American Journal of Life Sciences
   5. International Journal of Nutrition and Food Sciences
   6. International Journal of Energy and Power Engineering
   7. American Journal of Theoretical and Applied Statistics
   8. International Journal of Economy, Energy and Environment

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to Jan Kratochvil from comment #0)
> Maybe it could even always call realloc() for size reduction of any type of
> objects and just assert the returned pointer did not change.

I can't find anywhere a guarantee that realloc doesn't move stuff when the new
size is smaller than the old.

(In reply to Richard Biener from comment #3)
> I wonder if technically shrink_to_fit() is allowed to elide the shrinking? 
> And yes, I'm equally shocked about the need to copy!

What would be the point of shrink_to_fit() otherwise? It was created as a nicer
alternative for people who were copying to a new temporary vector and swapping
them.

[Bug fortran/86021] ICE when initializing a character array

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
(In reply to Richard Biener from comment #1)
> Both look more like PR84141/PR84155.  Paul, the gfc_get_dtype changes should
> probably be backported.

I'll take a look see over the weekend.

Cheers

Paul

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

[m.schewe at apt dot de]

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

--- Comment #20 from M.Schewe  ---
Removing -fshort-double completely was not a good idea.

It is required for ARM microcontrollers, e.g. ARM Cortex M4F with a FPU which
can handly only single precision arithmetic operations. All double precision
arithmetics must be emulated by slow integer software.
Without this option it is no more possible to compile runtime libraries and
application to efficiently use this FPU.
Restricing resolution to single precision is acceptable for many embedded
realtime applications, often runtime requirements must be met.

I agree to you that on architectures with powerful FPUs like x86 and x86_64
this option is not so important and may be unsupported to solve bugs.

I suggest to revert the changes from rev. 233218 thus implementing
-fshort-double as before.
Architectures which have implementation-bugs like x86_64-*-* simply can abort
compilation if the option is activated with some error message saying
"-fshort-double option is no more supported on this archeticture".

[Bug target/86019] [8/9 Regression] Unref implementation using atomic_thread_fence generates worse code on x86-64 in gcc 8.1 than 7.3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
URL|missed-optimization |
  Known to work||7.3.0
Version|unknown |8.1.0
   Target Milestone|--- |8.2
Summary|Unref implementation using  |[8/9 Regression] Unref
   |atomic_thread_fence |implementation using
   |generates worse code on |atomic_thread_fence
   |x86-64 in gcc 8.1 than 7.3  |generates worse code on
   ||x86-64 in gcc 8.1 than 7.3

[Bug tree-optimization/85964] [8/9 Regression] compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Jeff can you look at the backwards threading scaling issue?  There's also
PR69580
for that which may be the same underlying issue.

[Bug fortran/86021] ICE when initializing a character array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Both look more like PR84141/PR84155.  Paul, the gfc_get_dtype changes should
probably be backported.

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
shrink_to_fit is a non-binding request, the implementation is allowed to
completely ignore it. But the expected semantics (at least, expected by those
who designed the feature) is that it reallocates new storage, copies the
elements, and deallocates the old storage. If you don't want that, don't call
shrink_to_fit.

I don't see how this qualifies as a missed-optimization when doing it is
impossible in the general case.

[Bug ipa/85960] -fipa-pta and ifunc are incompatible

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
  Known to fail||8.1.0

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.  As it is unlikely a regression I'm only considering a
backport to GCC 8 but also only after some soaking on trunk.

Gianni - can you put the fix (that was actually committed, it has some
fixed over the attached patch) on more testing on your code?  It should
trivially apply to GCC 8 as well.

[Bug ipa/85960] -fipa-pta and ifunc are incompatible

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Jun  1 08:20:08 2018
New Revision: 261056

URL: https://gcc.gnu.org/viewcvs?rev=261056=gcc=rev
Log:
2018-06-01  Richard Biener  

PR ipa/85960
* tree-ssa-structalias.c (get_function_part_constraint):
Handle NULL fi->decl.
(find_func_aliases_for_call): Properly handle indirect
fi from direct call.
(find_func_clobbers): Likewise.
(ipa_pta_execute): Likewise.
(create_variable_info_for): For functions that are ifunc_resolver
resolve to a varinfo that contains the result of the resolver
call.
(associate_varinfo_to_alias): Do not treat ifunc resolvers as
aliases.

* gcc.dg/ipa/ipa-pta-19.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-19.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/86017] multiple consecutive calls to bzero/memset not merged

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-01
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  A related issue is that we inline the first but not the adjacent
memsets.  Fixing that makes us apply store-merging.  Testing a patch.

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Richard Biener  ---
I wonder if technically shrink_to_fit() is allowed to elide the shrinking?  And
yes, I'm equally shocked about the need to copy!

[Bug target/86011] Inefficient code generated for ldivmod with constant value

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||arm
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-06-01
  Component|other   |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think this was fixed with GCC 8.  Can you check?

[Bug tree-optimization/86010] [7/8/9 Regression] redundant memset with smaller size not eliminated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-01
 CC||law at gcc dot gnu.org
  Known to work||4.8.5
   Target Milestone|--- |7.4
Summary|[7/8 Regression] redundant  |[7/8/9 Regression]
   |memset with smaller size|redundant memset with
   |not eliminated  |smaller size not eliminated
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
This is the new byte-tracking in DSE I presume which isn't able to prune
optimally (off-by-one?) or do the better thing, namely removing the
later memset instead of the earlier.  With GCC 4.8 we managed to combine
the memsets at the RTL level.

[Bug target/86007] precompiled header on bdver2 with -march=native triggers a "created and used with differing settings of '-mlwp'" warning, intermittently

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
  Component|pch |target

--- Comment #2 from Richard Biener  ---
It sounds like -mlwp is detected randomly..

On current trunk I get it consistently detected when doing

> gcc -S t.c -march=native -v 2>&1 | grep lwp | sed -e 
> 's/.*\(-m\(no-\)\?lwp\).*/\1/'

repeatedly on a simple empty input.

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

--- Comment #4 from Richard Biener  ---
Do we somehow rely on plugin auto-loading now?

[Bug target/86003] [8/9 Regression] GCC fails to build when configured --with-cpu=xscale

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm
   Priority|P3  |P2
   Target Milestone|--- |8.2

[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Martin Liška from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > If the variable is unused, why is any stack assigned to it?
> 
> I guess it's due to -O0 or am I wrong?

Jakub?

[Bug inline-asm/49611] Inline asm should support input/output of flags

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #18 from Uroš Bizjak  ---
(In reply to David from comment #16)

> Still, if I were Richard, I'd be closing this bug.  If someone has
> optimization issues with his solution, that's a new bug.

This was implemented some time ago.