[Bug bootstrap/77510] genautomata memory footprint for MIPS

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org
   Last reconfirmed|2018-07-08 00:00:00 |2020-6-28

--- Comment #3 from Hans-Peter Nilsson  ---
I guess I can just add that this problem has only became worse.
With LAST_UPDATED
Fri Jun 26 21:36:32 CEST 2020
Fri Jun 26 19:36:32 UTC 2020 (revision
0fce12c0920:2873383514d:0801f419440c14f6772b28f763ad7d40f7f7a580)
(a.k.a r11-1677)
I just tried to build on CompileFarm gcc24, which is a "EdgeRouter Pro" mips64
with 2 GB memory but no swap, and with "gcc version 8.3.0 (Debian 8.3.0-6)".
Needless to say, genautomata fails.  Also tried in vain: configuring with
--enable-checking=release.

[Bug c++/95944] New: Concept diagnostic has multiple copies of irrelevant type and displays correct type incorrectly

[barry.revzin at gmail dot com]

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

Bug ID: 95944
   Summary: Concept diagnostic has multiple copies of irrelevant
type and displays correct type incorrectly
   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 following heavily reduced, and incorrect, attempt at an iterator:

#include 

template 
struct range {
struct iterator {
using reference = T;
using value_type = T;

auto operator*() -> T;
};
};

static_assert(std::indirectly_readable::iterator>);

This fails to meet the requirements of indirectly_readable because operator*()
needs to be const. This is the diagnostic I get from gcc trunk:

source>:13:20: error: static assertion failed
   13 | static_assert(std::indirectly_readable::iterator>);
  |   ~^
:13:20: note: constraints not satisfied
In file included from
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/bits/stl_iterator_base_types.h:71,
 from
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/iterator:61,
 from
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/ranges:44,
 from :1:
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/bits/iterator_concepts.h:446:13:
  required for the satisfaction of '__indirectly_readable_impl::type>::type>' [with _Tp =
range::iterator]
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/bits/iterator_concepts.h:446:42:
  in requirements with 'const _In __in' [with _Tp = range::iterator;
_Tp = range::iterator; _In = range::iterator]
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/bits/iterator_concepts.h:451:4:
note: the required expression '* __in' is invalid
  451 |  { *__in } -> same_as>;
  |^
/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/bits/iterator_concepts.h:452:21:
note: the required expression 'std::ranges::__cust::iter_move(__in)' is invalid
  452 |  { ranges::iter_move(__in) } -> same_as>;
  |~^~
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail
Compiler returned: 1

There are two especially important lines in this diagnostic: the one that
indicates the failed expression and the one that indicates the type of it. The
one that indicates the types is this one:

/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/bits/iterator_concepts.h:446:42:
  in requirements with 'const _In __in' [with _Tp = range::iterator;
_Tp = range::iterator; _In = range::iterator]

There is only one type in the requirement (_In) but the description starts with
some type _Tp. And then we get _Tp a second time, before finally getting to
_In. _In is also displayed incorrectly: it is shown as
range::iterator when it should be range::iterator.

Ideally this line looks closer to:

/opt/compiler-explorer/gcc-10.1.0/include/c++/10.1.0/bits/iterator_concepts.h:446:42:
  in requirements with 'const _In __in' [with _In = range::iterator]

[Bug fortran/85541] ICE with parameterized derived type (PDT) and allocate

[siteg at mathalacarte dot com]

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

Fred Krogh  changed:

   What|Removed |Added

 CC||siteg at mathalacarte dot com

--- Comment #3 from Fred Krogh  ---
I tried compiling the subroutine uc with GNU Fortran (GCC) 10.1.1 20200507 (Red
Hat 10.1.1-1).  And got this
gfortran -c -o uc.o uc.f90
f951: internal compiler error: Segmentation fault
0x7f8327870aaf ???
   
/usr/src/debug/glibc-2.31-17-gab029a2801/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f832785b041 __libc_start_main
../csu/libc-start.c:308
So the problem is still here.

[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler

[prop_design at protonmail dot com]

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

prop_design at protonmail dot com changed:

   What|Removed |Added

 CC||prop_design at protonmail dot 
com

--- Comment #19 from prop_design at protonmail dot com ---
hi everyone,

I'm not sure if this is the right place to ask this or not, but it relates to
the topic. I can't find the other thread about graphite auto-parallelization
that I made a long time ago.

I tried gfortran 10.1.0 via MSYS2. It seems to work very well on the latest
version of PROP_DESIGN. MP_PROP_DESIGN had some extra loops for benchmarking. I
found it made it harder for the optimizer so I deleted that code and just use
the 'real' version of the code it was based on called PROP_DESIGN_MAPS. So
that's the actual propeller design code with no additional looping for
benchmarking purposes.

I've found no Fortran compiler and do the auto-parallelization the way I would
like. The only code that would implement any at run time actually slowed the
code way down instead of sped it up.

I still have my original problem with gfortran. That is, at runtime no actual
parallelization occurs. The code runs the exact same as if the commands are not
present. Oddly though, the code does say it auto-parallelized many loops.
Although, not the loops that would really help, but at least it shows it's
doing something. That's an improvement from when I started these threads.

The problem is if I compile with the following:

gfortran PROP_DESIGN_MAPS.f -o PROP_DESIGN_MAPS.exe -O3 -ffixed-form -static
-march=x86-64 -mtune=generic -mfpmath=sse -mieee-fp -pthread
-ftree-parallelize-loops=2 -floop-parallelize-all -fopt-info-loop


It runs the exact same way as if I compile with:

gfortran PROP_DESIGN_MAPS.f -o PROP_DESIGN_MAPS.exe -O3 -ffixed-form -static
-march=x86-64 -mtune=generic -mfpmath=sse -mieee-fp


Again, gfortran does say it auto-parallelize some loops. So it's very odd. I
have searched the net and can't find anything that has helped.

I'm wondering if for Linux users, the code actually will work in parallel. That
would at least narrow the problem down some. I'm using Windows 10 and the code
will only run with one core. Compiling both ways it shows 2 threads used for
awhile and then drops to 1 thread.

The good news from when this was posted is that gfortran ran the code at the
same speed as the PGI Community Edition Compiler. Since they just stopped
developing that, I switched back to gfortran. I no longer have Intel Fortran to
test. That was the compiler that actually did run the code in parallel, but it
ran twice as slow instead of twice as fast. That was a year or two ago. I don't
know if it's any better now.

I'm wondering if there is some sort of issue with -pthread not being able to
call anything more than one core on Windows 10.

You can download PROP_DESIGN at https://propdesign.jimdofree.com

Inside the download are all the *.f files. I also have c.bat files in there
with the compiler options I used. The auto-parallelization commands are not
present, since they don't seem to be working still. At least on Windows 10.

The code now runs much faster than it used to, due to many bug fixes and
improvements I've made over the years. However, you can get it to run really
slow for testing purposes. In the settings file for the program change the
defaults like this:

1   ALLOW VORTEX INTERACTIONS (1) FOR YES (2) FOR NO (INTEGER, NON-DIM,
DEFAULT = 2)
2   ALLOW BLADE-TO-BLADE INTERACTIONS (1) FOR YES (2) FOR NO (INTEGER,
NON-DIM, DEFAULT = 2)

or like this

1   ALLOW VORTEX INTERACTIONS (1) FOR YES (2) FOR NO (INTEGER, NON-DIM,
DEFAULT = 2)
1   ALLOW BLADE-TO-BLADE INTERACTIONS (1) FOR YES (2) FOR NO (INTEGER,
NON-DIM, DEFAULT = 2)

The first runs very slow, the second incredibly slow. I just close the command
window once I've seen if the code is running in parallel or not. With the
defaults set at 2 for each of those values the code runs so fast you can't
really get a sense of what's going on.

Thanks for any help,

Anthony

[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-June/054638.html

[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Martin Liška from comment #3)
> Started with r11-524-geb069ae8819c3a84.

Good catch.

Fix:

diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index ba388ff598d..bfec57ccd9e 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -2027,7 +2027,12 @@ gfc_add_type (gfc_symbol *sym, gfc_typespec *ts, locus
*where)
   || (flavor == FL_PROCEDURE && sym->attr.subroutine)
   || flavor == FL_DERIVED || flavor == FL_NAMELIST)
 {
-  gfc_error ("Symbol %qs at %L cannot have a type",
sym->ns->proc_name->name, where);
+  if (sym->ns->proc_name)
+   gfc_error ("Symbol %qs at %L cannot have a type",
+  sym->ns->proc_name->name, where);
+  else
+   gfc_error ("Symbol %qs at %L cannot have a type",
+  sym->name, where);
   return false;
 }

Regtesting.

[Bug target/95943] New: arc -mbig-endian "inappropriate arguments" error from assembler

[arnd at linaro dot org]

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

Bug ID: 95943
   Summary: arc -mbig-endian "inappropriate arguments" error from
assembler
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Building an 'allmodconfig' linux kernel for ARC results in a failure to
assemble one file:

{standard input}: Assembler messages:
{standard input}:12347: Error: inappropriate arguments for opcode 'mpyd'
make[3]: *** [/tmp/mainline/scripts/Makefile.build:281: kernel/sched/core.o]
Error 1

With creduce, I reduced the problem to

void a(int b, int c, long long d) {
  long e = d;
  long long f = 0;
  if (e / 1000)
f = (long long)e * 1000;
  g(a, f);
}

$ arc-linux-gcc-O2 -mbig-endian  -mcpu=hs38 -c test.c
/tmp/ccfzWfgR.s: Assembler messages:
/tmp/ccfzWfgR.s:21: Error: inappropriate arguments for opcode 'mpyd'


$ arc-linux-gcc-O2 -mbig-endian  -mcpu=hs38 -S test.c -o-
.section.text
.align 4
.global a
.type   a, @function
a:
mov_s   r2,r3   ;4
add r2,r2,999
cmp r2,1998
mov.ls r2,0
mov.ls r3,0
mpyd.hi r2,r3,1000
mov_s   r1,r2   ;4
mov_s   r0,@a   ;13
b.d @g
mov_s   r2,r3   ;4
.size   a, .-a
.ident  "GCC: (GNU) 10.1.0"

This happens with at least gcc-8 through gcc-10, but not with gcc-7.5.

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Or even just  { target le }  yes.  You can put that as the selector on just
the scan tests, and even do a separate BE version as well.

You can quote regexps with {} instead of "", that makes them much more
readable.  The regexps seem to use . where they mean a literal dot, too?
Won't matter too much of course.

! { dg-final { scan-tree-dump "  \\(\\*var\\.str2\\)\\\[1\\\]{lb: 1 sz: 4} =
.dx00x00.\\\[1\\\]{lb: 1 sz: 4};" "original" } }

can become

! { dg-final { scan-tree-dump {  \(\*var\.str2\)\[1\]{lb: 1 sz: 4} =
.d\\x00\\x00.\[1\]{lb: 1 sz: 4};} "original" { target le } } }

and whatever BE needs.

[Bug c/82206] -Wformat-nonliteral does not warn when passing a non literal to vprintf

[simon.marchi at polymtl dot ca]

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

--- Comment #1 from Simon Marchi  ---
Stumbled on this again in the GDB code.  Here's another reproducer, probably
the same cause:

---
#include 
#include 

void add_line (const std::string );
void string_vappendf (std::string , const char *fmt, va_list args)
__attribute__((format(printf, 2, 0)));

void print(const char *fmt, ...)
{
  std::string tmp;

  va_list ap;
  va_start (ap, fmt);
  string_vappendf (tmp, fmt, ap);
  va_end (ap);

  add_line (tmp);
}
---

$ g++-9 test.cpp -c -Wall -Wextra -Wformat-nonliteral
* no warning *
$ clang++-9 test.cpp -c -Wall -Wextra -Wformat-nonliteral
test.cpp:13:25: warning: format string is not a string literal
[-Wformat-nonliteral]
  string_vappendf (tmp, fmt, ap);
^~~
1 warning generated.

[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Changed in r11-557-gbeb019d346b903c16b9fd349937de444b6a8b6c0

[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
Original code looks is at
https://github.com/dolphin-emu/dolphin/blob/2e8d1dd1dbcca7095e9d842f1df037cbe76868e4/Source/Core/Core/DSP/Jit/x64/DSPEmitter.cpp#L476:

"""
...
Gen::OpArg DSPEmitter::M_SDSP_r_st(size_t index)
{
  return MDisp(R15, static_cast(offsetof(SDSP, r.st[index])));
}
...
"""

[Bug c++/95942] New: [11 regression] offsetof on an array: error: 'e' is not a constant expression

[slyfox at inbox dot ru]

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

Bug ID: 95942
   Summary: [11 regression] offsetof on an array: error: 'e' is
not a constant expression
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

The original error is seen on https://www.dolphin-emu.org/ project as a build
error. Minimized example looks the following:

"""
  // $ cat.bug.cc
  struct a {
int b;
char c[100];
  };
  unsigned long d(long e) { return __builtin_offsetof(a, c[e]); }
"""

OK:
  $ LANG=C g++-10.1.0 -c bug.cc -o bug.o

OK:
  $ LANG=C clang++-10 -c bug.cc -o bug.o

FAIL:
  $ LANG=C g++-11.0.0 -c bug.cc -o bug.o
  bug.cc: In function 'void d(long int)':
  bug.cc:8:42: error: 'e' is not a constant expression
  8 | void d(long e) { __builtin_offsetof(a, c[e]); }
|

Who is wrong here? gcc-10 or gcc-11?

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[pdimov at gmail dot com]

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

Peter Dimov  changed:

   What|Removed |Added

 CC||pdimov at gmail dot com

--- Comment #30 from Peter Dimov  ---
I was going to ask the stupid question "why not just use the straightforward
double-checked locking here" but the answer is probably "ABI break".

[Bug c++/95937] ICE in finish_class_member_access_expr, at cp/typeck.c:3133

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||error-recovery
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-27
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

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

[Bug c++/95938] ICE in synthesize_implicit_template_parm, at cp/parser.c:44077

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-27
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

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

[Bug libstdc++/95915] [10/11 Regression] std::variant doesn't like types with a defaulted virtual destructor

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
Patch at https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549030.html

[Bug target/95941] New: Passing a struct by value wastes 16 bytes on the stack

[josephcsible at gmail dot com]

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

Bug ID: 95941
   Summary: Passing a struct by value wastes 16 bytes on the stack
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josephcsible at gmail dot com
  Target Milestone: ---
Target: x86_64-linux-gnu

Consider this C code:

extern struct foo {
long x, y, z;
} s;

void f(struct foo);

void g(void) {
f(s);
}

At "-O3", it compiles to this:

g:
subq$16, %rsp
pushq   s+16(%rip)
pushq   s+8(%rip)
pushq   s(%rip)
callf
addq$40, %rsp
ret

There's no reason at all to use that extra 16 bytes of stack space. It should
have compiled to this instead:

g:
pushq   s+16(%rip)
pushq   s+8(%rip)
pushq   s(%rip)
callf
addq$24, %rsp
ret

[Bug c++/94260] Specific friend function inside c++20 concept-constrained class template triggers 'not usable in a constant expression' error

[niekb at scintilla dot utwente.nl]

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

--- Comment #2 from niek  ---
Dear Patrick,

Nope, I cannot reproduce it anymore.
It seems to be fixed!


PS apologies for my delayed response; this is one of my public 'spam
email addresses', just saw it now.

best,
Niek

On 22/06/2020 15:45, ppalka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94260
> 
> Patrick Palka  changed:
> 
>What|Removed |Added
> 
>Last reconfirmed||2020-06-22
>  Ever confirmed|0   |1
>  CC||ppalka at gcc dot gnu.org
>  Status|UNCONFIRMED |WAITING
> 
> --- Comment #1 from Patrick Palka  ---
> Thanks for the report.  I'm unable to reproduce this issue against GCC 10.1 or
> current trunk.  Are you still able to reproduce?
> 
> -- You are receiving this mail because: You reported the bug.

[Bug middle-end/95939] [11 Regression] ice with -O3 in compute_live_loop_exits

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
  Component|fortran |middle-end

--- Comment #3 from kargl at gcc dot gnu.org ---
Change component as this appears to not be Fortran specific.

[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
In the particular case we are talking about, security/non-security, it doesn't
make sense to do anything but optimize it into straight line code, any
__builtin_trap or similar will just hurt.  If you feel e.g. by default adding
__builtin_unreachable is too dangerous in some cases, it can just handle
similar cases manually and optimize away the conditional if there are no
side-effect statements in between.
We are talking about:
   [local count: 1073741824]:
  if (base_2(D) != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 751619281]:
  iftmp.1_3 = base_2(D) + (sizetype)-4;

   [local count: 1073741824]:
  # iftmp.1_1 = PHI 
  _5 = MEM[(const struct Derived *)iftmp.1_1].D.2340.y;
where without -fno-delete-null-pointer-checks and without -fwrapv-pointer, we
can assume: 1) pointers in valid programs don't wrap 2) the first page is not
mapped
As offsetof (Derived, D.2340.y) is >= 4 and < 4096 here, we don't need to even
care about pointer wrapping, just rely on accesses to 0 .. 4095 offsets to
trap.
If the offsetof would be 0, it would be about pointer wrapping, whether we are
ok if instead of dereferencing *(int *)0 we dereference *(int *)-4 instead.

[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
The reason for turning the dereference into a trap is because we can clean up
ancillary computations -- the address computation, the RHS of a store, and the
like via standard dead code elimination algorithms.

[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law  ---
Marc,

Yes, absolutely.  In fact, I think that falls out of the work Martin S is doing
in this space.  Conceptually we're looking to generalize that code so that we
can route more cases where the compiler detects undefined behavior through the
path isolation routines.

Within those commonized routines we want to have a knob which selects different
behavior from the compiler when undefined behavior is detected which could
potentially include issuing the RTL equivalent of __builtin_unreachable vs trap
vs warn, but leave the code alone, try to mitigate, etc.

Where I think we've differed in the past is what to do with conditional branch
upon which the undefined behavior is control dependent upon.  As you may
remember, the original submission of path isolation would turn that conditional
into an unconditional branch to the valid path.  That's not correct because
there can be observable behavior that occurs on the path from the conditional,
but before the undefined behavior triggers.  Having a knob to twiddle *that*
may or may not be a good idea.

[Bug lto/95928] LTO through ar breaks weak function resolution

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Andi Kleen from comment #12)
> Okay. I only compared gcc-7 (working) vs gcc-9 (broken), but always with LTO.
> 
> Looking at the kernel link it also uses --whole-archive. Perhaps that makes
> a difference?
> 
> I'll redo the test case with --whole-archive (will need some fixes)

--whole-archive makes the difference.

[Bug lto/95928] LTO through ar breaks weak function resolution

[andi-gcc at firstfloor dot org]

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

--- Comment #12 from Andi Kleen  ---
Okay. I only compared gcc-7 (working) vs gcc-9 (broken), but always with LTO.

Looking at the kernel link it also uses --whole-archive. Perhaps that makes a
difference?

I'll redo the test case with --whole-archive (will need some fixes)

[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt

[bugdal at aerifal dot cx]

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

--- Comment #3 from Rich Felker  ---
Yes,I'm aware m68k has FLT_EVAL_METHOD=2. That's not license for *functions* to
return excess precision. The language specification is very clear about where
excess precision is and isn't kept, and here it must not be. All results are
deterministic even with excess precision. Moreover if there's excess precision
where gcc's middle end didn't expect it, it will turn into cascadingly wrong
optimization, possibly even making pure integer results wrong.

[Bug c++/95820] [10/11 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
*** Bug 95936 has been marked as a duplicate of this bug. ***

[Bug c++/95936] ICE in splice_late_return_type, at cp/pt.c:29114

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

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

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
{ target { le } }

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
FIXED on master for gcc-11, and on 10- and 9-branch.

Thanks for the report!

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

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

commit r9-8703-gcb797c730dd37ffe88ed0b1d04aec01982feacb5
Author: Harald Anlauf 
Date:   Sat Jun 27 14:56:33 2020 +0200

PR fortran/95881 - ICE in resolve_symbol, at fortran/resolve.c:15175

Avoid NULL pointer dereference.

gcc/fortran/
PR fortran/95881
* resolve.c (resolve_symbol): Avoid NULL pointer dereference.

(cherry picked from commit 3cbc0fb39c84ae0a51a9a88649dccd105bf17d6e)

[Bug lto/95928] LTO through ar breaks weak function resolution

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Andi Kleen from comment #9)
> I think the STB_SECONDARY stuff is only needed if ld -r is used, but not for
> ar

Linker won't search archive to resolve weak definition. Since SECONDARY is
between WEAK and undefined, linker will keep searching archive for strong
definition to override secondary definition.

[Bug fortran/95826] ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11 and on 10-branch.

Thanks for the report!

[Bug fortran/95828] ICE in resolve_select_rank, at fortran/resolve.c:9774

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
FIXED on master for gcc-11 and on 10-branch.

Thanks for the report!

[Bug lto/95928] LTO through ar breaks weak function resolution

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Andi Kleen from comment #8)
> It works fine without LTO.
> 
> Otherwise the Linux kernel wouldn't work. It relies on this behavior for its
> syscalls.
> 

[hjl@gnu-cfl-2 pr95928]$ make
/usr/gcc-9.3.1-x32/bin/gcc -B./-c -o dummy.o dummy.c
/usr/gcc-9.3.1-x32/bin/gcc -B./  -c sys_ni.i
/usr/gcc-9.3.1-x32/bin/gcc -B./  -c capability.i
/usr/gcc-9.3.1-x32/bin/gcc-ar rc -o libx.a sys_ni.o capability.o
/usr/gcc-9.3.1-x32/bin/gcc -B./ -O2  -o x dummy.o libx.a
/usr/gcc-9.3.1-x32/bin/gcc -B./ -O2  -o y dummy.o sys_ni.o capability.o
objdump --disassemble=__x64_sys_capget x | grep sys_ni_syscall
  401127:   e8 e5 ff ff ff  callq  40 
objdump --disassemble=__x64_sys_capget y | grep sys_ni_syscall
make: *** [Makefile:20: all] Error 1
[hjl@gnu-cfl-2 pr95928]$ 

> The test case is extracted from there.

Something is missing in this testcase.

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-8377-gd12079381e25571f2d5f7bb16eaef07ee89b361b
Author: Harald Anlauf 
Date:   Sat Jun 27 14:56:33 2020 +0200

PR fortran/95881 - ICE in resolve_symbol, at fortran/resolve.c:15175

Avoid NULL pointer dereference.

gcc/fortran/
PR fortran/95881
* resolve.c (resolve_symbol): Avoid NULL pointer dereference.

(cherry picked from commit 3cbc0fb39c84ae0a51a9a88649dccd105bf17d6e)

[Bug lto/95928] LTO through ar breaks weak function resolution

[andi-gcc at firstfloor dot org]

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

--- Comment #9 from Andi Kleen  ---
I think the STB_SECONDARY stuff is only needed if ld -r is used, but not for ar

[Bug lto/95928] LTO through ar breaks weak function resolution

[andi-gcc at firstfloor dot org]

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

--- Comment #8 from Andi Kleen  ---
It works fine without LTO.

Otherwise the Linux kernel wouldn't work. It relies on this behavior for its
syscalls.

The test case is extracted from there.

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:3cbc0fb39c84ae0a51a9a88649dccd105bf17d6e

commit r11-1688-g3cbc0fb39c84ae0a51a9a88649dccd105bf17d6e
Author: Harald Anlauf 
Date:   Sat Jun 27 14:56:33 2020 +0200

PR fortran/95881 - ICE in resolve_symbol, at fortran/resolve.c:15175

Avoid NULL pointer dereference.

gcc/fortran/
PR fortran/95881
* resolve.c (resolve_symbol): Avoid NULL pointer dereference.

[Bug tree-optimization/95923] Failure to optimize bool checks into and

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(With one variant I ended up with (a|b)&(a==b), which we don't optimize to a)

We don't optimize !(!a && !b) && !(!a && b) && !(a && !b) (we keep several
branches), but we do optimize if I manually replace enough && with &.

[Bug lto/95928] LTO through ar breaks weak function resolution

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to H.J. Lu from comment #6)
> It has nothing to do with LTO.  You get the same behavior without LTO.
> This is how weak symbol works.

BTW, this is why I proposed STB_SECONDARY:

https://gcc.gnu.org/legacy-ml/gcc/2012-06/msg00390.html

[Bug tree-optimization/95929] Failure to optimize tautological comparisons of comparisons to a single one

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Here gcc does optimize the first f to (a != 0) ^ (b != 0). However, for the
second f, it does indeed generate something that looks like the first f before
optimization... The optimization for the first f is probably "(X && !Y) || (!X
&& Y) is X ^ Y" in fold-const.c, which may not have an equivalent in match.pd
yet.

[Bug lto/95928] LTO through ar breaks weak function resolution

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #6 from H.J. Lu  ---
It has nothing to do with LTO.  You get the same behavior without LTO.
This is how weak symbol works.

[Bug tree-optimization/95924] Failure to optimize some bit magic to one of the operands

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
* If I replace ~a with !a, we manage to do everything with type bool. With ~a,
we don't, we stick to int.

* We don't handle a?b:false the same as a&

* Even for (a | !b) && (!(!a & b) && a) we don't completely simplify, because
that would be replacing too many && with & (I think). If I manually replace one
&& with &, gcc manages.

[Bug tree-optimization/95926] Failure to optimize xor pattern when using temporary variable

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
It is different to gcc because in the first case, tmp is used twice, while in
the second case, each a is only used once, and gcc only transforms (a)^b to
b&~a if this is the only use of a Yes, this heuristic often backfires, but
as long as we consider &~ as 2 operations, not restricting the transformation
could generate worse code in some cases.

[Bug fortran/95939] [11 Regression] ice with -O3 in compute_live_loop_exits

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
(In reply to David Binderman from comment #1)
> I'll have a go at reducing the first.

Pointless. It is only a few lines of code anyway.

[Bug fortran/95939] [11 Regression] ice with -O3 in compute_live_loop_exits

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Same error in testsuite files gcc.dg/tree-ssa/pr23433.c
and gcc.target/aarch64/sve/reduc_strict_8.c.

I'll have a go at reducing the first.

[Bug tree-optimization/95663] static_cast checks for null even when the pointer is dereferenced

[glisse at gcc dot gnu.org]

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

--- Comment #12 from Marc Glisse  ---
(In reply to Jeffrey A. Law from comment #10)
> __builtin_trap emits an actual trap into the instruction stream which halts
> the process immediately which is *much* better from a security standpoint

Regardless of what the default is, I think we should be able to agree that
there are uses where we want to favor hardening/security (public facing
servers, web browsers), and others where performance is more important
(scientific simulations), and it would be nice to give users a choice.
(I think sanitizers already provide a way to turn __builtin_unreachable into
__builtin_trap, but that's more meant for explicit __builtin_unreachable in
user code)

[Bug bootstrap/95940] New: sparc64-linux bootstrap with gcc-9.3 broken

[hp at gcc dot gnu.org]

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

Bug ID: 95940
   Summary: sparc64-linux bootstrap with gcc-9.3 broken
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---

As seen on gcc202 at LAST_UPDATED:
Fri Jun 26 21:36:32 CEST 2020
Fri Jun 26 19:36:32 UTC 2020 (revision
0fce12c0920:2873383514d:0801f419440c14f6772b28f763ad7d40f7f7a580)
(a.k.a. r11-1677-g0801f419440c14f6772b28f763ad7d40f7f7a580)
using no configure options and no make options:

/home/hp/combcheck/o0/./prev-gcc/xg++ -B/home/hp/combcheck/o0/./prev-gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/hp/combcheck/o0/prev-sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/hp/combcheck/o0/prev-sparc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/hp/combcheck/o0/prev-sparc64-unknown-linux-gnu/libstdc++-v3/include/sparc64-unknown-linux-gnu
 -I/home/hp/combcheck/o0/prev-sparc64-unknown-linux-gnu/libstdc++-v3/include 
-I/home/hp/combcheck/gcc/libstdc++-v3/libsupc++
-L/home/hp/combcheck/o0/prev-sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/hp/combcheck/o0/prev-sparc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/home/hp/combcheck/gcc/gcc -I/home/hp/combcheck/gcc/gcc/.
-I/home/hp/combcheck/gcc/gcc/../include
-I/home/hp/combcheck/gcc/gcc/../libcpp/include 
-I/home/hp/combcheck/gcc/gcc/../libdecnumber
-I/home/hp/combcheck/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/hp/combcheck/gcc/gcc/../libbacktrace   -o tree-ssanames.o -MT
tree-ssanames.o -MMD -MP -MF ./.deps/tree-ssanames.TPo
/home/hp/combcheck/gcc/gcc/tree-ssanames.c
In function ?wide_int get_nonzero_bits(const_tree)?,
inlined from ?wide_int get_nonzero_bits(const_tree)? at
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:514:1:
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:527:46: error:
?.generic_wide_int::.wide_int_storage::val[1]?
may be used uninitialized [-Werror=maybe-uninitialized]
  527 | | (HOST_WIDE_INT) pi->misalign, precision);
  |  ^
/home/hp/combcheck/gcc/gcc/tree-ssanames.c: In function ?wide_int
get_nonzero_bits(const_tree)?:
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:527:46: note: ?? declared
here
  527 | | (HOST_WIDE_INT) pi->misalign, precision);
  |  ^
In function ?wide_int get_nonzero_bits(const_tree)?,
inlined from ?wide_int get_nonzero_bits(const_tree)? at
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:514:1:
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:527:46: error:
?.generic_wide_int::.wide_int_storage::val[2]?
may be used uninitialized [-Werror=maybe-uninitialized]
  527 | | (HOST_WIDE_INT) pi->misalign, precision);
  |  ^
/home/hp/combcheck/gcc/gcc/tree-ssanames.c: In function ?wide_int
get_nonzero_bits(const_tree)?:
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:527:46: note: ?? declared
here
  527 | | (HOST_WIDE_INT) pi->misalign, precision);
  |  ^
In function ?wide_int get_nonzero_bits(const_tree)?,
inlined from ?wide_int get_nonzero_bits(const_tree)? at
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:514:1:
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:528:37: error:
?.generic_wide_int::.wide_int_storage::val[1]?
may be used uninitialized [-Werror=maybe-uninitialized]
  528 |   return wi::shwi (-1, precision);
  | ^
/home/hp/combcheck/gcc/gcc/tree-ssanames.c: In function ?wide_int
get_nonzero_bits(const_tree)?:
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:528:37: note: ?? declared
here
  528 |   return wi::shwi (-1, precision);
  | ^
In function ?wide_int get_nonzero_bits(const_tree)?,
inlined from ?wide_int get_nonzero_bits(const_tree)? at
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:514:1:
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:528:37: error:
?.generic_wide_int::.wide_int_storage::val[2]?
may be used uninitialized [-Werror=maybe-uninitialized]
  528 |   return wi::shwi (-1, precision);
  | ^
/home/hp/combcheck/gcc/gcc/tree-ssanames.c: In function ?wide_int
get_nonzero_bits(const_tree)?:
/home/hp/combcheck/gcc/gcc/tree-ssanames.c:528:37: note: ?? declared
here
  528 |   return wi::shwi (-1, precision);
  | ^
In function ?wide_int 

[Bug fortran/95939] New: ice with -O3 in compute_live_loop_exits

[dcb314 at hotmail dot com]

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

Bug ID: 95939
   Summary: ice with -O3 in compute_live_loop_exits
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Recent gcc trunk gfortran compiler does this:

$ /home/dcb/gcc/results/bin/gfortran -c -O3 ./gfortran.dg/graphite/pr42285.f90
during GIMPLE pass: vect
./gfortran.dg/graphite/pr42285.f90:3:0:

3 | SUBROUTINE EFGRDM(NCF,NFRG,G,RTRMS,GM,IOPT,K1)
  | 
internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
0x6d94fd compute_live_loop_exits
../../trunk.git/gcc/tree-ssa-loop-manip.c:247
0x6d94fd add_exit_phis_var
../../trunk.git/gcc/tree-ssa-loop-manip.c:334
0x6d94fd add_exit_phis
../../trunk.git/gcc/tree-ssa-loop-manip.c:356
0x6d94fd rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
../../trunk.git/gcc/tree-ssa-loop-manip.c:678

This seems to have gone wrong sometime between date 20200624
and 20200625.

It is often worthwhile to run all the Fortran code in the testsuite 
through the compiler with -O3 or -O3 -march=native.

[Bug c++/95938] New: ICE in synthesize_implicit_template_parm, at cp/parser.c:44077

[haoxintu at gmail dot com]

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

Bug ID: 95938
   Summary: ICE in synthesize_implicit_template_parm, at
cp/parser.c:44077
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.

$cat bug.cc
a ( union { auto


$g++ bug.cc
bug.cc:1:11: error: types may not be defined in parameter types
1 | a ( union { auto
  |   ^
bug.cc:1:13: internal compiler error: in synthesize_implicit_template_parm, at
cp/parser.c:44077
1 | a ( union { auto
  | ^~~~
0x642457 synthesize_implicit_template_parm
../../gcc/cp/parser.c:44077
0x9bd740 cp_parser_simple_type_specifier
../../gcc/cp/parser.c:18029
0x9a1a3d cp_parser_type_specifier
../../gcc/cp/parser.c:17838
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0x9cb167 cp_parser_member_declaration
../../gcc/cp/parser.c:24995
0x99f921 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24850
0x99f921 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23947
0x9a1aa3 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0x9a1aa3 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0x9a2a02 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0x9bf3ef cp_parser_parameter_declaration
../../gcc/cp/parser.c:22818
0x9bfdd2 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22641
0x9c01bc cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22568
0x9ad617 cp_parser_direct_declarator
../../gcc/cp/parser.c:21245
0x9ad617 cp_parser_declarator
../../gcc/cp/parser.c:21109
0x9c1ba6 cp_parser_init_declarator
../../gcc/cp/parser.c:20609
0x9a36d2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9cd06a c_parse_file()
../../gcc/cp/parser.c:44043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/95937] New: ICE in finish_class_member_access_expr, at cp/typeck.c:3133

[haoxintu at gmail dot com]

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

Bug ID: 95937
   Summary: ICE in finish_class_member_access_expr, at
cp/typeck.c:3133
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code, bug.cc, reduced by C-Reduce, makes GCC-trunk ICE.

$cat bug.cc
void a { [].decltype(auto)::b

$g++ bug.cc
bug.cc:1:6: error: variable or field ‘a’ declared void
1 | void a { [].decltype(auto)::b
  |  ^
bug.cc: In lambda function:
bug.cc:1:12: error: expected ‘{’ before ‘.’ token
1 | void a { [].decltype(auto)::b
  |^
bug.cc: At global scope:
bug.cc:1:29: internal compiler error: in finish_class_member_access_expr, at
cp/typeck.c:3133
1 | void a { [].decltype(auto)::b
  | ^
0x69a36f finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
../../gcc/cp/typeck.c:3133
0x9b9d27 cp_parser_postfix_dot_deref_expression
../../gcc/cp/parser.c:7900
0x9b2c52 cp_parser_postfix_expression
../../gcc/cp/parser.c:7540
0x99564a cp_parser_binary_expression
../../gcc/cp/parser.c:9609
0x9971ae cp_parser_assignment_expression
../../gcc/cp/parser.c:9914
0x995f6d cp_parser_constant_expression
../../gcc/cp/parser.c:10208
0x9966d1 cp_parser_initializer_clause
../../gcc/cp/parser.c:23272
0x99683a cp_parser_initializer_list
../../gcc/cp/parser.c:23550
0x99683a cp_parser_braced_list
../../gcc/cp/parser.c:23311
0x99aa3a cp_parser_initializer
../../gcc/cp/parser.c:23228
0x9c259b cp_parser_init_declarator
../../gcc/cp/parser.c:20903
0x9a36d2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9cd06a c_parse_file()
../../gcc/cp/parser.c:44043
0xae4dbb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Michael Bruck from comment #6)
> Is it possible to point the user to include  here like other parts of
> gcc do for standard library functions?
> i.e. name-lookup.c missing_std_header

That's also a possibility (we do that for a missing  include
already).

[Bug c++/95505] [coroutines] ICE assert with get_return_object_on_allocation_failure

[bruck.michael at gmail dot com]

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

--- Comment #6 from Michael Bruck  ---
Is it possible to point the user to include  here like other parts of gcc
do for standard library functions?
i.e. name-lookup.c missing_std_header

[Bug middle-end/95903] gcc 10: wrong code with -fwrapv

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:37995960984ea346dd9d168d332cd6f7adf0

commit r11-1685-g37995960984ea346dd9d168d332cd6f7adf0
Author: Jakub Jelinek 
Date:   Sat Jun 27 12:38:23 2020 +0200

c-family: Use TYPE_OVERFLOW_UNDEFINED instead of !TYPE_UNSIGNED in
pointer_sum [PR95903]

For lp64 targets and int off ... ptr[off + 1]
is lowered in pointer_sum to *(ptr + ((sizetype) off + (sizetype) 1)).
That is fine when signed integer wrapping is undefined (and is not done
already if off has unsigned type), but changes behavior for -fwrapv, where
overflow is well defined.  Runtime test could be:
int
main ()
{
  char *p = __builtin_malloc (0x1UL);
  if (!p) return 0;
  char *q = p + 0x8000UL;
  int o = __INT_MAX__;
  q[o + 1] = 1;
  if (q[-__INT_MAX__ - 1] != 1) __builtin_abort ();
  return 0;
}
with -fwrapv or so, not included in the testsuite because it requires 4GB
allocation (with some other test it would be enough to have something
slightly above 2GB, but still...).

2020-06-27  Jakub Jelinek  

PR middle-end/95903
gcc/c-family/
* c-common.c (pointer_int_sum): Use TYPE_OVERFLOW_UNDEFINED instead
of
!TYPE_UNSIGNED check to see if we can apply distributive law and
handle
smaller precision intop operands separately.
gcc/testsuite/
* c-c++-common/pr95903.c: New test.

[Bug target/95674] Unnecessary move when doing division-by-multiplication

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
(In reply to Vladimir Makarov from comment #3)
> I looked at this problem.
> 
> All assignments are done in IRA (LRA does not change them).  We can not make
> a better assignment because scratches do not permit to store any preferences
> from instruction constraints (pseudo-registers permits to do this). So
> storing and getting this info for scratches is the first step to solving the
> problem.
> 
> LRA changes scratches to pseudo-registers to generate the correct code
> satisfying the insn constraints and turn them back to scratches when the
> corresponding pseudo-registers do not get hard registers.  Moving change of
> scratches to pseudo-regs from LRA to IRA could help but it is a big work.
Yeah, sounds useful!  Could it be done as a prepass before IRA proper?
(Maybe not -- haven't really thought about it much.)

> Another solution is to not use scratches in machine-descriptions and use
> pseudo-registers instead.  Scratches are bad and should be avoided as much
> as possible.  I expressed this several times.  Besides it is not possible to
> keep hard register preferences for them, they also can not be taken into
> account in conflict graph and this results in overoptimistic assignments
> which LRA has to correct.
I can see that scratches make life harder for the register allocators,
at least until the above change is made.  But they're very useful for
pre-RA passes.  They make it possible for any pass to use recog to match
a candidate instruction and have recog automatically add the required
scratches, without the passes having to cope with new registers being
created “spontaneously”.  (Combine is of course the main example,
but others like fwprop benefit too.)

Although it would be possible to use pseudos instead, I'm not sure
the end result would be better than what we have now:
- Each pass would need to cope with recog creating new registers
- We'd need some way of deferring the creation of pseudo registers
  for successful but speculative recogs that might later be rejected
  for cost reasons, or at least have some kind of recycling scheme.
- Even then, we'll have more pseudos before RA, and so most of the
  DF datastructures will be larger and perhaps sparser.

[Bug c++/95736] coroutine method improperly copies awaitable

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r11-1684-gdaaed0199ee57013ae011421a7e90b7bdd295373
Author: Iain Sandoe 
Date:   Sat Jun 27 08:18:34 2020 +0100

coroutines: Handle awaiters that are sub-objects [PR95736]

Move deciding on initializers for awaitables to the build of the
co_await, this allows us to analyse cases that do not need
a temporary at that point.

As the PR shows, the late analysis meant that we  were not
checking properly for the case that an awaiter is a sub-object
of an existing variable outside the current function scope (and
therefore does not need to be duplicated in the frame).

gcc/cp/ChangeLog:

PR c++/95736
* coroutines.cc (get_awaitable_var): New helper.
(build_co_await): Check more carefully before
copying an awaitable.
(expand_one_await_expression): No initializer
is required when the awaitable is not a temp.
(register_awaits): Remove handling that is now
completed when the await expression is built.

gcc/testsuite/ChangeLog:

PR c++/95736
* g++.dg/coroutines/pr95736.C: New test.

[Bug c++/95936] New: ICE in splice_late_return_type, at cp/pt.c:29114

[haoxintu at gmail dot com]

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

Bug ID: 95936
   Summary: ICE in splice_late_return_type, at cp/pt.c:29114
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code, bug.cc. reduced by C-Reduce, makes GCC-trunk ICE.

$cat bug.cc
typedef (*a)()->const =


$g++ -fpermissive -w bug.cc 
bug.cc:1:17: internal compiler error: in splice_late_return_type, at
cp/pt.c:29114
1 | typedef (*a)()->const =
  | ^
0x65832a splice_late_return_type(tree_node*, tree_node*)
../../gcc/cp/pt.c:29114
0x90aab6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:12205
0x915628 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5233
0x9c1e6d cp_parser_init_declarator
../../gcc/cp/parser.c:20818
0x9a36d2 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0x9cc926 cp_parser_declaration
../../gcc/cp/parser.c:13484
0x9cd06a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9cd06a c_parse_file()
../../gcc/cp/parser.c:44043
0xae4dbb c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


$g++ --version
g++ (GCC) 11.0.0 20200626 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug bootstrap/92484] In tree build of ISL 0.22 fails: requires C++11

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

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

--- Comment #7 from Romain Geissler  ---
Current trunk (gcc 11) builds with C++11 now, so ISL 0.22 is useable during a
full bootstrap in tree.

Closing.

[Bug fortran/95918] gfortran.dg/char4-subscript.f90 fails for BE architectures

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
The problem is in the scans; the code runs fine.

Does anybody have the dejagnu-fu to run the scans only on little-endian
systems?

[Bug c++/95917] coroutine functions leak under freestanding mode causing dependencies and binary bloat.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC|jwakely at redhat dot com  |

--- Comment #7 from Jonathan Wakely  ---
Please don't CC me on your stupid rants.

[Bug bootstrap/95934] bootstrap fails in compiler assert in sanitizer_platform_limits_posix.cpp:1136

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

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug bootstrap/95934] bootstrap fails in compiler assert in sanitizer_platform_limits_posix.cpp:1136

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andreas Schwab  ---
You have left out the actual error message.

This has been fixed in commit 4abc46b51af and backported to gcc-9 in commit
75003cdd23c (included in 9.3.0).

[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt

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

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

--- Comment #2 from Andreas Schwab  ---
The m68k backend generally does all floating point arithmethic in extended
precision for !TARGET_68040, setting FLT_EVAL_METHOD to 2.