[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[davidegrayson at gmail dot com]

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

--- Comment #33 from David Grayson  ---
Hello, Terry.  I'd be happy to help.  I hope you have access to a Linux
computer.  I've actually spent a lot of time working on build scripts for
cross-compilers running on Linux and here's what I have come up with for you:

https://gist.github.com/DavidEGrayson/d5ca447cca1ea23d5adca2f353dbb67a

[Bug debug/48886] VTA issues with > word size integers

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Alexandre Oliva from comment #2)
> FWIW, I've just tried the testcase in the description with trunk, with -g
> alone and with -O2, and got a full pass on x86_64- and i686-linux-gnu.

So is this fixed then?

[Bug c++/70180] missing -Wpointer-arith on NULL arithmetic cast to a an object type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug fortran/87838] New: Segmentation fault with function pointer to contained function

[menospaamthereaper at hotmail dot com]

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

Bug ID: 87838
   Summary: Segmentation fault with function pointer to contained
function
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: menospaamthereaper at hotmail dot com
  Target Milestone: ---

Created attachment 44938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44938=edit
Output from -save-temps

Function pointer to a function contained within the same program gives a
segmentation fault. Confirmed in both 7.3.0 and 8.2.0-1 (Ubuntu 18.04 installed
from apt). Compiled with gfortran test.f03 and gfortran-8 test.f03. Minimal
failing example:

program test_func_ptrs

 implicit none

  abstract interface
  subroutine func()
  end subroutine
  end interface

procedure (func), pointer :: f_ptr => null ()

f_ptr => f1

call f_ptr()

 contains

 subroutine f1()
 implicit none

return
 end subroutine

 end program test_func_ptrs

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[xuepeng.guo at intel dot com]

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

--- Comment #32 from Terry Guo  ---
(In reply to David Grayson from comment #27)
> Thanks to everyone who is working on this.  I can confirm that the patch in
> comment #20 by Uroš Bizjak applies cleanly to GCC 7.3.0, and I successfully
> used the resulting toolchain targeting i686-w64-mingw32 to build Qt and
> several Qt GUI examples, all of which run correctly.
> 
> Just in case it helps you find more bugs: I noticed there are several other
> places in the code (of gcc-8-20181019) where ctrl->preferred_stack_boundary
> gets updated without any obvious update of ctrl->stack_alignment_needed:
> 
> gcc/explow.c:1247 in get_dynamic_stack_size
> gcc/explow.c:1595 in get_dynamic_stack_base
> gcc/calls.c:3811 in expand_call
> gcc/config/i386/i386.c:12593 in ix86_update_stack_boundary

Hello David,
Do you have instructions about how to build toolchain targeting
i686-w64-mingw32? I searched around and just found:
https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-doc/howto-build/mingw-w64-howto-build.txt

EDGE, the 1500kg Lithium Powered Pallet Truck, time to order now!--Noblelift Newsletter

[Noblelift Equipment]

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=8a6a843993=7264378baa
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=c37f160f34=7264378baa

Noblelift is the #1

manufacturer of pallet

trucks worldwide!
More information 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=df43a3b5e3=7264378baa)

Standard

Applications
Lithium powered pallet truck with 1500kg Capacity. Full electric, compact size 
(L=1530mm), weight 123kg and smallest turning radius in the industry. Optional 
Lithium bateries from 20Ah to 36Ah, gradeability 4/16%, travel speed 
4.6/4.8km/h. And more features you will love, for more information, please feel 
free to contact us!
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=8c63e9d614=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=639bb5eee5=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=a737425546=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=48267e8981=7264378baa

Light duty 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=a84d0288bd=7264378baa)

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=9ea3f5ef63=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=e8fdedbfd4=7264378baa
 
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=b35b635b00=7264378baa

Walkie 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=78165440fa=7264378baa)

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=8605f812a1=7264378baa

Ride-on 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=5334e05530=7264378baa)
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=31e893bb3d=7264378baa
* Full electric operation(traveling & lifting

* Easy battery change(PTE12) or bigger battery option(PTE15) for long operation
* Italian drive unit with optional rubber driver wheel

* European top brand key components,

* High performance Vertical AC drive unit

* Optional sideway battery replacement

* Robust and ergonomic design

* High Speed Vertical AC drive unit

* European top brand key components

* Optional EPS & Side battery extraction

* Ride on platform standardd
LEARN MORE 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=b90384989b=7264378baa)
  LEARN MORE 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=1a494705a3=7264378baa)
 LEARN MORE 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=6f00680e9c=7264378baa)

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=47dce9deff=7264378baa

(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=39eb3aa792=7264378baa)
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=bae0e2f798=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=2bf2865ca0=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=0c212670d3=7264378baa
 PS E10/10M/-1000kg 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=ceead1ba4e=7264378baa)
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=574c14a975=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=dbc146c78b=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=420700a247=7264378baa
 
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=454a4ef4ed=7264378baa
 PS12L/16L 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=ae4cb2317f=7264378baa)
 /20L-1200-2000kg 
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=6b4b4faa1d=7264378baa
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=95c64fe1dd=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=3b5632fd4c=7264378baa

https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=540eaedcb7=7264378baa
 
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=bcf626b2fa=7264378baa
 PS16N 
(https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=e862b6e027=7264378baa)
 /20N-1600-2000kg
https://noblelift.us10.list-manage.com/track/click?u=e8aec7d772de62b3b6c40316a=4254999ece=7264378baa

* Full electric operation(traveling & lifting)

* Compact design, DC drive unit

* Duplex mast with max. lift height up to  3.5m, optional straddle-leg type

* European top brand key components,

* High 

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[xuepeng.guo at intel dot com]

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

--- Comment #31 from Terry Guo  ---
(In reply to Uroš Bizjak from comment #30)
> (In reply to Jakub Jelinek from comment #29)
> > > Let's ask Jakub about asan, if it is possible to move generation of the 
> > > call
> > > after the function is already expanded to RTL.
> > 
> > I'm afraid no.
> 
> Hm...
> 
> ... maybe we could go with following patch:
> 
> +  if (SUPPORTS_STACK_ALIGNMENT)
> +{
> +  if (preferred_stack_boundary > crtl->stack_alignment_estimated)
> + crtl->stack_alignment_estimated = preferred_stack_boundary;
> +  if (preferred_stack_boundary > crtl->stack_alignment_needed)
> + crtl->stack_alignment_needed = preferred_stack_boundary;
> +}
> 
> This means that for functions, emitted through emit_library_call, stack
> won't be realigned. This would cure the assert (and would follow a bit more
> expand_stack_alignment from cfgrtl.c).

I have same thought. I will test this one.

[Bug c/87806] Option -Wall should warn about unused structs, typdefs, enums, etc

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
I agree that focusing the warning on definitions in .c files and avoiding those
in headers would be necessary to make the fallout manageable.  But I'm not sure
-Wall or even -Wextra is a good fit even for this relaxed version of the
warning.  GCC (and many other GNU projects, including Glibc) has a policy of
compiling cleanly with -Wall and -Wextra so enabling such a warning by either
would likely mean a lot of work cleaning up GCC itself (and the other
projects).  Building some of these projects with the warnings explicitly
enabled would give us an idea of the scope of the cleanup.  I could give that a
try but I can't find any options that control warnings about unused non-local
types and enums.  What are they?

[Bug sanitizer/87837] New: -O2 -fsanitize=signed-integer-overflow misses overflows on x86-64

[eggert at cs dot ucla.edu]

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

Bug ID: 87837
   Summary: -O2 -fsanitize=signed-integer-overflow misses
overflows on x86-64
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
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 GCC 8, -O2 -fsanitize=signed-integer-overflow (and -fsanitize=undefined) is
missing signed integer overflows. GCC 7 caught them so this is a regression. I
observed the problem with GCC 8.2.1 20181011 (Red Hat 8.2.1-4) on x86-64.
Consider this function in the file testovf.c:

_Bool
testovf (long n)
{
  return n + 9223372036854775807 < n;
}

Compile it with:

gcc -O2 -S -fsanitize=signed-integer-overflow testovf.c

With GCC 7.3.0, an overflow will be detected at runtime if one passes a
positive value to 'testovf', but with GCC 8.2.1 no overflow is detected. This
is because GCC 7.3.0 generates overflow-checking code (e.g., "addq %rdx, %rdp;
jo .L6") whereas GCC 8.2.1 merely generates this:

testovf:
xorl%eax, %eax
ret

Apparently GCC 8 is optimizing away the overflow test on the ground that if
overflow occurs, behavior is undefined so the generated code can do anything.
But when -fsanitize=signed-integer-overflow is used, that's not correct: the
user wants overflows to be diagnosed, not to be optimized away. That is, when
-fsanitize=signed-integer-overflow is used, behavior is not undefined when
signed integer overflow occurs (it is well-defined to trap), so these
optimizations should be inhibited.

[Bug d/87825] profiledbootstrap is broken when D is enabled

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
This is done.

[Bug d/87825] profiledbootstrap is broken when D is enabled

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Oct 31 21:48:52 2018
New Revision: 265702

URL: https://gcc.gnu.org/viewcvs?rev=265702=gcc=rev
Log:
Fix profiledbootstrap when D is enabled

gcc/d/ChangeLog:

2018-10-31  Iain Buclaw  

PR d/87825
* Make-lang.in (d/idgen) Link with BUILD_LINKERFLAGS.
(d/impcvgen): Likewise.

Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/Make-lang.in

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[ian at gcc dot gnu.org]

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

--- Comment #12 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Oct 31 20:46:17 2018
New Revision: 265701

URL: https://gcc.gnu.org/viewcvs?rev=265701=gcc=rev
Log:
PR bootstrap/82856

libgo: update to autoconf 2.69 and automake 1.15.1

Initial patch from Joseph Myers.

Reviewed-on: https://go-review.googlesource.com/c/146417

Removed:
trunk/libgo/config/go.m4
Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/Makefile.am
trunk/libgo/Makefile.in
trunk/libgo/aclocal.m4
trunk/libgo/config/libtool.m4
trunk/libgo/configure
trunk/libgo/configure.ac
trunk/libgo/testsuite/Makefile.in

[Bug web/87050] Bump wwwdocs to html5

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #13 from Janne Blomqvist  ---
I just committed an obvious patch to rename the XHTML var in style.mhtml to
NOSTYLE, and with that, all occurences of XHTML in wwwdocs have been exorcised
(except gitweb, but that of course comes from upstream).

Once again, a big thanks to Gerald!

[Bug fortran/20520] allocatable arrays used uninitialized without a warning

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #21 from Thomas Koenig  ---
Marking as fixed.

[Bug fortran/20520] allocatable arrays used uninitialized without a warning

[tkoenig at gcc dot gnu.org]

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

--- Comment #20 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Oct 31 18:35:59 2018
New Revision: 265698

URL: https://gcc.gnu.org/viewcvs?rev=265698=gcc=rev
Log:
2018-10-31  Thomas Koenig  

PR fortran/20520
* gfortran.dg/allocatable_uninitialized_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/allocatable_uninitialized_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/87836] New: ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

Bug ID: 87836
   Summary: ICE in cc1 for gcc-6.5.0 with SPARC hardware
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gary_mills at fastmail dot fm
  Target Milestone: ---

Here's information on the compiler:
$
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/build/sparcv7/./gcc/xgcc
--version
xgcc (OpenIndiana 6.5.0-OI-4) 6.5.0
Copyright (C) 2017 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.

$ -6/build/sparcv7/./gcc/xgcc -v<
Using built-in specs.
COLLECT_GCC=/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/build/sparcv7/./gcc/xgcc
Target: sparc-sun-solaris2.11
Configured with:
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/configure
CC=/usr/gcc/4.9/bin/gcc CXX=/usr/gcc/4.9/bin/g++ F77=/usr/gcc/4.9/bin/gfortran
FC=/usr/gcc/4.9/bin/gfortran CFLAGS='-g -O2' CXXFLAGS=' ' FFLAGS=' ' FCFLAGS=
LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig --prefix=/usr/gcc/6
--mandir=/usr/gcc/6/share/man --bindir=/usr/gcc/6/bin --libdir=/usr/gcc/6/lib
--sbindir=/usr/gcc/6/sbin --sbindir=/usr/gcc/6/bin --libdir=/usr/gcc/6/lib
--libexecdir=/usr/gcc/6/lib --host sparc-sun-solaris2.11 --build
sparc-sun-solaris2.11 --target sparc-sun-solaris2.11
--with-pkgversion='OpenIndiana 6.5.0-OI-4'
--with-bugurl=https://bugs.openindiana.org --enable-plugins --enable-objc-gc
--enable-initfini-array --enable-languages=c,c++,fortran,lto,objc
--without-gnu-ld --with-ld=/usr/bin/ld
--with-build-time-tools=/usr/gnu/sparc-sun-solaris2.11/bin --disable-libitm
--without-gnu-as --with-as=/usr/bin/as LDFLAGS=-R/usr/gcc/6/lib
Thread model: posix
gcc version 6.5.0 (OpenIndiana 6.5.0-OI-4) 

Here's the error I get:
$
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/build/sparcv7/./gcc/xgcc
-B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/build/sparcv7/./gcc/
-S conftest.c
conftest.c: In function 'main':
conftest.c:2:1: internal compiler error: Segmentation Fault
 main ()
 ^~~~
0x631deb crash_signal
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:333
0x360b3c et_splay
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:311
0x361833 et_set_father
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:525
0x301e6b calculate_dominance_info(cdi_direction)
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/dominance.c:658
0x6701cb cleanup_tree_cfg_noloop
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:759
0x6701cb cleanup_tree_cfg()
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:818
0x66ab87 execute_build_cfg
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:360
0x66ab87 execute
   
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:389
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Here's the source file:
$ cat conftest.c
int
main ()
{

  ;
  return 0;
}

This happens on a Sun T2000 running v9os (oi_151a9).  The kernel is illumos.
I get the same error and backtrace with gcc-6.4.0 and gcc-7.3.0 .  It worked
with gcc-4.9.4 .  The error appears with the configuration for phase 2 and
also when xgcc is run separately as in this test.  It does build correctly on
x86 hardware.

Note that all of these gcc versions have some patches applied.  These patches
adapt gcc for building the illumos kernel.

I'm willing to test potential fixes on my hardware and OS or to gather
additional debugging information.

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ubizjak at gmail dot com]

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

--- Comment #30 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #29)
> > Let's ask Jakub about asan, if it is possible to move generation of the call
> > after the function is already expanded to RTL.
> 
> I'm afraid no.

Hm...

... maybe we could go with following patch:

+  if (SUPPORTS_STACK_ALIGNMENT)
+{
+  if (preferred_stack_boundary > crtl->stack_alignment_estimated)
+   crtl->stack_alignment_estimated = preferred_stack_boundary;
+  if (preferred_stack_boundary > crtl->stack_alignment_needed)
+   crtl->stack_alignment_needed = preferred_stack_boundary;
+}

This means that for functions, emitted through emit_library_call, stack won't
be realigned. This would cure the assert (and would follow a bit more
expand_stack_alignment from cfgrtl.c).

[Bug tree-optimization/87415] [9 Regression] wrong code at -O1 and above on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
.

[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments

[jsm28 at gcc dot gnu.org]

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

Bug 82856 Summary: --enable-maintainter-mode broken by incompatiblity of gcc's 
required automake and modern Perl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

   What|Removed |Added

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

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.3 |9.0

--- Comment #11 from Joseph S. Myers  ---
Fixed for GCC 9 by updating the required automake version.

[Bug libgomp/87834] New: nvptx offloading: "WARNING: program timed out" for libgomp.fortran/target2.f90 execution test at -O0, -O1

[tschwinge at gcc dot gnu.org]

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

Bug ID: 87834
   Summary: nvptx offloading: "WARNING: program timed out" for
libgomp.fortran/target2.f90 execution test at -O0, -O1
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org, jakub at gcc dot gnu.org,
vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx-none

I'm aware of PR81691 "libgomp.fortran/target2.f90 fails for nvptx at -O0 and
-O1", but after r264397 "[nvptx] Remove use of CUDA unified memory in libgomp"
they now also run into "WARNING: program timed out", which is annoying.

PASS: libgomp.fortran/target2.f90   -O0  (test for excess errors)
{+WARNING: program timed out.+}
FAIL: libgomp.fortran/target2.f90   -O0  execution test
PASS: libgomp.fortran/target2.f90   -O1  (test for excess errors)
{+WARNING: program timed out.+}
FAIL: libgomp.fortran/target2.f90   -O1  execution test
PASS: libgomp.fortran/target2.f90   -O2  (test for excess errors)
PASS: libgomp.fortran/target2.f90   -O2  execution test

I have not yet analyzed what's causing this, but I have some ideas about
pending patches that might cure it.

[Bug libgomp/87835] New: nvptx offloading: libgomp.oacc-c-c++-common/asyncwait-1.c execution test intermittently fails at -O2

[tschwinge at gcc dot gnu.org]

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

Bug ID: 87835
   Summary: nvptx offloading:
libgomp.oacc-c-c++-common/asyncwait-1.c execution test
intermittently fails at -O2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org, jakub at gcc dot gnu.org,
vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx-none

After r264397 "[nvptx] Remove use of CUDA unified memory in libgomp", I'm
seeing (intermittently only, and only on some systems):

PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/asyncwait-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  (test for excess errors)
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/asyncwait-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/asyncwait-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  (test for excess errors)
[-PASS:-]{+FAIL:+}
libgomp.oacc-c/../libgomp.oacc-c-c++-common/asyncwait-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test

And/or:

PASS: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/asyncwait-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  (test for excess errors)
PASS: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/asyncwait-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O0  execution test
PASS: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/asyncwait-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  (test for excess errors)
[-PASS:-]{+FAIL:+}
libgomp.oacc-c++/../libgomp.oacc-c-c++-common/asyncwait-1.c
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0  -O2  execution test

I have not yet analyzed what's causing this, but I have some ideas about
pending patches that might cure it.

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #28)
> Let's ask Jakub about asan, if it is possible to move generation of the call
> after the function is already expanded to RTL.

I'm afraid no.

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #28 from Uroš Bizjak  ---
(In reply to Terry Guo from comment #25)
> Debugged the ICE further and found that below line in function
> ix86_get_drap_rtx is causing ICE:
> 
> 12050 insn = emit_insn_before (seq, NEXT_INSN (entry_of_function
> ()));
> 
> It is called when generating call to __asan_stack_free_5 via
> emit_library_call_value_1. The entry_of_function() is returned something
> invalid.

I wonder if it is correct for asan to emit the call without setting RTL
function framework first. The DRAP generation needs function in RTL form, so it
is able to emit DRAP setup.

Let's ask Jakub about asan, if it is possible to move generation of the call
after the function is already expanded to RTL.

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[jsm28 at gcc dot gnu.org]

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

--- Comment #10 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Oct 31 17:03:16 2018
New Revision: 265695

URL: https://gcc.gnu.org/viewcvs?rev=265695=gcc=rev
Log:
Update GCC to autoconf 2.69, automake 1.15.1 (PR bootstrap/82856).

This patch updates GCC to use autoconf 2.69 and automake 1.15.1.
(That's not the latest automake version, but it's the one used by
binutils-gdb, with which consistency is desirable, and in any case
seems a useful incremental update that should make a future update to
1.16.1 easier.)

The changes are generally similar to the binutils-gdb ones, and are
copied from there where shared files and directories are involved
(there are some further changes to such shared directories, however,
which I'd expect to apply to binutils-gdb once this patch is in GCC).
Largely, obsolete AC_PREREQ calls are removed, while many
AC_LANG_SOURCE calls are added to avoid warnings from aclocal and
autoconf.  Multilib support is no longer included in core automake,
meaning that multilib.am needs copying from automake's contrib
directory into the GCC source tree.  Autoconf 2.69 has Go support, so
local copies of that support are removed.  I hope the D support will
soon be submitted to upstream autoconf so the local copy of that can
be removed in a future update.  Changes to how automake generates
runtest calls mean quotes are removed from RUNTEST definitions in five
lib*/testsuite/Makefile.am files (libatomic, libgomp, libitm,
libphobos, libvtv; some others have RUNTEST definitions without
quotes, which are still OK); libgo and libphobos also get
-Wno-override added to AM_INIT_AUTOMAKE so those overrides of RUNTEST
do not generate automake warnings.

Note that the regeneration did not include regeneration of
fixincludes/config.h.in (attempting such regeneration resulted in all
the USED_FOR_TARGET conditionals disappearing; and I don't see
anything in the fixincludes/ directory that would result in such
conditionals being generated, unlike in the gcc/ directory).  Also
note that libvtv/testsuite/other-tests/Makefile.in was not
regenerated; that directory is not listed as a subdirectory for which
Makefile.in gets regenerated by calling "automake" in libvtv/, so I'm
not sure how it's meant to be regenerated.

While I mostly fixed warnings should running aclocal / automake /
autoconf, there were various such warnings from automake in the
libgfortran, libgo, libgomp, liboffloadmic, libsanitizer, libphobos
directories that I did not fix, preferring to leave those to the
relevant subsystem maintainers.  Specifically, most of those warnings
were of the following form (example from libgfortran):

Makefile.am:48: warning: source file 'caf/single.c' is in a subdirectory,
Makefile.am:48: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding
output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they
will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout
your
automake: project, to avoid future incompatibilities.

I think it's best for the relevant maintainers to add subdir-objects
and do any other associated Makefile.am changes needed.  In some cases
the paths in the warnings involved ../; I don't know if that adds any
extra complications to the use of subdir-objects.

I've tested this with native, cross and Canadian cross builds.  The
risk of any OS-specific issues should I hope be rather lower than if a
libtool upgrade were included (we *should* do such an upgrade at some
point, but it's more complicated - it involves identifying all our
local libtool changes to see if any aren't included in the upstream
version we update to, and reverting an upstream libtool patch that's
inappropriate for use in GCC); I think it would be better to get this
update into GCC so that people can test in different configurations
and we can fix any issues found, rather than to try to get more and
more testing done before it goes in.

top level:
2018-10-31  Joseph Myers  

PR bootstrap/82856
* multilib.am: New file.  From automake.

Merge from binutils-gdb:
2018-06-19  Simon Marchi  

* libtool.m4: Use AC_LANG_SOURCE.
* configure.ac: Remove AC_PREREQ, use AC_LANG_SOURCE.
* ar-lib: New file.
* test-driver: New file.
* configure: Re-generate.

config:
2018-10-31  Joseph Myers  

PR bootstrap/82856
* math.m4, tls.m4: Use AC_LANG_SOURCE.

Merge from binutils-gdb:
2018-06-19  Simon Marchi  

* override.m4 (_GCC_AUTOCONF_VERSION): Bump from 2.64 to 

[Bug target/87833] New: Intel MIC (emulated) offloading: "relocation [...] can not be used when making a shared object; recompile with -fPIC"

[tschwinge at gcc dot gnu.org]

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

Bug ID: 87833
   Summary: Intel MIC (emulated) offloading: "relocation [...] can
not be used when making a shared object; recompile
with -fPIC"
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, iverbin at gcc dot gnu.org,
jakub at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-intelmicemul-linux-gnu

Created attachment 44937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44937=edit
WIP patch/work around

Commit r263988 (for PR86517 "relocation R_X86_64_32 against `.rodata.str1.1'
can not be used when making a shared object with LTO") makes a lot of (or even
all?) Intel MIC offloading test cases fail to compile:

[...]/ld: /tmp/ccCCZyfF.o: relocation R_X86_64_32S against `[...]' can not
be used when making a shared object; recompile with -fPIC
/tmp/ccCCZyfF.o: error adding symbols: Bad value
mkoffload-intelmic: fatal error: [...]

I have not yet analyzed what's actually going wrong.  Before spending more time
on this, I first wanted to make sure that's still useful -- given that in the
past two months apparently nobody but me has run into this (or didn't bother to
report it), and I thus wonder whether anyone but me is still testing Intel MIC
(emulated) offloading?

No idea yet if the attached patch/hack is correct in any way, but it at least
restores Intel MIC (emulated) offloading compilation.

[Bug c++/82019] [concepts] ICE if concept is not satisfied

[antoshkka at gmail dot com]

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

--- Comment #1 from Antony Polukhin  ---
Trunk version of GCC (9.0) does not ICE any more.

This issue could be closed (but I'd appreciate if you could add example from
above to the test suite to avoid regressions).

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[davidegrayson at gmail dot com]

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

--- Comment #27 from David Grayson  ---
Thanks to everyone who is working on this.  I can confirm that the patch in
comment #20 by Uroš Bizjak applies cleanly to GCC 7.3.0, and I successfully
used the resulting toolchain targeting i686-w64-mingw32 to build Qt and several
Qt GUI examples, all of which run correctly.

Just in case it helps you find more bugs: I noticed there are several other
places in the code (of gcc-8-20181019) where ctrl->preferred_stack_boundary
gets updated without any obvious update of ctrl->stack_alignment_needed:

gcc/explow.c:1247 in get_dynamic_stack_size
gcc/explow.c:1595 in get_dynamic_stack_base
gcc/calls.c:3811 in expand_call
gcc/config/i386/i386.c:12593 in ix86_update_stack_boundary

[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #19 from Martin Liška  ---
The only missing pieces are 2c) and 3b). Which should leverage the new target
hook targetm_common.get_valid_option_values and provide list of possible
values.
I'm leaving that to ARM and aarch64 folks.

[Bug c/87806] Option -Wall should warn about unused structs, typdefs, enums, etc

[tavianator at gmail dot com]

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

Tavian Barnes  changed:

   What|Removed |Added

 CC||tavianator at gmail dot com

--- Comment #4 from Tavian Barnes  ---
Perhaps this is reasonable for types that are defined in the file itself, not
in an included header?

[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
Author: marxin
Date: Wed Oct 31 14:46:17 2018
New Revision: 265686

URL: https://gcc.gnu.org/viewcvs?rev=265686=gcc=rev
Log:
Provide extension hint for aarch64 target (PR driver/83193).

2018-10-31  Martin Liska  

PR driver/83193
* common/config/aarch64/aarch64-common.c (aarch64_parse_extension):
Add new argument invalid_extension.
(aarch64_get_all_extension_candidates): New function.
(aarch64_rewrite_selected_cpu): Add NULL to function call.
* config/aarch64/aarch64-protos.h (aarch64_parse_extension): Add
new argument.
(aarch64_get_all_extension_candidates): New function.
* config/aarch64/aarch64.c (aarch64_parse_arch): Add new
argument invalid_extension.
(aarch64_parse_cpu): Likewise.
(aarch64_print_hint_for_extensions): New function.
(aarch64_validate_mcpu): Provide hint about invalid extension.
(aarch64_validate_march): Likewise.
(aarch64_handle_attr_arch): Pass new argument.
(aarch64_handle_attr_cpu): Provide hint about invalid extension.
(aarch64_handle_attr_isa_flags): Likewise.
2018-10-31  Martin Liska  

PR driver/83193
* gcc.target/aarch64/spellcheck_7.c: New test.
* gcc.target/aarch64/spellcheck_8.c: New test.
* gcc.target/aarch64/spellcheck_9.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_7.c
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_8.c
trunk/gcc/testsuite/gcc.target/aarch64/spellcheck_9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/aarch64/aarch64-common.c
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/87830] [9 Regression] ICE in cp_var_mod_type_p at cp/cp-objcp-common.c:107 since r265638

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Btw, the "easy" solution for this bug is to re-set the var_mod_type_p langhook
in free-lang-data (to the default, hook_bool_tree_tree_false).

[Bug target/87832] New: AMD pipeline models are very costly size-wise

[amonakov at gcc dot gnu.org]

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

Bug ID: 87832
   Summary: AMD pipeline models are very costly size-wise
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Looking at i386 insn-automata.o, out of its 2.2M rodata size almost all is due
to very large tables for AMD CPU models. Note how znver additions are more than
half of overall size.

What is causing that and can it be improved?

2176 core2_core_transitions
2496 slm_base
2527 bdver3_load_min_issue_delay
2746 glm_base
3892 bdver1_fp_base
4261 insn_latency(rtx_insn*, rtx_insn*)
 bdver1_ieu_min_issue_delay
4492 geode_base
4608 bdver3_ieu_transitions
6402 bdver1_load_transitions
7862 athlon_fp_check
7862 athlon_fp_transitions
9433 internal_min_issue_delay(int, DFA_chip*)
10108 bdver3_load_transitions
10360 print_reservation(_IO_FILE*, rtx_insn*)::reservation_names
10498 geode_check
10498 geode_transitions
12575 athlon_fp_min_issue_delay
12599 internal_state_transition(int, DFA_chip*)
12742 btver2_fp_check
12742 btver2_fp_transitions
13896 slm_transitions
13896 slm_check
17776 bdver1_ieu_transitions
20068 bdver1_fp_check
20068 bdver1_fp_transitions
26208 slm_min_issue_delay
27244 bdver1_fp_min_issue_delay
28518 glm_transitions
28518 glm_check
33690 geode_min_issue_delay
46980 bdver3_fp_min_issue_delay
49428 glm_min_issue_delay
53730 btver2_fp_min_issue_delay
68160 znver1_ieu_min_issue_delay
93960 bdver3_fp_transitions
136320 znver1_ieu_transitions
428108 znver1_fp_min_issue_delay
856216 znver1_fp_transitions

[Bug lto/87830] [9 Regression] ICE in cp_var_mod_type_p at cp/cp-objcp-common.c:107 since r265638

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Hmm, I hope we can play with eliding the type copying during inlining somehow
...
(making VLA types "incomplete" given their sizes have been gimplified and debug
info has been generated - well, not fully ...).

[Bug middle-end/87831] Guard variable is not eliminated when there's nothing to guard

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-31
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

Not so easy task though, the middle-end doesn't know __cxa_guard_* is
"special".

[Bug middle-end/87831] New: Guard variable is not eliminated when there's nothing to guard

[antoshkka at gmail dot com]

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

Bug ID: 87831
   Summary: Guard variable is not eliminated when there's nothing
to guard
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

struct base {
base() {}
};

base& test() {
static base val;
return val;
}

For that example a lot of assembly is generated, including empty initialization
under the guard:

.L14:
 ; nothing to initialize
  mov edi, OFFSET FLAT:guard variable for test()::val
  call __cxa_guard_release
  mov eax, OFFSET FLAT:_ZZ4testvE3val
  add rsp, 8
  ret

Consider removing all the guard variable instructions if there's no
instructions for initialization.

[Bug lto/87830] [9 Regression] ICE in cp_var_mod_type_p at cp/cp-objcp-common.c:107 since r265638

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-31
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[xuepeng.guo at intel dot com]

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

--- Comment #26 from Terry Guo  ---
Hi Uroš:

I think I found why your proposed patch causes problem in Comment 23. It is all
about timing. The below code from patch is trying to set up DRAP reg in a
rather early stage when the function is not fully expanded to RTL.

+  if (crtl->drap_reg == NULL_RTX)
+   {
+ rtx drap_rtx = targetm.calls.get_drap_rtx ();

The targetm.calls.get_drap_rtx () will be hooked to ix86_get_drap_rtx () where
we will have code:

12046 drap_vreg = copy_to_reg (arg_ptr);
(gdb) 
12047 seq = get_insns ();
(gdb) 
12048 end_sequence ();
(gdb) 
12050 insn = emit_insn_before (seq, NEXT_INSN (entry_of_function ()));

At this stage, what returned from (entry_of_function ()) is actually GIMPLE
form of the function, not the RTL form we are expecting. Then NEXT_INSN
(something_in_gimple) goes wrong.

[Bug lto/87830] New: [9 Regression] ICE in cp_var_mod_type_p at cp/cp-objcp-common.c:107 since r265638

[marxin at gcc dot gnu.org]

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

Bug ID: 87830
   Summary: [9 Regression] ICE in cp_var_mod_type_p at
cp/cp-objcp-common.c:107 since r265638
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Following code (isolated from Libreoffice) causes ICE:

$ cat ice.ii
template  void ap(a);
template  struct b { template  b(at); };
void av();
template  void aw(a, ah... ay) {
  auto az = [&] { ap(ay...); };
  (*(decltype(az) *)av)();
}
class e {
  void be();

public:
  template  void bn(b) { aw(c, ::be); }
  int c;
} d;
void bq() { d.bn(b(1)); }

$ g++ -O -flto ice.ii -c
during GIMPLE pass: einline
ice.ii: In function ‘aw(int, void (e::*)())void’:
ice.ii:6:24: internal compiler error: Segmentation fault
6 |   (*(decltype(az) *)av)();
  |   ~^~
0xb8852f crash_signal
../../gcc/toplev.c:325
0x63228c cp_var_mod_type_p(tree_node*, tree_node*)
../../gcc/cp/cp-objcp-common.c:107
0xdc7a73 variably_modified_type_p(tree_node*, tree_node*)
../../gcc/tree.c:9065
0xdc7f0d variably_modified_type_p(tree_node*, tree_node*)
../../gcc/tree.c:9006
0xbede4c remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:600
0xbf320c copy_tree_body_r(tree_node**, int*, void*)
../../gcc/tree-inline.c:1304
0xdc6f65 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11632
0xdc750e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11950
0xbee1a6 remap_decls
../../gcc/tree-inline.c:683
0xbef021 remap_block
../../gcc/tree-inline.c:714
0xbef0f1 remap_blocks
../../gcc/tree-inline.c:736
0xbf5142 expand_call_inline
../../gcc/tree-inline.c:4605
0xbf6904 gimple_expand_calls_inline
../../gcc/tree-inline.c:4886
0xbf6904 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5026
0x12e08c1 early_inliner(function*)
../../gcc/ipa-inline.c:2797

[Bug libstdc++/84323] call_once uses TLS even when once_flag is set

[antoshkka at gmail dot com]

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

--- Comment #3 from Antony Polukhin  ---
Just noted that libc++ already does this optimization:
https://godbolt.org/z/alw1sq

libc++ directly accesses the content of std::once_flag and skips all the thread
local accesses if call_once previously succeeded.

[Bug libstdc++/86751] [6/7/8 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

Bug 87822 Summary: [6/7/8/9 Regression] Binary incompatibility in std::pair 
introduced by PR 86751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87822

   What|Removed |Added

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

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.4.0, 7.3.0, 8.2.0
 Resolution|--- |FIXED
  Known to fail||6.4.1, 7.3.1, 8.2.1, 9.0

--- Comment #14 from Jonathan Wakely  ---
.

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Created attachment 44936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44936=edit
Patch for GCC 6.5

Fixed in the gcc-7 and gcc-8 branches.

This will not be fixed on gcc-6-branch, but for anybody who wants to apply it
locally, the patch for GCC 6.5 is attached, and reproduced here:

--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -187,7 +187,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   };
 #endif // C++11

-  class __pair_base
+  template class __pair_base
   {
 #if __cplusplus >= 201103L
 template friend struct pair;
@@ -206,7 +206,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*/
   template
 struct pair
-: private __pair_base
+: private __pair_base<_T1, _T2>
 {
   typedef _T1 first_type;/// @c first_type is the first bound type
   typedef _T2 second_type;   /// @c second_type is the second bound type

[Bug libstdc++/86751] [6/7/8 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 31 13:16:10 2018
New Revision: 265683

URL: https://gcc.gnu.org/viewcvs?rev=265683=gcc=rev
Log:
PR libstdc++/87822 fix layout change for nested std::pair

The introduction of the empty __pair_base base class for PR 86751
changed the layout of std::pair, ...>. The outer pair and
its first member both have a base class of the same type, which cannot
exist at the same address. This causes the first member to be at a
non-zero offset.

The solution is to make the base class depend on the template
parameters, so that each pair type has a different base class type,
which allows the base classes of the outer pair and its first member to
have the same address.

PR libstdc++/87822
* include/bits/stl_pair.h (__pair_base): Change to class template.
(pair): Make base class type depend on template parameters.
* testsuite/20_util/pair/87822.cc: New test.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/pair/87822.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/stl_pair.h

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 31 13:16:10 2018
New Revision: 265683

URL: https://gcc.gnu.org/viewcvs?rev=265683=gcc=rev
Log:
PR libstdc++/87822 fix layout change for nested std::pair

The introduction of the empty __pair_base base class for PR 86751
changed the layout of std::pair, ...>. The outer pair and
its first member both have a base class of the same type, which cannot
exist at the same address. This causes the first member to be at a
non-zero offset.

The solution is to make the base class depend on the template
parameters, so that each pair type has a different base class type,
which allows the base classes of the outer pair and its first member to
have the same address.

PR libstdc++/87822
* include/bits/stl_pair.h (__pair_base): Change to class template.
(pair): Make base class type depend on template parameters.
* testsuite/20_util/pair/87822.cc: New test.

Added:
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/pair/87822.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/stl_pair.h

[Bug libstdc++/86751] [6/7/8 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 31 13:03:25 2018
New Revision: 265681

URL: https://gcc.gnu.org/viewcvs?rev=265681=gcc=rev
Log:
PR libstdc++/87822 fix layout change for nested std::pair

The introduction of the empty __pair_base base class for PR 86751
changed the layout of std::pair, ...>. The outer pair and
its first member both have a base class of the same type, which cannot
exist at the same address. This causes the first member to be at a
non-zero offset.

The solution is to make the base class depend on the template
parameters, so that each pair type has a different base class type,
which allows the base classes of the outer pair and its first member to
have the same address.

PR libstdc++/87822
* include/bits/stl_pair.h (__pair_base): Change to class template.
(pair): Make base class type depend on template parameters.
* testsuite/20_util/pair/87822.cc: New test.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/pair/87822.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/stl_pair.h

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 31 13:03:25 2018
New Revision: 265681

URL: https://gcc.gnu.org/viewcvs?rev=265681=gcc=rev
Log:
PR libstdc++/87822 fix layout change for nested std::pair

The introduction of the empty __pair_base base class for PR 86751
changed the layout of std::pair, ...>. The outer pair and
its first member both have a base class of the same type, which cannot
exist at the same address. This causes the first member to be at a
non-zero offset.

The solution is to make the base class depend on the template
parameters, so that each pair type has a different base class type,
which allows the base classes of the outer pair and its first member to
have the same address.

PR libstdc++/87822
* include/bits/stl_pair.h (__pair_base): Change to class template.
(pair): Make base class type depend on template parameters.
* testsuite/20_util/pair/87822.cc: New test.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/pair/87822.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/stl_pair.h

[Bug d/87827] libgphobos.spec in the wrong place with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Actually it applies to all of the library, not only the .spec file.

[Bug web/87829] Contradiction about -fReorder-Blocks

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Let me fix that.

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[romain.geissler at amadeus dot com]

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

--- Comment #10 from Romain Geissler  ---
Thanks for the quick patch !

If no commit is planned in the branch 6, I am going to apply this patch on top
myself. I hope people do read the release notes to figure out about this
potential ABI breaking.

[Bug c/86420] [9 regression] nextafter(0x1p-1022,0) is constant folded

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 31 12:29:02 2018
New Revision: 265678

URL: https://gcc.gnu.org/viewcvs?rev=265678=gcc=rev
Log:
PR libstdc++/87822 fix layout change for nested std::pair

The introduction of the empty __pair_base base class for PR 86751
changed the layout of std::pair, ...>. The outer pair and
its first member both have a base class of the same type, which cannot
exist at the same address. This causes the first member to be at a
non-zero offset.

The solution is to make the base class depend on the template
parameters, so that each pair type has a different base class type,
which allows the base classes of the outer pair and its first member to
have the same address.

PR libstdc++/87822
* include/bits/stl_pair.h (__pair_base): Change to class template.
(pair): Make base class type depend on template parameters.
* testsuite/20_util/pair/87822.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/pair/87822.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_pair.h

[Bug libstdc++/86751] [6/7/8 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 31 12:29:02 2018
New Revision: 265678

URL: https://gcc.gnu.org/viewcvs?rev=265678=gcc=rev
Log:
PR libstdc++/87822 fix layout change for nested std::pair

The introduction of the empty __pair_base base class for PR 86751
changed the layout of std::pair, ...>. The outer pair and
its first member both have a base class of the same type, which cannot
exist at the same address. This causes the first member to be at a
non-zero offset.

The solution is to make the base class depend on the template
parameters, so that each pair type has a different base class type,
which allows the base classes of the outer pair and its first member to
have the same address.

PR libstdc++/87822
* include/bits/stl_pair.h (__pair_base): Change to class template.
(pair): Make base class type depend on template parameters.
* testsuite/20_util/pair/87822.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/pair/87822.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_pair.h

[Bug c++/86608] [7/8/9 Regression] volatile variable is taken as a constexpr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/86586] [7/8/9 Regression] -Wsign-compare affects code generation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug fortran/86470] [7/8/9 Regression] [OOP] ICE with OMP

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug libstdc++/87520] [8/9 Regression] ODR violations in std::make_shared when mixing -fno-rtti and -frtti

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c/86420] [9 regression] nextafter(0x1p-1022,0) is constant folded

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug middle-end/87489] [8/9 Regression] Spurious -Wnonnull warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.3

[Bug c++/87366] [7/8/9 Regression] SFINAE trait as template parameter causes incorrect application of trait to other areas

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/85136] [7 Regression] ICE with array as template variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/85114] [7 Regression] -fstack-check causes ICE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/84191] [7 Regression] Compiler ICEs when trying to resolve impossible arithmetic operations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/87776] [9 Regression] Compile time hog during RPO VN

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine, somehow missed this.

[Bug rtl-optimization/83972] [7 Regression] ICE in code_motion_process_successors, at sel-sched.c:6398

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug target/24012] [7/8/9 regression] #define _POSIX_C_SOURCE breaks #include

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/80916] [7/8/9 Regression] Spurious "declared 'static' but never defined" warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug tree-optimization/87776] [9 Regression] Compile time hog during RPO VN

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/78986] [7/8/9 Regression] template inner classes are not affected by access specifiers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/87742] [7/8/9 Regression] false warning: array subscript 3 is above array bounds of 'const std::type_info* const [3]'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/87828] [7 Regression] g++ crashes in sizeof within lambda (ice-on-valid)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||ice-on-valid-code
   Priority|P3  |P2
Summary|g++ crashes in sizeof   |[7 Regression] g++ crashes
   |within lambda   |in sizeof within lambda
   |(ice-on-valid)  |(ice-on-valid)

[Bug web/87829] Contradiction about -fReorder-Blocks

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-31
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
These are two different but yes, the -freorder-blocks info looks wrong,
it is indeed enabled with -Os, thust the algorithm used is different.

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Wed, 31 Oct 2018, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87822
> 
> --- Comment #7 from Jonathan Wakely  ---
> (In reply to Richard Biener from comment #5)
> > Unfortunate :/  Can you add a 6.5 specific note to 6.5/changes.html?
> 
> Will do.
> 
> I think it would also be good to commit the fix to the gcc-6-branch, even if
> it's closed, so it can be picked up from there if needed.

Hmm.  I think it may be better to provide the fix as patch, referenced
from the changes.html note?

> Do we even want to consider a 6.6 release, or just officially bless a 6.5.1
> snapshot post-fix?

Neither of that (there are no further snapshots from the branch anyways).
Since 6.5 isn't supported anymore I'd rather point people to 7.x.

[Bug tree-optimization/86270] [8/9 Regression] Simple loop needs an extra register and an extra instruction

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 31 11:57:33 2018
New Revision: 265677

URL: https://gcc.gnu.org/viewcvs?rev=265677=gcc=rev
Log:
2018-10-31  Richard Biener  

PR middle-end/70359
PR middle-end/86270
* tree-outof-ssa.c (insert_backedge_copies): Restrict
copy generation to useful cases.  Place the copy before
the definition of the backedge value when possible.

* gcc.target/i386/pr70359.c: New testcase.
* gcc.target/i386/pr86270.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70359.c
trunk/gcc/testsuite/gcc.target/i386/pr86270.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-outof-ssa.c

[Bug middle-end/70359] [7/8/9 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[rguenth at gcc dot gnu.org]

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

--- Comment #47 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 31 11:57:33 2018
New Revision: 265677

URL: https://gcc.gnu.org/viewcvs?rev=265677=gcc=rev
Log:
2018-10-31  Richard Biener  

PR middle-end/70359
PR middle-end/86270
* tree-outof-ssa.c (insert_backedge_copies): Restrict
copy generation to useful cases.  Place the copy before
the definition of the backedge value when possible.

* gcc.target/i386/pr70359.c: New testcase.
* gcc.target/i386/pr86270.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70359.c
trunk/gcc/testsuite/gcc.target/i386/pr86270.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-outof-ssa.c

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[xuepeng.guo at intel dot com]

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

--- Comment #25 from Terry Guo  ---
Debugged the ICE further and found that below line in function
ix86_get_drap_rtx is causing ICE:

12050 insn = emit_insn_before (seq, NEXT_INSN (entry_of_function ()));

It is called when generating call to __asan_stack_free_5 via
emit_library_call_value_1. The entry_of_function() is returned something
invalid.

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #5)
> Unfortunate :/  Can you add a 6.5 specific note to 6.5/changes.html?

Will do.

I think it would also be good to commit the fix to the gcc-6-branch, even if
it's closed, so it can be picked up from there if needed.

Do we even want to consider a 6.6 release, or just officially bless a 6.5.1
snapshot post-fix?

[Bug web/87829] New: Contradiction about -fReorder-Blocks

[mcccs at gmx dot com]

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

Bug ID: 87829
   Summary: Contradiction about -fReorder-Blocks
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcccs at gmx dot com
  Target Milestone: ---

On this page: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
(invoke.texi)
It says:

@option{-Os} disables the following optimization flags:
@gccoptlist{-falign-functions  -falign-jumps  -falign-loops @gol
-falign-labels  -freorder-blocks  -freorder-blocks-algorithm=stc @gol
-freorder-blocks-and-partition  -fprefetch-loop-arrays}

If you scroll down, it says:

@item -freorder-blocks
@opindex freorder-blocks
Reorder basic blocks in the compiled function in order to reduce number of
taken branches and improve code locality.

Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, @option{-Os}.

Is it enabled in -Os or not? They contradict.

Also for -freorder-blocks-algorithm and -freorder-blocks-and-partition

[Bug ada/40025] gnatmake does not honour project files' Library_Version exactly

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||charlet at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Arnaud Charlet  ---
Good point, closing PR.

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
It only affects std::pair, z> (for any x, y, z) i.e. when the
first member of the pair is also a pair.

[Bug ada/40025] gnatmake does not honour project files' Library_Version exactly

[nicolas.boulenguez at free dot fr]

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

Nicolas Boulenguez  changed:

   What|Removed |Added

 CC||nicolas.boulenguez at free dot 
fr

--- Comment #2 from Nicolas Boulenguez  ---
Hello.
Gcc-9 stops supporting GPR projects, and gprbuild uses the given Shared Object
name.
Does anyone object to close this bug and remove
ada-library-project-files-soname.diff from the Debian packaging?

[Bug c++/87828] g++ crashes in sizeof within lambda (ice-on-valid)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-31
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||6.4.0, 8.2.0, 9.0
   Target Milestone|--- |7.4
 Ever confirmed|0   |1
  Known to fail||7.3.0

--- Comment #1 from Martin Liška  ---
Confirmed, only GCC-7 branch is affected. Fixed on trunk in r236615.

[Bug c++/87828] New: g++ crashes in sizeof within lambda (ice-on-valid)

[janniksilvanus at gmail dot com]

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

Bug ID: 87828
   Summary: g++ crashes in sizeof within lambda (ice-on-valid)
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janniksilvanus at gmail dot com
  Target Milestone: ---

: g++-7 --version
g++-7 (SUSE Linux) 7.3.1 20180817 [gcc-7-branch revision 263612]
Copyright (C) 2017 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. 

: cat test.ii

struct Test {
   Test();
   Test(Test &);
   int getint();
};

template 
void call_applier(Applier && f) {
   f(int());
}

Test run() {
   Test test;
   call_applier([=](auto) {
  sizeof(test.getint());
   });
   return test;
}


: g++-7 -std=c++1z -Wmissing-format-attribute -c test.ii
test.ii: In instantiation of ‘run():: [with auto:1 = int]’: 
test.ii:9:5:   required from ‘void call_applier(Applier&&) [with Applier =
run()::]’  
test.ii:16:5:   required from here
test.ii:15:25: internal compiler error: Segmentation fault
   sizeof(test.getint());
 ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Note the weird -Wmissing-format-attribute flag which is required to trigger the
crash, although it seems to be completely unrelated.

[Bug d/87827] New: libgphobos.spec in the wrong place with --enable-version-specific-runtime-libs

[rguenth at gcc dot gnu.org]

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

Bug ID: 87827
   Summary: libgphobos.spec in the wrong place with
--enable-version-specific-runtime-libs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

It ends up in /usr/lib* while it should be in /usr/lib*/gcc/$target/$version/
instead (where for example libgomp.spec ends up).  libgomp uses
toolexeclib_HEADERS for this.  I see libphobos does so as well so that's not
enough it seems.  See the enable_version_specific_runtime_libs handling in
configure of libgomp, libphobos lacks handling completely it seems.

[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  ---
bootstrap succeeded on x86_64-darwin16 --enable-languages=all for 265659.

Shall we leave this PR open as a place to track getting D working on Darwin?
.. or open a new one?

(I guess from the point of view of archeology, the latter might be better than
re-classifying this one to 'target').

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #4)
> The fix isn't in any other releases yet, only 6.5

Unfortunate :/  Can you add a 6.5 specific note to 6.5/changes.html?

How pervasive is this issue?

[Bug tree-optimization/87826] ubsan: gimple-ssa-store-merging.c:281

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The fix isn't in any other releases yet, only 6.5

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Romain Geissler from comment #0)
> (introduce a new
> tagged std::pair type and provide dual abi ?).

No, no, no! Anything but that.

[Bug libstdc++/87822] [6/7/8/9 Regression] Binary incompatibility in std::pair introduced by PR 86751

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-31
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Argh, dammit. Yes, it should have been a template.

[Bug target/87374] [8/9 Regression] ICE in extract_insn, at recog.c:2305

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Oct 31 10:05:54 2018
New Revision: 265662

URL: https://gcc.gnu.org/viewcvs?rev=265662=gcc=rev
Log:
Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

GCC ICEs under -mslow-flash-data and -mword-relocations because there
is no way to load an address, both literal pools and MOVW/MOVT being
forbidden. This patch gives an error message when both options are
specified by the user and adds the according dg-skip-if directives for
tests that use either of these options. It also explicitely set the
option when in PIC mode as per documentation rather than always check
for target_word_relocation together with flag_pic.

2018-10-31  Thomas Preud'homme  

gcc/
PR target/87374
* config/arm/arm.c (arm_option_check_internal): Disable the combined
use of -mslow-flash-data and -mword-relocations.
(arm_option_override): Enable -mword-relocations if -fpic or -fPIC.
* config/arm/arm.md (SYMBOL_REF MOVT splitter): Stop checking for
flag_pic.
* doc/invoke.texi (-mword-relocations): Mention conflict with
-mslow-flash-data.
(-mslow-flash-data): Reciprocally.

gcc/testsuite/
PR target/87374
* gcc.target/arm/movdi_movt.c: Skip if both -mslow-flash-data and
-mword-relocations would be passed when compiling the test.
* gcc.target/arm/movsi_movt.c: Likewise.
* gcc.target/arm/pr81863.c: Likewise.
* gcc.target/arm/thumb2-slow-flash-data-1.c: Likewise.
* gcc.target/arm/thumb2-slow-flash-data-2.c: Likewise.
* gcc.target/arm/thumb2-slow-flash-data-3.c: Likewise.
* gcc.target/arm/thumb2-slow-flash-data-4.c: Likewise.
* gcc.target/arm/thumb2-slow-flash-data-5.c: Likewise.
* gcc.target/arm/tls-disable-literal-pool.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/movdi_movt.c
trunk/gcc/testsuite/gcc.target/arm/movsi_movt.c
trunk/gcc/testsuite/gcc.target/arm/pr81863.c
trunk/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-1.c
trunk/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-2.c
trunk/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-3.c
trunk/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-4.c
trunk/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-5.c
trunk/gcc/testsuite/gcc.target/arm/tls-disable-literal-pool.c

[Bug c/87826] ubsan: gimple-ssa-store-merging.c:281

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Cleaned up:
int c;

void
foo (int *b)
{
  int e;
  for (e = 0; e < 16; ++e)
b[e] = c >> e * 8;
}

The testcase with UB in it if the function is ever called has the loop unrolled
by cunroll and we end up with out of bound shifts.  Store-merging should just
punt in that case.

[Bug d/87818] D runtime does not build on FreeBSD.

[ibuclaw at gcc dot gnu.org]

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

--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Oct 31 09:44:31 2018
New Revision: 265658

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

2018-10-31  Iain Buclaw  

PR bootstrap/87788
PR d/87799
* configure: Rebuild.
* configure.ac: Disable D on systems where it is known not to work.

libphobos/ChangeLog:

2018-10-31  Iain Buclaw  

PR bootstrap/87789
PR d/87818
PR d/87819
* configure.tgt: New file.

Added:
trunk/libphobos/configure.tgt
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/libphobos/ChangeLog

[Bug d/87789] D does not build on powerpc64-linux

[ibuclaw at gcc dot gnu.org]

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

--- Comment #3 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Oct 31 09:44:31 2018
New Revision: 265658

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

2018-10-31  Iain Buclaw  

PR bootstrap/87788
PR d/87799
* configure: Rebuild.
* configure.ac: Disable D on systems where it is known not to work.

libphobos/ChangeLog:

2018-10-31  Iain Buclaw  

PR bootstrap/87789
PR d/87818
PR d/87819
* configure.tgt: New file.

Added:
trunk/libphobos/configure.tgt
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/libphobos/ChangeLog

[Bug d/87819] failure during bootstrap, fails to build libdruntime

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Oct 31 09:44:31 2018
New Revision: 265658

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

2018-10-31  Iain Buclaw  

PR bootstrap/87788
PR d/87799
* configure: Rebuild.
* configure.ac: Disable D on systems where it is known not to work.

libphobos/ChangeLog:

2018-10-31  Iain Buclaw  

PR bootstrap/87789
PR d/87818
PR d/87819
* configure.tgt: New file.

Added:
trunk/libphobos/configure.tgt
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/libphobos/ChangeLog

[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[ibuclaw at gcc dot gnu.org]

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

--- Comment #12 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Oct 31 09:44:31 2018
New Revision: 265658

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

2018-10-31  Iain Buclaw  

PR bootstrap/87788
PR d/87799
* configure: Rebuild.
* configure.ac: Disable D on systems where it is known not to work.

libphobos/ChangeLog:

2018-10-31  Iain Buclaw  

PR bootstrap/87789
PR d/87818
PR d/87819
* configure.tgt: New file.

Added:
trunk/libphobos/configure.tgt
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/libphobos/ChangeLog

[Bug d/87799] failure during bootstrap, fails to build d/filename.o

[ibuclaw at gcc dot gnu.org]

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

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Wed Oct 31 09:44:31 2018
New Revision: 265658

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

2018-10-31  Iain Buclaw  

PR bootstrap/87788
PR d/87799
* configure: Rebuild.
* configure.ac: Disable D on systems where it is known not to work.

libphobos/ChangeLog:

2018-10-31  Iain Buclaw  

PR bootstrap/87789
PR d/87818
PR d/87819
* configure.tgt: New file.

Added:
trunk/libphobos/configure.tgt
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
trunk/libphobos/ChangeLog

[Bug c/87826] ubsan: gimple-ssa-store-merging.c:281

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
svn blame says

254947  jakub   n->n >>= count;

[Bug c/87826] New: ubsan: gimple-ssa-store-merging.c:281

[dcb314 at hotmail dot com]

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

Bug ID: 87826
   Summary: ubsan: gimple-ssa-store-merging.c:281
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

$ ../results.265631.ubsan/bin/gcc -c -O3 bug472.c
../../trunk/gcc/gimple-ssa-store-merging.c:281:12: runtime error: shift
exponent 64 is too large for 64-bit type 'long unsigned int'
$ 

For this C code:

typedef a;
*b;
c;
d() {
  a e, f = 8 + 8;
  e = 0;
  for (; e < f; ++e)
b[e] = c >> e * 8;
}

The bug seems to be sometime before revision 264725.