[Bug d/87824] x86_64-linux multilib issues

[ibuclaw at gcc dot gnu.org]

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

--- Comment #14 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Thu Nov 22 06:14:47 2018
New Revision: 266366

URL: https://gcc.gnu.org/viewcvs?rev=266366&root=gcc&view=rev
Log:
libphobos/ChangeLog:

2018-11-22  Johannes Pfau  

PR d/87824
* testsuite/libphobos.shared/shared.exp: Set proper path to phobos
library for multilib builds.

Modified:
trunk/libphobos/ChangeLog
trunk/libphobos/testsuite/libphobos.shared/shared.exp

[Bug c/88144] remove long-obsolete syntax for designated initializers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> I think one of the reasons why it has not been removed is there is still
> code out there that uses this syntax.
> If anything we should add a warning about it first if we are going to remove
> it.

There's a warning from -Wpedantic at least:

$ /usr/local/bin/gcc -c -Wall -Wextra -pedantic 88144.c
88144.c:2:21: warning: obsolete use of designated initializer with ':'
[-Wpedantic]
2 | struct point p = { x: 69, y: 42 };
  | ^
88144.c:2:28: warning: obsolete use of designated initializer with ':'
[-Wpedantic]
2 | struct point p = { x: 69, y: 42 };
  |^
$

But maybe it should be moved to a different flag that's also enabled by -Wextra
or -Wall or maybe even by default, too, besides just -Wpedantic, though. And
also have a fix-it hint added to use the new (standard) syntax.

[Bug other/704] --help and --version

[egallager at gcc dot gnu.org]

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

--- Comment #16 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #15)
> Author: iains
> Date: Wed Aug 22 12:12:46 2018
> New Revision: 263768
> 
> URL: https://gcc.gnu.org/viewcvs?rev=263768&root=gcc&view=rev
> Log:
> Make the gcc-ar,nm, strip tools respond correctly to --help and --version
> when there's no plugin built.
> 
> gcc/
> 
>   PR other/704
>   * gcc-ar.c (main): Don’t try to invoke the plug-in if we’re not
>   building it.
> 
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/gcc-ar.c

So can this be closed now?

[Bug target/88145] New: ICE: unrecognizable insn (mffs) targeting 32-bit BE FPU-less powerpc CPUs

[asolokha at gmx dot com]

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

Bug ID: 88145
   Summary: ICE: unrecognizable insn (mffs) targeting 32-bit BE
FPU-less powerpc CPUs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc-9.0.0-alpha20181118 snapshot (r266255) ICEs when compiling
gcc/testsuite/gcc.target/powerpc/test_mffsl.c for 32-bit powerpc cores that
don't include a FPU:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -mcpu=e300c2 -c
gcc/testsuite/gcc.target/powerpc/test_mffsl.c -o /dev/null  
gcc/testsuite/gcc.target/powerpc/test_mffsl.c: In function 'main':
gcc/testsuite/gcc.target/powerpc/test_mffsl.c:20:3: error: impossible
constraint in 'asm'
   20 |   __asm __volatile ("mffs %0" : "=f"(f14));
  |   ^
gcc/testsuite/gcc.target/powerpc/test_mffsl.c:32:1: error: unrecognizable insn:
   32 | }
  | ^
(insn 9 8 10 2 (set (reg:DF 128)
(unspec_volatile:DF [
(const_int 0 [0])
] UNSPECV_MFFS))
"gcc/testsuite/gcc.target/powerpc/test_mffsl.c":23:21 -1
 (nil))
during RTL pass: vregs
gcc/testsuite/gcc.target/powerpc/test_mffsl.c:32:1: internal compiler error: in
extract_insn, at recog.c:2305
0x639917 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:108
0x639935 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:116
0x637d86 extract_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/recog.c:2305
0xa2dbf2 instantiate_virtual_regs_in_insn
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1605
0xa2dbf2 instantiate_virtual_regs
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1975
0xa2dbf2 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:2024

gcc 4.9.4 correctly rejects it w/ "error: impossible constraint in 'asm'" and
w/o ICE, as does any version of the powerpcspe backend.

Also, shouldn't the rs6000 backend reject it when compiling for 85xx CPUs? I
see standard FPU instructions in the generated code which I believe shouldn't
be there. Maybe -mcpu=854[08] should be removed from the rs6000 backend
altogether, duplicating what was done in the powerpcspe backend previously w/
all non-SPE -mcpu's?

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
And if my guess that the problem is somehow related to the handling of FPU-less
cores in the rs6000 and powerpcspe backends is correct, than I see whan might
be another manifestation of that issue:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -mcpu=e300c2 --param
ggc-min-expand=3 --param ggc-min-heapsize=1024 -c
gcc/testsuite/gcc.dg/pr65345-3.c
gcc/testsuite/gcc.dg/pr65345-3.c:18:12: error: initializer element is not
constant
   18 | float c1 = i; /* { dg-error "initializer element is not constant" } */
  |^
gcc/testsuite/gcc.dg/pr65345-3.c:19:12: error: initializer element is not
constant
   19 | float c2 = (i ? 1 : 2); /* { dg-error "initializer element is not
constant" } */
  |^
gcc/testsuite/gcc.dg/pr65345-3.c:20:7: error: variably modified 'c3' at file
scope
   20 | float c3[(int) i]; /* { dg-error "variably modified" } */
  |   ^~
gcc/testsuite/gcc.dg/pr65345-3.c:21:12: error: initializer element is not
constant
   21 | float c4 = 0 || i; /* { dg-error "initializer element is not constant"
} */
  |^
gcc/testsuite/gcc.dg/pr65345-3.c:22:1: internal compiler error: Segmentation
fault
   22 | float c5 = (i += 10); /* { dg-error "initializer element is not
constant" } */
  | ^
0xd16576 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/toplev.c:325
0xfc99af contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree.h:3267
0xfc99af build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree.c:11278
0xfc9c11 build_call_expr(tree_node*, int, ...)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree.c:11328
0x10488e3 rs6000_atomic_assign_expand_fenv
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/config/rs6000/rs6000.c:38296
0x7a6a18 build_atomic_assign
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-typeck.c:4210
0x7b55e2 build_modify_expr(unsigned int, tree_node*, tree_node*, tree_code,
unsigned int, tree_node*, tree_node*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-typeck.c:6186
0x7cf936 c_parser_expr_no_commas
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:6632
0x7cfa5e c_parser_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:9486
0x7c38fb c_parser_postfix_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:7991
0x7cd1fa c_parser_unary_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:7289
0x7cdf07 c_parser_cast_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:7133
0x7ce154 c_parser_binary_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:6936
0x7cf07b c_parser_conditional_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:6670
0x7cf73b c_parser_expr_no_commas
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:6587
0x7d47bb c_parser_initializer
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:4547
0x7e1186 c_parser_declaration_or_fndef
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:2129
0x7e8c77 c_parser_external_declaration
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:1651
0x7e9341 c_parser_translation_unit
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:1532
0x7e9341 c_parse_file()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:19609

[Bug c/88144] remove long-obsolete syntax for designated initializers

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think one of the reasons why it has not been removed is there is still code
out there that uses this syntax.
If anything we should add a warning about it first if we are going to remove
it.

[Bug target/37760] internal compiler error: in extract_insn, at recog.c:1990

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
Does it still ICE? I cannot reproduce it w/ gcc 5.4.0 or newer.

[Bug other/88141] Issues with texinfo when building GCC r266351 in MSYS2

[jmm4077 at rit dot edu]

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

--- Comment #1 from Joshua Morrison  ---
I should also add that my installation of MSYS2 is up-to-date, including the
installation of texinfo. This is what makeinfo outputs when you pass it -V:

$ makeinfo -V
texi2any (GNU texinfo) 6.5

Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
I also see it when compiling gcc/testsuite/gcc.dg/pr37353.c for 32-bit BE
powerpc:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -O1 -ffinite-math-only
-fno-tree-forwprop -fno-tree-ter -c gcc/testsuite/gcc.dg/pr37353.c -o /dev/null 
gcc/testsuite/gcc.dg/pr37353.c: In function 'foo':
gcc/testsuite/gcc.dg/pr37353.c:15:1: error: unrecognizable insn:
   15 | }
  | ^
(insn 10 9 11 2 (set (reg:SI 127)
(unlt:SI (reg:CCFP 128)
(const_int 0 [0]))) -1
 (nil))
during RTL pass: vregs
gcc/testsuite/gcc.dg/pr37353.c:15:1: internal compiler error: in extract_insn,
at recog.c:2305
0x639917 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:108
0x639935 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:116
0x637d86 extract_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/recog.c:2305
0xa2dbf2 instantiate_virtual_regs_in_insn
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1605
0xa2dbf2 instantiate_virtual_regs
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1975
0xa2dbf2 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:2024

(as of r266255).

[Bug c/88144] New: remove long-obsolete syntax for designated initializers

[sandra at gcc dot gnu.org]

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

Bug ID: 88144
   Summary: remove long-obsolete syntax for designated
initializers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

The GCC manual documents alternative syntax for designated initializers that it
describes as "obsolete since GCC 2.5".  It appears this syntax is still
accepted in both C and C++.

GCC 2.5 was released in 1993.  Why is this still a part of GCC?  Shouldn't
things that have been obsolete this long simply be removed?  Or, if the
alternative syntax is not obsolete after all, the docs should be fixed not to
say that it is.

Test case:

struct point { int x, y; };
struct point p = { x: 69, y: 42 };

[Bug c++/88123] [8/9 Regression] faulty qualified name lookup of overloaded operator within generic lambda via using-directive

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
The error started with r258502.

[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type

[vmakarov at gcc dot gnu.org]

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

--- Comment #17 from Vladimir Makarov  ---
  I've reproduced it.  Clearly, it is some bug in LRA conflict calculation.  I
will be working on it.

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
(In reply to rguent...@suse.de from comment #3)
> The 
> powerpc64[le]-linux crosses insist that -mcpu=860 requires a 64bit CPU...

Which is strange, as 860 is a 32-bit CPU w/o FPU (perhaps a key here?)
introduced in the 90s[1,2]. Other -mcpu values for reproduction of this ICE are
all 4xx and 8xx (not including their corresponding fp variants) and e300c2 and
ec603e, all of which also don't include a FPU. Additionally, the powerpcspe
target doesn't need to specify -mcpu at all, as it implements floating-point
and SIMD ISA with its specific non-standard SPE unit which reuses integer GPRs.

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -v   
Using built-in specs.
COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/lto-wrapper
Target: powerpc-e300c3-linux-gnu
Configured with:
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/configure
--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/9.0.0-alpha20181118
--includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/include
--datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118
--mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/man
--infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/include/g++-v9
--with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=yes --disable-esp
--enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec
--disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto
--with-isl --disable-isl-version-check --disable-libsanitizer
Thread model: posix
gcc version 9.0.0-alpha20181118 20181118 (experimental) (GCC)

[1] https://www.nxp.com/docs/en/data-sheet/MPC860.pdf
[2] https://www.nxp.com/docs/en/reference-manual/MPC860UM.pdf

[Bug c/53182] GNU C: attributes without underscores should be discouraged / no longer be documented e.g. as examples

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
On this issue I'd like to get agreement from a broader community that it is a
good idea to deprecate the non-underscore names before implementing the
documentation changes.  I also think there are other compilers that have copied
the GCC attribute syntax; do they also recognize both the underscore and
non-underscore name variants?

The edits for this would be fairly mechanical, but I'm concerned that it won't
help readability of the manual, and would be confusing to people who have some
existing code with some attributes not using the __foo__ convention that they
want to look up.  At the very least we'd want to index both names.  

Also the optional underscore naming is currently explained in the attribute
syntax section, which appears after the sections where all the different
flavors of attributes are listed.  That would need to be moved to a more
prominent location.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #17 from Eric Botcazou  ---
>> Anybody should be able to reproduce this problem.  My guess is a logic error.
>
> I'm not sure whether we still support the native assembler on Solaris.  
> Rainer,
> do you still test it?

We do: I regularly test both as/ld, gas/ld, and gas/gld on Solaris/SPARC
and x86, even reporting /bin/as bugs upstream (and getting them fixed ;-)

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #17 from Eric Botcazou  ---
> I have a clue now.  I built gcc-7 on OI-SPARC with the GNU assembler.  The
> build was successful.  xgcc worked, without the ICE.  Clearly the ICE only 
> happens when gcc-7 is configured with the native assembler.  This is the usual
> configuration on SPARC hardware.

Interesting, why is that usual for SPARC and unusual for x86?

> Anybody should be able to reproduce this problem.  My guess is a logic error.

I'm not sure whether we still support the native assembler on Solaris.  Rainer,
do you still test it?

[Bug fortran/88143] New: gfortran crashes with an internal compiler error

[andrew at fluidgravity dot co.uk]

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

Bug ID: 88143
   Summary: gfortran crashes with an internal compiler error
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at fluidgravity dot co.uk
  Target Milestone: ---

I get an internal compiler error when compiling the code below:

> gfortran -c code.f90
f951: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


code.f90:
MODULE m
   IMPLICIT NONE
   TYPE t
  INTEGER, DIMENSION(:), ALLOCATABLE :: i
   END TYPE
   CONTAINS
  SUBROUTINE s(x)
 CLASS(*), DIMENSION(:), INTENT(IN), OPTIONAL :: x
 INTEGER :: k
 SELECT TYPE ( x )
 CLASS IS ( t )
ASSOCIATE ( j => x(1)%i )
   k = j(1)
END ASSOCIATE
 END SELECT
  END
END

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
Created attachment 45063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45063&action=edit
combined patch

> Can you attach one single patch from trunk?

Patch combining:
- Updated patch
  https://gcc.gnu.org/bugzilla/attachment.cgi?id=45055&action=edit
- Followup patch
  https://gcc.gnu.org/bugzilla/attachment.cgi?id=45058&action=edit
- Second followup patch
  https://gcc.gnu.org/bugzilla/attachment.cgi?id=45059&action=edit

[Bug c++/88118] GCC keeps unnecessary calls to new

[tiagomacarios at gmail dot com]

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

--- Comment #6 from Tiago Macarios  ---
Related clang bug: https://bugs.llvm.org/show_bug.cgi?id=39731

[Bug c++/88122] [9 Regression] g++ ICE: internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 21 22:42:09 2018
New Revision: 266360

URL: https://gcc.gnu.org/viewcvs?rev=266360&root=gcc&view=rev
Log:
PR c++/88122
* method.c (maybe_explain_implicit_delete): If
FUNCTION_FIRST_USER_PARMTYPE (decl) is NULL, set const_p to false
instead of ICEing.

* g++.dg/cpp0x/implicit15.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/implicit15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87386] [8/9 Regression] Error message for static_assert show wrong range

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 21 22:41:07 2018
New Revision: 266359

URL: https://gcc.gnu.org/viewcvs?rev=266359&root=gcc&view=rev
Log:
PR c++/87386
* parser.c (cp_parser_primary_expression): Use
id_expression.get_location () instead of id_expr_token->location.
Adjust the range from id_expr_token->location to
id_expressio.get_finish ().
(cp_parser_operator_function_id): Pass location of the operator
token down to cp_parser_operator.
(cp_parser_operator): Add start_loc argument, always construct a
location with caret at start_loc and range from start_loc to the
finish of the last token.
gcc/testsuite/
* g++.dg/diagnostic/pr87386.C: New test.
* g++.dg/parse/error17.C: Adjust expected diagnostics.
libstdc++-v3/
* testsuite/20_util/scoped_allocator/69293_neg.cc: Adjust expected
line.
* testsuite/20_util/uses_allocator/cons_neg.cc: Likewise.
* testsuite/20_util/uses_allocator/69293_neg.cc: Likewise.
* testsuite/experimental/propagate_const/requirements2.cc: Likewise.
* testsuite/experimental/propagate_const/requirements3.cc: Likewise.
* testsuite/experimental/propagate_const/requirements4.cc: Likewise.
* testsuite/experimental/propagate_const/requirements5.cc: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr87386.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/error17.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/20_util/scoped_allocator/69293_neg.cc
trunk/libstdc++-v3/testsuite/20_util/uses_allocator/69293_neg.cc
trunk/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements2.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements3.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements4.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements5.cc

[Bug middle-end/87836] 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

--- Comment #16 from Gary Mills  ---
I have a clue now.  I built gcc-7 on OI-SPARC with the GNU assembler.  The
build
was successful.  xgcc worked, without the ICE.  Clearly the ICE only happens
when gcc-7 is configured with the native assembler.  This is the usual
configuration on SPARC hardware.

Then I built gcc-7 on OI-x86 with the native assembler.  This is the opposite
of
the normal configuration.  It failed with the ICE.  xgcc by itself gets the
same
ICE.

My conclusion is that the ICE only occurs when gcc-7 is configured with the
native
assembler.  It doesn't matter if the hardware is SPARC or x86.  The fatal
configuration is with:

--without-gnu-as --with-as=/usr/bin/as

Something happens in that case that passes a null pointer to functions that
dereference it and cause the ICE.

Note that the assembler is not actually invoked.  My test uses the -S option
that causes the assembly output to be placed in a file.  xgcc still fails if
the
native assembler is configured.

Anybody should be able to reproduce this problem.  My guess is a logic error.

[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from emsr at gcc dot gnu.org ---
2018-05-07  Edward Smith-Rowland  <3dw...@verizon.net>

Moar PR libstdc++/80506
* include/bits/random.tcc (gamma_distribution::__generate_impl()):
Fix magic number used in loop condition.

[Bug libstdc++/83140] assoc_legendre returns negated value when m is odd

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from emsr at gcc dot gnu.org ---
2018-05-10  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/83140 - assoc_legendre returns negated value when m is odd
* include/tr1/legendre_function.tcc (__assoc_legendre_p): Add __phase
argument defaulted to +1.  Doxy comments on same.
* testsuite/special_functions/02_assoc_legendre/
check_value.cc: Regen.
* testsuite/tr1/5_numerical_facilities/special_functions/
02_assoc_legendre/check_value.cc: Regen.

[Bug libstdc++/83566] cyl_bessel_j returns wrong result for x>1000 for high orders.

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from emsr at gcc dot gnu.org ---
2018-11-16  Michele Pezzutti 
Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/83566 - cyl_bessel_j returns wrong result for x>1000
for high orders.
* include/tr1/bessel_function.tcc: Perform no fewer than nu/2
iterations
of the asymptotic series (nu is the Bessel order).
* testsuite/tr1/5_numerical_facilities/special_functions/
09_cyl_bessel_j/check_value.cc: Add tests at nu=100, 1000<=x<=2000.
* testsuite/tr1/5_numerical_facilities/special_functions/   
11_cyl_neumann/check_value.cc: Ditto.
* testsuite/special_functions/08_cyl_bessel_j/check_value.cc: Ditto.
* testsuite/special_functions/10_cyl_neumann/check_value.cc: Ditto.

[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x

[emsr at gcc dot gnu.org]

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

--- Comment #10 from emsr at gcc dot gnu.org ---
I'll look at updating the pedantic warn patch.

[Bug lto/88142] [9 Regression] ICE in lto_warn at ipa-devirt.c:1020 since r265519

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-21
  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 lto/88142] New: [9 Regression] ICE in lto_warn at ipa-devirt.c:1020 since r265519

[marxin at gcc dot gnu.org]

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

Bug ID: 88142
   Summary: [9 Regression] ICE in lto_warn at ipa-devirt.c:1020
since r265519
   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 is causing ICE:

$ cat ice1.ii
struct wiimote_t {
  const int unid;
} * a;

$ cat ice2.ii
struct wiimote_t;
class a {
  wiimote_t *b;
  a();
};
struct wiimote_t {
  int unid;
};
a::a() { b = __null; }

$ g++ ice1.ii ice2.ii -flto
lto1: internal compiler error: tree check: expected tree that contains ‘decl
minimal’ structure, have ‘integer_type’ in warn_odr, at ipa-devirt.c:1020
0x6b79c0 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9924
0x6171ca contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3268
0x6171ca warn_odr
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:1020
0xa064ce type_variants_equivalent_p
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:651
0xa0c389 odr_subtypes_equivalent_p
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:701
0xa0d4e2 odr_types_equivalent_p
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:1591
0xa0a290 add_type_duplicate
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:1894
0xa0a290 get_odr_type(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2075
0xa0e8d9 register_odr_type(tree_node*)
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2180
0x78c176 lto_read_decls
/home/marxin/Programming/gcc/gcc/lto/lto.c:1900
0x78d42e lto_file_finalize
/home/marxin/Programming/gcc/gcc/lto/lto.c:2134
0x78d42e lto_create_files_from_ids
/home/marxin/Programming/gcc/gcc/lto/lto.c:2144
0x78d42e lto_file_read
/home/marxin/Programming/gcc/gcc/lto/lto.c:2185
0x78d42e read_cgraph_and_symbols
/home/marxin/Programming/gcc/gcc/lto/lto.c:2865
0x78d42e lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:3401

[Bug rtl-optimization/85925] [7/8/9 regression] compilation of masking with 257 goes wrong in combine at -02

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 21 20:45:59 2018
New Revision: 266357

URL: https://gcc.gnu.org/viewcvs?rev=266357&root=gcc&view=rev
Log:
PR rtl-optimization/85925
* gcc.c-torture/execute/20181120-1.c: Require effective target
int32plus.
(u): New variable.
(main): Compare d against u.f1 rather than 0x101.  Use 0x4030201
instead of 0x10101.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/20181120-1.c

[Bug c++/86397] [7/8/9 Regression] g++ ICE at on valid code in nothrow_spec_p, at cp/except.c:1158

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #2 from Alexandre Oliva  ---
Created attachment 45062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45062&action=edit
candidate patch

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[ian at airs dot com]

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

--- Comment #11 from Ian Lance Taylor  ---
Sorry, I've gotten confused.  Can you attach one single patch from trunk? 
Thanks.

[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)

[segher at gcc dot gnu.org]

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

--- Comment #18 from Segher Boessenkool  ---
Your "trivial rewrite" does not work at all (you didn't modify "h").

It isn't trivial to avoid this warning at all, which was half of my point.

The other half is that we should not warn that the normal use of a GCC C
extension would be "bad" or a "security problem" when it is neither.  Yes,
marking the whole stack executable for the whole lifetime of a process when
something in your program may use a trampoline is less than optimal, may
make some exploits easier to pull off.  But that is all.

Making -Wall complain about it in all cases will only result in more people
not using nested functions, although those are a useful C language extension
(and required for some other languages, so GCC has to implement it *anyway*),
while not actually giving them any more security.

Nested functions are not insecure.  Trampolines are not insecure.  Executable
trampolines are not insecure.  Executable trampolines on the stack are not
insecure.  Executable *everything* on the stack is not insecure, on many
architectures.  The only thing is that having the whole stack executable makes
it easier to exploit other problems, on other architectures.

[Bug middle-end/88129] Two blockage insns are emited in the function epilogue

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #6)
> Fixed for gcc-9.0, no plan to backport.

Let's keep the PR open for the eventual removal of the remaining blockage
instruction for targets that emit unwind information in the epilogue.

[Bug middle-end/88129] Two blockage insns are emited in the function epilogue

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #6 from Uroš Bizjak  ---
Fixed for gcc-9.0, no plan to backport.

[Bug middle-end/88129] Two blockage insns are emited in the function epilogue

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov 21 20:18:45 2018
New Revision: 266356

URL: https://gcc.gnu.org/viewcvs?rev=266356&root=gcc&view=rev
Log:
PR middle-end/88129
* function.c (expand_function_end): Do not emit extra blockage insn.


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

[Bug target/85667] (x86_64) ms_abi rules aren't followed when returning short structs with float values

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov 21 20:09:56 2018
New Revision: 266355

URL: https://gcc.gnu.org/viewcvs?rev=266355&root=gcc&view=rev
Log:
PR target/85667
* config/i386/i386.c (function_value_ms_64): Return AX_REG instead
of FIRST_SSE_REG for 4 or 8 byte modes.

testsuite/ChangeLog:

PR target/85667
* gcc.target/pr85667-1.c: New testcase.
* gcc.target/pr85667-2.c: New testcase.
* gcc.target/pr85667-3.c: New testcase.
* gcc.target/pr85667-4.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr85667-1.c
trunk/gcc/testsuite/gcc.target/i386/pr85667-2.c
trunk/gcc/testsuite/gcc.target/i386/pr85667-3.c
trunk/gcc/testsuite/gcc.target/i386/pr85667-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88118] GCC keeps unnecessary calls to new

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
"An implementation is allowed to omit a call to a replaceable global allocation
function" (not any operator new) so I am not sure DECL_IS_OPERATOR_NEW is the
right test.

[Bug fortran/88124] Wrong results with procedure in seperate file

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-21
 Ever confirmed|0   |1

--- Comment #10 from Thomas Koenig  ---
(In reply to Steve Kargl from comment #8)
> On Wed, Nov 21, 2018 at 08:49:55AM +, tkoenig at gcc dot gnu.org wrote:
> > 
> > --- Comment #6 from Thomas Koenig  ---
> > The type has SEQUENCE, so I think this should actually work... or did I miss
> > something here?
> > 
> 
> Remove the INCLUDE from the problem, and consider
> 
> program foo
>type aaa
>   integer i
>end type aaa
>type(aaa) a
>call bar(a)
>print *, a%i
> end program foo
> 
> subroutine foo(a)
>type aaa
>   character(4) i
>end type aaa
>type(aaa) a
>a%i = 'abcd'
> end subroutine foo
> 
> Put each unit in its own file, compile each separately, and link.
> type aaa is clearly not the same both unit.

Correct.

> Do you expect to link 
> and execute the program?

No.

> You can now change character(4) to integer.
> How is the compiler to know that the types are the same as the types
> are in different namespaces.

Not for your example.

However, the original test case had SEQUENCE in the type
definition.

Here is 4.5.2.4 from F2008:

4.5.2.4 Determination of derived types

Derived-type definitions with the same type name may appear in different
scoping units, in which case they might be independent and describe different
derived types or they might describe the same type.

Two data entities have the same type if they are declared with reference to the
same derived-type definition. Data entities also have the same type if they are
declared with reference to different derived-type definitions that specify the
same type name, all have the SEQUENCE attribute or all have the BIND attribute,
have no components with PRIVATE accessibility, and have type parameters and
components that agree in order, name, and attributes. Otherwise, they are of
different derived types. [Rest about PRIVATE elided]

So, the original test case fulfilled the condition of 4.5.2.4, and the two
types in the different scoping unit did indeed describe the same type.


> Sure, it may compile, link, and execute
> but I think that is undefined behavior.  I also think SEQUENCE is a
> red herring here, as its only purpose is to restrict a compiler from
> re-ordering components in a type with multiple components. 

> The fix for the person in fortran@ is trivially stupid.  Use a module.

It certainly is a workaround, and the definitely preferred way to do
it, but what he showed was correct.

[Bug other/88141] New: Issues with texinfo when building GCC r266351 in MSYS2

[jmm4077 at rit dot edu]

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

Bug ID: 88141
   Summary: Issues with texinfo when building GCC r266351 in MSYS2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmm4077 at rit dot edu
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: x86_64-w64-mingw32
 Build: x86_64-w64-mingw32

I'm experiencing a problem with texinfo while attempting to build the latest
trunk revision of GCC in MSYS2 (r266351 at the time of writing this report). I
am building GCC with the latest release versions of GMP, MPC, MPFR, and ISL
(6.1.2, 1.1.0, 4.0.1, and 0.20, respectively).

This is the configure command I'm using for GCC:

../src/configure --build=$TARGET --host=$TARGET --target=$TARGET \
--prefix=$X_WORKDIR_ROOT/dest --with-sysroot=$X_WORKDIR_ROOT/dest \
--disable-multilib --disable-shared --disable-nls --enable-libgomp \
--disable-libstdcxx-pch --disable-libstdcxx-verbose --with-tune=native \
--enable-languages=c,c++,fortran --enable-threads=posix \
--disable-win32-registry "MAKEINFO=missing"

where TARGET is x86_64-w64-mingw32. This is the make call I'm using:

make $MAKE_JOBS bootstrap "CFLAGS=-g0 -O3" "CXXFLAGS=-g0 -O3" \
"CFLAGS_FOR_TARGET=-g0 -O3" "CXXFLAGS_FOR_TARGET=-g0 -O3" \
"BOOT_CXXFLAGS=-g0 -O3"

With MAKEINFO=missing, I get this error during the first stage of the
bootstrap:

make[3]: Entering directory '/d/mingw-distro-setup/build/gcc'
if [ xinfo = xinfo ]; then \
/d/mingw-distro-setup/src/missing makeinfo --split-size=500
--split-size=500 --split-size=500 --no-split -I . -I ../../src/gcc/doc
\
-I ../../src/gcc/doc/include -o doc/cpp.info
../../src/gcc/doc/cpp.texi; \
fi
../../src/gcc/doc/cpp.texi:4375: table requires an argument: the formatter for
@item
../../src/gcc/doc/cppopts.texi:493: table requires an argument: the formatter
for @item
make[3]: *** [Makefile:3226: doc/cpp.info] Error 1
make[3]: Leaving directory '/d/mingw-distro-setup/build/gcc'
make[3]: *** Waiting for unfinished jobs

A similar error occurs (i.e., the "table requires an argument" message) if I
don't include MAKEINFO=missing in the configure call.

I'm not sure if this is an issue with the distribution of texinfo provided by
MSYS2, or if it's an issue with GCC itself. I figured it would be a good idea
to inform the GCC developers first, though.

[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #6 from Jonathan Wakely  ---
This should be fixed now.

If you're able to run the tests for these components that would be very much
appreciated. To run just the  tests, run the following in the
$objdir/$target/libstdc++-v3 directory:

make check RUNTESTFLAGS=conformance.exp=20_util/*_resource/*

[Bug lto/88140] [9 Regression] ICE: verify_gimple failed since r266325

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-21
  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 libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 21 18:40:55 2018
New Revision: 266353

URL: https://gcc.gnu.org/viewcvs?rev=266353&root=gcc&view=rev
Log:
PR libstdc++/88111 Make maximum block size depend on size_t width

PR libstdc++/88111
* include/std/memory_resource (pool_options): Add Doxygen comments.
* src/c++17/memory_resource.cc (pool_sizes): Only use suitable values
on targets with 16-bit or 20-bit size_t type.
(munge_options): Make default values depend on width of size_t type.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/memory_resource
trunk/libstdc++-v3/src/c++17/memory_resource.cc

[Bug libstdc++/88113] Woverflow warning in memory_resource.cc (struct bitset), for 16-bit size_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #3 from Jonathan Wakely  ---
This should be fixed now.

[Bug libstdc++/88113] Woverflow warning in memory_resource.cc (struct bitset), for 16-bit size_t

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 21 18:40:37 2018
New Revision: 266352

URL: https://gcc.gnu.org/viewcvs?rev=266352&root=gcc&view=rev
Log:
PR libstdc++/88113 use size_type consistently instead of size_t

On 16-bit msp430-elf size_t is either 16 bits or 20 bits, and so can't
represent all values of the uint32_t type used for bitset::size_type.
Using the smaller of size_t and uint32_t for size_type ensures it fits
in size_t.

PR libstdc++/88113
* src/c++17/memory_resource.cc (bitset::size_type): Use the smaller
of uint32_t and size_t.
(bitset::size(), bitset::free(), bitset::update_next_word())
(bitset::max_blocks_per_chunk(), bitset::max_word_index()): Use
size_type consistently instead of size_t.
(chunk): Adjust static_assert checking sizeof(chunk).

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/memory_resource.cc

[Bug lto/88140] New: [9 Regression] ICE: verify_gimple failed since r266325

[marxin at gcc dot gnu.org]

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

Bug ID: 88140
   Summary: [9 Regression] ICE: verify_gimple failed since r266325
   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 is causing ICE:

$ cat ice.i
typedef struct {
} a;

typedef struct {
  a *b[0];
} c;

void d() { ((c *)0)->b[0] = 0; }

$ gcc ice.i  -c -flto
typedef struct {
} a;

typedef struct {
  a *b[0];
} c;

void d() { ((c *)0)->b[0] = 0; }
ice.i: In function ‘d’:
ice.i:8:1: error: type mismatch in component reference
8 | void d() { ((c *)0)->b[0] = 0; }
  | ^~~~
struct a *[0:]

struct a *[0:]

_1->b[0] = 0B;
during IPA pass: *free_lang_data
ice.i:8:1: internal compiler error: verify_gimple failed
0xd53697 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5422
0xc2cbef execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1977
0xc2dac1 do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1645
0xc2db1e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2031

[Bug sanitizer/86899] [8/9 regression] TSAN incorrect warning: control reaches end of non-void function

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
block_may_fallthru on:
  try
{
  return  = 0;
  if (0)
{
  return  = 0;
}
}
  finally
{
  A::~A (&a);
}
suggests that it may fall thru, because generally it looks at the last stmt, it
is way too early for dce.  Even for the if (0), it would need to prove there
are no labels in the block and would need to decide to look at stmts before
last too.
In *.ehopt we have:
  try
{
  A::A (&a);
  try
{
  D.2328 = 0;
  goto ;
  if (0 != 0) goto ; else goto ;
  :
  D.2328 = 0;
  // predicted unlikely by early return (on trees) predictor.
  goto ;
  :
}
  finally
{
  A::~A (&a);
}
}
  finally
{
  a = {CLOBBER};
}
  return;
  :
  return D.2328;
and even here the if (0) stuff makes gimple_stmt_may_fallthru think it might
fall thru, because it ends with a label (D.2330).
Because of this the eh lowering decides to use a finally_tmp temporary to track
where it should continue after the cleanup:
  finally_tmp.0 = 0;
  goto ;
  :
  finally_tmp.0 = 1;
  :
  A::~A (&a);
  switch (finally_tmp.0) , case 1: >
Now, cfg construct with its cleanup makes
   :
  A::A (&a);

   :
  D.2328 = 0;
  finally_tmp.0 = 0;

   :
  A::~A (&a);
  if (finally_tmp.0 == 1)
goto ; [INV]
  else
goto ; [INV]

   :
  a = {CLOBBER};
  return;

   :
  a = {CLOBBER};

   :
:
  return D.2328;

   :
:
  a = {CLOBBER};
  resx 1
out of this, which is unfortunately not good enough for the -Wreturn-type pass
that follows - we aren't in SSA form, so there is no easy way during the cfg
cleanup to figure out that finally_tmp.0 is ever stored only 0 and do further
cfg cleanup.

[Bug tree-optimization/88074] [7/8/9 Regression] g++ hangs on math expression

[joseph at codesourcery dot com]

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

--- Comment #23 from joseph at codesourcery dot com  ---
And, yes, at least one extra bit in emin is needed for that sticky 
rounding code to work (because the user's source code may have a decimal 
constant that is slightly over half the least subnormal, and mpfr_strtofr 
needs to return a nonzero value for that code to work, meaning a value 
whose exponent is one smaller than the smallest exponent of any subnormal 
value that is actually representable in the floating-point format).

[Bug tree-optimization/88074] [7/8/9 Regression] g++ hangs on math expression

[joseph at codesourcery dot com]

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

--- Comment #22 from joseph at codesourcery dot com  ---
On Wed, 21 Nov 2018, rguenther at suse dot de wrote:

>   /* Nonzero value, possibly overflowing or underflowing.  */
>   mpfr_init2 (m, SIGNIFICAND_BITS);
>   inexact = mpfr_strtofr (m, str, NULL, 10, GMP_RNDZ);
> 
> we return true and the rounding mode is GMP_RNDZ?  Indeed when changing
> the above to use GMP_RNDN it works OK.  The whole thing is also a bit

Note that using RNDZ is required there for correctness (this is 
round-to-odd / sticky rounding).

[Bug sanitizer/86899] [8/9 regression] TSAN incorrect warning: control reaches end of non-void function

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Doesn't seem to be a real regression to me, we've only stopped warning about
this with -Wreturn-type -fsanitize=thread in r254437 and started again in
r255403, that is less than month and no releases have been released with that.
We weren't warning before r219202 though.

Note, it is the same warning you get with e.g.
struct A { A (); ~A (); };
int foo()
{
A a;
return 0;
if(0) {
return 0;
}
}
or anything that needs a cleanup, -Wreturn-type is a simple warning and if you
try hard to screw it up, you'll manage to do it.  Any reason why we shouldn't
warn on this though?  It is clearly useless dead code that is better removed
when the compiler warns about it...

[Bug fortran/88139] New: ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047

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

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

Bug ID: 88139
   Summary: ICE in get_c_type_name, at
fortran/dump-parse-tree.c:3047
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Since version 8 with option -fc-prototypes :


$ cat z1.f90
module m
contains
   subroutine s(*) bind(c, name='f')
   end
end


$ gfortran-9-20181118 -c z1.f90 -fc-prototypes
f951: internal compiler error: Segmentation fault
0xc8934f crash_signal
../../gcc/toplev.c:325
0x636b19 get_c_type_name
../../gcc/fortran/dump-parse-tree.c:3047
0x63955d write_proc
../../gcc/fortran/dump-parse-tree.c:3262
0x63955d write_interop_decl
../../gcc/fortran/dump-parse-tree.c:3318
0x6cfae2 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x63e2d3 gfc_dump_c_prototypes(gfc_namespace*, _IO_FILE*)
../../gcc/fortran/dump-parse-tree.c:3026
0x699ac0 gfc_parse_file()
../../gcc/fortran/parse.c:6273
0x6e2d9f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
void f ($
$

[Bug fortran/88138] New: ICE in gfc_arith_concat, at fortran/arith.c:1007

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

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

Bug ID: 88138
   Summary: ICE in gfc_arith_concat, at fortran/arith.c:1007
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With invalid code down to at least gcc-5 :


$ cat z1.f90
program p
   type t
  character :: c = 'c'
   end type
   type(t), parameter :: x = 1e1
   print *, 'a'//x%c
end


$ cat z2.f90
program p
   type t
  character :: c = 'c'
   end type
   type(t), parameter :: x = .true.
   print *, 'a'//x%c
end


$ gfortran-9-20181118 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb2a03f crash_signal
../../gcc/toplev.c:325
0x5e8259 gfc_arith_concat
../../gcc/fortran/arith.c:1007
0x5e773a reduce_binary
../../gcc/fortran/arith.c:1425
0x5e7a9b eval_intrinsic
../../gcc/fortran/arith.c:1606
0x650aaa match_level_3
../../gcc/fortran/matchexp.c:571
0x650b74 match_level_4
../../gcc/fortran/matchexp.c:599
0x650b74 match_and_operand
../../gcc/fortran/matchexp.c:693
0x650d62 match_or_operand
../../gcc/fortran/matchexp.c:722
0x650e32 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x650f04 match_level_5
../../gcc/fortran/matchexp.c:811
0x6502e1 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.c:870
0x638e23 match_io_element
../../gcc/fortran/io.c:3587
0x63b795 match_io_list
../../gcc/fortran/io.c:3626
0x63bba4 match_io
../../gcc/fortran/io.c:4287
0x63f3aa gfc_match_print()
../../gcc/fortran/io.c:4344
0x66a891 match_word
../../gcc/fortran/parse.c:65
0x66e727 decode_statement
../../gcc/fortran/parse.c:536
0x66ebfa next_free
../../gcc/fortran/parse.c:1234
0x66ebfa next_statement
../../gcc/fortran/parse.c:1466
0x67020b parse_spec
../../gcc/fortran/parse.c:3858

[Bug fortran/83953] Internal compiler error with -fcheck=bounds option on derived type components and forall construct

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

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #2 from G. Steinmetz  ---

Simplification :


$ cat z1.f90
program p
   type t
  integer :: n = 1
  integer, allocatable :: u(:)
  real :: v(3, 3)
   end type
   type(t) :: z
   real :: x(3) = [1.0, 2.0, 3.0]
   allocate (z%u(3))
   z%u = [3, 1, 2]
   forall (j = 1:3)
  z%v(j, z%n) = x(z%u(j))
   end forall
end


$ gfortran-9-20181118 -c z1.f90 -fcheck=all
z1.f90:11:0:

   11 |forall (j = 1:3)
  |
internal compiler error: Segmentation fault
0xb2a03f crash_signal
../../gcc/toplev.c:325
0x6f1006 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8091
0x6f1160 gfc_conv_expr_type(gfc_se*, gfc_expr*, tree_node*)
../../gcc/fortran/trans-expr.c:8106
0x6c9540 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../gcc/fortran/trans-array.c:3614
0x6f1d8e gfc_conv_variable
../../gcc/fortran/trans-expr.c:2773
0x6eea0a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8047
0x6f1013 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8092
0x6f1160 gfc_conv_expr_type(gfc_se*, gfc_expr*, tree_node*)
../../gcc/fortran/trans-expr.c:8106
0x6c905c gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../gcc/fortran/trans-array.c:3597
0x6f1d8e gfc_conv_variable
../../gcc/fortran/trans-expr.c:2773
0x6eea0a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8047
0x6fd0b9 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10248
0x72b323 gfc_trans_forall_1
../../gcc/fortran/trans-stmt.c:4780
0x6c0047 trans_code
../../gcc/fortran/trans.c:1966
0x6e7754 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x674576 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x674576 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bc97f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
As a workaround, you can use -mstack-protector-guard=global on these targets
(together with -fstack-protector{,-all,-strong,-explicit}).

[Bug target/85644] [8/9 Regression] -fstack-protector generates invalid read to %fs:0x0 on mac

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832#c7 for more details.

[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I believe this is caused by the PR81708 changes.
While i386 defaulted to SSP_TLS rather than SSP_GLOBAL on everything but
Android,
the -mstack-protector-guard= switch controlled pretty much whether the i386.md
special stack protector patterns are used (if tls) or whether generic code is
used (global).  These special stack protector patterns did one thing if
TARGET_THREAD_SSP_OFFSET macro was defined (only defined on glibc targets) -
code like:
movq%fs:40, %rax
movq%rax, -8(%rbp)
xorl%eax, %eax
in the prologue and
movq-8(%rbp), %rdx
xorq%fs:40, %rdx
je  .L4
in the epilogue.  If TARGET_THREAD_SSP_OFFSET macro wasn't defined, it would do
instead:
movq.refptr.__stack_chk_guard(%rip), %rax
movq(%rax), %rcx
movq%rcx, -8(%rbp)
xorl%ecx, %ecx
and
movq.refptr.__stack_chk_guard(%rip), %rdx
movq-8(%rbp), %rcx
xorq(%rdx), %rcx
je  .L4
(this is taken from 7.x cross to mingw).
Finally, for Android or when -mstack-protector-guard=global was used, it
emitted:
movq__stack_chk_guard(%rip), %rax
movq%rax, -8(%rbp)
and
movq__stack_chk_guard(%rip), %rdx
cmpq%rdx, %rcx
je  .L4
Note, apart from OS specific details, those =global sequences are similar to
the =tls ones when TARGET_THREAD_SSP_OFFSET is not defined, the main difference
is that the =tls ones are more secure as they clear registers containing the
guard as quickly as possible.  The PR81708 changes dropped the non-tls special
stack_protector_* patterns from i386.md and now =tls implies really tls, but
the default remained, so mingw32 or darwin still default to tls and just use 0
offset by default.

So, this patch changes the default for mingw32, darwin and everything else
except gnu-user*.h to be =global, and just forces those special i386.md more
secure patterns unconditionally (slightly changing the generated code on
Android, but it is one extra insn in prologue and one fewer in the epilogue).

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

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

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Wed Nov 21 17:32:19 2018
New Revision: 266351

URL: https://gcc.gnu.org/viewcvs?rev=266351&root=gcc&view=rev
Log:

PR lto/87957
* g++.dg/lto/odr-1_0.C: Extend by mismatched enum.
* g++.dg/lto/odr-1_1.C: Extend by mismatched enum.
* g++.dg/lto/odr-2_0.C: New.
* g++.dg/lto/odr-2_0.C: New.
* g++.dg/lto/odr-3_1.C: New.
* g++.dg/lto/odr-3_1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lto/odr-2_0.C
trunk/gcc/testsuite/g++.dg/lto/odr-2_1.C
trunk/gcc/testsuite/g++.dg/lto/odr-3_0.C
trunk/gcc/testsuite/g++.dg/lto/odr-3_1.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/odr-1_0.C
trunk/gcc/testsuite/g++.dg/lto/odr-1_1.C

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
Author: hubicka
Date: Wed Nov 21 17:31:19 2018
New Revision: 266350

URL: https://gcc.gnu.org/viewcvs?rev=266350&root=gcc&view=rev
Log:

PR lto/87957
* tree.c (fld_decl_context): Break out from ...
(free_lang_data_in_decl): ... here; free TREE_PUBLIC, TREE_PRIVATE
DECL_ARTIFICIAL of TYPE_DECL; do not free TREE_TYPE of TYPE_DECL.
(fld_incomplete_type_of): Build copy of TYP_DECL.
* ipa-devirt.c (free_enum_values): Rename to ...
(free_odr_warning_data): ... this one; free also duplicated TYPE_DECLs
and TREE_TYPEs of TYPE_DECLs.
(get_odr_type): Initialize odr_vtable_hash if needed.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/tree.c

[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 45061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45061&action=edit
gcc9-pr85644.patch

Untested fix.  I have no access to Windows though.

[Bug target/85644] [8/9 Regression] -fstack-protector generates invalid read to %fs:0x0 on mac

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45060&action=edit
gcc9-pr85644.patch

Untested fix.  I have no access to Darwin though.

[Bug fortran/88137] New: BACKTRACE seems to have a memory leak

[longb at cray dot com]

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

Bug ID: 88137
   Summary: BACKTRACE seems to have a memory leak
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

Simple test case from site:

> cat test.f90
program test

implicit none
integer :: i

do i= 1,1
call backtrace()
enddo

end program test

Tracing memory usage with gfortran 4.9.3:

Process Memory Details
Virtual maximum (MB) 1.262
Resident maximum (MB) 0.930
Virtual at exit (MB) 1.258
Resident at exit (MB) 0.930

But with gfortran 8.2.0 

Process Memory Details
 Virtual  maximum   (MB)   48282.594
 Resident maximum   (MB)   31592.816
 Virtual  at exit   (MB)   48282.594
 Resident at exit   (MB)   31592.816


While the test case is artificial, it does illustrate that calls to backtrace
seems to accumulate memory usage.

[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)

[mark at gcc dot gnu.org]

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

--- Comment #17 from Mark Wielaard  ---
(In reply to Segher Boessenkool from comment #16)
> Something as trivial as this
> 
> ===
> void h(int (*)(void));
> void f(int x)
> {
> int g(void) { return x; }
> h(g);
> }
> ===
> 
> will already do.  *Anything* that needs trampolines will do.

Sure, if you pass around a nested function pointer that captures context that
the compiler cannot inline because it is passed to another function that cannot
capture that same context.

I just haven't seen any code base that does that. That is why I was asking for
a concrete example.

But I know it is possible to accidentally do this and that is why I like the
have -Wall/-Wtrampolines warn about it. The above example can trivially be
rewritten to not give the warning:

void h(int (*)(int), int);
void f(int x)
{
 int g(int i) { return i; }
 h(g, x);
}

And I believe that is what normally people would want. Having
-Wall/-Wtrampolines warn about it when they make the mistake of writing code
that would require executable code on the stack when they use nested functions.

I could be wrong of course, I might not have enough imagination to appreciate
that what I believe is the correct/trivial way to rewrite the code to avoid the
warning (and potential security issue) is in fact a real burden in some
environments.

Is your objection to add -Wtrampolines to -Wall because you have actual code
that would be hard to rewrite to avoid the warning? Or is it just that you
believe it should not be a default warning on some targets (those which already
have the security issue of having a default executable stack)?

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries  ---
(In reply to Tom de Vries from comment #9)
> Created attachment 45059 [details]
> Second followup patch
> 
> > [ OTOH, that's a memory leak in the fail
> > case, but corresponds to unused memory in the success case, so we might
> > wanna fix that as well, by keeping track of the number of struct unit_addr
> > found, and freeing the struct unit at the end of the 'while (info.left > 0)'
> > loop when it's 0. Perhaps that's worth a seperate patch. ]
> 
> Patch implementing this memory optimization.

After instrumenting the patch to print a marker when this triggers, we have
these trigger counts in the tests:
...
$ grep -c 'HERE!!!' *.log 
btest.log:94
ctesta.log:94
ctestg.log:94
dtest.log:94
edtest.log:94
stest.log:0
ttest.log:1000
ztest.log:0
...

So, this seems common enough.

[Bug fortran/88124] Wrong results with procedure in seperate file

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Wed, Nov 21, 2018 at 08:59:08AM -0800, Steve Kargl wrote:
> On Wed, Nov 21, 2018 at 08:49:55AM +, tkoenig at gcc dot gnu.org wrote:
> > 
> > --- Comment #6 from Thomas Koenig  ---
> > The type has SEQUENCE, so I think this should actually work... or did I miss
> > something here?
> > 
> 
> Remove the INCLUDE from the problem, and consider
> 
> program foo
>type aaa
>   integer i
>end type aaa
>type(aaa) a
>call bar(a)
>print *, a%i
> end program foo
> 
> subroutine foo(a)

s/foo/bar

>type aaa
>   character(4) i
>end type aaa
>type(aaa) a
>a%i = 'abcd'
> end subroutine foo
> 

s/foo/bar

[Bug fortran/88124] Wrong results with procedure in seperate file

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Wed, Nov 21, 2018 at 08:49:55AM +, tkoenig at gcc dot gnu.org wrote:
> 
> --- Comment #6 from Thomas Koenig  ---
> The type has SEQUENCE, so I think this should actually work... or did I miss
> something here?
> 

Remove the INCLUDE from the problem, and consider

program foo
   type aaa
  integer i
   end type aaa
   type(aaa) a
   call bar(a)
   print *, a%i
end program foo

subroutine foo(a)
   type aaa
  character(4) i
   end type aaa
   type(aaa) a
   a%i = 'abcd'
end subroutine foo

Put each unit in its own file, compile each separately, and link.
type aaa is clearly not the same both unit.  Do you expect to link 
and execute the program?  You can now change character(4) to integer.
How is the compiler to know that the types are the same as the types
are in different namespaces.  Sure, it may compile, link, and execute
but I think that is undefined behavior.  I also think SEQUENCE is a
red herring here, as its only purpose is to restrict a compiler from
re-ordering components in a type with multiple components. 

The fix for the person in fortran@ is trivially stupid.  Use a module.

[Bug target/87867] [7 regression] ICE on virtual destructor (-mlong-calls -ffunction-sections) on arm-none-eabi

[mihail.ionescu at arm dot com]

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

Mihail Ionescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.3.1
 Resolution|--- |FIXED
  Known to fail|7.3.0   |

--- Comment #4 from Mihail Ionescu  ---
Fixed -- Eric's patch was backported to GCC 8 and GCC 7.

[Bug target/87867] [7 regression] ICE on virtual destructor (-mlong-calls -ffunction-sections) on arm-none-eabi

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Nov 21 16:50:37 2018
New Revision: 266348

URL: https://gcc.gnu.org/viewcvs?rev=266348&root=gcc&view=rev
Log:
2018-11-21  Mihail Ionescu  

gcc/
PR target/87867
Backport from mainiline
2018-09-26  Eric Botcazou  

* config/arm/arm.c (arm_reorg): Skip Thumb reorg pass for thunks.
(arm32_output_mi_thunk): Deal with long calls.

gcc/testsuite/
PR target/87867
Backport from mainiline
2018-09-17  Eric Botcazou  

* g++.dg/other/thunk2a.C: New test.
* g++.dg/other/thunk2b.C: Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/other/thunk1.C
  - copied, changed from r266330,
branches/gcc-7-branch/gcc/testsuite/g++.dg/other/vthunk1.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/other/thunk2a.C
branches/gcc-7-branch/gcc/testsuite/g++.dg/other/thunk2b.C
Removed:
branches/gcc-7-branch/gcc/testsuite/g++.dg/other/vthunk1.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/arm/arm.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/87393] [8/9 Regression] gcc/cp/parser.c:13967:37:Unused Entity Issue: expression result unused: -Wunused-value since r251026

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk, not worth backporting.

[Bug target/87839] [9 Regression] ICE in final_scan_insn_1, at final.c:3070

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/87393] [8/9 Regression] gcc/cp/parser.c:13967:37:Unused Entity Issue: expression result unused: -Wunused-value since r251026

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 21 16:42:34 2018
New Revision: 266347

URL: https://gcc.gnu.org/viewcvs?rev=266347&root=gcc&view=rev
Log:
PR c++/87393
* parser.c (cp_parser_linkage_specification): Remove useless
dereference of the consume_open method result.

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

[Bug target/87839] [9 Regression] ICE in final_scan_insn_1, at final.c:3070

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 21 16:41:03 2018
New Revision: 266346

URL: https://gcc.gnu.org/viewcvs?rev=266346&root=gcc&view=rev
Log:
PR target/87839
* config/aarch64/atomics.md (@aarch64_compare_and_swap): Use
rIJ constraint for aarch64_plus_operand rather than rn.

* gcc.target/aarch64/pr87839.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr87839.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/atomics.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Richard Biener from comment #1)
> We've been there before with -Wexpansion-to-defined though.

That's only in -Wextra and -Wpedantic, though, not -Wall, so it's not exactly
the same.

[Bug fortran/88124] Wrong results with procedure in seperate file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #6)
> The type has SEQUENCE, so I think this should actually work... or did I miss
> something here?

It does seem to be not well defined. The preprocessor will substitute the
include text into multiple places and these multiple type declarations must be
in separate name spaces because they are not use associated like in a module.
My guess is the names are being prefixed differently and there is no way the
linker will know they are intended to be the same entity.  I have not looked at
the symbols in the executable yet.

[Bug c++/87393] [8/9 Regression] gcc/cp/parser.c:13967:37:Unused Entity Issue: expression result unused: -Wunused-value since r251026

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
http://gcc.gnu.org/ml/gcc-patches/2018-11/msg01845.html

[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jozef Lawrynowicz from comment #3)
> Your patch fixes the build, thanks.

Great, thanks for checking it.

I'll come up with a fix for Bug 88113 before I commit anything.

[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool  ---
Something as trivial as this

===
void h(int (*)(void));
void f(int x)
{
int g(void) { return x; }
h(g);
}
===

will already do.  *Anything* that needs trampolines will do.

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries  ---
Created attachment 45059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45059&action=edit
Second followup patch

> [ OTOH, that's a memory leak in the fail
> case, but corresponds to unused memory in the success case, so we might
> wanna fix that as well, by keeping track of the number of struct unit_addr
> found, and freeing the struct unit at the end of the 'while (info.left > 0)'
> loop when it's 0. Perhaps that's worth a seperate patch. ]

Patch implementing this memory optimization.

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

  Attachment #45057|0   |1
is obsolete||

--- Comment #8 from Tom de Vries  ---
Created attachment 45058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45058&action=edit
Followup patch

[ Oops, previous attachment did not build. ]

[Bug c++/87513] [8/9 Regression] ICE in write_expression, at cp/mangle.c:3050

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Slightly adjusted testcase:
template  struct A { static constexpr int c = N; };
template  struct B;
template  struct C;
template  struct C : A::c> {};
template  struct B : A {};
template  class D;
struct E { typedef int l; };
template  struct F;
template  struct F : E {};
template  struct G : F::c, C::c, U...>
{};
template  struct D : G {};
struct H { H (const char *); };
struct I { template  void foo (); };
struct J { template  auto bar (H) -> typename D)
(I, H)>::l; };
void
foo ()
{
  J j;
  j.bar<0> ("");
}

[Bug rtl-optimization/87468] [9 Regression] ice "wrong amount of branch edges after conditional jump in bb"

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
More correctly, jump threading is duplicating a switch in which there's an
outgoing edge marked as EDGE_IGNORE.  That duplicate has EDGE_IGNORE set, but
isn't in the cleanup queue.  Thus it leaks into the IL after the VRP pass is
complete.

Reviewing the original introduction of these bits, it looks like Richi's
intention was to simplify the switches and remove the edges later because doing
so early is going to mess up dominators.  That's a problem because we have to
do an ssa update to handle newly exposed variables.  That SSA update occurs
after identifying jump threads, but before the CFG updates.  Ugh.  I've always
hated the sequencing hoops we have to jump through for this stuff.

I'm going to look at moving the cleanup call to a slightly earlier point --
essentially just before we update the CFG for jump threading.  That has certain
nice properties, but I'll need to review some of the jump threading code to be
sure that's safe.

I'm also going to look at other mitigations in the updater.  We could just add
the copied objects to the cleanup list and the right things would just happen.

I don't want to disable threading through switches that have dead labels.  That
seems too drastic.

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
Created attachment 45057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45057&action=edit
Followup patch

> [ Btw, note that if we move the u and pu allocations to before read_abbrevs,
> we can read the abbrevs directly into u->abbrevs, and can get rid of the
> "free_abbrevs (&abbrevs)" at the end. Perhaps that's worth a separate patch.
> ]

Patch implementing this simplification.

[Bug c++/87921] [7/8/9 Regression] Incorrect error "storage size of [array] isn't known (when it is)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||6.3.0
Version|unknown |7.3.1

[Bug tree-optimization/87895] [7/8 Regression] ICE in purge_dead_edges, at cfgrtl.c:3246

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/87844] ICE in tsubst_copy using non-constant expression as a non-type template argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.4 |---
Summary|[7/8/9 Regression] ICE in   |ICE in tsubst_copy using
   |tsubst_copy using   |non-constant expression as
   |non-constant expression as  |a non-type template
   |a non-type template |argument
   |argument|
  Known to fail||4.9.0

--- Comment #2 from Richard Biener  ---
Hardly a regression - 4.8.5 which doesn't ICE doesn't grok auto params:

t.C: In function ‘auto foo(bool)’:
t.C:9:24: error: parameter declared ‘auto’
   auto f = [](auto c) -> B { };
^
t.C:9:32: error: decltype evaluates to ‘’, which is not a class or
enumeration type
   auto f = [](auto c) -> B { };
^
...

ICEs since 4.9.0.

[Bug target/87867] [7 regression] ICE on virtual destructor (-mlong-calls -ffunction-sections) on arm-none-eabi

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/88122] [9 Regression] g++ ICE: internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45056&action=edit
gcc9-pr88122.patch

Thus full patch I'm going to bootstrap/regtest.

[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

   Priority|P3  |P2

[Bug tree-optimization/87446] [7/8/9 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2431

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall

[ville.voutilainen at gmail dot com]

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

--- Comment #2 from Ville Voutilainen  ---
This is not just a Qt problem. I will write a proposal to undeprecate this
deprecation for C++20 before the next committee meeting.

[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

   Priority|P3  |P2

[Bug c++/87148] [7/8/9 Regression] backward compatibility issue to take char [] as incomplete type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/88122] [9 Regression] g++ ICE: internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Actually no, I think the const_p computation is ok, it is only relevant for
const vs. non-const copy ctor or const vs. non-const copy assignment, right?
So I think my patch is the right thing here.
E.g. copy_fn_p also returns 0 early if FUNCTION_FIRST_USER_PARMTYPE is NULL.

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 21 Nov 2018, asolokha at gmx dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
> 
> --- Comment #2 from Arseny Solokha  ---
> Sure, will paste it tomorrow. In the meantime, could you please try w/ -m32 
> (or
> w/o -m64) instead?

I've tried with the powerpc-linux cross to no avail.  The 
powerpc64[le]-linux crosses insist that -mcpu=860 requires a 64bit CPU...

[Bug c++/88122] [9 Regression] g++ ICE: internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-21
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
This ICEs in maybe_explain_implicit_delete.
If the computation of const_p is correct (and it is ok we often compute it e.g.
from parm_type that is void_type for the argument termination), then
--- cp/method.c.jj  2018-11-16 10:22:18.668258171 +0100
+++ cp/method.c 2018-11-21 15:42:08.441785625 +0100
@@ -1821,8 +1821,12 @@ maybe_explain_implicit_delete (tree decl
   if (!informed)
{
  tree parms = FUNCTION_FIRST_USER_PARMTYPE (decl);
- tree parm_type = TREE_VALUE (parms);
- bool const_p = CP_TYPE_CONST_P (non_reference (parm_type));
+ bool const_p = false;
+ if (parms)
+   {
+ tree parm_type = TREE_VALUE (parms);
+ const_p = CP_TYPE_CONST_P (non_reference (parm_type));
+   }
  tree raises = NULL_TREE;
  bool deleted_p = false;
  tree scope = push_scope (ctype);
will do the job.  But I somehow think that const_p should be rather computed
from the this parameter if any, though of course that is just a wild guess.
Jason?

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Created attachment 45055
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45055&action=edit
Updated patch

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> Comment on attachment 45048 [details]
> Proposed patch
> 
> >@@ -1476,6 +1483,15 @@ build_address_map (struct backtrace_stat
> >backtrace_alloc (state, sizeof *u, error_callback, data));
> >   if (u == NULL)
> > goto fail;
> >+
> >+  pu = ((struct unit **)
> >+backtrace_vector_grow (state, sizeof (struct unit *),
> >+   error_callback, data, &units));
> >+  if (pu == NULL)
> 
> This introduces another memory leak, this is missing here:
> ...
>   {
>   backtrace_free (state, u, sizeof *u, error_callback, data);
> ...
> 
> >+goto fail;
> 
> ...
>   }
> ...
> 
> [ Btw, note that if we move the u and pu allocations to before read_abbrevs,
> we can read the abbrevs directly into u->abbrevs, and can get rid of the
> "free_abbrevs (&abbrevs)" at the end. Perhaps that's worth a separate patch.
> ]
> 

Hmm, likewise, if we move the pu allocation before the u allocation, we can
drop the "backtrace_free (state, u, sizeof *u, error_callback, data);".

[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
We've been there before with -Wexpansion-to-defined though.

[Bug lto/88112] [9 regression] ICE in lto1: TYPE_FIELDS defined in incomplete type

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 21 Nov 2018, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88112
> 
> --- Comment #11 from Eric Botcazou  ---
> (> So short of avoiding the streaming of trees that are only targets
> > of abstract origins (the idea of streaming those as references to
> > DIEs rather than references to trees) a pragmatic "fix" is to
> > simply allow CALL_EXPRs to be streamed which fixes this testcase
> 
> This sounds heavy though.  If the C++ front-end cannot be changed to resetting
> the problematic size expressions, then maybe restrict your PR lto/87229 change
> to local types.

The type verifier will still trip over I guess.  The patch to stream
CALL_EXPRs isn't big, the code is mostly in place, a bit bitrotten
though.  I think it's probably the way to go for GCC 8 at least.
Will post it in a second.

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

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

--- Comment #5 from Renlin Li  ---
Mark it as fixed.