[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 #17 from Jiu Fu Guo  ---
For this case, as you said, I also think it is better to avoid unrolling for
the loop. 
'#pragma GCC unroll 1' could help to prevent the loop to be unrolled, even
someone compiles it with aggressive unroll options.
So, add pragma may be acceptable for in_pack_i4.c.

And at the same time, we would also enhance GCC 'cunroll' for this kind of
loop.

[Bug fortran/95071] ICE on select type block with assumed-rank selector

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-12

--- Comment #1 from Martin Liška  ---
It's rejected also for 4.8.0+, the ICE started with r10-2912-g70570ec192745095.

[Bug c++/95074] Function found via ADL when it should not

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
This is where we're confused by the function introduced by M::f:
/* We do not perform argument-dependent lookup if
   normal lookup finds a non-function, in accordance
   with the expected resolution of DR 218.  */
else if (!args->is_empty ()
 && is_overloaded_fn (postfix_expression))
  {
/* We only need to look at the first function,
   because all the fns share the attribute we're
   concerned with (all member fns or all local
   fns).  */
tree fn = get_first_fn (postfix_expression);
fn = STRIP_TEMPLATE (fn); 

/* Do not do argument dependent lookup if regular
   lookup finds a member function or a block-scope
   function declaration.  [basic.lookup.argdep]/3  */
if (!((TREE_CODE (fn) == USING_DECL && DECL_DEPENDENT_P
(fn)) 
  || DECL_FUNCTION_MEMBER_P (fn)
  || DECL_LOCAL_FUNCTION_P (fn)))
  {
koenig_p = true; 
if (!any_type_dependent_arguments_p (args))
  postfix_expression
= perform_koenig_lookup (postfix_expression, args, 
 complain);
  }
  }

[Bug c++/95074] Function found via ADL when it should not

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Marek Polacek  ---
Not a regression.

[Bug c++/95074] New: Function found via ADL when it should not

[mpolacek at gcc dot gnu.org]

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

Bug ID: 95074
   Summary: Function found via ADL when it should not
   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: ---

namespace N {
  struct S { };
  void f(S);
}

namespace M {
  void f(int);
}

int
main ()
{
  N::S s;
  extern void f(char); // #1
  using M::f; // #2
  f(s);
}

compiles fine, but shouldn't: [basic.lookup.argdep]/3: If X (the lookup set
produced by unqualified lookup) contains 
-- a block-scope function declaration that is not a using-declaration
[...]
then Y (the lookup set produced by ADL) is empty.

So the M::f here is fine but #1 should prevent ADL.  But we still find N::f.

If lines #1 and #2 are switched, this test rejected.

[Bug c++/95073] New: Add "did you mean" when fn declaration could be found via ADL

[mpolacek at gcc dot gnu.org]

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

Bug ID: 95073
   Summary: Add "did you mean" when fn declaration could be found
via ADL
   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: ---

namespace N {
  struct X { };
  void f(X);
}

void
g ()
{
  extern void f(); // #1
  N::X x;
  f(x); // calls locally declared function #1, no ADL
}

we issue

q.C: In function ‘void g()’:
q.C:11:6: error: too many arguments to function ‘void f()’
   11 |   f(x);
  |  ^
q.C:9:15: note: declared here
9 |   extern void f();
  |   ^

but we could do better and say

q.C:11:3: error: too many arguments to function call, expected 0, have 1; did
you mean 'N::f'?
  f(x);
  ^
  N::f
q.C:3:8: note: 'N::f' declared here
  void f(X);
   ^

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[luoxhu at gcc dot gnu.org]

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

Bug 83403 Summary: Missed register promotion opportunities in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83403

   What|Removed |Added

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

[Bug tree-optimization/83403] Missed register promotion opportunities in loop

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from luoxhu at gcc dot gnu.org ---
Fixed on master.

[Bug target/91518] [9 Regression] segfault when run CPU2006 465.tonto since r263875

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from luoxhu at gcc dot gnu.org ---
Also fixed on gcc-9.

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

[luoxhu at gcc dot gnu.org]

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

Bug 91518 Summary: [9 Regression] segfault when run CPU2006 465.tonto since 
r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518

   What|Removed |Added

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

[Bug go/95061] shared libgo library not found when running the testsuite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Ian Lance Taylor
:

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

commit r10-8134-gfbfa806e65c552e81b363756fd8e2925651f7333
Author: Ian Lance Taylor 
Date:   Mon May 11 16:23:44 2020 -0700

syscall: append to environment in tests, don't clobber it

This is a partial backport of https://golang.org/cl/233318.
It's only a partial backport because part of the change was
already applied to libgo in CL 193497 as part of the update
to the Go 1.13beta1 release.

Fixes PR go/95061

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/233359

[Bug middle-end/95072] -Warray-bounds false positive with flexible array bounds (regression from GCC 9)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2020-05-12
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||10.1.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94985

--- Comment #1 from Martin Sebor  ---
Confirmed.  Possibly related to or duplicate of pr94985, or simply a bug in
level 2 of the warning when it uses the size of the accessed member even for
raw memory functions for memcpy (as opposed to using the whole object) but
neglects to take flexible array members into consideration.

[Bug go/95061] shared libgo library not found when running the testsuite

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-302-g4f157ed7749fd13c3562dd09696f7d675b86434f
Author: Ian Lance Taylor 
Date:   Mon May 11 16:23:44 2020 -0700

syscall: append to environment in tests, don't clobber it

This is a partial backport of https://golang.org/cl/233318.
It's only a partial backport because part of the change was
already applied to libgo in CL 193497 as part of the update
to the Go 1.13beta1 release.

Fixes PR go/95061

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/233359

[Bug middle-end/95072] New: -Warray-bounds false positive with flexible array bounds (regression from GCC 9)

[eggert at cs dot ucla.edu]

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

Bug ID: 95072
   Summary: -Warray-bounds false positive with flexible array
bounds (regression from GCC 9)
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 48514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48514=edit
Test program illustrating the -Warray-bounds=2 false alarm

I ran into several false alarms when building GNU Emacs master with GCC 10.1.0
x86-64, which I compiled from source under RHEL 7.7. To reproduce one of them,
compile the attached file xx3.i (a drastic simplification of the Emacs
original) with:

gcc -S -Warray-bounds=2 -O2 xx3.i

The output I get is:

xx3.i: In function 'set_frame_menubar':
xx3.i:17:5: warning: 'memcpy' offset 3 from the object at 'menu_bar_vector' is
\
out of the bounds of referenced subobject 'contents' with type 'union Lisp_X
*[\
]' at offset 3 [-Warray-bounds]
   17 | memcpy (previous_items,
  | ^~~
   18 |  ((struct Lisp_Vector *) ((char *) menu_bar_vector - 5))->contents,
  |  ~~
   19 |  previous_menu_items_used);
  |  ~
xx3.i:9:17: note: subobject 'contents' declared here
9 | Lisp_Object contents[];
  | ^~~~

In the Emacs original, menu_bar_vector is a tagged pointer; subtracting 5 gives
you the true pointer to the struct. Somehow the subtraction of 5 confuses GCC
and it incorrectly claims that the flexible array member has an upper bound of
at most 3.

I do not observe the problem with GCC 9.3.0 on the same platform.

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

[seurer at linux dot vnet.ibm.com]

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

--- Comment #10 from Bill Seurer  ---
I tried the update on the spec 2000/2006 tests that were ICEing before and they
compile now.

[Bug fortran/95071] New: ICE on select type block with assumed-rank selector

[jrfsousa at gmail dot com]

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

Bug ID: 95071
   Summary: ICE on select type block with assumed-rank selector
   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 48513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48513=edit
Fortran code demonstrating problems.

Hi all!

ICE on wrong code with 10 and 11, rejects valid using -finit-integer and 9.

GNU Fortran (GCC) 9.3.1 20200503
GNU Fortran (GCC) 10.0.1 20200505 (prerelease)
GNU Fortran (GCC) 11.0.0 20200503 (experimental)

Thank you very much.

Best regards,
José Rui

[Bug go/94766] gcc/go/gofrontend/gogo.h:1076:25: performance: Function parameter 'afnname' should be passed by const reference. [passedByValue]

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed by
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2f4aeb2f53d96690953fabab487fd1d922f1c95f

Thanks.

[Bug c++/95066] [C++ 20] Incorrect successful compilation with a conditional explicit

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Marek Polacek  ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545565.html

[Bug target/95070] New: vec_cntlz_lsbb implementation uses BE semantics on LE

[pc at us dot ibm.com]

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

Bug ID: 95070
   Summary: vec_cntlz_lsbb implementation uses BE semantics on LE
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pc at us dot ibm.com
  Target Milestone: ---

Created attachment 48512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48512=edit
test case

This:
--
vector unsigned char a = { 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
int r = vec_cntlz_lsbb (a);
--
returns 14 on LE and 0 on BE. It should return 0 on both.

vec_cntlz_lsbb counts bytes with least significant bits of 0 *starting from the
lowest element number*.  In the above code, a[0] == 0xFF, so the count should
find 0 bytes.

The same issue occurs with vec_cnttz_lsbb (which should find 14 bytes in the
above example on both LE and BE, but finds 0 and 14, respectively).

[Bug c++/95069] New: Capture by reference cannot use list-initalization

[redi at gcc dot gnu.org]

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

Bug ID: 95069
   Summary: Capture by reference cannot use list-initalization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

int i;
int& f(int& i) { return i; }
auto ok = [ = f(i)] {};
auto err = [{f(i)}] {};

Clang, EDG and MSVC accept this in C++14 mode, but G++ doesn't:

l.cc:4:20: error: cannot capture ‘{f(i)}’ by reference
4 | auto err = [{f(i)}] {};
  |^

[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041

[casner at acm dot org]

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

Stephen Casner  changed:

   What|Removed |Added

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

--- Comment #5 from Stephen Casner  ---
This ICE occurred because my additions to config.gcc were incomplete.  Those
additions did not include elfos.h for pdp11-elf32 so SUPPORTS_ONE_ONLY==0 and
TARGET_SUPPORTS_WEAK==0 which caused have_weak==false which caused
comdat_linkage() to set TREE_PUBLIC(decl)=0, resulting in the assert failure. 
This was probably not a supported configuration for compiling C++ code.

[Bug c++/95066] [C++ 20] Incorrect successful compilation with a conditional explicit

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Reduced:

template 
struct Foo {
  template 
  explicit(static_cast(true)) operator Foo();
};

template 
template 
Foo::operator Foo() {
  return {};
}

int
main ()
{
  Foo a;
  Foo b = a;
}

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Argh, this only works if the wide encoding happens to be UCS-4 (or for 16-bit
wchar_t, UCS-2) because std::codecvt_utf8 only supports converting between that
and UTF-8. Which is why I used std::codecvt in the
first place.

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Using std::codecvt_utf8 fixes it:

--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -836,8 +836,7 @@ namespace __detail
  }
  }
 #else // ! windows
-   struct _UCvt : std::codecvt<_CharT, char, std::mbstate_t>
-   { } __cvt;
+   struct _UCvt : std::codecvt_utf8<_CharT> { } __cvt;
std::string __str;
if (__str_codecvt_out_all(__f, __l, __str, __cvt))
  return __str;

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Summary|wstring-constructor of  |[9/10/11 Regression]
   |std::filesystem::path   |wstring-constructor of
   |throws for non-ASCII|std::filesystem::path
   |characters  |throws for non-ASCII
   ||characters
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
In libstdc++ filesystem::path uses std::codecvt to
convert from wide character strings in the native wide encoding format (which
is set by GCC's -fwide-exec-charset option) to the native encoding for
pathnames.

The native encoding for pathnames should be UTF-8, but because we use codecvt,
which uses wcsnrtombs, we're actually converting to the narrow encoding of the
current C locale (which is ASCII by default as Carlos said).

So I think libstdc++ needs to use a different conversion from the native wide
encoding to UTF-8 (to be independent of the current locale's narrow encoding).

This would have changed with r272385 (and r272389 on the gcc-9 branch) which
was fixing PR libstdc++/90281.

[Bug libstdc++/95048] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[carlos at redhat dot com]

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

Carlos O'Donell  changed:

   What|Removed |Added

 CC||carlos at redhat dot com

--- Comment #2 from Carlos O'Donell  ---
(In reply to Jonathan Wakely from comment #1)
> This happens because glibc won't convert the wide string to UTF-8:
> 
> #include 
> #include 
> 
> int main()
> {
>   const wchar_t wstr[] = L"ä";
>   const wchar_t* from = wstr;
>   char to[10];
>   mbstate_t s;
>   size_t res = wcsnrtombs(to, , 1, sizeof(to), );
>   assert(res != (size_t)-1);
> }
> 
> I'm not yet sure why glibc refuses to convert that.

ISO C says:

"At program startup, the equivalent of
setlocale(LC_ALL, "C");
is executed."

Which means you are trying to convert UTF-8 to ASCII.

You should call setlocale with a non-ASCII character set to make this work.

[Bug libstdc++/95048] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This happens because glibc won't convert the wide string to UTF-8:

#include 
#include 

int main()
{
  const wchar_t wstr[] = L"ä";
  const wchar_t* from = wstr;
  char to[10];
  mbstate_t s;
  size_t res = wcsnrtombs(to, , 1, sizeof(to), );
  assert(res != (size_t)-1);
}

I'm not yet sure why glibc refuses to convert that.

[Bug c++/92583] [8/9 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:15552

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:0f50f6daa140186a048cbf33f54f4591eabf5f12

commit r11-291-g0f50f6daa140186a048cbf33f54f4591eabf5f12
Author: Jason Merrill 
Date:   Mon May 11 15:46:59 2020 -0400

c++: tree walk into TYPENAME_TYPE.

While looking at 92583/92654 it occurred to me that typename types needed
the same fix.  So extract_locals_r also needs to see the TYPE_CONTEXT of a
TYPENAME_TYPE.  But it must not look through a typedef.

Most tree walking in the front end wants to walk through the syntactic form
of a type of expression, and doesn't care about the type referred to by a
typedef.  But min_vis_r does care.

gcc/cp/ChangeLog
2020-05-11  Jason Merrill  

PR c++/92583
PR c++/92654
* tree.c (cp_walk_subtrees): Stop at typedefs.
Handle TYPENAME_TYPE here.
* pt.c (find_parameter_packs_r): Not here.
(for_each_template_parm_r): Clear *walk_subtrees.
* decl2.c (min_vis_r): Look through typedefs.

[Bug c++/92654] [8/9 Regression] internal compiler error: in lookup_template_class_1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:0f50f6daa140186a048cbf33f54f4591eabf5f12

commit r11-291-g0f50f6daa140186a048cbf33f54f4591eabf5f12
Author: Jason Merrill 
Date:   Mon May 11 15:46:59 2020 -0400

c++: tree walk into TYPENAME_TYPE.

While looking at 92583/92654 it occurred to me that typename types needed
the same fix.  So extract_locals_r also needs to see the TYPE_CONTEXT of a
TYPENAME_TYPE.  But it must not look through a typedef.

Most tree walking in the front end wants to walk through the syntactic form
of a type of expression, and doesn't care about the type referred to by a
typedef.  But min_vis_r does care.

gcc/cp/ChangeLog
2020-05-11  Jason Merrill  

PR c++/92583
PR c++/92654
* tree.c (cp_walk_subtrees): Stop at typedefs.
Handle TYPENAME_TYPE here.
* pt.c (find_parameter_packs_r): Not here.
(for_each_template_parm_r): Clear *walk_subtrees.
* decl2.c (min_vis_r): Look through typedefs.

[Bug tree-optimization/95060] vfnmsub132ps is not generated with -ffast-math

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I see the needed simplifiers in match.pd:
  (simplify
   (negate (fmas@3 @0 @1 @2))
   (if (single_use (@3))
(IFN_FNMS @0 @1 @2
but perhaps the problem is that there is no forwprop after widening_mul that
would perform that optimization?
So, shall widening_mul itself if it matches some FMA check if the result of
IFN_{FMA,FMS,FNMA,FNMS} it created isn't negation and if yes, try to
gimple_fold it?

[Bug c++/90748] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:15564

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
   |tsubst_copy, at |tsubst_copy, at
   |cp/pt.c:15564   |cp/pt.c:15564

--- Comment #7 from Jason Merrill  ---
Fixed for GCC 11 so far.

[Bug c++/90748] [9/10/11 Regression] ICE in tsubst_copy, at cp/pt.c:15564

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r11-289-gf981395c220c9afd73be138294946e085e64af78
Author: Jason Merrill 
Date:   Mon May 11 15:39:44 2020 -0400

c++: Use of 'this' in parameter declaration [PR90748]

We were incorrectly accepting the use of 'this' at parse time and then
crashing when we tried to instantiate it.  It is invalid because 'this' is
not in scope until after the function-cv-quals.  So let's hoist setting
current_class_ptr up from cp_parser_late_return_type_opt into
cp_parser_direct_declarator where it can work for noexcept as well.

gcc/cp/ChangeLog
2020-05-11  Jason Merrill  

PR c++/90748
* parser.c (inject_parm_decls): Set current_class_ptr here.
(cp_parser_direct_declarator): And here.
(cp_parser_late_return_type_opt): Not here.
(cp_parser_noexcept_specification_opt): Nor here.
(cp_parser_exception_specification_opt)
(cp_parser_late_noexcept_specifier): Remove unneeded parameters.

[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|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from anlauf at gcc dot gnu.org ---
Should be fixed.  Please reopen if you find further issues.

Sorry for the breakage.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> It gets actually really weird during parsing.

Nah.  gfortran runs a sequence of matchers, and queues
errors as it runs.  If a matcher is not found, then
(normally only) the last queued error message is emitted.
If a matcher is found, the error message queue is cleaned
up.

> The following (invalid) code shows that the parser is still in an
> early phase where it has not yet decided that it is a FORMAT statement,
> but rather could be something else:
> 
>   format('x') = x
> end
> 
> This gives:
> 
> 1 |   format('x') = x
>   |  1
> Error: The function result on the lhs of the assignment at (1) must have the
> pointer attribute.
> 
> while e.g. Intel detects:
> 
> foo.f90(1): error #6072: A dummy argument of a statement function must be a
> scalar identifier.   ['x']
>   format('x') = x
> -^

gfortran and ifort are simply trying different sequences of
matchers.

> The simplest solution is to defer error detection and recovery by restoring
> the previous behavior when the basic type of operand 2 to gfc_divide is
> non-numeric:
> 
> diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
> index 1cd0867a941..dd72f44d377 100644
> --- a/gcc/fortran/arith.c
> +++ b/gcc/fortran/arith.c
> @@ -1828,7 +1828,8 @@ gfc_divide (gfc_expr *op1, gfc_expr *op2)
> rc = ARITH_DIV0;
>   break;
> default:
> - gfc_internal_error ("gfc_divide(): Bad basic type");
> + /* basic type is non-numeric, handle this elsewhere.  */
> + break;
> }
>if (rc == ARITH_DIV0)
> {

>From my long forgotten days of working in arith.c, it is almost
always wrong to emit a gfc_internal_error.  Typical an error
message is generated during simplification or resolution that
catches a problems.

[Bug fortran/93499] ICE in gfc_zero_size_array, at fortran/arith.c:1686

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:1422c2e4462c9b7c44aa035ac56af77565556181

commit r11-288-g1422c2e4462c9b7c44aa035ac56af77565556181
Author: Harald Anlauf 
Date:   Mon May 11 21:27:11 2020 +0200

PR fortran/95053 - ICE in gfc_divide(): Bad basic type

The fix for PR 93499 introduced a too strict check in gfc_divide
that could trigger errors in the early parsing phase.  Relax the
check and defer to a later stage.

gcc/fortran/

2020-05-11  Harald Anlauf  

PR fortran/95053
* arith.c (gfc_divide): Do not error out if operand 2 is
non-numeric.  Defer checks to later stage.

gcc/testsuite/

2020-05-11  Harald Anlauf  

PR fortran/95053
* gfortran.dg/pr95053.f: New test.

[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 #7 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:1422c2e4462c9b7c44aa035ac56af77565556181

commit r11-288-g1422c2e4462c9b7c44aa035ac56af77565556181
Author: Harald Anlauf 
Date:   Mon May 11 21:27:11 2020 +0200

PR fortran/95053 - ICE in gfc_divide(): Bad basic type

The fix for PR 93499 introduced a too strict check in gfc_divide
that could trigger errors in the early parsing phase.  Relax the
check and defer to a later stage.

gcc/fortran/

2020-05-11  Harald Anlauf  

PR fortran/95053
* arith.c (gfc_divide): Do not error out if operand 2 is
non-numeric.  Defer checks to later stage.

gcc/testsuite/

2020-05-11  Harald Anlauf  

PR fortran/95053
* gfortran.dg/pr95053.f: New test.

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
Hi,

I was unable to find a performance problem, so I take back my
presumption of the original problem.  I have checked two versions
of the preprocessed source, with

+#pragma GCC unroll 1
   while (count[n] == extent[n])
 {

as the difference.

What I found was that with the pragma and -O2

- stack size decreased from 752 bytes to 432 bytes, from the stdu 1,-752(1)
  instruction

- object code size decreased from 7042 to 1936 bytes, determined by looking
  at the addresses of objdump --disassemble

(I also found that #pragma GCC unroll 2 was ignored, but that's for another
PR).

Considering we have this idiom around 400 times in libgfortran, I would
estimate an increase of the size of libgfortan of around two Megabytes.

So, what to do?  I don't know if the gcc optimization routines can even
consider this particular loop to be one that is not often used,
although it is an inner loop.

As far as libgfortran is concerned, we could simply use the
pragma on our sources, but maybe other people have the same issue.

[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

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
It gets actually really weird during parsing.

The following (invalid) code shows that the parser is still in an
early phase where it has not yet decided that it is a FORMAT statement,
but rather could be something else:

  format('x') = x
end

This gives:

1 |   format('x') = x
  |  1
Error: The function result on the lhs of the assignment at (1) must have the
pointer attribute.

while e.g. Intel detects:

foo.f90(1): error #6072: A dummy argument of a statement function must be a
scalar identifier.   ['x']
  format('x') = x
-^

The simplest solution is to defer error detection and recovery by restoring
the previous behavior when the basic type of operand 2 to gfc_divide is
non-numeric:

diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
index 1cd0867a941..dd72f44d377 100644
--- a/gcc/fortran/arith.c
+++ b/gcc/fortran/arith.c
@@ -1828,7 +1828,8 @@ gfc_divide (gfc_expr *op1, gfc_expr *op2)
rc = ARITH_DIV0;
  break;
default:
- gfc_internal_error ("gfc_divide(): Bad basic type");
+ /* basic type is non-numeric, handle this elsewhere.  */
+ break;
}
   if (rc == ARITH_DIV0)
{

[Bug middle-end/95052] Excess padding of partially initialized strings/char arrays

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 48511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48511=edit
gcc11-pr95052.patch

Untested fix.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[myron.walker at gmail dot com]

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

--- Comment #22 from Myron Walker  ---
It does the same things a gcov and lcov  combined but in python.  It also does
merging of data but in a different way than gcov-tool.  I might need to change
that.  Another part of it is to allow access to different types of resource
location hinting.  so a gcov prefix for a source code might be a github url and
token.  A gcno file hint might be a web url or sub or nfs share.  Like wise the
data file hints might be http, smb or nfs prefixes.

https://github.com/myronww/pycover

Still a work in progress though.

[Bug fortran/95068] [10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

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

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

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

Further reduced (ICEs down to r7, r6 rejects it) :


$ cat z2.f90
function f() result(x)
   associate (y => (f))
   end associate
end


$ gfortran-11-20200510 -c z2.f90
z2.f90:2:20:

2 |associate (y => (f))
  |1
Warning: Non-RECURSIVE procedure 'f' at (1) is possibly calling itself
recursively.  Declare it RECURSIVE or use '-frecursive'
during RTL pass: expand
z2.f90:2:0:

2 |associate (y => (f))
  |
internal compiler error: in convert_mode_scalar, at expr.c:313
0x8c13cc convert_mode_scalar
../../gcc/expr.c:313
0x8c13cc convert_move(rtx_def*, rtx_def*, int)
../../gcc/expr.c:297
0x8cd3f2 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:8670
0x7c3175 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3786
0x7c3175 expand_gimple_stmt
../../gcc/cfgexpand.c:3847
0x7c7d57 expand_gimple_basic_block
../../gcc/cfgexpand.c:5887
0x7ca3ce execute
../../gcc/cfgexpand.c:6571



$ gfortran-11-20200510-chk -c z2.f90
z2.f90:2:20:

2 |associate (y => (f))
  |1
Warning: Non-RECURSIVE procedure 'f' at (1) is possibly calling itself
recursively.  Declare it RECURSIVE or use '-frecursive'
z2.f90:1:0:

1 | function f() result(x)
  |
Error: non-trivial conversion in unary operation
real(kind=4)
real(kind=4)  (void)
y = ((f.0_1));
z2.f90:1:0: internal compiler error: 'verify_gimple' failed
0xd9158d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5113
0xa4ded1 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:14917
0xa4e187 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:14988
0x889347 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x88c771 analyze_functions
../../gcc/cgraphunit.c:1227
0x88d982 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2971

[Bug fortran/95068] New: [10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

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

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

Bug ID: 95068
   Summary: [10/11 Regression] ICE in gfc_get_class_from_expr, at
fortran/trans-expr.c:484
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190922 and 20190929 :


$ cat z1.f90
program p
   type t
   end type
contains
   function f() result(x)
  class(t), allocatable :: x
  associate (y => (f))
  end associate
   end
end


$ gfortran-9 -c z1.f90   # no error
z1.f90:7:23:

7 |   associate (y => (f))
  |   1
Warning: Non-RECURSIVE procedure 'f' at (1) is possibly calling itself
recursively.  Declare it RECURSIVE or use '-frecursive'



$ gfortran-11-20200510-chk -c z1.f90
z1.f90:7:23:

7 |   associate (y => (f))
  |   1
Warning: Non-RECURSIVE procedure 'f' at (1) is possibly calling itself
recursively.  Declare it RECURSIVE or use '-frecursive'
z1.f90:7:0:

7 |   associate (y => (f))
  |
internal compiler error: tree check: expected class 'expression', have
'declaration' (function_decl) in tree_operand_check, at tree.h:3792
0x61669c tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9736
0x776349 expr_check(tree_node*, char const*, int, char const*)
../../gcc/tree.h:3463
0x776349 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3792
0x776349 gfc_get_class_from_expr(tree_node*)
../../gcc/fortran/trans-expr.c:484
0x7d2502 trans_associate_var
../../gcc/fortran/trans-stmt.c:2100
0x7d8d99 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2283
0x73a207 trans_code
../../gcc/fortran/trans.c:1960
0x77194d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6835
0x77165c gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5830
0x77165c gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6767
0x6ea066 translate_all_program_units
../../gcc/fortran/parse.c:6306
0x6ea066 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x7364ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug c++/94775] [8/9/10/11 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48

[mpolacek at gcc dot gnu.org]

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

--- Comment #16 from Marek Polacek  ---
It caused testsuite failures on non-x86-64 platforms, see bug 94896.

[Bug fortran/95067] New: [10/11 Regression] ICE in tree_fits_shwi_p, at tree.c:7262

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

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

Bug ID: 95067
   Summary: [10/11 Regression] ICE in tree_fits_shwi_p, at
tree.c:7262
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190526 and 20190602, with option -gstabs :


$ cat z1.f90
program p
   character(:), allocatable :: a
   character(3) :: b[*]
   a = 'abc'
   b[1] = a
end


$ gfortran-9 -c z1.f90 -fcoarray=lib -O2 -gstabs
$
$ gfortran-11-20200510 -c z1.f90 -fcoarray=lib -O2 -gstabs
during RTL pass: final
z1.f90:6:0:

6 | end
  |
internal compiler error: Segmentation fault
0xbb93cf crash_signal
../../gcc/toplev.c:328
0xe0d447 tree_fits_shwi_p(tree_node const*)
../../gcc/tree.c:7262
0x815e82 dbxout_range_type
../../gcc/dbxout.c:1740
0x81556a dbxout_type
../../gcc/dbxout.c:2042
0x8141d4 dbxout_type
../../gcc/dbxout.c:2334
0x8161fe dbxout_symbol_location
../../gcc/dbxout.c:3246
0x816f00 dbxout_symbol(tree_node*, int)
../../gcc/dbxout.c:2972
0x817f2e dbxout_syms(tree_node*)
../../gcc/dbxout.c:3428
0x81808c dbxout_block
../../gcc/dbxout.c:3791
0x8182a3 dbxout_function_decl
../../gcc/dbxout.c:1388
0x8d9399 rest_of_handle_final
../../gcc/final.c:4694
0x8d9399 execute
../../gcc/final.c:4736

[Bug tree-optimization/95051] error: invalid RHS for gimple memory store:

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Yes, that's very similar.

[Bug c++/94775] [8/9/10/11 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48

[zhroma at gcc dot gnu.org]

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

--- Comment #15 from Roman Zhuykov  ---
(In reply to Marek Polacek from comment #14)
> Patch reverted from 10/11.
Maybe I've missed something in gcc-patches, but why it was reverted?  I can
imagine reasons to revert in 10 branch, but in master...

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
(In reply to Myron Walker from comment #20)
> So I will probably continue working on the python script or package that can
> do much of the enhanced processing.  One of the benefits of the python is I
> can process the code coverage data outside of a build environment altogether.

Can you please show me what the script does? I might be interested and for the
future I may add the options.
Right now, it's quite low on my TODO list..

[Bug c++/95066] [C++ 20] Incorrect successful compilation with a conditional explicit

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-05-11
   Keywords||accepts-invalid
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Thanks for the report.  In the first case we don't seem to ever substitute the
explicit-specifier.  I think we forget to lookup the explicit-specifier when
instantiating the out-of-line definition of operator Foo.

Since I've implemented explicit(bool), mine.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #5 from kargl at gcc dot gnu.org ---
*** Bug 95064 has been marked as a duplicate of this bug. ***

[Bug fortran/95064] [11 regression] ICEs in fortran compiler starting with r11-255

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
See PR 95053.

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

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-281-g2b2d298ff845ab7a07ffbd51da79473736da3324
Author: Uros Bizjak 
Date:   Mon May 11 20:12:14 2020 +0200

i386: Add V2SFmode sqrt insn pattern [PR95046]

gcc/ChangeLog:

2020-05-11  Uroš Bizjak  

PR target/95046
* config/i386/mmx.md (sqrtv2sf2): New insn pattern.

testsuite/ChangeLog:

2020-05-11  Uroš Bizjak  

PR target/95046
* gcc.target/i386/pr95046-1.c (test_sqrt): Add.

[Bug libstdc++/91383] C++17 should remove some library feature deprecated in C++14

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||gcc at linkmauve dot fr

--- Comment #6 from Marc Glisse  ---
*** Bug 95065 has been marked as a duplicate of this bug. ***

[Bug libstdc++/95065] Remove std::bind1st and std::bind2nd when building in -std=c++17

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
They are kept on purpose.

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

[Bug c++/95066] [C++ 20] Incorrect valid compilation with a conditional explicit

[ojman101 at protonmail dot com]

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

--- Comment #1 from Owen Smith  ---

#include 

template 
class IsSafelyCastable : public std::false_type {};

template <>
class IsSafelyCastable : public std::true_type {};

template 
struct Foo {
template 
explicit(!IsSafelyCastable::value) operator Foo() { return {}; }
};

int main() {
Foo a;
Foo b = a;
}


Inlining the definition yields the correct error with GCC 9.3.0:


main.cpp: In function 'int main()':
main.cpp:17:18: error: conversion from 'Foo' to non-scalar type
'Foo' requested
   17 | Foo b = a;
  | 

[Bug libbacktrace/95012] [mingw/gcc10.1] mmapio.c:69:14: error: implicit declaration of function ‘getpagesize’

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #5 from Ian Lance Taylor  ---
Thanks, should be fixed on master.

[Bug libbacktrace/95012] [mingw/gcc10.1] mmapio.c:69:14: error: implicit declaration of function ‘getpagesize’

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:47f4703c33c4936fd423c2a1180b2de144115d3d

commit r11-280-g47f4703c33c4936fd423c2a1180b2de144115d3d
Author: Ian Lance Taylor 
Date:   Mon May 11 10:51:21 2020 -0700

libbacktrace: declare getpagesize if necessary

libbacktrace/
PR libbacktrace/95012
* configure.ac: Check for getpagesize declaration.
* mmap.c: Declare getpagesize if necessary.
* mmapio.c: Likewise.

[Bug c++/95066] New: [C++ 20] Incorrect valid compilation with a conditional explicit

[ojman101 at protonmail dot com]

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

Bug ID: 95066
   Summary: [C++ 20] Incorrect valid compilation with a
conditional explicit
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ojman101 at protonmail dot com
  Target Milestone: ---

The code below is invalid C++, the line "Foo b = a;" should fail to
compile as implicitly casting is made illegal by the conditional explicit using
the "IsSafelyCastable" predicate.


#include 

template 
class IsSafelyCastable : public std::false_type {};

template <>
class IsSafelyCastable : public std::true_type {};

template 
struct Foo {
template 
explicit(!IsSafelyCastable::value) operator Foo();
};

template 
template 
Foo::operator Foo() {
  return {};
}

int main() {
Foo a;
Foo b = a;
}


Clang 10 correctly evaluates the explicit condition to be true and blocks the
implicit cast. However, GCC 9.3.0 successfully compiles without any errors. I
believe this to be a GCC bug as subtle changes can make GCC produce the correct
error. For example, moving the definition of the function to be inline with the
declaration.

[Bug fortran/95064] [11 regression] ICEs in fortran compiler starting with r11-255

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

   Host||powerpc64*-linux-gnu
 CC||anlauf at gcc dot gnu.org
  Build||powerpc64*-linux-gnu
 Target||powerpc64*-linux-gnu

--- Comment #1 from Bill Seurer  ---
spec 2000 test cases that now fail: 2x171.swim 2x191.fma3d 2x200.sixtrack



This also effects some of the spec 2006 test cases:  416.gamess 481.wrf

[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|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 48510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48510=edit
gcc11-pr95063.patch

Untested fix.

[Bug libstdc++/95065] New: Remove std::bind1st and std::bind2nd when building in -std=c++17

[gcc at linkmauve dot fr]

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

Bug ID: 95065
   Summary: Remove std::bind1st and std::bind2nd when building in
-std=c++17
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at linkmauve dot fr
  Target Milestone: ---

std::bind1st etc. got deprecated in C++11 and removed in C++17, but g++ still
happily compiles them in while clang++ correctly removed them, leading to a
build failure on the latter if the code didn’t get adapted.

I’m on gcc 10.1.0, but I believe previous versions of libstdc++ also had this
issue, so it would make sense to backport it to them once fixed.

[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

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase that is valid:

template 
struct S {
  T a:12;
  S () : a(0)
  {
#pragma omp for linear(a)
for (int k = 0; k < 64; ++k)
  a++;
  }
};

S s;

I guess this boils down to what type should the artificial
DECL_OMP_PRIVATIZED_MEMBER vars have for bit-fields, without it being a
template or without the bitfield type being a dependent type
omp_privatize_field would create the bitfield type, which is I think right, the
artificial var just stands for the COMPONENT_REF of this->bit_field (just will
have to check what exactly we do during expansion with that).

[Bug fortran/95064] New: [11 regression] ICEs in fortran compiler starting with r11-255

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95064
   Summary: [11 regression] ICEs in fortran compiler starting with
r11-255
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

Several of the spec 2000 test cases (specifically ) ICE when being built now. 
Errors are occurring in a couple of different places.

f951: internal compiler error: gfc_divide(): Bad basic type
0x102b464f gfc_report_diagnostic
/home/seurer/gcc/git/gcc-test/gcc/fortran/error.c:782
0x102b62bf gfc_internal_error(char const*, ...)
/home/seurer/gcc/git/gcc-test/gcc/fortran/error.c:1402
0x1026f357 gfc_divide(gfc_expr*, gfc_expr*)
/home/seurer/gcc/git/gcc-test/gcc/fortran/arith.c:1831
0x10301b07 match_add_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:394
0x10301e73 match_level_2
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:480
0x10302073 match_level_3
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:551
0x1030220f match_level_4
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:599
0x1030220f match_and_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:693
0x10302493 match_or_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:722
0x10302603 match_equiv_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:765
0x10302777 match_level_5
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:811
0x103014ff gfc_match_expr(gfc_expr**)
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:870
0x103356ab match_actual_arg
/home/seurer/gcc/git/gcc-test/gcc/fortran/primary.c:1662
0x1033753f gfc_match_actual_arglist(int, gfc_actual_arglist**, bool)
/home/seurer/gcc/git/gcc-test/gcc/fortran/primary.c:1927
0x1033a2db gfc_match_rvalue(gfc_expr**)
/home/seurer/gcc/git/gcc-test/gcc/fortran/primary.c:3611
0x1030173f match_primary
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:157
0x1030173f match_level_1
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:211
0x1030173f match_mult_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:267
0x10301a73 match_add_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:356
0x10301e73 match_level_2
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:480


And a different one:

0x102b464f gfc_report_diagnostic
/home/seurer/gcc/git/gcc-test/gcc/fortran/error.c:782
0x102b62bf gfc_internal_error(char const*, ...)
/home/seurer/gcc/git/gcc-test/gcc/fortran/error.c:1402
0x1026f357 gfc_divide(gfc_expr*, gfc_expr*)
/home/seurer/gcc/git/gcc-test/gcc/fortran/arith.c:1831
0x10301b07 match_add_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:394
0x10301e73 match_level_2
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:480
0x10302073 match_level_3
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:551
0x1030220f match_level_4
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:599
0x1030220f match_and_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:693
0x10302493 match_or_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:722
0x10302603 match_equiv_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:765
0x10302777 match_level_5
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:811
0x103014ff gfc_match_expr(gfc_expr**)
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:870
0x103356ab match_actual_arg
/home/seurer/gcc/git/gcc-test/gcc/fortran/primary.c:1662
0x1033753f gfc_match_actual_arglist(int, gfc_actual_arglist**, bool)
/home/seurer/gcc/git/gcc-test/gcc/fortran/primary.c:1927
0x1033a2db gfc_match_rvalue(gfc_expr**)
/home/seurer/gcc/git/gcc-test/gcc/fortran/primary.c:3611
0x1030173f match_primary
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:157
0x1030173f match_level_1
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:211
0x1030173f match_mult_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:267
0x10301a73 match_add_operand
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:356
0x10301e73 match_level_2
/home/seurer/gcc/git/gcc-test/gcc/fortran/matchexp.c:480


Author: Harald Anlauf 
Date:   Sun May 10 19:46:06 2020 +0200

PR fortran/93499 - ICE on division by zero in declaration statements

Division by zero in declaration statements could sometimes
generate NULL pointers being passed around that lead to ICEs.

2020-05-10  Harald Anlauf  

gcc/fortran/
PR fortran/93499
* arith.c (gfc_divide): Catch division by zero.

[Bug analyzer/95031] GCC 10 Analyzer and fatal error: Terminated signal terminated program cc1plus

[noloader at gmail dot com]

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

--- Comment #3 from Jeffrey Walton  ---
(In reply to David Malcolm from comment #2)
> Please note that C++ isn't supported in the -fanalyzer implementation in GCC
> 10.  I hope to get it working for GCC 11 (but there's a lot of work to do).

Oh, sorry about that. That explains a lot.

You might want to add that information to
https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10/. Maybe
even add an example of the unexpected beahvior when using C++. I started the
Analyzer testing after reading the blog.

[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

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Even shorter and simpler (no linebreak needed):

  SUBROUTINE MNSTIN ()
* Adding a comma before or after the "/" avoids the ICE
 132  FORMAT ('A'/'B')
  END

Running this under gdb and setting a breakpoint in gfc_divide,
it appears to really divide characters:

(gdb) p op1->ts.type
$3 = BT_CHARACTER
(gdb) p op2->ts.type
$4 = BT_CHARACTER

What's going on here?

Most likely there's something latent in parsing FORMAT().

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Confirmed, started with r11-15-gbcbf334afe091ad7d0f5ffe164299f8730cf41d1

[Bug c++/95020] requires expression always evaluates to true in the definition of template lambda defined within template function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Ever confirmed|0   |1
 Resolution|FIXED   |---

[Bug c++/95020] requires expression always evaluates to true in the definition of template lambda defined within template function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2020-5-11

--- Comment #1 from Patrick Palka  ---
Confirmed.  Looking into it.

[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

   Keywords||ice-on-invalid-code
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
It is not valid OpenMP, clang is incorrect to accept it.  Of course g++
shouldn't ICE.

[Bug c++/95063] New: [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

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

g++-11.0.0-alpha20200510 snapshot (g:13a46321516e2efd3bbb1f1899c539c6724240a9)
ICEs when compiling the following testcase, extracted from
test/OpenMP/for_ast_print.cpp from the clang 10.0.0 test suite, w/ -fopenmp:

struct S {
  S(): a(0) {}
  S(int v) : a(v) {}
  int a;
  typedef int type;
};

template 
class S7 : public T {
protected:
  T a;
  T 
  typename T::type c:12;
  typename T::type 

public:
  S7(typename T::type v) : a(v), b(a), c(v), d(a.a) {
#pragma omp for linear(val(c))
for (int k = 0; k < a.a; ++k)
  ++this->a.a;
  }
};

class S8 : public S7 {
public:
  S8(int v) : S7(v) {
  }
};

% g++-11.0.0 -fopenmp -c epvsqux2.cpp
epvsqux2.cpp: In constructor 'S7::S7(typename T::type)':
epvsqux2.cpp:18:28: error: modifier should not be specified in 'linear' clause
on 'simd' or 'for' constructs
   18 | #pragma omp for linear(val(c))
  |^
epvsqux2.cpp: In instantiation of 'S7::S7(typename T::type) [with T = S;
typename T::type = int]':
epvsqux2.cpp:26:22:   required from here
epvsqux2.cpp:18:31: internal compiler error: in tsubst_decl, at cp/pt.c:14633
   18 | #pragma omp for linear(val(c))
  |   ^
0x6607d0 tsubst_decl
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/pt.c:14633
0x9f6fa6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/pt.c:17938
0x9f4ea0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/pt.c:17836
0x9f51f7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/pt.c:18155
0x9f4ea0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/pt.c:17836
0x9f51f7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/pt.c:18155
0x9f22fa instantiate_decl(tree_node*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/pt.c:25708
0xa2335b instantiate_pending_templates(int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/pt.c:25824
0x9276e3 c_parse_final_cleanups()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200510/work/gcc-11-20200510/gcc/cp/decl2.c:4889

clang++ 10.0.0 accepts this code.

[Bug libgomp/95062] New: [10/11 Regression] libgomp.oacc-c-c++-common/pr92843-1.c:26: verify_array: Assertion `array[i] == value' failed

[tschwinge at gcc dot gnu.org]

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

Bug ID: 95062
   Summary: [10/11 Regression]
libgomp.oacc-c-c++-common/pr92843-1.c:26:
verify_array: Assertion `array[i] == value' failed
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

As made apparent by the 'dg-xfail-run-if' added, r279621 "OpenACC reference
count overhaul" regressed the 'libgomp.oacc-c-c++-common/pr92843-1.c' test
case:

pr92843-1.exe: [...]/libgomp.oacc-c-c++-common/pr92843-1.c:26:
verify_array: Assertion `array[i] == value' failed.

There are patches to cure this:

"Introduce dynamic data mapping sentinel for OpenACC",

[Bug analyzer/95031] GCC 10 Analyzer and fatal error: Terminated signal terminated program cc1plus

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Please note that C++ isn't supported in the -fanalyzer implementation in GCC
10.  I hope to get it working for GCC 11 (but there's a lot of work to do).

[Bug analyzer/95043] GCC 10 Analyzer and false positive on 'memcpy(dest, src, count);'

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Please note that C++ isn't supported in the GCC 10 implementation of -fanalyzer
(I hope to do so for GCC 11, but there's a lot of work to do).

In particular, I haven't implemented exceptions yet.

[Bug analyzer/95007] RFE: -fanalyzer should complain about writes to string literals

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
I guess I'm thinking about the case where a string literal has been exposed as
a non-const "char *": the RFE here is for -fanalyzer to be able to detect if we
ever write to such a string (with interprocedural analysis etc etc).

[Bug tree-optimization/95049] [9/10/11 Regression] GCC never terminates with trivial input program

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:84f4954c38228e4cb3e6f0b5471883e6c2523631

commit r11-277-g84f4954c38228e4cb3e6f0b5471883e6c2523631
Author: Richard Biener 
Date:   Mon May 11 13:40:37 2020 +0200

tree-optimization/95049 - fix not terminating RPO VN iteration

This rejects lattice changes from one constant to another.

2020-05-11  Richard Biener  

PR tree-optimization/95049
* tree-ssa-sccvn.c (set_ssa_val_to): Reject lattice transition
between different constants.

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

[Bug c++/95029] Compile error when using constant variable instead of literal

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Not a bug then.

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

[juergen.reuter at desy dot de]

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

--- Comment #3 from Jürgen Reuter  ---
Just as a quick cross check: the 10.1 release works without problems, so this
indeed must have been introduced in one of the earliest commits after the 10.1
was branched off.

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[seurer at linux dot vnet.ibm.com]

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

--- Comment #4 from Bill Seurer  ---
And for the power 7 specific one (the other one also occurs on power 7)

Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-pr69907.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-slp-details -O3 -S -o bb-slp-pr69907.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-pr69907.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-slp-details -O3 -S -o bb-slp-pr69907.s
PASS: gcc.dg/vect/bb-slp-pr69907.c -flto -ffat-lto-objects (test for excess
errors)
FAIL: gcc.dg/vect/bb-slp-pr69907.c -flto -ffat-lto-objects  scan-tree-dump slp1
"BB vectorization with gaps at the end of a load is not supported"

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[seurer at linux dot vnet.ibm.com]

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

--- Comment #5 from Bill Seurer  ---
Created attachment 48509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48509=edit
dump file p7 specific

[Bug go/95061] New: shared libgo library not found when running the testsuite

[doko at debian dot org]

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

Bug ID: 95061
   Summary: shared libgo library not found when running the
testsuite
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at debian dot org
CC: cmang at google dot com
  Target Milestone: ---

seen with a 10.1 build in the test log:

/tmp/TestDeathSignal940117740/a.out: error while loading shared libraries:
libgo.so.16: cannot open shared object file: No such file or directory
--- FAIL: TestLinuxDeathSignal (0.01s)
syscall_linux_test.go:222: did not receive start from child, received "",
EOF
--- FAIL: TestSyscallNoError (0.01s)
syscall_linux_test.go:367: failed to start first child process: exit status
127
FAIL
FAIL: syscall
make[7]: *** [Makefile:2875: syscall/check] Error 1

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[seurer at linux dot vnet.ibm.com]

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

--- Comment #3 from Bill Seurer  ---
Created attachment 48508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48508=edit
dump file

[Bug tree-optimization/95058] [11 regression] vector test case failures starting with r11-205

[seurer at linux dot vnet.ibm.com]

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

--- Comment #2 from Bill Seurer  ---
PASS: gcc.dg/vect/bb-slp-pr68892.c (test for excess errors)
XPASS: gcc.dg/vect/bb-slp-pr68892.c scan-tree-dump slp2 "not profitable"
PASS: gcc.dg/vect/bb-slp-pr68892.c scan-tree-dump-times slp2 "BB vectorization
with gaps at the end of a load is not supported" 1
gcc.dg/vect/bb-slp-pr68892.c: pattern found 0 times
FAIL: gcc.dg/vect/bb-slp-pr68892.c scan-tree-dump-times slp2 "Basic block will
be vectorized" 1
Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-pr68892.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-slp-details -fvect-cost-model=dynamic -S -o bb-slp-pr68892.s   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/bb-slp-pr68892.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-slp-details -fvect-cost-model=dynamic -S -o bb-slp-pr68892.s
PASS: gcc.dg/vect/bb-slp-pr68892.c -flto -ffat-lto-objects (test for excess
errors)
XPASS: gcc.dg/vect/bb-slp-pr68892.c -flto -ffat-lto-objects  scan-tree-dump
slp2 "not profitable"
PASS: gcc.dg/vect/bb-slp-pr68892.c -flto -ffat-lto-objects 
scan-tree-dump-times slp2 "BB vectorization with gaps at the end of a load is
not supported" 1
gcc.dg/vect/bb-slp-pr68892.c -flto -ffat-lto-objects : pattern found 0 times
FAIL: gcc.dg/vect/bb-slp-pr68892.c -flto -ffat-lto-objects 
scan-tree-dump-times slp2 "Basic block will be vectorized" 1

Output files from last compile command attached.

[Bug tree-optimization/95060] vfnmsub132ps is not generated with -ffast-math

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
Related to PR86999.

[Bug tree-optimization/95060] New: vfnmsub132ps is not generated with -ffast-math

[ubizjak at gmail dot com]

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

Bug ID: 95060
   Summary: vfnmsub132ps is not generated with -ffast-math
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
float r[8], a[8], b[8], c[8];

void
test_fnms (void)
{
  for (int i = 0; i < 8; i++)
r[i] = -(a[i] * b[i]) - c[i];
}
--cut here--

compiles on x86_64 with "-O3 -mfma" to

vmovaps b(%rip), %ymm0
vmovaps c(%rip), %ymm1
vfnmsub132psa(%rip), %ymm1, %ymm0
vmovaps %ymm0, r(%rip)
vzeroupper
ret

However, when -ffast-math is added, negation gets moved out of the insn:

vmovaps b(%rip), %ymm0
vmovaps c(%rip), %ymm1
vfmadd132ps a(%rip), %ymm1, %ymm0
->  vxorps  .LC0(%rip), %ymm0, %ymm0
vmovaps %ymm0, r(%rip)
vzeroupper
ret

[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 94988, which changed state.

Bug 94988 Summary: [11 Regression] FAIL: gcc.target/i386/pr64110.c 
scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988

   What|Removed |Added

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

[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[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 95025, which changed state.

Bug 95025 Summary: [11 Regression] ICE in execute_sm_exit at 
gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95025

   What|Removed |Added

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

[Bug regression/95025] [11 Regression] ICE in execute_sm_exit at gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug regression/95025] [11 Regression] ICE in execute_sm_exit at gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-272-gb6ff3ddecfa93d53867afaaa078f85fc848abbbd
Author: Richard Biener 
Date:   Fri May 8 12:03:30 2020 +0200

tree-optimization/94988 - enhance SM some more

This enhances store-order preserving store motion to handle the case
of non-invariant dependent stores in the sequence of unconditionally
executed stores on exit by re-issueing them as part of the sequence
of stores on the exit.  This fixes the observed regression of
gcc.target/i386/pr64110.c which relies on store-motion of 'b'
for a loop like

  for (int i = 0; i < j; ++i)
*b++ = x;

where for correctness we now no longer apply store-motion.  With
the patch we emit the correct

  tem = b;
  for (int i = 0; i < j; ++i)
{
  tem = tem + 1;
  *tem = x;
}
  b = tem;
  *tem = x;

preserving the original order of stores.  A testcase reflecting
the miscompilation done by earlier GCC is added as well.

This also fixes the reported ICE in PR95025 and adds checking code
to catch it earlier - the issue was not-supported refs propagation
leaving stray refs in the sequence.

2020-05-11  Richard Biener  

PR tree-optimization/94988
PR tree-optimization/95025
* tree-ssa-loop-im.c (seq_entry): Make a struct, add from.
(sm_seq_push_down): Take extra parameter denoting where we
moved the ref to.
(execute_sm_exit): Re-issue sm_other stores in the correct
order.
(sm_seq_valid_bb): When always executed, allow sm_other to
prevail inbetween sm_ord and record their stored value.
(hoist_memory_references): Adjust refs_not_supported propagation
and prune sm_other from the end of the ordered sequences.

* gcc.dg/torture/pr94988.c: New testcase.
* gcc.dg/torture/pr95025.c: Likewise.
* gcc.dg/torture/pr95045.c: Likewise.
* g++.dg/asan/pr95025.C: New testcase.

[Bug middle-end/94988] [11 Regression] FAIL: gcc.target/i386/pr64110.c scan-assembler vmovd[\\t ]

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-272-gb6ff3ddecfa93d53867afaaa078f85fc848abbbd
Author: Richard Biener 
Date:   Fri May 8 12:03:30 2020 +0200

tree-optimization/94988 - enhance SM some more

This enhances store-order preserving store motion to handle the case
of non-invariant dependent stores in the sequence of unconditionally
executed stores on exit by re-issueing them as part of the sequence
of stores on the exit.  This fixes the observed regression of
gcc.target/i386/pr64110.c which relies on store-motion of 'b'
for a loop like

  for (int i = 0; i < j; ++i)
*b++ = x;

where for correctness we now no longer apply store-motion.  With
the patch we emit the correct

  tem = b;
  for (int i = 0; i < j; ++i)
{
  tem = tem + 1;
  *tem = x;
}
  b = tem;
  *tem = x;

preserving the original order of stores.  A testcase reflecting
the miscompilation done by earlier GCC is added as well.

This also fixes the reported ICE in PR95025 and adds checking code
to catch it earlier - the issue was not-supported refs propagation
leaving stray refs in the sequence.

2020-05-11  Richard Biener  

PR tree-optimization/94988
PR tree-optimization/95025
* tree-ssa-loop-im.c (seq_entry): Make a struct, add from.
(sm_seq_push_down): Take extra parameter denoting where we
moved the ref to.
(execute_sm_exit): Re-issue sm_other stores in the correct
order.
(sm_seq_valid_bb): When always executed, allow sm_other to
prevail inbetween sm_ord and record their stored value.
(hoist_memory_references): Adjust refs_not_supported propagation
and prune sm_other from the end of the ordered sequences.

* gcc.dg/torture/pr94988.c: New testcase.
* gcc.dg/torture/pr95025.c: Likewise.
* gcc.dg/torture/pr95045.c: Likewise.
* g++.dg/asan/pr95025.C: New testcase.

[Bug target/95052] Excess padding of partially initialized strings/char arrays

[krzysztof.a.nowicki+gcc at gmail dot com]

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

--- Comment #5 from Krzysztof Nowicki  ---
(In reply to Martin Sebor from comment #4)
> I don't expect the commit above to have changed anything for the latter
> form, and I would expect each back end to choose the same optimal code to
> emit in both cases.  So I don't think the commit above is a regression; it
> just exposed an inefficiency that was already present.

Yes, from the implementation point of view I agree - the missed optimization
was there all the time and this commit exposed it in one more use case, where
it wasn't seen before. However from the point of view of an application
developer on an embedded system, who has developed it with some memory
constraints in mind, a sudden increase of memory usage, possibly causing an OOM
since the memory budget on this system is very tight (legacy platform), just by
upgrading the compiler is a regression.

[Bug gcov-profile/94928] Doc comments in gcov-io.h do not show cwd and unexec blocks in the Notes file format

[myron.walker at gmail dot com]

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

--- Comment #20 from Myron Walker  ---
So I will probably continue working on the python script or package that can do
much of the enhanced processing.  One of the benefits of the python is I can
process the code coverage data outside of a build environment altogether.

[Bug target/95052] Excess padding of partially initialized strings/char arrays

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Component|c   |target

--- Comment #4 from Martin Sebor  ---
The optimization in g:23aa9f7c4637ad51587e536e245ae6adb5391bbc should only
convert into a STRING_CST the initial portion of the braced initializer list up
to just past the last non-nul character.  The remaining nuls should be skipped.
 In other words, this

char buf[1*1024*1024] = { 0 };

should result in the same IL as this equivalent:

char buf[1*1024*1024] = "";

I don't expect the commit above to have changed anything for the latter form,
and I would expect each back end to choose the same optimal code to emit in
both cases.  So I don't think the commit above is a regression; it just exposed
an inefficiency that was already present.

[Bug fortran/94672] [10/11 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:892c7427ee234c04852e90d9ce32913a429adf9d

commit r11-271-g892c7427ee234c04852e90d9ce32913a429adf9d
Author: Tobias Burnus 
Date:   Mon May 11 16:39:20 2020 +0200

[Fortran] Fix/modify present() handling for assumed-shape optional (PR
94672)

gcc/fortran/
2020-05-07  Tobias Burnus  

PR fortran/94672
* trans.h (gfc_conv_expr_present): Add use_saved_decl=false
argument.
* trans-expr.c (gfc_conv_expr_present): Likewise; use DECL directly
and only if use_saved_decl is true, use the actual PARAM_DECL arg
(saved
descriptor).
* trans-array.c (gfc_trans_dummy_array_bias): Set local 'arg.0'
variable to NULL if 'arg' is not present.
* trans-openmp.c (gfc_omp_check_optional_argument): Simplify by
checking
'arg.0' instead of the true PARM_DECL.
(gfc_omp_finish_clause): Remove setting 'arg.0' to NULL.

gcc/testsuite/
2020-05-07  Jakub Jelinek  
Tobias Burnus  

PR fortran/94672
* gfortran.dg/gomp/pr94672.f90: New.
* gfortran.dg/missing_optional_dummy_6a.f90: Update scan-tree.

[Bug target/95046] Vectorize V2SFmode operations

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-270-gaa4317866bf3e9f42f3b8e3b1b1ec113ed1f818d
Author: Uros Bizjak 
Date:   Mon May 11 16:37:19 2020 +0200

i386: Improve basic vectorized V2SFmode operations [PR95046]

Use plain "v" constraint for AVX alternatives and add "prefix" attribute.

gcc/ChangeLog:

PR target/95046
* config/i386/mmx.md (mmx_addv2sf3): Use "v" constraint
instead of "Yv" for AVX alternatives.  Add "prefix" attribute.
(*mmx_addv2sf3): Ditto.
(*mmx_subv2sf3): Ditto.
(*mmx_mulv2sf3): Ditto.
(*mmx_v2sf3): Ditto.
(mmx_ieee_v2sf3): Ditto.

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||eggert at cs dot ucla.edu

--- Comment #8 from Martin Sebor  ---
*** Bug 95044 has been marked as a duplicate of this bug. ***

[Bug other/90556] [meta-bug] bogus/missing -Wreturn-local-addr

[msebor at gcc dot gnu.org]

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

Bug 95044 Summary: [10/11 Regression] -Wreturn-local-addr false alarm since 
r10-1741-gaac9480da1ffd037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95044

   What|Removed |Added

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

[Bug c/95044] [10/11 Regression] -Wreturn-local-addr false alarm since r10-1741-gaac9480da1ffd037

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
This looks like a duplicate of pr93644, including the test case involving the
careadlinkat function.

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

[Bug target/94991] aarch64: ICE: Segmentation fault with option -mgeneral-regs-only

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:248e357f6941fe9409658386dc9b86b75dfd96c6

commit r11-269-g248e357f6941fe9409658386dc9b86b75dfd96c6
Author: Fei Yang 
Date:   Mon May 11 15:18:47 2020 +0100

aarch64: Fix ICE when expanding scalar floating move with
-mgeneral-regs-only. [PR94991]

In the testcase for PR94991, we are doing FAIL for scalar floating move
expand
pattern since TARGET_FLOAT is false with option -mgeneral-regs-only. But
move
expand pattern cannot fail. It would be better to replace the FAIL with
code
that bitcasts to the equivalent integer mode using gen_lowpart.

2020-05-11  Felix Yang  

gcc/
PR target/94991
* config/aarch64/aarch64.md (mov):
Bitcasts to the equivalent integer mode using gen_lowpart
instead of doing FAIL for scalar floating point move.

gcc/testsuite/
PR target/94991
* gcc.target/aarch64/mgeneral-regs_5.c: New test.

[Bug c/95002] VLA: 'var = sizeof array' gives spurous '= array, ' instead of just '= '

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Or deal with that during gimplification.

[Bug fortran/59107] [8/9/10/11 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #23 from markeggleston at gcc dot gnu.org ---
Commits to master and backported to gcc-10, gcc-9 and gcc-8.