[Bug go/93844] New: [debug] Incorrect scope for local variables

[vries at gcc dot gnu.org]

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

Bug ID: 93844
   Summary: [debug] Incorrect scope for local variables
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: vries at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

Consider the following c example hello.c (based on
gdb/testsuite/gdb.go/hello.go):
...
#include 

const char *st = "Shall we?";

int
main (void)
{
  printf ("%s\n", st);
  printf ("%s\n", "Before assignment");
  {
const char *st = "Hello, world!";
printf ("%s\n", st);
  }
  return 0;
}
...

when compiling and executing, we get first the value of the global variable,
then the one of the local variable:
...
$ gcc hello.c -g
$ ./a.out 
Shall we?
Before assignment
Hello, world!
...

Likewise, when debugging:
...
Temporary breakpoint 2, main () at hello.c:8
8 printf ("%s\n", st);
(gdb) p st
$3 = 0x4005d4 "Shall we?"
(gdb) n
Shall we?
9 printf ("%s\n", "Before assignment");
(gdb) p st
$4 = 0x4005d4 "Shall we?"
(gdb) n
Before assignment
11  const char *st = "Hello, world!";
(gdb) p st
$5 = 0x0
(gdb) n
12  printf ("%s\n", st);
(gdb) p st
$6 = 0x4005f0 "Hello, world!"
(gdb)
...

Now, consider the equivalent program in go:
...
package main

import "fmt"

var st = "Shall we?"

func main () {
  fmt.Println (st)
  fmt.Println ("Before assignment")
  st := "Hello, world!"
  fmt.Println (st)
}
...

When compiling and executing, again we get first the value of the global
variable, then the one of the local variable:
...
$ gccgo hello.go -g
$ ./a.out 
Shall we?
Before assignment
Hello, world!
...

But when debugging, we fail to print the value of the global variable:
...
Thread 1 "a.out" hit Temporary breakpoint 1, main.main () at hello.go:7
7   func main () {
(gdb) p st
$1 = 0x0 ""
(gdb) n
8 fmt.Println (st)
(gdb) p st
$2 = 0x0 ""
(gdb) n
Shall we?
9 fmt.Println ("Before assignment")
(gdb) p st
$3 = 0x0 ""
(gdb) n
Before assignment
10st := "Hello, world!"
(gdb) p st
$4 = 0x0 ""
(gdb) n
11fmt.Println (st)
(gdb) p st
$5 = 0x404e06 "Hello, world!"
...

This is due to lack of scoping of the local variable.

In the C case, the st local variable is scoped by a DW_TAG_lexical_block:
...
 <1><3c3>: Abbrev Number: 18 (DW_TAG_variable)
<3c4>   DW_AT_name: st
 <1><3d7>: Abbrev Number: 19 (DW_TAG_subprogram)
<3d8>   DW_AT_name: main
 <2><3f4>: Abbrev Number: 20 (DW_TAG_lexical_block)
 <3><405>: Abbrev Number: 21 (DW_TAG_variable)
<406>   DW_AT_name: st
...

But in the Go case, that scoping is missing:
...
 <1><155>: Abbrev Number: 10 (DW_TAG_variable)
<156>   DW_AT_name: main.st
(DW_OP_addr: 60e1f0)
 <1><1ceb>: Abbrev Number: 34 (DW_TAG_subprogram)
<1cec>   DW_AT_name: main.main
 <2><1d05>: Abbrev Number: 35 (DW_TAG_variable)
<1d06>   DW_AT_name: st
...

[Bug tree-optimization/93843] New: wrong code at -O3 on x86_64-linux-gnu

[qrzhang at gatech dot edu]

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

Bug ID: 93843
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

A recent regression. Gcc-9 works fine.

Bisection points to g:6271dd984d7f920d4fb17ad37af6a1f8e6b796dc

$ gcc-trunk -v
gcc version 10.0.1 20200219 (experimental) [master revision
665c5bad168:533e82edecf:51faf07cef9293af544bfacc7d0b320ab90d7d60] (GCC)


$ gcc-trunk -O3 abc.c ; ./a.out
4
0

$ gcc-9 -O3 abc.c ; ./a.out
4
4

$ gcc-trunk  abc.c ; ./a.out
4
4

$ cat abc.c
int printf(const char *, ...);
char a, e;
struct {
  short b;
  short c;
} d;
int f;
int main() {
  short *g = , *h = 
  e = 4 - a;
  *h = *g = e;
  for (; f < 2; f++)
printf("%d\n", d.c);
}

[Bug translation/93831] wrong abbreviation in diagnostic for 64-bit Darwin

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack
 CC||egallager at gcc dot gnu.org,
   ||iains at gcc dot gnu.org
   Severity|normal  |trivial

Re: [RFC] c++/93730 create VLA constructor if explicitly initialized as zeroes

[Andrew Pinski]

On Tue, Feb 18, 2020 at 7:29 AM Slava Barinov  wrote:
>
> * cp/decl.c (reshape_init_array_1): Enforce constructor creation
> for VLAs when initialized with zero value.
> * testsuite/g++.dg/pr93730.C: New test
> * testsuite/g++.dg/abi/mangle72.C: Change mangling to new version
>
> I'm not sure about fix of c++/58646 but this allows to work around certain 
> case
> when we want to initialize VLA with zeroes.
>
> Bootstrapped on x86_64, no testsuite regressions found.
>
> Not sure about mangling: is there any ABI requirements to mangling for cases
> from mangle72.C?

Can you send this patch to gcc-patc...@gcc.gnu.org instead?
gcc-bugs@gcc.gnu.org is more for bugzilla emails.

Thanks,
Andrew

>
> Signed-off-by: Slava Barinov 
> ---
>  gcc/ChangeLog   |  8 
>  gcc/cp/decl.c   |  3 ++-
>  gcc/testsuite/g++.dg/abi/mangle72.C | 14 +++---
>  gcc/testsuite/g++.dg/pr93730.C  |  8 
>  4 files changed, 25 insertions(+), 8 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/pr93730.C
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 7c481407de9..e614552a1a5 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,11 @@
> +2020-02-18  Vyacheslav Barinov  
> +
> +   PR c++/93730
> +   * cp/decl.c (reshape_init_array_1): Enforce constructor creation
> +   for VLAs when initialized with zero value.
> +   * testsuite/g++.dg/pr93730.C: New test
> +   * testsuite/g++.dg/abi/mangle72.C: Change mangling to new version
> +
>  2020-02-17  Richard Biener  
>
> PR c/86134
> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> index 31a556a0a1f..e90a397fc11 100644
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -6043,7 +6043,8 @@ reshape_init_array_1 (tree elt_type, tree max_index, 
> reshape_iter *d,
>  even if the string is empty.  */
>tree init_type = TREE_TYPE (elt_init);
>if (POINTER_TYPE_P (elt_type) != POINTER_TYPE_P (init_type)
> - || !type_initializer_zero_p (elt_type, elt_init))
> + || !type_initializer_zero_p (elt_type, elt_init)
> + || sized_array_p)
> last_nonzero = index;
>
>/* This can happen with an invalid initializer (c++/54501).  */
> diff --git a/gcc/testsuite/g++.dg/abi/mangle72.C 
> b/gcc/testsuite/g++.dg/abi/mangle72.C
> index 656a0cae403..928a38da021 100644
> --- a/gcc/testsuite/g++.dg/abi/mangle72.C
> +++ b/gcc/testsuite/g++.dg/abi/mangle72.C
> @@ -27,16 +27,16 @@ void g__ (Y) { }
>  // { dg-final { scan-assembler "_Z3g__1YIXtl1BtlA2_M1AA2_iLS3_0E" } }
>
>  void g0_ (Y) { }
> -// { dg-final { scan-assembler "_Z3g0_1YIXtl1BtlA2_M1AA2_iLS3_0E" } }
> +// { dg-final { scan-assembler "_Z3g0_1YIXtl1BtlA2_M1AA2_iLS3_0ELS3_0E" 
> } }
>
>  void g00 (Y) { }
> -// { dg-final { scan-assembler "_Z3g001YIXtl1BtlA2_M1AA2_iLS3_0E" } }
> +// { dg-final { scan-assembler "_Z3g001YIXtl1BtlA2_M1AA2_iLS3_0ELS3_0E" 
> } }
>
>  void g0x (Y) { }
>  // FIXME: This needs to mangle differently from g00.  The space at
>  // the end is intentional to make the directive fail so that the xfail
>  // can be reminder to change this once the mangling is fixed.
> -// { dg-final { scan-assembler "_Z3g0x1YIXtl1BtlA2_M1AA2_iLS3_0E " { 
> xfail *-*-* } } }
> +// { dg-final { scan-assembler "_Z3g0x1YIXtl1BtlA2_M1AA2_iLS3_0ELS3_0E " 
> { xfail *-*-* } } }
>
>  void gx_ (Y) { }
>  // { dg-final { scan-assembler "_Z3gx_1YIXtl1BtlA2_M1AA2_iLS3_0ELS3_0E" 
> } }
> @@ -49,17 +49,17 @@ void h___ (Z) { }
>  // { dg-final { scan-assembler "_Z4h___1ZIXtl1CtlA3_M1AA2_iLS3_0E" } }
>
>  void h0__ (Z) { }
> -// { dg-final { scan-assembler "_Z4h0__1ZIXtl1CtlA3_M1AA2_iLS3_0E" } }
> +// { dg-final { scan-assembler "_Z4h0__1ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0E" 
> } }
>
>  void h00_ (Z) { }
> -// { dg-final { scan-assembler "_Z4h00_1ZIXtl1CtlA3_M1AA2_iLS3_0E" } }
> +// { dg-final { scan-assembler 
> "_Z4h00_1ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0ELS3_0E" } }
>
>  void h000 (Z) { }
> -// { dg-final { scan-assembler "_Z4h0001ZIXtl1CtlA3_M1AA2_iLS3_0E" } }
> +// { dg-final { scan-assembler 
> "_Z4h0001ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0ELS3_0E" } }
>
>  void h00x (Z) { }
>  // FIXME: This needs to mangle differently from hx0_ and hx__.
> -// { dg-final { scan-assembler "_Z4h00x1ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0E 
> " { xfail *-*-*} } }
> +// { dg-final { scan-assembler 
> "_Z4h00x1ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0ELS3_0E " { xfail *-*-*} } }
>
>  void h0x0 (Z) { }
>  // { dg-final { scan-assembler 
> "_Z4h0x01ZIXtl1CtlA3_M1AA2_iLS3_0ELS3_0ELS3_0E" } }
> diff --git a/gcc/testsuite/g++.dg/pr93730.C b/gcc/testsuite/g++.dg/pr93730.C
> new file mode 100644
> index 000..066c23a99cb
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pr93730.C
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-additional-options "-Wno-vla" } */
> +
> +int sz = 1;
> +
> +void f() {
> +  int arr[1][sz] = { 0 };
> +}
> --
> 2.25.0

[Bug target/93811] __builtin___clear_cache() is a noop on powerpc (which is incorrect)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Note ___clear_cache was originally designed for trampolines. PoewrPC64v1 ABI
does not use trampolines for nested functions.

[Bug target/93828] [10 Regression] incorrect shufps instruction emitted for -march=k8

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #190 from Peter Bisroev  ---
(In reply to dave.anglin from comment #189)
> On 2020-02-16 4:21 p.m., John David Anglin wrote:
> > On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
> >> I have not had a chance to look through these in great detail, will do this
> >> later today, but some things I've noticed (not sure how important they are
> >> yet):
> >> - aCC seems to use PCREL21BI relocations while GCC PCREL21B.
> > That may be the clue.  With GNU ld, only PCREL21BI goes through PLT.  Need 
> > to look at when
> > GNU as uses PCREL21BI instead of PCREL21B.  I believe this selection is 
> > done in assembler.
> Sorry, only PCREL21B goes through PLT.  PCREL21BI is for local (internal)
> calls.

Hi Dave, I apologize for the delay in response, been a busy week so far.
However I should be able to take a look at this further tomorrow.

As per your recommendation I will try and find out when GNU as generates
PCREL21BI relocations instead of PCREL21B. I am assuming this is what we want
in order to match aCC behavior, right?

Thanks!

[Bug c++/93842] New: generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression

[kuzniar95 at o2 dot pl]

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

Bug ID: 93842
   Summary: generic lambda accesses a variable with with automatic
storage duration that wasn't captured by the lambda
expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kuzniar95 at o2 dot pl
  Target Milestone: ---

The following code:
--
int main() {
constexpr char ch = '=';

[](auto) { return ch; }; // NOT OK
}
--
g++ -Wunused -std=c++14 lambda.cpp

produces:
--
lambda.cpp: In function ‘int main()’:
lambda.cpp:2:17: warning: variable ‘ch’ set but not used
[-Wunused-but-set-variable]
  constexpr char ch = '=';
--

I believe GCC is doubly wrong here, as this warning isn't right, because 'ch'
is actually used, but primarily it shouldn't compile the code as:
> If a lambda expression (or an instantiation of a generic lambda's function
> call operator) ODR-uses this or any variable with automatic storage duration,
> it must be captured by the lambda expression.

[Bug middle-end/93829] [10 Regression] bogus -Wstringop-overflow on memcpy of a struct with a pointer member from another with a long string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |10.0

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01140.html

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:8f9dd1b0bdd935592ba151e9d843fddf6193afbc

commit r10-6749-g8f9dd1b0bdd935592ba151e9d843fddf6193afbc
Author: Marek Polacek 
Date:   Wed Feb 19 16:36:38 2020 -0500

c++: Fix wrong-code with non-constexpr constructor [PR93169]

In order to detect modifying constant objects in constexpr evaluation,
which is UB, in r10-2655 I added code that sets TREE_READONLY on
CONSTRUCTORs of const-qualified objects after they have been fully
constructed.  But I never made sure that what we're setting the flag
on actually is a CONSTRUCTOR.  Consequently, as this test case shows,
we could set TREE_READONLY on a VAR_DECL that in fact wasn't constant,
causing problems later.  Fixed by setting the flag on CONSTRUCTORs
only, and only when the evaluation produced something constant.

2020-02-19  Marek Polacek  

PR c++/93169 - wrong-code with a non-constexpr constructor.
* constexpr.c (cxx_eval_call_expression): Only set TREE_READONLY
on constant CONSTRUCTORs.

* g++.dg/cpp0x/constexpr-93169.C: New test.

[Bug c++/93431] FAIL: g++.dg/cpp2a/lambda-uneval9.C -std=c++2a (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
The following are unsupported:
UNSUPPORTED: g++.dg/cpp2a/lambda-uneval9.C  -std=c++98
UNSUPPORTED: g++.dg/cpp2a/lambda-uneval9.C  -std=c++14
UNSUPPORTED: g++.dg/cpp2a/lambda-uneval9.C  -std=c++17

Seems like on issue with check_effective_target_c++2a.

[Bug tree-optimization/92128] fold more non-constant strlen relational expressions

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:ccf86d54cb02ed24bc4568bd9fffdcdbf0bf68a8

commit r10-6748-gccf86d54cb02ed24bc4568bd9fffdcdbf0bf68a8
Author: Martin Sebor 
Date:   Wed Feb 19 16:54:50 2020 -0700

PR tree-optimization/92128 - fold more non-constant strlen relational
expressions

gcc/testsuite/ChangeLog:
* gcc.dg/strlenopt-81.c: Align arrays to let strictly aligned targets
optimize away calls as expected.

[Bug c++/93596] [10 Regression] ICE related to templates and vectors.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug translation/93841] New: typo in or1kopt: generated using using

[roland.illig at gmx dot de]

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

Bug ID: 93841
   Summary: typo in or1kopt: generated using using
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Duplicate word. Once in or1k.opt, once in invoke.texi.

[Bug tree-optimization/79621] Missed path isolation opportunity

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from Jeffrey A. Law  ---
I don't think the missed optimization opportunity is really ever going to be
worth the complication to catch.  With the ICE fixed years ago, I'm just going
to close the BZ.

[Bug translation/93840] .po files are installed to PREFIX but only looked up in /usr/lib

[roland.illig at gmx dot de]

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

Roland Illig  changed:

   What|Removed |Added

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

--- Comment #2 from Roland Illig  ---
$ grep -wr ENABLE_NLS . | grep h:
./build-x86_64-pc-linux-gnu/libcpp/config.h:/* #undef ENABLE_NLS */
./gcc/auto-host.h:#define ENABLE_NLS 1
./intl/config.h:#define ENABLE_NLS 1
./libcpp/config.h:#define ENABLE_NLS 1

ltrace says:
bindtextdomain("gcc", "/home/rillig/tmp/gcc10/share/locale") =
"/home/rillig/tmp/gcc10/share/locale"

objdump -t says:
bindtextdomain@@GLIBC_2.2.5

I wonder why the openat calls don't ever mention "gcc.mo". There's also no
readdirat anywhere near, therefore I could not explain how gettext would even
find the translations.

I quickly wrote a test program, and that program confirms that it's the GNU C
Library and its libintl that behaves strange. Without setting LC_ALL or
LC_MESSAGES, it correctly searches in the path given to bindtextdomain. But
when LC_MESSAGES is set, only /usr/lib/locale is searched, and the .mo files
are not even touched.

#include 
#include 
#include 
#include 

int main(void)
{
setlocale(LC_ALL, "");
bindtextdomain("gcc", "/home/rillig/tmp/gcc10/share/locale");
textdomain("gcc");
setlocale(LC_ALL, "");
puts(gettext(""));
}

In the end, I just did a "ln -s de en" in locale/share, and now I can test my
German translation.

Thanks for your help.

[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #10 from Peter Bergner  ---
Ok, after debugging, this looks to be a bug in rs6000_legitimate_address_p().
At the beginning of LRA, we have the following insn:

(insn 520 67 71 5 (set (mem:V16QI (and:DI (reg/f:DI 110 sfp)
(const_int -16 [0xfff0])) [0 MEM 
[(char *) + 16B]+0 S16 A128])
(reg:V16QI 303 [ vect__2.13 ])) "bug.i":10:10 1103 {vsx_movv16qi_64bit}
 (expr_list:REG_DEAD (reg:V16QI 303 [ vect__2.13 ])
(nil)))

lra_eliminate() then converts that to:

(insn 520 67 71 5 (set (mem:V16QI (and:DI (plus:DI (reg/f:DI 110 sfp)
(const_int 112 [0x70]))
(const_int -16 [0xfff0])) [0 MEM 
[(char *) + 16B]+0 S16 A128])
(reg:V16QI 303 [ vect__2.13 ])) "bug.i":10:10 1103 {vsx_movv16qi_64bit}
 (expr_list:REG_DEAD (reg:V16QI 303 [ vect__2.13 ])
(nil)))

which isn't valid and needs fixing...which is fine.  process_address() then
gives us:

(insn 520 67 71 5 (set (mem:V16QI (and:DI (reg:DI 633)
(const_int -16 [0xfff0])) [0 MEM 
[(char *) + 16B]+0 S16 A128])
(reg:V16QI 303 [ vect__2.13 ])) "bug.i":10:10 1103 {vsx_movv16qi_64bit}
 (expr_list:REG_DEAD (reg:V16QI 303 [ vect__2.13 ])
(nil)))

...with pseudo 633 being set to plus:DI (reg/f:DI 110 sfp) (const_int 112
[0x70])
which is also good.  The bug comes when we now pass insn 520 to
rs6000_legitimate_address_p() and we hit the following code:

  /* If this is an unaligned stvx/ldvx type address, discard the outer AND.  */
  if (VECTOR_MEM_ALTIVEC_P (mode)
  && GET_CODE (x) == AND
  && CONST_INT_P (XEXP (x, 1))
  && INTVAL (XEXP (x, 1)) == -16)
x = XEXP (x, 0);

Our mode is V16QI, so we should execute this code, but we don't.  The problem
is that VECTOR_MEM_ALTIVEC_P(mode) checks for "rs6000_vector_unit[(MODE)] ==
VECTOR_ALTIVEC" and V16QI mode returns VECTOR_VSX, so we fail to fall into the
code above and end up telling LRA this isn't a valid address.  LRA then
attempts to spill this again and again and...   

The following patch fixes the bug for me and I'm regtesting it now:

--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -8808,7 +8808,7 @@ rs6000_legitimate_address_p (machine_mode mode, rtx x,
bool reg_ok_strict)
   bool quad_offset_p = mode_supports_dq_form (mode);

   /* If this is an unaligned stvx/ldvx type address, discard the outer AND. 
*/
-  if (VECTOR_MEM_ALTIVEC_P (mode)
+  if (VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)
   && GET_CODE (x) == AND
   && CONST_INT_P (XEXP (x, 1))
   && INTVAL (XEXP (x, 1)) == -16)

[Bug libstdc++/93770] std::tuple::operator< sometimes does needless extra work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
If we structure it like this we can avoid instantiating the redundant
expressions:

  static constexpr bool
  __less(const _Tp& __t, const _Up& __u)
  {
if (std::get<__i>(__t) < std::get<__i>(__u))
  return true;

if _GLIBCXX17_CONSTEXPR ((__i + 1) < __size)
  {
return !bool(std::get<__i>(__u) < std::get<__i>(__t))
  && __tuple_compare<_Tp, _Up, __i + 1, __size>::__less(__t, __u);
  }
return false;
  }

[Bug fortran/93839] diagnostic starts with lowercase letter

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Feb 19, 2020 at 10:41:16PM +, roland.illig at gmx dot de wrote:
> 
> --- Comment #2 from Roland Illig  ---
> Ok, if it's intentionally written in lowercase I'm fine with it. In the German
> translation I used uppercase names since all German nouns start with 
> uppercase,
> therefore I have a consistent "Rang + Korang", which looks nice.
> 
> I'm assuming that these "variable names" are not used anywhere else. If this
> assumption is wrong, please tell me.
> 

The spelling is probably author dependent. :-)

The words 'rank' and 'corank' appear all over the Fortran
standard.  Both are the names on intrinsic routines or
names of dummy arguments or simply used to describe a property
of an array or coarray.  I suspect that if you grep the 
gfortran source code, you'll find errors message with 'rank' and
'RANK', and cases where the word is printed with %qs formatting.

[Bug translation/93836] teach xgettext what HOST_WIDE_INT_PRINT means

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
Thanks for the explanation. I think it might make sense to have a static
analysis tool for cases like this, to prevent this mistake from the beginning,
or at least be notified quickly, before the translators have to write bug
reports. It's not the first time I saw this kind of bug. :)

[Bug fortran/93839] diagnostic starts with lowercase letter

[roland.illig at gmx dot de]

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

Roland Illig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Roland Illig  ---
Ok, if it's intentionally written in lowercase I'm fine with it. In the German
translation I used uppercase names since all German nouns start with uppercase,
therefore I have a consistent "Rang + Korang", which looks nice.

I'm assuming that these "variable names" are not used anywhere else. If this
assumption is wrong, please tell me.

[Bug translation/93840] .po files are installed to PREFIX but only looked up in /usr/lib

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
The messages should be read from LOCALEDIR as passed to bindtextdomain.  
If GCC is calling bindtextdomain from libc with the correct LOCALEDIR 
argument, this is not a GCC bug.  (If it's calling bindtextdomain from the 
shipped intl/, there's probably a configure bug causing intl/ to be used.  
If it's not calling bindtextdomain, or calling it too late, there's a bug 
somewhere else.  But in any case, the first thing to find out is whether 
bindtextdomain is called, when (compared to the openat calls), and with 
what arguments.)

[Bug libstdc++/93770] std::tuple::operator< sometimes does needless extra work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-19
 Ever confirmed|0   |1

[Bug fortran/93839] diagnostic starts with lowercase letter

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
The other error messages start with an English word whereas
'rank' here is used in a mathematical sense as a variable.
Here 'rank + corank' is a mathematical expression.  As the 
author of this error message I find this much more appealing
than 'Rank + corank'.

Changed to 'P5 enhancement'

Personally, I think this should be close as WONTFIX, but I'll
leave it open.

[Bug translation/93836] teach xgettext what HOST_WIDE_INT_PRINT means

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
It is never valid to use HOST_WIDE_INT_PRINT macros in calls to diagnostic 
functions, because the HOST_WIDE_INT_PRINT macros expand to host printf 
formats (e.g. "I64" on MinGW host), which may not be understood by the 
pretty-printing code which has its own host-independent set of formats.

The bug here is not in xgettext, it's that a call to a GCC diagnostic 
function should be using %wd not HOST_WIDE_INT_PRINT.

[Bug translation/93840] New: .po files are installed to PREFIX but read from DATAROOTDIR

[roland.illig at gmx dot de]

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

Bug ID: 93840
   Summary: .po files are installed to PREFIX but read from
DATAROOTDIR
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

When GCC installs the translation files, it should install them in the same
place where it later looks them up. In the following example, this is not the
case.

~/git/gcc/configure --disable-bootstrap --prefix=$HOME/tmp/gcc10
--enable-languages=c --disable-multilib

make -s -j7 install

strace env LC_ALL=de_DE.UTF-8 $HOME/tmp/gcc10/bin/gcc 2>&1 | grep locale
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/de_DE.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de_DE.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de_DE/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de_DE.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de_DE.utf8/LC_MESSAGES", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de_DE/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de.utf8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/de/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #7 from Marek Polacek  ---
(In reply to Jason Merrill from comment #6)
> > It is caused by 
> > commit 88bbd5a94e06eb42a5ed84a3ff6da498bea229e9 (HEAD, refs/bisect/bad)
> 
> r274671, or r10-2655-g04e1749c557a5df14f8528efa451bb0e93afea80 in the new
> git.
> 
> The problem is that
> 
>  TREE_READONLY (e) = true;
> 
> ends up setting the flag on the variable 'f' because its initialization is
> not actually constant.  Protecting that by checking one or both of
> *non_constant_p and TREE_CODE (e) should fix the issue.  What do you think,
> Marek?

Absolutely, blindly setting TREE_READONLY was definitely a mistake.  Patch
posted: .  Thanks for
the suggestion.

[Bug fortran/93839] New: diagnostic starts with lowercase letter

[roland.illig at gmx dot de]

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

Bug ID: 93839
   Summary: diagnostic starts with lowercase letter
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From fortran/array.c:
>   gfc_error ("rank + corank of %qs exceeds %d at %C", sym->name,

The other diagnostics in that file start with an uppercase letter.

[Bug translation/93838] New: space at the end of a diagnostic in cp/parser.c

[roland.illig at gmx dot de]

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

Bug ID: 93838
   Summary: space at the end of a diagnostic in cp/parser.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From cp/parser.c:
> pedwarn (token->location, 0, "C++20 concept definition syntax "
>  "is % = %> ");

Isn't there a linter in contrib/ for cases like these?

[Bug fortran/93835] [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-19
 CC||kargl at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
Patch is against svn r280157.  Someone needs to convert the example code into a
testcase.  Some whitespace clean is mixed in as a bonus.

Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c  (revision 280157)
+++ gcc/fortran/simplify.c  (working copy)
@@ -5497,7 +5497,7 @@ simplify_findloc_nodim (gfc_expr *result, gfc_expr *va
   bool continue_loop;
   bool ma;

-  for (i = 0; irank; i++)
+  for (i = 0; i < array->rank; i++)
 res[i] = -1;

   /* Shortcut for constant .FALSE. MASK.  */
@@ -5506,14 +5506,19 @@ simplify_findloc_nodim (gfc_expr *result, gfc_expr *va
   && !mask->value.logical)
 goto finish;

-  for (i = 0; i < array->rank; i++)
+  if (array->shape)
 {
-  count[i] = 0;
-  sstride[i] = (i == 0) ? 1 : sstride[i-1] * mpz_get_si
(array->shape[i-1]);
-  extent[i] = mpz_get_si (array->shape[i]);
-  if (extent[i] <= 0)
-   goto finish;
+  for (i = 0; i < array->rank; i++)
+   {
+ count[i] = 0;
+ sstride[i] = (i == 0) ? 1 : sstride[i-1] * mpz_get_si
(array->shape[i-1]);
+ extent[i] = mpz_get_si (array->shape[i]);
+ if (extent[i] <= 0)
+   goto finish;
+   }
 }
+  else
+goto finish;

   continue_loop = true;
   array_ctor = gfc_constructor_first (array->value.constructor);
@@ -5540,7 +5545,7 @@ simplify_findloc_nodim (gfc_expr *result, gfc_expr *va

  if (ma && gfc_compare_expr (a, value, INTRINSIC_EQ) == 0)
{
- for (i = 0; irank; i++)
+ for (i = 0; i < array->rank; i++)
res[i] = count[i];
  if (!back_val)
goto finish;
@@ -5565,9 +5570,9 @@ simplify_findloc_nodim (gfc_expr *result, gfc_expr *va
} while (count[n] == extent[n]);
 }

- finish:
+finish:
   result_ctor = gfc_constructor_first (result->value.constructor);
-  for (i = 0; irank; i++)
+  for (i = 0; i < array->rank; i++)
 {
   gfc_expr *r_expr;
   r_expr = result_ctor->expr;

[Bug c++/93676] [8/9/10 Regression] crash in build_value_init

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01124.html

[Bug c++/93790] Cannot initialize reference from std::reference_wrapper using direct- or list-initialization syntax in GCC 10 c++2a mode

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-19
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Looks like an undesirable side-effects of

commit 43aae289866f5ea55d187444520412554aa2e171
Author: Marek Polacek 
Date:   Tue Dec 3 15:59:40 2019 +

PR c++/91363 - P0960R3: Parenthesized initialization of aggregates.

So mine.

[Bug c/93837] New: overly complicated code in c_finish_omp_declare_variant

[roland.illig at gmx dot de]

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

Bug ID: 93837
   Summary: overly complicated code in
c_finish_omp_declare_variant
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

> else if (fndecl_built_in_p (variant)
>  && (strncmp (IDENTIFIER_POINTER (DECL_NAME (variant)),
>   "__builtin_", strlen ("__builtin_")) == 0
>  || strncmp (IDENTIFIER_POINTER (DECL_NAME (variant)),
>  "__sync_", strlen ("__sync_")) == 0
>  || strncmp (IDENTIFIER_POINTER (DECL_NAME (variant)),
>  "__atomic_", strlen ("__atomic_")) == 0))

Why not simply define a function str_startswith and rewrite the code to:

> str_startswith (IDENTIFIER_POINTER (DECL_NAME (variant)), "__builtin_")
> || str_startswith (IDENTIFIER_POINTER (DECL_NAME (variant)), "__sync_")
> || str_startswith (IDENTIFIER_POINTER (DECL_NAME (variant)), "__atomic_")

This would make it even more obvious that an additional CSE pass would make the
code even easier to read:

> const char *variant_name = IDENTIFIER_POINTER (DECL_NAME (variant));
> if (str_startswith(variant_name, "__builtin_")
> || str_startswith(variant_name, "__sync_")
> || str_startswith(variant_name, "__atomic_"))

Is there any reason why you chose to write the code in the complicated and hard
to read way?

[Bug translation/93836] New: teach xgettext what HOST_WIDE_INT_PRINT means

[roland.illig at gmx dot de]

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

Bug ID: 93836
   Summary: teach xgettext what HOST_WIDE_INT_PRINT means
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From pru-pragma.c:
> error ("% index %" HOST_WIDE_INT_PRINT "d"
>" is not valid", i);

This code ends up in gcc.pot as:

> msgstr "% index %"

This is wrong and means that this particular error message will never be output
in its translated form.

[Bug c++/93761] ICE when compiling a standard header as a header unit

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
fwiw the stack traceback doesn't look like it's concept related, probably some
other bug ...

[Bug other/93168] Error messages are full of control code garbage

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to David Malcolm from comment #6)
> Segher: did the above patch fix it for your terminal?

I haven't found time to test it on all those systems yet, no.

[Bug middle-end/93644] [10 Regression] spurious -Wreturn-local-addr with PHI of PHI

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|10.0|11.0

[Bug middle-end/93644] [10 Regression] spurious -Wreturn-local-addr with PHI of PHI

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
So optimizing things in remove_range_assertions works for the reduced testcase,
but not for the original testcase.  There's a couple of deeper issues that have
to be figured out for the original testcase. 

The trick we were trying to utilize is if we could safely copy-propagate a
value which we knew not to be a stack address for an object which might have
been a stack address, then we avoid the false positive.  This has a nice
property that it likely improves optimization.

But it's insufficient for the full testcase.  First, loops get in the way. 

We might have something like this at the top of a loop:


x = phi (a, b)
b = 


If we have an subsequent assert that x != b, we can't then replace uses of x
with a.  Why?  Because the assert refers to the value of b on the current
iteration while the PHI refers to the value of b on the previous iteration. 
This issue doesn't show up in the reduced testcase, but does in the full
testcase.

Second, we have to deal with the cascading nature of the asserts.  If we go
back to the original testcase the PHI in question looks like this just before
removal of the ASSERT_EXPRs in VRP1:

  # _25 = PHI <0B(10), buf_79(16), 0B(26), 0B(30), b_94(15), b_92(19), 0B(9),
buf_80(17), buf_80(39)>

Just looking at chain for buf_79 we have:

  # buffer_17 = PHI <_buf(5), buffer_38(D)(34)>

  # buf_20 = PHI 

  # buf_29 = PHI 

  buf_79 = ASSERT_EXPR ;


We can see that buf_79 has 3 possible values:

_buf, buffer_38 and buf_90 (buf_90 is loop carried)

The ASSERT only excludes _buf so we can't copy propagate buffer_38 or
buf_90 for the uses of buf_79.  And we (of course) lose the knowledge that
buf_79 can't be _buf when we drop the ASSERT_EXPRs.


We may still want to use the trick Marc noted in c#2.  It applies something
like 20k times during a bootstrap and fixes Wreturn-local-addr-9 in the
testsuite.  But it doesn't seem appropriate for stage4.

I find myself wondering if we could tackle this on the alias analysis side by
looking at the PTA solution and see if any of the objects point into the stack.
 I also wonder if PTA would benefit from the VRP analysis which excluded the
stack object for certain addresses.  All blue sky stuff though.

[Bug other/93168] Error messages are full of control code garbage

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Segher: did the above patch fix it for your terminal?

[Bug tree-optimization/77889] missing optimization on strlen(p + offset) with a bounded offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2016-10-07 00:00:00 |2020-2-19
  Component|middle-end  |tree-optimization
  Known to fail||10.0, 7.3.0, 8.2.0, 9.1.0

--- Comment #4 from Martin Sebor  ---
A simpler test case (that doesn't involve __builtin_object_size checking):

$ cat z.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout z.c
const char a[] = "0123456789";

void f (int i)
{
  if (__builtin_strlen (a + i) > 30)   // folded
__builtin_abort ();
}

void g (int i)
{
  const char *p = a + i;
  if (__builtin_strlen (p) > 30)   // not folded
__builtin_abort ();
}


;; Function f (f, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=1)

f (int i)
{
   [local count: 1073741824]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1934, cgraph_uid=2, symbol_order=2)

g (int i)
{
  const char * p;
  sizetype _1;
  long unsigned int _2;

   [local count: 1073741824]:
  _1 = (sizetype) i_3(D);
  p_4 =  + _1;
  _2 = __builtin_strlen (p_4);
  if (_2 > 30)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}

[Bug tree-optimization/63989] tree-ssa-strlen.c doesn't handle constant pointer plus and array refs if constant offset is smaller than known constant string length

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2014-11-20 00:00:00 |2020-2-19
  Known to fail||10.0, 5.5.0, 6.4.0, 7.5.0,
   ||8.3.0, 9.2.0

--- Comment #10 from Martin Sebor  ---
No change in GCC 10.  The strlen call in f3() is still not eliminated.

[Bug fortran/93835] [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

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

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

This analogous variant works :


$ cat z2.f90
program p
   print *, findloc([integer::], 1)
end


$ gfortran-10-20200216 z1.f90 && a.out
   0
$

[Bug fortran/93835] New: [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

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

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

Bug ID: 93835
   Summary: [9/10 Regression] ICE in simplify_findloc_nodim, at
fortran/simplify.c:5513
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20181021 and 20181028 :


$ cat z1.f90
program p
   print *, findloc(shape(1), 1)
end


$ gfortran-9-20181021 -c z1.f90
$
$ gfortran-10-20200216 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbae76f crash_signal
../../gcc/toplev.c:328
0x6d0d20 simplify_findloc_nodim
../../gcc/fortran/simplify.c:5513
0x6d9df9 gfc_simplify_findloc(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*,
gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:5779
0x6607f6 do_simplify
../../gcc/fortran/intrinsic.c:4638
0x66af6a gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4996
0x6c2b1e resolve_unknown_f
../../gcc/fortran/resolve.c:2894
0x6c2b1e resolve_function
../../gcc/fortran/resolve.c:3238
0x6c2b1e gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7000
0x6b9eac gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6967
0x6b9eac gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11687
0x6c8d9f gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10714
0x6b8bd8 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11677
0x6bb457 resolve_codes
../../gcc/fortran/resolve.c:17204
0x6bb51e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17239
0x6a987c resolve_all_program_units
../../gcc/fortran/parse.c:6245
0x6a987c gfc_parse_file()
../../gcc/fortran/parse.c:6492
0x6f44ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93834] New: [8/9/10 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

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

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

Bug ID: 93834
   Summary: [8/9/10 Regression] ICE in trans_caf_is_present, at
fortran/trans-intrinsic.c:8469
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started to ICE with gfortran-7 :
(derived from a valid z0.f90)


$ cat z0.f90
program p
   integer, allocatable :: a[:]
   print *, allocated(a)
end


$ cat z1.f90
program p
   integer, allocatable :: a[:]
   print *, allocated(a[1])
end


$ cat z2.f90
program p
   integer, allocatable :: a[:]
   if ( allocated(a[1]) ) stop
end


$ gfortran-10-20200216 -c z1.f90 -fcoarray=single
$
$ gfortran-10-20200216 -c z1.f90 -fcoarray=lib
z1.f90:3:0:

3 |print *, allocated(a[1])
  |
internal compiler error: in trans_caf_is_present, at
fortran/trans-intrinsic.c:8469
0x79a4c3 trans_caf_is_present
../../gcc/fortran/trans-intrinsic.c:8469
0x79a4c3 gfc_conv_allocated
../../gcc/fortran/trans-intrinsic.c:8531
0x7aadab gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9840
0x77d52a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8665
0x787205 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:8810
0x7b2197 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2582
0x735727 trans_code
../../gcc/fortran/trans.c:2084
0x7aecc2 build_dt
../../gcc/fortran/trans-io.c:2026
0x735747 trans_code
../../gcc/fortran/trans.c:2056
0x76cd5d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6835
0x6e69a6 translate_all_program_units
../../gcc/fortran/parse.c:6306
0x6e69a6 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x731b3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93833] New: [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

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

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

Bug ID: 93833
   Summary: [8/9/10 Regression] ICE in trans_array_constructor, at
fortran/trans-array.c:2566
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started to ICE with gfortran-8 before 20180525 :


$ cat z1.f90
program p
   character(:), allocatable :: c
contains
   subroutine s
  associate (y => [c])
 if (any(y /= [c])) stop
  end associate
   end
end


$ gfortran-7 -c z1.f90
$
$ gfortran-10-20200216 -c z1.f90
z1.f90:6:0:

6 |  if (any(y /= [c])) stop
  |
internal compiler error: in trans_array_constructor, at
fortran/trans-array.c:2566
0x709197 trans_array_constructor
../../gcc/fortran/trans-array.c:2566
0x709197 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:2924
0x709205 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5216
0x744ecd gfc_conv_intrinsic_anyall
../../gcc/fortran/trans-intrinsic.c:4342
0x7523dd gfc_conv_intrinsic_anyall
../../gcc/fortran/trans-intrinsic.c:10203
0x7523dd gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9898
0x72837a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8665
0x72b1f3 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8718
0x763859 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:1442
0x76b33a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1480
0x6f7b67 trans_code
../../gcc/fortran/trans.c:1952
0x76b81f gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2276
0x6f7bd7 trans_code
../../gcc/fortran/trans.c:1960
0x7210a4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6835
0x720ea4 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5830
0x720ea4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6767
0x6a9ec6 translate_all_program_units
../../gcc/fortran/parse.c:6306
0x6a9ec6 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x6f44ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93832] New: [8/9/10 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:3100

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

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

Bug ID: 93832
   Summary: [8/9/10 Regression] ICE in
gfc_convert_to_structure_constructor, at
fortran/primary.c:3100
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started to ICE with gfortran-8 before 20180525 :


$ cat z1.f90
program p
   type t
  character :: a
  integer :: b
  integer :: c(t(1))
   end type
   type(t) :: z = t('a', 2, [3])
end


$ gfortran-7 -c z1.f90   # error message doubled
z1.f90:5:19:

   integer :: c(t(1))
   1
Error: No initializer for component 'b' given in the structure constructor at
(1)!
z1.f90:5:19:

   integer :: c(t(1))
   1
Error: No initializer for component 'b' given in the structure constructor at
(1)!


$ gfortran-10-20200216 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbae76f crash_signal
../../gcc/toplev.c:328
0x6aea05 gfc_convert_to_structure_constructor(gfc_expr*, gfc_symbol*,
gfc_expr**, gfc_actual_arglist**, bool)
../../gcc/fortran/primary.c:3100
0x6c27a1 resolve_generic_f
../../gcc/fortran/resolve.c:2723
0x6c27a1 resolve_function
../../gcc/fortran/resolve.c:3230
0x6c27a1 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7000
0x61a724 resolve_array_bound
../../gcc/fortran/array.c:378
0x61b396 gfc_resolve_array_spec(gfc_array_spec*, int)
../../gcc/fortran/array.c:422
0x6be945 resolve_component
../../gcc/fortran/resolve.c:14576
0x6bf4c2 resolve_fl_derived0
../../gcc/fortran/resolve.c:14695
0x6bfb07 resolve_fl_derived0
../../gcc/fortran/resolve.c:14782
0x6bfb07 resolve_fl_derived
../../gcc/fortran/resolve.c:14824
0x6bbf6f resolve_symbol
../../gcc/fortran/resolve.c:15198
0x6df9f2 do_traverse_symtree
../../gcc/fortran/symbol.c:4147
0x6b7754 resolve_types
../../gcc/fortran/resolve.c:17122
0x6bb50c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17237
0x6a987c resolve_all_program_units
../../gcc/fortran/parse.c:6245
0x6a987c gfc_parse_file()
../../gcc/fortran/parse.c:6492
0x6f44ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug translation/93831] New: wrong abbreviation in diagnostic for 64-bit Darwin

[roland.illig at gmx dot de]

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

Bug ID: 93831
   Summary: wrong abbreviation in diagnostic for 64-bit Darwin
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From darwin.c:
> "%<-mpic-symbol-stubs%> is not required for 64b code (ignored)");

The 64b probably means 64-bit, therefore it should be spelled out. The
abbreviation b for bit should only be used in transfer speeds, like 100kb/s.

[Bug translation/93830] New: typo in avr command line error message

[roland.illig at gmx dot de]

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

Bug ID: 93830
   Summary: typo in avr command line error message
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From avr-common.c:
> "configured %<--with-double={|32|32,64|64,32}%>");

The "{|" looks wrong. In the 64-bit case a few lines above, there is no leading
"|" inside the braces.

[Bug middle-end/93829] [10 Regression] bogus -Wstringop-overflow on memcpy of a struct with a pointer member from another with a long string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Known to work||9.2.0
URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1800289
   Keywords||diagnostic
   Last reconfirmed||2020-02-19
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug middle-end/93829] New: [10 Regression] bogus -Wstringop-overflow on memcpy of a struct with a pointer member from another with a long string

[msebor at gcc dot gnu.org]

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

Bug ID: 93829
   Summary: [10 Regression] bogus -Wstringop-overflow on memcpy of
a struct with a pointer member from another with a
long string
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following test case reduced from RHBZ #1800289 shows a spurious
-Wstringop-overflow issued for the memcpy call.  The warning misinterprets the
second MEM_REF involving the string as a store of the string itself into the
allocated object (as opposed to the store of its address into the char*
member).

$ cat rhbz-1800289.c && gcc -O2 -S -Wall -Wextra -fdump-tree-strlen=/dev/stdout
rhbz-1800289.c
struct S
{
  void *p, *q, *r;
} a;

void create_command_list (void)
{
  struct S b = { 0, "Enable all debug messages", 0 };

  __builtin_memcpy (, , sizeof b);
}

;; Function create_command_list (create_command_list, funcdef_no=0,
decl_uid=1935, cgraph_uid=1, symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
rhbz-1800289.c: In function ‘create_command_list’:
rhbz-1800289.c:10:3: warning: writing 26 bytes into a region of size 16
[-Wstringop-overflow=]
   10 |   __builtin_memcpy (, , sizeof b);
  |   ^~~
rhbz-1800289.c:4:3: note: at offset 8 to object ‘a’ with size 24 declared here
4 | } a;
  |   ^
create_command_list ()
{
   [local count: 1073741824]:
  MEM  [(char * {ref-all})] = 0B;
  MEM  [(char * {ref-all}) + 8B] = "Enable all debug messages";
  MEM  [(char * {ref-all}) + 16B] = 0B;
  return;

}

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

[rafael at espindo dot la]

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

--- Comment #15 from Rafael Avila de Espindola  ---
In gcc 9 it is pretty easy to avoid this warning by adding an assert or
builtin_unreachable and we have done that in seastar.

Unfortunately the warning still shows up with gcc 8. Is there a known way to
work around this warning with gcc 8 or should we should disable the warning?

[Bug fortran/93827] fails to initialize logical variable

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |INVALID

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Unlike C the initialisation of a local variable at declaration only occurs once
on the first entry to the subroutine.

See http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html see the section on locally
initialised variables.

[Bug target/93828] New: [10 Regression] incorrect shufps instruction emitted for -march=k8

[kretz at kde dot org]

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

Bug ID: 93828
   Summary: [10 Regression] incorrect shufps instruction emitted
for -march=k8
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---
Target: x86_64-*-*

Test case (https://godbolt.org/z/ramAe3):

using float2 [[gnu::vector_size(8)]] = float;
using int2 [[gnu::vector_size(8)]] = int;
float2 y = {2, 2};

int main() {
  const auto k = y == float2{2, 2};
  if (k[1] == 0)
__builtin_abort();
  const auto a = k & int2{2, 2};
  return a[0] - 2;
}

Compile with `-O2 -march=k8`. The resulting instruction sequence uses:
  movlps xmm0, QWORD PTR y[rip]
  shufps xmm1, xmm0, 0xe5
to place y[0] in xmm0[0] and y[1] in xmm1[0]. The latter is missing a `movaps
xmm1, xmm0` to work correctly, though. Most/all other -march flags load
individual floats (using movss) from y.

[Bug fortran/93827] New: fails to initialize logical variable

[zmth at yahoo dot com]

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

Bug ID: 93827
   Summary: fails to initialize logical variable
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmth at yahoo dot com
  Target Milestone: ---

in certain callings of the subroutine the determinant was being returned with
the wrong sign because the logical variable was not being initialized with
the official line

logical*1:: fl=.false.

nor did 

logical*1:: fl /.false./ 

but instead had to specifically do

fl=.false.

which should not have been necessary
NOT it committed the error sometimes whether this was in a module and
called or whether the subroutine was in the same program as the
calling routine in main,not included below because it did same
error on various calling routines but not all,
eg in a file he2.f03 for example

gfortran -O3 -ffast-math he2.f03
gfortran -g -fbacktrace -fcheck=all -Wall -O3 -ffast-math he2.f03

using either of these command lines got the error sometimes
and NO warnings and NO errors reported from gfortran neither at
compile nor runtime  - NO errors reported from gfortran


subroutine det(n,aa,dt)
real*8 aa(n,n),dt,rm,tmp(n)
integer m(2)
logical*1:: fl=.false.  ! did not work nor did   /.false./ 
! fl=.false. !but had to do this
dt=1
do i=1,n-1
m=maxloc(abs(aa(i:,i:)))
rm=aa(i+m(1)-1,i+m(2)-1)
dt=dt*rm
if(m(1).ne.1)then
fl=.not.fl
tmp(i:)=aa(i,i:)
aa(i,i:)=aa(i+m(1)-1,i:)
aa(i+m(1)-1,i:)=tmp(i:)
endif
if(m(2).ne.1)then
fl=.not.fl
tmp(i:)=aa(i:,i)
aa(i:,i)=aa(i:,i+m(2)-1)
aa(i:,i+m(2)-1)=tmp(i:)
endif

do j=i+1,n
aa(j,i+1:)=aa(j,i+1:)-aa(j,i)*aa(i,i+1:)/rm
enddo
enddo!i
dt=dt*aa(n,n)
if(fl)then;dt=-dt;endif
end
--
reference

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/tdm-gcc-32/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.8.2-mingw/configure --host=x86_64-w64-mingw32
--build=x86_64-unkno
wn-linux-gnu --target=x86_64-w64-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/nat
ive/x86_64/gcc/4.8.2
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_64/gcc/
4.8.2 --with-gcc --with-gnu-ld --with-gnu-as
--with-gmp=/home/gfortran/gcc-home/binary/mingw
32/native/x86_64/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpfr -
-with-mpc=/home/gfortran/gcc-home/binary/mingw32/native/x86_64/mpc
--with-cloog=/home/gfortr
an/gcc-home/binary/mingw32/native/x86_64/cloog
--with-isl=/home/gfortran/gcc-home/binary/min
gw32/native/x86_64/isl --enable-cloog-backend=isl
--enable-targets=i686-w64-mingw32,x86_64-w
64-mingw32 --enable-lto --enable-languages=c,c++,fortran --enable-threads=win32
--enable-sta
tic --enable-shared=lto-plugin --enable-plugins --enable-ld=yes
--enable-libquadmath --enabl
e-libquadmath-support --enable-libgomp --disable-nls --disable-tls
--disable-win32-registry
Thread model: win32
gcc version 4.8.2 (GCC)

[Bug fortran/93825] [OpenACC] Implicit typing not honored – bogus type errors

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Created attachment 47877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47877=edit
Draft patch

The attached patch fixes the issue for "tile". (By doing what is done in
gfc_resolve_code for EXEC_DO.)

However: I do not understand why it is needed for 'tile' but not for
'collapse'. – At a glance, collapse vs. tile shouldn't make a difference but it
does. (Collapse exists  OpenMP; the patch handled is for both OpenACC and
OpenMP.)

[Bug fortran/93552] [8/9/10 Regression][OpenACC] ICE in gfc_trans_exit, at fortran/trans-stmt.c:6110 since r7-6598-g02889d23ee3b0285

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #2)
> As PR 93825 shows,

Wrong PR – it is related, but the one relevant for this discussion is PR 93826.

[Bug fortran/93552] [8/9/10 Regression][OpenACC] ICE in gfc_trans_exit, at fortran/trans-stmt.c:6110 since r7-6598-g02889d23ee3b0285

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||openacc
 CC||burnus at gcc dot gnu.org
Summary|[8/9/10 Regression] ICE in  |[8/9/10
   |gfc_trans_exit, at  |Regression][OpenACC] ICE in
   |fortran/trans-stmt.c:6110   |gfc_trans_exit, at
   |since   |fortran/trans-stmt.c:6110
   |r7-6598-g02889d23ee3b0285   |since
   ||r7-6598-g02889d23ee3b0285

--- Comment #2 from Tobias Burnus  ---
If one places the "exit" into the outer loop (or jumps via label to the
outermost loop), the compiler complains:
  Error: EXIT statement at (1) terminating !$ACC LOOP loop

As PR 93825 shows, the current code gen in trans-openmp.c's gfc_trans_omp_do
creates a pragma, then a bunch of "for" loops and then translates the code of
the innermost for loop.

For "collapse" any attempt of doing "cycle" to any but the innermost loop – or
any "exit" is rejected.

For "tile", the code handling is the same but "cycle" to outer loops or "exit"
(except exit with label to the outermost loop) is accepted – but then gives an
ICE.

The question is whether "exit" / non-innermost-"cycle" is permitted according
to the OpenACC spec with the "tile" clause. If so, the whole code in
gfc_trans_omp_do needs to be restructured.

[Bug fortran/93826] New: [OpenMP][OpenACC] Collapsed loop – code silently ignored

[burnus at gcc dot gnu.org]

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

Bug ID: 93826
   Summary: [OpenMP][OpenACC] Collapsed loop – code silently
ignored
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Found when looking at PR 93552.

The code gfc_trans_omp_do for collapes (and for OpenACC's 'tile') creates a
single #pragma followed by a bunch of "for ()" statements, matching the
specified number of collapse/tile.

It then translates the body of the inner loop in one go.

RESULT: Code outside the innermost loop is silently ignored.

EXPECTED: I have still to digest the OpenMP/OpenACC spec, but I expect either
an error (if invalid) or that the code does not get ignored (if valid).

program p
   integer :: i, j, k
   real :: x
   !$acc parallel loop collapse(3)
   !$omp parallel do collapse(3)
   do i = 1, 8
  do j = 1, 8
do k = 1, 8
end do
x = 5  ! <<< not translated but also not an error message
  end do
   end do
end

[Bug fortran/93825] New: [OpenACC] Implicit typing not honored – bogus type errors

[burnus at gcc dot gnu.org]

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

Bug ID: 93825
   Summary: [OpenACC] Implicit typing not honored – bogus type
errors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

In following code, i and j are implicitly typed and of type integer.
Nonetheless, the error is shown:

Error: !$ACC LOOP iteration variable must be of type integer at (1)

program p
   !$acc parallel loop tile(2,2)
   do i = 1, 8
  do j = 1, 8
  end do
   end do
end

[Bug rtl-optimization/93730] [8/9/10 Regression] ICE in make_decl_rtl, at varasm.c:1375

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
I think VLA initialization should be rejected in C++ just as it is in C.

The mangling wasn't specified the last time I checked so unless there has been
some informal consensus on how to do it changing it for the member pointers
shouldn't be a big problem.  (They might also end up taking place as a result
of the patch for pr90938 if the code gets moved from reshape_init_array_1 to
process_init_constructor_array as Jason suggested.)

In any case, please post your patch (for bug 58646) for consideration to
gcc-patches.

[Bug c++/93824] New: -Wredundant-tags false positives

[sbergman at redhat dot com]

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

Bug ID: 93824
   Summary: -Wredundant-tags false positives
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

With recent GCC trunk and

> $ cat incA.h
> struct S {};

> $ cat incB.h
> void f(struct S *);

> $ cat test1.cc
> #include "incA.h"
> #include "incB.h"

> $ cat test2.cc
> #include "incB.h"

> $ g++ -Wredundant-tags -fsyntax-only test1.cc
> In file included from test1.cc:2:
> incB.h:1:8: warning: redundant class-key ‘struct’ in reference to ‘struct S’ 
> [-Wredundant-tags]
> 1 | void f(struct S *);
>   |^~
>   |--

> $ g++ -Wredundant-tags -fsyntax-only test2.cc
> In file included from test2.cc:1:
> incB.h:1:8: warning: redundant class-key ‘struct’ in reference to ‘struct S’ 
> [-Wredundant-tags]
> 1 | void f(struct S *);
>   |^~
>   |--

there should IMO not be warnings when compiling neither test1.ccc nor test2.cc.
 test2.cc clearly is a false positive, and arguably test1.cc is as well, albeit
a little more subtly.

[Bug libgomp/93591] Bad number of threads and place management on Power-9 (with OpenBLAS)

[jeromerichard111 at msn dot com]

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

--- Comment #1 from Jérôme Richard  ---
It is worth noting that if OMP_DISPLAY_AFFINITY is set to TRUE, the runtime do
not print the affinity when the issue occur (and vice-versa: the value is
printed when no problem happend).
A deeper analysis shows that it seems to comes from the function
gomp_team_start not being called (in libgomp/team.c), itself due to
GOMP_parallel not being called...

[Bug fortran/93554] [8/9/10 Regression] ICE in expand_oacc_for, at omp-expand.c:6035 since r6-4364-ge4834818d22f5c66

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
Draft patch, lightly tested:

--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -6029,10 +6029,7 @@ expand_oacc_for (struct omp_region *region, struct
omp_for_data *fd)
   basic_block cont_bb = region->cont; /* BB ending in OMP_CONTINUE  */
   basic_block bottom_bb = NULL;

-  /* entry_bb has two sucessors; the branch edge is to the exit
- block,  fallthrough edge to body.  */
-  gcc_assert (EDGE_COUNT (entry_bb->succs) == 2
- && BRANCH_EDGE (entry_bb)->dest == exit_bb);
+  gcc_assert (EDGE_COUNT (entry_bb->succs) == 2);

   /* If cont_bb non-NULL, it has 2 successors.  The branch successor is
  body_bb, or to a block whose only successor is the body_bb.  Its
@@ -6043,7 +6040,7 @@ expand_oacc_for (struct omp_region *region, struct
omp_for_data *fd)
   basic_block body_bb = FALLTHRU_EDGE (entry_bb)->dest;
   basic_block bed = BRANCH_EDGE (cont_bb)->dest;

-  gcc_assert (FALLTHRU_EDGE (cont_bb)->dest == exit_bb);
+  gcc_assert (EDGE_COUNT (cont_bb->succs) == 2);
   gcc_assert (bed == body_bb || single_succ_edge (bed)->dest == body_bb);
 }
   else

[Bug ipa/93823] [10 Regression] ICE: in find_more_scalar_values_for_callers_subset, at ipa-cp.c:4709 due to -fipa-cp

[zsojka at seznam dot cz]

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

--- Comment #3 from Zdenek Sojka  ---
(In reply to fxue from comment #2)
> Duplicate of pr93707

Sorry about the dup, I searched for
"find_more_scalar_values_for_callers_subset" in Summary only; search in Comment
used to be slow (but it looks fast nowadays).

[Bug fortran/93554] [8/9/10 Regression] ICE in expand_oacc_for, at omp-expand.c:6035 since r6-4364-ge4834818d22f5c66

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
The analogous OpenMP variant [omp target / omp do private(x)] works.

The problem seems to be that "private(x)" implies that the data is device
private and, hence, it is finalized after the loop and before returning to the
host. – But the OpenACC code expects that directly after the loop the "omp
return" (internal) pragma comes.

* * *

The code flow is:
  expand_omp_for
-> t  (for OpenACC)
-> expand_omp_for_static_nochunk (for OpenMP)
i.e. the input in those functions is the same.

 * * *

One has:
debug_bb(region->entry):
   :
  #pragma omp for private(i) private(x)
  for (i = 0; i <= 31; i = i + 1)

debug_bb(region->cont):
   :
  x.a = 1;
  #pragma omp continue (i, i)

debug_bb(region->exit):
   :
  #pragma omp return

HOWEVER:
  BRANCH_EDGE (entry_bb)->dest
is the code after the region->exit (autodeallocation of the allocatable
component x%b); namely "debug_bb((*region->entry->succs)[1]->dest)" 
[with …[0]->flag == 1 == EDGE_FALLTHRU]:
  D.3967 = x.b.data;
  if (D.3967 != 0B)
goto ; [INV]
  else
goto ; [INV]

Hence, the second condition of the assert fails for OpenACC:
  gcc_assert (EDGE_COUNT (entry_bb->succs) == 2
  && BRANCH_EDGE (entry_bb)->dest == exit_bb);
and likewise the later
  gcc_assert (FALLTHRU_EDGE (cont_bb)->dest == exit_bb);

In OpenMP, the result is the same but there one operates checks:
  BRANCH_EDGE (entry_bb)->dest == FALLTHRU_EDGE (cont_bb)->dest
[OpenMP: "bool broken_loop = region->cont == NULL", which is similar to the
handling of cont == NULL in the OpenACC code.]

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9

[olegendo at gcc dot gnu.org]

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

--- Comment #10 from Oleg Endo  ---
I've just tried to compile the preprocessed string.i with the current gcc 9
branch sh-elf cross compiler with the following options:

sh-elf-gcc -c -mieee -g -O2  -fstack-protector-strong -Wformat
-Werror=format-security -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector
-fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard
-DRUBY_EXPORT -Wdate-time -D_FORTIFY_SOURCE=2 -save-temps 

but the resulting string.s is quite different from the one in #comment 7.

It's difficult to see what's going on there.  Can you try building this without
the stackprotector options and see if still crashes in the same way?

[Bug ipa/93823] [10 Regression] ICE: in find_more_scalar_values_for_callers_subset, at ipa-cp.c:4709 due to -fipa-cp

[fxue at gcc dot gnu.org]

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

--- Comment #2 from fxue at gcc dot gnu.org ---
Duplicate of pr93707

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[vincent-gcc at vinc17 dot net]

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

--- Comment #7 from Vincent Lefèvre  ---
(In reply to rguent...@suse.de from comment #5)
> From below I implicitely assume you say that "1. + x != 1." -> "x != 0."
> isn't "rearranging at the source level".

No, it depends on how you do that. If in the source you have

  int c = 1. + x != 1.;

then you might choose to transform this to

  int c = x != 0.;

under -funsafe-math-optimizations (though this transformation is currently not
documented, see below). What the optimizer MUST NOT do is to replace an
occurrence of c in the code by the expression used to compute it, as doing such
a thing is likely to yield major inconsistencies (this might be acceptable if
the value of c is read only once, but IMHO, even this case should not be
optimized as this could be too dangerous).

> Note our documentation
> on -funsafe-math-optimizations is quite vague and I'd argue that
> "rearranging at the source level" is covered by -fassociative-math
> instead.

BTW, strictly speaking, transforming "1. + x != 1." to "x != 0." does not just
use the associativity, but also the "additive property" or "cancellation
property". In math, if "a = b", then "a + x = b + x". However, for an arbitrary
operation, the converse is not necessarily true, even though the operation may
be associative. That is, if "a != b", then "a + x != b + x" is not necessarily
true. Having the cancellation property under -funsafe-math-optimizations might
be OK (here, this is similar to assuming associativity, but possibly stronger,
so that it could be preferable to have a separate option for that).

But I think that this is not directly related to this bug.

The gcc(1) man page says:

-fassociative-math
Allow re-association of operands in series of floating-point
operations.  [...]

As I read it, this is possible only inside an expression, otherwise it should
not be worded like that. What the optimizer does here is to apply
re-association of operands beyond expressions, changing the allowed behaviors
to an unexpected one; thus, IMHO, the "as-if rule" is broken by the optimizer
here.

> It's not clear how to classify the above specific transform though.
> There's -ffp-contract which also enables removing of rounding steps.
> So the classification as "unsafe" is probably correct (and vague).

Note that the conditions under FP contraction are rather strict. A consequence
of what -funsafe-math-optimizations can do is to increase the error of the
considered expression, which is not allowed by FP contraction.

[Bug libstdc++/92546] [10 Regression] Large increase in preprocessed file sizes in C++2a mode

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Another way to reduce things would be to move tuple_size and tuple_element from
 to a new  header, so that e.g.  doesn't need
the whole of .

[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf

[doko at ubuntu dot com]

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

--- Comment #9 from Matthias Klose  ---
that works again with the gcc-8 branch from 20200218.  LTO link times however
are about three hours.

[Bug tree-optimization/93767] [8/9/10 Regression] wrong code at -O3 on x86_64-linux-gnu since r8-6064

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:f91aa3e6cb808f8dfc6b45fa135f7583a7549161

commit r10-6732-gf91aa3e6cb808f8dfc6b45fa135f7583a7549161
Author: Richard Sandiford 
Date:   Tue Feb 18 18:06:32 2020 +

vect: Fix offset calculation for -ve strides [PR93767]

This PR is a regression caused by r256644, which added support for alias
checks involving variable strides.  One of the changes in that commit
was to split the access size out of the segment length.  The PR shows
that I hadn't done that correctly for the handling of negative strides
in vect_compile_time_alias.  The old code was:

  const_length_a = (-wi::to_poly_wide (segment_length_a)).force_uhwi
();
  offset_a = (offset_a + vect_get_scalar_dr_size (a)) - const_length_a;

where vect_get_scalar_dr_size (a) was cancelling out the subtraction
of the access size inherent in "- const_length_a".  Taking the access
size out of the segment length meant that the addition was no longer
needed/correct.

2020-02-19  Richard Sandiford  

gcc/
PR tree-optimization/93767
* tree-vect-data-refs.c (vect_compile_time_alias): Remove the
access-size bias from the offset calculations for negative strides.

gcc/testsuite/
PR tree-optimization/93767
* gcc.dg/vect/pr93767.c: New test.

[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Richard Biener from comment #7)
> (In reply to Richard Biener from comment #3)
> > I'm checking head with our GCC 8 build on armv7 which we build with
> > --with-arch=armv7-a --with-tune=cortex-a15 --with-float=hard
> > notably w/o --with-mode=thumb
> 
> That worked fine here with 9eba9635f653291804ecb832e

Oh, but we're not doing profiledbootstrap on arm (only aarch64).

[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> I'm checking head with our GCC 8 build on armv7 which we build with
> --with-arch=armv7-a --with-tune=cortex-a15 --with-float=hard
> notably w/o --with-mode=thumb

That worked fine here with 9eba9635f653291804ecb832e

[Bug ipa/93823] [10 Regression] ICE: in find_more_scalar_values_for_callers_subset, at ipa-cp.c:4709 due to -fipa-cp

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-19
 CC||fxue at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-6540-ga0f6a8cb414b687f.

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[ch3root at openwall dot com]

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

--- Comment #6 from Alexander Cherepanov  ---
I agree that every separate optimization here is quite natural. At the same
time, the end result is quite unnatural.

The following is a look at the situation from an outsider POV.

-funsafe-math-optimizations makes floating-point values unpredictable and
unstable. That's fine. And gcc is ready for this. For example, it doesn't
propagate conditional equivalence for them (signed zeros would complicate it
but -funsafe-math-optimizations enables -fno-signed-zeros).

OTOH gcc assumes that integers are stable. And conditional equivalence
propagation is fine for them.

Nonsense results start to appear when the boundary between FPs and integers
blurs. So an evident solution would be to stop replacing integers by FP
computations. E.g., in this particular case, don't substitute FP equality in
place of non-first instances of `a`, all instances of `a` should use the result
of the same FP computation.

This approach will also solve some problems with x87 (pr85957, pr93681) and
with -mpc64 (pr93682). It will not make them conformant but at least it will
fix some egregious issues.

[Bug c++/93821] Define __cplusplus to 202002L in C++20

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Don't we up __cplusplus only when we support all language features?

[Bug c++/93822] [8/9/10 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|sanitizer   |c++

--- Comment #1 from Richard Biener  ---
Simply another case of missed VLA DECL_EXPRs.  C++ FE issue (or a sanitizer C++
FE issue)

[Bug ipa/93823] [10 Regression] ICE: in find_more_scalar_values_for_callers_subset, at ipa-cp.c:4709 due to -fipa-cp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |10.0

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Wed, 19 Feb 2020, vincent-gcc at vinc17 dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
> 
> --- Comment #4 from Vincent Lefèvre  ---
> (In reply to Richard Biener from comment #3)
> > with -funsafe-math-optimizations you get the 1 + x != 1 -> x != 0
> > optimization which is unsafe because a rounding step is removed.
> > But you asked for that.  So no "wrong-code" here, just another case
> > of "instabilities" or how you call that via conditional equivalence
> > propagation.
> 
> I disagree. -funsafe-math-optimizations just means that floating-point
> expressions can be rearranged at the source level according to math rules
> (valid in the real numbers), thus changing how rounding is done.

>From below I implicitely assume you say that "1. + x != 1." -> "x != 0."
isn't "rearranging at the source level".  Note our documentation
on -funsafe-math-optimizations is quite vague and I'd argue that
"rearranging at the source level" is covered by -fassociative-math
instead.

It's not clear how to classify the above specific transform though.
There's -ffp-contract which also enables removing of rounding steps.
So the classification as "unsafe" is probably correct (and vague).

Even only associating differently, like if you'd have 1 + x + x != 1
and re-arrange it as 1 + (x + x) != 1 may change the outcome of
the comparison (and the outcome of a comparison is an integer).

So my answer to you would be - if you don't like them, don't use
any of the special math "optimization" flags.

[Bug c++/93821] Define __cplusplus to 202002L in C++20

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Romain Geissler from comment #2)
> You may have misunderstood my intentions here.

Yes, looks like I did. The way you phrased it (particularly "you need to use
this assertions so that there is no error") read like you were reporting it as
a bug. Apologies if I misunderstood.

> It's definitely not the first time you complain I open bugs which aren't
> bugs. However I see other gcc contributors use this ticket system to also
> track things like "change requests", "feature requests", or "enhancement". I
> also know in that case the change should be trivial enough so that I could
> actually submit the patch myself, however I am still trying to find a legal
> agreement that would suit both my employer and the FSF (wrt copyright
> assignment).

That would be great :-)

> So what do you suggest I do in that case ? Open a bug ? Start a
> discussion on the gcc mailing list ?

Personally, I'd use the mailing list for something this small.

I'm not really fond of using bugzilla to track unimplemented features (they're
not bugs, and there's no need to request an "enhancement" for something that's
required for standard conformance anyway). But as you say, other people do use
bugzilla that way.

[Bug ipa/93823] New: [10 Regression] ICE: in find_more_scalar_values_for_callers_subset, at ipa-cp.c:4709 due to -fipa-cp

[zsojka at seznam dot cz]

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

Bug ID: 93823
   Summary: [10 Regression] ICE: in
find_more_scalar_values_for_callers_subset, at
ipa-cp.c:4709 due to -fipa-cp
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 47876
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47876=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O3 testcase.c -Wno-psabi
during IPA pass: cp
testcase.c:21:1: internal compiler error: in
find_more_scalar_values_for_callers_subset, at ipa-cp.c:4709
   21 | }
  | ^
0x998120 find_more_scalar_values_for_callers_subset
/repo/gcc-trunk/gcc/ipa-cp.c:4709
0x1a0fc87 decide_about_value
/repo/gcc-trunk/gcc/ipa-cp.c:5490
0x1a1159c decide_whether_version_node
/repo/gcc-trunk/gcc/ipa-cp.c:5537
0x1a1159c ipcp_decision_stage
/repo/gcc-trunk/gcc/ipa-cp.c:5718
0x1a1159c ipcp_driver
/repo/gcc-trunk/gcc/ipa-cp.c:5901
0x1a1159c execute
/repo/gcc-trunk/gcc/ipa-cp.c:5992
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20200219091344-g8d1a1cb1b81-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20200219091344-g8d1a1cb1b81-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200219 (experimental) (GCC)

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Richard Biener from comment #3)
> with -funsafe-math-optimizations you get the 1 + x != 1 -> x != 0
> optimization which is unsafe because a rounding step is removed.
> But you asked for that.  So no "wrong-code" here, just another case
> of "instabilities" or how you call that via conditional equivalence
> propagation.

I disagree. -funsafe-math-optimizations just means that floating-point
expressions can be rearranged at the source level according to math rules
(valid in the real numbers), thus changing how rounding is done. From that, an
integer variable will always be stable (and IMHO, this should also be the case
of a floating-point variable to avoid some consistency issues, perhaps unless
you design a specific model with multivalued FP variables that would change
them to a stable value once the variable is used to obtain a non-FP value).

This option does not mean that the optimizer may assume that math rules are
valid on floating point. Otherwise one can prove that 1 == 0 (as seen above),
and then it is valid to transform the program to

  int main () { return 0; }

Indeed, you can assume an "if (1)" around the main code, and since 1 == 0, you
can transform it to "if (0)", and since this is always false, you can remove
the code entirely. This makes no sense!

[Bug c++/93821] Define __cplusplus to 202002L in C++20

[romain.geissler at amadeus dot com]

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

--- Comment #2 from Romain Geissler  ---
You may have misunderstood my intentions here. I was just trying to suggest a
change which I think is better for the consistency with the standard and with
clang which just implemented this change.

So yes I agree with you it's definitely not a bug, and no I am not writing such
__cplusplus == X checks for real, I know I should use __cplusplus >= X or even
better use SD-6 macros.

It's definitely not the first time you complain I open bugs which aren't bugs.
However I see other gcc contributors use this ticket system to also track
things like "change requests", "feature requests", or "enhancement". I also
know in that case the change should be trivial enough so that I could actually
submit the patch myself, however I am still trying to find a legal agreement
that would suit both my employer and the FSF (wrt copyright assignment). So
what do you suggest I do in that case ? Open a bug ? Start a discussion on the
gcc mailing list ?

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc 8 and gcc 9 branches.

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:db0e1e9948434352455db1e729383272d79105e8

commit r8-10037-gdb0e1e9948434352455db1e729383272d79105e8
Author: Mark Eggleston 
Date:   Wed Feb 19 10:30:38 2020 +

[fortran] ICE assign character pointer to non target PR93714

An ICE occurred if an attempt was made to assign a pointer to a
character variable that has an length incorrectly specified using
a real constant and does not have the target attribute.

Backported from mainline
2020-02-18  Mark Eggleston  

PR fortran/93714
* expr.c (gfc_check_pointer_assign): Move check for
matching character length to after checking the lvalue
attributes for target or pointer.

PR fortran/93714
* gfortran.dg/char_pointer_assign_6.f90: Look for no target
message instead of length mismatch.
* gfortran.dg/pr93714_1.f90
* gfortran.dg/pr93714_2.f90

[Bug tree-optimization/93776] [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2326

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:51faf07cef9293af544bfacc7d0b320ab90d7d60

commit r10-6723-g51faf07cef9293af544bfacc7d0b320ab90d7d60
Author: Martin Jambor 
Date:   Wed Feb 19 11:13:52 2020 +0100

sra: Do not create zero sized accesses  (PR 93776)

SRA can get a bit confused with zero-sized accesses like the one in
the testcase.  Since there is nothing in the access, nothing is
scalarized, but we can get order of the structures wrong, which the
verifier is not happy about.

Fixed by simply ignoring such accesses.

2020-02-19  Martin Jambor  

PR tree-optimization/93776
* tree-sra.c (create_access): Do not create zero size accesses.
(get_access_for_expr): Do not search for zero sized accesses.

testsuite/
* gcc.dg/tree-ssa/pr93776.c: New test.

[Bug tree-optimization/93776] [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2326

[jamborm at gcc dot gnu.org]

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

Bug 93667 Summary: [10 regression] ICE in esra with nested 
[[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667

   What|Removed |Added

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

[Bug c++/93711] ICE: [[no_unique_address] when constructing via template helper

[jamborm at gcc dot gnu.org]

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

Bug 93667 Summary: [10 regression] ICE in esra with nested 
[[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667

   What|Removed |Added

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

[Bug tree-optimization/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Jambor  ---
Fixed.

[Bug tree-optimization/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:665c5bad168ab63629b29ed2ce08ed042c088dc2

commit r10-6722-g665c5bad168ab63629b29ed2ce08ed042c088dc2
Author: Martin Jambor 
Date:   Wed Feb 19 11:08:40 2020 +0100

sra: Avoid totally scalarizing overallping field_decls (PR 93667)

[[no_unique_address]] C++ attribute can cause two fields of a
RECORD_TYPE overlap, which currently confuses the totally scalarizing
code into creating invalid access tree.  For GCC 10, I'd like to
simply disable total scalarization of types where this happens.

For GCC 11 I'll write down a TODO item to enable total scalarization
of cases like this where the problematic fields are basically empty -
despite having a non-zero size - i.e. when they are just RECORD_TYPEs
without any data fields.

2020-02-19  Martin Jambor  

gcc/

PR tree-optimization/93667
* tree-sra.c (scalarizable_type_p): Return false if record fields
do not follow wach other.

gcc/testsuite/

PR tree-optimization/93667
* g++.dg/tree-ssa/pr93667.C: New test.

[Bug c++/93821] Define __cplusplus to 202002L in C++20

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Romain Geissler from comment #0)
> A few hours ago the clang folks did add explicit support for the flag
> -std=c++20, and not only did they change that, they also changed the value
> of __cplusplus to 202002L. I think in gcc this __cplusplus value shall be
> updated too.

The fact GCC didn't update the macro yet doesn't seem like a bug to me.


> Right now on Compiler Explorer you need to use this assertions so that there
> is no error on clang/gcc trunk:
> 
> #ifndef __clang__
> static_assert(__cplusplus == 201709L);
> #else
> static_assert(__cplusplus == 202002L);
> #endif

I don't understand this claim, why do you "need to use" that?

Why can't you test for > C++17 i.e. #if __cplusplus > 201703L ?

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|wrong-code  |

--- Comment #3 from Richard Biener  ---
Well, it's really down to valid simplifications with -ffast-math and
conditional equivalences again.  From

if (one == a) {
...
if (x == 1) {
...
if (one == 0)

we're turning the last compare to if (a == 0) and that "simplifies" from

(1 + opaque(0x1p-60) == x) == 0

again via conditional equivalences x == 1

(1 + opaque(0x1p-60) != 1)

to

opaque(0x1p-60) != 0

at -O1 printing

one = 1
one = 1

where we still print a and at -O2

one = 1
one = 0

where we figured to constant-prop the one == 0 constant before substituting
the one == a equivalence in evrp.

I think the patch enabled the x == 1 conditional equivalence to be used.

with -funsafe-math-optimizations you get the 1 + x != 1 -> x != 0
optimization which is unsafe because a rounding step is removed.
But you asked for that.  So no "wrong-code" here, just another case
of "instabilities" or how you call that via conditional equivalence
propagation.

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:44ea6508f1009086018d0db4347a14b9c4eec2c0

commit r9-8256-g44ea6508f1009086018d0db4347a14b9c4eec2c0
Author: Mark Eggleston 
Date:   Wed Feb 19 09:36:42 2020 +

[Fortran] ICE assign character pointer to non target PR93714

An ICE occurred if an attempt was made to assign a pointer to a
character variable that has an length incorrectly specified using
a real constant and does not have the target attribute.

Backported from mainline
2020-02-18  Mark Eggleston  

PR fortran/93714
* expr.c (gfc_check_pointer_assign): Move check for
matching character length to after checking the lvalue
attributes for target or pointer.

PR fortran/93714
* gfortran.dg/char_pointer_assign_6.f90: Look for no target
message instead of length mismatch.
* gfortran.dg/pr93714_1.f90
* gfortran.dg/pr93714_2.f90

[Bug sanitizer/93822] [8/9/10 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-19
Version|9.0 |10.0
   Target Milestone|--- |8.4
 Ever confirmed|0   |1

[Bug sanitizer/93822] New: [8/9/10 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[marxin at gcc dot gnu.org]

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

Bug ID: 93822
   Summary: [8/9/10 Regression] ICE in make_ssa_name_fn, at
tree-ssanames.c:279 since r7-536-g381cdae49785fc4b
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

I know the options are strange, but:

g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-vla1.C
-fnon-call-exceptions -Ofast -fsanitize=vla-bound
during IPA pass: inline
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-vla1.C: In
function ‘int main()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp1y/lambda-vla1.C:10:42:
internal compiler error: in make_ssa_name_fn, at tree-ssanames.c:279
   10 |   return [](auto x){ return buf[x]; }(t);
  |  ^~~
0x8253a3 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
/home/marxin/Programming/gcc/gcc/tree-ssanames.c:279
0x110da84 make_ssa_name
/home/marxin/Programming/gcc/gcc/tree-ssanames.h:115
0x110da84 remap_ssa_name
/home/marxin/Programming/gcc/gcc/tree-inline.c:258
0x1110c3f copy_tree_body_r(tree_node**, int*, void*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:1251
0x1363183 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11954
0x1363a48 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:12284
0x110bf1e remap_type_1
/home/marxin/Programming/gcc/gcc/tree-inline.c:618
0x110c359 remap_type(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:735
0x110bff1 remap_type_1
/home/marxin/Programming/gcc/gcc/tree-inline.c:555
0x110c359 remap_type(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:735
0x110b934 remap_type_1
/home/marxin/Programming/gcc/gcc/tree-inline.c:460
0x110c359 remap_type(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:735
0x11108f8 copy_tree_body_r(tree_node**, int*, void*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:1437
0x1363183 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11954
0x110cf75 remap_decls
/home/marxin/Programming/gcc/gcc/tree-inline.c:811
0x110eafa remap_block
/home/marxin/Programming/gcc/gcc/tree-inline.c:842
0x110eba5 remap_blocks
/home/marxin/Programming/gcc/gcc/tree-inline.c:864
0x1117f16 expand_call_inline
/home/marxin/Programming/gcc/gcc/tree-inline.c:4936
0x1118c79 gimple_expand_calls_inline
/home/marxin/Programming/gcc/gcc/tree-inline.c:5250
0x1118c79 optimize_inline_calls(tree_node*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:5423
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/93821] Define __cplusplus to 202002L in C++20

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-19
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Version|unknown |10.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #9 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #8)
> One may want to see whether GCC 10 is affected or not.

Yes, I can confirm it affects GCC-10 as well.

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-19
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
> 
> __attribute__((noipa)) // imagine it in a separate TU
> static double opaque(double d) { return d; }

Putting the function into a separate file, I see it started with:
r6-2248-g612b9d1364bbefb7

Can you Richi take a look?