[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Thomas Kथà¤nig
:

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

commit r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
Author: Thomas König 
Date:   Fri Apr 24 08:22:48 2020 +0200

Fix PR 93956, wrong pointer when returned via function.

Backport from trunk.

This one took a bit of detective work.  When array pointers point
to components of derived types, we currently set the span field
and then create an array temporary when we pass the array
pointer to a procedure as a non-pointer or non-target argument.
(This is inefficient, but that's for another release).

Now, the compiler detected this case when there was a direct assignment
like p => a%b, but not when p was returned either as a function result
or via an argument.  This patch fixes that.

2020-04-24  Thomas Koenig  

PR fortran/93956
* expr.c (gfc_check_pointer_assign): Also set subref_array_pointer
when a function returns a pointer.
* interface.c (gfc_set_subref_array_pointer_arg): New function.
(gfc_procedure_use): Call it.

2020-04-24  Thomas Koenig  

PR fortran/93956
* gfortran.dg/pointer_assign_13.f90: New test.

[Bug fortran/90350] ubound ICE on assumed size array even though explicit bound is specified

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
Fixen on trunk, closing.

Thanks for the bug report!

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Jeffrey A. Law from comment #6)
> THe whole point of that change is to not require a dominating load if the
> object comes from the stack.

Yeah, but I find that flawed.  One can do it after performing
get_ref_base_and_extent and verifying the offset is const and the whole access
must be within the object, or one could do it with VR verification again
verifying the access is fully within the object, but otherwise it can't be done
and one needs to find dominating load, just the noload needs to handle also
ARRAY_REFs etc., not only MEM_REFs.

[Bug target/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
Reduced test case:



struct __attribute__((scalar_storage_order("big-endian"))) {
  int a;
  int b[];
} c;
int d;
int e() { d = c.b[0]; }

[Bug target/94740] New: ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

[acsawdey at gcc dot gnu.org]

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

Bug ID: 94740
   Summary: ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future
-mpcrel -O1
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---

Compiler is trunk 3bcdb5dec72b6d7b197821c2b814bc9fc07f4628 on ppc64le power9
host.

~/work/gcc/trunk/build/gcc/xgcc -B/home2/sawdey/work/gcc/trunk/build/gcc
/home2/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.dg/sso/t5.c -mcpu=future
-mpcrel -O1 -lm -o ./t5.exe
during RTL pass: reload
/home2/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.dg/sso/t5.c: In function
‘main’:
/home2/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.dg/sso/t5.c:73:1: internal
compiler error: in set_address_disp, at rtlanal.c:6254
   73 | }
  | ^
0x10a50ca3 set_address_disp
../../gcc/gcc/rtlanal.c:6254
0x10a50ca3 set_address_disp
../../gcc/gcc/rtlanal.c:6252
0x10a50ca3 decompose_automod_address
../../gcc/gcc/rtlanal.c:6297
0x10a50ca3 decompose_address(address_info*, rtx_def**, machine_mode, unsigned
char, rtx_code)
../../gcc/gcc/rtlanal.c:6457
0x10887973 process_address_1
../../gcc/gcc/lra-constraints.c:3367
0x10889b9b process_address
../../gcc/gcc/lra-constraints.c:3641
0x10889b9b curr_insn_transform
../../gcc/gcc/lra-constraints.c:3956
0x1088f95f lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:5029
0x1087119f lra(_IO_FILE*)
../../gcc/gcc/lra.c:2440
0x10810b9b do_reload
../../gcc/gcc/ira.c:5523
0x10810b9b execute
../../gcc/gcc/ira.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/94739] New: GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

Bug ID: 94739
   Summary: GCC won't build on CET enabled Linux OS
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-tgl-1 build-x86_64-linux]$ readelf -n /bin/ld 2>&1|more

Displaying notes found in: .note.gnu.property
  OwnerData sizeDescription
  GNU  0x0030   NT_GNU_PROPERTY_TYPE_0
  Properties: x86 feature: IBT, SHSTK
x86 ISA used: CMOV, SSE, SSE2
x86 feature used: x86, XMM

and I got

build-x86_64-linux/./gcc/liblto_plugin.so: indirect branch tracking isn't
enabled: Invalid argument
collect2: error: ld returned 1 exit status
make[7]: *** [Makefile:994: libgcc_s.so] Error 1

Since ld is CET enabled, dlopen failed on liblto_plugin.so since it isn't CET
enabled.  On CET enabled Linux OS, we need to always enable CET on
liblto_plugin.so.

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
THe whole point of that change is to not require a dominating load if the
object comes from the stack.

We conditionally load from the same location, then have a PHI which selects
that loaded value or "1" and we store the result.  That's precisely what is
supposed to be happening.

The loop in question looks like:

;;   basic block 3, loop depth 1
;;pred:   2
;;6
  # ivtmp.13_9 = PHI <0(2), ivtmp.13_7(6)>
  _4 = MEM[base: in_21(D), index: ivtmp.13_9, step: 8, offset: 0B];
  if (_4 == 0B)
goto ; [5.50%]
  else
goto ; [94.50%]
;;succ:   13
;;4

;;   basic block 4, loop depth 1
;;pred:   3
  if (ivtmp.13_9 != 2)
goto ; [28.10%]
  else
goto ; [71.90%]
;;succ:   6
;;5

;;   basic block 5, loop depth 1
;;pred:   4
  cstore_32 = MEM[symbol: arr, index: ivtmp.13_9, step: 4, offset: 0B];
;;succ:   6

;;   basic block 6, loop depth 1
;;pred:   5
;;4
  # cstore_31 = PHI 
  MEM[symbol: arr, index: ivtmp.13_9, step: 4, offset: 0B] = cstore_31;
  _40 = (unsigned int) ivtmp.13_9;
  _38 = _40 + 1;
  _37 = (int) _38;
  ivtmp.13_7 = ivtmp.13_9 + 1;
  sum_a_27 = (int) ivtmp.13_7;
  if (n_16(D) > sum_a_27)
goto ; [94.50%]
  else
goto ; [5.50%]
;;succ:   3
;;7

You can see the load from the same stock slot in bb5, the selecting PHI in bb6
and the store in bb6.

THe test in bb4 looks weird and is the source of the problem I believe.

[Bug libstdc++/91807] [9/10 Regression] std::variant with multiple identical types assignment fail to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/92156] Cannot in-place construct std::any with std::any

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |10.0
 Status|NEW |RESOLVED

--- Comment #5 from Jonathan Wakely  ---
Fixed for GCC 10.

[Bug libstdc++/90415] [9 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[9/10 Regression]   |[9 Regression]
   |std::is_copy_constructible< |std::is_copy_constructible<
   |std::tuple> is|std::tuple> is
   |incomplete  |incomplete

--- Comment #14 from Jonathan Wakely  ---
Fixed on master so far, backport to follow soon.

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7935-gd1462b0782555354b4480e1f46498586d5882972
Author: Jonathan Wakely 
Date:   Fri Apr 24 00:54:20 2020 +0100

libstdc++: Fix constructor constraints for std::any  (PR 90415)

This removes a non-standard extension to std::any which causes errors
for valid code, due to recursive instantiation of a trait that isn't
supposed to be in the constraints.

It also removes some incorrect constraints on the in_place_type
constructors and emplace members, which were preventing creating a
std::any object with another std::any as the contained value.

2020-04-24  Kamlesh Kumar  
Jonathan Wakely  

PR libstdc++/90415
PR libstdc++/92156
* include/std/any (any): Rename template parameters for consistency
with the standard.
(any::_Decay): Rename to _Decay_if_not_any.
(any::any(T&&):: Remove is_constructible from constraints. Remove
non-standard overload.
(any::any(in_place_type_t, Args&&...))
(any::any(in_place_type_t, initializer_list, Args&&...))
(any::emplace(Args&&...))
(any::emplace(initializer_list, Args&&...)):
Use decay_t instead of _Decay.
* testsuite/20_util/any/cons/90415.cc: New test.
* testsuite/20_util/any/cons/92156.cc: New Test.
* testsuite/20_util/any/misc/any_cast_neg.cc: Make dg-error
directives
more robust.
* testsuite/20_util/any/modifiers/92156.cc: New test.

[Bug libstdc++/92156] Cannot in-place construct std::any with std::any

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7935-gd1462b0782555354b4480e1f46498586d5882972
Author: Jonathan Wakely 
Date:   Fri Apr 24 00:54:20 2020 +0100

libstdc++: Fix constructor constraints for std::any  (PR 90415)

This removes a non-standard extension to std::any which causes errors
for valid code, due to recursive instantiation of a trait that isn't
supposed to be in the constraints.

It also removes some incorrect constraints on the in_place_type
constructors and emplace members, which were preventing creating a
std::any object with another std::any as the contained value.

2020-04-24  Kamlesh Kumar  
Jonathan Wakely  

PR libstdc++/90415
PR libstdc++/92156
* include/std/any (any): Rename template parameters for consistency
with the standard.
(any::_Decay): Rename to _Decay_if_not_any.
(any::any(T&&):: Remove is_constructible from constraints. Remove
non-standard overload.
(any::any(in_place_type_t, Args&&...))
(any::any(in_place_type_t, initializer_list, Args&&...))
(any::emplace(Args&&...))
(any::emplace(initializer_list, Args&&...)):
Use decay_t instead of _Decay.
* testsuite/20_util/any/cons/90415.cc: New test.
* testsuite/20_util/any/cons/92156.cc: New Test.
* testsuite/20_util/any/misc/any_cast_neg.cc: Make dg-error
directives
more robust.
* testsuite/20_util/any/modifiers/92156.cc: New test.

[Bug driver/90983] [9 Regression] manual documents `-Wno-stack-usage` flag, but it is unrecognized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|10.0|
   Target Milestone|--- |9.5
Summary|[9/10 Regression] manual|[9 Regression] manual
   |documents   |documents
   |`-Wno-stack-usage` flag,|`-Wno-stack-usage` flag,
   |but it is unrecognized  |but it is unrecognized

--- Comment #10 from Martin Sebor  ---
Fixed for GCC 10.

[Bug driver/90983] [9/10 Regression] manual documents `-Wno-stack-usage` flag, but it is unrecognized

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7934-gae962e573ea5063fda7e86f93d9622e64cea9a7e
Author: Martin Sebor 
Date:   Thu Apr 23 17:49:01 2020 -0600

PR driver/90983 - manual documents `-Wno-stack-usage` flag but it is
unrecognized

gcc/ChangeLog:

PR driver/90983
* common.opt (-Wno-frame-larger-than): New option.
(-Wno-larger-than, -Wno-stack-usage): Same.

gcc/testsuite/ChangeLog:

PR driver/90983
* gcc.dg/Wframe-larger-than-3.c: New test.
* gcc.dg/Wlarger-than4.c: New test.
* gcc.dg/Wstack-usage.c: New test.

[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257

[rafael at espindo dot la]

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

--- Comment #13 from Rafael Avila de Espindola  ---
Thank you so much. I can confirm that scylla now builds with gcc master with
just a few fixes on the scylla side (we build with -Werror).

There is a couple of test failures. I will try to reduce those and open new
bugs as appropriate.

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
All the PR89430 testcases have such a load.

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
+  int cstore_31;
+  int cstore_32;

[local count: 114863530]:
   goto ; [100.00%]

[local count: 1014686026]:
   _1 = (long unsigned int) sum_a_7;
   _2 = _1 * 8;
   _3 = input_21(D) + _2;
   _4 = *_3;
   if (_4 == 0B)
 goto ; [5.50%]
   else
 goto ; [94.50%]

[local count: 958878296]:
   if (sum_a_7 <= 1)
-goto ; [28.10%]
+goto ; [28.10%]
   else
-goto ; [71.90%]
+goto ; [71.90%]

-   [local count: 269444804]:
-  arr[sum_a_7] = 1;
+   [local count: 689433492]:
+  cstore_32 = MEM  [(void *)&arr][sum_a_7];

[local count: 958878296]:
+  # cstore_31 = PHI <1(4), cstore_32(5)>
+  MEM  [(void *)&arr][sum_a_7] = cstore_31;
   sum_a_23 = sum_a_7 + 1;

done by cselim looks just plain wrong, there is no dominating load from that
memory, so even when the variable is an automatic variable, there is no
guarantee it won't be out of bounds and thus crash already on the load, or just
modify random unrelated memory.

[Bug fortran/94737] BIND(C) names are not always treated as case sensitive. Versions < 8 are ok.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Last reconfirmed||2020-04-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||10.0, 8.1.0

--- Comment #1 from kargl at gcc dot gnu.org ---
This also fails with trunk as svn revision 280157.  The following trivial patch
allows your code to compile.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
@@ -2517,8 +2517,14 @@ resolve_global_procedure (gfc_symbol *sym, locus *wher
   gsym = gfc_get_gsymbol (sym->binding_label ? sym->binding_label : sym->name,
  sym->binding_label != NULL);

-  if ((gsym->type != GSYM_UNKNOWN && gsym->type != type))
-gfc_global_used (gsym, where);
+  if (gsym->type != GSYM_UNKNOWN && gsym->type != type)
+{
+  if (sym->binding_label && gsym->binding_label
+ && strcmp (sym->binding_label, gsym->binding_label) != 0)
+   ;
+  else
+   gfc_global_used (gsym, where);
+}

   if ((sym->attr.if_source == IFSRC_UNKNOWN
|| sym->attr.if_source == IFSRC_IFBODY)




Passing the created *.mod file through gunzip shows

3 'func1' 'foo' 'c_func' 1 ((PROCEDURE UNKNOWN-INTENT EXTERNAL-PROC BODY
UNKNOWN 0 0 EXTERNAL FUNCTION IS_BIND_C IS_C_INTEROP
ARRAY_OUTER_DEPENDENCY) () (INTEGER 4 0 1 0 INTEGER ()) 4 0 (5) () 6 ()
() () 0 0)

11 'sub1' 'foo' 'c_Func' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC BODY
UNKNOWN 0 0 EXTERNAL SUBROUTINE IS_BIND_C IS_C_INTEROP
ARRAY_OUTER_DEPENDENCY) () (UNKNOWN 0 0 1 0 UNKNOWN ()) 12 0 (13 14) ()

so I suspect it works.  Probably, need to expand the test to skip the
error path to do comparisons involving sym->name and gsym->name.  Just
details for someone else to consider.

[Bug libstdc++/91630] std::any SFINAE breaks valid code since 9.1

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Indeed. Thanks, Daniel.

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

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||alabuzhev at gmail dot com

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

[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7932-gf9f166251f181ddcee64092d89aecbc1166ca706
Author: Patrick Palka 
Date:   Thu Apr 23 17:29:55 2020 -0400

c++: Lambda in friend of constrained class [PR94645]

In the testcase below, when grokfndecl processes the operator() decl for
the
lambda inside the friend function foo, processing_template_decl is rightly
1,
but template_class_depth on the lambda's closure type incorrectly returns 0
instead of 1.

Since processing_template_decl > template_class_depth, this makes
grokfndecl
think that the operator() has its own set of template arguments, and so we
attach the innermost set of constraints -- those belonging to struct l --
to the
operator() decl.  We then get confused when checking
constraints_satisfied_p on
the operator() because it doesn't have template information and yet has
constraints associated with it.

This patch fixes template_class_depth to return the correct template
nesting
level in cases like these, in that when it hits a friend function it walks
into
the DECL_FRIEND_CONTEXT of the friend rather than into the CP_DECL_CONTEXT.

gcc/cp/ChangeLog:

PR c++/94645
* pt.c (template_class_depth): Walk into the DECL_FRIEND_CONTEXT of
a
friend declaration rather than into its CP_DECL_CONTEXT.

gcc/testsuite/ChangeLog:

PR c++/94645
* g++.dg/cpp2a/concepts-lambda6.C: New test.

[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #12 from Patrick Palka  ---
Fixed.

[Bug fortran/94738] New: C descriptor passed to Fortran from C apepars to have wrong type information.

[longb at cray dot com]

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

Bug ID: 94738
   Summary: C descriptor passed to Fortran from C apepars to have
wrong type information.
   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 main.c
#include 
#include 
#include "ISO_Fortran_binding.h"

int main (int argc, char *argv[]) {

int ret;
int line;
int my_errno;
int i;
CFI_CDESC_T(1) cdesc;
CFI_rank_t rank = 1;
int version = CFI_VERSION;
CFI_attribute_t attribute = CFI_attribute_allocatable;
CFI_type_t typ = CFI_type_double;
CFI_index_t extents[rank];
CFI_index_t lower_bounds[rank];
CFI_index_t upper_bounds[rank];
size_t elem_len; // value doesn't matter
void sub (CFI_cdesc_t *);

for (i = 0; i < rank; i++) {
extents[i] = 100;
lower_bounds[i] = 1;
upper_bounds[i] = 100;
}
ret = CFI_establish ((CFI_cdesc_t *)&cdesc, 0, attribute, typ, elem_len, rank,
extents);
if (ret != CFI_SUCCESS) {
   line = __LINE__;
   goto done;
} 
ret = CFI_allocate ((CFI_cdesc_t *)&cdesc, lower_bounds, upper_bounds,
elem_len);
 if (ret != CFI_SUCCESS) {
line = __LINE__;
goto done;
 }
 sub ((CFI_cdesc_t *) &cdesc);
 line = 0;

done:

 if (line != 0) {
asm ("hlt");
 }
 return 0;
}

> cat sub.f90
subroutine sub (a) bind (c)
  use,intrinsic :: iso_c_binding
  real(C_double), allocatable :: a(:)
  do i = 1, size(a, 1)
 a(i) = i
  end do
  print *, a
end subroutine sub
> 
> ftn -c sub.f90
> cc main.c sub.o
> ./a.out
At line 7 of file sub.f90 (unit = 6, file = 'stdout')
Internal Error: list_formatted_write(): Bad type


It appears that the C descriptor, after being converted to a Fortran
descriptor, has the wrong type information encoded.

> cc --version
gcc (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.

> ftn --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.

Output from other compilers:

> module swap PrgEnv-gnu PrgEnv-cray
> ftn -c sub.f90
> cc main.c sub.o
>  ./a.out
 1.,  2.,  3.,  4.,  5.,  6.,  7.,  8.,  9.,  10.,  11.,  12.,  13.,  14., 
15.,  16.,  17.,  18.,  19.,  20.,  21.,  22.,  23.,  24.,  25.,  26.,  27., 
28.,  29.,  30.,  31.,  32.,  33.,  34.,  35.,  36.,  37.,  38.,  39.,  40., 
41.,  42.,  43.,  44.,  45.,  46.,  47.,  48.,  49.,  50.,  51.,  52.,  53., 
54.,  55.,  56.,  57.,  58.,  59.,  60.,  61.,  62.,  63.,  64.,  65.,  66., 
67.,  68.,  69.,  70.,  71.,  72.,  73.,  74.,  75.,  76.,  77.,  78.,  79., 
80.,  81.,  82.,  83.,  84.,  85.,  86.,  87.,  88.,  89.,  90.,  91.,  92., 
93.,  94.,  95.,  96.,  97.,  98.,  99.,  100.
> module swap PrgEnv-cray PrgEnv-intel
> ftn -c sub.f90
> cc main.c sub.o
> ./a.out
   1.002.003.00 
   4.005.006.00 
   7.008.009.00 
   10.011.012.0 
   13.014.015.0 
   16.017.018.0 
   19.020.021.0 
   22.023.024.0 
   25.026.027.0 
   28.029.030.0 
   31.032.033.0 
   34.035.036.0 
   37.038.039.0 
   40.041.042.0 
   43.044.045.0 
   46.047.048.0 
   49.050.051.0 
   52.053.054.0 
   55.056.057.0 
   58.059.060.0 
   61.062.063.0 
   64.065.066.0 
   67.068.0 

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Looks like we're running past the end of the array with the stores in the loop.

[Bug fortran/94737] New: BIND(C) names are not always treated as case sensitive. Versions < 8 are ok.

[busby1 at llnl dot gov]

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

Bug ID: 94737
   Summary: BIND(C) names are not always treated as case
sensitive.  Versions < 8 are ok.
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: busby1 at llnl dot gov
  Target Milestone: ---

Created attachment 48365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48365&action=edit
A fortran module.  Compilation instructions (Linux) and output are in it

I will attach a small reproducer for the problem.  There is an obvious
workaround in this case, to use a C name that is unique even if case
sensitivity is disregarded.  I do not have easy access to gfortran version 9 or
10, sorry I cannot report on those.

Thank you,
Lee Busby

[Bug target/94630] General bug for changes needed to switch the PowerPC long double default

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  ---
Created attachment 48364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48364&action=edit
Propsed patch to build ibm-ldouble.c with -mno-gnu-attributes

ibm-ldouble.c in libgcc must be compiled without GNU attributes, so that the
__ibm128 functions can be called if long double is IEEE 128-bit.

[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
.

[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r10-7926-gcb76fcd7fb4a4f1e4d1688deca87969124f16fef
Author: Eric Botcazou 
Date:   Thu Apr 23 22:25:04 2020 +0200

Fix segfault with -O2 -fnon-call-exceptions -ftracer

The GIMPLE SSA store merging pass blows up when it is rewriting the
stores because it didn't realize that they don't belong to the same
EH region.  Fixed by refusing to merge them.

PR tree-optimization/94717
* gimple-ssa-store-merging.c (try_coalesce_bswap): Return false if
one of the stores doesn't have the same landing pad number as the
first.
(coalesce_immediate_stores): Do not try to coalesce the store using
bswap if it doesn't have the same landing pad number as the first.

[Bug libstdc++/94702] std::unsequenced_policy should not be defined for C++17

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:9d13ebadf78821fe5a239600460a81c10def10cc

commit r9-8536-g9d13ebadf78821fe5a239600460a81c10def10cc
Author: Jonathan Wakely 
Date:   Thu Apr 23 18:48:50 2020 +0100

libstdc++: Define __cpp_lib_execution feature test

This macro has never been defined by libstdc++, despite supporting the
parallel algorithms. It should have a different value for C++17 and
C++20, because P1001R2 should not be supported in C++17, but
unsequenced_policy is defined for C++17 (see PR 94702).

Backport from mainline
2020-04-22  Jonathan Wakely  

* include/std/execution (__cpp_lib_execution): Define to indicate
support for P0024R2 and P1001R2.
* include/std/version (__cpp_lib_execution): Define.
* testsuite/25_algorithms/pstl/feature_test.cc: Only test macro
defined by , move other tests to new tests ...
* testsuite/25_algorithms/pstl/feature_test-2.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-3.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-4.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-5.cc: New test.

[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7924-gf51be2fb8653f81092f8158a0f0527275f86603b
Author: Jakub Jelinek 
Date:   Thu Apr 23 21:57:50 2020 +0200

Shortcut identity VEC_PERM expansion [PR94710]

This PR is about the rs6000 backend emitting wrong assembly
for whole vector shift by 0, and while I think it is desirable
to fix the backend, I don't see a point why the expander should
try to emit that, whole vector shift by 0 is identity, we can just
return the operand.

2020-04-23  Jakub Jelinek  

PR target/94710
* optabs.c (expand_vec_perm_const): For shift_amt const0_rtx
just return v2.

[Bug c++/94288] co_await in while loop crashes g++

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7923-g3dbc772128e944819b09e21021d4fcd5dc17f2d4
Author: Iain Sandoe 
Date:   Thu Apr 23 16:59:00 2020 +0100

coroutines: Fix handling of conditional statements [PR94288]

Normally, when we find a statement containing an await expression
this will be expanded to a statement list implementing the control
flow implied.  The expansion process successively replaces each
await expression in a statement with the result of its await_resume().

In the case of conditional statements (if, while, do, switch) the
expansion of the condition (or expression in the case of do-while)
cannot take place 'inline', leading to the PR.

The solution is to evaluate the expression separately, and to
transform while and do-while loops into endless loops with a break
on the required condition.

In fixing this, I realised that I'd also made a thinko in the case
of expanding truth-and/or-if expressions, where one arm of the
expression might need to be short-circuited.  The mechanism for
expanding via the tree walk will not work correctly in this case and
we need to pre-expand any truth-and/or-if with an await expression
on its conditionally-taken arm.  This applies to any statement with
truth-and/or-if expressions, so can be handled generically.

gcc/cp/ChangeLog:

2020-04-23  Iain Sandoe  

PR c++/94288
* coroutines.cc (await_statement_expander): Simplify cases.
(struct susp_frame_data): Add fields for truth and/or if
cases, rename one field.
(analyze_expression_awaits): New.
(expand_one_truth_if): New.
(add_var_to_bind): New helper.
(coro_build_add_if_not_cond_break): New helper.
(await_statement_walker): Handle conditional expressions,
handle expansion of truth-and/or-if cases.
(bind_expr_find_in_subtree): New, checking-only.
(coro_body_contains_bind_expr_p): New, checking-only.
(morph_fn_to_coro): Ensure that we have a top level bind
expression.

gcc/testsuite/ChangeLog:

2020-04-23  Iain Sandoe  

PR c++/94288
* g++.dg/coroutines/torture/co-await-18-if-cond.C: New test.
* g++.dg/coroutines/torture/co-await-19-while-cond.C: New test.
* g++.dg/coroutines/torture/co-await-20-do-while-cond.C: New test.
* g++.dg/coroutines/torture/co-await-21-switch-value.C: New test.
* g++.dg/coroutines/torture/co-await-22-truth-and-of-if.C: New
test.
* g++.dg/coroutines/torture/co-ret-16-simple-control-flow.C: New
test.

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[meissner at gcc dot gnu.org]

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

--- Comment #31 from Michael Meissner  ---
For the Spec 2017 521.wrf_r benchmark on little endian PowerPC power9 systems,
there was no difference in runtime between a normal run using -Ofast
-mcpu=power9 and one with -Ofast -mcpu=power9 -fno-inline-arg-packing.

Of the seven rate benchmarks in Spec 2017 that use Fortran (548.exchange2_r,
503.bwaves_r, 507.cactuBSSN_r, 521.wrf_r, 527.cam4_r, 549.fotonik3d_r, and
554.roms_r) none of them vary by more tha 0.7% depending on whether the switch
is used or not.

I used the compiler checked out from the master branch on March 27, 2020 to
build and run the benchmarks.

As others have said, using -fno-inline-arg-packing does dramatically reduce the
time it takes to compile 521.wrf_r.

[Bug c++/90448] [8/9 Regression] decltype-based lambda parameter pack is rejected

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
I see the same ICE on 32-bit sparc-sun-solaris2.11.

[Bug c++/94733] [10 Regression] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c++/94733] [10 Regression] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:7291b2edf6f87fba839b0d10c04b2562a5f6bd60

commit r10-7922-g7291b2edf6f87fba839b0d10c04b2562a5f6bd60
Author: Marek Polacek 
Date:   Thu Apr 23 14:38:58 2020 -0400

c-family: Fix ICE on attribute with -fgnu-tm [PR94733]

find_tm_attribute was using TREE_PURPOSE to get the attribute name,
which is breaking now that we preserve the C++11-style attribute
format past decl_attributes.  So use get_attribute_name which can
handle both formats of attributes.

PR c++/94733
* c-attribs.c (find_tm_attribute): Use get_attribute_name instead
of
TREE_PURPOSE.

* g++.dg/tm/attrib-5.C: New test.

[Bug middle-end/94724] [10 Regression] wrong code at -O0 on x86_64-linux-gnu since r10-7344-gca6c722561ce9b9d

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jakub at redhat dot com|
 Resolution|--- |FIXED

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

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.0
 CC||liujiangning at gcc dot 
gnu.org,
   ||marxin at gcc dot gnu.org
Summary|Program crashes when|[10 Regression] Program
   |compiled with GCC 10|crashes when compiled with
   ||-O2 since
   ||r10-1892-gb9ef6a2e04bfd013
  Known to work||9.3.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.0
   Last reconfirmed||2020-04-23
 Ever confirmed|0   |1
   Priority|P3  |P1
   Keywords||wrong-code
  Component|c   |tree-optimization

--- Comment #2 from Martin Liška  ---
Confirmed, ASAN is also fine. Started with r10-1892-gb9ef6a2e04bfd013.

[Bug middle-end/94724] [10 Regression] wrong code at -O0 on x86_64-linux-gnu since r10-7344-gca6c722561ce9b9d

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7921-gbca558de2a24b2a78c6a321d6cec384e07759d77
Author: Jakub Jelinek 
Date:   Thu Apr 23 21:11:36 2020 +0200

tree: Fix up get_narrower [PR94724]

In the recent get_narrower change, I wanted it to be efficient and avoid
recursion if there are many nested COMPOUND_EXPRs.  That builds the
COMPOUND_EXPR nest with the right arguments, but as build2_loc computes
some
flags like TREE_SIDE_EFFECTS, TREE_CONSTANT and TREE_READONLY, when it
is called with something that will not be the argument in the end, those
flags are computed incorrectly.
So, this patch instead uses an auto_vec and builds them in the reverse
order
so when they are built, they are built with the correct operands.

2020-04-23  Jakub Jelinek  

PR middle-end/94724
* tree.c (get_narrower): Instead of creating COMPOUND_EXPRs
temporarily with non-final second operand and updating it later,
push COMPOUND_EXPRs into a vector and process it in reverse,
creating COMPOUND_EXPRs with the final operands.

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

[Bug target/94736] New: Missing ENDBR at label

[hjl.tools at gmail dot com]

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

Bug ID: 94736
   Summary: Missing ENDBR at label
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-cfl-2 gcc]$ cat /tmp/foo.c
#include 

typedef void *(*func_t) (void);

void *p;

void
__attribute__ ((noclone, noinline))
foo (int a)
{
  switch (a)
{
case 0:
a0:
  return;
case 1:
a1:
  p = &&a1;
case 2:
a2:
  p = &&a2;
case 3:
a3:
  p = &&a3;
case 4:
a4:
  p = &&a4;
case 5:
a5:
  p = &&a5;
case 6:
a6:
  p = &&a6;
case 7:
a7:
  p = &&a7;
case 8:
a8:
  p = &&a8;
case 9:
a9:
  p = &&a9;
case 10:
a10:
  p = &&a10;
default:
  p = &&a0;
}
  goto *p;
}

int
main ()
{
  foo (20);
  if (p == NULL)
abort ();
  ((func_t) p) ();
  return 0;
}
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2  -fcf-protection /tmp/foo.c
[hjl@gnu-cfl-2 gcc]$ cat foo.s
.file   "foo.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB11:
.cfi_startproc
endbr64
testl   %edi, %edi
je  .L1
.L3:
endbr64
.L4:
.L5:
.L6:
.L7:
.L8:
.L9:
.L10:
.L11:
.L12:
movq$.L2, p(%rip)
.L2:
.L1:  Missing ENDBR
ret
.cfi_endproc
.LFE11:
.size   foo, .-foo
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.section.text.startup,"ax",@progbits
.LHOTB0:
.p2align 4
.globl  main
.type   main, @function
main:
.LFB12:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$20, %edi
callfoo
movqp(%rip), %rax
testq   %rax, %rax
je  .L19
call*%rax
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.type   main.cold, @function
main.cold:
.LFSB12:
.L19:
.cfi_def_cfa_offset 16
callabort
.cfi_endproc
.LFE12:
.section.text.startup
.size   main, .-main
.section.text.unlikely
.size   main.cold, .-main.cold
.LCOLDE0:
.section.text.startup
.LHOTE0:
.globl  p
.bss
.align 8
.type   p, @object
.size   p, 8
p:
.zero   8
.ident  "GCC: (GNU) 10.0.1 20200422 (experimental)"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 8
.long1f - 0f
.long4f - 1f
.long5
0:
.string  "GNU"
1:
.align 8
.long0xc002
.long3f - 2f
2:
.long0x3
3:
.align 8
4:
[hjl@gnu-cfl-2 gcc]$

[Bug analyzer/94732] Analyzer: false positive in MPFR's atan.c

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre  ---
Here's the corresponding simple testcase:

typedef struct { int *a; } S;
int *f (void);
static void g (S *x)
{
  int *p = x->a;
  p[0] = 0;
}
void h (void)
{
  S x[1];
  x->a = f ();
  g (x);
}

$ gcc-10 -c -fanalyzer bug.i
bug.i: In function ‘g’:
bug.i:6:8: warning: use of uninitialized value ‘p’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
6 |   p[0] = 0;
  |   ~^~~
  ‘h’: events 1-2
|
|8 | void h (void)
|  |  ^
|  |  |
|  |  (1) entry to ‘h’
|..
|   12 |   g (x);
|  |   ~
|  |   |
|  |   (2) calling ‘g’ from ‘h’
|
+--> ‘g’: events 3-4
   |
   |3 | static void g (S *x)
   |  | ^
   |  | |
   |  | (3) entry to ‘g’
   |..
   |6 |   p[0] = 0;
   |  |      
   |  ||
   |  |(4) use of uninitialized value ‘p’ here
   |

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:06eca1acafa27e19e82dc73927394a7a4d0bdbc5

commit r10-7920-g06eca1acafa27e19e82dc73927394a7a4d0bdbc5
Author: Thomas König 
Date:   Thu Apr 23 20:30:01 2020 +0200

Fix PR 93956, wrong pointer when returned via function.

This one took a bit of detective work.  When array pointers point
to components of derived types, we currently set the span field
and then create an array temporary when we pass the array
pointer to a procedure as a non-pointer or non-target argument.
(This is inefficient, but that's for another release).

Now, the compiler detected this case when there was a direct assignment
like p => a%b, but not when p was returned either as a function result
or via an argument.  This patch fixes that.

2020-04-23  Thomas Koenig  

PR fortran/93956
* expr.c (gfc_check_pointer_assign): Also set subref_array_pointer
when a function returns a pointer.
* interface.c (gfc_set_subref_array_pointer_arg): New function.
(gfc_procedure_use): Call it.

2020-04-23  Thomas Koenig  

PR fortran/93956
* gfortran.dg/pointer_assign_13.f90: New test.

[Bug target/94697] aarch64: bti j at function start instead of bti c

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c/94734] Program crashes when compiled with GCC 10

[john+gcc at hogberg dot online]

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

john+gcc at hogberg dot online changed:

   What|Removed |Added

  Attachment #48361|0   |1
is obsolete||

--- Comment #1 from john+gcc at hogberg dot online ---
Created attachment 48363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48363&action=edit
Improved testcase

[Bug c++/94721] C++2a: Three-way comparison operator for function pointers rejected

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #3 from Marek Polacek  ---
(In reply to Daniel Krügler from comment #2)
> (In reply to Marek Polacek from comment #1)
> > Confirmed, thanks for the report.
> 
> Sigh, thanks. I'm starting to realize now, that it seems that the
> *intention* of
> https://wg21.link/p1959r0 adopted in November was to remove support of <=>
> on function pointers, but the current post-Prague wording paper seems to
> still have wording leftovers that mislead me to the interpretation expressed
> in this issue. I would like to withdraw this issue now and I'm starting a
> CWG discussion instead. My apologize for the false alarm.

No worries at all.  Closing as invalid then.

[Bug c/94730] [8/9/10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:2435

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
I'd suspect the code in finish_decl that deals with types determined from 
array initializers ("For global variables, update the copy of the type 
that exists in the binding.") of being involved here.

  if (b_ext->u.type && comptypes (b_ext->u.type, type))
b_ext->u.type = composite_type (b_ext->u.type, type);
  else
b_ext->u.type = type;

If the new type isn't compatible with the existing type of the 
declaration, it should probably not be stored in b_ext->u.type.

[Bug c++/94721] C++2a: Three-way comparison operator for function pointers rejected

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  ---
(In reply to Marek Polacek from comment #1)
> Confirmed, thanks for the report.

Sigh, thanks. I'm starting to realize now, that it seems that the *intention*
of
https://wg21.link/p1959r0 adopted in November was to remove support of <=> on
function pointers, but the current post-Prague wording paper seems to still
have wording leftovers that mislead me to the interpretation expressed in this
issue. I would like to withdraw this issue now and I'm starting a CWG
discussion instead. My apologize for the false alarm.

[Bug c++/90448] [8/9 Regression] decltype-based lambda parameter pack is rejected

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The testcase ICEs on powerpc64-linux with -m32:
lambda-generic-variadic20.C:5:12: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:8075
5 |   auto L = [](auto ... a) {
  |^~~~
6 | auto M = [](decltype(a) ... b) -> void {
  | 
7 | };
  | ~~  
8 | return M;
  | ~
9 |   };
  |   ~ 
0xd9422a expand_expr_addr_expr_1
../../gcc/expr.c:8075
0xd94817 expand_expr_addr_expr
../../gcc/expr.c:8188
0xda0a68 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11363
0xd94bcd expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.c:8358
0xc050ff expand_normal
../../gcc/expr.h:288
0xc0686f precompute_register_parameters
../../gcc/calls.c:982
0xc0fc27 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4398
0xd9f9cb expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11135
0xd94bcd expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.c:8358
0xd8cef5 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5752
0xd8c194 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5514
0xc2860b expand_call_stmt
../../gcc/cfgexpand.c:2701
0xc2b6b5 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3682
0xc2bc49 expand_gimple_stmt
../../gcc/cfgexpand.c:3847
0xc32a16 expand_gimple_basic_block
../../gcc/cfgexpand.c:5887
0xc3401a execute
../../gcc/cfgexpand.c:6542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/94735] MVE vector load/store pair getting removed with -O2.

[sripar01 at gcc dot gnu.org]

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |sripar01 at gcc dot 
gnu.org
 Target||arm-none-eabi
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-23

[Bug tree-optimization/94718] Failure to optimize opposite signs check

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
--- gcc/fold-const.c.jj 2020-03-31 11:06:14.063512214 +0200
+++ gcc/fold-const.c2020-04-23 18:39:15.399738420 +0200
@@ -11631,50 +11631,6 @@ fold_binary_loc (location_t loc, enum tr
  return omit_one_operand_loc (loc, type, res, arg0);
}

-  /* Fold (X & C) op (Y & C) as (X ^ Y) & C op 0", and symmetries.  */
-  if (TREE_CODE (arg0) == BIT_AND_EXPR
- && TREE_CODE (arg1) == BIT_AND_EXPR)
-   {
- tree arg00 = TREE_OPERAND (arg0, 0);
- tree arg01 = TREE_OPERAND (arg0, 1);
- tree arg10 = TREE_OPERAND (arg1, 0);
- tree arg11 = TREE_OPERAND (arg1, 1);
- tree itype = TREE_TYPE (arg0);
-
- if (operand_equal_p (arg01, arg11, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg10);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg00, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg01);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg01, arg10, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg11);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg00, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg01);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg00, arg11, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg10);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg01, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg00);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg00, arg10, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg11);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg01, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg00);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
-   }
-
   if (TREE_CODE (arg0) == BIT_XOR_EXPR
  && TREE_CODE (arg1) == BIT_XOR_EXPR)
{
--- gcc/match.pd.jj 2020-03-11 18:33:50.341663648 +0100
+++ gcc/match.pd2020-04-23 19:17:37.954208051 +0200
@@ -4335,7 +4335,12 @@ (define_operator_list COND_TERNARY
  (simplify
   (cmp (convert? addr@0) integer_zerop)
   (if (tree_single_nonzero_warnv_p (@0, NULL))
-   { constant_boolean_node (cmp == NE_EXPR, type); })))
+   { constant_boolean_node (cmp == NE_EXPR, type); }))
+
+ /* (X & C) op (Y & C) into (X ^ Y) & C op 0.  */
+ (simplify
+  (cmp (bit_and:cs @0 @2) (bit_and:cs @1 @2))
+  (cmp (bit_and (bit_xor @0 @1) @2) { build_zero_cst (TREE_TYPE (@2)); })))

 /* If we have (A & C) == C where C is a power of 2, convert this into
(A & C) != 0.  Similarly for NE_EXPR.  */

is untested part without testsuite coverage that optimizes the above #c2 third
test the same as #c2 second test.  Unsure about :s.

[Bug c/94735] New: MVE vector load/store pair getting removed with -O2.

[sripar01 at gcc dot gnu.org]

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

Bug ID: 94735
   Summary: MVE vector load/store pair getting removed with -O2.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sripar01 at gcc dot gnu.org
  Target Milestone: ---

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

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/media/sripar01/2tb_work/Release/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/10.0.1/lto-wrapper
Target: arm-none-eabi
Configured with: /media/sripar01/2tb_work/Release/src/gcc/configure
--target=arm-none-eabi
--prefix=/media/sripar01/2tb_work/Release/build-arm-none-eabi/install//
--with-gmp=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-mpfr=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-mpc=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-isl=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c --without-cloog --without-isl
--with-newlib --without-headers --with-multilib-list=rmprofile
--with-pkgversion=unknown
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200423 (experimental) (unknown)

$ arm-none-eabi-gcc mve_vstore.i -S -O2 -march=armv8.1-m.main+mve
-mfloat-abi=hard

On compiling attached test case (mve_vstore.i) with -02 optimizes out a pair of
vector load/store statements.

[Bug c/94734] New: Program crashes when compiled with GCC 10

[john+gcc at hogberg dot online]

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

Bug ID: 94734
   Summary: Program crashes when compiled with GCC 10
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john+gcc at hogberg dot online
  Target Milestone: ---

Created attachment 48361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48361&action=edit
Test case program

The attached program crashes when it has been compiled with GCC 10 and -O2.
With -O3 or -Os it returns an incorrect value instead.

There are no warnings with `-Wall -Wextra` or `-fanalyzer`, and strangely
enough `-fsanitize=undefined` hides the crash without reporting any errors.

-fno-aggressive-loop-optimizations also makes the crash go away which made me
suspect that the code is wrong somehow, but `frama-c` insists that it's correct
and should always return 0. If there's a bug in there, I'm not seeing it. :(

Steps to reproduce:


$ gcc -O2 test.c -o bug
$ ./bug
Segmentation fault (core dumped)


GCC version:


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200423 (experimental) (GCC) 


It appears to work fine with GCC 7, I tested it with:


$ gcc-7 -v
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to CVS Commits from comment #14)
> [AArch64] (PR94383) Avoid C++17 empty base field checking for HVA/HFA
> 
> In C++17, an empty class deriving from an empty base is not an
> aggregate, while in C++14 it is.

FWIW that's backwards.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #208 from dave.anglin at bell dot net ---
On 2020-04-23 11:48 a.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> Peter Bisroev  changed:
>
>What|Removed |Added
> 
>  CC||peter.bisroev at groundlabs 
> dot co
>||m
>
> --- Comment #207 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #206)
>> Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and
>> cc1plus?
> Hi Dave, sorry for the delayed response. That is a good catch, I missed that
> option before. I will be able to test this out this weekend. Will let you know
> asap.
I saw it perusing the comments for weak support on PA-RISC.  I believe that I
found that shared libraries
are automatically garbage collected but applications are not.

Dave

[Bug testsuite/94725] Tests with proprietary license notices

[ams at gcc dot gnu.org]

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

Andrew Stubbs  changed:

   What|Removed |Added

 CC||ams at gcc dot gnu.org

--- Comment #2 from Andrew Stubbs  ---
The update-copyright.py can have the special handling removed.

[Bug c++/94733] [10 Regression] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Status|UNCONFIRMED |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-04-23

--- Comment #1 from Marek Polacek  ---
I broke it: r10-1214-g1bf32c1141e230743f9248f7f7bf8aab91823df5

[Bug c++/94733] New: [10 Regression] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155

[asolokha at gmx dot com]

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

Bug ID: 94733
   Summary: [10 Regression] ICE: tree check: expected
identifier_node, have tree_list in is_attribute_p, at
attribs.h:155
   Product: gcc
   Version: 10.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: ---

g++-10.0.1-alpha20200419 snapshot (g:717e91dbc44c6bf55a498f45f6045191ceb10a11)
ICEs when compiling the following testcase w/ -fgnu-tm:

struct [[gnu::may_alias]] pe { };

% g++-10.0.1 -fgnu-tm -c eqtzx3iu.cpp
eqtzx3iu.cpp:1:27: internal compiler error: tree check: expected
identifier_node, have tree_list in is_attribute_p, at attribs.h:155
1 | struct [[gnu::may_alias]] pe { };
  |   ^~
0x7bcf2c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/tree.c:9727
0x6aa239 tree_check(tree_node const*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/tree.h:3543
0x6aa239 is_attribute_p
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/attribs.h:155
0x6abe5e tm_attr_to_mask(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/tree.h:3401
0xafbaef find_tm_attribute(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/c-family/c-attribs.c:3318
0x896740 set_method_tm_attributes
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/class.c:5092
0x896740 finish_struct_1(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/class.c:7302
0x897b24 finish_struct(tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/class.c:7516
0x9975f3 cp_parser_class_specifier_1
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/parser.c:23878
0x99969b cp_parser_class_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/parser.c:24177
0x99969b cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/parser.c:17708
0x99a7a5 cp_parser_decl_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/parser.c:14356
0x99b244 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/parser.c:13610
0x9c5a32 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/parser.c:13430
0x9c61cf cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/parser.c:4731
0x9c61cf c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/cp/parser.c:43972
0xadeaeb c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200419/work/gcc-10-20200419/gcc/c-family/c-opts.c:1190

Citing Jakub's PR94106 comment 2: "Nobody really maintains the -fgnu-tm stuff
anymore".

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

Peter Bisroev  changed:

   What|Removed |Added

 CC||peter.bisroev at groundlabs 
dot co
   ||m

--- Comment #207 from Peter Bisroev  ---
(In reply to dave.anglin from comment #206)
> Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and
> cc1plus?

Hi Dave, sorry for the delayed response. That is a good catch, I missed that
option before. I will be able to test this out this weekend. Will let you know
asap.

Thanks!
--peter

[Bug tree-optimization/94718] Failure to optimize opposite signs check

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
In fold-const.c this is optimized by
fold_binary case EQ_EXPR: case NE_EXPR:
  /* Fold (X & C) op (Y & C) as (X ^ Y) & C op 0", and symmetries.  */
Of course, the (x op 0) op2 (y op 0) for op < or >= and op2 == or != could be
added to the same spot, but is there any reason why the above mentioned
optimization shouldn't be moved into match.pd (won't it be even much simpler
there where it can just use :c 3 times)?

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[andrea.corallo at arm dot com]

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

--- Comment #31 from Andrea Corallo  ---
I confirm master now builds for me aarch64-none-elf.

[Bug target/94697] aarch64: bti j at function start instead of bti c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

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

commit r10-7918-gf7e4641afba7c348a7e7c8655e537a953c416bb3
Author: Szabolcs Nagy 
Date:   Fri Apr 17 16:54:12 2020 +0100

aarch64: ensure bti c is emitted at function start [PR94697]

The bti pass currently first emits bti c at function start
if there is no paciasp (which also acts as indirect call
landing pad), then bti j is emitted at jump labels, however
if there is a label right before paciasp then the function
start can end up like

  foo:
  label:
bti j
paciasp
...

This patch is a minimal fix that just moves the bti c handling
after the bti j handling so we end up with

  foo:
bti c
  label:
bti j
paciasp
...

This could be improved by emitting bti jc in this case, or by
detecting that the label is not in fact an indirect jump target
and then this situation would be much less common.

Needs to be backported to gcc-9 branch.

gcc/ChangeLog:

PR target/94697
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Swap
bti c and bti j handling.

gcc/testsuite/ChangeLog:

PR target/94697
* gcc.target/aarch64/pr94697.c: New test.

[Bug target/94678] aarch64: unexpected result with -mgeneral-regs-only and sve

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:857d1fa3f0a04569382bab12829e5bfd3725ecbf

commit r10-7917-g857d1fa3f0a04569382bab12829e5bfd3725ecbf
Author: Fei Yang 
Date:   Thu Apr 23 16:08:03 2020 +0100

testsuite: Add extra aarch64 predefine tests

Add extra testing in the following two tests to make sure CPP predefines
redefinitions on #pragma works as expected when -mgeneral-regs-only
option is specified (See PR94678):
gcc.target/aarch64/pragma_cpp_predefs_2.c
gcc.target/aarch64/pragma_cpp_predefs_3.c

2020-04-23  Felix Yang  

gcc/testsuite/
PR target/94678
* gcc.target/aarch64/pragma_cpp_predefs_2.c: Fix typos, pop_pragma
->
pop_options. Add tests for general-regs-only.
* gcc.target/aarch64/pragma_cpp_predefs_3.c: Add tests for
general-regs-only.

[Bug middle-end/93488] [OpenACC] ICE in type-cast 'async', 'wait' clauses

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Andrew Stubbs :

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

commit r10-7916-gee9fcee3ec3a124dc3947c73c264bbcda97198df
Author: Andrew Stubbs 
Date:   Thu Jan 30 18:25:15 2020 +

OpenACC: Avoid ICE in type-cast 'async', 'wait' clauses

2020-04-23  Andrew Stubbs  
Thomas Schwinge  

PR middle-end/93488

gcc/
* omp-expand.c (expand_omp_target): Use force_gimple_operand_gsi on
t_async and the wait arguments.

gcc/testsuite/
* c-c++-common/goacc/pr93488.c: New file.

Reviewed-by: Thomas Schwinge 

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-23
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

[Bug analyzer/94732] New: Analyzer: false positive in MPFR's atan.c

[vincent-gcc at vinc17 dot net]

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

Bug ID: 94732
   Summary: Analyzer: false positive in MPFR's atan.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

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

Test with: gcc-10 (Debian 10-20200418-1) 10.0.1 20200418 (experimental) [master
revision 27c171775ab:4c277008be0:c5bac7d127f288fd2f8a1f15c3f30da5903141c6]

When I want to compile GNU MPFR with -fanalyzer, the compilation of atan.c
fails on what appears to be a false positive. I've managed to reduce the
6000-line preprocessed code to code with fewer than 300 lines (attached bug.i
file). More specifically, I've removed
  * blank lines and comments;
  * unused declarations/definitions;
  * code that could have an influence only after the "error";
  * code testing and handling special cases.

I order to see where the issue could come from, I've added 2 lines
  * "((y)->_mpfr_d)[0] = 0;" at the beginning of mpfr_atan_aux;
  * "((tmp2)->_mpfr_d)[0] = 0;" just before the call to mpfr_atan_aux.

Without these 2 lines, "gcc-10 -c -fanalyzer bug.i" gives:

bug.i: In function ‘set_table’:
bug.i:145:9: warning: use of uninitialized value ‘yp’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
  145 |   yp[0] &= ~(((void) 0), sh ==
  | ^~

where yp is set with

  mp_limb_t *yp = ((y)->_mpfr_d);

So I suppose that the analyzer complains that (y)->_mpfr_d is uninitialized.
This comes from mpfr_atan_aux, and "((y)->_mpfr_d)[0] = 0;" at the beginning of
this function should trigger the same error. If I add this line, I get in a
consistent way:

bug.i: In function ‘mpfr_atan_aux’:
bug.i:154:19: warning: use of uninitialized value ‘’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
  154 | ((y)->_mpfr_d)[0] = 0;
  | ~~^~~

This mpfr_atan_aux function is called at only one place:

  mpfr_atan_aux (tmp2, ukz, twopoweri, n0 - i, tabz);

So I added "((tmp2)->_mpfr_d)[0] = 0;" just before this call. I thought that I
would get an error on this, but I still get an error only on "((y)->_mpfr_d)[0]
= 0;" in mpfr_atan_aux. If I remove this line (just keeping the one before the
call to mpfr_atan_aux), I get the error in set_table only, just like in the
first test.

Now, this appears to be a false positif since (tmp2)->_mpfr_d was initialized
earlier.

I could probably simplify the code even further, focusing on (tmp2)->_mpfr_d
only.

[Bug tree-optimization/94727] [10 Regression] GCC produces incorrect code with -O3 since r10-5071-g02d895504cc59be0

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Fixed on master.  Thanks for the report.

[Bug tree-optimization/94727] [10 Regression] GCC produces incorrect code with -O3 since r10-5071-g02d895504cc59be0

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:901f5289d9465d4c388ae288f850ad4f29e99a2c

commit r10-7915-g901f5289d9465d4c388ae288f850ad4f29e99a2c
Author: Richard Sandiford 
Date:   Thu Apr 23 15:45:43 2020 +0100

vect: Fix comparisons between invariant booleans [PR94727]

This PR was caused by mismatched expectations between
vectorizable_comparison and SLP.  We had a "<" comparison
between two booleans that were leaves of the SLP tree, so
vectorizable_comparison fell back on:

  /* Invariant comparison.  */
  if (!vectype)
{
  vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
 slp_node);
  if (maybe_ne (TYPE_VECTOR_SUBPARTS (vectype), nunits))
return false;
}

rhs1 and rhs2 were *unsigned* boolean types, so we got back a vector
of unsigned integers.  This in itself was OK, and meant that "<"
worked as expected without the need for the boolean fix-ups:

  /* Boolean values may have another representation in vectors
 and therefore we prefer bit operations over comparison for
 them (which also works for scalar masks).  We store opcodes
 to use in bitop1 and bitop2.  Statement is vectorized as
   BITOP2 (rhs1 BITOP1 rhs2) or
   rhs1 BITOP2 (BITOP1 rhs2)
 depending on bitop1 and bitop2 arity.  */
  bool swap_p = false;
  if (VECTOR_BOOLEAN_TYPE_P (vectype))
{

However, vectorizable_comparison then used vect_get_slp_defs to get
the actual operands.  The request went to vect_get_constant_vectors,
which also has logic to calculate the vector type.  The problem was
that this type was different from the one chosen above:

  if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
  && vect_mask_constant_operand_p (stmt_vinfo))
vector_type = truth_type_for (stmt_vectype);
  else
vector_type = get_vectype_for_scalar_type (vinfo, TREE_TYPE (op),
op_node);

So the function gave back a vector of mask types, which here are vectors
of *signed* booleans.  This meant that "<" gave:

  true (-1) < false (0)

and so the boolean fixup above was needed after all.

Fixed by making vectorizable_comparison also pick a mask type in
this case.

2020-04-23  Richard Sandiford  

gcc/
PR tree-optimization/94727
* tree-vect-stmts.c (vectorizable_comparison): Use mask_type when
comparing invariant scalar booleans.

gcc/testsuite/
PR tree-optimization/94727
* gcc.dg/vect/pr94727.c: New test.

[Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390

[jakub at gcc dot gnu.org]

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

Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly 
with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383

   What|Removed |Added

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

[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #30 from Jakub Jelinek  ---
Hopefully fixed.

[Bug target/94707] [8/9 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le

[jakub at gcc dot gnu.org]

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

Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly 
with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383

   What|Removed |Added

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

[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'

[jakub at gcc dot gnu.org]

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

Bug 94694 Summary: [10 Regression][libgfortran] libgfortran does not compile on 
bare-metal aarch64-none-elf (newlib)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

   What|Removed |Added

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

[Bug target/94711] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on arm

[jakub at gcc dot gnu.org]

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

Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly 
with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383

   What|Removed |Added

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

[Bug target/94706] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on ia64

[jakub at gcc dot gnu.org]

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

Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly 
with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383

   What|Removed |Added

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

[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Matthew Malcomson :

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

commit r10-7914-ge73a32d6d47ec7c5fb5a5fe7eb896c0e1258ea68
Author: Matthew Malcomson 
Date:   Thu Apr 23 15:33:55 2020 +0100

[AArch64] (PR94383) Avoid C++17 empty base field checking for HVA/HFA

In C++17, an empty class deriving from an empty base is not an
aggregate, while in C++14 it is.  In order to implement this, GCC adds
an artificial field to such classes.

This artificial field has no mapping to Fundamental Data Types in the
AArch64 PCS ABI and hence should not count towards determining whether an
object can be passed using the vector registers as per section
"6.4.2 Parameter Passing Rules" in the AArch64 PCS.
   
https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst#the-base-procedure-call-standard

This patch avoids counting this artificial field in
aapcs_vfp_sub_candidate, and hence calculates whether such objects
should be passed in vector registers in the same manner as C++14 (where
the artificial field does not exist).

Before this change, the test below would pass the arguments to `f` in
general registers.  After this change, the test passes the arguments to
`f` using the vector registers.

The new behaviour matches the behaviour of `armclang`, and also matches
the behaviour when run with `-std=gnu++14`.

> gcc -std=gnu++17 test.cpp

``` test.cpp
struct base {};

struct pair : base
{
  float first;
  float second;
  pair (float f, float s) : first(f), second(s) {}
};

void f (pair);
int main()
{
  f({3.14, 666});
  return 1;
}
```

We add a `-Wpsabi` warning to catch cases where this fix has changed the
ABI for
some functions.  Unfortunately this warning is not emitted twice for
multiple
calls to the same function, but I feel this is not much of a problem and
can be
fixed later if needs be.

(i.e. if `main` called `f` twice in a row we only emit a diagnostic for the
first).

Testing:
Bootstrap and regression test on aarch64-linux.
All struct-layout-1 tests now pass.

gcc/ChangeLog:

2020-04-23  Matthew Malcomson  
Jakub Jelinek  

PR target/94383
* config/aarch64/aarch64.c (aapcs_vfp_sub_candidate): Account for
C++17
empty base class artificial fields.
(aarch64_vfp_is_call_or_return_candidate): Warn when ABI PCS
decision is
different after this fix.

[Bug c/94730] [8/9/10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:2435

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Note, with
int x, y;

void
foo ()
{
  x = 0;
  y = 0;
  if (x != 0)
y++;
  else
x++;
}

int x[1] = { 0 };

the type of x isn't overritten, only when it is int x[] = { 0 };

The type replacement happened in pop_scope:
1370  gcc_assert (I_SYMBOL_BINDING (b->id) == b);
1371  I_SYMBOL_BINDING (b->id) = b->shadowed;
1372  if (b->shadowed && b->shadowed->u.type)
1373TREE_TYPE (b->shadowed->decl) = b->shadowed->u.type;

[Bug c/94731] [8/9/10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:2558

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-23
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
Summary|[10 Regression] internal|[8/9/10 Regression]
   |compiler error: in  |internal compiler error: in
   |fold_convert_loc, at|fold_convert_loc, at
   |fold-const.c:2558   |fold-const.c:2558
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |8.5
   Keywords||error-recovery
   Priority|P3  |P4

--- Comment #1 from Jakub Jelinek  ---
This one started to ICE with r8-2897-g02e637d86f9ecb6d0e368438291bb6f6f8feb3ab
I bet in the end it is the same FE bug, that it really shouldn't change the
type of a decl on duplicate_decls once it has been used because the middle-end
is unprepared to see error_mark_nodes.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[ams at gcc dot gnu.org]

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

--- Comment #23 from Andrew Stubbs  ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Andrew Stubbs from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > or if instead we should drop the "status = " for the cases where nothing
> > > checks it. Andrew?
> > 
> > I think checking the status is probably good practice, even though I don't
> > think there's an actual bug here.
> 
> I have no way to test it, so if you want and can test it (perhaps with other
> changes), please take it over, or we throw it away, we don't have to fix all
> the warnings, we just should skim through it to find if there aren't any
> actual bugs.

I think this is done now. The patch needed to be changed a little because
HSA_STATUS_INFO_BREAK is also a valid return value (meaning that the iterator
exited early).

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from CVS Commits  ---
The master branch has been updated by Fritz Reese :

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

commit r10-7913-ge8eecc2a919033ad4224756a8759d8e94c0e4bc2
Author: Fritz Reese 
Date:   Wed Apr 22 11:45:22 2020 -0400

Protect the trigd functions in libgfortran from unavailable math functions.

libgfortran/ChangeLog:

2020-04-22  Fritz Reese  

PR libfortran/94694
PR libfortran/94586
* intrinsics/trigd.c, intrinsics/trigd_lib.inc,
intrinsics/trigd.inc:
Guard against unavailable math functions.
Use suffixes from kinds.h based on the REAL kind.

gcc/fortran/ChangeLog:

2020-04-22  Fritz Reese  

* trigd_fe.inc: Use mpfr to compute cosd(30) rather than a host-
precision floating point literal based on an invalid macro.

[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'

[cvs-commit at gcc dot gnu.org]

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

--- Comment #40 from CVS Commits  ---
The master branch has been updated by Fritz Reese :

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

commit r10-7913-ge8eecc2a919033ad4224756a8759d8e94c0e4bc2
Author: Fritz Reese 
Date:   Wed Apr 22 11:45:22 2020 -0400

Protect the trigd functions in libgfortran from unavailable math functions.

libgfortran/ChangeLog:

2020-04-22  Fritz Reese  

PR libfortran/94694
PR libfortran/94586
* intrinsics/trigd.c, intrinsics/trigd_lib.inc,
intrinsics/trigd.inc:
Guard against unavailable math functions.
Use suffixes from kinds.h based on the REAL kind.

gcc/fortran/ChangeLog:

2020-04-22  Fritz Reese  

* trigd_fe.inc: Use mpfr to compute cosd(30) rather than a host-
precision floating point literal based on an invalid macro.

[Bug c/94730] [8/9/10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:2435

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery
   Target Milestone|--- |8.5
Summary|[10 Regression] internal|[8/9/10 Regression]
   |compiler error: in  |internal compiler error: in
   |fold_convert_loc, at|fold_convert_loc, at
   |fold-const.c:2435   |fold-const.c:2435
   Last reconfirmed||2020-04-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
ICEs since r0-94713-ga406865a0845cdef8bdd3eefa53e7f3992cb34ff or so (perhaps
the previous commit).

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Andrew Stubbs :

https://gcc.gnu.org/g:966de09be91c639d66d252c9ae6ab8da5ebfca18

commit r10-7912-g966de09be91c639d66d252c9ae6ab8da5ebfca18
Author: Andrew Stubbs 
Date:   Mon Apr 20 15:25:31 2020 +0100

amdgcn: Check HSA return codes [PR94629]

Ensure that the returned status values are not ignored.  The old code was
not broken, but this is both safer and satisfies static analysis.

2020-04-23  Andrew Stubbs  

PR other/94629

libgomp/
* plugin/plugin-gcn.c (init_hsa_context): Check return value from
hsa_iterate_agents.
(GOMP_OFFLOAD_init_device): Check return values from both calls to
hsa_agent_iterate_regions.

[Bug c/94731] New: [10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:2558

[anbu1024.me at gmail dot com]

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

Bug ID: 94731
   Summary: [10 Regression] internal compiler error: in
fold_convert_loc, at fold-const.c:2558
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat reduced.c 

int x = - 1 << 0 ; 

int foo () 
{ 
switch ( x ) 
case - 1 << 0 : 
break ; 
}

int x[] = { 1 };



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



$ gcc-10 reduced.c 
reduced.c:11:5: error: conflicting types for ‘x’
   11 | int x[] = { 1 };
  | ^
reduced.c:2:5: note: previous definition of ‘x’ was here
2 | int x = - 1 << 0 ;
  | ^
during GIMPLE pass: cfg
reduced.c: In function ‘foo’:
reduced.c:4:5: internal compiler error: in fold_convert_loc, at
fold-const.c:2558
4 | int foo ()
  | ^~~
0x65b384 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc-10-20200419/gcc/fold-const.c:2558
0xdf7852 convert_single_case_switch
../../gcc-10-20200419/gcc/tree-cfgcleanup.c:110
0xdf7852 cleanup_control_expr_graph
../../gcc-10-20200419/gcc/tree-cfgcleanup.c:145
0xdf7852 cleanup_control_flow_bb
../../gcc-10-20200419/gcc/tree-cfgcleanup.c:252
0xdf7a95 cleanup_control_flow_pre
../../gcc-10-20200419/gcc/tree-cfgcleanup.c:886
0xdf8c4b cleanup_tree_cfg_noloop
../../gcc-10-20200419/gcc/tree-cfgcleanup.c:1055
0xdf9428 cleanup_tree_cfg(unsigned int)
../../gcc-10-20200419/gcc/tree-cfgcleanup.c:1165
0xdf03a4 execute_build_cfg
../../gcc-10-20200419/gcc/tree-cfg.c:376
0xdf03a4 execute
../../gcc-10-20200419/gcc/tree-cfg.c:405
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-9 --version
gcc (GCC) 9.2.1 20191102
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.



$ gcc-9 reduced.c 
reduced.c:11:5: error: conflicting types for ‘x’
   11 | int x[] = { 1 };
  | ^
reduced.c:2:5: note: previous definition of ‘x’ was here
2 | int x = - 1 << 0 ;
  | ^
reduced.c:4: confused by earlier errors, bailing out

[Bug c/94730] New: [10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:2435

[anbu1024.me at gmail dot com]

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

Bug ID: 94730
   Summary: [10 Regression] internal compiler error: in
fold_convert_loc, at fold-const.c:2435
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat reduced.c 

int x , y ; 

int foo ( ) 
{ 
x = 0 ; 
y = 0 ; 

if (x != 0) 
y ++; 
else 
x ++ ; 

} 

int x [] = { 0 } ;



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



$ gcc-10 reduced.c 
reduced.c:16:5: error: conflicting types for ‘x’
   16 | int x [] = { 0 } ;
  | ^
reduced.c:2:5: note: previous declaration of ‘x’ was here
2 | int x , y ;
  | ^
reduced.c: In function ‘foo’:
reduced.c:12:5: internal compiler error: in fold_convert_loc, at
fold-const.c:2435
   12 |   x ++ ;
  |   ~~^~
0x65b582 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc-10-20200419/gcc/fold-const.c:2435
0xb12707 gimplify_self_mod_expr(tree_node**, gimple**, gimple**, bool,
tree_node*)
../../gcc-10-20200419/gcc/gimplify.c:3186
0xafd218 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:13538
0xb00bd6 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xb133cc gimplify_cond_expr
../../gcc-10-20200419/gcc/gimplify.c:4269
0xafdafe gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:13565
0xb00bd6 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xafe48b gimplify_statement_list
../../gcc-10-20200419/gcc/gimplify.c:1869
0xafe48b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:14052
0xb00bd6 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xb0199b gimplify_bind_expr
../../gcc-10-20200419/gcc/gimplify.c:1424
0xafe0b3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-10-20200419/gcc/gimplify.c:13809
0xb15927 gimplify_stmt(tree_node**, gimple**)
../../gcc-10-20200419/gcc/gimplify.c:6825
0xb15927 gimplify_body(tree_node*, bool)
../../gcc-10-20200419/gcc/gimplify.c:14857
0xb15e53 gimplify_function_tree(tree_node*)
../../gcc-10-20200419/gcc/gimplify.c:15030
0x9607d7 cgraph_node::analyze()
../../gcc-10-20200419/gcc/cgraphunit.c:670
0x9633f7 analyze_functions
../../gcc-10-20200419/gcc/cgraphunit.c:1227
0x963fc2 symbol_table::finalize_compilation_unit()
../../gcc-10-20200419/gcc/cgraphunit.c:2974
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-9 --version
gcc (GCC) 9.2.1 20191102
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.



$ gcc-9 reduced.c 
reduced.c:16:5: error: conflicting types for ‘x’
   16 | int x [] = { 0 } ;
  | ^
reduced.c:2:5: note: previous declaration of ‘x’ was here
2 | int x , y ;
  | ^
reduced.c:12: confused by earlier errors, bailing out

[Bug target/94282] [amdgcn] ld: error: undefined symbol: __gxx_personality_v0

[ams at gcc dot gnu.org]

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

--- Comment #6 from Andrew Stubbs  ---
I think we've decided to with Thomas's approach.

Thomas, please go ahead and commit.

[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener  ---
So the issue is we're both not doing enough and too much, the half way early
optimizations do confuse us later.  Another such opportunity would maybe
be:

   short unsigned int _950;
  _950 = BIT_FIELD_REF <_58, 16, 240>;
  _253 = (unsigned char) _950;

where this is the only use of _950.  It might be tempting to "optimize"
this into

  _253 = BIT_FIELD_REF <_58, 8, 240>;

forwprop does similar transforms for loads of complex and vector (though
the above is not a load but the transform would extend to loads as well).

[Bug target/94514] aarch64: unwinding across mixed pac-ret and non-pac-ret frames is broken

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

https://gcc.gnu.org/g:744b3e4478df83f54543964b8eb7250eb9bb6d40

commit r10-7911-g744b3e4478df83f54543964b8eb7250eb9bb6d40
Author: Szabolcs Nagy 
Date:   Thu Apr 23 11:26:10 2020 +0100

aarch64: disable tests on ilp32 [PR94514]

branch-protection=pac-ret is only supported with lp64 abi.

gcc/testsuite/ChangeLog:

PR target/94514
* g++.target/aarch64/pr94514.C: Require lp64.
* gcc.target/aarch64/pr94514.c: Likewise.

[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257

[ppalka at gcc dot gnu.org]

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

--- Comment #10 from Patrick Palka  ---
Oops, it turns out the ICEs I was seeing in the cmcstl2 testsuite with the
change in #c9 were actually due to PR94719, which has since been fixed.  The
cmcstl2 testsuite now compiles fine with or without the change in #c9 FWIW.

[Bug tree-optimization/94718] Failure to optimize opposite signs check

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I guess:
int
foo (int x, int y)
{
  return (x < 0) != (y < 0);
}

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

int
baz (int x, int y)
{
  return (x >= 0) != (y >= 0);
}

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

which we don't optimize ATM is equivalent to:
#define I (-__INT_MAX__ - 1)

int
foo (int x, int y)
{
  return (x & I) != (y & I);
}

int
bar (int x, int y)
{
  return (x & I) == (y & I);
}

int
baz (int x, int y)
{
  return (~x & I) != (~y & I);
}

int
qux (int x, int y)
{
  return (~x & I) == (~y & I);
}

int
quux (int x, int y)
{
  return ((x & I) ^ I) != ((y & I) ^ I);
}

int
corge (int x, int y)
{
  return ((x & I) ^ I) == ((~y & I) ^ I);
}
which we do (already in *.original dump), but then
#define I (-__INT_MAX__ - 1)

int
foo (int x, int y)
{
  int s = (x & I);
  int t = (y & I);
  return s != t;
}

int
bar (int x, int y)
{
  int s = (x & I);
  int t = (y & I);
  return s == t;
}

int
baz (int x, int y)
{
  int s = (~x & I);
  int t = (~y & I);
  return s != t;
}

int
qux (int x, int y)
{
  int s = (~x & I);
  int t = (~y & I);
  return s == t;
}

int
quux (int x, int y)
{
  int s = ((x & I) ^ I);
  int t = ((y & I) ^ I);
  return s != t;
}

int
corge (int x, int y)
{
  int s = ((x & I) ^ I);
  int t = ((~y & I) ^ I);
  return s == t;
}
is not again, which means we optimize this somewhere in fold-const.c or where
and don't in match.pd.

[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Even the
&& info->ins_stmt != NULL
in coalesce_immediate_stores is redundant, because try_coalesce_bswap is called
with first = i - 1 and starts with i = first + 1 and thus caller's i and
info in the caller is m_store_info[i].
But I certainly don't object to having the redundant check in the caller,
so patch to add the check to try_coalesce_bswap is preapproved, with or without
adding the check to the caller too, your decision.

[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> Shouldn't that be done in try_coalesce_bswap instead?
> Because checking lp_nr above will only make sure it is the same between
> merged_store and the first store after it, but we are trying to coalesce
> often more than that.
> By checking it in try_coalesce_bswap, in the first loop in that function, it
> will verify all stores.

OK, I didn't realize that try_coalesce_bswap has its own private loop.  But
this can be done in both places, like the check on ins_stmt.

[Bug tree-optimization/94727] [10 Regression] GCC produces incorrect code with -O3 since r10-5071-g02d895504cc59be0

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #6)
> (In reply to rsand...@gcc.gnu.org from comment #5)
> > 
> > However, we then defer to vect_get_slp_defs to get the actual operands.
> > The expected vector type is not part of this interface.
> 
> Ah yeah - sth on my list to fix (not making the type part of that API
> but assigning vector types to SLP nodes).  I even have partly completed
> "hacks" to do that.  When we have (and use!) vector types on all SLP
> nodes we can also get rid of the mismatch code.

Sounds great!  The fewer decisions we make on the fly the better...

> > I'm going to try:
> > 
> > diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> > index 7f3a9fb5fb3..88a1e2c51d2 100644
> > --- a/gcc/tree-vect-stmts.c
> > +++ b/gcc/tree-vect-stmts.c
> > @@ -10566,8 +10566,11 @@ vectorizable_comparison (stmt_vec_info stmt_info,
> > gimple_stmt_iterator *gsi,
> >/* Invariant comparison.  */
> >if (!vectype)
> >  {
> > -  vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
> > -slp_node);
> > +  if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (rhs1)))
> > +   vectype = mask_type;
> > +  else
> > +   vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
> > +  slp_node);
> >if (!vectype || maybe_ne (TYPE_VECTOR_SUBPARTS (vectype), nunits))
> > return false;
> >  }
> > 
> > which does at least fix the testcase.
> 
> LGTM.

Thanks.  aarch64-linux-gnu and x86_64-linux-gnu bootstrapped passed,
now trying an SVE test run.  Will commit if that passes too.

[Bug target/94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV

[ams at gcc dot gnu.org]

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

--- Comment #4 from Andrew Stubbs  ---
Almost all the tests listed in pr81430 pass for me (and the exception I found
is a link error).

I don't understand what's happening with your build, but from my point of view
the patch fixes an issue that doesn't exist.

[Bug target/94707] [8/9 Regression] class with empty base passed incorrectly with -std=c++17 on powerpc64le

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:239cfd92e9ce5014a7616f692e0c6d4f337227b8

commit r10-7910-g239cfd92e9ce5014a7616f692e0c6d4f337227b8
Author: Jakub Jelinek 
Date:   Thu Apr 23 14:43:18 2020 +0200

rs6000: Small improvement to the C++17 ABI fix [PR94707]

Anyway, based on IRC discussion with Richard Sandiford on IRC, we should
probably test type uids instead of type pointers because type uids aren't
reused, but type pointers in a very bad luck case could be, and having the
static var at filescope and GTY((deletable)) is an overkill (and with costs
during GC time).

2020-04-23  Jakub Jelinek  

PR target/94707
* config/rs6000/rs6000-call.c
(rs6000_discover_homogeneous_aggregate):
Use TYPE_UID (TYPE_MAIN_VARIANT (type)) instead of type to check
if the same type has been diagnosed most recently already.

[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Eric Botcazou from comment #3)
> > The compiler is apparently not prepared for new trapping loads.  Fixing...
> 
> No, just a missing check on landing pads:
> 
> index a6687cd9c98..4ab8e0250ab 100644
> --- a/gcc/gimple-ssa-store-merging.c
> +++ b/gcc/gimple-ssa-store-merging.c
> @@ -2680,6 +2680,7 @@ imm_store_chain_info::coalesce_immediate_stores ()
>  p[3] = data;
>  using the bswap framework.  */
>if (info->bitpos == merged_store->start + merged_store->width
> + && info->lp_nr == merged_store->lp_nr
>   && merged_store->stores.length () == 1
>   && merged_store->stores[0]->ins_stmt != NULL
>   && info->ins_stmt != NULL)

Shouldn't that be done in try_coalesce_bswap instead?
Because checking lp_nr above will only make sure it is the same between
merged_store and the first store after it, but we are trying to coalesce often
more than that.
By checking it in try_coalesce_bswap, in the first loop in that function, it
will verify all stores.

[Bug tree-optimization/94727] [10 Regression] GCC produces incorrect code with -O3 since r10-5071-g02d895504cc59be0

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> Well, this is a bit of mess (surprise).  We have a "<" comparison
> between two booleans that are leaves of the SLP tree, so
> vectorizable_comparison falls back on:
> 
>   /* Invariant comparison.  */
>   if (!vectype)
> {
>   vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
>  slp_node);
>   if (maybe_ne (TYPE_VECTOR_SUBPARTS (vectype), nunits))
> return false;
> }
> 
> rhs1 and rhs2 are *unsigned* boolean types, so we get back a vector
> of unsigned integers.  All is well, and "<" works as expected without
> the need for:
> 
>   /* Boolean values may have another representation in vectors
>  and therefore we prefer bit operations over comparison for
>  them (which also works for scalar masks).  We store opcodes
>  to use in bitop1 and bitop2.  Statement is vectorized as
>BITOP2 (rhs1 BITOP1 rhs2) or
>rhs1 BITOP2 (BITOP1 rhs2)
>  depending on bitop1 and bitop2 arity.  */
>   bool swap_p = false;
>   if (VECTOR_BOOLEAN_TYPE_P (vectype))
> {
> 
> However, we then defer to vect_get_slp_defs to get the actual operands.
> The expected vector type is not part of this interface.

Ah yeah - sth on my list to fix (not making the type part of that API
but assigning vector types to SLP nodes).  I even have partly completed
"hacks" to do that.  When we have (and use!) vector types on all SLP
nodes we can also get rid of the mismatch code.

> The request
> goes to vect_get_constant_vectors, which does:
> 
>   if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
>   && vect_mask_constant_operand_p (stmt_vinfo))
> vector_type = truth_type_for (stmt_vectype);
>   else
> vector_type = get_vectype_for_scalar_type (vinfo, TREE_TYPE (op),
> op_node);
> 
> So the function gives back a vector of mask types, which here are
> vectors of *signed* booleans.  This means that "<" gives:
> 
>   true (-1) < false (0)
> 
> and so the boolean fixup above was needed after all.
> 
> I'm going to try:
> 
> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index 7f3a9fb5fb3..88a1e2c51d2 100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -10566,8 +10566,11 @@ vectorizable_comparison (stmt_vec_info stmt_info,
> gimple_stmt_iterator *gsi,
>/* Invariant comparison.  */
>if (!vectype)
>  {
> -  vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
> -slp_node);
> +  if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (rhs1)))
> +   vectype = mask_type;
> +  else
> +   vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
> +  slp_node);
>if (!vectype || maybe_ne (TYPE_VECTOR_SUBPARTS (vectype), nunits))
> return false;
>  }
> 
> which does at least fix the testcase.

LGTM.

[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  ---
> The compiler is apparently not prepared for new trapping loads.  Fixing...

No, just a missing check on landing pads:

index a6687cd9c98..4ab8e0250ab 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -2680,6 +2680,7 @@ imm_store_chain_info::coalesce_immediate_stores ()
 p[3] = data;
 using the bswap framework.  */
   if (info->bitpos == merged_store->start + merged_store->width
+ && info->lp_nr == merged_store->lp_nr
  && merged_store->stores.length () == 1
  && merged_store->stores[0]->ins_stmt != NULL
  && info->ins_stmt != NULL)

[Bug middle-end/94715] Squared multiplies are unnecessarily signextended

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
One could use get_range_pos_neg (op0) for that, so something like:
... if (CONVERT_EXPR_CODE_P (code)
&& INTEGRAL_TYPE_P (type)
&& INTEGRAL_TYPE_P (TREE_TYPE (op0))
&& TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (op0))
&& get_range_pos_neg (op0) == 1)
  /* Both sign and zero extension achieve the required extension,
 as the operand is guaranteed not to have the most significant
 bit set.  Try to build both conversions and ask the backend
 which one is less expensive.  If both are same costly, use
 the op0's signedness.  */

[Bug rtl-optimization/94728] [haifa-sched][restore_pattern] recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL

[xuemaosheng at huawei dot com]

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

--- Comment #4 from otcmaf  ---
(In reply to Alexander Monakov from comment #3)
> On the high level the analysis makes sense to me, but as this is predication
> in Haifa scheduler this is not really my domain :)  The bugreport is also
> missing a testcase and information about the target.
> 
> I see the reporter has just sent an email to the gcc@ mailing list, so I'm
> closing the report: https://gcc.gnu.org/pipermail/gcc/2020-April/232192.html

OK! Thanks a lot!

[Bug middle-end/94715] Squared multiplies are unnecessarily signextended

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The GIMPLE transformation is correct and should stay as is.
User could have written int t = x * x; return t; instead.
What you are asking for is a new RTL optimization somewhere (dunno if in
expander, or where else), where e.g. using value ranges from the GIMPLE opts
the middle-end? sees that both sign and zero extension do what needs to be
performed because the value doesn't have msb set, and uses costs to decide
which one is faster.
  # RANGE [0, 2147483647] NONZERO 2147483645
  t_2 = x_1(D) * x_1(D);
  # RANGE [0, 2147483647] NONZERO 2147483645
  _3 = (long long unsigned int) t_2;
So, in this case it could be an optimization done in expand_expr_real_2 in the
CASE_CONVERT: case after the
  else if (modifier == EXPAND_INITIALIZER)
case or so.