[Bug c++/96163] New: another ice in pass slp

[dcb314 at hotmail dot com]

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

Bug ID: 96163
   Summary: another ice in pass slp
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 48862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48862&action=edit
C++ source code

For the attached C++ source code with flag -O3, recent gcc trunk does this:

/home/dcb/gcc/results.20200630/bin/g++
/home/dcb/gcc/results.20200701/bin/g++
bug630.cc: In function ‘void cm()’:
bug630.cc:139:6: error: definition in block 2 follows the use
  139 | void cm() {
  |  ^~
for SSA_NAME: vect_cst__16 in statement:
vect__2.37_17 = _14 / vect_cst__16;
during GIMPLE pass: slp
bug630.cc:139:6: internal compiler error: verify_ssa failed
0x13fb41b verify_ssa(bool, bool)
../../trunk.git/gcc/tree-ssa.c:1208
0x108dbf5 execute_function_todo
../../trunk.git/gcc/passes.c:1992

Trunk dated 20200630 is fine, 20200701 not.

[Bug fortran/92913] Add argument-mismatch check for INTERFACE for non-module procedures in the same file

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
The first part has now been fixed with the fix for PR 27318,
r11-1814-gcc9a9229285a26ac12bc8de53237ce9c4d42f867 .

The second test case, where interfaces are checked vs. interfaces,

subroutine sub_1()
   interface
 subroutine bar(x)
   integer :: x
 end subroutine bar
   end interface
end subroutine sub_1

subroutine sub_2()
   interface
 subroutine bar()  ! arg mismatch
 end subroutine bar
   end interface
end subroutine sub_2

subroutine sub_3
   external bar
   integer bar  ! function vs. subroutine mismatch
end subroutine sub_3

is not yet reported.
~

[Bug fortran/96158] Symbols not emitted for module common variables

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
(In reply to kargl from comment #2)

> I won't comment on the questionable programming idiom of placing
> a common block in a module, which kind of defeats the niceties of
> a module.

If somebody wants to transition your code from using common blocks to
modules, that is a good way to proceed.   When all the direct usage
of the common block have been removed, you can then remove the
COMMON statement from the module.

[Bug c++/96164] New: Constraints and explicit template instantiation

[jaahans2 at gmail dot com]

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

Bug ID: 96164
   Summary: Constraints and explicit template instantiation
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaahans2 at gmail dot com
  Target Milestone: ---

The following code does not compile in all of gcc 10.1, msvc 19.24, and clang
10.0.0:

template 
struct A {
void g() requires (N == 3) {}
void f() requires (N == 3) { g(); }
};

template struct A<2>;

[Bug c++/96164] Constraints and explicit template instantiation

[jaahans2 at gmail dot com]

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

--- Comment #1 from kaba  ---
The error is "use of function 'void A::g() requires  N == 3 [with int N =
2]' with unsatisfied constraints"

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #5 from Thomas Koenig  ---
I see nothing in the standard which prohibits this, so ice-on-valid.

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
What we have here is, in gfc_check_externals0,

(gdb) call debug(def_sym->formal) 

|| symbol: '_formal_0'
  type spec : (INTEGER 4)
  attributes: (VARIABLE  ARTIFICIAL DUMMY)
|| symbol: '_formal_1'
  type spec : (REAL 4)
  attributes: (VARIABLE  ARTIFICIAL DUMMY)
(gdb) call debug(sym->formal)

|| symbol: 'set'  
  type spec : (INTEGER 4)
  attributes: (VARIABLE  DUMMY(IN))
|| symbol: 'xmin' 
  type spec : (REAL 4)
  attributes: (VARIABLE  DUMMY(OUT))

so the inferred argument list from the call does not match the
interface.  And, since the location is not set, we get an ICE
on top of it.

I think resolution should have found the interface in addition
to the EXTERNAL statement.

[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl

[iii at linux dot ibm.com]

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

--- Comment #12 from Ilya Leoshkevich  ---
I managed to bootstrap and regtest upstream commit 6e41c27bf549 on gcc113 farm
machine.

Two questions:

- What is your system compiler version? For GCC 11, C++11 compiler is required:
https://gcc.gnu.org/install/prerequisites.html

- What exactly is "native aarch64 build" - is it simply building the compiler
on aarch64, or something else?

[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:505032d97d0593d5e9a6f51b107650e27fcf6b23

commit r11-2034-g505032d97d0593d5e9a6f51b107650e27fcf6b23
Author: Richard Sandiford 
Date:   Sat Jul 11 13:25:26 2020 +0100

value-range: Fix handling of POLY_INT_CST anti-ranges [PR96146]

The range infrastructure has code to decompose POLY_INT_CST ranges
to worst-case integer bounds.  However, it had the fundamental flaw
(obvious in hindsight) that it applied to anti-ranges too, meaning
that a range 2+2X would end up with a range of ~[2, +INF], i.e.
[-INF, 1].  This patch decays to varying in that case instead.

I'm still a bit uneasy about this.  ISTM that in terms of
generality:

  SSA_NAME => POLY_INT_CST => INTEGER_CST
   => ADDR_EXPR

I.e. an SSA_NAME could store a POLY_INT_CST and a POLY_INT_CST
could store an INTEGER_CST (before canonicalisation).  POLY_INT_CST
is also âas constant asâ ADDR_EXPR (well, OK, only some ADDR_EXPRs
are run-time rather than link-time constants, whereas all POLY_INT_CSTs
are, but still).  So it seems like we should at least be able to treat
POLY_INT_CST as symbolic.  On the other hand, I don't have any examples
in which that would be useful.

gcc/
PR tree-optimization/96146
* value-range.cc (value_range::set): Only decompose POLY_INT_CST
bounds to integers for VR_RANGE.  Decay to VR_VARYING for
anti-ranges
involving POLY_INT_CSTs.

gcc/testsuite/
PR tree-optimization/96146
* gcc.target/aarch64/sve/acle/general/pr96146.c: New test.

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Two things:  We should not warn about INTENT mismatches when
we artificially generate the prototypes, and we should set a
valid gfc_locus.

Both done with the attached patch.

diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index 69f9ca64c97..7768fdc25ca 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -5441,6 +5441,7 @@ check_externals_procedure (gfc_symbol *sym, locus *loc,
   gfc_current_ns = gsym->ns;

   gfc_get_formal_from_actual_arglist (new_sym, actual);
+  new_sym->declared_at = *loc;
   gfc_current_ns = save_ns;

   return 0;
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 0cc504f4e04..e51820918b8 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1343,7 +1343,8 @@ gfc_check_dummy_characteristics (gfc_symbol *s1,
gfc_symbol *s2,
 }

   /* Check INTENT.  */
-  if (s1->attr.intent != s2->attr.intent)
+  if (s1->attr.intent != s2->attr.intent && !s1->attr.artificial
+  && !s2->attr.artificial)
 {
   snprintf (errmsg, err_len, "INTENT mismatch in argument '%s'",
s1->name);

[Bug c/96165] New: internal compiler error during IPA pass: fnsummary

[jpalus+gcc at fastmail dot com]

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

Bug ID: 96165
   Summary: internal compiler error during IPA pass: fnsummary
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpalus+gcc at fastmail dot com
  Target Milestone: ---

Created attachment 48863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48863&action=edit
preprocessed source file

During Mesa compilation gcc segfaults with:


during IPA pass: fnsummary
../src/gallium/drivers/softpipe/sp_tex_sample.c: In function
‘sample_compare’:
../src/gallium/drivers/softpipe/sp_tex_sample.c:3862:1: internal compiler
error: Segmentation fault

Confirmed on both aarch64 and x86_64, note that issue occurs only if -O flag
was passed. Attached source file after preprocessor. Command to reproduce:

   gcc -O2 -c test.c -o test.o

[Bug c/96165] internal compiler error during IPA pass: fnsummary

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jpalus+gcc at fastmail dot com

--- Comment #8 from Jakub Jelinek  ---
*** Bug 96165 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/96166] New: [10/11 Regression] -O3/-ftree-slp-vectorize turns ROL into a mess

[nok.raven at gmail dot com]

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

Bug ID: 96166
   Summary: [10/11 Regression] -O3/-ftree-slp-vectorize turns ROL
into a mess
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

inline void swap(int &x, int &y)
{
  int tmp = x;
  x = y;
  y = tmp;
}

void bar(int (&x)[2])
{
  int y[2];
  __builtin_memcpy(&y, &x, sizeof x);
  swap(y[0], y[1]);
  __builtin_memcpy(&x, &y, sizeof x);
}


GCC 9 (-Os/O2/O3) produces:
  rolq $32, (%rdi)

GCC 10/trunk (-O3/-ftree-slp-vectorize) produces:
  movq (%rdi), %rax
  movd (%rdi), %xmm1
  sarq $32, %rax
  movq %rax, %xmm0
  punpckldq %xmm1, %xmm0
  movq %xmm0, (%rdi)


https://godbolt.org/z/5h3bW8

[Bug tree-optimization/96167] New: fails to detect ROL pattern in simple case, but succeeds when operand goes through memcpy

[nok.raven at gmail dot com]

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

Bug ID: 96167
   Summary: fails to detect ROL pattern in simple case, but
succeeds when operand goes through memcpy
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

inline void swap(int &x, int &y)
{
  int tmp = x;
  x = y;
  y = tmp;
}

void foo(int (&x)[2])
{
  swap(x[0], x[1]);
}

void bar(int (&x)[2])
{
  int y[2];
  __builtin_memcpy(&y, &x, sizeof x);
  swap(y[0], y[1]);
  __builtin_memcpy(&x, &y, sizeof x);
}


foo:
  movl (%rdi), %eax
  movl 4(%rdi), %edx
  movl %eax, 4(%rdi)
  movl %edx, (%rdi)
  ret

bar:
  rolq $32, (%rdi)
  ret

https://godbolt.org/z/Tcz7YG

[Bug bootstrap/96168] New: Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[gcczilla at cpellegrino dot de]

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

Bug ID: 96168
   Summary: Cannot bootstrap with Xcode 12 Beta on aarch64, macOS
11.0/Darwin, Apple Silicon
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcczilla at cpellegrino dot de
  Target Milestone: ---

Created attachment 48864
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48864&action=edit
Minimal shell script to reproduce the failure

Dear GCC team,


Thanks in advance for hearing me out even though I have near-zero experience in
C/C++ programming.

I assume you have heard of Apple’s plans to switch to aarch64 hardware for
Macs.
As a maintainer for the Homebrew package manager for macOS, I’m trying to
figure out how to build the most important FOSS projects on the new Apple
Silicon hardware.

IIRC, there have been successful third-party efforts to build older GCC
versions (such as GCC 4) for aarch64/Darwin already, targeting iOS. I have
learned that it’s completely unfeasible to forward-port those so I haven’t
tried that yet. But it shows that it’s not entirely unrealistic to build GCC 10
for aarch64/Darwin so I gave it a try.


Required information according to https://gcc.gnu.org/bugs/:

Exact version of gcc:
- I’m trying to build (bootstrap) gcc 10.1.0 from the source tarball.
- I’m running macOS 11.0 beta 1 on Apple Silicon.
- I’m using clang from Xcode 12 Beta 2.
- I have GNU make 3.81 installed, which was built from source using `brew
install make`.

System type:
- Hardware rented out from Apple
- Based on Apple Silicon, which currently is an A12z SoC based on the armv8.3
architecture.

Options when GCC was configured/built:
- See attached shell script.

Exact command line passed to the gcc program triggering the bug:
- Not applicable because I’m trying to build GCC.
- For the exact command lines passed to clang, configure and make, please see
the attached shell script.

Collection of source files for reproducing the bug, preferably a minimal set:
- See attached shell script.

Expected behavior:
- `make` builds GCC 10.1.0 and exits successfully.

Actual behavior:
- See description below.

Using information from the `gccint.info` file from GCC’s source tree, I managed
to patch a few things to the best of my knowledge. But now I’m stuck with
`make` failing at `config/aarch64/aarch64-builtins.c` as follows (edited for
clarity):

```
../../gcc/config/aarch64/aarch64-builtins.c:1225:3: error: expected expression
  AARCH64_INIT_MEMTAG_BUILTINS_DECL (IRG, irg, irg, fntype);
  ^
../../gcc/config/aarch64/aarch64-builtins.c:1221:5: note: expanded from macro
'AARCH64_INIT_MEMTAG_BUILTINS_DECL'
{T, CODE_FOR_##I};
^

[…]

149 warnings and 6 errors generated.
make[3]: *** [aarch64-builtins.o] Error 1
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
```

After `make` fails, I can immediately reproduce the exact same error messages
again by running:

```
cd gcc && clang++ -DIN_GCC -Wno-invalid-offsetof -Wno-ignored-attributes
-Wno-deprecated -Wno-macro-redefined -Wno-array-bounds -I. -I../../gcc
-I../../include -I../../gcc/../libcpp/include -o aarch64.o
../../gcc/config/aarch64/aarch64-builtins.c
```

I have attached a shell script showing my exact build steps. The shell script
is self-contained in the sense that it also applies the exact patches I made.
(The bug tracker seems to allow only a single attachment.)

The name of the AARCH64_INIT_MEMTAG_BUILTINS_DECL macro suggests that this is
about memory tagging. My test hardware is an Apple A12Z SoC, which is based on
armv8.3, and I know it definitely doesn’t support memory tagging, nor any other
armv8.5 feature. I aim to build for vanilla armv8 so I want to ignore any
armv8.3 or .5 features for now, such as memory tagging and pointer
authentication.

How do I tell `make` to ignore those features? What other things can I try for
`make` to get past `aarch64-builtins.c` and to help get GCC building?


Thank you very much for your time and help.

Regards and greetings from Darmstadt, Germany,  
Claudia

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[gcczilla at cpellegrino dot de]

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

--- Comment #1 from Claudia Pellegrino  ---
For those who want to run the shell script out of the box without any
modifications, the following requirements apply:

- You’re on Apple Silicon hardware.

- You’re running macOS 11.0 Beta 1 or newer.

- The gcc 10.1.0 source tarball has been extracted into a `gcc-10.1.0`
subdirectory of the current working directory.

- Homebrew is installed and works.

The Homebrew requirement is just for convenience; the attached shell script
installs gcc’s dependencies for you, including GNU make.
For in-detail guidance how to install Homebrew, consult https://brew.sh and
https://github.com/Homebrew/brew/issues/7857. Alternatively, install the
dependencies on your own but be aware that patches are needed for Apple
Silicon, which the Homebrew formulae already include.

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2020-07-11

--- Comment #2 from Andrew Pinski  ---
The abi support for aarch64 Darwin has not been added by anyone yet so this is
not going to work until someone does a full port.

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Someone will need to take the llvm port and then port the full ABI to gcc. This
is not just as simple of what you did.

[Bug middle-end/96136] [11 regression] ICE in reduce_to_bit_field_precision

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #1 from David Binderman  ---
I am also seeing this on an O3 bootstrap on Raspberry Pi 3+.

[Bug c++/96164] Constraints and explicit template instantiation

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-11
 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Confirmed.  [temp.explicit]/11 says:

An explicit instantiation that names a class template specialization is also an
explicit instantiation of the same kind (declaration or definition) of each of
its members (not including members inherited from base classes and members that
are templates) that has not been previously explicitly specialized in the
translation unit containing the explicit instantiation, ***provided that the
associated constraints, if any, of that member are satisfied by the template
arguments of the explicit instantiation*** ...

[Bug c++/96164] Constraints and explicit template instantiation

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Another testcase:

   template 
   struct A {
   void f() requires (N == 3) { static_assert(N == 3); }
   };

   template struct A<2>;

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[gcczilla at cpellegrino dot de]

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

--- Comment #4 from Claudia Pellegrino  ---
Thanks Andrew for the feedback. I wasn’t sure whether or not that has been done
already.

Even though I’m unable to do it on my own: if anyone wants to give it a try,
I’m happy to help out with testing at all stages.

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

https://gcc.gnu.org/g:90efb2512d40f0a59b063aa0416a6d28849ee424

commit r11-2036-g90efb2512d40f0a59b063aa0416a6d28849ee424
Author: Thomas Koenig 
Date:   Sat Jul 11 19:16:16 2020 +0200

Fix ICE on warning with new interface check.

In the test case, there was a warning about INTENT where an EXTERNAL
masked an interface in an outer scope, when the location of the
symbol was not set, leading to an ICE.

Two problems, two-part solution: It makes no sense to warn about
INTENT for artificially generated formal argument lists, and the
location should be set.

gcc/fortran/ChangeLog:

PR fortran/96073
* frontend-passes.c (check_externals_procedure):  Add locus
information for new_sym.
* interface.c (gfc_check_dummy_characteristics): Do not warn
about INTENT for artificially generated variables.

gcc/testsuite/ChangeLog:

PR fortran/96073
* gfortran.dg/interface_48.f90: New test.

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #9 from Thomas Koenig  ---
Fixed on master, closing.

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
... and thanks for the timely bug report!

[Bug fortran/96122] Segfault when using finalizer

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Blocks||37336

--- Comment #3 from Thomas Koenig  ---
(In reply to Andrew Benson from comment #2)
> (In reply to Dominique d'Humieres from comment #1)
> > Confirmed. For me it segfaults from GCC7 up to GCC11.
> 
> Interesting. This started occurring for me when I updated from GCC10.1 to
> 11. But, the code I posted is a reduced test case that I created - so maybe
> the original (non-reduced-test-case) code wasn't triggering this previously
> for some reason.

In Gcc 10.1, we did not call the finalizer for all required instances
(PR 94109).  This has been fixed for gcc11 and the upcoming 10.2 release.

It is likely that calling a (required?) finalizer again has led to
the segfault reappearing.

(Our finalizer handling is a mess, this and PDTs are really the
only two really buggy fields for F2003 conformance).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug 37336] [F03] Finish derived-type finalization

[Bug c++/96169] New: Don't provide internal lambda names in diagnostics?

[barry.revzin at gmail dot com]

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

Bug ID: 96169
   Summary: Don't provide internal lambda names in diagnostics?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider the erroneous program:

#include 
#include 

template  F>
void call_with_ints(F);

void foo() {
call_with_ints([](std::string const& s){
return s.size();
});
}

This (correctly) doesn't compile, but the tail end of the diagnostic we get is:

In file included from :1:
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/concepts: In instantiation
of 'void call_with_ints(F) [with F = foo()::]':
:10:6:   required from here
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/concepts:338:13:  
required for the satisfaction of 'invocable<_Fn, _Args ...>' [with _Fn =
foo::._anon_92; _Args = {int}]
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/concepts:342:13:  
required for the satisfaction of 'regular_invocable' [with F =
foo::._anon_92]
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/concepts:338:25: note: the
expression 'is_invocable_v<_Fn, _Args ...> [with _Fn = foo::._anon_92; _Args =
{int}]' evaluated to 'false'
  338 | concept invocable = is_invocable_v<_Fn, _Args...>;
  | ^
Compiler returned: 1

The lambda is initially introduced as "foo()::" but then
throughout the rest of the error is presented as "foo::._anon_92". The former
is a useful descriptor, especially in this specific example where the argument
the lambda takes is critical in understanding the error. The latter is not
useful - it doesn't really tell me anything. 

Could we use the former name in diagnostics, instead of the latter?

[Bug fortran/95998] gfc_typename use of static memory

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #1)
> Is static in C/C++ equivalent of SAVE in fortran (at least in the context of
> gfc_typename)?

Yes.

> If yes, AFAIU the code the odd access to gfc_typename use buffer2, while
> even ones
> use buffer1? Wouldn't it be simple (safer?) to use only buffer1?
> 
>   static char buffer[GFC_MAX_SYMBOL_LEN + 7];  /* 7 for "TYPE()" + '\0'.  */
>   gfc_typespec *ts1;
>   gfc_charlen_t length = 0;
> 
> Same thing for gfc_dummy_typename, gfc_typename, ... .

If we ever have three occurences of gfc_typename in a function list,
like

   foo (gfc_typename(a), gfc_typename(b), gfc_typename(c));

we will get the wrong result for the third one.  We will also get
a wrong result for

   pa = gfc_typename(a);
   pb = gfc_typename(b);
   pc = gfc_typename(c);

because then pa will point to the same memory as pc.

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||iains at gcc dot gnu.org,
   ||mikestump at comcast dot net

--- Comment #5 from Eric Gallager  ---
I asked about this on the mailing lists here:
https://gcc.gnu.org/pipermail/gcc/2020-June/232922.html
Iain Sandoe and Mike Stump had some hints about how to proceed; cc-ing them

[Bug c++/96170] New: Enhancement: allow requires-clause checking of statement expression substitution success or failure

[wjwray at gmail dot com]

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

Bug ID: 96170
   Summary: Enhancement: allow requires-clause checking of
statement expression substitution success or failure
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

Some sort of sfinae on statement expressions containing structured bindings
can provide a convenient way to detect the number of bindings in a type.

Checking in requires clauses seems like the most direct approach:
https://godbolt.org/z/Eoq9rr

template  constexpr int arity()
{
   if constexpr (requires (T& a) { ({auto [x] = a;}); })   return 1;
  else if constexpr (requires (T& a) { ({auto [x,y] = a;}); }) return 2;
  //   ... etc ... 3,4,5 ... N
  else
   return 0;
};

G++ accepts the template and, 
for a type T that decomposes into 1 element, arity() == 1 succeeds.

However, it fails eagerly on the 1st condition for any other type,
e.g. arity(), arity(), &etc...

c.f. bug 92402 seeking to match Clang's ability to sfinae in other contexts

(Clang accepts the template above but returns 0 for all T.)

[Bug c/96171] New: ICE on invalid VLA argument declaration and attribute access

[msebor at gcc dot gnu.org]

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

Bug ID: 96171
   Summary: ICE on invalid VLA argument declaration and attribute
access
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Specifying attribute access on an invalid function declaration involving a VLA
and an only subsequently declared bound parameter triggers an ICE:

$ cat q.c && gcc -S -Wall q.c
__attribute__ ((access (read_write, 1))) void f (int[n], int n);

q.c:1:54: error: ‘n’ undeclared here (not in a function)
1 | __attribute__ ((access (read_write, 1))) void f (int[n], int n);
  |  ^
‘
in print_type, at c/c-objc-common.c:188
1 | __attribute__ ((access (read_write, 1))) void f (int[n], int n);
  | ^
0x969bd2 print_type
/src/gcc/master/gcc/c/c-objc-common.c:188
0x96a268 c_tree_printer
/src/gcc/master/gcc/c/c-objc-common.c:310
0x23bd4d5 pp_format(pretty_printer*, text_info*)
/src/gcc/master/gcc/pretty-print.c:1475
0x2397247 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/src/gcc/master/gcc/diagnostic.c:1159
0x239786b diagnostic_impl
/src/gcc/master/gcc/diagnostic.c:1309
0x2398ad6 error(char const*, ...)
/src/gcc/master/gcc/diagnostic.c:1605
0xa6789d handle_access_attribute
/src/gcc/master/gcc/c-family/c-attribs.c:4134
0x8df64f decl_attributes(tree_node**, tree_node*, int, tree_node*)
/src/gcc/master/gcc/attribs.c:714
0x8f895e c_decl_attributes
/src/gcc/master/gcc/c/c-decl.c:5002
0x8f8ea9 start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
/src/gcc/master/gcc/c/c-decl.c:5141
0x96e7d8 c_parser_declaration_or_fndef
/src/gcc/master/gcc/c/c-parser.c:2299
0x96d426 c_parser_external_declaration
/src/gcc/master/gcc/c/c-parser.c:1773
0x96cf47 c_parser_translation_unit
/src/gcc/master/gcc/c/c-parser.c:1646
0x9ab605 c_parse_file()
/src/gcc/master/gcc/c/c-parser.c:21822
0xa375d1 c_common_parse_file()
/src/gcc/master/gcc/c-family/c-opts.c:1194
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/96171] ICE on invalid VLA argument declaration and attribute access

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |10.2
  Known to fail||10.1.0, 11.0
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-07-11

[Bug libfortran/93592] Invalid UP/DOWN rounding with EN descriptor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Dominique d'Humieres  ---
Confirmed since at least GCC7.

[Bug bootstrap/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

Version|10.1.0  |11.0
   Severity|normal  |enhancement
Summary|Cannot bootstrap with Xcode |GCC support for Apple
   |12 Beta on aarch64, macOS   |Silicon (Arm64) on macOS
   |11.0/Darwin, Apple Silicon  |requested

--- Comment #6 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #5)
> I asked about this on the mailing lists here:
> https://gcc.gnu.org/pipermail/gcc/2020-June/232922.html
> Iain Sandoe and Mike Stump had some hints about how to proceed; cc-ing them

It requires more or less a complete port (the amount of work depending on how
divergent the ABI and/or ISA is/are from the ones currently supported by GCC). 
We haven't begun to poke at this seriously yet.

Using the assembler / linker from LLVM upstream or Xcode is presumably possible
(in the same way that we can for X86 and PPC).

As Andrew says, it's a (IMO very) significant undertaking;  to get a port into
GCC11 would require the work to be complete and accepted by ≈ Dec 2020. 
Ideally, someone would work on it full-time for their day job to achieve that
;)

(of course, that won't stop us trying - but you should set expectations
realistically - spare time work is unlikely to achieve GCC11)

[Bug tree-optimization/96172] New: Failure to optimize direct assignment to bitfield through shifts

[gabravier at gmail dot com]

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

Bug ID: 96172
   Summary: Failure to optimize direct assignment to bitfield
through shifts
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

struct ret_struct
{
union
{
struct
{
unsigned int a : 1;
unsigned int b : 1;
unsigned int c : 1;
};
unsigned char as_char;
};
};

ret_struct f1(uint32_t x)
{
x >>= 16;
ret_struct result;
result.a = x;
result.b = (x >> 1);
result.c = (x >> 2);
return result;
}
// Compiling f1 with GCC yields code equivalent to f2
ret_struct f2(uint32_t x)
{
uint32_t a = (x >> 17) & 1;
uint32_t d = x;
a += a;
x = ((x >> 18) & 1) << 2;

ret_struct result;
result.as_char = ((a | ((d >> 16) & 1)) | x);
return result;
}
// Compiling f2 with GCC yields code equivalent to f3
ret_struct f3(uint32_t x)
{
x >>= 16;
ret_struct result;
result.as_char = (x & 1) | ((x & 2) | (x & 4));
return result;
}
// Compiling f3 with GCC yields code equivalent to f4
ret_struct f4(uint32_t x)
{
ret_struct result;
result.as_char = (x >> 16) & 7;
return result;
}

f1 and f2 can be directly optimized to f4. That transformation is done by LLVM,
but not by GCC.

Additionally, even directly compiling f4 with GCC doesn't yield an optimal code
generation on architectures like x86. GCC generates this :

f4(unsigned int):
  shr edi, 16
  and edi, 7
  xor eax, eax
  mov al, dil
  ret

and LLVM generates this :

f4(unsigned int):
  mov eax, edi
  shr eax, 16
  and eax, 7
  ret

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[gcczilla at cpellegrino dot de]

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

--- Comment #7 from Claudia Pellegrino  ---
Thanks Eric, and thank you Iain for the ballpark estimate.

Just to add a piece of data to get a better idea of the work involved, here’s a
link to a document published by Apple. It specifies how their ABI differs from
the standard ARM64 one:
https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html

Note that the document says iPhone OS but after a few cursory checks, the ABI
of macOS 11 on Apple Silicon seems entirely identical to the iOS one – which
makes sense, given the SoCs are the same and their kernels and large parts of
either OS are known to be built from the same source.

To give proper credit: I didn’t do those quick checks myself but macOS/iOS
security researcher Saagar Jha did, who is cc’ed on this bug and knows a ton
more about Apple’s OSes than I do.

[Bug fortran/93671] gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-11
 Status|UNCONFIRMED |NEW

--- Comment #2 from Dominique d'Humieres  ---
Confirmed since at least GCC7.

[Bug fortran/94408] Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-11

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[keno at juliacomputing dot com]

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

Keno Fischer  changed:

   What|Removed |Added

 CC||keno at juliacomputing dot com

--- Comment #8 from Keno Fischer  ---
Is there a list of all the things that need doing? I don't know very much about
how GCC is architected (but am familiar with LLVM,MachO,Aarch64 ISA, etc), but
from my naive point of view, at least

- Add all the ARM64 MachO relocations
- Add special cases for the Aarch64 ABI differences on Apple platforms
- Implement parsing/(& printing?) for Apple's assembly dialect
- Add CPU models for the relevant chips

The good news is that I don't think there's currently any proprietary ISA
extensions that we would have to worry about, so most of the code generation
should just go through.

I unfortunately don't have very much time myself either, but might able able to
pick up a small piece. Perhaps we can subdivide the work and prioritize what's
on the "critical path". I think the biggest reason people are clamoring for GCC
support at the moment is that the platform otherwise has no fortran compiler,
which is blocking a lot of the scientific computing stack. I think identifying
a minimal "fortran-complete" path would be helpful and encourage people to help
out :).

[Bug target/96173] New: double to _Decimal64 or _Decimal128 conversion with BID generates 3 MB of code

[vincent-gcc at vinc17 dot net]

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

Bug ID: 96173
   Summary: double to _Decimal64 or _Decimal128 conversion with
BID generates 3 MB of code
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider the following code:

int main (void)
{
  volatile double x = 0.0;
  volatile _Decimal128 i = x;
  return i != 0;
}

On x86_64:

zira:~> gcc-snapshot -O2 tst.c -o tst
zira:~> ll --human-readable tst
-rwxr-xr-x 1 vinc17 vinc17 3.3M 2020-07-12 01:44:05 tst*

With _Decimal64 instead of _Decimal128, tst is a bit smaller: 2.9M

Tested with gcc (Debian 20200616-1) 11.0.0 20200616 (experimental) [master
revision beaf12b49ae:aed76232726:b70eeb248efe2b3e9bdb5e26b490e3d8aa07022d]

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Keno Fischer from comment #8)
> Is there a list of all the things that need doing? I don't know very much
> about how GCC is architected (but am familiar with LLVM,MachO,Aarch64 ISA,
> etc), but from my naive point of view, at least
> 
> - Add all the ARM64 MachO relocations
GCC does not output macho files directly, so this part is just printing.

> - Add special cases for the Aarch64 ABI differences on Apple platforms
This one should be the majority of the work really.

> - Implement parsing/(& printing?) for Apple's assembly dialect
The printing part is part of GCC, GCC has support for alternative dialect that
can be used here.

> - Add CPU models for the relevant chips
You don't need this to start out with really, since ARMv8.3-a is backwards
compatiable with ARMv8-a.  You could default the arch to armv8.3-a if you want.

[Bug target/96173] double to _Decimal64 or _Decimal128 conversion with BID generates 3 MB of code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
_Decimal128 and _Decimal64 are all software based so there are functions which
implement everything.  The main thing which is actually taking up the space is
the functions for the conversions.

The functions for the conversions are all stored in one .o file:
 .text  0x004005d00x10567
/home/apinski/upstream-gcc/lib/gcc/x86_64-pc-linux-gnu/11.0.0/libgcc.a(bid_binarydecimal.o)
0x004005d0__bid32_to_binary32
0x00400bf0__bid64_to_binary32
0x00401460__bid128_to_binary32
0x00401f10__bid32_to_binary64
0x00402460__bid64_to_binary64
0x00402b60__bid128_to_binary64
0x00403680__bid32_to_binary80
0x00403e30__bid64_to_binary80
0x00404870__bid128_to_binary80
0x00405640__bid32_to_binary128
0x00405c10__bid64_to_binary128
0x00406430__bid128_to_binary128
0x00406fc0__binary32_to_bid32
0x00407650__binary64_to_bid32
0x00408100__binary80_to_bid32
0x00408be0__binary128_to_bid32
0x00409990__binary32_to_bid64
0x00409fb0__binary64_to_bid64
0x0040a730__binary80_to_bid64
0x0040b280__binary128_to_bid64
0x0040c040__binary32_to_bid128
0x0040cfa0__binary64_to_bid128
0x0040e160__binary80_to_bid128
0x0040f330__binary128_to_bid128

Since most of the time when using _Decimal128/_Decimal64, you will be using
many of these files, it won't change the size overall to have these functions
in different .o file.

[Bug target/96173] double to _Decimal64 or _Decimal128 conversion with BID generates 3 MB of code

[vincent-gcc at vinc17 dot net]

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

--- Comment #2 from Vincent Lefèvre  ---
IMHO, the implementation is highly inefficient. Even with all these functions
(which are similar, thus should share most code), 3 MB seems a lot to me.

In particular, some user complained that the size of the GNU MPFR library
(which now uses such conversions) has been multiplied by 5. This is even worse
with the GCC 11 snapshot, using ./configure CC=gcc-snapshot CFLAGS="-O2":

 663880 with --disable-decimal-float
4836016 with --enable-decimal-float
1914376 with --enable-decimal-float and hardcoded values instead of conversions
 668240 with --enable-decimal-float and even more hardcoded values

Note that this is MPFR that does the binary-to-decimal conversion itself (MPFR
uses _Decimal128 operations just for the format conversion, to generate either
NaN/±Inf/±0 from a double or some regular value from a decimal character
sequence). If MPFR can do this conversion within its few hundreds of KB[*], I
don't see why this can't be done by GCC.

[*] This does not include the small part of GMP on which MPFR is based, but
this includes much unrelated code, for all the functions MPFR implements.

[Bug libgcc/96173] double to _Decimal64 or _Decimal128 conversion with BID generates 3 MB of code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |libgcc

--- Comment #3 from Andrew Pinski  ---
The code is all located in libgcc/config/libbid/bid_binarydecimal.c

It looks to be precalulated tables which increase the size.

[Bug libgcc/96173] double to _Decimal64 or _Decimal128 conversion with BID generates 3 MB of code

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> The code is all located in libgcc/config/libbid/bid_binarydecimal.c
> 
> It looks to be precalulated tables which increase the size.

That is the code size is simple, just the tables are huge and go into the
readonly section (text section).

[Bug gcov-profile/96092] Should --coverage respect -ffile-prefix-map?

[i at maskray dot me]

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

--- Comment #3 from Fangrui Song  ---
(In reply to Martin Liška from comment #2)
> Apparently we've got a patch in queue that does something similar:
> 
> +fprofile-prefix-path=
> +Common·Joined·RejectNegative·Var(profile_prefix_path) 
> +remove·prefix·from·absolute·path·before·manging·name·for·-fprofile-
> generate=·and·-fprofile-use=.

Can we generalize the option to -fprofile-prefix-map= and let it be part of
-ffile-prefix-map? We can let clang side add -fprofile-prefix-map= as well
(https://reviews.llvm.org/D83154#2146085 )
clang may not support -fprofile-prefix-path= as it can be emulated by
-fprofile-prefix-map=

(IIUC, in GCC, -fprofile-generate uses gcov so either -fprofile-prefix-map= or
-fcoverage-prefix-map= will be an ok name. In clang, -fprofile-generate is an
instrumentation different from --coverage (gcov).)

[Bug c/95857] [8/9/10 Regression] Silencing an unused label warning with (void)&&label; can make gcc segfault

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:1ba192b5b7d2509b833f288000f21d6294420ace

commit r10-8466-g1ba192b5b7d2509b833f288000f21d6294420ace
Author: Jakub Jelinek 
Date:   Thu Jul 2 11:38:20 2020 +0200

tree-cfg: Fix ICE with switch stmt to unreachable opt and forced labels
[PR95857]

The following testcase ICEs, because during the cfg cleanup, we see:
  switch (i$e_11)  [33.33%], case -3:  [33.33%], case
0:  [33.33%], case 2:  [33.33%]>
...
lab2:
  __builtin_unreachable ();
where lab2 is FORCED_LABEL.  The way it works, we go through the case
labels
and when we reach the first one that points to gimple_seq_unreachable*
basic block, we remove the edge (if any) from the switch bb to the bb
containing the label and bbs reachable only through that edge we've just
removed.  Once we do that, we must throw away all other cases that use
the same label (or some other labels from the same bb we've removed the
edge
to and the bb).  To avoid quadratic behavior, this is not done by walking
all remaining cases immediately before removing, but only when processing
them later.
For normal labels this works, fine, if the label is in a deleted bb, it
will
have NULL label_to_block and we handle that case, or, if the unreachable bb
has some other edge to it, only the edge will be removed and not the bb,
and again, find_edge will not find the edge and we only remove the case.
And if a label would be to some other block, that other block wouldn't have
been removed earlier because there would be still an edge from the switch
block.
Now, FORCED_LABEL (and I think DECL_NONLOCAL too) break this, because
those labels aren't removed, but instead moved to some surrounding basic
block.  So, when we later process those, when their gimple_seq_unreachable*
basic block is removed, label_to_block will return some unrelated block
(in the testcase the switch bb), so we decide to keep the case which
doesn't
seem to be unreachable, but we don't really have an edge from the switch
block to the block the label got moved to.

I thought first about punting in gimple_seq_unreachable* on
FORCED_LABEL/DECL_NONLOCAL labels, but that might penalize even code that
doesn't care, so this instead just makes sure that for
FORCED_LABEL/DECL_NONLOCAL labels that are being removed (and thus moved
randomly) we remember in a hash_set the fact that those labels should be
treated as removed for the purpose of the optimization, and later on
handle those labels that way.

2020-07-02  Jakub Jelinek  

PR tree-optimization/95857
* tree-cfg.c (group_case_labels_stmt): When removing an unreachable
base_bb, remember all forced and non-local labels on it and later
treat those as if they have NULL label_to_block.  Formatting fix.
Fix a comment typo.

* gcc.dg/pr95857.c: New test.

(cherry picked from commit 00f24f56732861d09a9716fa5b6b8a96c2289143)