[Bug target/97792] ICE in extract_insn, at recog.c:2315

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |11.0

[Bug target/97792] New: ICE in extract_insn, at recog.c:2315

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97792
   Summary: ICE in extract_insn, at recog.c:2315
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, rearnsha at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: arm-linux-gnueabi

The following fails:

$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/overflow-vec-2.c
-mcpu=iwmmxt -c
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/overflow-vec-2.c:
In function ‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/overflow-vec-2.c:144:1:
error: unrecognizable insn:
  144 | }
  | ^
(insn 1590 1589 1591 2 (set (reg:V8QI 353 [ _337 ])
(mult:V8QI (reg:V8QI 351 [ _335 ])
(reg:V8QI 352 [ _336 ])))
"/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/overflow-vec-2.c":110:9
-1
 (nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/overflow-vec-2.c:144:1:
internal compiler error: in extract_insn, at recog.c:2315
0x5f02f7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/rtl-error.c:108
0x5f0313 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/rtl-error.c:116
0x5ef7c8 extract_insn(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/recog.c:2315
0x87e5ff instantiate_virtual_regs_in_insn
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/function.c:1609
0x87e5ff instantiate_virtual_regs
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/function.c:1979
0x87e5ff execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/function.c:2028
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/97788] [11 regression] g++.dg/ubsan/pr61272.C fails after r11-4852

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #1 from Martin Liška  ---
I'll take a look.

[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> I guess it succeeds when you do not enable -g?  Can you check if reverting
> 63a2bdbfb42628800a6999e98804928855592ce7 or
> 136256c32db63600168516e562441f73c26a187a helps?  That said, is 10.1.0 OK?

I bet 136256c32db63600168516e562441f73c26a187a should fix that.

[Bug tree-optimization/97789] valgrind error with ./gcc.dg/c11-atomic-2.c

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-11
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
  Component|c   |tree-optimization
Version|unknown |11.0

--- Comment #1 from Richard Biener  ---
Hmm, I'll take a look.  But this maybe got fixed with
17c25a454e056f4677649a5ed4a8b8587d29177c

[Bug testsuite/97788] [11 regression] g++.dg/ubsan/pr61272.C fails after r11-4852

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-11

[Bug target/97779] [9/10 Regression] Newest releases/gcc-10 cannot build because lack of PTA_CLDEMOTE

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Liška  ---
It's fixed now.

[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Target||mips64
   Target Milestone|--- |10.3
 Status|UNCONFIRMED |WAITING
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2020-11-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I guess it succeeds when you do not enable -g?  Can you check if reverting
63a2bdbfb42628800a6999e98804928855592ce7 or
136256c32db63600168516e562441f73c26a187a helps?  That said, is 10.1.0 OK?

[Bug target/97784] Expressions evaluated as long chain instead of as tree or the like

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
Oh and for the GIMPLE side there's still my TODO item of "finishing" turning
late GIMPLE to -fwrapv as to make the last reassoc pass effective here.  But
it's again a bit late for that.  Hmm, I might simply try ...

[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:81372618277bfae682434fcdc80b311ee6007476

commit r11-4902-g81372618277bfae682434fcdc80b311ee6007476
Author: Jakub Jelinek 
Date:   Wed Nov 11 08:27:38 2020 +0100

fortran: Fix up gfc_typename CHARACTER length handling [PR97768]

The first testcase below ICEs when f951 is 32-bit (or 64-bit big-endian).
The problem is that ex->ts.u.cl && ex->ts.u.cl->length are both non-NULL,
but ex->ts.u.cl->length->expr_type is not EXPR_CONSTANT, but EXPR_FUNCTION.
value.function.actual and value.function.name are in that case pointers,
but value._mp_alloc and value._mp_size are 4 byte integers no matter what.
So, in 64-bit little-endian the function returns most of the time incorrect
CHARACTER(0) because the most significant 32 bits of the
value.function.actual pointer are likely 0.
Anyway, the following patch is an attempt to get all the cases right.
Uses ex->value.character.length only for ex->expr_type == EXPR_CONSTANT
(i.e. CHARACTER literals), handles the deferred lengths, assumed lengths,
known constant lengths and finally if the length is something other,
just doesn't print it, i.e. prints just CHARACTER (for default kind)
or CHARACTER(KIND=4) (for e.g. kind 4).

2020-11-11  Jakub Jelinek  

PR fortran/97768
gcc/fortran/
* misc.c (gfc_typename): Use ex->value.character.length only if
ex->expr_type == EXPR_CONSTANT.  If ex->ts.deferred, print :
instead
of length.  If ex->ts.u.cl && ex->ts.u.cl->length == NULL, print *
instead of length.  Otherwise if character length is non-constant,
print just CHARACTER or CHARACTER(KIND=N).
gcc/testsuite/
* gfortran.dg/pr97768_1.f90: New test.
* gfortran.dg/pr97768_2.f90: New test.

[Bug target/97784] Expressions evaluated as long chain instead of as tree or the like

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|target
 Target||powerpc

--- Comment #3 from Richard Biener  ---
There is targetm.sched.reassociation_width which specifies how re-assocation
should make such sequence "wide".  Andrew is correct that we don't do this
for any types that are TYPE_OVERFLOW_UNDEFINED.

And powerpc has

static int
rs6000_reassociation_width (unsigned int opc ATTRIBUTE_UNUSED,
machine_mode mode)
{
  switch (rs6000_tune)
{
case PROCESSOR_POWER8:
case PROCESSOR_POWER9:
case PROCESSOR_POWER10:
  if (DECIMAL_FLOAT_MODE_P (mode))
return 1;
  if (VECTOR_MODE_P (mode))
return 4;
  if (INTEGRAL_MODE_P (mode))
return 1;

thus you get width 1 which means a linear chain (even if the user wrote
a tree).

Note RTL doesn't do any such thing like re-assocation (I guess in principle
scheduling could, and that's the only place where it would make sense
on RTL).

[Bug rtl-optimization/97783] Optimizer assumes global static variable cannot be updated by external function, even though function is passed address of local functions

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Confirmed.  It's IPA reference that does not appropriately make the "local"
function gl_lstat global when it escapes in main to glob().

For some reason it doesn't reproduce with the simple

TU1:

void foo(void (**fn)())
{
  (*fn)();
}

TU2:

static int x;
static void bar() { x = 1; }
extern void foo(void (**)());
int
main ()
{
  void (*ptr)() = bar;
  x = 0;
  foo();
  if (x != 1)
__builtin_abort ();
  return 0;
}

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[admin at levyhsu dot com via Gcc-bugs]

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

Levy  changed:

   What|Removed |Added

  Attachment #49542|0   |1
is obsolete||

--- Comment #32 from Levy  ---
Created attachment 49543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49543=edit
QI/HI/SImode auto Zero/Sign-extend

Added one missing space at the end of the comment.
Added one tab before each brace.
Replace all tabs with space (come on)

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[admin at levyhsu dot com via Gcc-bugs]

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

Levy  changed:

   What|Removed |Added

  Attachment #49536|0   |1
is obsolete||

--- Comment #31 from Levy  ---
Created attachment 49542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49542=edit
QI/HI/SImode auto Zero/Sign-extend

Much appreciated Jim.

The new patch should solve the format issue by adding the same tabs on each
line.

In the meanwhile I'll try to patch the pass_shorten_memrefs::analyze() in
riscv-shorten-memrefs.c

Any idea on the combiner issue?

[Bug target/97779] [9/10 Regression] Newest releases/gcc-10 cannot build because lack of PTA_CLDEMOTE

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
Fixed in GCC10,GCC9.

[Bug target/96238] [i386] cpuid.h header needs include guards

[roland at gnu dot org via Gcc-bugs]

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

roland at gnu dot org changed:

   What|Removed |Added

 CC||roland at gnu dot org

--- Comment #4 from roland at gnu dot org ---
Can at least the header guard fix be backported to 10?

[Bug c++/97771] gcc/g++ failed to generate proper .init_array entries for local scope function, should create "axG", .init_array comdat

[erstrauss at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Erez Strauss  ---
Yes, thanks, the asm() works - but if it can be expressed in C++, why add the
dependency on assembly?

1. attribute constructor - fails to compile
2. placing the address into the .init_array fails to generate the proper code.
3. assembly is required for gcc, but not for clang.

I minimized the program by avoiding any include files, having three different
macros for the different options.
I would expect that gcc will handle correctly the first two options, as other
compilers do.

See https://godbolt.org/z/Mr1794  - for the three compilers: gcc clang icc


$ cat init_array_minimized.cpp

extern "C" int   write(int, const char *, long);
extern "C" unsigned long strlen(const char *);
extern "C" int   snprintf(char *, unsigned long, const char *, ...);

#define SIMPLE_LOCAL_FUNC_INIT_ARRAY() 
 \
do 
 \
{  
 \
struct Local   
 \
{  
 \
static void init() 
 \
{  
 \
char buffer[256];  
 \
snprintf(buffer, sizeof(buffer), "%p: %s:%d: %s\n",
(void*), __FILE__, __LINE__,  \
 __PRETTY_FUNCTION__); 
 \
write(1, buffer, strlen(buffer));  
 \
}  
 \
}; 
 \
static void *volatile initp __attribute__((__used__,
section(".init_array"))){(void *)::init}; \
} while (0)

#define SIMPLE_LOCAL_FUNC_CONSTRUCTOR()
 \
do 
 \
{  
 \
struct Local   
 \
{  
 \
static void init() __attribute__((constructor))
 \
{  
 \
char buffer[256];  
 \
snprintf(buffer, sizeof(buffer), "%p: %s:%d: %s\n",
(void*), __FILE__, __LINE__,  \
 __PRETTY_FUNCTION__); 
 \
write(1, buffer, strlen(buffer));  
 \
}  
 \
}; 
 \
} while (0)

#define SIMPLE_LOCAL_FUNC_INIT_ASM()   
 \
do 
 \
{  
 \
struct Local   
 \
{  
 \
static void init() 
 \
{  
 \
char buffer[256];  
 \
snprintf(buffer, sizeof(buffer), "%p: %s:%d: %s\n",
(void*), __FILE__, __LINE__,  \
 __PRETTY_FUNCTION__); 
 \
write(1, buffer, strlen(buffer));  
 \
}  
 \
}; 
 \
  __asm (".section .init_array, \"aw\",%%init_array; .balign %P0; .%P0byte %P1;
.previous" : : "i" (sizeof (void *)), "g" ((void*)::init)); \
} while (0)




//#define LOCAL_INIT_FUNC() SIMPLE_LOCAL_FUNC_INIT_ARRAY()
//#define LOCAL_INIT_FUNC() SIMPLE_LOCAL_FUNC_CONSTRUCTOR()
#define LOCAL_INIT_FUNC() SIMPLE_LOCAL_FUNC_INIT_ASM()



void funcA() {
LOCAL_INIT_FUNC();
LOCAL_INIT_FUNC();
}

inline void funcB() { LOCAL_INIT_FUNC(); }

template void funcT(int) { LOCAL_INIT_FUNC(); }

int main()
{

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[wilson at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #30 from Jim Wilson  ---
Looking at your v2 patch, the first verison fails because you are passing
mismatched modes to emit_move_insn.  The version with gen_lowpart solves that
problem, but fails because of infinite recursion.

The v4 patch looks good.  There are some coding style issues, but I can always
fix them for you.  There should be a space before open paren.  The first &&
should line up with the last two.  The braces should be indented two more
spaces.  The comment needs to end with a period and two spaces.

In the comment, instead of "Separate ... to ..." I'd say "Expand ... to ..." or
maybe "Emit ... as ...".

Now we need the copyright assignment paperwork.

[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Jonathan Wakely  ---
Untested patch:

--- a/libstdc++-v3/src/c++98/compatibility.cc
+++ b/libstdc++-v3/src/c++98/compatibility.cc
@@ -88,7 +88,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  __sb->__safe_gbump(__size);
  _M_gcount += __size;
- __c = __sb->sgetc();
+ if (_M_gcount < __n
+ || __n ==
__gnu_cxx::__numeric_traits::__max)
+   __c = __sb->sgetc();
}
  else
{


A similar change would be needed in the other versions of this function (the
wistream specialization, and the generic version).

[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #9 from ncm at cantrip dot org ---
(In reply to Jonathan Wakely from comment #8)
> Probably changed by one of the patches for PR 94749 or PR 96161, although I
> still see two reads for the first example.

Thank you, I was mistaken. This bug is still present in g++-10.

[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jonathan Wakely  ---
Probably changed by one of the patches for PR 94749 or PR 96161, although I
still see two reads for the first example.

[Bug c++/68703] __attribute__((vector_size(N))) template member confusion

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #9 from ncm at cantrip dot org ---
This bug appears not to manifest in g++-8, 9, and 10.

[Bug c++/66028] false positive, unused loop variable

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #2 from ncm at cantrip dot org ---
This bug appears not to manifest in g++-10.2.

[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #7 from ncm at cantrip dot org ---
This bug appears not to manifest in g++-10.

[Bug c++/58855] Attributes ignored on type alias in template

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #2 from ncm at cantrip dot org ---
This bug is still present in g++-10.2

[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates

[roland at gnu dot org via Gcc-bugs]

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

roland at gnu dot org changed:

   What|Removed |Added

 CC||roland at gnu dot org

--- Comment #12 from roland at gnu dot org ---
I think the correct behavior here is clear for ELF targets, which is what Clang
does.  Using section attributes always highly target-specific semantics, so I
think it would be fine for it to continue to behave as it does now for non-ELF
targets or to give a diagnostic.  With ELF COMDAT semantics, I think it's
straightforward and obviously consistent with general use of COMDAT what you'd
want here, so I don't see any controversy here.  Is this difficult to
implement?

[Bug target/97791] New: GNU attributes for long double could be improved on PowerPC

[meissner at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97791
   Summary: GNU attributes for long double could be improved on
PowerPC
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The long double gnu attributes on PowerPC are not quite correct.

If you have a function that returns __float128 when the ABI is IBM extended
double, it still sets gnu attribute #4 to 5 (i.e. h/w float, IBM 128-bit long
double).

Similarly if you have a function that returns __ibm128 when the ABI is IEEE
extended double, it still sets gnu attribute #4 to 13 (i.e. h/w float, IEEE
128-bit long double).

This is due to code in rs6000-call.c that treats any __float128 or __ibm128
function return or argument as passing long double.  Instead, it should only
set the attribute if the type used is long double.

Due to decisions made previously, where __ibm128 uses the long double type if
the default long double is IBM extended and __float128 uses the long double
type if the default long double is IEEE 128-bit, the gnu attribute will mirror
the long double type.  But if you use the non-default type, it should not
trigger setting the long double type.

Similarly if you just use a variable of the right type, even if it isn't the
official long double type, it will set the long double flag.  This is due to
code in rs6000_emit_move that checks the mode.  The rs6000_emit_move code is
too late to make this distinction, since it just has modes, and it does not
have access to the type node.

Similar issues exist if the default long double is set to 64 bits.

A simple fix is just to remove the code in rs6000_emit_move.  A more complete
fix would be insert a gimple pass that sees if the long double type was ever
used.

[Bug c++/97790] constexpr evaluation reports false positive memory leak

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Luke Dalessandro  ---
It is possible to workaround this bug by creating a symbol for the offending
allocation in the IILE. 

https://godbolt.org/z/jeoEra


```
struct vector {
int *data;
int n;
constexpr vector() : data(new int[1]{}), n(1) {}
constexpr ~vector() { delete [] data; }
};

struct Foo {
constexpr auto foo() const {
return vector();
}
};

template 
constexpr static auto bar() {
[] { 
auto temp = f.foo(); // <--  GIVE THIS A NAME
return temp.n; 
}();
return true;
}

constexpr Foo foo;
constexpr auto dd = bar();
```

[Bug c++/97790] New: constexpr evaluation reports false positive memory leak

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 97790
   Summary: constexpr evaluation reports false positive memory
leak
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

The constexpr evaluator seems to lose track of dynamic allocations in some
contexts, resulting in false-positive leaks and rejected valid code. 

This particular example uses an immediately invoked function expression
referencing an NTTP, which seems like a corner case but is actually extremely
common in two-pass constexpr algorithms (i.e., compute constexpr size of
result, then compute result to return).

https://godbolt.org/z/Tnn6xh

```
struct vector {
int *data;
int n;
constexpr vector() : data(new int[1]{}), n(1) {}
constexpr ~vector() { delete [] data; }
};

struct Foo {
constexpr auto foo() const {
return vector();
}
};

template 
constexpr static auto bar() {
[] { return f.foo().n; }();
return true;
}

constexpr Foo foo;
constexpr auto dd = bar();
```

[Bug c/97789] New: valgrind error with ./gcc.dg/c11-atomic-2.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97789
   Summary: valgrind error with ./gcc.dg/c11-atomic-2.c
   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: ---

For the C testsuite file ./gcc.dg/c11-atomic-2.c and recent
gcc trunk compiled with valgrind and
with compiler flag -O2, I get this:

$ /home/dcb/gcc/results.20201107.valgrind/bin/gcc -c -w -O2
./gcc.dg/c11-atomic-2.c
==640132== Invalid write of size 4
==640132==at 0xD63AE7: mark_deleted (tree-ssa-pre.c:594)
==640132==by 0xD63AE7: mark_deleted (hash-table.h:546)
==640132==by 0xD63AE7: clear_slot (hash-table.h:895)
==640132==by 0xD63AE7: phi_translate(bitmap_set*, pre_expr_d*, bitmap_set*,
bitmap_set*, edge_def*) (tree-ssa-pre.c:1745)

[Bug testsuite/97788] New: [11 regression] g++.dg/ubsan/pr61272.C fails after r11-4852

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97788
   Summary: [11 regression] g++.dg/ubsan/pr61272.C fails after
r11-4852
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:05b03452db6a520091aed254d3c399caed714b15, r11-4852

make  -k check-gcc RUNTESTFLAGS="ubsan.exp=g++.dg/ubsan/pr61272.C"

FAIL: g++.dg/ubsan/pr61272.C(test for errors, line 15)
FAIL: g++.dg/ubsan/pr61272.C   (test for excess errors)

# of expected passes2
# of unexpected failures2


spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-fsanitize=undefined -std=c++11 -S -o pr61272.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C: In
instantiation of 'struct
std::__gnu_cxx::__alloc_traits >
>':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C:20:156:  
required from 'struct
std::__gnu_cxx::_Vector_base,
std::allocator > >'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C:21:78:  
required from 'class std::__gnu_cxx::vector >'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C:24:33:  
required from here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C:18:25:
error: 'template decltype (_S_construct(__a, __p))
std::allocator_traits<_Alloc>::construct(_Alloc&, _Tp*) [with _Tp = _Tp; _Alloc
= std::allocator >]' is private within this
context
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C:10:38: note:
declared private here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C: In
instantiation of 'struct
std::__gnu_cxx::_Vector_base,
std::allocator > >':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C:21:78:  
required from 'class std::__gnu_cxx::vector >'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C:24:33:  
required from here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ubsan/pr61272.C:20:156:
error: no class template named 'rebind' in 'struct
std::__gnu_cxx::__alloc_traits > >'
compiler exited with status 1
PASS: g++.dg/ubsan/pr61272.C(test for warnings, line 10)
FAIL: g++.dg/ubsan/pr61272.C(test for errors, line 15)
PASS: g++.dg/ubsan/pr61272.C(test for errors, line 20)

[Bug c++/97518] Improving static_assert diagnostics

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Improved in GCC 11.

[Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[bunk at stusta dot de via Gcc-bugs]

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

Bug ID: 97787
   Summary: [10/11 regression] 64bit mips lto: .symtab local
symbol at index x (>= sh_info of y)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bunk at stusta dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

https://buildd.debian.org/status/fetch.php?pkg=dolfin=mips64el=2019.2.0~git20200629.946dbd3-4=1604936169=0

/usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -isystem
/<>/debian/tmp/usr/include -DVERSION_INFO=\"2019.2.0.dev0\" -O3
-DNDEBUG -flto -Wl,-z,relro -shared
-Wl,-soname,cpp.cpython-38-mips64el-linux-gnuabi64.so -o
../lib.linux-mips64-3.8/dolfin/cpp.cpython-38-mips64el-linux-gnuabi64.so
CMakeFiles/cpp.dir/src/dolfin.cpp.o CMakeFiles/cpp.dir/src/parameter.cpp.o
CMakeFiles/cpp.dir/src/adaptivity.cpp.o CMakeFiles/cpp.dir/src/ale.cpp.o
CMakeFiles/cpp.dir/src/common.cpp.o CMakeFiles/cpp.dir/src/fem.cpp.o
CMakeFiles/cpp.dir/src/function.cpp.o CMakeFiles/cpp.dir/src/generation.cpp.o
CMakeFiles/cpp.dir/src/geometry.cpp.o CMakeFiles/cpp.dir/src/graph.cpp.o
CMakeFiles/cpp.dir/src/log.cpp.o CMakeFiles/cpp.dir/src/math.cpp.o
CMakeFiles/cpp.dir/src/mesh.cpp.o CMakeFiles/cpp.dir/src/multistage.cpp.o
CMakeFiles/cpp.dir/src/ts.cpp.o CMakeFiles/cpp.dir/src/io.cpp.o
CMakeFiles/cpp.dir/src/la.cpp.o CMakeFiles/cpp.dir/src/nls.cpp.o
CMakeFiles/cpp.dir/src/refinement.cpp.o
CMakeFiles/cpp.dir/src/MPICommWrapper.cpp.o 
-Wl,-rpath,"/<>/debian/tmp/usr/lib/mips64el-linux-gnuabi64:/usr/lib/mips64el-linux-gnuabi64/hdf5/openmpi:/usr/lib/slepcdir/slepc3.14/mips64el-linux-gnuabi64-real/lib:/usr/lib/petscdir/petsc3.14/mips64el-linux-gnuabi64-real/lib:/usr/lib/mips64el-linux-gnuabi64/openmpi/lib"
"/<>/debian/tmp/usr/lib/mips64el-linux-gnuabi64/libdolfin.so.2019.2.0.dev0"
/usr/lib/mips64el-linux-gnuabi64/libboost_timer.so
/usr/lib/mips64el-linux-gnuabi64/libboost_chrono.so
/usr/lib/mips64el-linux-gnuabi64/hdf5/openmpi/libhdf5.so
/usr/lib/mips64el-linux-gnuabi64/libsz.so
/usr/lib/mips64el-linux-gnuabi64/libz.so
/usr/lib/mips64el-linux-gnuabi64/libdl.so
/usr/lib/mips64el-linux-gnuabi64/libm.so
/usr/lib/slepcdir/slepc3.14/mips64el-linux-gnuabi64-real/lib/libslepc_real.so
/usr/lib/petscdir/petsc3.14/mips64el-linux-gnuabi64-real/lib/libpetsc_real.so
/usr/lib/mips64el-linux-gnuabi64/openmpi/lib/libmpi_cxx.so
/usr/lib/mips64el-linux-gnuabi64/openmpi/lib/libmpi.so 
/usr/bin/ld:
/tmp/cpp.cpython-39-mips64el-linux-gnuabi64.so.1TtsmU.ltrans32.ltrans.o:
.symtab local symbol at index 214 (>= sh_info of 34)
/usr/bin/ld:
/tmp/cpp.cpython-39-mips64el-linux-gnuabi64.so.1TtsmU.ltrans32.ltrans.o: error
adding symbols: bad value

https://buildd.debian.org/status/fetch.php?pkg=bibletime=mips64el=3.0-2=1601887167=0

/usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -flto -fno-fat-lto-objects -Wl,-z,relro -Wl,-z,now
CMakeFiles/bibletime.dir/bibletime_autogen/mocs_compilation.cpp.o
CMakeFiles/bibletime.dir/src/frontend/BookmarkItem.cpp.o
CMakeFiles/bibletime.dir/src/frontend/BtMimeData.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bibletime.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bibletime_init.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bibletime_slots.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bibletimeapp.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookmarks/bteditbookmarkdialog.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookmarks/cbookmarkindex.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfinstallfinalpage.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelflanguagespage.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfremovefinalpage.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfsourcespage.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfsourcesprogresspage.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelftaskpage.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfwizard.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfwizardpage.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfworkspage.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btinstallpagemodel.cpp.o
CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/cswordsetupinstallsourcesdialog.cpp.o
CMakeFiles/bibletime.dir/src/frontend/btaboutdialog.cpp.o
CMakeFiles/bibletime.dir/src/frontend/btaboutmoduledialog.cpp.o
CMakeFiles/bibletime.dir/src/frontend/btbookshelfdockwidget.cpp.o
CMakeFiles/bibletime.dir/src/frontend/btbookshelfgroupingmenu.cpp.o
CMakeFiles/bibletime.dir/src/frontend/btbookshelfview.cpp.o

[Bug c++/97518] Improving static_assert diagnostics

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-4891-g8c0c83feb04d7486ccf9cbe86dcd5668f0a21ef9
Author: Marek Polacek 
Date:   Fri Nov 6 15:21:13 2020 -0500

c++: Improve static_assert diagnostic [PR97518]

Currently, when a static_assert fails, we only say "static assertion
failed".
It would be more useful if we could also print the expression that
evaluated to false; this is especially useful when the condition uses
template parameters.  Consider the motivating example, in which we have
this line:

  static_assert(is_same::value);

if this fails, the user has to play dirty games to get the compiler to
print the template arguments.  With this patch, we say:

  error: static assertion failed
  note: 'is_same::value' evaluates to false

which I think is much better.  However, always printing the condition that
evaluated to 'false' wouldn't be very useful: e.g. noexcept(fn) is
always parsed to true/false, so we would say "'false' evaluates to false"
which doesn't help.  So I wound up only printing the condition when it was
instantiation-dependent, that is, we called finish_static_assert from
tsubst_expr.

Moreover, this patch also improves the diagnostic when the condition
consists of a logical AND.  Say you have something like this:

  static_assert(fn1() && fn2() && fn3() && fn4() && fn5());

where fn4() evaluates to false and the other ones to true.  Highlighting
the whole thing is not that helpful because it won't say which clause
evaluated to false.  With the find_failing_clause tweak in this patch
we emit:

  error: static assertion failed
6 | static_assert(fn1() && fn2() && fn3() && fn4() && fn5());
  |  ~~~^~

so you know right away what's going on.  Unfortunately, when you combine
both things, that is, have an instantiation-dependent expr and && in
a static_assert, we can't yet quite point to the clause that failed.  It
is because when we tsubstitute something like is_same::value, we
generate a VAR_DECL that doesn't have any location.  It would be awesome
if we could wrap it with a location wrapper, but I didn't see anything
obvious.

In passing, I've cleaned up some things:
* use iloc_sentinel when appropriate,
* it's nicer to call contextual_conv_bool instead of the rather verbose
  perform_implicit_conversion_flags,
* no need to check for INTEGER_CST before calling integer_zerop.

gcc/cp/ChangeLog:

PR c++/97518
* cp-tree.h (finish_static_assert): Adjust declaration.
* parser.c (cp_parser_static_assert): Pass false to
finish_static_assert.
* pt.c (tsubst_expr): Pass true to finish_static_assert.
* semantics.c (find_failing_clause_r): New function.
(find_failing_clause): New function.
(finish_static_assert): Add a bool parameter.  Use
iloc_sentinel.  Call contextual_conv_bool instead of
perform_implicit_conversion_flags.  Don't check for INTEGER_CST
before
calling integer_zerop.  Call find_failing_clause and maybe use its
location.  Print the original condition or the failing clause if
SHOW_EXPR_P.

gcc/testsuite/ChangeLog:

PR c++/97518
* g++.dg/diagnostic/pr87386.C: Adjust expected output.
* g++.dg/diagnostic/static_assert1.C: New test.
* g++.dg/diagnostic/static_assert2.C: New test.

libcc1/ChangeLog:

PR c++/97518
* libcp1plugin.cc (plugin_add_static_assert): Pass false to
finish_static_assert.

[Bug c++/89565] [C++2a] ICE on template instantiating user defined non-type template from template value member

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-4890-ga210d404d08e363af4b2e2a60986c3cb08f8ebc5
Author: Marek Polacek 
Date:   Tue Nov 10 14:57:19 2020 -0500

c++: Add 5 unfixed tests.

A couple of dg-ice tests.

gcc/testsuite/ChangeLog:

PR c++/52830
PR c++/88982
PR c++/90799
PR c++/87765
PR c++/89565
* g++.dg/cpp0x/constexpr-52830.C: New test.
* g++.dg/cpp0x/vt-88982.C: New test.
* g++.dg/cpp1z/class-deduction76.C: New test.
* g++.dg/cpp1z/constexpr-lambda26.C: New test.
* g++.dg/cpp2a/nontype-class39.C: New test.

[Bug c++/90799] noexcept specification dependent on template argument throws internal compiler error when trying to deduce it from a function argument

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-4890-ga210d404d08e363af4b2e2a60986c3cb08f8ebc5
Author: Marek Polacek 
Date:   Tue Nov 10 14:57:19 2020 -0500

c++: Add 5 unfixed tests.

A couple of dg-ice tests.

gcc/testsuite/ChangeLog:

PR c++/52830
PR c++/88982
PR c++/90799
PR c++/87765
PR c++/89565
* g++.dg/cpp0x/constexpr-52830.C: New test.
* g++.dg/cpp0x/vt-88982.C: New test.
* g++.dg/cpp1z/class-deduction76.C: New test.
* g++.dg/cpp1z/constexpr-lambda26.C: New test.
* g++.dg/cpp2a/nontype-class39.C: New test.

[Bug c++/87765] Internal compiler error: coerce_template_parms (8.2) or cxx_eval_constant_expression (trunk)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-4890-ga210d404d08e363af4b2e2a60986c3cb08f8ebc5
Author: Marek Polacek 
Date:   Tue Nov 10 14:57:19 2020 -0500

c++: Add 5 unfixed tests.

A couple of dg-ice tests.

gcc/testsuite/ChangeLog:

PR c++/52830
PR c++/88982
PR c++/90799
PR c++/87765
PR c++/89565
* g++.dg/cpp0x/constexpr-52830.C: New test.
* g++.dg/cpp0x/vt-88982.C: New test.
* g++.dg/cpp1z/class-deduction76.C: New test.
* g++.dg/cpp1z/constexpr-lambda26.C: New test.
* g++.dg/cpp2a/nontype-class39.C: New test.

[Bug c++/88982] ICE in tsubst_pack_expansion, at cp/pt.c:12221

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-4890-ga210d404d08e363af4b2e2a60986c3cb08f8ebc5
Author: Marek Polacek 
Date:   Tue Nov 10 14:57:19 2020 -0500

c++: Add 5 unfixed tests.

A couple of dg-ice tests.

gcc/testsuite/ChangeLog:

PR c++/52830
PR c++/88982
PR c++/90799
PR c++/87765
PR c++/89565
* g++.dg/cpp0x/constexpr-52830.C: New test.
* g++.dg/cpp0x/vt-88982.C: New test.
* g++.dg/cpp1z/class-deduction76.C: New test.
* g++.dg/cpp1z/constexpr-lambda26.C: New test.
* g++.dg/cpp2a/nontype-class39.C: New test.

[Bug c++/52830] ICE: "canonical types differ for identical types ..." when attempting SFINAE with member type

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-4890-ga210d404d08e363af4b2e2a60986c3cb08f8ebc5
Author: Marek Polacek 
Date:   Tue Nov 10 14:57:19 2020 -0500

c++: Add 5 unfixed tests.

A couple of dg-ice tests.

gcc/testsuite/ChangeLog:

PR c++/52830
PR c++/88982
PR c++/90799
PR c++/87765
PR c++/89565
* g++.dg/cpp0x/constexpr-52830.C: New test.
* g++.dg/cpp0x/vt-88982.C: New test.
* g++.dg/cpp1z/class-deduction76.C: New test.
* g++.dg/cpp1z/constexpr-lambda26.C: New test.
* g++.dg/cpp2a/nontype-class39.C: New test.

[Bug libstdc++/97415] Invalid pointer comparison in stringbuf::str() (reported by pointer-compare AddressSanitizer)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-4887-gced70ebaa372945ec8d73703d81e4a10d6d51c9b
Author: Jonathan Wakely 
Date:   Tue Nov 10 15:46:02 2020 +

libstdc++: Fix more unspecified comparisons to null pointer [PR 97415]

This adds some more null checks to avoid a relational comparison with a
null pointer, similar to 78198b6021a9695054dab039340202170b88423c.

libstdc++-v3/ChangeLog:

PR libstdc++/97415
* include/std/sstream (basic_stringbuf::_M_update_egptr)
(basic_stringbuf::__xfer_bufptrs::__xfer_bufptrs): Check for
null before comparing pointers.

[Bug target/97786] New: rs6000 isinf etc. are pretty horrible

[segher at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97786
   Summary: rs6000 isinf etc. are pretty horrible
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

int isfinite(double x) { return __builtin_isfinite (x); }
int isinf(double x) { return __builtin_isinf (x); }
int isinf_sign(double x) { return __builtin_isinf_sign (x); }
int isnan(double x) { return __builtin_isnan (x); }
int isnormal(double x) { return __builtin_isnormal (x); }
int fpclassify(double x) { return __builtin_fpclassify (5, 6, 7, 8, 9, x); }

We can generate much better code for all these than the generic code
we use now.

[Bug rtl-optimization/97784] Expressions evaluated as long chain instead of as tree or the like

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Segher Boessenkool  ---
No, it is exactly the same with unsigned types :-(

Use  -Dlong="unsigned long"  or use  #define O ^  (as in my original test).
I forgot about this signed thing, but it has nothing to do with it (that
matters on gimple level, sure, but the problem exists in pure RTL as well).

[Bug c++/56842] Argument deduction failure note is empty for alias template

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed by r270433 for PR c++/90047 - ICE with enable_if alias template.

[Bug c++/85979] Diagnostic says "__alignof" when the source says "alignof"

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-11-10
 Status|UNCONFIRMED |ASSIGNED
 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug c++/65943] template keyword required for base-specifier that names member of the current instantiation

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed by r10-7403 for PR c++/94057

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

[Bug c++/94057] [9 Regression] -std=gnu++20 causes failure naming nested templated class since r9-4536

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #8 from Jonathan Wakely  ---
*** Bug 65943 has been marked as a duplicate of this bug. ***

[Bug c++/97785] const_cast shows diagnostic about Y*

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  First, build_const_cast_1 should use 'reference_type' when it's
non-null; second, for diagnostic, we should use src_type prior it was adjusted
by build_pointer_type.

[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2016-05-26 00:00:00 |2020-11-10

--- Comment #4 from Jonathan Wakely  ---
Complete testcase:

#include 

struct S1 {
  unsigned int x;
  floaty;
  struct S1   *z;
};


struct S1 *f1(void) {
  struct S1 *p = malloc(sizeof(p));  // diagnostic required
  return p;
}


It would probably make sense to not only warn for malloc, but also for other
functions with __attribute__((malloc)) and __attribute__((alloc_size(n))) where
n!=sizeof(*p). That would also help for xmalloc and similar wrappers in gcc and
glibc.

[Bug c++/97785] New: const_cast shows diagnostic about Y*

[redi at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97785
   Summary: const_cast shows diagnostic about Y*
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct X { };
struct Y { };

X x;
Y& y = const_cast(x);



cc.cc:5:8: error: invalid ‘const_cast’ from type ‘X*’ to type ‘const Y*’
5 | Y& y = const_cast(x);
  |^~~


There is no X* or Y* here.

[Bug rtl-optimization/97784] Expressions evaluated as long chain instead of as tree or the like

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Reassociation is done for signed types and places where it could introduce
overflows.

If you -fwrapv, you should get the optimization. Likewise for unsigned types.

[Bug rtl-optimization/97784] New: Expressions evaluated as long chain instead of as tree or the like

[segher at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97784
   Summary: Expressions evaluated as long chain instead of as tree
or the like
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

When compiling something like

#define O +
long x4(long x, long a, long b, long c, long d) { return x O a O b O c O d; }

we end up with machine code like

add 3,3,4# 10   [c=4 l=4]  *adddi3/0
add 3,3,5# 11   [c=4 l=4]  *adddi3/0
add 3,3,6# 12   [c=4 l=4]  *adddi3/0
add 3,3,7# 18   [c=4 l=4]  *adddi3/0
blr  # 30   [c=4 l=4]  simple_return

Every of those "add" insns depends on the result of the previous one,
making this slower than necessary: it has the latency of 4 add insns in
series, while some can be done in parallel.


This problem is there on gimple level already:

  _1 = x_4(D) + a_5(D);
  _2 = _1 + b_6(D);
  _3 = _2 + c_7(D);
  _9 = _3 + d_8(D);
  return _9;


A very similar problem also happens as a result of RTL unrolling.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #10 from John Paul Adrian Glaubitz  ---
(In reply to abebeos from comment #9)
> So, if it's ok for the backers, reduce the scope of the bounty to "just get
> avr into gcc11 and keep generated code as much as possible unchanged".

It would be gcc11 and beyond that, not just gcc11.

FWIW, I talked to multiple GCC developers and they confirmed that converting
the target to MODE_CC should be possible.

The main problem is apparently that the target hasn't been properly worked on
for a long time.

Also, be aware that there are others working on this such as:

> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551504.html

Good luck!

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

abebeos at lazaridis dot com changed:

   What|Removed |Added

 CC||abebeos at lazaridis dot com

--- Comment #9 from abebeos at lazaridis dot com ---
Looking into this since a few days. All looks that B.S. statements seem valid:

https://gcc.gnu.org/pipermail/gcc/2020-April/000455.html

The bounty goal should be similar to "Convert m68k to not use cc0":

=> Convert avr to not use cc0 (thus it can be included to gcc11).

So, the requirements would be:

- must not use cc0
- keep generated code as much as possible identical (= avoid trouble and
follow-up work)
- use of MODE_CC constructs is optional

-

P.S.: It looks like previous work on this from "pipcet" got stuck, possibly
exactly due to the complexity that a larger one-chunk-change introduces,
especially when the resulting generated code changes much:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c6

So, if it's ok for the backers, reduce the scope of the bounty to "just get avr
into gcc11 and keep generated code as much as possible unchanged".

[Bug rtl-optimization/97783] Optimizer assumes global static variable cannot be updated by external function, even though function is passed address of local functions

[quentin at armitage dot org.uk via Gcc-bugs]

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

--- Comment #1 from Quentin Armitage  ---
I don't know if the following addition output from gcc -v when compiling
glob_err.c is useful:

COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-D' 'TEST1' '-o' 'glob_err'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/10/cc1 -E -quiet -v -D TEST1 glob_err.c
-mtune=generic -march=x86-64 -O1 -fpch-preprocess -o glob_err.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/10/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/10/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-D' 'TEST1' '-o' 'glob_err'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/10/cc1 -fpreprocessed glob_err.i -quiet
-dumpbase glob_err.c -mtune=generic -march=x86-64 -auxbase glob_err -O1
-version -o glob_err.s
GNU C17 (GCC) version 10.2.1 20201016 (Red Hat 10.2.1-6) (x86_64-redhat-linux)
compiled by GNU C version 10.2.1 20201016 (Red Hat 10.2.1-6), GMP
version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version
isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 10.2.1 20201016 (Red Hat 10.2.1-6) (x86_64-redhat-linux)
compiled by GNU C version 10.2.1 20201016 (Red Hat 10.2.1-6), GMP
version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version
isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: abdc7099d3f7dcdac32d7a56c3312bc2
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-D' 'TEST1' '-o' 'glob_err'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o glob_err.o glob_err.s
GNU assembler version 2.35 (x86_64-redhat-linux) using BFD version version
2.35-14.fc33
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/10/:/usr/libexec/gcc/x86_64-redhat-linux/10/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/10/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/10/:/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/10/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-D' 'TEST1' '-o' 'glob_err'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/10/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
-plugin-opt=-fresolution=glob_err.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o glob_err
/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/10/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/10
-L/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/10/../../.. glob_err.o
-lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state
--as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-redhat-linux/10/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64/crtn.o
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-D' 'TEST1' '-o' 'glob_err'
'-mtune=generic' '-march=x86-64'

[Bug rtl-optimization/97783] New: Optimizer assumes global static variable cannot be updated by external function, even though function is passed address of local functions

[quentin at armitage dot org.uk via Gcc-bugs]

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

Bug ID: 97783
   Summary: Optimizer assumes global static variable cannot be
updated by external function, even though function is
passed address of local functions
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: quentin at armitage dot org.uk
  Target Milestone: ---

Created attachment 49541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49541=edit
The preprocessed glob_err.i file

The attached code, when compiled with -O1 outputs: 

glob(/tmp/zz{a,b}.conf) returned 3, missing files 0
glob(/tmp/zz{a,b}.conf) returned 3, missing files 2

When compiled with -O0, the following is output:
glob(/tmp/zz{a,b}.conf) returned 3, missing files 2
glob(/tmp/zz{a,b}.conf) returned 3, missing files 2

Since the two fprintf statements (lines 40 and 41) generating the two lines of
output are consecutive statements, and no variables are altered in the calls to
fprintf, the output when using -O1 is incorrect.

It appears that when compiled with -O1 or higher levels of optimisation, if the
missing_files variable is accessed prior to another function call following the
return from the call to open_and_check_glob(), then the value used is 0; if
there is any intermediate function call before missing_files is accessed, then
the correct value is used.

If missing_files is not declared static, or if it is declared static volatile,
then the problem does not occur. The problem also does not occur if the
statement (at line 36)
missing_files = 0;
is deleted.

The versions of gcc given below are using the latest version I have installed.
If have also tested this on Fedora 31 x86_64 with gcc version 9.3.1, Debian 10
(Buster) 32 bit armv7l, and Debian 10 aarch64 (both with gcc version 8.3.0),
and all exhibit exactly the same behaviour.

the exact version of GCC
the system type
the options given when GCC was configured/built


This is from a Fedora 33 x86_64 system:

Output of gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20201016 (Red Hat 10.2.1-6) (GCC) 


the complete command line that triggers the bug
===
Ensure that /tmp/azz.conf and /tmp/bzz.conf do not exist:
./glob_err "/tmp/{a,b}zz.conf"

the compiler output (error messages, warnings, etc.)

None


the preprocessed file (*.i*) that triggers the bug
==
Attached

[Bug c/97748] Preincrement of _Complex gives bogus warning = "value computed is not used"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-4878-gea4fb4eaacbd2c954d78d7f8e9f03c7be739
Author: Jakub Jelinek 
Date:   Tue Nov 10 15:56:20 2020 +0100

c, c++: Fix up -Wunused-value on COMPLEX_EXPRs [PR97748]

The -Wunused-value warning in both C and C++ FEs (implemented
significantly differently between the two) sees the COMPLEX_EXPRs created
e.g. for complex pre/post increment and many other expressions as useless
and warns about it.

For the C warning implementation, on e.g.
COMPLEX_EXPR < ++REALPART_EXPR , IMAGPART_EXPR >;
would warn even on the IMAGPART_EXPR  there alone etc., so what works
is check if we'd warn about both operands of COMPLEX_EXPR and if yes,
warn on the whole COMPLEX_EXPR, otherwise don't warn.

The C++ warning implementation is significantly different and for that one
the only warn if both would be warned about doesn't really work,
we then miss warnings e.g. about
COMPLEX_EXPR > + 1.0e+0, IMAGPART_EXPR
>> >
The patch replaces the warning_at call with call to the c-family
warn_if_unused_value function.

On the testcase which after the initial new tests contains pretty much
everything from gcc.dg/Wunused-value-1.c both approaches seem to work
nicely.

2020-11-10  Jakub Jelinek  

PR c/97748
gcc/c-family/
* c-common.h (warn_if_unused_value): Add quiet argument defaulted
to false.
* c-warn.c (warn_if_unused_value): Likewise.  Pass it down
recursively and just return true instead of warning if it is true.
Handle COMPLEX_EXPR.
gcc/cp/
* cvt.c (convert_to_void): Check (complain & tf_warning) in the
outer
if rather than twice times in the inner one.  Use
warn_if_unused_value.
Formatting fix.
gcc/testsuite/
* c-c++-common/Wunused-value-1.c: New test.

[Bug c++/97771] gcc/g++ failed to generate proper .init_array entries for local scope function, should create "axG", .init_array comdat

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
That is about the assembler warning (which isn't fatal though); for the uses in
inline functions or templates anothing thing is that the comdat sections from
comdat take priority over the section attribute.
Now, when assembler doesn't support comdat groups, there is really no way
around it, section attribute has to be ignored and one needs to use
.gnu.linkonce.* etc. sections, because otherwise it wouldn't act as comdat.
With comdat groups, we could use the section name from the section attribute
and just put it into the comdat group, but don't do that.

[Bug c++/97771] gcc/g++ failed to generate proper .init_array entries for local scope function, should create "axG", .init_array comdat

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
What you are doing is certainly wrong.  .init_array section needs to be
@init_array,
there is no way to create initialized variables in anything but @progbits.
The section attribute doesn't have any list of magic sections that should be
treated differently from anything else.
constructor attribute indeed is only allowed on file-scope functions.
Why don't you use inline asm?
I'd suggest
__asm (".section .init_array, \"aw\",%%init_array; .balign %P0;
.%P0byte %P1; .previous" : : "i" (sizeof (void *)), "g" ((void
*)::init));
instead of your initp declaration.

[Bug fortran/97782] [Fortran] Confused location information for OpenACC compute constructs

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Tobias Burnus  ---
Technically, the issue is (was): The input_location is used which is obtained
when finishing the the block (= '!$acc end kernels') - or rather whatever comes
before and bumps the line location.

[Bug fortran/97782] [Fortran] Confused location information for OpenACC compute constructs

[burnus at gcc dot gnu.org via Gcc-bugs]

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

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

There are probably more – like 'omp sections', 'omp parallel', if I glanced at
it correctly. (Search for 'input_location' after 'gfc_trans_omp_code'.)

[Bug c++/97771] gcc/g++ failed to generate proper .init_array entries for local scope function, should create "axG", .init_array comdat

[erstrauss at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Erez Strauss  ---
Thanks, I tried, it fails with:

$ g++ -O2 -std=c++20 init_array5c.cpp -o init_array5c
init_array5c.cpp: In function ‘void localFunc(const char*)’:
init_array5c.cpp:17:55: warning: ‘constructor’ attribute ignored [-Wattributes]
   17 | static void init() __attribute__((constructor))
  |   ^
===
$ ./init_array5c
main() started
post-main-start: X1 init_array5c.cpp 37 : 0x4041d4 count: 1 void
localFunc(const char*) [with const
std::experimental::fundamentals_v2::source_location& X = s]
post-main-start: X2 init_array5c.cpp 38 : 0x4041dc count: 1 void
localFunc(const char*) [with const
std::experimental::fundamentals_v2::source_location& X = s]
===

clang++ accepts correctly the attribute:
$ clang++ -O2 -std=c++20 init_array5c.cpp -o init_array5c
===
$ ./init_array5c
pre-main-start init from localFunc: init_array5c.cpp 37 : 0x4041d8 count:
1 okFunc1 / static void localFunc(const char *)::Local::init()
pre-main-start init from localFunc: init_array5c.cpp 38 : 0x4041dc count:
1 okFunc2 / static void localFunc(const char *)::Local::init()
main() started
post-main-start: X1 init_array5c.cpp 37 : 0x4041d8 count: 2 void
localFunc(const char *) [X = s]
post-main-start: X2 init_array5c.cpp 38 : 0x4041dc count: 2 void
localFunc(const char *) [X = s]

===

$ cat init_array5c.cpp
#include 
#include 

using namespace std::experimental;

template
void localFunc(const char* name)
{
static int count{0};
volatile ::std::ios_base::Init dummy{};
std::cout << "post-main-start: " << name << " " << X.file_name() << " " <<
X.line()
  << " : " << (void*) << " count: " << (++count) << " "
  << __PRETTY_FUNCTION__ << std::endl;

struct Local
{
static void init() __attribute__((constructor))
{
volatile ::std::ios_base::Init dummy{};
std::cout << "pre-main-start init from localFunc: " <<
X.file_name() << " "
  << X.line() << " : " << (void*)
  << " count: " << (++count) << " " << X.function_name() <<
" / " << __PRETTY_FUNCTION__
  << std::endl;
}
};

//static void* volatile initp __attribute__((__used__,
section(".init_array"))){(void*)::init};
}

#define LOCAL_FUNC(NAME)  \
do\
{ \
constexpr static auto s = source_location::current(); \
localFunc((const char*)&(NAME)[0]);\
} while (0)

void okFunc1() { LOCAL_FUNC("X1"); }
inline void okFunc2() { LOCAL_FUNC("X2"); }

int main()
{
std::cout << "main() started" << std::endl;
okFunc1();
okFunc2();
return 0;
}

[Bug c++/64194] [C++14] for function template with auto return

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||janezz55 at gmail dot com

--- Comment #14 from Jonathan Wakely  ---
*** Bug 97778 has been marked as a duplicate of this bug. ***

[Bug c++/97778] return type not deduced with gcc but get deduced with clang

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Reduced:

template 
struct hash
{
  auto operator()(T) const noexcept
  {
return 0;
  }
};

template 
auto hash_combine(T&& ...) noexcept
{
  return 0;
}

template
struct tuple
{
};

template
auto
apply(F, tuple)
{
}

template 
struct hash>
{
  auto operator()(tuple t) const
  {
return apply(hash_combine, t);
  }
};

int main()
{
  using T = tuple;
  hash h;
  T t;
  h(t);
}

Confirmed as fixed by r11-2420 which fixed PR c++/64194

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

[Bug fortran/97782] New: [Fortran] Confused location information for OpenACC compute constructs

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97782
   Summary: [Fortran] Confused location information for OpenACC
compute constructs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: burnus at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

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

Tobias, please see the '-fdump-tree-original-lineno' dump of the testcase I'm
attaching.  Instead of expected line 9, the '#pragma acc kernels' has location
information for line 18, which happens to be the second '#pragma acc loop'. 
The same happens for other OpenACC compute constructs.  I have not checked
OpenMP.

Amongst other things, this confuses the '-fopt-info-omp-all' checking (that
one's specific to OpenACC 'kernels').

[Bug c++/97778] return type not deduced with gcc but get deduced with clang

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jonathan Wakely  ---
Looks like a dup of PR 64194, checking ...

[Bug middle-end/97769] [11 Regression] vectorizer ICE when building perlbench in SPECCPU 2017

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Tamar Christina  ---
Thanks Richi!

[Bug middle-end/97769] [11 Regression] vectorizer ICE when building perlbench in SPECCPU 2017

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug middle-end/97769] [11 Regression] vectorizer ICE when building perlbench in SPECCPU 2017

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:1693746302e4306b43cb66a0afe589137069bd8e

commit r11-4877-g1693746302e4306b43cb66a0afe589137069bd8e
Author: Richard Biener 
Date:   Tue Nov 10 13:36:22 2020 +0100

tree-optimization/97769 - fix assert in peeling for alignment

The following removes an assert that can not easily be adjusted to
cover the additional cases we now handle after the removal of
the same-align DRs vector.

2020-11-10  Richard Biener  

PR tree-optimization/97769
* tree-vect-data-refs.c (vect_update_misalignment_for_peel):
Remove assert.

* gcc.dg/vect/pr97769.c: New testcase.

[Bug middle-end/97769] [11 Regression] vectorizer ICE when building perlbench in SPECCPU 2017

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
OK, it's just an overzealeous assert that is too difficult to update for the
additional cases we now handle.  I'll remove it.

[Bug target/97779] [9/10 Regression] Newest releases/gcc-10 cannot build because lack of PTA_CLDEMOTE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-10
   Target Milestone|--- |9.4
 Target||x86_64-*-* i?86-*-*
 Ever confirmed|0   |1
   Priority|P3  |P1
Summary|Newest releases/gcc-10  |[9/10 Regression] Newest
   |cannot build because lack   |releases/gcc-10 cannot
   |of PTA_CLDEMOTE |build because lack of
   ||PTA_CLDEMOTE
 Status|UNCONFIRMED |NEW
   Keywords||build

--- Comment #3 from Richard Biener  ---
(In reply to Hongtao.liu from comment #1)
> Mine, also similar issue happened in release/gcc-9 branch
> 
> I'm working on this, sorry for the inconvenience.

When you do backporting you _always_ need to bootstrap & regtest on the
respective branch(es).

[Bug libstdc++/97781] New: basic_stringbuf::swap is not exception safe

[redi at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97781
   Summary: basic_stringbuf::swap is not exception safe
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

If swapping the strings throws, the rest of the state has already been swapped,
and the __xfer_bufptrs guards will make further changes.

Swapping the strings should be done first, and __xfer_bufptrs can't be used.

[Bug tree-optimization/97780] [11 Regression] ICE Segmentation fault since r11-4831-g17c25a454e056f46

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed.

[Bug tree-optimization/97780] [11 Regression] ICE Segmentation fault since r11-4831-g17c25a454e056f46

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:960c4712c8e1e08f29af999d4198bd96fcccb93c

commit r11-4876-g960c4712c8e1e08f29af999d4198bd96fcccb93c
Author: Richard Biener 
Date:   Tue Nov 10 13:06:08 2020 +0100

tree-optimization/97780 - fix ICE in fini_pre

This deals with blocks elimination added.

2020-11-10  Richard Biener  

PR tree-optimization/97780
* tree-ssa-pre.c (fini_pre): Deal with added basic blocks
when freeing PHI_TRANS_TABLE.

[Bug target/97779] Newest releases/gcc-10 cannot build because lack of PTA_CLDEMOTE

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
patch posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558578.html

[Bug target/97779] Newest releases/gcc-10 cannot build because lack of PTA_CLDEMOTE

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
Mine, also similar issue happened in release/gcc-9 branch

I'm working on this, sorry for the inconvenience.

[Bug c++/97778] return type not deduced with gcc but get deduced with clang

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Janez Zemva  ---
t.cpp:57:22: error: no matching function for call to 'apply(, const std::tuple >, std::chrono::time_point > >,
std::basic_string_view > >&)'
   57 | return std::apply(hash_combine, t);
  |~~^~
In file included from /usr/include/c++/10.2.0/functional:54,
 from t.cpp:3:
/usr/include/c++/10.2.0/tuple:1729:5: note: candidate: 'template constexpr decltype(auto) std::apply(_Fn&&, _Tuple&&)'
 1729 | apply(_Fn&& __f, _Tuple&& __t)
  | ^
/usr/include/c++/10.2.0/tuple:1729:5: note:   template argument
deduction/substitution failed:
t.cpp:57:22: note:   couldn't deduce template parameter '_Fn'
   57 | return std::apply(hash_combine, t);
  |~~^~

[Bug tree-optimization/97780] New: [11 Regression] ICE Segmentation fault since r11-4831-g17c25a454e056f46

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97780
   Summary: [11 Regression] ICE Segmentation fault since
r11-4831-g17c25a454e056f46
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr69141.C
-fno-tree-fre -O2 -fno-tree-dominator-opts -c
during GIMPLE pass: pre
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr69141.C: In constructor
‘B::B()’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/opt/pr69141.C:12:1: internal
compiler error: Segmentation fault
   12 | B::B () : b (this)
  | ^
0x102a07f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:330
0x77889d1f ???
   
/usr/src/debug/glibc-2.32-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x11bc69f fini_pre
/home/marxin/Programming/gcc/gcc/tree-ssa-pre.c:4204
0x11bc69f execute
/home/marxin/Programming/gcc/gcc/tree-ssa-pre.c:4325
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97780] [11 Regression] ICE Segmentation fault since r11-4831-g17c25a454e056f46

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.2.0
  Known to fail||11.0
 Ever confirmed|0   |1
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
   Last reconfirmed||2020-11-10

[Bug target/97779] New: Newest releases/gcc-10 cannot build because lack of PTA_CLDEMOTE

[icenowy at aosc dot io via Gcc-bugs]

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

Bug ID: 97779
   Summary: Newest releases/gcc-10 cannot build because lack of
PTA_CLDEMOTE
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: icenowy at aosc dot io
  Target Milestone: ---

When building GCC commit 454702f5213a7a8b6b3581c29c817b952ce0f184 on x86-64
natively, I met this failure:

```
In file included from ./tm.h:26,
 from
/var/cache/acbs/build/acbs.ctuyh9m4/gcc/gcc/gencheck.c:23:
/var/cache/acbs/build/acbs.ctuyh9m4/gcc/gcc/config/i386/i386.h:2481:46: error:
'PTA_CLDEMOTE' was not declared in this scope; did you mean 'PTA_CLZERO'?
 2481 |   | PTA_GFNI | PTA_MOVDIRI | PTA_MOVDIR64B | PTA_CLDEMOTE |
PTA_WAITPKG;
  |  ^~~~
  |  PTA_CLZERO
/var/cache/acbs/build/acbs.ctuyh9m4/gcc/gcc/config/i386/i386.h:2480:24:
warning: 'PTA_TREMONT' defined but not used [-Wunused-variable]
 2480 | const wide_int_bitmask PTA_TREMONT = PTA_GOLDMONT_PLUS | PTA_CLWB
  |^~~
```

This seems to be a issue of commit 3ec6a380bda3d2193925e1c017ea2739476cc125 ,
which adds this macro to PTA_TREMONT.

[Bug c++/97778] return type not deduced with gcc but get deduced with clang

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Janez Zemva  ---
oh, once, again, -std=c++20

[Bug c++/97778] New: return type not deduced with gcc but get deduced with clang

[janezz55 at gmail dot com via Gcc-bugs]

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

Bug ID: 97778
   Summary: return type not deduced with gcc but get deduced with
clang
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janezz55 at gmail dot com
  Target Milestone: ---

Created attachment 49538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49538=edit
bug

Ok, here we go again: does not compile with gcc version 10.2.0, does compile
with clang version 10.0.1.

Changing auto to std::size_t of hash_combine() fixes the problem.

[Bug rtl-optimization/97777] New: ICE: in df_refs_verify, at df-scan.c:3991 with -O -ffinite-math-only -fzero-call-used-regs=all

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 9
   Summary: ICE: in df_refs_verify, at df-scan.c:3991 with -O
-ffinite-math-only -fzero-call-used-regs=all
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

The compiler is configured with --enable-checking=yes,rtl,df,extra

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -ffinite-math-only -fzero-call-used-regs=all
testcase.c
during RTL pass: zero_call_used_regs
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in df_refs_verify, at df-scan.c:3991
5 | }
  | ^
0x63bf73 df_refs_verify
/repo/gcc-trunk/gcc/df-scan.c:3991
0xbd44a6 df_insn_refs_verify
/repo/gcc-trunk/gcc/df-scan.c:4074
0xbd644c df_bb_verify
/repo/gcc-trunk/gcc/df-scan.c:4107
0xbd6807 df_scan_verify()
/repo/gcc-trunk/gcc/df-scan.c:4228
0xbc0757 df_verify()
/repo/gcc-trunk/gcc/df-core.c:1818
0xbc0757 df_analyze_1
/repo/gcc-trunk/gcc/df-core.c:1214
0xce77ec execute
/repo/gcc-trunk/gcc/function.c:6656
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug c++/97776] [C/C++][OpenMP] 'error: array section is not contiguous in ‘map’ clause' for: map(alloc: p[i][0:C])

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jakub Jelinek  ---
As p is array of pointers, if it was say p[i:2][0:C] it would be
non-contiguous, but in this particular case, while such array sections are
blurry (because
the array section describes the p[i][0], p[i][1] etc. (contiguous) as well as
the p[i] pointer that points to it), I agree it should be probably accepted.

That said, we really need to rewrite the array section handling completely in
the C/C++ FEs, such that rather than having just a special case we just set
some parser flag that array sections are allowed and during parsing of [ ... ]
if that flag is on we also parse the :s in there and create a new
ARRAY_SECTION_REF or similar, and then only later on verify that the array
section is where it can be specified and deal also with the non-contiguous
to/from etc.

[Bug c++/97776] New: [C/C++][OpenMP] 'error: array section is not contiguous in ‘map’ clause' for: map(alloc: p[i][0:C])

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97776
   Summary: [C/C++][OpenMP] 'error: array section is not
contiguous in ‘map’ clause' for: map(alloc: p[i][0:C])
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

The following is rejected by gcc/g++ with:
  error: array section is not contiguous in ‘map’ clause 

This  map(alloc: p[i][0:C]) is accepted by clang/clang++ and I also do not see
why it is not contiguous.

Found at:
https://github.com/clang-ykt/omptests/blob/master/t-array-of-ptr/test.cpp
and
https://github.com/clang-ykt/omptests/blob/master/t-unified-array-of-ptr/test.cpp


//-
#define N 640
#define C 64
#define P 10

int A[N];
int *p[P];

void
foo ()
{
  #pragma omp target enter data map(alloc: p)
  for (int i=0; i < P; i++) {
#pragma omp target enter data map(alloc: p[i][0:C])
  }
}
//-

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[admin at levyhsu dot com via Gcc-bugs]

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

Levy  changed:

   What|Removed |Added

  Attachment #49534|0   |1
is obsolete||

--- Comment #29 from Levy  ---
Created attachment 49536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49536=edit
QI/HI/SImode auto Zero/Sign-extend

Finally, make gen_extend_insn() seems to work with auto-extension based on Jim
and Kito's idea.

Just 10 lines of code at the beginning of riscv_legitimize_move() in
riscv-gcc/gcc/config/riscv.c

if (GET_MODE_CLASS (mode) == MODE_INT
&& GET_MODE_SIZE (mode) < UNITS_PER_WORD
  && can_create_pseudo_p()
  && MEM_P (src))
  {
  rtx temp_reg = gen_reg_rtx (word_mode);
  int zero_sign_extend = (LOAD_EXTEND_OP (mode) == ZERO_EXTEND);
  emit_insn(gen_extend_insn(temp_reg, src, word_mode, mode,
zero_sign_extend));
  riscv_emit_move(dest, gen_lowpart(mode, temp_reg));
  return true;
  }

Haven't make report-gcc, but already passed 2-stage make. 
I'll have a test later.

[Bug c++/85468] Wrong location for -Wignored-qualifiers diagnostic on conversion operator

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I forgot to say that the test needs -Wignored-qualifiers (as shown in the
diagnostic).

Still present on trunk.

[Bug c++/97773] gcc crash after some noexcept magic

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Martin Liška from comment #12)
> Started to ICE with -std=c++17 since r6-3372-g378b307d0d7e789c.

That's the commit that added C++17 fold expressions, but the ICE doesn't depend
on fold expressions. Comment 13 doesn't use them.

[Bug c++/97773] gcc crash after some noexcept magic

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #14 from Jonathan Wakely  ---
dup

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

[Bug c++/82099] internal compiler error: in type_throw_all_p, at cp/except.c:1186 when using a function pointer for templated predicate

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||janezz55 at gmail dot com

--- Comment #8 from Jonathan Wakely  ---
*** Bug 97773 has been marked as a duplicate of this bug. ***

[Bug c++/97773] gcc crash after some noexcept magic

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Jonathan Wakely  ---
I think it's just a dup of PR 82099.

Reduced further to only use C++14

template 
struct hash
{
  int operator()(T) const noexcept { return 0; }
};

template 
int hash_combine(T v) noexcept(noexcept(hash()(v)))
{
  return 0;
}

template
auto
apply(F& f, T t)
{
  return f(t);
}

auto x = apply(hash_combine, 0);

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
*** Bug 97775 has been marked as a duplicate of this bug. ***

[Bug middle-end/97775] Wrong code with bitfield

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Already reproduces with plain -O1.

Value numbering stmt = _1 = BIT_FIELD_REF ;
Successfully combined 2 partial definitions
Setting value number of _1 to 0 (changed)
Replaced BIT_FIELD_REF  with 0 in all uses of _1 =
BIT_FIELD_REF ;

Jakub just pushed a fix here (PR97764), which fixes this issue.

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

[Bug c++/97773] gcc crash after some noexcept magic

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Martin Liška  ---
Started to ICE with -std=c++17 since r6-3372-g378b307d0d7e789c. Before that it
was rejected:

pr97773-2.C:30:40: error: expected primary-expression before ‘...’ token
   ((hash>()(v)), ...)))
^
pr97773-2.C:30:40: error: expected ‘)’ before ‘...’ token
pr97773-2.C:78:1: error: expected ‘)’ at end of input
 }
 ^
pr97773-2.C:78:1: error: expected ‘)’ at end of input
pr97773-2.C:78:1: error: expected initializer at end of input
posix.c (backtrace_open): Cast second argument of open() to int.

2015-09-17  Ian Lance Taylor  

* posix.c (backtrace_open): Cast second argument of open() to int.

From-SVN: r227881

[Bug c++/97773] gcc crash after some noexcept magic

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82099

--- Comment #11 from Jonathan Wakely  ---
ICE happens at the same place as for PR 82099

[Bug c++/97773] gcc crash after some noexcept magic

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Jonathan Wakely  ---
Reduced:

using size_t = decltype(sizeof(0));

template struct remove_reference { using type = T; };
template struct remove_reference { using type = T; };
template struct remove_reference { using type = T; };
template using remove_reference_t = typename
remove_reference::type;

struct seconds
{
  long count() const;
};

template 
struct hash
{
};

template <>
struct hash
{
  auto operator()(seconds const cp) const noexcept
  {
return (size_t)cp.count();
  }
};

template 
size_t hash_combine(T&& ...v) noexcept(noexcept(
  ((hash>()(v)), ...)))
{
  auto seed{672807365};

  (
(
  seed ^= hash>()(v) +
0x9e3779b9 + (seed << 6) + (seed >> 2)
),
...
  );

  return seed;
}

template
struct tuple_node
{
  T t;
};

template
struct tuple : tuple_node...
{
};

template
auto
apply(F& f, tuple t)
{
  f(static_cast&>(t).t...);
}

template 
struct hash>
{
  auto operator()(tuple& t) const
  {
return apply(hash_combine, t);
  }
};

int main()
{
  using T = tuple;
  hash h;
  T t;
  h(t);
}

[Bug middle-end/97775] Wrong code with bitfield

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jan Hubicka  ---
Forgot to say, flags to reproduce are: -Os t2.c -fno-tree-sra -fno-ipa-modref

[Bug middle-end/97775] New: Wrong code with bitfield

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97775
   Summary: Wrong code with bitfield
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

The follwing testcase reduced from ssd/t2.c 

#include 

void dump (void *p, unsigned int len)
{
  const char digits[17] = "0123456789abcdef";
  unsigned char *a = (unsigned char *)p;
  int i;

  for (i = 0; i < len; i++)
{
  putchar (' ');
  putchar (digits[a[i] / 16]);
  putchar (digits[a[i] % 16]);
}
}

void put (const char s[])
{
  int i;
  for (i = 0; s[i]; i++)
putchar (s[i]);
}

void new_line (void)
{
  putchar ('\n');
}
struct __attribute__((scalar_storage_order("little-endian"), packed)) R1
{
  unsigned S1 : 2;
  unsigned I  : 32;
  unsigned S2 : 2;
  unsigned A1 : 9;
  unsigned A2 : 9;
  unsigned A3 : 9;
  unsigned B  : 1;
};

struct R1 My_R1 = { 2, 0x12345678, 1, 0xAB, 0xCD, 0xEF, 1 };

int main (void)
{
  struct R1 Local_R1;


  Local_R1.B  = 1;

#ifdef BAD
  new_line ();
#endif
  /* { dg-output "Local_R1 : e2 59 d1 48 b4 aa d9 bb.*\n" } */

  Local_R1.S1 = 0;
  Local_R1.I  = 0;
  Local_R1.S2 = 0;
  Local_R1.A1 = 0;
  Local_R1.A2 = 0;
  Local_R1.A3 = 0;
  Local_R1.B  = !Local_R1.B;

  put ("Local_R1 :");
  dump (_R1, sizeof (struct R1));
  new_line ();
  /* { dg-output "Local_R1 : e5 59 d1 48 b0 a0 c1 03.*\n" } */

  new_line ();
  return 0;
}

Defining BAD canges output 
< Local_R1 : 00 00 00 00 00 00 00 00
---
> Local_R1 : 00 00 00 00 00 00 00 80

Difference is already in fre1:
-Value numbering store Local_R1.B to _3
+Value numbering store Local_R1.B to 1

-RPO tracked 17 values available at 3 locations and 17 lattice elements
+RPO tracked 17 values available at 0 locations and 17 lattice elements
+Replaced BIT_FIELD_REF  with 0 in all uses of _1 =
BIT_FIELD_REF ;
+Replaced (signed char) _1 with 0 in all uses of _2 = (signed char) _1;
+Replaced _2 >= 0 with 1 in all uses of _3 = _2 >= 0;
+Deleted redundant store Local_R1.B = _3;
+Removing dead stmt Local_R1.B = _3;
+Removing dead stmt _3 = _2 >= 0;
+Removing dead stmt _2 = (signed char) _1;
+Removing dead stmt _1 = BIT_FIELD_REF ;
 main ()
 {
   struct R1 Local_R1;
-  unsigned char _1;
-  signed char _2;
-  _Bool _3;

:
   Local_R1.B = 1;
@@ -533,10 +540,6 @@
   Local_R1.A1 = 0;
   Local_R1.A2 = 0;
   Local_R1.A3 = 0;
-  _1 = BIT_FIELD_REF ;
-  _2 = (signed char) _1;
-  _3 = _2 >= 0;
-  Local_R1.B = _3;
   put ("Local_R1 :");
   dump (_R1, 8);
   new_line ();

Clearly B should be 0 and not 1.

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:4b47f86c40a071fbcad5bce5001b1b689748a2e8

commit r10-8998-g4b47f86c40a071fbcad5bce5001b1b689748a2e8
Author: Jakub Jelinek 
Date:   Tue Nov 10 11:17:46 2020 +0100

sccvn: Fix up push_partial_def little-endian bitfield handling [PR97764]

This patch fixes a thinko in the left-endian push_partial_def path.
As the testcase shows, we have 3 bitfields in the struct,
bitoff  bitsize
0   3
3   28
31  1
the corresponding read is the byte at offset 3 (i.e. 24 bits)
and push_partial_def first handles the full store ({}) to all bits
and then is processing the store to the middle bitfield with value of -1.
Here are the interesting spots:
  pd.offset -= offseti;
this adjusts the pd to { -21, 28 }, the (for little-endian lowest) 21
bits aren't interesting to us, we only care about the upper 7.
  len = native_encode_expr (pd.rhs, this_buffer, bufsize,
MAX (0, -pd.offset) / BITS_PER_UNIT);
native_encode_expr has the offset parameter in bytes and we tell it
that we aren't interested in the first (lowest) two bytes of the number.
It encodes 0xff, 0xff with len == 2 then.
  HOST_WIDE_INT size = pd.size;
  if (pd.offset < 0)
size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT);
we get 28 - 16, i.e. 12 - the 16 is subtracting those 2 bytes that we
omitted in native_encode_expr.
  size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT);
needed_len is how many bytes the read at most needs, and that is 1,
so we get size 8 and copy all 8 bits (i.e. a single byte plus nothing)
from the native_encode_expr filled this_buffer; this incorrectly sets
the byte to 0xff when we want 0x7f.  The above line is correct for the
pd.offset >= 0 case when we don't skip anything, but for the pd.offset < 0
case we need to subtract also the remainder of the bits we aren't
interested
in (the code shifts the bytes by that number of bits).
If it weren't for the big-endian path, we could as well do
  if (pd.offset < 0)
size += pd.offset;
but the big-endian path needs it differently.
With the following patch, amnt is 3 and we subtract from 12 the (8 - 3)
bits and thus get the 7 which is the value we want.

2020-11-10  Jakub Jelinek  

PR tree-optimization/97764
* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): For
little-endian stores with negative pd.offset, subtract
BITS_PER_UNIT - amnt from size if amnt is non-zero.

* gcc.c-torture/execute/pr97764.c: New test.

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-4867-gc69325a5db450dbac198f76f1162734af05a1061
Author: Jakub Jelinek 
Date:   Tue Nov 10 11:17:46 2020 +0100

sccvn: Fix up push_partial_def little-endian bitfield handling [PR97764]

This patch fixes a thinko in the left-endian push_partial_def path.
As the testcase shows, we have 3 bitfields in the struct,
bitoff  bitsize
0   3
3   28
31  1
the corresponding read is the byte at offset 3 (i.e. 24 bits)
and push_partial_def first handles the full store ({}) to all bits
and then is processing the store to the middle bitfield with value of -1.
Here are the interesting spots:
  pd.offset -= offseti;
this adjusts the pd to { -21, 28 }, the (for little-endian lowest) 21
bits aren't interesting to us, we only care about the upper 7.
  len = native_encode_expr (pd.rhs, this_buffer, bufsize,
MAX (0, -pd.offset) / BITS_PER_UNIT);
native_encode_expr has the offset parameter in bytes and we tell it
that we aren't interested in the first (lowest) two bytes of the number.
It encodes 0xff, 0xff with len == 2 then.
  HOST_WIDE_INT size = pd.size;
  if (pd.offset < 0)
size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT);
we get 28 - 16, i.e. 12 - the 16 is subtracting those 2 bytes that we
omitted in native_encode_expr.
  size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT);
needed_len is how many bytes the read at most needs, and that is 1,
so we get size 8 and copy all 8 bits (i.e. a single byte plus nothing)
from the native_encode_expr filled this_buffer; this incorrectly sets
the byte to 0xff when we want 0x7f.  The above line is correct for the
pd.offset >= 0 case when we don't skip anything, but for the pd.offset < 0
case we need to subtract also the remainder of the bits we aren't
interested
in (the code shifts the bytes by that number of bits).
If it weren't for the big-endian path, we could as well do
  if (pd.offset < 0)
size += pd.offset;
but the big-endian path needs it differently.
With the following patch, amnt is 3 and we subtract from 12 the (8 - 3)
bits and thus get the 7 which is the value we want.

2020-11-10  Jakub Jelinek  

PR tree-optimization/97764
* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): For
little-endian stores with negative pd.offset, subtract
BITS_PER_UNIT - amnt from size if amnt is non-zero.

* gcc.c-torture/execute/pr97764.c: New test.