[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling

[guojiufu at gcc dot gnu.org]

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

--- Comment #34 from Jiu Fu Guo  ---
As previous patch 6d099a76a0f6a040a3e678f2bce7fc69cc3257d8(rs6000: Enable
limited unrolling at -O2) only affects simple loops on rs6000.  
We may also set limits for GIMPLE cunroll, like for RTL unroller through a
hook, and tune the limits for the unroller on simple loops.

[Bug libstdc++/95200] New: user-defined hash function is not copied correctly if unordered_map is declared using an incomplete type

[jevgenijsz1 at verifone dot com]

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

Bug ID: 95200
   Summary: user-defined hash function is not copied correctly if
unordered_map is declared using an incomplete type
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jevgenijsz1 at verifone dot com
  Target Milestone: ---

Created attachment 48558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48558=edit
g++ -v output

The failing code requires at least 3 source files, I did not find a cleaner way
to reproduce the issue. I'm not 100% sure this is a bug in libstdc++ however I
couldn't find a reason for why this should not work as expected.

Code:
=
map_obj.h
=

#ifndef MAP_OBJ_H_
#define MAP_OBJ_H_

#include 

enum class EnumType;

typedef std::unordered_map map;

class MapObj {
 public:
  map getEnumMap() const;
  map enum_map_;
};

#endif
=

=
map_obj.cpp
=
#include "map_obj.h"

map MapObj::getEnumMap() const {
  return enum_map_;
}
=

=
main.cpp
=
#include 

enum class EnumType : int {
  VALUE0,
  VALUE1,
};

namespace std {
template <>
struct hash {
  size_t operator()(EnumType type) const { return
std::hash()(static_cast(type)); }
};
}

#include "map_obj.h"

int main() {
  auto event = MapObj();
  event.enum_map_[EnumType::VALUE0] = true;
  event.enum_map_[EnumType::VALUE1] = false;
  event.getEnumMap().at(EnumType::VALUE0);
  event.getEnumMap().at(EnumType::VALUE1);
  return 0;
}
=

using: 
gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC)
libstdc++ 3.4.28

command line to build: g++ -save-temps -Wall -Wextra -o map_test main.cpp
map_obj.cpp

expected result: runnnig map_test returns 0

actual result: terminate called after throwing an instance of
'std::out_of_range'
  what():  _Map_base::at

[Bug libfortran/95177] error: array subscript has type char

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
>--- Comment #1 from kargl at gcc dot gnu.org ---
>Why cast to unsigned char?  The prototypes for tolower(), toupper(),
>isdigit(), etc show that the type of the argument is int.

See https://stackoverflow.com/a/60696378 for a detailed explanation.

[Bug c++/66439] Diagnostic on failed function template lookup is missing a line

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:864fed4a491606a7b17325d847e1d723d2a44104

commit r11-476-g864fed4a491606a7b17325d847e1d723d2a44104
Author: Patrick Palka 
Date:   Mon May 18 23:50:14 2020 -0400

c++: Explain fn template argument type/value mismatches [PR66439]

In fn_type_unifcation, we are passing NULL_TREE as the 'in_decl'
parameter to coerce_template_parms, and this is causing template
type/value mismatch error messages to get suppressed regardless of the
value of 'complain'.

This means that when substitution into a function template fails due to
a type/value mismatch between a template parameter and the provided
template argument, we just say "template argument deduction/substitution
failed:" without a followup explanation of the failure.

Fix this by passing 'fn' instead of NULL_TREE to coerce_template_parms.

gcc/cp/ChangeLog:

PR c++/66439
* pt.c (fn_type_unification): Pass 'fn' instead of NULL_TREE as
the 'in_decl' parameter to coerce_template_parms.

gcc/testsuite/ChangeLog:

PR c++/66439
* g++.dg/cpp2a/concepts-ts4.C: Expect a "type/value mismatch"
diagnostic.
* g++.dg/cpp2a/concepts-ts6.C: Likewise.
* g++.dg/template/error56.C: Likewise.
* g++.dg/template/error59.C: New test.

libstdc++-v3/ChangeLog:

PR c++/66439
* testsuite/20_util/pair/astuple/get_neg.cc: Prune "type/value
mismatch" messages.
* testsuite/20_util/tuple/element_access/get_neg.cc: Likewise.

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:573e5f0500968dcf4025b8fc0ae5fb367f9c70d9

commit r11-477-g573e5f0500968dcf4025b8fc0ae5fb367f9c70d9
Author: Patrick Palka 
Date:   Mon May 18 23:50:32 2020 -0400

c++: Enable spec_hasher table sanitization [PR87847]

It looks like hash table sanitization is now safe to enable for the
decl_specializations and type_specializations tables, probably ever
since PR94454 was fixed.

gcc/cp/ChangeLog:

PR c++/87847
* pt.c (init_template_processing): Enable sanitization for
decl_specializations and type_specializations.

[Bug d/95174] [D] Incorrect compiled functions involving const fixed size arrays

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Witold Baryluk from comment #2)
> Doh. Of course. My bad. Sorry.
> 
> 
> static arrays are value type, dynamic arrays are reference type.
> 


Dynamic arrays are still value types, the value passed around is a pointer and
length. For example:

void f(immutable(float[64]) x, float[] o) {
   o[] = x[] * 2.0f;
}

float[64] x = 1.0f;
float[] o;
f(x, o);
// o does not change here.
assert(o.length == 0);
assert(o.ptr is null);

[Bug tree-optimization/95199] New: Remove extra variable created for memory reference in loop vectorization.

[zhoukaipeng3 at huawei dot com]

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

Bug ID: 95199
   Summary: Remove extra variable created for memory reference in
loop vectorization.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhoukaipeng3 at huawei dot com
  Target Milestone: ---

The function vect_create_data_ref_ptr created two equal variable for two equal
memory references.

gcc version 11.0.0 20200515 (experimental) (GCC)
Target: aarch64-unknown-linux-gnu
Configured with: ../configure
Command: gcc -O2 -march=armv8.2-a+fp+sve -ftree-vectorize test.c -S

Testcase:
void
foo (double *a, double *b, double m, int inc_x, int inc_y) {
  int ix = 0, iy = 0;
  for (int i = 0; i < 1000; ++i)
{
  a[ix] += m * b[iy];
  ix += inc_x;
  iy += inc_y;
}
  return ;
}

Assembly code
.L5:
  ld1d z3.d, p0/z, [x5, z2.d, lsl 3]
  ld1d z1.d, p0/z, [x3, z4.d, lsl 3]
  fmad z1.d, p1/m, z0.d, z3.d
  st1d z1.d, p0, [x2, z2.d, lsl 3]
  incd x1
  add  x5, x5, x6
  add  x3, x3, x4
  add  x2, x2, x6
  whilelo  p0.d, x1, x0
  b.any.L5

x2 is the same as x5.
vectorizable_load and vectorizable_store called vect_create_data_ref_ptr twice
for a[ix].

Dump Log in test.c.161.vect
test.c:4:2: note:  create real_type-pointer variable to type: double 
vectorizing a pointer ref: *a_16(D)
test.c:4:2: note:  created a_16(D)
test.c:4:2: note:  add new stmt: vect__4.5_94 = .MASK_GATHER_LOAD
(vectp_a.3_91, _90, 8, { 0.0, ... }, loop_mask_93);
...
test.c:4:2: note:  create real_type-pointer variable to type: double 
vectorizing a pointer ref: *a_16(D)
test.c:4:2: note:  created a_16(D)
test.c:4:2: note:  add new stmt: .MASK_SCATTER_STORE (vectp_a.11_117, _116, 8,
vect__10.10_108, loop_mask_93);

I plan to add a hash_map to loop_vec_info for dr and the corresponding pointer
created by vect_create_data_ref_ptr. If the dr->ref has been handled, return
the corresponding pointer.

Optimized assembly code
.L3:
  ld1dz2.d, p0/z, [x0, z1.d, lsl 3]
  ld1dz0.d, p0/z, [x1, z4.d, lsl 3]
  fmadz0.d, p1/m, z3.d, z2.d
  st1dz0.d, p0, [x0, z1.d, lsl 3]
  incdx2
  add x0, x0, x5
  add x1, x1, x4
  whilelo p0.d, w2, w3
  b.any   .L3
  ret

[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #1 from Witold Baryluk  ---
BTW.

Using:

```
extern(C) private final static int f() { ... }
```


doesn't change anything.

[Bug d/95198] New: [D] extern(C) private final functions should use 'local' linker attribute

[witold.baryluk+gcc at gmail dot com]

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

Bug ID: 95198
   Summary: [D] extern(C) private final functions should use
'local' linker attribute
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: witold.baryluk+gcc at gmail dot com
  Target Milestone: ---

```
module t1;

extern(C)
private final int f() {
  return 5;
}
pragma(msg, f.mangleof);

```

`gdc -c t1.d -o t1.o` results in object with this symbols:

 D _D2t111__moduleRefZ
 D _D2t112__ModuleInfoZ
 U _d_dso_registry
 T f
 W gdc.dso_ctor
 W gdc.dso_dtor
 u gdc.dso_initialized
 u gdc.dso_slot
0016 t _GLOBAL__D_2t1
000b t _GLOBAL__I_2t1
 U _GLOBAL_OFFSET_TABLE_
 U __start_minfo
 U __stop_minfo



Symbol, ' T f' should instead be ' t f'

Additional when using optimizations, I would expect the f to not be emitted at
all, but it is still there (unless compiler decides not to inline it or its
address is not taken and passed around), even with `gdc -O3`.

gcc for C does use LOCAL for static functions and variables in translation
unit. Similarly probably for C++ symbols in anonymous namespaces.



Example of linking issues:

t1.d:
```
module t1;

extern(C)
private final int f() {
  return 5;
}
```

t2.d:
```
module t2;

extern(C)
private final int f() {
  return 10;
}
```

tm.d:
```
module tm;

void main() {
}
```

$ gdc -O0 -c t1.d -o t1.o
$ gdc -O0 -c t2.d -o t2.o
$ gdc t1.o t2.o tm.d -o t12
/usr/bin/ld: t2.o: in function `f':
t2.d:(.text+0x0): multiple definition of `f'; t1.o:t1.d:(.text+0x0): first
defined here
collect2: error: ld returned 1 exit status
$


This code should link, similar to equivalent code in C. The use case is local
function that is passed in some other module function or method (or static
module constructor for example), to C libraries or other modules as a callback
or for variables a return value.

[Bug d/95174] [D] Incorrect compiled functions involving const fixed size arrays

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #2 from Witold Baryluk  ---
Doh. Of course. My bad. Sorry.


static arrays are value type, dynamic arrays are reference type.

Changing signature to:

```
void f(immutable(float[64]) x, float[] o);
```


solves the problem.

[Bug libfortran/95177] error: array subscript has type char

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Why cast to unsigned char?  The prototypes for tolower(), toupper(),
isdigit(), etc show that the type of the argument is int.

Also, why are errors being issued?  None of the places where 
you have inserted an (unsigned char) cast is a subscripts.

[Bug c++/95197] New: libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[mpolacek at gcc dot gnu.org]

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

Bug ID: 95197
   Summary: libgomp/testsuite/libgomp.c++/for-27.C fails with
-std=c++17
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See  for why
this fails.  My workaround was

--- a/libgomp/testsuite/libgomp.c++/for-27.C
+++ b/libgomp/testsuite/libgomp.c++/for-27.C
@@ -151,6 +151,12 @@ f4 (const I , const I )
 else if (results[i])   \
   abort ()

+// FIXME: OpenMP seems to count on this being instantiated; the copy
+// constructor is called in functions fn2/fn3/fn4.  But in C++17 we
+// elide this copy constructor, so it's never been instantiated.  For
+// now instantiate it explicitly.
+template I::I(const I &);
+
 int
 main ()
 {

Seems that OpenMP has to call mark_used or some such.

[Bug c/30368] missing warning for dereferencing null pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
   Last reconfirmed|2007-03-13 16:12:46 |2020-5-18

--- Comment #9 from Martin Sebor  ---
Missing warning reconfirmed with GCC 11.

The last pass where the null pointer is still available is the CCP1 pass whose
output shows that it removes it:

$ gcc -O2 -S -Wall -Wextra -fdump-tree-ccp1-all=/dev/stdout pr30368.c

...
Substituting values and folding statements

Folding statement: _1 = _3->b;
Folded into: _1 = 0B;

Folding statement: if (_1 != 0B)
...

So it should be possible to diagnose the dereference there, just prior to its
removal.

[Bug c++/95175] [9/10/11 Regression] constexpr and alias template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P2
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|constexpr and alias |[9/10/11 Regression]
   |template|constexpr and alias
   ||template
   Target Milestone|--- |9.4
   Last reconfirmed||2020-05-18

--- Comment #1 from Marek Polacek  ---
Confirmed, we used to accept this.

Started with r9-6136-g43574e4ff2afd4a2e47c179921a9b5661786ebf3

[Bug c++/12341] Request for additional warning for variable shadowing

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||87403
   Last reconfirmed|2005-12-11 23:28:15 |2020-5-18
 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
Reconfirming with GCC 11.0.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug fortran/95196] New: Assumed-rank incorrect array bounds inside select rank

[jrfsousa at gmail dot com]

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

Bug ID: 95196
   Summary: Assumed-rank incorrect array bounds inside select rank
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 48557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48557=edit
Fortran code demonstrating problems.

Hi all!

Assumed-rank array has incorrect array bounds inside select rank clauses.

Probably related to Bug 94289.

Seen with:

GNU Fortran (GCC) 10.1.1 20200513
GNU Fortran (GCC) 11.0.0 20200513 (experimental)

Thank you very much.

Best regards,
José Rui

[Bug c++/94955] [10 Regression] ICE in to_wide

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
   |to_wide |to_wide

--- Comment #7 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/94955] [10/11 Regression] ICE in to_wide

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2d4e1e144c25e526e4f668be5a0bc10d0c1c738c

commit r11-474-g2d4e1e144c25e526e4f668be5a0bc10d0c1c738c
Author: Marek Polacek 
Date:   Wed May 6 15:53:33 2020 -0400

c++: ICE when shortening right shift [PR94955]

Since r10-6527 fold_for_warn calls maybe_constant_value, which means it
can fold more than it previously could.  In this testcase it means that
cp_build_binary_op/RSHIFT_EXPR set short_shift because now we were able
to fold op1 to an INTEGER_CST.  But then when actually performing the
shortening we crashed because cp_fold_rvalue wasn't able to fold as much
as f_f_w and so tree_int_cst_sgn crashed on a NOP_EXPR.  Therefore the
calls should probably match.

PR c++/94955
* typeck.c (cp_build_binary_op): Use fold_for_warn instead of
cp_fold_rvalue.

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

[Bug c++/94937] [10 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE with |[10 Regression] ICE with if
   |if constexpr (in|constexpr (in
   |cp_get_fndecl_from_callee,  |cp_get_fndecl_from_callee,
   |at cp/cvt.c:1000) since |at cp/cvt.c:1000) since
   |r10-2835-g14da3939da3adcef  |r10-2835-g14da3939da3adcef

--- Comment #20 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-473-gbf732686c0b9c42a2fe119db774c5a65e5a97174
Author: Marek Polacek 
Date:   Wed May 6 19:24:58 2020 -0400

c++: ICE with -Wall and constexpr if [PR94937]

An ICE arises here because we call cp_get_callee_fndecl_nofold in a
template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK.
This tickles the INDIRECT_TYPE_P assert in cp_get_fndecl_from_callee.

Fixed by turning the assert into a condition and returning NULL_TREE
in that case.

PR c++/94937
* cvt.c (cp_get_fndecl_from_callee): Return NULL_TREE if the
function
type is not INDIRECT_TYPE_P.
* decl.c (omp_declare_variant_finalize_one): Call
cp_get_callee_fndecl_nofold instead of looking for the function
decl
manually.

* g++.dg/cpp1z/constexpr-if34.C: New test.
* g++.dg/cpp2a/is-constant-evaluated10.C: New test.

[Bug fortran/95195] New: gfortran poorly handles a program error of writing a namelist to an unformatted file.

[longb at cray dot com]

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

Bug ID: 95195
   Summary: gfortran poorly handles a program error of writing a
namelist to an unformatted file.
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

gfortran poorly handles a program error of writing a namelist to an unformatted
file.

> cat test.f90
  program test
  character(len=16) my_form
  character(len=240) msg
  data my_form /'unformatted'/
  namelist /nml1/ i, j, k
  i = 1; j = 2; k = 3
  open (unit=10, file='test.dat')
  write (10, nml=nml1)
  close (10)
  open (unit=10, file='test.dat', form=my_form)
read (unit=10, nml=nml1)
  close (unit=10, status='delete')
  end program test


> gfortran test.f90
> ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x7fadb087459f in ???
#1 0x7fadb15bf69e in fbuf_getc
at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/fbuf.h:78
#2 0x7fadb15bf69e in next_char_default
at
../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/list_read.c:215
#3 0x7fadb15bf69e in next_char_default
at
../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/list_read.c:207
#4 0x7fadb15c8db7 in finalize_transfer
at
../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/transfer.c:4109
#5 0x400bf7 in ???
#6 0x400c7c in ???
#7 0x7fadb085f349 in ???
#8 0x400779 in ???
at ../sysdeps/x86_64/start.S:120
#9 0x in ???
Segmentation fault (core dumped)

> gfortran --version
GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



A diagnostic message along the lines of the Cray or Intel compilers is
preferred:

> module swap PrgEnv-gnu PrgEnv-cray
> ftn test.f90
> ./a.out

lib-4080 : UNRECOVERABLE library error
A formatted read or write is not allowed on an unformatted file.

Encountered during a namelist READ from unit 10
Fortran unit 10 is connected to a sequential unformatted file: "test.dat"
Aborted (core dumped)



> module swap PrgEnv-cray PrgEnv-intel
> ifort test.f90
> ./a.out
forrtl: severe (257): formatted I/O to unit open for unformatted transfers,
unit 10, file //test.dat
Image PC Routine Line Source
a.out 0040546B Unknown Unknown Unknown
a.out 0041EF5E Unknown Unknown Unknown
a.out 00402C31 Unknown Unknown Unknown
a.out 00402A12 Unknown Unknown Unknown
libc-2.26.so 7FC2FABAF34A __libc_start_main Unknown Unknown
a.out 0040292A Unknown Unknown Unknown

[Bug lto/95194] bootstrap-lto fails on musl (bundled libintl uses asm aliases)

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
https://gcc.gnu.org/PR48200 touches on why asm aliases are problematic.

[Bug lto/95194] New: bootstrap-lto fails on musl (bundled libintl uses asm aliases)

[slyfox at inbox dot ru]

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

Bug ID: 95194
   Summary: bootstrap-lto fails on musl (bundled libintl uses asm
aliases)
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

The bug is originally reported by Andrew Savchenko as
https://bugs.gentoo.org/723370. There gcc's bootstrap-lto fails on musl libc.
It's slightly different from glibc as libintl relies on glibc-specific gettext
symbols like '_nl_msg_cat_cntr'.

The bug:

$ /var/tmp/portage/sys-devel/gcc-10.1.0/work/gcc-10.1.0/configure
--host=x86_64-gentoo-linux-musl --build=x86_64-gentoo-linux-musl --prefix=/usr
--bindir=/usr/x86_64-gentoo-linux-musl/gcc-bin/10.1.0
--includedir=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0/include
--datadir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0
--mandir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/man
--infodir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0/include/g++-v10
--with-python-dir=/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion=Gentoo Hardened 10.1.0 p1 --enable-esp
--enable-libstdcxx-time --with-build-config=bootstrap-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --disable-multilib --with-multilib-list=m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libada --disable-systemtap
--disable-vtable-verify --disable-libvtv --without-zstd --disable-libquadmath
--enable-lto --without-isl --disable-libsanitizer --enable-default-pie
--enable-default-ssp

$ make -j8 -l10 'LDFLAGS=-march=native -pipe
-Wl,-O1,--as-needed,--sort-common,-z,combreloc,-z,relro,-z,now,--relax,--hash-style=gnu'
STAGE1_CFLAGS= LIBPATH=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0
'BOOT_CFLAGS=-m64 -march=native -pipe -O2' bootstrap-lean

/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/./prev-gcc/xg++
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/./prev-gcc/
-B/usr/x86_64-gentoo-linux-musl/bin/ -nostdinc++
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/src/.libs
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/libsupc++/.libs
 -isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/include/x86_64-gentoo-linux-musl
 -isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/include
 -isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/gcc-10.1.0/libstdc++-v3/libsupc++
-L/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/src/.libs
-L/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/libsupc++/.libs
-DEXTRA_OPTIONS -m64 -march=native -pipe -O2 -fno-checking -flto=jobserver
-frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE
-static-libstdc++ -static-libgcc  -no-pie -o build/genmatch \
build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o
build/vec.o build/hash-table.o build/sort.o .././libiberty/libiberty.a
./../intl/libintl.a
...
/usr/x86_64-gentoo-linux-musl/bin/ld:
/var/tmp/portage/sys-devel/gcc-10.1.0/temp/genmatch.NlicMk.ltrans2.ltrans.o: in
function `main':
:(.text.startup+0x94ba): undefined reference to `libintl_dgettext'
/usr/x86_64-gentoo-linux-musl/bin/ld:
/var/tmp/portage/sys-devel/gcc-10.1.0/temp/genmatch.NlicMk.ltrans3.ltrans.o: in
function `cpp_diagnostic(cpp_reader*, cpp_diagnostic_level, cpp_warning_reason,
char const*, __va_list_tag (*) [1])':
:(.text+0x2732): undefined reference to `libintl_dgettext'
...

Mechanically it fails because 'libintl_dgettext' is decclared as an asm alias:

"""
extern char *dgettext (const char *__domainname, const char *__msgid)
   __asm__ ("" "libintl_dgettext")
   __attribute__ ((__format_arg__ (2)));

$ ../prev-gcc/lto-dump -list errors.o | fgrep dgettext
function  default 0  *libintl_dgettext
$ ../prev-gcc/lto-dump -demangle -list errors.o | fgrep dgettext
function  default 0  dgettext
"""

I'm not sure if gcc should be able to link such 

[Bug middle-end/92815] [8/9/10 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-472-g8edf0adb6616bd717312d9b305c7d7c9a6b7a171
Author: Martin Sebor 
Date:   Mon May 18 16:31:13 2020 -0600

PR middle-end/92815 - spurious -Wstringop-overflow writing into a flexible
array of an extern struct

Adjust test to avoid failures in ILP32 mode.

gcc/testsuite/ChangeLog:

PR middle-end/92815
* gcc.dg/builtin-object-size-20.c: Adjust to avoid failures in
ILP32 mode.

[Bug c++/90915] [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
   |has_attribute, at   |has_attribute, at
   |c-family/c-attribs.c:4221   |c-family/c-attribs.c:4221
   Assignee|paolo.carlini at oracle dot com|mpolacek at gcc dot 
gnu.org

--- Comment #7 from Marek Polacek  ---
Fixed on trunk.  I'll also backport to 10.

[Bug c++/90915] [9/10/11 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5d2246a32c638e9caea109e5dd9f182f5cd43b2a

commit r11-471-g5d2246a32c638e9caea109e5dd9f182f5cd43b2a
Author: Marek Polacek 
Date:   Thu May 7 21:10:42 2020 -0400

c++: Sorry about type-dependent arg for __builtin_has_attribute [PR90915]

Until 92104 is fixed, let's sorry rather than crash.

PR c++/90915
* parser.c (cp_parser_has_attribute_expression): Sorry on a
type-dependent argument.

* g++.dg/ext/builtin-has-attribute.C: New test.

[Bug middle-end/94940] [10 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
Fixed for GCC 11 and 10.2.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 94940 Summary: [10 Regression] spurious -Warray-bounds for a zero length 
array member of union since r10-4300-g49fb45c81f4ac068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940

   What|Removed |Added

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

[Bug middle-end/94940] [10 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Sebor
:

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

commit r10-8154-gff61c5bd1490a006c00bed9259dc672351eb217a
Author: Martin Sebor 
Date:   Mon May 18 16:04:56 2020 -0600

PR middle-end/94940 - spurious -Warray-bounds for a zero length array
member of union

gcc/testsuite/ChangeLog:

PR middle-end/94940
* gcc.dg/Warray-bounds-61.c: New test.

gcc/ChangeLog:

PR middle-end/94940
* tree-vrp.c (vrp_prop::check_mem_ref): Remove unreachable code.
* tree.c (component_ref_size): Correct the handling or array
members
of unions.
Drop a pointless test.
Rename a local variable.

[Bug fortran/94361] Memory leak in nested types with final

[antony at cosmologist dot info]

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

--- Comment #2 from Antony Lewis  ---
I tried it on another system where gfortran 6.5 and 7.4.0 that don't leak, but
8.4.0 does, so in that sense at least I think it is a regression.

[Bug middle-end/92815] [8/9/10 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |spurious|spurious
   |-Wstringop-overflow writing |-Wstringop-overflow writing
   |into a flexible array of an |into a flexible array of an
   |extern struct   |extern struct

--- Comment #7 from Martin Sebor  ---
Fixed on trunk for now.

[Bug middle-end/92815] [8/9/10/11 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:7a41fcde6c67faafab8c8ee2a31140999383dcef

commit r11-470-g7a41fcde6c67faafab8c8ee2a31140999383dcef
Author: Martin Sebor 
Date:   Mon May 18 15:24:12 2020 -0600

PR middle-end/92815 - spurious -Wstringop-overflow writing into a flexible
array of an extern struct

gcc/ChangeLog:

PR middle-end/92815
* tree-object-size.c (decl_init_size): New function.
(addr_object_size): Call it.
* tree.h (last_field): Declare.
(first_field): Add attribute nonnull.

gcc/testsuite/ChangeLog:

PR middle-end/92815
* gcc.dg/Warray-bounds-56.c: Remove xfails.
* gcc.dg/builtin-object-size-20.c: New test.
* gcc.dg/builtin-object-size-21.c: New test.

[Bug middle-end/94940] [10/11 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:3956244c58acceebf1ef2cf9a63e99f0f82abcb7

commit r11-469-g3956244c58acceebf1ef2cf9a63e99f0f82abcb7
Author: Martin Sebor 
Date:   Mon May 18 15:07:48 2020 -0600

PR middle-end/94940 - spurious -Warray-bounds for a zero length array
member of union

gcc/testsuite/ChangeLog:

PR middle-end/94940
* gcc.dg/Warray-bounds-61.c: New test.

gcc/ChangeLog:

PR middle-end/94940
* tree-vrp.c (vrp_prop::check_mem_ref): Remove unreachable code.
* tree.c (component_ref_size): Correct the handling or array
members
of unions.
Drop a pointless test.
Rename a local variable.

[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
I will look into this.

[Bug target/82261] x86: missing peephole for SHLD / SHRD

[michaeljclark at mac dot com]

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

Michael Clark  changed:

   What|Removed |Added

 CC||michaeljclark at mac dot com

--- Comment #2 from Michael Clark  ---
Just refreshing this issue. I found it while testing some code-gen on Godbolt:

- https://godbolt.org/z/uXGxZ9

I noticed that Haswell code-gen uses SHRX/SHLX, but I think -Os and pre-Haswell
would benefit from this peephole if it is not complex to add. Noting that Clang
prefers SHLD / SHRD over the SHRX+SHLX pair no matter the -march flavor.

[Bug c++/87699] Implement CWG 1512

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Implemented in GCC 11.

[Bug c++/87699] Implement CWG 1512

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-467-gae8ed736addb2b005d54c0b3191ac599a04ec170
Author: Marek Polacek 
Date:   Wed May 13 15:52:42 2020 -0400

c++: Implement DR 1512, Pointer comparison vs qual convs [PR87699]

This patch resolves DR 1512 (and, by turn, DR 583).  This entails:

1) Relational pointer comparisons against null pointer constants have
   been made ill-formed:

   void f(char *p) {
  if (p > 0)
// ...
   }

   was always invalid in C but was -- accidentally -- allowed in C++.

2) This was ill-formed:

   bool foo(int** x, const int** y) {
 return x < y;
   }

   because 'int**' couldn't be converted to 'const int**'.  This was
   fixed by re-defining a generic composite pointer type.  The composite
   type of these two pointers will be 'const int *const *', to which
   both pointers can be converted.

3) The overload descriptions for built-in operators were adjusted,
   because objects of type std::nullptr_t cannot be used with relational
   operators any more.

I fixed 1) by adjusting cp_build_binary_op; we already had a warning
for it so made it a hard error now.

Then 2) required tweaking composite_pointer_type_r.  [expr.type] defines
the composite pointer type by using the "cv-combined type."  We didn't
implement the [conv.qual]/3.3 part; previously the composite type of
'int**' and 'const int**' was 'const int**', so this didn't compile:

void f(const int **p, int **q) {
  true ? p : q;
}

I wrote a more extensive test for this which uses decltype and some
template magic to check the composite type, see composite-ptr-type.C.
We still don't handle everything that [expr.type] requires us to,
but it's pretty close.

And finally 3) was handled in add_builtin_candidate.  Turned out we
weren't creating built-in operator candidates when the type was
std::nullptr_t at all.  We should, for == and !=.  Tested in builtin4.C.
In passing, I'm fixing some of the comments too.

DR 1512
PR c++/87699
* call.c (add_builtin_candidate) : Create candidate
operator functions when type is std::nullptr_t for ==/!=.
* typeck.c (composite_pointer_type_r): Add bool a * parameter.  Use
it
to maybe add "const" to the pointer type.
(composite_pointer_type): Update the call to
composite_pointer_type_r.
(cp_build_binary_op): Turn two warning_at into error_at.  Print the
types.

* g++.dg/cpp0x/constexpr-array-ptr10.C: Change dg-warning to
dg-error
and adjust the expected messages in dg-error.
* g++.dg/expr/composite-ptr-type.C: New test.
* g++.dg/expr/ptr-comp1.C: New test.
* g++.dg/expr/ptr-comp2.C: New test.
* g++.dg/expr/ptr-comp3.C: New test.
* g++.dg/overload/builtin4.C: New test.
* g++.dg/warn/Wextra-3.C: Change dg-warning to dg-error.

[Bug c++/95193] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14624

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |11.0
   Last reconfirmed||2020-05-18
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r11-15-gbcbf334afe091ad7d0f5ffe164299f8730cf41d1

[Bug c++/95193] New: [11 Regression] ICE in tsubst_decl, at cp/pt.c:14624

[asolokha at gmx dot com]

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

Bug ID: 95193
   Summary: [11 Regression] ICE in tsubst_decl, at cp/pt.c:14624
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200517 snapshot (g:2b9a271b2d0ba340234a138b7f8289bd7dca2fc5)
ICEs when compiling the following testcase, extracted from
test/SemaCXX/cxx1z-lambda-star-this.cpp from the clang 10.0.0 test suite, w/
-std=c++17:

struct X {
  void foo() const {
auto GL1 = [*this](auto a) {
};

GL1("abc");
  }
};

% g++-11.0.0 -std=c++17 -c g5fztf1w.cpp
g5fztf1w.cpp: In instantiation of 'X::foo() const:: [with
auto:1 = const char*]':
g5fztf1w.cpp:6:14:   required from here
g5fztf1w.cpp:3:30: internal compiler error: in tsubst_decl, at cp/pt.c:14624
3 | auto GL1 = [*this](auto a) {
  |  ^
0x662811 tsubst_decl
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:14624
0x9fa006 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:17921
0x9f8267 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:18138
0x9f536a instantiate_decl(tree_node*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:25609
0x926d1a maybe_instantiate_decl
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/decl2.c:5377
0x929558 maybe_instantiate_decl
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/tree.h:3411
0x929558 mark_used(tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/decl2.c:5573
0x87afa3 build_over_call
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:9077
0x87ff91 build_op_call_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4883
0x87ff91 build_op_call(tree_node*, vec**, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4912
0xa3d83e finish_call_expr(tree_node*, vec**, bool,
bool, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/semantics.c:2692
0x9b3e51 cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:7465
0x9958e9 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:9559
0x99759e cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:9864
0x997963 cp_parser_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:10032
0x99a918 cp_parser_expression_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:11692
0x9a5f73 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:11488
0x9a7828 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:11839
0x9a7908 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:11789
0x9bfcf5 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:23058

[Bug c++/95063] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14633

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/95192] [11 Regression] ICE: tree check: expected tree_list, have error_mark in handle_assume_aligned_attribute, at c-family/c-attribs.c:2996

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  Started with r11-423-gcda6396a1b6e6bba2a3b0847931567c3458f2184

[Bug c++/95063] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14633

[asolokha at gmx dot com]

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

--- Comment #6 from Arseny Solokha  ---
Is there more work pending, or can this PR be closed?

[Bug c++/95192] New: [11 Regression] ICE: tree check: expected tree_list, have error_mark in handle_assume_aligned_attribute, at c-family/c-attribs.c:2996

[asolokha at gmx dot com]

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

Bug ID: 95192
   Summary: [11 Regression] ICE: tree check: expected tree_list,
have error_mark in handle_assume_aligned_attribute, at
c-family/c-attribs.c:2996
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200517 snapshot (g:2b9a271b2d0ba340234a138b7f8289bd7dca2fc5)
ICEs when compiling the following testcase, extracted from
test/SemaCXX/builtin-assume-aligned-tmpl.cpp from the clang 10.0.0 test suite:

template __attribute__((assume_aligned(sizeof(int(T()) T *f();
void test21() {
  void *p = f()
}

% g++-11.0.0 -c iu1wkpbg.cpp
iu1wkpbg.cpp: In substitution of 'template T* f() [with T = void]':
iu1wkpbg.cpp:3:21:   required from here
iu1wkpbg.cpp:1:75: internal compiler error: tree check: expected tree_list,
have error_mark in handle_assume_aligned_attribute, at
c-family/c-attribs.c:2996
1 | template __attribute__((assume_aligned(sizeof(int(T())
T *f();
  |
  ^
0x7c0c50 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/tree.c:9686
0x6af9db tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/tree.h:3296
0x6af9db handle_assume_aligned_attribute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/c-family/c-attribs.c:2996
0x6af9db handle_assume_aligned_attribute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/c-family/c-attribs.c:2977
0xa96507 decl_attributes(tree_node**, tree_node*, int, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/attribs.c:714
0x9236f7 cplus_decl_attributes(tree_node**, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/decl2.c:1598
0xa178f4 tsubst_function_decl
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:13929
0xa0196f tsubst_decl
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:14182
0xa11b19 instantiate_template_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:20678
0xa2137c instantiate_template(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:20735
0xa2137c fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:21179
0x876223 add_template_candidate_real
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:3415
0x876cf6 add_template_candidate
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:3500
0x876cf6 add_candidates
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:5866
0x8771e7 add_candidates
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4522
0x8771e7 perform_overload_resolution
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4530
0x87eea5 build_new_function_call(tree_node*, vec**, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4604
0xa3d1b4 finish_call_expr(tree_node*, vec**, bool,
bool, int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/semantics.c:2675
0x9b3e51 cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:7465
0x9958e9 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:9559

[Bug fortran/94361] Memory leak in nested types with final

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4

[Bug fortran/94361] Memory leak in nested types with final

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.1.1, 11.0, 7.4.1, 8.2.1,
   ||8.3.1, 9.3.1
Summary|Regression: Memory leak in  |Memory leak in nested types
   |nested types with final |with final
   Last reconfirmed||2020-05-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed regarding the memory leak.

Cannot confirm as regression.  My 8.2.1 (OpenSuse) leaks the same as other
versions according to valgrind.

Regression marker therefore removed.

[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #11 from Rainer Orth  ---
Two of the new tests FAIL on 32-bit Solaris/x86:

+FAIL: gcc.target/i386/pr95021-1.c scan-assembler movq[ \\t]%xmm[0-9]+,
(%esp)
+FAIL: gcc.target/i386/pr95021-3.c scan-assembler movq[ \\t]+[^\\n]*, %xmm

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #30 from anlauf at gcc dot gnu.org ---
Should be fixed now.

Sorry for the breakage.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[anlauf at gcc dot gnu.org]

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

Bug 95053 Summary: [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/95191] Hang in WAIT with a bad ID= value if threading specified

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P4
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2020-05-18
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-461-ge5abd1cb9160619721336ed800779a01548231f1
Author: Harald Anlauf 
Date:   Mon May 18 20:27:29 2020 +0200

PR fortran/95053 - division by zero constants

Partially revert the fix for PR93499.  Replace by checks for valid
expressions in the declaration of array shape and PDT KIND and LEN
expressions at a later stage.

gcc/fortran/

2020-05-18  Harald Anlauf  

PR fortran/95053
* arith.c (gfc_divide): Revert hunk introduced by patch for
PR93499.
* decl.c (variable_decl): Generate error for array shape not being
an INTEGER constant.
(gfc_get_pdt_instance): Generate error if KIND or LEN expressions
in declaration of a PDT instance do not simplify to INTEGER
constants.

gcc/testsuite/

2020-05-18  Harald Anlauf  

PR fortran/95053
* gfortran.dg/dec_structure_23.f90: Adjust to new error messages.
* gfortran.dg/pr93499.f90: Adjust to new error messages.
* gfortran.dg/pr95053_2.f90: New test.
* gfortran.dg/pr95053_3.f90: New test.

[Bug tree-optimization/94952] Possible false positive of uninitialized variable usage during release build in gimple-ssa-store-merging.c

[stefansf at linux dot ibm.com]

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #2 from Stefan Schulze Frielinghaus  
---
Closing as fixed by 2c832ffedf0

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[stefansf at linux dot ibm.com]

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

Bug 94952 Summary: Possible false positive of uninitialized variable usage 
during release build in gimple-ssa-store-merging.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94952

   What|Removed |Added

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

[Bug tree-optimization/94952] Possible false positive of uninitialized variable usage during release build in gimple-ssa-store-merging.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Stefan Schulze Frielinghaus
:

https://gcc.gnu.org/g:2c832ffedf06ff614fc36c44ab6c892d84075e08

commit r11-460-g2c832ffedf06ff614fc36c44ab6c892d84075e08
Author: Stefan Schulze Frielinghaus 
Date:   Tue May 5 19:44:19 2020 +0200

tree-optimization: Fix use of uninitialized variables warnings [PR94952]

While bootstrapping GCC on S/390 with --enable-checking=release several
warnings about use of uninitialized variables bitpos, bitregion_start, and
bitregion_end of function pass_store_merging::process_store are raised.
According to PR94952 these seem to be false positives which are silenced by
initialising the mentioned variables.

Bootstrapped on S/390.  Ok for master and releases/gcc-10 assuming that
regtest succeeds (still running but I don't see a reason why it
should fail)?

gcc/ChangeLog:

2020-05-18  Stefan Schulze Frielinghaus  

PR tree-optimization/94952
* gimple-ssa-store-merging.c (pass_store_merging::process_store):
Initialize variables bitpos, bitregion_start, and bitregion_end in
order to silence warnings about use of uninitialized variables.

[Bug c++/95143] SFINAE failure with static_cast

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-459-gbe464161b4ae128681958d94aa460531cf30e0a4
Author: Marek Polacek 
Date:   Mon May 18 13:50:39 2020 -0400

c++: Add test for c++/95143

Already fixed by r10-8124-gceae6a13366d9646e172fc943fe8e221b70f0920.

PR c++/95143
* g++.dg/cpp0x/sfinae66.C: New test.

[Bug target/94833] vec_first_match_index does not function as described in its description

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Carl Love :

https://gcc.gnu.org/g:24f68831d25bad739a6fe167a58b5b4c0c3cbf9a

commit r11-458-g24f68831d25bad739a6fe167a58b5b4c0c3cbf9a
Author: Carl Love 
Date:   Wed Apr 29 10:23:11 2020 -0500

pr94833, fix vec_first_match_index for nulls

gcc/ChangeLog

2020-04-30  Carl Love  

PR target/94833
* config/rs6000/vsx.md (define_expand): Fix instruction generation
for
first_match_index_.
* testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c (main): Add
additional test cases with zero vector elements.

[Bug lto/95190] Documentation for -Wstringop-overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-18
 Status|UNCONFIRMED |WAITING
  Component|c++ |lto
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Keywords||documentation

--- Comment #1 from Martin Sebor  ---
Which part do you find surprising?  That the warning is issued during the LTO
stage at all or that -Wno-stringop-overflow can be used during the LTO stage to
suppress it?

During LTO the same compiler options should be implicitly enabled as during
ordinary compilation, including warnings.  (This presents some challenges when
the compilation was done with different options for different files.)

It also means that all the same warnings should be expected to be implicitly
enabled during LTO that were explicitly enabled during the compilation stage. 
I'd expect to see only "late" warnings during LTO, i.e., those that depend on
optimization.  (I understand this doesn't work completely consistently yet but
I believe that's the goal.)

So this effect isn't specific to -Wstringop-overflow, but perhaps it would be
worth mentioning under -flto?

[Bug fortran/95191] New: Hang in WAIT with a bad ID= value if threading specified

[longb at cray dot com]

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

Bug ID: 95191
   Summary: Hang in WAIT with a bad ID= value if threading
specified
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90
  program test
  real a(1)
  integer my_id
  integer bad_id
  data my_id /1/
  data bad_id /2/
  a = 1.
  open (unit=10, file='test.dat', form='unformatted', &
 &asynchronous='yes')
  write (unit=10, asynchronous='yes', id=my_id) a
  wait (unit=10, id=bad_id)
  close (unit=10, status='delete')
  end program test

If there are no command line options for the compile, there is no
issue. However, if -fopenmp is added (or -lpthreads is added for the
link), then the code hangs.

> gfortran test.f90
> ./a.out
> gfortran -fopenmp test.f90
> ./a.out 
^C  <<<-- hangs here.
> gfortran --version
GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Original submitter says it hangs here: hang in __gthread_cond_wait.

[Bug target/95169] [10/11 Regression] i386 comparison between nan and 0.0 triggers Invalid operation exception

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r11-457-g8f17461bdfeed758f2be71529fc3af55a76ea3e1
Author: Uros Bizjak 
Date:   Mon May 18 17:52:14 2020 +0200

i386: Avoid reversing a non-trapping comparison to a trapping one [PR95169]

gcc/ChangeLog:

PR target/95169
* config/i386/i386-expand.c (ix86_expand_int_movcc):
 Avoid reversing a non-trapping comparison to a trapping one.

testsuite/ChangeLog:

PR target/95169
* gcc.target/i386/pr95169.c: New test.

[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1

[antony at cosmologist dot info]

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

--- Comment #4 from Antony Lewis  ---
Not sure why no one has at least picked up on 

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

since it is a reproducible regression with a simple test case, an a bug that
effectively kills some previously-working code from 7.x updates onwards?

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[n...@self-evident.org]

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

--- Comment #5 from Nemo  ---
(In reply to Jakub Jelinek from comment #2)

I would be happy if GCC could just emit optimal code (single vcmpeqd
instruction) for this useful constant:

_mm256_set_m128i(_mm_setzero_si128(), _mm_set1_epi8(-1))

aka.

_mm256_inserti128_si256(_mm256_setzero_si256(), _mm_set1_epi8(-1), 0)


(The latter is just what GCC uses to implement _mm256_zextsi128_si256, if I am
reading the headers correctly.)

It's a minor thing, but I was a little surprised to find that none of the
compilers I know of are able to do this. At least, not with any input I tried.

[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
(In reply to Nathan Sidwell from comment #2)
> This is a bug, but you're running a --traditional C preprocessor test
> through the c++ compiler, right?

Through the C compiler, but otherwise yes. I've posted the compiler invocation
in comment 0 verbatim.


> (A regular test run doesn't fail this test
> for me at least)

Yep, because trad.exp adds -traditional-cpp, as intended. But I don't run the
testsuite, but rather use its test cases as part of my larger test corpus,
compiling every individual case in that corpus with randomly chosen compiler
options. IOW, my testing ignores DejaGNU directives in gcc testsuite (which
means it also often ignores common sense when choosing compiler options, as a
consequence).

I can further describe my setup if you are interested, but it's off-topic in
this PR.

[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
This is a bug, but you're running a --traditional C preprocessor test through
the c++ compiler, right?  (A regular test run doesn't fail this test for me at
least)

[Bug d/95120] [D] Incorrectly allows fqdn access to imported symbols when doing selective imports.

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Witold Baryluk from comment #0)
> Created attachment 48529 [details]
> Example of incorrectly accepted d source by gdc-10
> 
> gdc does violatate D language spec:
> 
> https://dlang.org/spec/module.html#selective_imports
> 

This bug (upstream http://issues.dlang.org/show_bug.cgi?id=313) was first
deprecated in 2.070, then made an error in 2.083, The upstream front-end merged
in gdc is based off 2.076.

Please compile with -Wdeprecated.

[Bug d/95174] [D] Incorrect compiled functions involving const fixed size arrays

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Buclaw  ---
(In reply to Witold Baryluk from comment #0)
> https://explore.dgnu.org/z/LppySp
> 
> 
[--snip--]
> 
> Is incorrectly compiled to 'nop; ret'
> 

It is correct, all those functions do nothing.  What you're missing is a 'ref'
or 'out' storage class on the 'o' parameter.

Rationale, static arrays are value types in D (they don't saturate to pointers
like in C).

See https://dlang.org/spec/arrays.html#static-arrays

> 
> As a bonus:
> 
> ```
> void f(immutable(float[4]) x, float[4] o) {
>o[2] = x[1] + x[3];
> }
> 
> import std.stdio : writeln;
> 
> void main() {
>   immutable(float[4]) k = [7.0f, 5.3f, 1.2f, 3.2f];
>   float[4] o;
>   f(k, o);
>   writeln(o);
> }
> 
> ```
> 
> prints '[nan, nan, nan, nan]', but it should: '[nan, nan, 8.5, nan]'.
> 
> 

All NaNs is the correct result here too.

[Bug fortran/94925] Undesired runtime warning message

[siteg at mathalacarte dot com]

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

--- Comment #4 from Fred Krogh  ---
Before submitting this I tried to make a small test case to show the problem. 
It did not show the problem.  I was hoping that the fact that the message just
started and there were no options that would turn it off would be sufficient.
Sorry.

[Bug c++/95190] New: Documentation for -Wstringop-overflow

[stayprivate at gmail dot com]

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

Bug ID: 95190
   Summary: Documentation for -Wstringop-overflow
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stayprivate at gmail dot com
  Target Milestone: ---

I'm compiling code with 10.1 for the first time. I'm getting a warning:

"writing 1 bytes into a region of size 0 -Wstringop-overflow=". Yet
-Wno-stringop-overflow is passed to the compiler.  I tried disabling the
warning with #pragma diagnostic, no luck there.

Then I realized the error came from the link stage. Surely related to lto. I
modified my cmake files to add the -Wno-stringop-overflow to the link command
line and the warning disappear.

I'm surprise by this behavior. I looked through the documentation and could not
find anything that mentionned this. Is this something that is worth improving
in  the documentation or do I just need to get smarter ;-)

[Bug c/95189] New: memcmp being wrongly stripped (regression)

[gcc at pkh dot me]

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

Bug ID: 95189
   Summary: memcmp being wrongly stripped (regression)
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at pkh dot me
  Target Milestone: ---

Given the following C code:

% cat a.c
#include 
static const float z[1] = {0};
int f(float x) { return memcmp(, z, sizeof(x)); }

GCC 10 generates this on x86-64:

% gcc -Wall -O2 -c a.c && objdump -d -Mintel a.o

a.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   f3 0f 11 44 24 fc   movss  DWORD PTR [rsp-0x4],xmm0
   6:   0f b6 44 24 fc  movzx  eax,BYTE PTR [rsp-0x4]
   b:   c3  ret

This doesn't happen if "= {0}" is removed from the z initialization (wtf?).
It also doesn't happen with -O1.

[Bug analyzer/95188] New: analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

[mark at gcc dot gnu.org]

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

Bug ID: 95188
   Summary: analyzer-unsafe-call-within-signal-handler shows wrong
statement for signal registration event
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: mark at gcc dot gnu.org
  Target Milestone: ---

Reproducer:

wget https://sourceware.org/ftp/bzip2/bzip2-1.0.8.tar.gz
tar zxf bzip2-1.0.8.tar.gz
cd bzip2-1.0.8/
gcc -g -O2 -fanalyzer -c bzip2.c

In function ‘showFileNames.part.0’:
bzip2.c:677:4: warning: call to ‘fprintf’ from within signal handler [CWE-479]
[-Wanalyzer-unsafe-call-within-signal-handler]
  677 |fprintf (
  |^
  678 |   stderr,
  |   ~~~
  679 |   "\tInput file = %s, output file = %s\n",
  |   
  680 |   inName, outName
  |   ~~~
  681 |);
  |~
  ‘main’: events 1-2
|
| 1776 | IntNative main ( IntNative argc, Char *argv[] )
|  |   ^~~~
|  |   |
|  |   (1) entry to ‘main’
|..
| 1792 |smallMode   = False;
|  |~
|  ||
|  |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler
|
  event 3
|
|cc1:
| (3): later on, when the signal is delivered to the process
|
+--> ‘mySIGSEGVorSIGBUScatcher’: events 4-5
   |
   |  676 |if (noisy)
   |  |   ~
   |  |   |
   |  |   (5) following ‘true’ branch...
   |..
   |  816 | void mySIGSEGVorSIGBUScatcher ( IntNative n )
   |  |  ^~~~
   |  |  |
   |  |  (4) entry to ‘mySIGSEGVorSIGBUScatcher’
   |
 ‘mySIGSEGVorSIGBUScatcher’: event 6
   |
   |cc1:
   | (6): ...to here
   |
 ‘mySIGSEGVorSIGBUScatcher’: event 7
   |
   |cc1:
   | (7): calling ‘showFileNames.part.0’ from
‘mySIGSEGVorSIGBUScatcher’
   |
   +--> ‘showFileNames.part.0’: events 8-9
  |
  |  674 | void showFileNames ( void )
  |  |  ^
  |  |  |
  |  |  (8) entry to ‘showFileNames.part.0’
  |..
  |  677 |fprintf (
  |  |~
  |  ||
  |  |(9) call to ‘fprintf’ from within signal handler
  |  678 |   stderr,
  |  |   ~~~
  |  679 |   "\tInput file = %s, output file = %s\n",
  |  |   
  |  680 |   inName, outName
  |  |   ~~~
  |  681 |);
  |  |~  
  |

Note that the signal handler registration points to the wrong instruction:

| 1792 |smallMode   = False;
|  |~
|  ||
|  |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler

A workaround is to add  -fanalyzer-fine-grained, then it does show to correct
signal registration event:

  | 1808 |signal (SIGSEGV, mySIGSEGVorSIGBUScatcher);
  |  |~~
  |  ||
  |  |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler

[Bug c/95141] [8/9/10/11 Regression] Incorrect integer overflow warning message for bitand expression

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> So there's already (OVF) at
> 
> ((long unsigned int) IA1 & 158(OVF)) & 1
> 
> but we only check
> 
> 375   if (TREE_OVERFLOW_P (ret)
> 376   && !TREE_OVERFLOW_P (op0)
> 377   && !TREE_OVERFLOW_P (op1))
> 378 overflow_warning (EXPR_LOC_OR_LOC (expr, input_location),
> ret, expr);
> 
> which doesn't catch the pre-existing overflow on op0 which then propagates.
> 
> The original overflow is introduced folding short 158 to signed char -98(OVF)
> via convert.c:do_narrow:
> 
> 437   /* We should do away with all this once we have a proper
> 438  type promotion/demotion pass, see PR45397.  */
> 439   expr = maybe_fold_build2_loc (dofold, loc, ex_form, typex,
> 440 convert (typex, arg0),
> 441 convert (typex, arg1));
> 
> specifically the convert (typex, arg1).
> 
> Now TREE_OVERFLOW in general is quite a fragile thing, but it's tempting to
> adjust the overflow_warning guard for this case ...
> 
> The do_narrow code also specifically looks for overflow cases that matter
> and does not perform narrowing then so clearing TREE_OVERFLOW there would
> also look reasonable.
> 
> Thus like the following?  Should be cheaper than adding walk_tree to the
> diagnostic guard.
> 
> diff --git a/gcc/convert.c b/gcc/convert.c
> index 42509c518a9..ed00ded1a89 100644
> --- a/gcc/convert.c
> +++ b/gcc/convert.c
> @@ -436,9 +436,16 @@ do_narrow (location_t loc,
> }
>/* We should do away with all this once we have a proper
>  type promotion/demotion pass, see PR45397.  */
> +  /* Above we checked for all cases where overflow matters, avoid
> +geneating overflowed constants here which otherwise propagate
> +and cause spurious warnings, see PR95141.  */
> +  tree converted_arg1 = convert (typex, arg1);
> +  if (TREE_OVERFLOW_P (converted_arg1)
> + && !TREE_OVERFLOW_P (arg1))
> +   converted_arg1 = drop_tree_overflow (converted_arg1);
>expr = maybe_fold_build2_loc (dofold, loc, ex_form, typex,
> convert (typex, arg0),
> -   convert (typex, arg1));
> +   converted_arg1);
>return convert (type, expr);
>  }

Regresses

FAIL: gcc.dg/overflow-warn-5.c  (test for warnings, line 6)

which looks like a useful warning to preserve.  Lame "walk-tree" variant
catching this case:

diff --git a/gcc/c/c-fold.c b/gcc/c/c-fold.c
index 63becfeaf2c..bd21d247051 100644
--- a/gcc/c/c-fold.c
+++ b/gcc/c/c-fold.c
@@ -374,6 +374,7 @@ c_fully_fold_internal (tree expr, bool in_init, bool
*maybe_const_operands,
ret = fold (expr);
   if (TREE_OVERFLOW_P (ret)
  && !TREE_OVERFLOW_P (op0)
+ && !(BINARY_CLASS_P (op0) && TREE_OVERFLOW_P (TREE_OPERAND (op0, 1)))
  && !TREE_OVERFLOW_P (op1))
overflow_warning (EXPR_LOC_OR_LOC (expr, input_location), ret, expr);
   if (code == LSHIFT_EXPR

[Bug d/95184] GDC reporting multiple definitions of functions where DMD and LDC do not

[ibuclaw at gdcproject dot org]

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

--- Comment #4 from Iain Buclaw  ---
Done in r9-8603.

[Bug d/92216] GDC generate duplicate symbols when mixins and interfaces are used to gather

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8603-g3e84ee0fab9cedfa57fe86ea3c00608f6a873ab9
Author: Iain Buclaw 
Date:   Mon Mar 16 23:04:49 2020 +0100

d: Fix multiple definition error when using mixins and interfaces.

gcc/d/ChangeLog:

PR d/92216
* decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the
target
function is external to the current compilation.

gcc/testsuite/ChangeLog:

PR d/92216
* gdc.dg/imports/pr92216.d: New.
* gdc.dg/pr92216.d: New test.

[Bug tree-optimization/95187] New: Failure to optimize bool check into consecutive literals

[gabravier at gmail dot com]

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

Bug ID: 95187
   Summary: Failure to optimize bool check into consecutive
literals
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(bool b)
{
if (b)
return 1;
return 2;
}

This can be optimized into `2 - (int)b`. LLVM does this transformation, but GCC
does not.

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Btw, thanks for all these bugreports!

[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||easyhack,
   ||missed-optimization
   Last reconfirmed||2020-05-18
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/70320] msp430 asm volatile does not accept lower-case register names in clobber list

[jozefl at gcc dot gnu.org]

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

jozefl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jozefl at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from jozefl at gcc dot gnu.org ---
Fixed since GCC 10.

[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`

[jozefl at gcc dot gnu.org]

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

jozefl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jozefl at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from jozefl at gcc dot gnu.org ---
Fixed.

[Bug fortran/95186] New: Optimize allocate(..., source=0) or allocate(..., source=[0.0, 0.0, ...]) to use calloc instead of malloc

[burnus at gcc dot gnu.org]

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

Bug ID: 95186
   Summary: Optimize allocate(..., source=0) or allocate(...,
source=[0.0, 0.0, ...]) to use calloc instead of
malloc
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

calloc returns zeroed memory, hence, for "source=0.0" or "source=0" (or the
array equivalent, if ever used), calloc instead of malloc could be used.

[Bug target/78554] Internal Compiler Error in msp430 target with -mlarge, -O{s123}

[jozefl at gcc dot gnu.org]

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

jozefl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jozefl at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from jozefl at gcc dot gnu.org ---
Fixed.

[Bug target/78838] msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created

[jozefl at gcc dot gnu.org]

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

jozefl at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||jozefl at gcc dot gnu.org

--- Comment #6 from jozefl at gcc dot gnu.org ---
Fixed.

[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

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

template  class f {
  template  f();
  template  requires false f();
};

[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug tree-optimization/95185] New: Failure to optimize specific kind of sign comparison check

[gabravier at gmail dot com]

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

Bug ID: 95185
   Summary: Failure to optimize specific kind of sign comparison
check
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int x, int y)
{
return (x >= 0) == (y <= 0);
}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94718 was resolved and most of the
patterns are now optimized, but this specific one isn't. It's equivalent to `(x
< 0) ^ (y <= 0)`, which can be done with a single compare instead of two. That
transformation is made by LLVM, but not by GCC.

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #5)
> > FakeStack (stack_size_log=20):bail out after 8192
> > FakeStack (stack_size_log=20):bail out after 16384
> > FakeStack (stack_size_log=20):bail out after 4096
> > FakeStack (stack_size_log=20):bail out after 8192
> > ...
> 
> This comes after the 27000 success Fake stack allocations.

I guess the important question is what is different with clang that it behaves
differently, whether it allocates fake stack for fewer functions, or what else.
 E.g. try ltrace on it to see how many each one allocates and if it is very
different, it would be nice to understand why.

[Bug tree-optimization/95171] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 2)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|11.0|
  Known to work||11.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/95171] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 2)

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-451-gfe168751c5c1c517c7c89c9a1e4e561d66b24663
Author: Richard Biener 
Date:   Mon May 18 08:51:23 2020 +0200

middle-end/95171 - inlining of trapping compare into non-call EH fn

This fixes always-inlining across -fnon-call-exception boundaries
for conditions which we do not allow to throw.

2020-05-18  Richard Biener  

PR middle-end/95171
* tree-inline.c (remap_gimple_stmt): Split out trapping compares
when inlining into a non-call EH function.

* gcc.dg/pr95171.c: New testcase.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[crazylht at gmail dot com]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #2)
> But such an instruction isn't always redundant, it really depends on what
> the previous setter of the register did, whether the upper 128 bit of the
> 256-bit register are already guaranteed to be zero or not.

(define_insn "avx_vec_concat"
  [(set (match_operand:V_256_512 0 "register_operand" "=x,v,x,Yv")
(vec_concat:V_256_512
  (match_operand: 1 "nonimmediate_operand" "x,v,xm,vm")
  (match_operand: 2 "nonimm_or_0_operand"
"xm,vm,C,C")))]

define_insn "*_vinsert_0"
  [(set (match_operand:AVX512_VEC 0 "register_operand" "=v,x,Yv")
(vec_merge:AVX512_VEC
  (match_operand:AVX512_VEC 1 "reg_or_0_operand" "v,C,C")
  (vec_duplicate:AVX512_VEC
(match_operand: 2 "nonimmediate_operand"
"vm,xm,vm"))
  (match_operand:SI 3 "const_int_operand" "n,n,n")))]


Upper part already zeroed.

> Thus the #c1 patch looks incorrect to me, one would need peephole2s or some
> combine patterns or target specific pass etc. to discover that at least for
> the common cases; and it isn't something we model in the RTL patterns (what
> insns guarantee which upper bits zero and what do not; and for some there
> can be different choices even in the same define_insn, we could implement
> something using widened registers and then there would be no guarantee etc.).

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[crazylht at gmail dot com]

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

--- Comment #3 from Hongtao.liu  ---
You're right, from intel SDM: 
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are
zeroed.

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[rguenth at gcc dot gnu.org]

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

Bug 95172 Summary: [11 Regression] wrong code at -O1 on x86_64-linux-gnu since 
r11-272-gb6ff3ddecfa93d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95172

   What|Removed |Added

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

[Bug tree-optimization/95172] [11 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-272-gb6ff3ddecfa93d53

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Blocks||57359
 Status|ASSIGNED|RESOLVED

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
[Bug 57359] store motion causes wrong code for union access at -O3

[Bug tree-optimization/95172] [11 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-272-gb6ff3ddecfa93d53

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:52a0f83980082c9995f2d8ec9b88548520fb8a5f

commit r11-450-g52a0f83980082c9995f2d8ec9b88548520fb8a5f
Author: Richard Biener 
Date:   Mon May 18 09:17:24 2020 +0200

tree-optimization/95172 - avoid mixing conditionalized and ordered SM

The following testcase shows a missed optimization that then leads to
wrong-code when issueing SMed stores on exits.  When we were able to
compute an ordered sequence of stores for an exit we need to emit
that in the correct order and we can emit it disregarding to any
conditional for whether a store actually happened (we know it did).
We can also improve detection as of whether we need conditional
processing at all.  Both parts fix the testcase.

2020-05-18  Richard Biener  

PR tree-optimization/95172
* tree-ssa-loop-im.c (execute_sm): Get flag whether we
eventually need the conditional processing.
(execute_sm_exit): When processing an orderd sequence
avoid doing any conditional processing.
(hoist_memory_references): Pass down whether all edges
have ordered processing for a ref to execute_sm.

* gcc.dg/torture/pr95172.c: New testcase.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
But such an instruction isn't always redundant, it really depends on what the
previous setter of the register did, whether the upper 128 bit of the 256-bit
register are already guaranteed to be zero or not.
Thus the #c1 patch looks incorrect to me, one would need peephole2s or some
combine patterns or target specific pass etc. to discover that at least for the
common cases; and it isn't something we model in the RTL patterns (what insns
guarantee which upper bits zero and what do not; and for some there can be
different choices even in the same define_insn, we could implement something
using widened registers and then there would be no guarantee etc.).

[Bug d/95075] gcc/d/dmd/dscope.c: 2 * strange assignments ?

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
"""
I think I wrote it that way to emphasize what the result should be, and relied
on the optimizer removing the self-assignment. So, the code is correct.
"""

So I'll remove the self-assignment with a comment expressing this instead.

[Bug target/94934] Failure to inline addv

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Gabriel Ravier from comment #3)
> In that case, it looks really easy to reimplemnet `-ftrapv` as literally
> just enabling `-fsanitize=signed-integer-overflow
> -fsanitize-undefined-trap-on-error`.

It shouldn't be literally that, because -ftrapv should be able to coexist with
other UBSan sanitizers (just not signed-integer-overflow) and e.g. let the
other UBSan sanitizers have different decision on what to do on error (the
trap. vs. fatal error vs. just diagnostics and continue).
And for -ftrapv we should consider using the library functions rather than
emitting code inline if it would be too large to match past behavior.

[Bug c++/71954] template partial specialization for constexpr error

[suratovvlad at gmail dot com]

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

--- Comment #2 from Vladislav Suratov  ---
Confirmed with 9.3, 10.1 and current trunk (11.0). 
Tested with --std=c++17, meanwhile clang 10.0 (and trunk) and MSVC 19.24 and
MSVC 19.25 successfully compile it.
The following example is what I used for testing:

#include 

struct Test1
{
template 
struct Helper1{
  static constexpr bool value = false;
};

template 
struct Helper1>{
  static constexpr bool value = true;
};
};

struct Test2
{
template 
static constexpr bool Helper1 = false;

template 
static constexpr bool Helper1> = true;
};

static_assert(Test1::Helper1>::value, "Check");
static_assert(Test2::Helper1>, "Check");

[Bug d/95184] GDC reporting multiple definitions of functions where DMD and LDC do not

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #3 from Iain Buclaw  ---
OK, I'll prep a backport then.

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
> FakeStack (stack_size_log=20):bail out after 8192
> FakeStack (stack_size_log=20):bail out after 16384
> FakeStack (stack_size_log=20):bail out after 4096
> FakeStack (stack_size_log=20):bail out after 8192
> ...

This comes after the 27000 success Fake stack allocations.

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Martin Liška  ---
I was able to reproduce that!
The problem is the number of fake stacks that are exhausted.
I see 27000x:

FakeStack (stack_size_log=20):succ after 0
FakeStack (stack_size_log=20):succ after 0
FakeStack (stack_size_log=20):succ after 0
FakeStack (stack_size_log=20):succ after 0
...
FakeStack (stack_size_log=20):bail out after 8192
FakeStack (stack_size_log=20):bail out after 16384
FakeStack (stack_size_log=20):bail out after 4096
FakeStack (stack_size_log=20):bail out after 8192
...

So it seems that the program uses enormous number of stacks. Or the run-time
does not release them in an efficient way.

[Bug libstdc++/95170] GetTickCount64 cannot get found in KERNEL32.dll on Legacy Windows Platforms like Windows XP, 2000

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Right, libstdc++ doesn't use GetTickCount64 anywhere.

[Bug d/92216] GDC generate duplicate symbols when mixins and interfaces are used to gather

[oss at cogitri dot dev]

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

Rasmus Thomsen  changed:

   What|Removed |Added

 CC||oss at cogitri dot dev

--- Comment #5 from Rasmus Thomsen  ---
*** Bug 95184 has been marked as a duplicate of this bug. ***

[Bug d/95184] GDC reporting multiple definitions of functions where DMD and LDC do not

[oss at cogitri dot dev]

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

Rasmus Thomsen  changed:

   What|Removed |Added

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

--- Comment #2 from Rasmus Thomsen  ---
Yes, the patch mentioned in that bug fixed it, thanks!

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