[Bug go/107992] New: m68k-linux-gnu bootstap error in gofrontend

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 107992
   Summary: m68k-linux-gnu bootstap error in gofrontend
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Hi, I don't know if that is expected,
but I got a boot-strap error with r13-4502-ga0ee2e52252
.../configure --target=m68k-linux-gnu --prefix=... --enable-languages=all

libtool: compile:  /home/ed/gnu/gcc-build-m68k/./gcc/gccgo
-B/home/ed/gnu/gcc-build-m68k/./gcc/
-B/home/ed/gnu/m68k-linux-gnu/m68k-linux-gnu/bin/
-B/home/ed/gnu/m68k-linux-gnu/m68k-linux-gnu/lib/ -isystem
/home/ed/gnu/m68k-linux-gnu/m68k-linux-gnu/include -isystem
/home/ed/gnu/m68k-linux-gnu/m68k-linux-gnu/sys-include -O2 -g -mcpu=68040 -I .
-c -fgo-pkgpath=image/color/palette
../../../../gcc-trunk/libgo/go/image/color/palette/generate.go
../../../../gcc-trunk/libgo/go/image/color/palette/palette.go  -fPIC -o
image/color/.libs/palette.o
go1: internal compiler error: in set_from, at go/gofrontend/types.cc:2851
0x692aaf Ptrmask::set_from(Gogo*, Type*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2851
0x92f9a0 Ptrmask::set_from(Gogo*, Type*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2825
0x92f9a0 Ptrmask::set_from(Gogo*, Type*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2884
0x92fdcb Ptrmask::set_from(Gogo*, Type*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2825
0x92fdcb Type::gc_ptrmask_var(Gogo*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:3030
0x930b09 Type::make_gc_symbol_var(Gogo*)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2710
0x930c9a Type::gc_symbol_pointer(Gogo*)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2660
0x88290a Struct_construction_expression::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/expressions.cc:15689
0x88290a Struct_construction_expression::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/expressions.cc:15689
0x92973c Type::make_type_descriptor_var(Gogo*)
../../gcc-trunk/gcc/go/gofrontend/types.cc:1432
0x929cad Type::type_descriptor_pointer(Gogo*, Location)
../../gcc-trunk/gcc/go/gofrontend/types.cc:1308
0x8befdd Named_object::get_backend(Gogo*, std::vector >&, std::vector >&,
std::vector >&)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:8868
0x8c80f9 Gogo::write_globals()
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:1560
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[8]: *** [Makefile:3043: runtime.lo] Error 1
make[8]: *** Waiting for unfinished jobs

[Bug tree-optimization/107973] wrong warning with -Werror -fsanitize=address

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
Thanks,

I see a very similar warning with
m68k-linux-gnu-gcc but without sanitizer:

crypto/modes/cfb128.c: In function 'CRYPTO_cfb128_encrypt':
crypto/modes/cfb128.c:117:33: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
  117 | ivec[n] = c;
  | ^~~
crypto/modes/cfb128.c:27:42: note: at offset 16 into destination object 'ivec'
of size [0, 16]
   27 |unsigned char ivec[16], int *num,
  |~~^~~~
cc1: all warnings being treated as errors

[Bug c/107973] New: wrong warning with -Werror -fsanitize=address

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 107973
   Summary: wrong warning with -Werror -fsanitize=address
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

when compiling openssl-1.1.1s with the following workflow:

$ wget https://www.openssl.org/source/openssl-1.1.1s.tar.gz
$ tar xf openssl-1.1.1s.tar.gz
$ cd openssl-1.1.1s
$ ./config  --strict-warnings enable-asan
$ make

I get this unexpected warning (error)

gcc  -I. -Iinclude -fPIC -pthread -m64 -fsanitize=address
-fno-omit-frame-pointer -g -Wa,--noexecstack -Wall -O3 -DDEBUG_UNUSED
-DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wswitch -Wsign-compare -Wshadow -Wformat
-Wtype-limits -Wundef -Werror -Wmissing-prototypes -Wstrict-prototypes
-DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM
-DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
-DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -DNDEBUG  -MMD -MF
ssl/s3_enc.d.tmp -MT ssl/s3_enc.o -c -o ssl/s3_enc.o ssl/s3_enc.c
In function 'ssl3_generate_key_block',
inlined from 'ssl3_setup_key_block' at ssl/s3_enc.c:290:11:
ssl/s3_enc.c:48:20: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
   48 | buf[j] = c;
  | ~~~^~~
ssl/s3_enc.c: In function 'ssl3_setup_key_block':
ssl/s3_enc.c:21:19: note: at offset 16 into destination object 'buf' of size 16
   21 | unsigned char buf[16], smd[SHA_DIGEST_LENGTH];
  |   ^~~
cc1: all warnings being treated as errors


this happens with:
gcc version 12.2.1 20221130 (GCC)
gcc version 11.3.1 20221205 (GCC) 
gcc version 10.4.1 20221205 (GCC)

but did not happen with:
gcc version 9.5.0 (GCC)

nor does it happen with:
gcc version 13.0.0 20221130 (experimental) (GCC)

It is pretty annoying because this happens in CI builds
once we change from ubuntu-20.04 (gcc9) to ubuntu-22.04 (gcc11)

[Bug analyzer/107943] [11/12/13 Regression] gcc -fanalyzer hangs in openssl curve25519.c since r11-3840-gaf66094d03779377

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #6 from Bernd Edlinger  ---
I don't know if that is relevant or not,
but I was using a slighthly different criterion in bisection.
I used .../configure --prefix=... --enable-languages=all
and defined the bad criterion using the unreduced test case
compilation took >10 minutes on Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
The original test case is available as follows:

$ wget https://www.openssl.org/source/openssl-1.1.1s.tar.gz
$ tar xf openssl-1.1.1s.tar.gz
$ ./config -fanalyzer
$ make

With this pointed to a different commit:
r12-7615-gc5288df751f

Author: Roger Sayle 
Date:   Fri Mar 11 17:46:50 2022 +

PR tree-optimization/98335: Improvements to DSE's compute_trims.

This patch is the main middle-end piece of a fix for PR tree-opt/98335,
which is a code-quality regression affecting mainline.  The issue occurs
in DSE's (dead store elimination's) compute_trims function that determines
where a store to memory can be trimmed.  In the testcase given in the
PR, this function notices that the first byte of a DImode store is dead,
and replaces the 8-byte store at (aligned) offset zero, with a 7-byte store
at (unaligned) offset one.  Most architectures can store a power-of-two
bytes (up to a maximum) in single instruction, so writing 7 bytes requires
more instructions than writing 8 bytes.  This patch follows Jakub Jelinek's
suggestion in comment 5, that compute_trims needs improved heuristics.

beginning with this version the original test case, enters
a steady state after 2 minutes (observed with top:
VIRT=196296 RES=170872 SHR=21992  %CPU=100,0) and has no
progress for at least 20 hours, before I killed it.
The reduced test case does not exhibit this behaviour,
and runs just for some seconds.

But I agree that the r11-3840-gaf66094d03779377 is also special
and made the compile time raise from 0 to 2-10 minutes, however
I would not have opened this issue for that, since I was believing
there is something expensive to check that just did not give
a result in the end.

[Bug analyzer/107943] gcc -fanalyzer hangs in openssl curve25519.c

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #3 from Bernd Edlinger  ---
this is how far I got with bisecting:

$ git bisect log 
git bisect start
# good: [885f5c3d5763d46e02bd2f192765cb589b4c4fe4] Daily bump.
git bisect good 885f5c3d5763d46e02bd2f192765cb589b4c4fe4
# bad: [24b8b44ea3bc232f4fe8daf24900ccaca98e8280] Daily bump.
git bisect bad 24b8b44ea3bc232f4fe8daf24900ccaca98e8280
# good: [250f234988b6231669a720c52101d3686d645072] testsuite: Fix up
gcc.target/s390/zero-scratch-regs-1.c
git bisect good 250f234988b6231669a720c52101d3686d645072

[Bug analyzer/107943] gcc -fanalyzer hangs in openssl curve25519.c

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
Created attachment 53998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53998=edit
preprocessed source file

[Bug analyzer/107943] New: gcc -fanalyzer hangs in openssl curve25519.c

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 107943
   Summary: gcc -fanalyzer hangs in openssl curve25519.c
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

I see a reproducible endless loop in analyzing openssl-1.1.1s
gcc  -I. -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -fanalyzer
-DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM
-DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
-DX25519_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -DNDEBUG  -MMD -MF
crypto/ec/curve25519.d.tmp -MT crypto/ec/curve25519.o -c -o
crypto/ec/curve25519.o crypto/ec/curve25519.c

observed with: gcc-12.2.1 and gcc-13.0.0
working version: gcc-11.3.1

trying to bisect that now.

[Bug ada/104710] New: Ada-Bootstrap fails with gcc-4.8.4

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 104710
   Summary: Ada-Bootstrap fails with gcc-4.8.4
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Configured as ususal with
.../configure --prefix=/home/ed/gnu/install --enable-languages=all

make fails in stage1:
gcc -std=gnu99 -c -g  -gnatpg -gnatwns -gnata -W -Wall -I- -I. -Iada/generated
-Iada -I../../gcc-trunk/gcc/ada ../../gcc-trunk/gcc/ada/osint.adb -o
ada/osint.o
osint.adb:438:31: "strlen" not declared in "CRTL"
osint.adb:441:14: "strncpy" not declared in "CRTL"
osint.adb:675:21: "strlen" not declared in "CRTL"
osint.adb:728:16: "Open_Append" is undefined
osint.adb:1108:41: "int64" not declared in "CRTL"
osint.adb:3130:28: "strlen" not declared in "CRTL"
osint.adb:3133:11: "strncpy" not declared in "CRTL"

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.4' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4) 


git Bisect shows this started with

commit a6eae6a9bbf83ada3aab7f5a2a74e7024889d237
Author: Arnaud Charlet 
Date:   Mon Nov 29 10:15:26 2021 +

[Ada] Reduce runtime dependencies on stage1

gcc/ada/

* gcc-interface/Make-lang.in (ADA_GENERATED_FILES): Remove
s-casuti.ad?, s-crtl.ad?, s-os_lib.ad?.  Update list of object
files accordingly.


I wonder if this is intentional, since boot-strap with gcc-4.8.x works
otherwise.

[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #9 from Bernd Edlinger  ---
(In reply to Richard Biener from comment #7)
> A fix in the source would be:
> 
> void MyClass::call() {
> volatile char * volatile null = nullptr;
> *null = 1;  /* line 26 */
> }
> 
> which then compiles to
> 
> movq$0, -8(%rsp)
> movq-8(%rsp), %rax
> movb$1, (%rax)
> ret
> 
> (some "advanced" means using some asm() to hide the constant from the
> compiler might also work)

Yes, that works, but I would prefer:

*(volatile char*)1 = 2;

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #15 from Bernd Edlinger  ---
While there are certainly empty subranges that could be avoided,
there are also completely empty subroutines, which cannot be
avoided without losing the ability to inspect the procedure
variable at this location.  I have one example of that class here:

$ cat empty-inline.cc
/* This testcase is part of GDB, the GNU debugger.

   Copyright 2021 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see .  */

/* PR 25987 */
struct MyClass;
struct ptr {
MyClass* get() { return t; } /* line 21 */
MyClass* t;
};
struct MyClass { void call(); };
void MyClass::call() {
*(volatile char*)(nullptr) = 1;  /* line 26 */
}
static void intermediate(ptr p) {
p.get()->call(); /* line 29 */
}
int main() {
intermediate(ptr{new MyClass});
}
/* EOF */

$ gcc -g -Og empty-inline.cc

The empty inline I mean is ptr::get():

In the debug info this function looks like this:
 <2><11b>: Abbrev Number: 17 (DW_TAG_inlined_subroutine)
<11c>   DW_AT_abstract_origin: <0x189>
<120>   DW_AT_entry_pc: 0x40113f
<128>   DW_AT_GNU_entry_view: 2
<129>   DW_AT_low_pc  : 0x40113f
<131>   DW_AT_high_pc : 0x0
<139>   DW_AT_call_file   : 1
<13a>   DW_AT_call_line   : 29
<13b>   DW_AT_call_column : 18
<13c>   DW_AT_sibling : <0x14e>
 <3><140>: Abbrev Number: 18 (DW_TAG_formal_parameter)
<141>   DW_AT_abstract_origin: <0x197>
<145>   DW_AT_location: 0x16 (location list)
<149>   DW_AT_GNU_locviews: 0x14
[...]
 <2><197>: Abbrev Number: 22 (DW_TAG_formal_parameter)
<198>   DW_AT_name: (indirect string, offset: 0x2e): this
<19c>   DW_AT_type: <0x98>
<1a0>   DW_AT_artificial  : 1
[...]
Contents of the .debug_loclists section:
[...]
0014 v002 v004 location view pair

0016 v002 v004 views at 0014 for:
 0040113f 0040113f (DW_OP_implicit_pointer: <0x109>
0)
0020 

when stepping through the empty subroutine the "this" pointer
and in particular the value of the symbol "t" would be accessible,
like this:

(gdb) s
intermediate (p=...) at empty-inline.cc:29
29  p.get()->call(); /* line 29 */
(gdb) s
ptr::get (this=)
at empty-inline.cc:21
21  MyClass* get() { return t; } /* line 21 */
(gdb) p t
$1 = (MyClass *) 0x416c20

This loclist is of course only accessible when we accept an empty
range as something which may exist at all, thus with my latest
GDB-patch applied:
[0/4] https://sourceware.org/pipermail/gdb-patches/2021-May/179367.html
[1/4] https://sourceware.org/pipermail/gdb-patches/2021-May/179368.html
[2/4] https://sourceware.org/pipermail/gdb-patches/2021-May/179370.html
[3/4] https://sourceware.org/pipermail/gdb-patches/2021-May/179369.html
Currently gdb ignores these subroutine as a kind of nonsense.

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #14 from Bernd Edlinger  ---
(In reply to Andrew Burgess from comment #0)
>   + This bug report has a bit of history.  Originally there was a GCC
> patch here:
>https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
> and a reply here:
>https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
> 
> This led to a GDB patch here:
>https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
> which in turn led to a different GDB patch (adding is-stmt
> support), here:
>https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
> 

one correction here:
the reply to the oct 2019 patch was here:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg01771.html

The follow up GDB patch probably this one is meant:
https://sourceware.org/pipermail/gdb-patches/2019-November/162747.html

The different patch adding is-stmt probably this one is meant:
https://sourceware.org/pipermail/gdb-patches/2019-December/164224.html

[Bug rtl-optimization/103830] New: volatile optimized away

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 103830
   Summary: volatile optimized away
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

the following test case is intentionally writing at address 0,
it is IMHO invalid to optimize it away (at -Og):

$ cat empty-inline.cc
/* This testcase is part of GDB, the GNU debugger.

   Copyright 2021 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */

/* PR 25987 */
struct MyClass;
struct ptr {
MyClass* get() { return t; } /* line 21 */
MyClass* t;
};
struct MyClass { void call(); };
void MyClass::call() {
*(volatile char*)(nullptr) = 1;  /* line 26 */
}
static void intermediate(ptr p) {
p.get()->call(); /* line 29 */
}
int main() {
intermediate(ptr{new MyClass});
}
/* EOF */

previously this used to SIGSEGV in line 26, but no longer with
git master from December 18th at least.
I think it is rather common to have something at address zero,
for instance interrupt tables or device registers,
and therefore it's not OK to optimize those volatile accesses away.

[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #8 from Bernd Edlinger  ---
patch was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576027.html
review here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576520.html
and here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576538.html

conclusion: I'm not sure that we want it.

[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #7 from Bernd Edlinger  ---
Created attachment 51202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51202=edit
Proposed patch

[Bug ada/101575] [gcc-11, -gdwarf-4] Missing .file directive causes invalid line info

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #12 from Bernd Edlinger  ---
(In reply to Eric Botcazou from comment #1)
> Not going to be fixed, just stick to the default setting (DWARF 5).

one minor remark, while working on a patch, I became aware,
that probably the same will happen when using -gdwarf-5 
with old binutils, since we have this code in dwarf2out.c:

#if defined(HAVE_AS_GDWARF_5_DEBUG_FLAG) &&
defined(HAVE_AS_WORKING_DWARF_N_FLAG)
  if (output_asm_line_debug_info () && dwarf_version >= 5)
{
  /* When gas outputs DWARF5 .debug_line[_str] then we have to
 tell it the comp_dir and main file name for the zero entry
 line table.  */
  const char *comp_dir, *filename0;

  comp_dir = comp_dir_string ();
  if (comp_dir == NULL)
comp_dir = "";

  filename0 = get_AT_string (comp_unit_die (), DW_AT_name);
  if (filename0 == NULL)
filename0 = "";

  fprintf (asm_out_file, "\t.file 0 ");
  output_quoted_string (asm_out_file, remap_debug_filename (comp_dir));
  fputc (' ', asm_out_file);
  output_quoted_string (asm_out_file, remap_debug_filename (filename0));
  fputc ('\n', asm_out_file);
}
#endif

[Bug ada/101575] [gcc-11, -gdwarf-4] Missing .file directive causes invalid line info

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #11 from Bernd Edlinger  ---
(In reply to Eric Botcazou from comment #10)
> > I can of course make the .loc go away. If you really want that.
> > 
> > It is basically the DECL_SOURCE_LOCATION of an
> > otherwise ignored decl.  If the DECL_SOURCE_LOCATION
> > is UNKNOWN_LOCATION the function should have no line info,
> > and gdb should be able not to step into this function.
> 
> But that's not the original design, which is that a DECL_IGNORED_P function
> does not have .loc directives, like any other debugging information.

Yes, indeed.

DECL_IGNORED_P functions do also not have a block-structure and
many other sophisticated features like variable locations.
That does not change.

The intended change is just that if a DECL_SOURCE_LOCATION
is available it is shown in the debugger, and if there is no
DECL_SOURCE_LOCATION, really no line number shall be shown.

The motivation for this patch is the following:
Unfortunately some non-DECL_IGNORED_P functions decay
to DECL_IGNORED_P as shown in PR97937. While the test case
there is written in "C", it is certainly also an issue for Ada.

All that is left over from the original debug info is the
DECL_SOURCE_LOCATION.  Therefore the desire to at least show
this source location, because previously a completely wrong
line info from the preceding function was shown.

And on the other hand, we have DECL_IGNORED_P functions that
do not have any DECL_SOURCE_LOCATION right from the beginning.

Therefore the patch does a lot to prevent line number info
from the previous functions to extend to the following function
where it will be misleading.

But it will need some adjustments to also address DECL_IGNORED_P
functions directly at the beginning of the CU, when dwarf-4 is
used as in this PR.

[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Tom de Vries from comment #4)
> (In reply to Bernd Edlinger from comment #2)
> > Yes, but it wont fix dwarf-4 and also not the case
> > when this is not the first function. then we'll
> > have the .loc from the previous function extend to this one.
> 
> I just tried out:
> - dwarf-4
> - manually changing order of defs__f1 and defs__struct1IP in .s file
> 
> The result look fine to me.  So please show a concrete example where this
> produces wrong results.


I did the same.
The effect I meant is the following which is basically PR97937
The line number from the previous function defs__f1 extends to
defs__structIP.

So when I debug this I see the following:
Reading symbols from ./formatted_ref...
(gdb) b defs__struct1IP 
Breakpoint 1 at 0x402faa: file defs.adb, line 21.
(gdb) r
Starting program:
/home/ed/gnu/binutils-gdb/gdb/testsuite/gdb.ada/formatted_ref/formatted_ref 

Breakpoint 1, 0x00402faa in defs__struct1IP () at defs.adb:21
21 end F1;


This here the line number is totally misleading.
So to me it appears, that PR101575 is just the evil
twin brother of PR97937.

And indeed the fix for PR97937 - excluding the really
not debuggable funtions from the debug ranges -
is not sufficient to get rid of the bogus line table
entries from PR101575.

So I start to think that emitting a dummy .file table entry
as you suggest is the way to go, but I would like not to
break the fix for PR97937 at the same time.

[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #5 from Bernd Edlinger  ---
I will have a look.

[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
Yes, but it wont fix dwarf-4 and also not the case
when this is not the first function. then we'll
have the .loc from the previous function extend to this one.

[Bug ada/101575] [gcc-11, -gdwarf-4] Missing .file directive causes invalid line info

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #8 from Bernd Edlinger  ---
I can of course make the .loc go away. If you really want that.

It is basically the DECL_SOURCE_LOCATION of an
otherwise ignored decl.  If the DECL_SOURCE_LOCATION
is UNKNOWN_LOCATION the function should have no line info,
and gdb should be able not to step into this function.

However the location does not look really wrong to me.
In create_subprog_decl it is taken over from input_location.
I could imagine that this is sometimes a misleading location.
But then in gnat_pushdecl we have
Sloc_to_locus (Sloc (gnat_node), _SOURCE_LOCATION (decl));
and it is again the same location.

In the test case the location points here:

+ column location
v
   type Struct1 is limited record  <- line location
  X : Integer := 13;
  Y : Integer := 19;
   end record;

[Bug ada/101575] [gcc-11, -gdwarf-4] Missing .file directive causes invalid line info

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #4 from Bernd Edlinger  ---
Hi,

I think my commit e69ac020372 ("Add line debug info for virtual thunks")
has a mitigating effect on this test case:
due to such functions have DECL_IGNORED_P
they are excluded from the debug_range info,
and therfore gdb should ignore the bogus line tables.

However, I applied this only in the trunk, not the gcc-11 branch.

[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #6 from Bernd Edlinger  ---
Jonathan,

what was the problem why you wanted to add the dg-shouldfail ?

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #21 from Bernd Edlinger  ---
Hi Srinath,

when we add new assertions to gcc we use always a gcc_checking_assert
nowadays, that is also the case here.

The assertion is only firing in your compiler because it is a development
snapshot 10.3.1.  So that is an experimemtal version.

That means the release version 10.3.0 will not have an ICE with this test case,
except the long-standing potential wrong code due to unaligned memory access,
however most contemporary ARM chips do no longer trap on an unaligned
load/store.

But on the other hand, this change might affects all targets whether
or not they have any issue at all.

So it might trigger a completely unrelated bug in a completely different area
of the compiler.

That said I do not object this back-port, I just wanted to say that it
fixes a non-issue in a released compiler version.

And even a small risk of a regression seems to be not worth it.


Regards
Bernd.

[Bug target/100106] [10/11 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #3 from Bernd Edlinger  ---
Yes, indeed something like the following seems to fix the issue:

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index d13c390..56271e9 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -7217,6 +7217,7 @@ simplify_context::simplify_subreg (machine_mode outermode
  have instruction to move the whole thing.  */
   && (! MEM_VOLATILE_P (op)
  || ! have_insn_for (SET, innermode))
+  && (STRICT_ALIGNMENT && GET_MODE_ALIGNMENT (outermode) < MEM_ALIGN (op))
   && known_le (outersize, innersize))
 return adjust_address_nv (op, outermode, byte);

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 since r11-6325

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #13 from Bernd Edlinger  ---
Hi Nathan,

I've been playing with a variant of c-c++-common/raw-string-6.c
with your patch:

$ cat raw-string-6.c
$ cat raw-string-6.c 
// { dg-do compile }
// { dg-options "-std=gnu99" { target c } }
// { dg-options "-std=c++0x" { target c++ } }

#include ".h"
$ cat .h 
const void *s0 = R"ouch()ouCh";
$ gcc -x c raw-string-6.c
In file included from raw-string-6.c:5:
.h:1:18: error: unterminated raw string
1 | const void *s0 = R"ouch()ouCh";
  |  ^
raw-string-6.c:6: error: expected expression at end of input
$ gcc -x c++ raw-string-6.c 
In file included from raw-string-6.c:5:
.h:1:18: error: unterminated raw string
1 | const void *s0 = R"ouch()ouCh";
  |  ^
.h:1:16: error: expected primary-expression at end of input
1 | const void *s0 = R"ouch()ouCh";
  |^

Do you agree that the C++ FE places the error about the end of input
on a somewhat surprising place?


Bernd.

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 since r11-6325

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #9 from Bernd Edlinger  ---
The last token is a CPP_PRAGMA_EOL, and has a line number 2,
while the include file has only one line, so it is similar to an EOL position.
I guess therefore this fails to add a column?

1002  location_t r = 
1003linemap_position_for_line_and_column (set, map, line, column);
1004  if (linemap_assert_fails (r <= set->highest_location)
1005  || linemap_assert_fails (map == linemap_lookup (set, r)))
1006return loc;


(gdb) p tok[0]
$30 = {type = CPP_EOF, keyword = RID_MAX, flags = 64 '@', implicit_extern_c =
false, error_reported = false, 
  purged_p = false, tree_check_p = false, main_source_p = true, location =
255712, u = {tree_check_value = 0x0, 
value = 0x0}}
(gdb) p tok[-1]
$31 = {type = CPP_PRAGMA_EOL, keyword = RID_MAX, flags = 0 '\000',
implicit_extern_c = false, error_reported = false, 
  purged_p = false, tree_check_p = false, main_source_p = false, location =
251552, u = {tree_check_value = 0x0, 
value = 0x0}}

location_t r = 
1003linemap_position_for_line_and_column (set, map, line, column);
(gdb) p r
$68 = 252480
(gdb) p *map
$70 = { = {start_location = 251584}, reason = LC_LEAVE, sysp = 0
'\000', m_column_and_range_bits = 12, 
  m_range_bits = 5, to_file = 0x2ac9800 "pr99446-1.h", to_line = 2,
included_from = 238400}
(gdb) p *result
$74 = { = {start_location = 251616}, reason = LC_LEAVE, sysp = 0
'\000', m_column_and_range_bits = 12, 
  m_range_bits = 5, to_file = 0x2b0a2d0 "pr99446.c", to_line = 2, included_from
= 0}

but line 2 does not exist in both files.

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 since r11-6325

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #7 from Bernd Edlinger  ---
Hmm,

I don't fully understand what's the reason why
the assertion fires here.

... but what's apparently wrong here, is the location
before the EOF is in a different file.

While it was intended to show the line above the end-of-file,
it was likely not intended to show the last token in
a different include file?

So something like that fixes the test case:

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 59adac4..99026f4 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -668,7 +668,8 @@ cp_lexer_new_main (void)
   + lexer->buffer->length ()
  - 1;

-  if (lexer->buffer->length () != 1)
+  if (lexer->buffer->length () != 1
+  && LOCATION_FILE (tok[-1].location) == LOCATION_FILE(tok[0].location))
 {
   /* Set the EOF token's location to be the just after the previous
  token's range.  That way 'at-eof' diagnostics point at something

[Bug middle-end/98525] New: potential error in expand_call_inline error handling

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 98525
   Summary: potential error in expand_call_inline error handling
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

The error handling in the following if-statement is possibly broken

tree-inline.c:
   /* If callee is thunk, all we need is to adjust the THIS pointer
  and redirect to function being thunked.  */
   if (id->src_node->thunk)
   {
  ...
  expand_call_inline (bb, stmt, id, to_purge);
  maybe_remove_unused_call_args (cfun, stmt);
  return true;
   }

The return value of the recursive expand_call_inline
is ignored, and instead we always return true here.

BUT the inline function is not always successfully
expanded here.

At least in the following test cases, the expansion of the
inline call fails, but it is unclear if the IL is already modified
in preparation of a successful inlining:

+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++98 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++98 compilation failed to produce
executable
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++14 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++14 compilation failed to produce
executable
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++17 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++17 compilation failed to produce
executable
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/devirt-5.C  -std=gnu++2a (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-5.C  -std=gnu++2a compilation failed to produce
executable
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++98 compilation failed to
produce executable
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++14 compilation failed to
produce executable
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++17 compilation failed to
produce executable
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a (test for excess errors)
+UNRESOLVED: g++.dg/ipa/devirt-c-4.C  -std=gnu++2a compilation failed to
produce executable
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++98 compilation failed to
produce executable
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++14 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++14 compilation failed to
produce executable
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++17 (test for excess errors)
+UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++17 compilation failed to
produce executable
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/imm-devirt-2.C  -std=gnu++2a (test for excess errors)
+UNRESOLVED: g++.dg/ipa/imm-devirt-2.C  -std=gnu++2a compilation failed to
produce executable
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++98 (test for excess errors)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/pr71146.C  -std=gnu++2a (test for excess errors)
+FAIL: g++.dg/ipa/pr79776.C  -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/ipa/pr79776.C  -std=gnu++98 (test for excess errors)
+FAIL: g++.dg/ipa/pr79776.C  -std=gnu++14 (internal compiler error)
+FAIL: g++.dg/ipa/pr79776.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/ipa/pr79776.C  -std=gnu++17 (internal compiler error)
+FAIL: g++.dg/ipa/pr79776.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/ipa/pr79776.C  -std=gnu++2a (internal compiler error)
+FAIL: g++.dg/ipa/pr79776.C

[Bug tree-optimization/98467] gcc optimizes tapping code away

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
I debugged a bit in when we decide this function is const.
That appears to be in gcc/ipa-fnsummary.c:

/* Return true if T is a pointer pointing to memory location that is local
   for the function (that means, dead after return) or read-only.  */

bool
points_to_local_or_readonly_memory_p (tree t)
{
  /* See if memory location is clearly invalid.  */
  if (integer_zerop (t))
return flag_delete_null_pointer_checks;
  if (TREE_CODE (t) == SSA_NAME)
return !ptr_deref_may_alias_global_p (t);
  if (TREE_CODE (t) == ADDR_EXPR)
return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
  return false;
}



And indeed the "problem" can be fixed by using -fno-delete-null-pointer-checks.
>From the documentation in gcc/doc/invoke.texi I would never have guessed
what this option does here:

"@item -fdelete-null-pointer-checks
@opindex fdelete-null-pointer-checks
Assume that programs cannot safely dereference null pointers, and that
no code or data element resides at address zero.
This option enables simple constant
folding optimizations at all optimization levels.  In addition, other
optimization passes in GCC use this flag to control global dataflow
analyses that eliminate useless checks for null pointers; these assume
that a memory access to address zero always results in a trap, so
that if a pointer is checked after it has already been dereferenced,
it cannot be null."


It is only supposed to remove checks for null-pointer, not the other
way round...

[Bug tree-optimization/98467] New: gcc optimizes tapping code away

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 98467
   Summary: gcc optimizes tapping code away
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Consider this test case:

$ cat test.cc
struct MyClass;
struct ptr {
MyClass* get() { return t; }
MyClass* t;
};
struct MyClass { void call(); };
void MyClass::call() {
*(char*)(nullptr) = 1;
}
static void intermediate(ptr p) {
p.get()->call();
}
int main() {
intermediate(ptr{new MyClass});
}

$ g++ -g -O0 test.cc
$ ./a.out
Segmentation fault (core dumped)
$ g++ -g -Og test.cc
$ ./a.out
$ g++ -g -O1 test.cc
$ ./a.out
$ g++ -g -O2 test.cc
$ ./a.out
Segmentation fault (core dumped)
$ g++ -g -O3 test.cc
$ ./a.out
Segmentation fault (core dumped)
$ g++ -g -Ofast test.cc
$ ./a.out
Segmentation fault (core dumped)

It is somehow unexpected that this code is optimized
away only at -Og -O1, but not at very high or very low optimization levels.

I would even say although the code is of course invalid, it should
not be optimized away, as it might be a debug-code that intentionally taps.

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #16 from Bernd Edlinger  ---
(In reply to SRINATH PARVATHANENI from comment #15)
> (In reply to Bernd Edlinger from comment #14)
> > fixed on trunk.
> 
> Thanks Bernd for fixing this on trunk, would you mind backporting this to
> GCC-10 as well?
> 
> Thanks you.
> 
> Regards,
> Srinath.

Since it is a gcc_checking_assert that triggers the ICE,
I assumed that does not affect a release build,
is that correct?

[Bug ipa/97937] New: Line numbers are missing from duplicated function

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 97937
   Summary: Line numbers are missing from duplicated function
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Consider this test case:

$ cat test.c
int test(void)
{
  return 0;
}

int test1(void)
{
  return 0;
}

struct s {
  int (*x) (void);
  int (*y) (void);
};

struct s xxx = { test, test1 };

$ gcc -g -O2 -S test.c

test.s:
.file   "test.c"
.text
.Ltext0:
.p2align 4
.globl  test
.type   test, @function
test:
.LFB0:
.file 1 "test.c"
.loc 1 2 1 view -0
.cfi_startproc
.loc 1 3 3 view .LVU1
.loc 1 4 1 is_stmt 0 view .LVU2
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size   test, .-test
.p2align 4
.globl  test1
.type   test1, @function
test1:
.LFB3:
.cfi_startproc
xorl%eax, %eax
ret
.cfi_endproc


The problem is that there are no line numbers in test1.

That is caused by this statement in symtab-thunks.cc

428   if (force_gimple_thunk)
429 DECL_IGNORED_P (thunk_fndecl) = 1;

#0  expand_thunk (node=0x7fffeee7edd0, output_asm_thunks=false,
force_gimple_thunk=true)
at ../../gcc-trunk/gcc/symtab-thunks.cc:429
#1  0x00fca17b in cgraph_node::create_wrapper (this=0x7fffeee7edd0,
target=0x7fffeee7ebb0)
at ../../gcc-trunk/gcc/cgraphunit.c:2601
#2  0x0281d7bd in ipa_icf::sem_function::merge (this=0x46dfc90,
alias_item=0x46c2880)
at ../../gcc-trunk/gcc/ipa-icf.c:1299
#3  0x02825672 in ipa_icf::sem_item_optimizer::merge_classes
(this=0x4746390, prev_class_count=902, 
loaded_symbols=74) at ../../gcc-trunk/gcc/ipa-icf.c:3406
#4  0x028220c8 in ipa_icf::sem_item_optimizer::execute (this=0x4746390)
at ../../gcc-trunk/gcc/ipa-icf.c:2459

together with this in final.c:

2433case NOTE_INSN_BEGIN_STMT:
2434  gcc_checking_assert (cfun->debug_nonbind_markers);
2435  if (!DECL_IGNORED_P (current_function_decl)
2436  && notice_source_line (insn, NULL))
(gdb) 
2437{
2438output_source_line:
2439  (*debug_hooks->source_line) (last_linenum,
last_columnnum,
2440   last_filename,
last_discriminator,
2441   true);
2442  clear_next_view_needed (seen);
2443}
2444  break;

which prevents the line number from being included in the asm.

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #12 from Bernd Edlinger  ---
(In reply to Bernd Edlinger from comment #11)
> (In reply to rguent...@suse.de from comment #10)
> > 
> > I failed to track down where we'd expand this to a possibly
> > unaligned mem - but is this just bogus MEM_ALIGN set?  Can we instead
> > fix that somehow?
> > 
> 
> No, this fixes the assertion in the back-end, while the first hunk
> makes the memory at least mode aligned, the MEM_ALIGN needs to
> be adjusted here, GET_MODE_ALIGNMENT (GET_MODE (x)) is a lower
> bound of the true alignment.
> 
> Also in the case of the PARM_DECLs it is possible that we take
> advantage from a MEM_ALIGN which happens to be larger than
> what's implied by TYPE_ALIGN.
> 

In case, I misunderstood the question.
set_rtl does this, but it is also called from a lot
of other places, for instance set_parm_rtl where
I did not want to change the alignment.

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #11 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #10)
> On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> 
> > --- Comment #9 from Bernd Edlinger  ---
> > (In reply to rguent...@suse.de from comment #7)
> > 
> > Ah, yes, using a similar strategy as we did in r274986
> > where we aligned param_decls, I would say this
> > completely untested patch goes in the same direction:
> > 
> > diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> > index f3f17d3..030d0cb 100644
> > --- a/gcc/cfgexpand.c
> > +++ b/gcc/cfgexpand.c
> > @@ -366,7 +366,18 @@ align_local_variable (tree decl, bool really_expand)
> >unsigned int align;
> > 
> >if (TREE_CODE (decl) == SSA_NAME)
> > -align = TYPE_ALIGN (TREE_TYPE (decl));
> > +{
> > +  tree type = TREE_TYPE (decl);
> > +  machine_mode mode = TYPE_MODE (type);
> > +
> > +  align = TYPE_ALIGN (type);
> > +  if (mode != BLKmode
> > + && align < GET_MODE_ALIGNMENT (mode)
> > + && ((optab_handler (movmisalign_optab, mode)
> > +  != CODE_FOR_nothing)
> > + || targetm.slow_unaligned_access (mode, align)))
> 
> I wouldn't even restrict it this way - after all if we have an
> SSA_NAME its address hasn't been exposed and thus any different
> user requested alignment isn't exposed.  Instead we can work
> to produce optimal code which means aligning according to the mode
> (that's what the RA would do when spilling the 'register').
> 

Agreed.

> Note that this would argue we could fix the types for SSA names
> upfront but there might be some complication when we have to
> adjust the underlying decl and that's a PARM_DECL.
> 

I would like to avoid changing the types to be more aligned,
just make the MEM_ALIGN larger than what the TYPE_ALIGN
requires.  Also in the case of the incoming param_decls,
the decl_rtl may reflect the true alignment of the stack,
which may be higher than required by the type.
The backend looks at the MEM_ALIGN and can in some cases
generate better code, based on the MEM_ALIGN and, it
can assert when we have a misaligned MEM_P, also based
on the value in MEM_ALIGN.

> > +   align = GET_MODE_ALIGNMENT (mode);
> > +}
> >else
> >  {
> >align = LOCAL_DECL_ALIGNMENT (decl);
> > @@ -1022,6 +1033,17 @@ expand_one_stack_var_at (tree decl, rtx base, 
> > unsigned
> > base_align,
> >  }
> > 
> >set_rtl (decl, x);
> > +
> > +  if (TREE_CODE (decl) == SSA_NAME
> > +  && GET_MODE (x) != BLKmode
> > +  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x))
> > +  && ((optab_handler (movmisalign_optab, GET_MODE (x))
> > +  != CODE_FOR_nothing)
> > + || targetm.slow_unaligned_access (GET_MODE (x), MEM_ALIGN (x
> 
> I failed to track down where we'd expand this to a possibly
> unaligned mem - but is this just bogus MEM_ALIGN set?  Can we instead
> fix that somehow?
> 

No, this fixes the assertion in the back-end, while the first hunk
makes the memory at least mode aligned, the MEM_ALIGN needs to
be adjusted here, GET_MODE_ALIGNMENT (GET_MODE (x)) is a lower
bound of the true alignment.

Also in the case of the PARM_DECLs it is possible that we take
advantage from a MEM_ALIGN which happens to be larger than
what's implied by TYPE_ALIGN.

> > +{
> > +  gcc_checking_assert (GET_MODE_ALIGNMENT (GET_MODE (x)) <= 
> > base_align);
> > +  set_mem_align (x, GET_MODE_ALIGNMENT (GET_MODE (x)));
> > +}
> >  }
> > 
> >  class stack_vars_data
> > @@ -1327,13 +1349,11 @@ expand_one_stack_var_1 (tree var)
> >  {
> >tree type = TREE_TYPE (var);
> >size = tree_to_poly_uint64 (TYPE_SIZE_UNIT (type));
> > -  byte_align = TYPE_ALIGN_UNIT (type);
> >  }
> >else
> > -{
> > -  size = tree_to_poly_uint64 (DECL_SIZE_UNIT (var));
> > -  byte_align = align_local_variable (var, true);
> > -}
> > +size = tree_to_poly_uint64 (DECL_SIZE_UNIT (var));
> > +
> > +  byte_align = align_local_variable (var, true);
> > 
> >/* We handle highly aligned variables in expand_stack_vars.  */
> >gcc_assert (byte_align * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT);
> > 
> > 
> > > Also, when an SSA name gets a stack location, we should instead use
> > > the underlying decl for the MEM_EXPR, not the SSA name.
> > > 
> > 
> > At least the MEM_EXPRs from this t

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #9 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #7)
> On Wed, 28 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
> > 
> > --- Comment #6 from Bernd Edlinger  ---
> > (In reply to rguent...@suse.de from comment #3)
> > > On Tue, 27 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> > > > --- a/gcc/emit-rtl.c
> > > > +++ b/gcc/emit-rtl.c
> > > > @@ -2089,7 +2089,8 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, 
> > > > int
> > > > objectp,
> > > > {
> > > >   gcc_assert (handled_component_p (t)
> > > >   || TREE_CODE (t) == MEM_REF
> > > > - || TREE_CODE (t) == TARGET_MEM_REF);
> > > > + || TREE_CODE (t) == TARGET_MEM_REF
> > > > + || TREE_CODE (t) == SSA_NAME);
> > > 
> > > Can you track down this?  It's a red herring to have a MEM_EXPR
> > > that just is a SSA_NAME.
> > > 
> > 
> > This happens here:
> > 
> >   if (MEM_P (to_rtx))
> > {
> >   /* If the field is at offset zero, we could have been given 
> > the
> >  DECL_RTX of the parent struct.  Don't munge it.  */
> >   to_rtx = shallow_copy_rtx (to_rtx);
> >   set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
> >   if (volatilep)
> > MEM_VOLATILE_P (to_rtx) = 1;
> > }
> > 
> > since the patch allows the SSA_NAME to reach this block.
> > 
> > 
> > > > --- a/gcc/expr.c
> > > > +++ b/gcc/expr.c
> > > > @@ -5200,6 +5200,9 @@ expand_assignment (tree to, tree from, bool 
> > > > nontemporal)
> > > >|| (TREE_CODE (to) == MEM_REF
> > > >   && (REF_REVERSE_STORAGE_ORDER (to)
> > > >   || mem_ref_refers_to_non_mem_p (to)))
> > > > +  || (TREE_CODE (to) == SSA_NAME
> > > > + && mode != BLKmode
> > > > + && TYPE_ALIGN (TREE_TYPE (to)) < GET_MODE_ALIGNMENT (mode))
> > > 
> > > But an SSA name is a register, esp. one with non-BLKmode.  And if
> > > expanded to a stack location that stack location should better
> > > be aligned...  or be BLKmode.  So I think the bug is elsewhere?
> > > 
> > 
> > Hmm, to avoid the ICE the SSA_NAME would need a naturally
> > aligned type, maybe replace it somehow in make_ssa_name_fn ...
> 
> Ah, OK - only now looked at the testcase ;)  Yes, I think for
> registers we should ignore decl/type alignment and _always_
> use the natural (mode) alignment.  That is,
> 
> static unsigned int
> align_local_variable (tree decl, bool really_expand)
> {
>   unsigned int align;
> 
>   if (TREE_CODE (decl) == SSA_NAME)
> align = TYPE_ALIGN (TREE_TYPE (decl));
> 
> should probably use GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (decl)))
> unless it is a BLKmode var.  There's a duplicate code in
> expand_one_stack_var_1, not sure why it special-cases SSA_NAMEs there.
> 

Ah, yes, using a similar strategy as we did in r274986
where we aligned param_decls, I would say this
completely untested patch goes in the same direction:

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index f3f17d3..030d0cb 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -366,7 +366,18 @@ align_local_variable (tree decl, bool really_expand)
   unsigned int align;

   if (TREE_CODE (decl) == SSA_NAME)
-align = TYPE_ALIGN (TREE_TYPE (decl));
+{
+  tree type = TREE_TYPE (decl);
+  machine_mode mode = TYPE_MODE (type);
+
+  align = TYPE_ALIGN (type);
+  if (mode != BLKmode
+ && align < GET_MODE_ALIGNMENT (mode)
+ && ((optab_handler (movmisalign_optab, mode)
+  != CODE_FOR_nothing)
+ || targetm.slow_unaligned_access (mode, align)))
+   align = GET_MODE_ALIGNMENT (mode);
+}
   else
 {
   align = LOCAL_DECL_ALIGNMENT (decl);
@@ -1022,6 +1033,17 @@ expand_one_stack_var_at (tree decl, rtx base, unsigned
base_align,
 }

   set_rtl (decl, x);
+
+  if (TREE_CODE (decl) == SSA_NAME
+  && GET_MODE (x) != BLKmode
+  && MEM_ALIGN (x) < GET_MODE_ALIGNMENT (GET_MODE (x))
+  && ((optab_handler (movmisalign_optab, GET_MODE (x))
+  != CODE_FOR_nothing)
+ || targetm.slow_unaligned_access (GET_MODE (x), MEM_ALIGN (x
+{
+  gcc_checking_assert (GET_MODE_ALIG

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #3)
> On Tue, 27 Oct 2020, bernd.edlinger at hotmail dot de wrote:
> > --- a/gcc/emit-rtl.c
> > +++ b/gcc/emit-rtl.c
> > @@ -2089,7 +2089,8 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, int
> > objectp,
> > {
> >   gcc_assert (handled_component_p (t)
> >   || TREE_CODE (t) == MEM_REF
> > - || TREE_CODE (t) == TARGET_MEM_REF);
> > + || TREE_CODE (t) == TARGET_MEM_REF
> > + || TREE_CODE (t) == SSA_NAME);
> 
> Can you track down this?  It's a red herring to have a MEM_EXPR
> that just is a SSA_NAME.
> 

This happens here:

  if (MEM_P (to_rtx))
{
  /* If the field is at offset zero, we could have been given the
 DECL_RTX of the parent struct.  Don't munge it.  */
  to_rtx = shallow_copy_rtx (to_rtx);
  set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos);
  if (volatilep)
MEM_VOLATILE_P (to_rtx) = 1;
}

since the patch allows the SSA_NAME to reach this block.


> > --- a/gcc/expr.c
> > +++ b/gcc/expr.c
> > @@ -5200,6 +5200,9 @@ expand_assignment (tree to, tree from, bool 
> > nontemporal)
> >|| (TREE_CODE (to) == MEM_REF
> >   && (REF_REVERSE_STORAGE_ORDER (to)
> >   || mem_ref_refers_to_non_mem_p (to)))
> > +  || (TREE_CODE (to) == SSA_NAME
> > + && mode != BLKmode
> > + && TYPE_ALIGN (TREE_TYPE (to)) < GET_MODE_ALIGNMENT (mode))
> 
> But an SSA name is a register, esp. one with non-BLKmode.  And if
> expanded to a stack location that stack location should better
> be aligned...  or be BLKmode.  So I think the bug is elsewhere?
> 

Hmm, to avoid the ICE the SSA_NAME would need a naturally
aligned type, maybe replace it somehow in make_ssa_name_fn ...

But isn't it possible that expand_expr_real_1
returns the original unaligned decl here?

case GIMPLE_SINGLE_RHS:
  {
r = expand_expr_real (gimple_assign_rhs1 (g), target,
  tmode, modifier, alt_rtl,
  inner_reference_p);
break;
  }
default:
  gcc_unreachable ();
}
  set_curr_insn_location (saved_loc);
  if (REG_P (r) && !REG_EXPR (r))
set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r);
  return r;

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #5 from Bernd Edlinger  ---
(In reply to SRINATH PARVATHANENI from comment #4)
> With the above patch I'm getting ICE as below while building arm-none-eabi
> target:
> 
> checking for scalbnl... during RTL pass: expand
> 
> generice_bug/src/gcc/libstdc++-v3/src/c++98/locale_init.cc: In constructor
> 'std::locale::_Impl::_Impl(std::size_t)':
> 
> generice_bug/src/gcc/libstdc++-v3/src/c++98/locale_init.cc:471:3: internal
> compiler error: tree check: expected bit_field_ref or mem_ref, have ssa_name
> in expand_assignment, at expr.c:5203
>   471 |   locale::_Impl::
>   |   ^~

Hmm, it looks like I cannot reproduce this,
which version did you use for that ?
what is in line 5203 of expr.c ?

[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
Thanks for reporting this.

The expansion of assignments to misaligned ssa names
does not handle the case of misaligned stores, which
would result in incorrect code without the assertion.

I have an untested patch below:

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 3706f0a..12b81cd 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2089,7 +2089,8 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, int
objectp,
{
  gcc_assert (handled_component_p (t)
  || TREE_CODE (t) == MEM_REF
- || TREE_CODE (t) == TARGET_MEM_REF);
+ || TREE_CODE (t) == TARGET_MEM_REF
+ || TREE_CODE (t) == SSA_NAME);
  attrs.expr = t;
  attrs.offset_known_p = true;
  attrs.offset = 0;
diff --git a/gcc/expr.c b/gcc/expr.c
index 9d951e8..49f2699 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -5200,6 +5200,9 @@ expand_assignment (tree to, tree from, bool nontemporal)
   || (TREE_CODE (to) == MEM_REF
  && (REF_REVERSE_STORAGE_ORDER (to)
  || mem_ref_refers_to_non_mem_p (to)))
+  || (TREE_CODE (to) == SSA_NAME
+ && mode != BLKmode
+ && TYPE_ALIGN (TREE_TYPE (to)) < GET_MODE_ALIGNMENT (mode))
   || TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE)
 {
   machine_mode mode1;
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr97205.c
b/gcc/testsuite/gcc.c-torture/compile/pr97205.c
new file mode 100644
index 000..6600011
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr97205.c
@@ -0,0 +1,7 @@
+int a;
+typedef __attribute__((aligned(2))) int x;
+int f ()
+{
+  x b = a;
+  return b;
+}

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger  ---
Hi Andrew,

You are right about the instruction re-ordering, that is done in
a compiler pass, which simply re-orders RTL instruction lists.
But I think when the code motion happens, we just
have no easy access to the range markers.
And it may be the case that this is-stmt location
mentions a register value that is indeed the parameter
of the inline function, so it may be no instruction but only
a side note, to the debugger, that a certain value would
be already here available in a certain register.
Also that is only a vague guess, since although I did already
a number of gcc patches, I learn new things each time :-)


Bernd.

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
Andrew,

(In reply to Andrew Burgess from comment #10)
> Further, I've seen no mention of exit views anywhere, and I think they
> would also be needed.
> 

Yes, that is also my idea, when I say the dwarf2 spec needs to
be fixed.

> With the addition of these two features we would be able to support (I
> believe) fully merged callers and callees, with lines marked as
> is-stmt from both the caller and callee appearing at the same address.
> 
> For now, without this, I think GCC needs to restrict itself when
> inlining.  When an address represents a line from both the caller and
> callee, then that address should only be is-stmt true for EITHER lines
> from the caller, or lines from the callee.  If the address is is-stmt
> true for a line from the caller, then the address should NOT be within
> the callee's range(s), and if the address is is-stmt true for a line
> from the callee, then the address MUST be within the callee's
> range(s).
> 

I tried to do something similar, in my original gcc-patch,
which was unfortunately not accepted.

But what I learned from writing the patch is that gcc cannot
easily tell if a range will be empty or not.  That is because
the assembler does emit the line info and the views,
and the assembler decides how many bytes if any a certain
construct will take in the binary representation.

That is why this empty range appears, because that was
supposed to be the start of the inline function, but
instructions from the function prologue were moved in there.
What causes the problem is the is-stmt line info which
is the only remaining thing from the original plan.
But on the other hand, it is not a big issue for gdb to
ignore those artefacts, when they rarely occur.
My gdb-patch does this, by changing the is-stmt bit of
this line info.

> On a final note.  These are just my personal thoughts from the
> perspective of a debug consumer, though I use words like "must" or
> "should" above this reflects my thoughts on how I believe the debug
> should appear, and is not an attempt to prescribe how GCC should
> be.  I know there are limitations to what GCC can achieve, and also, I
> could be totally wrong in my understanding of DWARF.  I'm always happy
> to be corrected!

Yeah, that is true for myself as well.

Ping, Alexandre Oliva, are you still with us?
I would be curious to know what you think, about this how
should we proceed?


Thanks
Bernd.

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger  ---
Andrew,

please update the reproducer, and explain in more detail
what you would like to be changed.

I still do not understand your idea.
But I try hard to do so.


Please be patient with me.

Bernd.

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
> I don't understand why each range wouldn't need its own view number?

Each of the sub ranges end PC can be an exit point.
At least how I see it.

Please have a look at my patch.

It adds each of the ranges end address to the
end address list, and there are two cases,
one where only one range is there, and
one where multiple ranges are there.

then the end PC addresses are used to modify the
is-stmt bits of the corresponding line entries if there are any.

Those cannot be used for break points per line number, possibly.
But I dont care.

Thanks
Bernd.

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
Right,

#+BEGIN_EXAMPLE
  0030 00400545 00400545 (start == end)
  0030 00400549 00400553
  0030 00400430 00400435
  0030 
#+END_EXAMPLE

I dont see any view numbers here, but I would need them.

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
Can you please approve my patch now?

https://sourceware.org/pipermail/gdb-patches/2020-April/167385.html

Thanks
Bernd.

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
(In reply to Andrew Burgess from comment #2)
> Sorry for including the wrong DWARF dump output in the bug report.  I too
> had seen the DW_AT_GNU_entry_view using a more recent binutils.
> 

NP.

> When you pose the question:
> 
>   I am not sure if there are any view numbers when the inline has multiple
> ranges, (I dont remember)
> 
> I think you're asking do we get DW_AT_GNU_entry_view when we have multiple
> ranges.  And the answer is yes, this case already has multiple ranges (it
> has a DW_AT_ranges, which contains multiple ranges), and this is super
> confusing, because each range could, I guess, could have a different view
> number for its start, right?
> 

I am talking about the end of the range each of the subranges
They should have view numbers, gdb should note the view number
when parsing the line program.

I think we need an DW_AT_GNU_exit_view, you know, young jedi :-)


Bernd.

[Bug debug/94474] Incorrect DWARF range information for inlined function

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
Hi,

I use a newer binutils versions FWIW, and buit GCC-10 from
a few days ago using those binutils.

$ readelf -version
GNU readelf (GNU Binutils) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

instead of
#+BEGIN_EXAMPLE
   <2><8db>: Abbrev Number: 38 (DW_TAG_inlined_subroutine)
  <8dc>   DW_AT_abstract_origin: <0x9cc>
  <8e0>   DW_AT_entry_pc: 0x400545
  <8e8>   Unknown AT value: 2138: 3
  <8e9>   DW_AT_ranges  : 0x30
  <8ed>   DW_AT_call_file   : 1
  <8ee>   DW_AT_call_line   : 52
  <8ef>   DW_AT_call_column : 10
  <8f0>   DW_AT_sibling : <0x92f>
#+END_EXAMPLE

 I see:

 <2><8b3>: Abbrev Number: 38 (DW_TAG_inlined_subroutine)
<8b4>   DW_AT_abstract_origin: <0x9a4>
<8b8>   DW_AT_entry_pc: 0x401165
<8c0>   DW_AT_GNU_entry_view: 0
<8c1>   DW_AT_ranges  : 0x30
<8c5>   DW_AT_call_file   : 1
<8c6>   DW_AT_call_line   : 52
<8c7>   DW_AT_call_column : 10
<8c8>   DW_AT_sibling : <0x907>

But as you can see there is a view number where
the range begins, but there is no view number where
the range ends.

I am not sure if there are any view numbers when
the inline has multiple ranges, (I dont remember)

Therefore I try to chamge gdb to ignore is-stmt breakpoints
which are at the end of the inline block.

I am not sure if an entirely new DWARF version is necessary,
or just a new  AT value: like 2139 or so, to give us
an idea if the is-stmt is per its view in the subroutine
or in the calling program.


Bernd.

[Bug target/91614] [10 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #3 from Bernd Edlinger  ---
My attempt at fixing this failure
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html
I am not sure if it war rejected or just not reviewe

[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d

[bernd.edlinger at hotmail dot de]

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

--- Comment #19 from Bernd Edlinger  ---
Okay, forget my previous comment,
I overlooked that you say the .c.gcov is missing...

[Bug gcov-profile/94029] [9 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d

[bernd.edlinger at hotmail dot de]

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

--- Comment #16 from Bernd Edlinger  ---
Sandra,

I am pretty sure it should exist,
can you check which git revision you are looking at?

[Bug gcov-profile/94029] [9/10 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
openssl workaround is here:
https://github.com/openssl/openssl/pull/11246

[Bug gcov-profile/94029] [9/10 Regression] gcc crash in coverage.c:655 since r9-4216-g390e529e2b98983d

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
Martin, in the gcc-8 branch
is the gcov working, or has it the
same issue as bug#88045 ?

[Bug gcov-profile/94029] New: gcc crash in coverage.c:655

[bernd.edlinger at hotmail dot de]

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

Bug ID: 94029
   Summary: gcc crash in coverage.c:655
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This causes a crash in gcc:

$ cat test.c
#define impl_test(name) void test_##name() { }
impl_test(t1
) impl_test(t2)
$ gcc -ftest-coverage -c test.c
during IPA pass: profile
test.c: In function ‘test_t2’:
test.c:2:1: internal compiler error: in coverage_begin_function, at
coverage.c:655
2 | impl_test(t1
  | ^
0x66ce7f coverage_begin_function(unsigned int, unsigned int)
../../gcc-trunk/gcc/coverage.c:655
0xd2cc66 branch_prob(bool)
../../gcc-trunk/gcc/profile.c:1307
0xea6687 tree_profiling
../../gcc-trunk/gcc/tree-profile.c:779
0xea6687 execute
../../gcc-trunk/gcc/tree-profile.c:885
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


(this was reduced from openssl-1.1.1d where this also happens,
when configured with -ftest-coverage)

[Bug bootstrap/93548] gcc build tries to modify source tree

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Bernd Edlinger  ---
thanks, seems to work now.

[Bug bootstrap/93548] gcc build tries to modify source tree

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
Ah, thanks I will do that.
Apparently the git conversion is to blame :)

[Bug bootstrap/93548] gcc build tries to modify source tree

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
git Revision c3ccce5b47f85d70127f5bb894bc5e83f8d2510e

If absolutely necessary that should only be done in maintainer mode.

[Bug bootstrap/93548] New: gcc build tries to modify source tree

[bernd.edlinger at hotmail dot de]

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

Bug ID: 93548
   Summary: gcc build tries to modify source tree
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

I build gcc with read only source tree,
this worked all the time, but now it does no longer:


 ../gcc-trunk-0/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=all --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with-float=hard

make Fails, because it attempts to modify the source code;

HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/sh ../../gcc-trunk-0/gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="\"arm10e\"" \
HEADERS="options.h insn-constants.h config/vxworks-dummy.h config/dbxelf.h
config/elfos.h config/gnu-user.h config/linux.h config/linux-android.h
config/glibc-stdint.h config/arm/elf.h config/arm/linux-gas.h
config/arm/linux-elf.h config/arm/bpabi.h config/arm/linux-eabi.h
config/arm/aout.h config/arm/arm.h config/initfini-array.h defaults.h"
DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 LIBC_MUSL=4
DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0" \
/bin/sh ../../gcc-trunk-0/gcc/mkconfig.sh tm.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/arm/arm-flags.h config/arm/arm-protos.h
config/arm/aarch-common-protos.h config/linux-protos.h tm-preds.h" DEFINES="" \
/bin/sh ../../gcc-trunk-0/gcc/mkconfig.sh tm_p.h
gawk -f ../../gcc-trunk-0/gcc/config/arm/parsecpu.awk -v cmd=md \
../../gcc-trunk-0/gcc/config/arm/arm-cpus.in > arm-tune.new
mv arm-tune.new ../../gcc-trunk-0/gcc/config/arm/arm-tune.md
mv: can't rename 'arm-tune.new': Permission denied
make[3]: *** [../../gcc-trunk-0/gcc/config/arm/arm-tune.md] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf'
make: *** [all] Error 2

[Bug c++/92024] crash in check_local_shadow

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
Yes, I guess so.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[bernd.edlinger at hotmail dot de]

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

--- Comment #34 from Bernd Edlinger  ---
(In reply to fdlbxtqi from comment #33)
> Created attachment 47574 [details]
> copy_backward bug fixed for the last patch
> 
> going to further run testsuite

Your test does not contain any test cases.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[bernd.edlinger at hotmail dot de]

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

--- Comment #31 from Bernd Edlinger  ---
Yes, you usually need to make a full bootstrap / make check twice
which the same svn revision one with and one without your patch.
You also should make sure that the test case actually is able to fail
before your patch.
You run "$(srcdir)/contrib/test_summary -t" each time and
compare the output.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #26 from Bernd Edlinger  ---
(In reply to fdlbxtqi from comment #2)
> Also find a bug of __memmove
> 
>   /*
>* A constexpr wrapper for __builtin_memmove.
>* @param __num The number of elements of type _Tp (not bytes).
>*/
>   template
> _GLIBCXX14_CONSTEXPR
> inline void*
> __memmove(_Tp* __dst, const _Tp* __src, size_t __num)
> {
> #ifdef __cpp_lib_is_constant_evaluated
>   if (std::is_constant_evaluated())
>   {
> for(; __num > 0; --__num)
>   {
> if constexpr (_IsMove)
>   *__dst = std::move(*__src);
> else
>   *__dst = *__src;
> ++__src;
> ++__dst;
>   }
> return __dst;
>   }
>   else
> #endif
>   return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
>   return __dst;
> }
> 
> The last 2nd line return __dst is wrong. It should not exist.

Sorry, I don't know what this function is all about.
But to me the code in the ifdef looks totally bogus.
First it returns __dst+__num, while memmove is sopposed
to return __dst, and is is somehow clear that
__dst and __src do not overlap?

because if they do the loop would overwite the __dst buffer before
__src is fully copied?

[Bug target/91615] [10 regression][armeb] ICEs since r274986

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #11 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #9)
> Is this fixed now?

everything except the regression in arm/unaligned-memcpy-2/3.c
the patch was considered too ugly:

the last version was here (probably still too ugly):
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00370.html

but I did not consider this important enough to send any pings.

[Bug c++/92024] crash in check_local_shadow

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
(In reply to Arseny Solokha from comment #4)
> Is there a backport pending? I cannot reproduce this ICE on release branches.

Hmm, interesting, I would have expected this to ICE.

However this patch is not complete yet as it seems,
since it exposed another hidden bug: #92365

With proposed patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00639.html

[Bug c++/92365] [10 Regression] ice unexpected expression ‘int16_t()’ of kind cast_expr

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
Created attachment 47180
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47180=edit
possible fix

This seems to fix the issue,
although a fix in cxx_eval_constant_expression
might be preferrable.

[Bug c++/92024] crash in check_local_shadow

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
there is alos a valid test case where an ICE happens:

template
struct S {
  S () {
struct c;
  {
struct c {};
  }
  }
};

S s;

[Bug c++/92024] crash in check_local_shadow

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
This seems to fix the ICE:

Index: pt.c
===
--- pt.c(revision 276634)
+++ pt.c(working copy)
@@ -10973,6 +10973,9 @@
   || uses_template_parms (type))
 return type;

+  if (CLASSTYPE_TEMPLATE_INFO (type) == NULL)
+return error_mark_node;
+
   /* Figure out which template is being instantiated.  */
   templ = most_general_template (CLASSTYPE_TI_TEMPLATE (type));
   gcc_assert (TREE_CODE (templ) == TEMPLATE_DECL);

[Bug c++/92024] New: crash in check_local_shadow

[bernd.edlinger at hotmail dot de]

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

Bug ID: 92024
   Summary: crash in check_local_shadow
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

g++ crashes on testsuite/g++.dg/parse/crash68.C
when invoked with -Wshadow=compatible-local

$ g++ -Wshadow=compatible-local crash68.C 
crash68.C: In constructor 'a<  >::a()':
crash68.C:8:23: error: types may not be defined in exception-declarations
8 | } catch (struct c {}) {  // { dg-error "types may not be
defined|conflicting" }
  |   ^
crash68.C: In instantiation of 'a<  >::a() [with
 = int]':
crash68.C:18:6:   required from here
crash68.C:8:24: error: conflicting declaration 'struct a<
 >::a() [with  = int]::c'
8 | } catch (struct c {}) {  // { dg-error "types may not be
defined|conflicting" }
  |^
crash68.C:6:12: note: previous declaration as 'struct a<
 >::a() [with  = int]::c'
6 | struct c;
  |^
crash68.C:8:21: internal compiler error: Segmentation fault
8 | } catch (struct c {}) {  // { dg-error "types may not be
defined|conflicting" }
  | ^
0xeec04f crash_signal
../../gcc-10-20191006/gcc/toplev.c:326
0x9c3062 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-10-20191006/gcc/tree.h:3266
0x9c3062 instantiate_class_template_1
../../gcc-10-20191006/gcc/cp/pt.c:10977
0x9c4db2 instantiate_class_template(tree_node*)
../../gcc-10-20191006/gcc/cp/pt.c:11525
0xa06559 complete_type(tree_node*)
../../gcc-10-20191006/gcc/cp/typeck.c:139
0x9d2798 lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../../gcc-10-20191006/gcc/cp/search.c:194
0x84a93d is_properly_derived_from(tree_node*, tree_node*)
../../gcc-10-20191006/gcc/cp/call.c:10026
0x84a93d is_properly_derived_from(tree_node*, tree_node*)
../../gcc-10-20191006/gcc/cp/call.c:10018
0x84af82 standard_conversion
../../gcc-10-20191006/gcc/cp/call.c:1496
0x84da39 implicit_conversion
../../gcc-10-20191006/gcc/cp/call.c:1972
0x85ff58 can_convert_arg(tree_node*, tree_node*, tree_node*, int, int)
../../gcc-10-20191006/gcc/cp/call.c:11164
0x93108e check_local_shadow
../../gcc-10-20191006/gcc/cp/name-lookup.c:2762
0x93108e do_pushdecl
../../gcc-10-20191006/gcc/cp/name-lookup.c:3096
0x931813 pushdecl(tree_node*, bool)
../../gcc-10-20191006/gcc/cp/name-lookup.c:3161
0x931813 do_pushdecl_with_scope
../../gcc-10-20191006/gcc/cp/name-lookup.c:3843
0x931f61 do_pushtag
../../gcc-10-20191006/gcc/cp/name-lookup.c:6840
0x931f61 pushtag(tree_node*, tree_node*, tag_scope)
../../gcc-10-20191006/gcc/cp/name-lookup.c:6910
0x9b2991 lookup_template_class_1
../../gcc-10-20191006/gcc/cp/pt.c:9561
0x9b3c53 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-10-20191006/gcc/cp/pt.c:9775
0x9b3c53 tsubst_aggr_type
../../gcc-10-20191006/gcc/cp/pt.c:12777
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


It is in this expression
  else if (warn_shadow_compatible_local
   && (same_type_p (TREE_TYPE (old), TREE_TYPE (decl))
   || (!dependent_type_p (TREE_TYPE (decl))
   && !dependent_type_p (TREE_TYPE (old))
   /* If the new decl uses auto, we don't yet know
  its type (the old type cannot be using auto
  at this point, without also being
  dependent).  This is an indication we're
  (now) doing the shadow checking too
  early.  */
   && !type_uses_auto (TREE_TYPE (decl))
   && can_convert (TREE_TYPE (old), TREE_TYPE (decl),
   tf_none

What is wrong with this can_convert?

[Bug fortran/91716] [9/10 Regression] ICE in output_constant, at varasm.c:5026

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
Hmm, I tried it out and built gcc-9.2.0 out of the release tar ball,
with no checking flag
and, actually the test case still ICEs, just in a different
place:

$ gfortran -c z1.f90
z1.f90:5:0:

5 | end
  |
internal compiler error: in output_constructor_regular_field, at varasm.c:5207
0x5e6e68 output_constructor_regular_field
../../gcc-9.2.0/gcc/varasm.c:5207
0x5e6e68 output_constructor
../../gcc-9.2.0/gcc/varasm.c:5513
0xdac6aa output_constant
../../gcc-9.2.0/gcc/varasm.c:4885
0xdac6aa output_constructor_regular_field
../../gcc-9.2.0/gcc/varasm.c:5246
0xdac6aa output_constructor
../../gcc-9.2.0/gcc/varasm.c:5513
0xdad03c output_constant
../../gcc-9.2.0/gcc/varasm.c:4885
0xdad03c assemble_variable_contents
../../gcc-9.2.0/gcc/varasm.c:2144
0xdb3b97 assemble_variable(tree_node*, int, int, int)
../../gcc-9.2.0/gcc/varasm.c:2323
0xdb59e9 varpool_node::assemble_decl()
../../gcc-9.2.0/gcc/varpool.c:584
0xdb59e9 varpool_node::assemble_decl()
../../gcc-9.2.0/gcc/varpool.c:552
0x7cc17c output_in_order
../../gcc-9.2.0/gcc/cgraphunit.c:2446
0x7cc17c symbol_table::compile()
../../gcc-9.2.0/gcc/cgraphunit.c:2686
0x7ce14c symbol_table::compile()
../../gcc-9.2.0/gcc/cgraphunit.c:2599
0x7ce14c symbol_table::finalize_compilation_unit()
../../gcc-9.2.0/gcc/cgraphunit.c:2865
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


And the patch applies cleanly and fixes the issue.

So I guess I will look at running a reg-test cycle
and send the patch to the fortran mailing list when that is
done.

[Bug fortran/91716] [9/10 Regression] ICE in output_constant, at varasm.c:5026

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #5 from Bernd Edlinger  ---
It is only a checking assert, so it goes away
automatically when the branch is released.
Therefore I thought a back-port would not be necessary.

[Bug c++/91868] New: wrong location info with -Wshadow on C++ constructors

[bernd.edlinger at hotmail dot de]

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

Bug ID: 91868
   Summary: wrong location info with -Wshadow on C++ constructors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

While playing with -Wshadow I saw a wrong location info creating a confusing
warning (but I think other warnings have similar issues):

$ cat test.cc
enum x {a};

struct c
{
  c (x, x);
};

void
foo ()
{
  int xx;
  {
c xx
( a, a);
  }
}
$ $ gcc -Wshadow -c test.cc 
test.cc: In function 'void foo()':
test.cc:14:7: warning: declaration of 'xx' shadows a previous local [-Wshadow]
   14 | ( a, a);
  |   ^
test.cc:11:7: note: shadowed declaration is here
   11 |   int xx;
  |   ^~

[Bug c++/91803] statement-expressions are not allowed in template arguments

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
(In reply to Marek Polacek from comment #1)
> I do not think that is a bug in the compiler; after all, the error message
> says that is not valid.

Yes, usually that would not make sense, but __typeof() alone
can handle those statement-expressions just fine, but not when
in an argument list, that is strange.
So maybe a feature request, not a bug report.

[Bug c++/91803] New: statement-expressions are not allowed in template arguments

[bernd.edlinger at hotmail dot de]

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

Bug ID: 91803
   Summary: statement-expressions are not allowed in template
arguments
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

I wanted to use something like __typeof(ORIGINAL_REGNO(rtl)) in a template
argument, but it does not work, I wonder if that is a bug.

$ cat test.cc 
template 
X identity(X x)
{ return x; }

#define IDENTITY(X) __extension__ \
({ __typeof(X) const x = (X); x; })

int
main()
{
  /* error: statement-expressions are not allowed
 outside functions nor in template-argument lists  */
  if (identity<__typeof(IDENTITY(0))>(1) != 1);
__builtin_abort();

  /* but this works! */
  if (identity<__typeof(identity<__typeof(0)>(0))>(1) != 1)
__builtin_abort();
}

$ g++ test.cc
test.cc: In function 'int main()':
test.cc:6:1: error: statement-expressions are not allowed outside functions nor
in template-argument lists
6 | ({ __typeof(X) const x = (X); x; })
  | ^
test.cc:13:25: note: in expansion of macro 'IDENTITY'
   13 |   if (identity<__typeof(IDENTITY(0))>(1) != 1);
  | ^~~~
test.cc:13:40: error: no matching function for call to 'identity< >(int)'
   13 |   if (identity<__typeof(IDENTITY(0))>(1) != 1);
  |^
test.cc:2:3: note: candidate: 'template X identity(X)'
2 | X identity(X x)
  |   ^~~~
test.cc:2:3: note:   template argument deduction/substitution failed:
test.cc:13:40: error: template argument 1 is invalid
   13 |   if (identity<__typeof(IDENTITY(0))>(1) != 1);
  |^

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger  ---
Created attachment 46863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46863=edit
untested patch

That was easy :-)
I have been there before...

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger  ---
$ grep -A4 -r "insn 234 .*:SI 340" real.c.*|less

real.c.237r.subreg1:(insn 234 233 235 11 (set (reg:SI 340)
real.c.237r.subreg1-(mem:SI (reg/v/f:SI 273 [ rD.73757 ]) [52 MEM
 [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32]))
"../../gcc-trunk-1/gcc/real.c":5185:9 643 {*thumb2_movsi_vfp}
real.c.237r.subreg1- (nil))
real.c.237r.subreg1-(insn 235 234 236 11 (set (reg:SI 339)
real.c.237r.subreg1-(and:SI (reg:SI 340)
--
real.c.238r.dfinit:(insn 234 233 235 11 (set (reg:SI 340)
real.c.238r.dfinit-(mem:SI (reg/v/f:SI 273 [ rD.73757 ]) [52 MEM
 [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32]))
"../../gcc-trunk-1/gcc/real.c":5185:9 643 {*thumb2_movsi_vfp}
real.c.238r.dfinit- (nil))
real.c.238r.dfinit-(insn 235 234 236 11 (set (reg:SI 339)
real.c.238r.dfinit-(and:SI (reg:SI 340)
--
real.c.239r.cse1:(insn 234 233 235 11 (set (reg:SI 340)
real.c.239r.cse1-(mem:SI (reg/v/f:SI 273 [ rD.73757 ]) [52 MEM
 [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32]))
"../../gcc-trunk-1/gcc/real.c":5185:9 643 {*thumb2_movsi_vfp}
real.c.239r.cse1- (nil))
real.c.239r.cse1-(insn 235 234 236 11 (set (reg:SI 339)
real.c.239r.cse1-(and:SI (reg:SI 340)
--
real.c.239r.cse1:(insn 234 233 235 11 (set (reg:SI 340 [ MEM 
[(struct real_valueD.28367 *)r_77(D)] ])
real.c.239r.cse1-(mem:SI (plus:SI (reg/v/f:SI 273 [ rD.73757 ])
real.c.239r.cse1-(const_int 20 [0x14])) [0 MEM 
[(voidD.73 *)r_77(D)]+20 S4 A8])) "../../gcc-trunk-1/gcc/real.c":5185:9 643
{*thumb2_movsi_vfp}
real.c.239r.cse1- (nil))
real.c.239r.cse1-(insn 235 234 236 11 (set (reg:SI 339)
--

so initially the mem-ref was:
[52 MEM  [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32]

but it is replaced by:
[0 MEM  [(voidD.73 *)r_77(D)]+20 S4 A8]

this is bad, because the Alignment is worse, and the alias-set
is changed from 52 to 0, alias everything.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger  ---
I see this instruction is responsible (in function real_nextafter
first in real.c.239r.cse1:

(insn 234 198 205 11 (set (reg:SI 340 [ MEM  [(struct
real_valueD.28367 *)r_77(D)] ])
(mem:SI (plus:SI (reg/v/f:SI 273 [ rD.73757 ])
(const_int 20 [0x14])) [0 MEM  [(voidD.73
*)r_77(D)]+20 S4 A8])) "../../gcc-trunk-1/gcc/real.c":5185:9 643
{*thumb2_movsi_vfp}

it should to be a unaligned_loadsi of course.

[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
probably fixed by r275489
It was not intended to run this test on cortex-a9,
but I used the wrong effective-target.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
without looking in detail, this could
be another middle-end error or the back-end
generating an invalid instruction where no assertions
are, then lra can rewrite the insn in a way that
triggers the assertion later.

I have no resources to work on reducing this
due to the upcoming OpenSSL release tomorrow, were
I need to work on a fix for a CVE I found.

Could you pleas help reducing this one?

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Wilco from comment #5)
> (In reply to Christophe Lyon from comment #4)
> > (In reply to Bernd Edlinger from comment #3)
> > > I will try to reproduce with building of a cross for this target.
> > 
> > FWIW, cross-build looked fine for me at r275501:
> > --target arm-none-linux-gnueabihf
> > --with-mode arm / thumb
> > --with-cpu cortex-a57
> > --with-fpu crypto-neon-fp-armv8
> 
> It passes with --with-fpu=neon-fp-armv8, so it seems not having Neon enabled
> is necessary too.

Yeah, using Wico's config flags I was able to reproduce this now:

during RTL pass: reload
../../gcc-trunk-1/gcc/real.c: In function 'bool real_nextafter(real_value*,
format_helper, const real_value*, const real_value*)':
../../gcc-trunk-1/gcc/real.c:5240:1: internal compiler error: in gen_movsi, at
config/arm/arm.md:5435
 5240 | }
  | ^
0x882ecb gen_movsi(rtx_def*, rtx_def*)
../../gcc-trunk-1/gcc/config/arm/arm.md:5435
0xc82977 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
../../gcc-trunk-1/gcc/recog.h:318
0xc82977 emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc-trunk-1/gcc/expr.c:3694
0xc82d04 emit_move_insn(rtx_def*, rtx_def*)
../../gcc-trunk-1/gcc/expr.c:3790
0xe2eb4a lra_emit_move(rtx_def*, rtx_def*)
../../gcc-trunk-1/gcc/lra.c:498
0xe44be2 curr_insn_transform
../../gcc-trunk-1/gcc/lra-constraints.c:4402
0xe463fe lra_constraints(bool)
../../gcc-trunk-1/gcc/lra-constraints.c:4999
0xe2f0d4 lra(_IO_FILE*)
../../gcc-trunk-1/gcc/lra.c:2452
0xde7191 do_reload
../../gcc-trunk-1/gcc/ira.c:5522
0xde7191 execute
../../gcc-trunk-1/gcc/ira.c:5706
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [real.o] Error 1
make[2]: Leaving directory
`/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross-1/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross-1'
make: *** [all] Error 2

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
I will try to reproduce with building of a cross for this target.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
Oh, nice, could you say what config options you use?

[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
Created attachment 46846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46846=edit
untested patch

[Bug middle-end/91603] Unaligned access in expand_assignment

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
Okay, Thanks!

Looks like these neon instructions don't work at all in big-endian.

[Bug target/91612] [10 regression][arm] gcc.target/arm/aapcs/align4.c ICE after r274986

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #1 from Bernd Edlinger  ---
this is related to pr91603 which is a reduced test case
from align4.c where wrong code happened before r27485

[Bug middle-end/91603] New: Unaligned access in expand_assignment

[bernd.edlinger at hotmail dot de]

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

Bug ID: 91603
   Summary: Unaligned access in expand_assignment
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Currently this ICEs due to the middle-end sanitization:

$ cat test.c
typedef __simd64_int32_t int32x2_t;
typedef __attribute__((aligned (1))) int32x2_t unalignedvec;

unalignedvec a = {11, 13};

void foo(unalignedvec *);

void test()
{
  unalignedvec x = a;
  foo ();
  a = x;
}
$ arm-linux-gnueabihf-gcc -O3 -S test.c
during RTL pass: expand
test.c: In function 'test':
test.c:10:16: internal compiler error: in gen_movv2si, at
config/arm/vec-common.md:30
   10 |   unalignedvec x = a;
  |^
0x7bb33c gen_movv2si(rtx_def*, rtx_def*)
../../gcc-trunk/gcc/config/arm/vec-common.md:30
0xa4a807 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
../../gcc-trunk/gcc/recog.h:318
0xa4a807 emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc-trunk/gcc/expr.c:3694
0xa4ab94 emit_move_insn(rtx_def*, rtx_def*)
../../gcc-trunk/gcc/expr.c:3790
0xa522bf store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc-trunk/gcc/expr.c:5855
0xa52bfd expand_assignment(tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/expr.c:5441
0xa52bfd expand_assignment(tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/expr.c:4982
0x934adf expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:3777
0x934adf expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:3875
0x93a451 expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:5915
0x93c1b6 execute
../../gcc-trunk/gcc/cfgexpand.c:6538
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

But it is actually a genuine wrong code bug:
with the assertions removed, it generates this code:

test:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, r6, r7, lr}
movwr4, #:lower16:.LANCHOR0
movtr4, #:upper16:.LANCHOR0
sub sp, sp, #8
mov r0, sp
vldrd16, [r4]   <= unaligned access (will trap)
vstrd16, [sp]
bl  foo
ldrdr6, [sp]
uxtbip, r6
ubfxr2, r6, #16, #8
lsr lr, r6, #24
uxtbr0, r7
lsr r1, r7, #24
strbip, [r4]
ubfxr3, r7, #16, #8
strbr2, [r4, #2]
ubfxip, r6, #8, #8
ubfxr2, r7, #8, #8
strblr, [r4, #3]
strbip, [r4, #1]
strbr0, [r4, #4]
strbr2, [r4, #5]
strbr3, [r4, #6]
strbr1, [r4, #7]
add sp, sp, #8
@ sp needed
pop {r4, r6, r7, pc}

[Bug middle-end/89544] Argument marshalling incorrectly assumes stack slots are naturally aligned.

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
However while writing the patch "Sanitizing the middle-end interface
to the back-end for strict alignment":
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01130.html

I discovered another wrong code bug, this time affecting all arch:

$ cat unaligned-argument-3.c 
/* { dg-do compile } */
/* { dg-require-effective-target arm_arm_ok } */
/* { dg-require-effective-target arm_ldrd_strd_ok } */
/* { dg-options "-marm -mno-unaligned-access -O3" } */

typedef int __attribute__((aligned(1))) s;

void x(char*, s*);
void f(char a, s f)
{
  x(, );
}

/* { dg-final { scan-assembler-times "str\t\[^\\n\]*\\\[sp\\\]" 1 } } */
/* { dg-final { scan-assembler-times "str\t\[^\\n\]*\\\[sp, #3\\\]" 0 } } */

currently with -marm -mno-unaligned-access -O3 we generate:

f:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
str lr, [sp, #-4]!
sub sp, sp, #12
mov r3, r0
str r1, [sp, #3]
add r0, sp, #7
add r1, sp, #3
strbr3, [sp, #7]
bl  x
add sp, sp, #12
@ sp needed
ldr pc, [sp], #4

[Bug middle-end/89544] Argument marshalling incorrectly assumes stack slots are naturally aligned.

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
This is half fixed now:
Since r274531 the original test case no longer generates wrong code,
but only slightly non-optimal code.
I had so far two test cases:

$ cat unaligned-argument-1.c 
/* { dg-do compile } */
/* { dg-require-effective-target arm_arm_ok } */
/* { dg-require-effective-target arm_ldrd_strd_ok } */
/* { dg-options "-marm -mno-unaligned-access -O3" } */

struct s {
  int a, b;
} __attribute__((aligned(8)));

struct s f0;

void f(int a, int b, int c, int d, struct s f)
{
  f0 = f;
}

/* { dg-final { scan-assembler-times "ldrd" 1 } } */
/* { dg-final { scan-assembler-times "strd" 1 } } */
/* { dg-final { scan-assembler-times "stm" 0 } } */

$ cat unaligned-argument-2.c 
/* { dg-do compile } */
/* { dg-require-effective-target arm_arm_ok } */
/* { dg-require-effective-target arm_ldrd_strd_ok } */
/* { dg-options "-marm -mno-unaligned-access -O3" } */

struct s {
  int a, b;
} __attribute__((aligned(8)));

struct s f0;

void f(int a, int b, int c, int d, int e, struct s f)
{
  f0 = f;
}

/* { dg-final { scan-assembler-times "ldrd" 0 } } */
/* { dg-final { scan-assembler-times "strd" 0 } } */
/* { dg-final { scan-assembler-times "stm" 1 } } */

the remaining issue is that the fist one should generate ldrd/strd
instead of stm.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #19 from Bernd Edlinger  ---
Hope all is now working again.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #14 from Bernd Edlinger  ---
I can reproduce with trunk:
arm-linux-gnueabihf-gcc -S -O2 -mthumb -flto -fno-use-linker-plugin
20040709-1.c

but not with -O3 -g, neither with gcc-9 and my fix applied.

Nevertheless it is quite obvious that the second patch is needed to handle
the case when rematerialized instructions have scratches, but nothing needs
to be spilled so the loop need to continue with lra_assign instead of
lra_spill.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger  ---
Created attachment 46704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46704=edit
another untested patch

[Bug c/69558] [7/8 Regression] glib2 warning pragmas stopped working

[bernd.edlinger at hotmail dot de]

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

--- Comment #29 from Bernd Edlinger  ---
Hm, the target milestone is wrong. I believe this was fixed in gcc-9

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
No, it needs to be back-ported to gcc-9.3 (i am still reg-testing)
and Vladimir Makarov wrote the following:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00463.html

> Still I think more work on the PR is needed.  If subsequent LRA sub-pass
> spills some pseudo to assign a hard register to the scratch of the
> rematerialized insn as it was in the original insn, it might make this
> rematerialization unprofitable.  So I'll think how to avoid the
> unprofitable rematerialization in such cases and would like to work on
> this  PR more.
> 
> Please, do not close the PR after committing the patch.  I am going to
> work on it more when stage3 starts.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #8 from Bernd Edlinger  ---
Patch is posted here: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00305.html

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
I can reproduce this defect with gcc-9 (!)

$ ../gcc-9-branch/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64-1
--target=arm-linux-gnueabihf --enable-languages=c,c++ --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard

$ TMP=. arm-linux-gnueabihf-gcc -O2 -flto -save-temps -fdump-rtl-all-all
20040709-1.c

$ grep same *.reload
 Assigning the same 6155 to r11
$ vi *.ltrans0.s
look for the last umull (it is always the last one):

str r5, [fp]
umull   fp, r3, r7, r8
[...]
str r6, [fp]

But the same does not happen for gcc-8:

$ grep same *.reload

the assembler listing looks okay.
But the update_scratch_ops looks exactly identical,
Therefore the issue is likely just a hidden one there.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
with this patch the relevant part if the reload dump file looks different:

(insn 3414 6591 6682 129 (set (mem/c:SI (reg/f:SI 5 r5 [5715]) [1
s.5566D.5531+0 S4 A32])
(reg:SI 6 r6 [orig:828 _821 ] [828])) "20040709-1.c":13:5 654
{*arm_movsi_vfp}
 (nil))
[...]
(insn 6826 3453 6816 129 (parallel [
(set (reg:SI 3 r3 [4187])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg:SI 11
fp [4186]))
(zero_extend:DI (reg:SI 7 r7 [4188])))
(const_int 32 [0x20]
(clobber (reg:SI 1 r1 [5970]))
]) "20040709-1.c":108:291 70 {*umulsi3_highpart_v6}
 (nil))
[...]
(insn 3509 3530 3531 132 (set (mem/c:SI (reg/f:SI 5 r5 [5715]) [1
s.5566D.5531+0 S4 A32])
(reg:SI 14 lr [orig:692 D.6083 ] [692])) "20040709-1.c":13:5 654
{*arm_movsi_vfp}
 (nil))


This time insn 6826 is able to choose a different register than r5,
and most importantly the live-range info is correct, since the
old register r5970 is renamed to r6374 temporarily:

  Creating newreg=6374 from oldreg=5970, assigning class GENERAL_REGS to
scratch pseudo copy r6374
 6816: r6364:SI=r4187:SI
  REG_DEAD r4187:SI
Inserting rematerialization insn before:
 6826: {r6364:SI=trunc(zero_extend(r4186:SI)*zero_extend(r4188:SI)
0>>0x20);clobber r6374:SI;}
  REG_UNUSED r6374:SI

which is visible in the live ranges (which was not there before):

 r6007: [59..59]
 r6374: [1572..1572]
Compressing live ranges: from 3802 to 75 - 1%
Ranges after the compression:
[...]
 r6007: [1..1]
 r6374: [40..40]

However since the re-materialized instruction is able to use r1
there is no conflict any more.  So I believe the patch is a
straight improvement over the previous state of affairs.


So, as it looks like, this is a potentially catastrophic bug, and not
related to -flto at all or any specific target architecture.
From my testing it is likely that was already there in gcc-9.0.1.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
Created attachment 46654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46654=edit
untested patch

It looks like update_scratch_ops creates a copy of the original scratch
register, but the new scratch register has no working live range info.
I don't know a correct solution for the underlying problem, but
removing the assignment to reg_renumber seems to fix the test case.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #4 from Bernd Edlinger  ---
hmm, funny, I saw this test case failing since february at least:

https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg02686.html

FAIL: gcc.c-torture/execute/20040709-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16
--with-float=hard


I have not looked into it before, but
to me it looks like a reload bug:

str r6, [r5] <= r5 still valid
stm r9, {r0, r1, r2, r3}
umull   r5, r3, r7, fp <= r5 clobbered
ldr r2, [r4, #176]
lsr r9, r3, #3
mov r3, r0
eor r3, r3, r2
rsb r9, r9, r9, lsl #4
tst r3, r10
sub r9, fp, r9
bne .L29
ldrhr2, [sp, #176]
ldrhr3, [r4, #176]
eor r2, r2, r3
ubfxr2, r2, #0, #12
cmp r2, #0
bne .L29
cmp r9, r9
bne .L29
mla r6, r8, r6, lr
ldr fp, .L79+36
mla lr, r8, r6, lr
ubfxr6, r6, #16, #11
bfi r3, r6, #0, #12
strhr3, [r4, #176]  @ movhi
uxthr8, r3
ldm fp, {r0, r1, r2, r3}
ubfxip, lr, #16, #11
add r7, r6, ip
add ip, sp, #176
bfi r8, r7, #0, #12
str lr, [r5]   <= r5 invalid

reload:
(insn 6826 3453 6816 129 (parallel [
(set (reg:SI 3 r3 [4187])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg:SI 11
fp [4186]))
(zero_extend:DI (reg:SI 7 r7 [4188])))
(const_int 32 [0x20]
(clobber (reg:SI 5 r5 [5970]))
]) "20040709-1.c":108:291 70 {*umulsi3_highpart_v6}
 (nil))
[...]
(insn 3509 3530 3531 132 (set (mem/c:SI (reg/f:SI 5 r5 [5715]) [1
s.5566D.5531+0 S4 A32])
(reg:SI 14 lr [orig:692 D.6083 ] [692])) "20040709-1.c":13:5 654
{*arm_movsi_vfp}
 (nil))

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

  Attachment #46200|0   |1
is obsolete||

--- Comment #74 from Bernd Edlinger  ---
Created attachment 46203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46203=edit
gcc9-pr89093.patch

Same patch, just guard the target attribute with a version check,
so that supported boot-strap configurations should work

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #73 from Bernd Edlinger  ---
Okay, the requirement is only to be able to boot-strap with
a released gcc version, so gcc-8 should not use the pragma,
while gcc-9 should use the pagma.
I was able to bootstrap from x86_64 -> arm cross -> arm native
that worked fine.
I will guard the pragma with a gcc-version check.

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #72 from Bernd Edlinger  ---
I use host Compiler from last week:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/9.0.1/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-9-20190331/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=all
--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16
--with-float=hard
Thread model: posix
gcc version 9.0.1 20190331 (experimental) (GCC)

and libgnat, is definietly affected since the personality function pushes d8-d9

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #71 from Bernd Edlinger  ---
I am sorry, but my native arm bootstrap Fails:

g++ -std=gnu++98 -fno-PIE -c  -I../../gcc-trunk-r270444/gcc/../libgcc
-DEH_MECHANISM_arm -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format  -Wmissing-format-attribute -Woverloaded-virtual
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -Iada -I../../gcc-trunk-r270444/gcc
-I../../gcc-trunk-r270444/gcc/ada -I../../gcc-trunk-r270444/gcc/../include
-I../../gcc-trunk-r270444/gcc/../libcpp/include
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./gmp
-I/home/ed/gnu/gcc-trunk-r270444/gmp
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./mpfr/src
-I/home/ed/gnu/gcc-trunk-r270444/mpfr/src
-I/home/ed/gnu/gcc-trunk-r270444/mpc/src 
-I../../gcc-trunk-r270444/gcc/../libdecnumber
-I../../gcc-trunk-r270444/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-trunk-r270444/gcc/../libbacktrace
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./isl/include
-I/home/ed/gnu/gcc-trunk-r270444/isl/include  -o ada/raise-gcc.o -MT
ada/raise-gcc.o -MMD -MP -MF ada/.deps/raise-gcc.TPo
../../gcc-trunk-r270444/gcc/ada/raise-gcc.c
g++ -std=gnu++98 -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format  -Wmissing-format-attribute -Woverloaded-virtual
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -Iada -I../../gcc-trunk-r270444/gcc
-I../../gcc-trunk-r270444/gcc/ada -I../../gcc-trunk-r270444/gcc/../include
-I../../gcc-trunk-r270444/gcc/../libcpp/include
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./gmp
-I/home/ed/gnu/gcc-trunk-r270444/gmp
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./mpfr/src
-I/home/ed/gnu/gcc-trunk-r270444/mpfr/src
-I/home/ed/gnu/gcc-trunk-r270444/mpc/src 
-I../../gcc-trunk-r270444/gcc/../libdecnumber
-I../../gcc-trunk-r270444/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-trunk-r270444/gcc/../libbacktrace
-I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/./isl/include
-I/home/ed/gnu/gcc-trunk-r270444/isl/include  -o ada/seh_init.o -MT
ada/seh_init.o -MMD -MP -MF ada/.deps/seh_init.TPo
../../gcc-trunk-r270444/gcc/ada/seh_init.c
../../gcc-trunk-r270444/gcc/ada/raise-gcc.c:1165:55: error: unknown target
attribute or pragma 'general-regs-only'
 1165 |struct _Unwind_Context* uw_context ATTRIBUTE_UNUSED)
  |   ^
../../gcc-trunk-r270444/gcc/ada/raise-gcc.c:1183:32: error: unknown target
attribute or pragma 'general-regs-only'
 1183 | _Unwind_Context *uw_context)
  |^
../../gcc-trunk-r270444/gcc/ada/raise-gcc.c:1354:43: error: unknown target
attribute or pragma 'general-regs-only'
 1354 | struct _Unwind_Context* uw_context)
  |   ^
make[3]: *** [ada/raise-gcc.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf'
make: *** [all] Error 2

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #70 from Bernd Edlinger  ---
Yes, thanks, now switching to your latest patch.