[Bug lto/88585] [9 Regression] ICE in fld_incomplete_type_of, at tree.c:5295

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Liška  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00684.html

[Bug lto/87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Is Jason working on that? Can you please link a gcc-patches mailing list
discussion (if there's any).

[Bug lto/89335] [9 Regression] ICE with LTO -Wsuggest-final-methods: ICE during IPA pass devirt in types_same_for_odr, at ipa-devirt.c:391

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Is Jason working on that? Can you please link a gcc-patches mailing list
discussion (if there's any).

[Bug fortran/89516] New: ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506

[marxin at gcc dot gnu.org]

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

Bug ID: 89516
   Summary: ICE in gfc_calculate_transfer_sizes at
gcc/fortran/check.c:5506
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Apparently a very old surprise, test-case is simplified from:
gcc/testsuite/gfortran.dg/pr89266.f90:

$ cat ice.f90 
program test
  character(*), parameter :: n = ''
  character(*), parameter :: o = transfer ([''], n)
end program test

$ gfortran ice.f90 -c -Wsurprising
f951: internal compiler error: Segmentation fault
0xdd0caf crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:326
0x77b79e0f ???
   
/usr/src/debug/glibc-2.29-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7b1daa gfc_calculate_transfer_sizes(gfc_expr*, gfc_expr*, gfc_expr*, unsigned
long*, unsigned long*, unsigned long*)
/home/marxin/Programming/gcc/gcc/fortran/check.c:5506
0x7b1daa gfc_calculate_transfer_sizes(gfc_expr*, gfc_expr*, gfc_expr*, unsigned
long*, unsigned long*, unsigned long*)
/home/marxin/Programming/gcc/gcc/fortran/check.c:5470
0x7b1e58 gfc_check_transfer(gfc_expr*, gfc_expr*, gfc_expr*)
/home/marxin/Programming/gcc/gcc/fortran/check.c:5566
0x7eaa40 check_specific
/home/marxin/Programming/gcc/gcc/fortran/intrinsic.c:4634
0x7f4c7d gfc_intrinsic_func_interface(gfc_expr*, int)
/home/marxin/Programming/gcc/gcc/fortran/intrinsic.c:4870
0x84b7af resolve_unknown_f
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:2873
0x84b7af resolve_function
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:3211
0x84b7af gfc_resolve_expr(gfc_expr*)
/home/marxin/Programming/gcc/gcc/fortran/resolve.c:6866
0x7db2af gfc_reduce_init_expr(gfc_expr*)
/home/marxin/Programming/gcc/gcc/fortran/expr.c:2987
0x7de330 gfc_match_init_expr(gfc_expr**)
/home/marxin/Programming/gcc/gcc/fortran/expr.c:3035
0x7c9169 variable_decl
/home/marxin/Programming/gcc/gcc/fortran/decl.c:2788
0x7c9169 gfc_match_data_decl()
/home/marxin/Programming/gcc/gcc/fortran/decl.c:6015
0x827eef match_word
/home/marxin/Programming/gcc/gcc/fortran/parse.c:65
0x827eef decode_statement
/home/marxin/Programming/gcc/gcc/fortran/parse.c:376
0x82b82e next_free
/home/marxin/Programming/gcc/gcc/fortran/parse.c:1241
0x82b82e next_statement
/home/marxin/Programming/gcc/gcc/fortran/parse.c:1473
0x82cedb parse_spec
/home/marxin/Programming/gcc/gcc/fortran/parse.c:3865
0x82f87c parse_progunit
/home/marxin/Programming/gcc/gcc/fortran/parse.c:5680

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to darkkirb from comment #9)
> I have bisected the fix a bit (I didn't have enough time today to finish it)
> and i found that the fix has happened in one of the 322 commits between 
> 
> d1540be4d3b4b8ac6d19997539c13d2ca74f65e4 (2018-09-26, broken)
> 
> and 
> 
> 44257478a8d157f8e0030bb7abe1c3ac91be9302 (2018-10-31, fixed)
> 
> Hopefully the fix can be applied to the gcc-8_0 branch.

I already bisected that, see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497#c6

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #7 from Piotr Kubaj  ---
It still crashes (test was done with 7.4.0), but we're getting somewhere.
It crashes at:
libtool: compile: 
/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/xgcc
-shared-libgcc -B/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc
-nostdinc++
-L/usr/local/poudriere/ports/default/lang/gcc7/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/src
-L/usr/local/poudriere/ports/default/lang/gcc7/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/src/.libs
-L/usr/local/poudriere/ports/default/lang/gcc7/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/powerpc64-portbld-freebsd12.0/bin/
-B/usr/local/powerpc64-portbld-freebsd12.0/lib/ -isystem
/usr/local/powerpc64-portbld-freebsd12.0/include -isystem
/usr/local/powerpc64-portbld-freebsd12.0/sys-include
-I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libstdc++-v3/../libgcc
-I/usr/local/poudriere/ports/default/lang/gcc7/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0
-I/usr/local/poudriere/ports/default/lang/gcc7/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/include
-I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=class_type_info.lo -g -O2 -pipe -DLIBICONV_PLUG
-c
/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libstdc++-v3/libsupc++/class_type_info.cc
 -fPIC -DPIC -D_GLIBCXX_SHARED -o class_type_info.o
/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libstdc++-v3/libsupc++/class_type_info.cc:
In member function 'virtual bool
__cxxabiv1::__class_type_info::__do_upcast(const
__cxxabiv1::__class_type_info*, void**) const':
/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libstdc++-v3/libsupc++/class_type_info.cc:45:6:
internal compiler error: Segmentation fault
 bool __class_type_info::
  ^

Interestingly, I can see -O0 added to flags before:
gmake "AR_FLAGS=rc" "CC_FOR_BUILD=cc"
"CC_FOR_TARGET=/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/xgcc
-B/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/" "CFLAGS=-O0"
"CXXFLAGS=-g -O2 -pipe   -DLIBICONV_PLUG " "CFLAGS_FOR_BUILD=-O0"
"CFLAGS_FOR_TARGET=-O0" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=install  -m
0644" "INSTALL_PROGRAM=install  -s -m 555" "INSTALL_SCRIPT=install  -m 555"
"LDFLAGS=" "LIBCFLAGS=-O0" "LIBCFLAGS_FOR_TARGET=-O0" "MAKE=gmake"
"MAKEINFO=makeinfo --no-split --split-size=500 --split-size=500
--split-size=500" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr/local"
"infodir=/usr/local/share/info/gcc7" "libdir=/usr/local/lib/gcc7"
"includedir=/usr/local/include" "prefix=/usr/local"
"tooldir=/usr/local/powerpc64-portbld-freebsd12.0"
"gxx_include_dir=/usr/local/lib/gcc7/include/c++/"
"AR=/usr/local/powerpc64-portbld-freebsd12.0/bin/ar"
"AS=/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/as"
"LD=/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/collect-ld"
"RANLIB=/usr/local/powerpc64-portbld-freebsd12.0/bin/ranlib"
"NM=/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/nm"
"NM_FOR_BUILD=" "NM_FOR_TARGET=/usr/local/powerpc64-portbld-freebsd12.0/bin/nm"
"DESTDIR=" "WERROR=" all-recursive

But the failing command is run strictly with -O2. If I just cd to
'/usr/local/poudriere/ports/default/lang/gcc7/work/.build/libiberty' and run it
manually, but change -O2 to -O0, it passes.

I can't find how to change -O level globally.
I currently set BOOT_CFLAGS="-O0" CFLAGS_FOR_TARGET="-O0"
CFLAGS_FOR_BUILD="-O0" STAGE_CFLAGS="-O0" STAGE2_CXXFLAGS="-O0"
STAGE2_CFLAGS="-O0" STAGE1_CXXFLAGS="-O0" STAGE1_CFLAGS="-O0" and it looks like
some files are compiled with -O0, but some commands still use -O2 (like the one
above). How can I set it to add -O0 everywhere?

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[amodra at gmail dot com]

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

--- Comment #19 from Alan Modra  ---
Created attachment 45829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45829=edit
Prevent use of merge sections when -fsection-anchors

This isn't particularly elegant, but survives bootstrap and regtest on
powerpc64le-linux.  Companion to this patch is an rs6000 backend one that only
enables -fsection-anchors by default when -mcmodel=small.

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[amodra at gmail dot com]

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

--- Comment #18 from Alan Modra  ---
The assertion triggered in multiple places when compiling various libgcc2.c
pieces, and dfp-bit.c.

[Bug tree-optimization/89350] [9 Regression] Wrong -Wstringop-overflow= warning since r261518

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #10 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg02029.html

[Bug c/12245] [7/8/9 regression] Uses lots of memory when compiling large initialized arrays

[fche at redhat dot com]

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

Frank Ch. Eigler  changed:

   What|Removed |Added

 CC||fche at redhat dot com

--- Comment #66 from Frank Ch. Eigler  ---
Just in case it helps, we are encountering this problem with fedora29's gcc
8.2.1,
when compiling a 24-million unsigned-char initialized array:

% gcc -c -Q -v foo.i
[...]

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)
   1243 kB (  0%)
 phase parsing  :  25.26 ( 83%)  26.12 (100%)  51.47 ( 90%)
2592523 kB (100%)
 phase opt and generate :   5.32 ( 17%)   0.08 (  0%)   5.42 ( 10%)
  7 kB (  0%)
 phase finalize :   0.00 (  0%)   0.02 (  0%)   0.13 (  0%)
  0 kB (  0%)
 garbage collection :   1.27 (  4%)   0.00 (  0%)   1.27 (  2%)
  0 kB (  0%)
 callgraph construction :   4.05 ( 13%)   0.08 (  0%)   4.15 (  7%)
  5 kB (  0%)
 preprocessing  :   5.99 ( 20%)   6.39 ( 24%)  12.20 ( 21%)
 524289 kB ( 20%)
 lexical analysis   :   7.34 ( 24%)   8.90 ( 34%)  16.18 ( 28%)
  0 kB (  0%)
 parser (global):  11.93 ( 39%)  10.83 ( 41%)  23.09 ( 40%)
2068233 kB ( 80%)
 TOTAL  :  30.58 26.24 57.05   
2593783 kB

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

[egallager at gcc dot gnu.org]

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

--- Comment #22 from Eric Gallager  ---
(In reply to Eric Gallager from comment #21)
> (In reply to Iain Sandoe from comment #20)
> > (In reply to Eric Gallager from comment #19)
> > > (In reply to jos...@codesourcery.com from comment #18)
> > > > Whether this is fixed may be determined by running all of the programs 
> > > > installed in $exec_prefix/bin by current mainline with the --help and 
> > > > --version options (and confirming the GCC version number is properly 
> > > > shown 
> > > > in the --version output).
> > > 
> > > looks like gcc-nm and gcc-ranlib still fail with --help:
> > 
> > That's not a fault with the GCC wrappers, it's because the "upstream"
> > cctools nm and ranlib don't respond to "--help" (or --version).  I have
> > amended versions of them that handle --help and --version (available on
> > github***) that work:
> > 
> > $ ./gcc/gcc-ar --help
> > usage:  ar -d [-TLsv] archive file ...
> > ar -m [-TLsv] archive file ...
> > 
> > 
> > $ ./gcc/gcc-ar --version
> > xtools-1.1.0 ar
> > 
> > - the point is that this is not a problem with the GCC wrappers, the
> > intention of them is to pass the --help and --version onto the underlying
> > commands.
> > 
> > From the point of view of Darwin, I'd say this could be closed, of course it
> > might not be completely clean for other platforms.
> > 
> > *** Note: the versions published on github are quite old - on the TODO to
> > provide some updates.
> 
> OK, closing then.

Opened an issue on GitHub for your version of cctools about this:
https://github.com/iains/darwin-xtools/issues/3

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[amodra at gmail dot com]

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

--- Comment #17 from Alan Modra  ---
The correct place for comment #15 patch is get_block_for_decl, I think.  I'm
bootstrapping such a patch along with an assert in output_object_block that we
don't have a merge section.

[Bug target/89502] Inefficient access to stack_guard in TCB

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
rtx
memory_address_addr_space (machine_mode mode, rtx x, addr_space_t as)
{
  rtx oldx = x; 
  scalar_int_mode address_mode = targetm.addr_space.address_mode (as);

  x = convert_memory_address_addr_space (address_mode, x, as); 

  /* By passing constant addresses through registers
 we get a chance to cse them.  */
  if (! cse_not_expected && CONSTANT_P (x) && CONSTANT_ADDRESS_P (x)) 
x = force_reg (address_mode, x);

cprop undoes it, which isn't enabled by O1.  For x86, using register
instead of a 32-bit constant usually is a performance loss.  Shouldn't
backend have a choice here?

[Bug target/87199] Thread local storage dynamic initialization behaviour differs Linux vs macOS

[drikosev at gmail dot com]

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

--- Comment #5 from Ev Drikos  ---
 Hello,

 At first, I'd like to note that these 2 options are also ok in MacOS-10.13:
 (a) g++8 -g  -std=c++11  lib.cpp   main.c -o main && ./main
 (b) g++8 -g  -std=c++11 -I . main.c-S
 g++8 -g  -std=c++11 -I . lib.cpp   -S 
 g++8 -g  -std=c++11 -I . lib.s main.s -o main && ./main

 Just for the record, a fresh built gcc-4.8.5~36 in OS X Yosemite (10.10) 
 doesn't have this problem but I just faced it in OS X Mavericks (10.9),
 where I had to properly comment the stmt "ld_uses_coal_sects = true" in
 file "darwin.c", added by an unofficial backport of PR/71767.


 Hope this helps,
 Ev. Drikos

[Bug libstdc++/89477] Incorrect CTAD deduction guides for set and multiset

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for all associative and unordered containers.

[Bug libstdc++/89477] Incorrect CTAD deduction guides for set and multiset

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Feb 26 23:12:44 2019
New Revision: 269234

URL: https://gcc.gnu.org/viewcvs?rev=269234=gcc=rev
Log:
PR libstdc++/89477 constrain deduction guides for maps and sets

The Compare, Hash, and Pred template parameters should be constrained in
the C++17 deduction guides for associative and unordered containers.

The deduction guides for stack, queue and priority_queue are already
constrained, but this patch makes them use the _RequireNotAllocator
helper instead of reproducing the logic each time.

PR libstdc++/89477
* include/bits/alloc_traits.h (_RequireNotAllocator): New helper for
container deduction guides.
* include/bits/hashtable.h (_RequireNotAllocatorOrIntegral): Likewise.
* include/bits/stl_map.h (map): Use _RequireNotAllocator to constrain
parameters in deduction guides.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_queue.h (queue, priority_queue): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_stack.h (stack): Likewise.
* include/bits/unordered_map.h (unordered_map, unordered_multimap):
use _RequireNotAllocator and _RequireNotAllocatorOrIntegral to
constrain parameters in deduction guides.
* include/bits/unordered_set.h (unordered_set, unordered_multiset):
Likewise.
* testsuite/23_containers/map/cons/deduction.cc: Test additional
deduction cases.
* testsuite/23_containers/multiset/cons/deduction.cc: Likewise.
* testsuite/23_containers/set/cons/deduction.cc: Likewise.
* testsuite/23_containers/unordered_map/cons/deduction.cc: Likewise.
* testsuite/23_containers/unordered_multimap/cons/deduction.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/cons/deduction.cc:
Likewise.
* testsuite/23_containers/unordered_set/cons/deduction.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/alloc_traits.h
trunk/libstdc++-v3/include/bits/hashtable.h
trunk/libstdc++-v3/include/bits/stl_map.h
trunk/libstdc++-v3/include/bits/stl_multimap.h
trunk/libstdc++-v3/include/bits/stl_multiset.h
trunk/libstdc++-v3/include/bits/stl_queue.h
trunk/libstdc++-v3/include/bits/stl_set.h
trunk/libstdc++-v3/include/bits/stl_stack.h
trunk/libstdc++-v3/include/bits/unordered_map.h
trunk/libstdc++-v3/include/bits/unordered_set.h
trunk/libstdc++-v3/testsuite/23_containers/map/cons/deduction.cc
trunk/libstdc++-v3/testsuite/23_containers/multiset/cons/deduction.cc
trunk/libstdc++-v3/testsuite/23_containers/set/cons/deduction.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/cons/deduction.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/cons/deduction.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/cons/deduction.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/cons/deduction.cc

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[dvoreader at gmail dot com]

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

Orr Shalom Dvory  changed:

   What|Removed |Added

 CC||dvoreader at gmail dot com

--- Comment #33 from Orr Shalom Dvory  ---
(In reply to Jakub Jelinek from comment #25)
> Created attachment 44657 [details]
> gcc9-pr82853.patch
> 
> Full untested patch.  For x % C1 == C2 it handles all unsigned cases where
> C1 is odd, if C1 is even, just cases where C2 <= -1U % C1, if signed modulo,
> just x % C1 == 0 cases (where C1 is not INT_MIN).

Hi, I will try to help. I've got a more accurate formula. look at my comment
over here https://reviews.llvm.org/D50222
I'm copying it here for the sake of all. 
Hi guys, I found the magical formula for unsigned integers that works also with
even numbers without the need to check for overflows with any remainder:
from divisor d and reminder r, I calculate 4 constants.
any d!=0 should fit.

void calculate_constants64(uint64_t d, uint64_t r, uint64_t ,uint64_t ,
uint64_t ,uint64_t& u)
{
k=__builtin_ctzll(d);/* the power of 2 */
uint64_t d_odd=d>>k;
mmi=find_mod_mul_inverse(d_odd,64);
/* 64 is word size*/
s=(r*mmi);
u=(ULLONG_MAX-r)/d;/* note that I divide by d, not d_odd */
}
A little bit background: the constant (u +1) is the count of the possible
values in the range of 64 bit number that will yield the correct modulo.
The constant s should zero the first k bits if the given value have modulo of
r. it will also zero the modulo of d_odd.

then the compiler should generate the following code with the given constants:

int checkrem64(uint64_t k,uint64_t mmi, uint64_t s,uint64_t u,uint64_t x)
{
uint64_t o=((x*mmi)-s);
o= (o>>k)|(o<<(64-k));/*ROTR64(o,k)*/
return o<=u;
}
this replace the following:

/* d is the divisor, r is the remainder */
int checkrem64(uint64_t x)
{
  return x%d==r;
}
this is the code to find modular inverse..

uint64_t find_mod_mul_inverse(uint64_t x, uint64_t bits)
{
  if (bits > 64 || ((x&1)==0))
  return 0;// invalid parameters
  uint64_t mask;
  if (bits == 64)
  mask = -1;
  else
  {
  mask = 1;
  mask<<=bits;
  mask--;
  }
  x&=mask;
  uint64_t result=1, state=x, ctz=0;
  while(state!=1ULL)
  {
  ctz=__builtin_ctzll(state^1);
  result|=1ULL<>k;
mmi=find_mod_mul_inverse(d_odd,64);
/* 64 is word size*/
 //this is the added line to make it work with signed integers
  r+=0x8000   % d;
s=(r*mmi);
u=(ULLONG_MAX-r)/d;
}

int checkrem64(uint64_t k,uint64_t mmi, uint64_t s,uint64_t u,uint64_t x)
{
 //this is the added line to make it work with signed integers
//x came as signed number but was casted to unsigned
x^=0x8000   ;// this is addition simplified to xor, spaces for
clarity.
uint64_t o=((x*mmi)-s);
o= (o>>k)|(o<<(64-k));/*ROTR64(o,k)*/
return o<=u;
}
There is a way to tweak u and s to make it work on negative only numbers or
positive only numbers, when r is negative or positive... but for r=0, this
should work. please tell me the exact requirements, and I will do the math.

[Bug target/83670] m32c ICE in leaf_function_p, at final.c:4368

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Exposed by https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01027.html .
The value might already be cached by the time we call leaf_function_p in
crtl->is_leaf which can be used here instead.


Related to the similar issue on mmix: PR 85666.

[Bug target/89515] m32c ICE error: in leaf_function_p, at final.c:4492 when compiling newlib 3.1.0 with XGCC 8.3.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Yes it is a dup.

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

[Bug target/83670] m32c ICE in leaf_function_p, at final.c:4368

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hdu...@tangerine-soft.de

--- Comment #1 from Andrew Pinski  ---
*** Bug 89515 has been marked as a duplicate of this bug. ***

[Bug target/89515] m32c ICE error: in leaf_function_p, at final.c:4492 when compiling newlib 3.1.0 with XGCC 8.3.0

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely a dup of bug 83670.

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
If that works, I'm all for it.
CCing Richard Sandiford as the original author of -fsection-anchors if he
remembers why this hasn't been done for SECTION_MERGE sections from the
beginning.
default_use_anchors_for_symbol_p starts with
  /* Don't use anchors for mergeable sections.  The linker might move
 the objects around.  */
  sect = SYMBOL_REF_BLOCK (symbol)->sect;
  if (sect->common.flags & SECTION_MERGE)
return false;
and seems all other targetm.use_anchors_for_symbol_p hooks just return false in
a few extra cases than default_use_anchors_for_symbol_p, never return true when
it doesn't.
So indeed, I don't see advantages in using SYMBOL_REF_BLOCK for SECTION_MERGE
section symbols.

[Bug c/89515] New: m32c ICE error: in leaf_function_p, at final.c:4492 when compiling newlib 3.1.0 with XGCC 8.3.0

[hdu...@tangerine-soft.de]

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

Bug ID: 89515
   Summary: m32c ICE error: in leaf_function_p, at final.c:4492
when compiling newlib 3.1.0 with XGCC 8.3.0
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hdu...@tangerine-soft.de
  Target Milestone: ---

m32c-none-elf-gcc
-B/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/newlib/
-isystem
/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/newlib/targ-include
-isystem
/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/include
-B/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/libgloss/m32c
-L/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/libgloss/libnosys
-L/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/libgloss/m32c 
-mcpu=m32cm -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz -Os
-fno-builtin -DPREFER_SIZE_OVER_SPEED -DSMALL_MEMORY -D__NO_SYSCALLS__
-DMISSING_SYSCALL_NAMES -DABORT_PROVIDED -DHAVE_INIT_FINI  -g -O2 
-mcpu=m32cm -c -o lib_a-argz_create_sep.o `test -f 'argz_create_sep.c' || echo
'/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz/'`argz_create_sep.c
m32c-none-elf-gcc
-B/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/newlib/
-isystem
/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/newlib/targ-include
-isystem
/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/include
-B/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/libgloss/m32c
-L/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/libgloss/libnosys
-L/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/libgloss/m32c 
-mcpu=m32cm -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz -Os
-fno-builtin -DPREFER_SIZE_OVER_SPEED -DSMALL_MEMORY -D__NO_SYSCALLS__
-DMISSING_SYSCALL_NAMES -DABORT_PROVIDED -DHAVE_INIT_FINI  -g -O2 
-mcpu=m32cm -c -o lib_a-argz_delete.o `test -f 'argz_delete.c' || echo
'/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz/'`argz_delete.c
m32c-none-elf-gcc
-B/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/newlib/
-isystem
/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/newlib/targ-include
-isystem
/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/include
-B/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/libgloss/m32c
-L/tmp/build_cross_gcc/newlib-3.1.0_build_m32c-none-elf/m32c-none-elf/m32cm/libgloss/libnosys
-L/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/libgloss/m32c 
-mcpu=m32cm -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz -Os
-fno-builtin -DPREFER_SIZE_OVER_SPEED -DSMALL_MEMORY -D__NO_SYSCALLS__
-DMISSING_SYSCALL_NAMES -DABORT_PROVIDED -DHAVE_INIT_FINI  -g -O2 
-mcpu=m32cm -c -o lib_a-argz_extract.o `test -f 'argz_extract.c' || echo
'/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz/'`argz_extract.c
during RTL pass: pro_and_epilogue
/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz/argz_count.c:
In function 'argz_count':
/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz/argz_count.c:25:1:
internal compiler error: in leaf_function_p, at final.c:4492
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [lib_a-argz_count.o] Error 1
make[8]: *** Waiting for unfinished jobs
during RTL pass: pro_and_epilogue
/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz/argz_append.c:
In function 'argz_append':
/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz/argz_append.c:31:1:
internal compiler error: in leaf_function_p, at final.c:4492
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
during RTL pass: pro_and_epilogue
/tmp/build_cross_gcc/newlib-3.1.0_arch/newlib-3.1.0/newlib/libc/argz/argz_add.c:
In function 'argz_add':

[Bug c++/89513] constexpr functions with function try block shouldn't be accepted at least with -pedantic in -std=c++{11,14,17} modes

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 CC||msebor at gcc dot gnu.org
 Blocks||55004
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Clang 7 prints:

$ clang++ -S -Wall pr89513.C
pr89513.C:2:1: error: function try block not allowed in constexpr function
try {
^
pr89513.C:9:3: error: statement not allowed in constexpr function
  try { return true; } catch (...) {}
  ^
2 errors generated.


The latest Clang with -Wall:

pr89513.C:3:1: warning: function try block in constexpr function is a C++2a
extension [-Wc++2a-extensions]
try {
^
pr89513.C:6:1: warning: control may reach end of non-void function
[-Wreturn-type]
}
^
pr89513.C:10:3: warning: use of this statement in a constexpr function is a
C++2a extension [-Wc++2a-extensions]
  try { return true; } catch (...) {}
  ^
pr89513.C:14:16: warning: unused variable 'a' [-Wunused-const-variable]
constexpr auto a = foo ();
   ^
pr89513.C:15:16: warning: unused variable 'b' [-Wunused-const-variable]
constexpr auto b = bar ();
   ^
5 warnings generated.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[bernd.edlinger at hotmail dot de]

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

--- Comment #15 from Bernd Edlinger  ---
I wonder if this would also work?
At least for simple test cases that seems to be fine.

--- varasm.c.orig   2019-01-25 17:57:32.0 +0100
+++ varasm.c2019-02-26 22:03:39.753325517 +0100
@@ -373,6 +373,9 @@ get_block_for_section (section *sect)
   if (sect == NULL)
 return NULL;

+  if (sect->common.flags & SECTION_MERGE)
+return NULL;
+
   object_block **slot
 = object_block_htab->find_slot_with_hash (sect, hash_section (sect),
  INSERT);

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/87996] [8 Regression] "size of array is negative" error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX

[jakub at gcc dot gnu.org]

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

Bug 89507 Summary: [9 Regression] bogus "size of array exceeds maximum object 
size"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89507

   What|Removed |Added

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

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 26 21:27:33 2019
New Revision: 269233

URL: https://gcc.gnu.org/viewcvs?rev=269233=gcc=rev
Log:
PR c++/89507
* tree.c (valid_constant_size_p): Deal with size INTEGER_CSTs
with types other than sizetype/ssizetype.

* g++.dg/other/new2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/other/new2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug tree-optimization/89500] [9 Regression] ICE: tree check: expected integer_cst, have ssa_name in get_len, at tree.h:5653

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
(In reply to Paolo Carlini from comment #9)
> Totally agreed.

Thanks (also thanks for the DR reference)!.

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  ---
Totally agreed.

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
(In reply to Paolo Carlini from comment #7)
> Thus, to repeat, if we only want to avoid the regression part, it would be
> just matter of changing the code I added for c++/60265 to do qscope =
> CP_TYPE_CONTEXT (qscope) only when we end-up in a namespace. On the other
> hand, if we want to go beyond that we have a little more non-trivial work to
> do.

I think I'll do just that.  I don't know what we would use as the
USING_DECL_SCOPE in this case; anything other than a NAMESPACE_DECL won't work
currently.  do_nonmember_using_decl uses qualified_namespace_lookup so that
would require further changes.

And maybe the DR will be resolved in such a way that both examples will be
ill-formed.

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
Thus, to repeat, if we only want to avoid the regression part, it would be just
matter of changing the code I added for c++/60265 to do qscope =
CP_TYPE_CONTEXT (qscope) only when we end-up in a namespace. On the other hand,
if we want to go beyond that we have a little more non-trivial work to do.

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  ---
Yes, it works, it's c++/60265.

[Bug tree-optimization/89500] [9 Regression] ICE: tree check: expected integer_cst, have ssa_name in get_len, at tree.h:5653

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 26 20:36:29 2019
New Revision: 269230

URL: https://gcc.gnu.org/viewcvs?rev=269230=gcc=rev
Log:
PR tree-optimization/89500
* tree-ssa-strlen.c (stridx_strlenloc): Adjust comment.
(handle_builtin_strlen): Remove noncst_bound variable.  Always
optimize strnlen (x, 0) to 0.  Optimize strnlen (x, cst) to
cst if the first cst bytes starting at x are known to be non-zero,
even if the string is not zero terminated.  Don't try to modify
*si for strnlen.  Update strlen_to_stridx only for strlen or if
we can prove strnlen returns the same value as strlen would.

* gcc.dg/pr89500.c: New test.
* gcc.dg/Wstringop-overflow-10.c: New test.
* gcc.dg/strlenopt-60.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-10.c
trunk/gcc/testsuite/gcc.dg/pr89500.c
trunk/gcc/testsuite/gcc.dg/strlenopt-60.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug libstdc++/89416] [9 regression] std::vector::push_back no longer builds.

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue Feb 26 20:34:46 2019
New Revision: 269229

URL: https://gcc.gnu.org/viewcvs?rev=269229=gcc=rev
Log:
PR libstdc++/89416 fix alloc insertable trait for clang (again)

PR libstdc++/89416
* include/bits/alloc_traits.h (__is_alloc_insertable_impl): Change
to class template and partial specialization using void_t.
(__is_copy_insertable, __is_move_insertable): Adjust base class.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/alloc_traits.h

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
This works:

namespace N {
  enum E { e };
  using E::e;
}

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #4 from Marek Polacek  ---
Changing the keywords;
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742 says it's
well-formed.

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
To clarify a bit: if I revert r211479 we don't ICE anymore on the new testcase
but we reject it anyway and using-enum-1.C too, which instead we should accept.
By the way, Core/1742 is still open ;)

[Bug lto/89514] -g -fdebug-types-section -flto gives 'Dwarf Error: bad length' in gdb

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||87295

--- Comment #1 from Andrew Pinski  ---
Related to PR 87295.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295
[Bug 87295] [8 Regression][early debug] ICE with -ffat-lto-objects
-fdebug-types-section -g

[Bug lto/89514] New: -g -fdebug-types-section -flto gives 'Dwarf Error: bad length' in gdb

[gcc at mailinator dot com]

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

Bug ID: 89514
   Summary: -g -fdebug-types-section -flto gives 'Dwarf Error: bad
length' in gdb
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mailinator dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

#include 
int main() 
{
std::cout << "Hello, World!";
return 0;
}

g++ hello_world.cc -g -fdebug-types-section -flto -o hello_world
gdb hello_world

Then GDB 7.11.1, 8.1, 8.2 reports: 
Dwarf Error: bad length (0xe7) in compilation unit header (offset 0x1e3a + 0)

For larger binaries GDB reports a corrupted dwarf version:
Dwarf Error: wrong version in compilation unit header (is 3745, should be 2, 3,
or 4)

Reproduced on GCC 8.1, 8.2, 8.3 with Binutils 2.30 and Binutils 2.32.

At first I suspected Binutils, then GDB, but I think this is a GCC issue, since
-fdebug-types-section works with -fwhole-program, but not -flto.

[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Tue Feb 26 20:03:08 2019
New Revision: 269227

URL: https://gcc.gnu.org/viewcvs?rev=269227=gcc=rev
Log:
2019-02-26  Harald Anlauf  

PR fortran/89492
* check.c (gfc_calculate_transfer_sizes): Handle cases where
storage size of elements of MOLD is 0.

PR fortran/89492
* gfortran.dg/pr89492.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr89492.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[darkkirb at darkkirb dot de]

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

--- Comment #9 from darkkirb at darkkirb dot de ---
I have bisected the fix a bit (I didn't have enough time today to finish it)
and i found that the fix has happened in one of the 322 commits between 

d1540be4d3b4b8ac6d19997539c13d2ca74f65e4 (2018-09-26, broken)

and 

44257478a8d157f8e0030bb7abe1c3ac91be9302 (2018-10-31, fixed)

Hopefully the fix can be applied to the gcc-8_0 branch.

[Bug c++/89513] New: constexpr functions with function try block shouldn't be accepted at least with -pedantic in -std=c++{11,14,17} modes

[jakub at gcc dot gnu.org]

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

Bug ID: 89513
   Summary: constexpr functions with function try block shouldn't
be accepted at least with -pedantic in
-std=c++{11,14,17} modes
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

With -std=c++{11,14,17} -pedantic-errors we should reject both of these
functions, but we do reject just bar and not foo.  I assume this ought to be
valid C++2a (though wonder if the catch block needs to contain only valid
constexpr constructs even when it is not actually ever evaluated during
constexpr evaluation).

constexpr bool foo ()
try {
  return true;
} catch (...) {
}

constexpr bool bar ()
{
  try { return true; } catch (...) {}
  return true;
}

constexpr auto a = foo ();
constexpr auto b = bar ();

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[tkoenig at gcc dot gnu.org]

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

Bug 89496 Summary: [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime 
error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496

   What|Removed |Added

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

[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Feb 26 19:10:00 2019
New Revision: 269226

URL: https://gcc.gnu.org/viewcvs?rev=269226=gcc=rev
Log:
2019-02-26  Thomas Koenig  

PR fortran/89496
* trans-types.c (get_formal_from_actual_arglist): If
the actual arglist has no expression, the corresponding
formal arglist is an alternate return.

2019-02-26  Thomas Koenig  

PR fortran/89496
* gfortran.dg/altreturn_9_0.f90: New file.
* gfortran.dg/altreturn_9_1.f90: New file.


Added:
trunk/gcc/testsuite/gfortran.dg/altreturn_9_0.f90
trunk/gcc/testsuite/gfortran.dg/altreturn_9_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed, closing.

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.5

[Bug c++/89512] [7/8/9 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:882

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|ICE in get_expr_operands,   |[7/8/9 Regression] ICE in
   |at tree-ssa-operands.c:882  |get_expr_operands, at
   ||tree-ssa-operands.c:882
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r214396.

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Since Jakub already has a fix I'm unassigning myself.

[Bug c++/89511] [7/8/9 Regression] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|ICE in push_using_decl_1,   |[7/8/9 Regression] ICE in
   |at cp/name-lookup.c:3845|push_using_decl_1, at
   ||cp/name-lookup.c:3845

--- Comment #2 from Marek Polacek  ---
GCC 4.9.4 doesn't ICE.  Started with r211479.

[Bug target/89434] [7/8 Regression] wrong code with -Og and __builtin_mul_overflow()

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
The PR89506 patch might contain a fix for this.

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[bernd.edlinger at hotmail dot de]

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

--- Comment #14 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #13)
> 
> Well, it matches what output_constant does:
> case STRING_CST:
>   thissize = (unsigned HOST_WIDE_INT)TREE_STRING_LENGTH (exp);
>   if (merge_strings
>   && (thissize == 0
>   || TREE_STRING_POINTER (exp) [thissize - 1] != '\0'))
> thissize++;
> (using MAX just in case there is already some extra padding in the length or
> whatever else).

Ah, well. Just FYI, this check in output_constant

  if (size == 0 || flag_syntax_only)
return size;

prevents zero-padding of strings with STRING_LENGTH==0 && DECL_SIZE==0.

But due to the check in mergeable_string_section

  && (len = int_size_in_bytes (TREE_TYPE (decl))) > 0
  && TREE_STRING_LENGTH (decl) == len)

we should not get size==0 or thissize == 0 in a merge_strings section.
So it should not make a difference what happens with thissize==0.

[Bug c++/89511] ICE in push_using_decl_1, at cp/name-lookup.c:3845

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/89434] [7/8 Regression] wrong code with -Og and __builtin_mul_overflow()

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #8 from Tamar Christina  ---
This is causing a glibc build failure on arm-none-Linux-gnueabihf, for some
reason I can only reproduce it native but not cross. Don't exactly know why...

configured with

```
--enable-languages=c,c++,fortran --target=arm-none-linux-gnueabihf
--build=arm-none-linux-gnueabihf --host=arm-none-linux-gnueabihf
--with-arch=armv7-a --with-fpu=neon --with-float=hard --with-mode=thumb
```

repro case

```
long long a;

void f () {
  if (a >= 9223372036854775807 - 1 + 400)
for (;;)
  ;
}
```

compiled with

```
-c -O2 -Wno-maybe-uninitialized
```

Which gets combined by combine into

```
Trying 8 -> 10:
8: r112:DI=0x818e
   10: {cc:CC_NCV=cmp(r113:DI,r112:DI);clobber scratch;}
  REG_DEAD r113:DI
  REG_DEAD r112:DI
  REG_EQUAL cmp(r113:DI,0x818e)
Successfully matched this instruction:
(parallel [
(set (reg:CC_NCV 100 cc)
(compare:CC_NCV (reg:DI 113 [ aD.5557 ])
(const_int -9223372036854775410 [0x818e])))
(clobber (scratch:SI))
])
allowing combination of insns 8 and 10
```

and then later is split into

```
(insn 51 50 11 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 3 r3 [ aD.5557+4 ])
(const_int -2147483648 [0x8000])))
(set (reg:SI 3 r3 [114])
(minus:SI (plus:SI (reg:SI 3 r3 [ aD.5557+4 ])
(const_int -2147483648 [0x8000]))
(ltu:SI (reg:CC_C 100 cc)
(const_int 0 [0]
]) "zic.i":4:6 -1
 (nil))
```

Which matches no instruction and so ICEs.  On a cross build this seems to get
split into

```
(insn 51 50 11 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 3 r3 [ aD.5557+4 ])
(const_int 2147483647 [0x7fff])))
(set (reg:SI 3 r3 [114])
(minus:SI (plus:SI (reg:SI 3 r3 [ aD.5557+4 ])
(const_int 2147483647 [0x7fff]))
(ltu:SI (reg:CC_C 100 cc)
(const_int 0 [0]
]) "zin.i":4:6 32 {*subsi3_carryin_compare_const}
 (nil))
```

So the constants seem to be different.

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[segher at gcc dot gnu.org]

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

--- Comment #20 from Segher Boessenkool  ---
Maybe you want to say  .-1  instead of  -1  ?

[Bug go/89171] FAIL: go/build

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|riscv64-*-* |

--- Comment #5 from Andreas Schwab  ---
If $GOROOT is unset, ctxt.GOROOT it set to "/usr".  listStdPkgs then finds all
the files in /usr/src/debug.

[Bug c++/89512] New: ICE in get_expr_operands, at tree-ssa-operands.c:882

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

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

Bug ID: 89512
   Summary: ICE in get_expr_operands, at tree-ssa-operands.c:882
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gcc-5, no ICE seen with 4.9 or older :


$ cat z1.cc
struct A {
  template 
  static const int a = 0;
};
struct B {
  template 
  static int foo ()
  {
return B::a;
  }
};
int bar ()
{
  int i = B::foo ();
}


$ g++-9-20190224 -c z1.cc
z1.cc: In function 'int bar()':
z1.cc:15:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   15 | }
  | ^
unhandled expression in get_expr_operands():
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f4cbd179bd0 precision:32 min  max
>
used decl_1 VOID z1.cc:3:20
align:1 warn_if_not_align:0 context 
parms 
value 
length:1
elt:0 >>>
full-name "template const int A::a"
chain >

during GIMPLE pass: ssa
z1.cc: In static member function 'static int B::foo() [with B = A]':
z1.cc:15:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:882
0xfd18e9 get_expr_operands
../../gcc/tree-ssa-operands.c:882
0xfd24cd parse_ssa_operands
../../gcc/tree-ssa-operands.c:932
0xfd3d23 build_ssa_operands
../../gcc/tree-ssa-operands.c:947
0xfd3d23 update_stmt_operands(function*, gimple*)
../../gcc/tree-ssa-operands.c:1081
0xed1f4a update_stmt
../../gcc/gimple-ssa.h:175
0xed1f4a mark_def_sites
../../gcc/tree-into-ssa.c:649
0xed1f4a mark_def_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-into-ssa.c:2346
0x16925c7 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xed4619 execute
../../gcc/tree-into-ssa.c:2458

[Bug fortran/67542] ICE in gfc_emit_parameter_debug_info, at fortran/trans-decl.c:4947 and :4945

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

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

G. Steinmetz  changed:

   What|Removed |Added

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

--- Comment #9 from G. Steinmetz  ---
Yep, done.

[Bug c++/89212] [8 Regression] ICE in fold_convert_loc at fold-const.c:2552

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Author: mpolacek
Date: Tue Feb 26 18:00:41 2019
New Revision: 269222

URL: https://gcc.gnu.org/viewcvs?rev=269222=gcc=rev
Log:
PR c++/89212 - ICE converting nullptr to pointer-to-member-function.
* pt.c (tsubst_copy_and_build) : Return early for
null member pointer value.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/nullptr40.C
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/nullptr41.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/89212] [8 Regression] ICE in fold_convert_loc at fold-const.c:2552

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
Fixed.

[Bug c/89511] New: ICE in push_using_decl_1, at cp/name-lookup.c:3845

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

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

Bug ID: 89511
   Summary: ICE in push_using_decl_1, at cp/name-lookup.c:3845
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Seems to be an older issue (with -std=c++17) :


$ cat z1.cc
void f ()
{
  enum e { a };
  using e::a;
}


$ g++-9-20190224 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:4:12: internal compiler error: in push_using_decl_1, at
cp/name-lookup.c:3845
4 |   using e::a;
  |^
0x6922f9 push_using_decl_1
../../gcc/cp/name-lookup.c:3845
0x6922f9 push_using_decl
../../gcc/cp/name-lookup.c:3866
0x6922f9 validate_nonmember_using_decl
../../gcc/cp/name-lookup.c:3967
0x699767 finish_local_using_decl(tree_node*, tree_node*, tree_node*)
../../gcc/cp/name-lookup.c:5166
0x6c9711 cp_parser_using_declaration
../../gcc/cp/parser.c:19495
0x6b8639 cp_parser_declaration_statement
../../gcc/cp/parser.c:12922
0x6b9097 cp_parser_statement
../../gcc/cp/parser.c:11246
0x6b9f20 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11608
0x6b9fcf cp_parser_compound_statement
../../gcc/cp/parser.c:11562
0x6d0830 cp_parser_function_body
../../gcc/cp/parser.c:22578
0x6d0830 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:22615
0x6d0b10 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:27682
0x6d17c3 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:27598
0x6d17c3 cp_parser_init_declarator
../../gcc/cp/parser.c:20221
0x6b6b0e cp_parser_simple_declaration
../../gcc/cp/parser.c:13492
0x6d6b34 cp_parser_declaration
../../gcc/cp/parser.c:13189
0x6d728e cp_parser_translation_unit
../../gcc/cp/parser.c:4698
0x6d728e c_parse_file()
../../gcc/cp/parser.c:41062
0x796060 c_common_parse_file()
../../gcc/c-family/c-opts.c:1155

[Bug libstdc++/89510] New: new_allocator::construct needs to be constrained

[redi at gcc dot gnu.org]

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

Bug ID: 89510
   Summary: new_allocator::construct needs to be constrained
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The construct member has an exception specification which might cause errors
outside the immediate context when trying to determine if the function is
callable.

We should either remove the exception specification (which would be a step
backwards) or should constrain the function using enable_if.

This isn't currently causing issues because we only use the function in
contexts where it's required to work anyway. However, the internal
__is_copy_insertable and __is_move_insertable traits do attempt to check if the
construct() function template is invocable, and so could hit this issue.
Currently we don't use __is_copy_insertable, and only use __is_move_insertable
in contexts where move insertion into std::vector is required to be valid
anyway.

Any other allocators that have a conditional exception specification (including
at least malloc_allocator) need the same change.

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The reason to change tree.c rather than doing something on the cp/init.c side
is the comment there that the checking ought to be done before conversion to
std::size_t (and also, we'd fold to sizetype just for the purposes of the
diagnostics and throw away the result).

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[jakub at gcc dot gnu.org]

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

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

Untested patch I have right now.

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|diagnostic  |rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-26
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Let me look into it.

[Bug rtl-optimization/87761] [9 regression][MIPS] New FAIL: gcc.target/mips/fix-r4000-10.c -O1 start with r265398

[law at gcc dot gnu.org]

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

--- Comment #14 from Jeffrey A. Law  ---
Author: law
Date: Tue Feb 26 17:08:06 2019
New Revision: 269218

URL: https://gcc.gnu.org/viewcvs?rev=269218=gcc=rev
Log:
PR rtl-optimization/87761
* regcprop.c (copyprop_hardreg_forward_1): Use REG_UNUSED notes to
detect obviously dead insns and delete them.

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

[Bug middle-end/89501] Odd lack of warning about missing initialization

[torva...@linux-foundation.org]

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

--- Comment #8 from Linus Torvalds  ---
(In reply to Jeffrey A. Law from comment #7)
> It's reliably the case that a false positive uninit warning also represents
> a failure to optimize something.  So we've got significant incentives to
> deeply analyze and look for fixes.  So feel free to pass examples of those
> along.

Well, most of it is due to interactions with *other* issues entirely.

For example, when we enable GCOV for coverage checking, we have to disable
tree-loop-im, because of excessive stack usage due to gcc bugzilla 69702.

And disabling that optimization then leads to bogus "might be used
uninitialized" warnings.

We have a few other cases like that. Eg we can't use -Os without also disabling
-Wmaybe-uninitialized etc.

Some of the cases may be historical (ie maybe you've fixed the issues that
cause us to do that in newer versions), but for various distro reasons we end
up supporting old compilers for a _looong_ time.

We not that long ago ended up increasing the minimum required gcc version for
the kernel to gcc-4.6.

So we have this odd "we love using new features" fight with "oops, but we end
up having people using relatively ancient compiler versions".

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
valid_constant_size_p assumes it is sizetype/ssizetype constant, but in this
case we check it before converting it to sizetype.  Checking now if it is just
one spot or if there aren't others.

[Bug libstdc++/89416] [9 regression] std::vector::push_back no longer builds.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Jonathan Wakely  ---
Sigh, I tested with clang but using std::allocator, which is handled by a
partial specialization. It's still broken with clang.

[Bug middle-end/89501] Odd lack of warning about missing initialization

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
It's reliably the case that a false positive uninit warning also represents a
failure to optimize something.  So we've got significant incentives to deeply
analyze and look for fixes.  So feel free to pass examples of those along.

[Bug middle-end/89501] Odd lack of warning about missing initialization

[torva...@linux-foundation.org]

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

--- Comment #6 from Linus Torvalds  ---
(In reply to Richard Biener from comment #5)
> 
> And this meeting helps us avoid bogus warnings for cases where GCC has
> difficulties proving dead code paths are actually dead ... 

Ack. I do see the difficulty. We already disable some of the
"may-be-uninitialized" warnings in the kernel because they end up being too
noisy for some configurations.

NP. If you guys figure something out, it will be good. If not, we'll survive.

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Bernd Edlinger from comment #11)
> Instead of:
> 
> if (thissize == 0
> || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
>   size = MAX (size, thissize + 1);
> 
> maybe:
> 
> if (thissize != 0
> && TREE_STRING_POINTER (str) [thissize - 1] != '\0')
>   size = MAX (size, thissize + 1);

Well, it matches what output_constant does:
case STRING_CST:
  thissize = (unsigned HOST_WIDE_INT)TREE_STRING_LENGTH (exp);
  if (merge_strings
  && (thissize == 0
  || TREE_STRING_POINTER (exp) [thissize - 1] != '\0'))
thissize++;
(using MAX just in case there is already some extra padding in the length or
whatever else).

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger  ---
> These should not go into mergeable sections.

I mean: These do not go into mergeable sections.

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
I agree, that it would be better to not put any
mergeable things in a block object.  If section anchors
are ever used on a string constant, it is going to fail.

A constant with size = 0 is possible, for instance
in Ada an empty string really empty.  These should not
go into mergeable sections.  output_constant
ignores the merge_strings parameter, therefore
I would not assume there is a zero termination


Instead of:

  if (thissize == 0
  || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
size = MAX (size, thissize + 1);

maybe:

  if (thissize != 0
  && TREE_STRING_POINTER (str) [thissize - 1] != '\0')
size = MAX (size, thissize + 1);

[Bug tree-optimization/89509] restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 45827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45827=edit
the patch

[Bug c++/89507] [9 Regression] bogus "size of array exceeds maximum object size"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P1
 Blocks||87996
   Target Milestone|--- |9.0
Summary|bogus "size of array|[9 Regression] bogus "size
   |exceeds maximum object  |of array exceeds maximum
   |size"   |object size"


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996
[Bug 87996] [8 Regression] "size of array is negative" error when SIZE_MAX/2 <
sizeof(array) <= SIZE_MAX

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
I think there is a serious flaw that the section anchor infrastructure is used
at all for the SECTION_MERGE sections, one really must not use any kind of
section anchors for those sections, there is no guarantees that the layout made
by the compiler will match what the linker will do in the end (between
different objects in the section that is, within a single object it has to
stay).

If that isn't done and we for some strange reason must still go through the
block stuff, I think we should do for something like following, where we'll
account for the artificially added trailing zeros.

--- gcc/varasm.c.jj 2019-02-22 09:30:19.133180850 +0100
+++ gcc/varasm.c2019-02-26 16:42:11.699848053 +0100
@@ -7452,7 +7452,7 @@ place_block_symbol (rtx symbol)
   struct constant_descriptor_rtx *desc;
   unsigned int alignment;
   struct object_block *block;
-  tree decl;
+  tree decl = NULL_TREE;

   gcc_assert (SYMBOL_REF_BLOCK (symbol));
   if (SYMBOL_REF_BLOCK_OFFSET (symbol) >= 0)
@@ -7511,6 +7511,20 @@ place_block_symbol (rtx symbol)

   /* Calculate the object's offset from the start of the block.  */
   block = SYMBOL_REF_BLOCK (symbol);
+  if ((block->sect->common.flags & SECTION_MERGE)
+  && (block->sect->common.flags & SECTION_STRINGS)
+  && decl
+  && DECL_INITIAL (decl)
+  && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
+{
+  tree str = DECL_INITIAL (decl);
+  unsigned HOST_WIDE_INT thissize = TREE_STRING_LENGTH (str);
+  if ((thissize == 0
+  || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
+ && size == thissize)
+   size++;
+}
+
   mask = alignment / BITS_PER_UNIT - 1;
   offset = (block->size + mask) & ~mask;
   SYMBOL_REF_BLOCK_OFFSET (symbol) = offset;
@@ -7639,6 +7653,8 @@ output_object_block (struct object_block

   /* Output the objects themselves.  */
   offset = 0;
+  bool merge_strings = ((block->sect->common.flags & SECTION_MERGE)
+   && (block->sect->common.flags & SECTION_STRINGS));
   FOR_EACH_VEC_ELT (*block->objects, i, symbol)
 {
   /* Move to the object's offset, padding with zeros if necessary.  */
@@ -7657,9 +7673,18 @@ output_object_block (struct object_block
  HOST_WIDE_INT size;
  decl = SYMBOL_REF_DECL (symbol);
  assemble_constant_contents (DECL_INITIAL (decl), XSTR (symbol, 0),
- DECL_ALIGN (decl), false);
+ DECL_ALIGN (decl), merge_strings);

  size = get_constant_size (DECL_INITIAL (decl));
+ if (merge_strings
+ && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
+   {
+ tree str = DECL_INITIAL (decl);
+ HOST_WIDE_INT thissize = TREE_STRING_LENGTH (str);
+ if (thissize == 0
+ || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
+   size = MAX (size, thissize + 1);
+   }
  offset += size;
  if ((flag_sanitize & SANITIZE_ADDRESS)
  && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST
@@ -7674,8 +7699,18 @@ output_object_block (struct object_block
{
  HOST_WIDE_INT size;
  decl = SYMBOL_REF_DECL (symbol);
- assemble_variable_contents (decl, XSTR (symbol, 0), false, false);
+ assemble_variable_contents (decl, XSTR (symbol, 0), false,
+ merge_strings);
  size = tree_to_uhwi (DECL_SIZE_UNIT (decl));
+ if (merge_strings
+ && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST)
+   {
+ tree str = DECL_INITIAL (decl);
+ HOST_WIDE_INT thissize = TREE_STRING_LENGTH (str);
+ if (thissize == 0
+ || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
+   size = MAX (size, thissize + 1);
+   }
  offset += size;
  if ((flag_sanitize & SANITIZE_ADDRESS)
  && asan_protect_global (decl))

[Bug target/89482] arm aarch32 inline assembly w constraints generate s registers instead of d

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Right. So when dealing with double-precision values you should use the %P
output modifier like so:
double my_double = 1.5;
__asm__ (
"vmov.f64 d0, 1.0;"
"vadd.f64 %P[my_double], %P[my_double], d0;"
: [my_double] "+w" (my_double)
:
: "d0"
);

This will print the right D-form of the VFP register allocated.
The documentation for this could, admittedly be improved
(https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html). I believe someone is
working on that currently.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[ian at airs dot com]

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

--- Comment #15 from Ian Lance Taylor  ---
I committed a patch that should fix the nanotime problem.

Some of the other issues you describe will most likely require a fix in the
libgo/mkrsysinfo.sh script, which generates the file runtime_sysinfo.go.  For
example, that is likely the problem with _CTL_HW and _HW_PAGESIZE.

For sysctl we'll need a declaration with a //extern comment.

I'm happy to advise but I don't realistically have the time to do the work
myself.

[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails

[ian at gcc dot gnu.org]

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

--- Comment #14 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Feb 26 14:46:56 2019
New Revision: 269214

URL: https://gcc.gnu.org/viewcvs?rev=269214=gcc=rev
Log:
PR go/86535
runtime: always declare nanotime in Go

For libgo it's always defined in C.

Updates https://gcc.gnu.org/PR86535

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

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/runtime/stubs3.go

[Bug c++/89481] constexpr function allows writing one active union member and reading another

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for GCC 9+.

[Bug c++/89481] constexpr function allows writing one active union member and reading another

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 26 14:37:39 2019
New Revision: 269213

URL: https://gcc.gnu.org/viewcvs?rev=269213=gcc=rev
Log:
PR c++/89481
* constexpr.c (cxx_eval_store_expression): When changing active union
member, set no_zero_init.

* g++.dg/cpp1y/constexpr-89481.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89481.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

合e法N经O营u

[jrxo]

办PP 

理$ +Q+V+信#%
 --
$-- I 3 4
髮$---2 4 3 4
$---6 1 4 8
漂 $ 
 -2019/2/26

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[tnfchris at gcc dot gnu.org]

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

--- Comment #19 from Tamar Christina  ---
Hmm we're running it on 

Tcl: 8.5
Expect: 5.45
Dejagnu: 1.5.1

So I think those are about the same..

[Bug c++/71446] Incorrect overload resolution when using designated initializers

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
So, shall we never try ck_list conversion for CONSTRUCTORs with any designators
(while for -std=c++2a we'll complain if there is a mix of designated
initializer clauses and non-designated initializ clauses, I think we don't
diagnose that earlier, so maybe we need to cache it in some CONSTRUCTOR flag?),
or never any conversion but ck_aggr?

[Bug tree-optimization/89509] New: restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

Bug ID: 89509
   Summary: restrict doesnt work with subfield accesses
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

struct S { int i; void *p; int j; };
int
foo (struct S * __restrict p, int *q, int flag)
{
  int *x = >j;
  if (flag)
x = >i;
  *q = 1;
  *x = 2;
  return *q;
}

Is not optimized to return 1.  This is the missed-optimization part of
PR89505.

[Bug tree-optimization/89509] restrict doesnt work with subfield accesses

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-02-26
 Blocks||49774
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I have a patch (for GCC 10).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
[Bug 49774] [meta-bug] restrict qualification aliasing issues

[Bug tree-optimization/89505] [9 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Feb 26 14:09:19 2019
New Revision: 269212

URL: https://gcc.gnu.org/viewcvs?rev=269212=gcc=rev
Log:
2019-02-26  Richard Biener  

PR tree-optimization/89505
* tree-ssa-structalias.c (compute_dependence_clique): Make sure
to handle restrict pointed-to vars with multiple subvars
correctly.

* gcc.dg/torture/pr89505.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr89505.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/89505] [8/7 Regression] LibreOffice miscompilation starting with r260383

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P1  |P2
  Known to work||9.0
   Target Milestone|9.0 |7.5
Summary|[9 Regression] LibreOffice  |[8/7 Regression]
   |miscompilation starting |LibreOffice miscompilation
   |with r260383|starting with r260383

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar, the reduced testcase also fails on branches.

[Bug c++/71446] Incorrect overload resolution when using designated initializers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 Ever confirmed|0   |1

--- Comment #8 from Jonathan Wakely  ---
I'm confirming this as a bug. If we claim to support the extension we should
make it behave sensibly, and we need to fix it for C++2a anyway.

[Bug tree-optimization/89479] __restrict on a pointer ignored when a function is passed alongside it

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 26 Feb 2019, eyalroz at technion dot ac.il wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
> 
> --- Comment #5 from Eyal Rozenberg  ---
> (In reply to Richard Biener from comment #4)
> > exposing __restrict to the IL). 
> 
> Is "IL" an acronym for "Intermediate Language"? Remember many bug
> posters/readers are not GCC developers and don't know all the lingo.

Yes.

> > To elaborate further to successfully mark a function call
> > with clique == 1 and base == 0 we have to prove the pointer marked restrict
> > doesn't escape the function through calls
> 
> Certainly, calling g() could be just the same as writing to an alias of the x
> pointer. But - __restrict is how we guarantee this doesn't happen (or can be
> ignored) even when the compiler can't prove that's the case on its own. So I'm
> not sure I understand what you're suggesting with your comment. I suppose you
> could try and "disprove the __restrict" to give a warning, but other than that
> - why not just respect it?

Well, "respecting" it means encoding it in the intermediate language
which we don't at the moment for calls.

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[dmalcolm at gcc dot gnu.org]

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

--- Comment #18 from David Malcolm  ---
(In reply to Tamar Christina from comment #17)
> Hi, 
> 
> I'm getting a test failure on master for these new tests
> 
> UNRESOLVED: gcc.dg/pr89410-1.c: bad option "-1": must be -exact, -glob,
> -regexp, or -- for " dg-warning 8 "msg" "" { target *-*-* } -1 "
> 
> is that `-1` correct there?

Sorry about this.

It's meant to be expressing a line number of "-1", but it looks like on your
system that DejaGnu/Tcl is picking that up as an option to a regexp.

Works for me (on x86_64-pc-linux-gnu) with the following:
  dejagnu-1.5.2-1.fc20.noarch
  expect-5.45-10.fc20.x86_64
  tcl-8.5.14-1.fc20.x86_64
where I get:
  PASS: gcc.dg/pr89410-1.c  (test for warnings, line -1)
  PASS: gcc.dg/pr89410-2.c  (test for warnings, line -1)
for such directives.

[Bug target/89502] Inefficient access to stack_guard in TCB

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #5)

> I think we should avoid %fs:(%edx) address.  Is that possible to generate

It is what middle-end expands to, so nothing much that we can do here.

[Bug go/89171] FAIL: go/build

[ian at airs dot com]

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

--- Comment #4 from Ian Lance Taylor  ---
To run, say, just the go/build test, cd to the libgo build directory and run
"make go/build/check".  To keep the test binary around, run "make
GOTESTFLAGS=--keep go/build/check".  That will leave the test binary (and other
stuff) in the directory gotestN/test.  In that directory you can run
"LD_LIBRARY_PATH=../../.libs ./a.out -test.short".  That executable also takes
other options, like "-test.run=TestDependencies" to run just the
TestDependencies test.

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/88530] [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||andrewm.roberts at sky dot com

--- Comment #4 from Tamar Christina  ---
*** Bug 89508 has been marked as a duplicate of this bug. ***

[Bug target/89508] gcc snapshot 9.0.1 20190127 generates invalid assembler options on aarch64-unknown-linux-gnu with -march=native

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tnfchris at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Tamar Christina  ---
Marking as a dupe of PR target/88530.

This will be fixed by https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00381.html
once it's committed.

Thanks!

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

[Bug target/89506] [7/8/9 Regression] ICE: in decompose, at rtl.h:2266 with -Og -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-26
 CC||jakub at gcc dot gnu.org
  Component|rtl-optimization|target
   Target Milestone|--- |7.5
 Ever confirmed|0   |1