[Bug go/90482] [10 regression] Many 32-bit Solaris/SPARC tests FAIL with SIGBUS

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri May 17 05:49:22 2019
New Revision: 271310

URL: https://gcc.gnu.org/viewcvs?rev=271310=gcc=rev
Log:
PR go/90482
compiler: make value method of direct interface type takes pointer

Currently, a value method of a direct interface type takes the
value of the receiver, which is pointer shaped, as the first
parameter. When this method is called through interface, we
actually pass the interface data as a pointer. On most platforms
this is ok, as the underlying calling convention is the same,
except that on SPARC32, the calling convention is actually
different.

This CL changes the method function actually takes a pointer.
The function will convert the pointer to the pointer-shaped
receiver type (a no-op conversion from machine code's aspect).
For a direct call, in the caller we convert the receiver to a
pointer (also no-op conversion) before invoking the method. For
an interface call, we pass the pointer as before. This way, it is
consistent that we always pass a pointer.

Hopefully this fixes SPARC32 build and https://gcc.gnu.org/PR90482.

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

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/expressions.cc
trunk/gcc/go/gofrontend/expressions.h
trunk/gcc/go/gofrontend/gogo.cc
trunk/gcc/go/gofrontend/types.cc

[Bug middle-end/90514] New: Issue about enum type in gcc tree

[JunMa at linux dot alibaba.com]

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

Bug ID: 90514
   Summary: Issue about enum type in gcc tree
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: JunMa at linux dot alibaba.com
  Target Milestone: ---

For case pr23046.c:

enum eumtype { ENUM1, ENUM2 };
void g(const enum eumtype kind );
void f(long i);
void g(const enum eumtype kind)
  {
if ((kind != ENUM1) && (kind != ENUM2))
  f(kind);
  }

 command: gcc -O2  test.c
 and when I dumped kind, I found:

 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x70a93738 precision:32 min  max 
values 
value 
chain 
value >> context
>
visited var 
def_stmt GIMPLE_NOP
version:3>

It looks weird to me, since I think that min/max/precision of TREE_TYPE(kind)
is inverted with TREE_TYPE(TREE_TYPE(kind)).

This cause vrp pass get wrong range info. Also, the code which checks enum type
is out of data.

[Bug target/90513] Pwerplcelfv2 :R2 is not updated to the TOC base .

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin  ---
The mentioned attached case was missed?

[Bug target/90512] New: Pwerplcelfv2 :R2 is not updated to the TOC base .

[umesh.kalappa0 at gmail dot com]

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

Bug ID: 90512
   Summary: Pwerplcelfv2 :R2 is not updated to the  TOC base .
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: umesh.kalappa0 at gmail dot com
  Target Milestone: ---

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

the attached case is failing with segfault  and found that r2 was not updated
with toc base ,since r12 doesn't point to Global entry point for the function
,since its local call (like bl func).

like eric mentioned,its the issue with vxworks kernel module and following fix
in the compiler 

#undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
#define TARGET_ASM_CAN_OUTPUT_MI_THUNK rs6000_can_output_mi_thunk

/* Return true if rs6000_output_mi_thunk would be able to output the
   assembler code for the thunk function specified by the arguments
   it is passed, and false otherwise.  */

static bool
rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT,
const_tree)
{
  /* The only possible issue is for VxWorks in kernel mode.  */
  if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP)
return true;

  /* The loader neither creates the glue code sequence that loads r12 nor uses
 the local entry point for the sibcall's target in the ELFv2 ABI.  */
  return DEFAULT_ABI != ABI_ELFv2;
}

will fix the issue ,but not optimal .

[Bug target/90513] New: Pwerplcelfv2 :R2 is not updated to the TOC base .

[umesh.kalappa0 at gmail dot com]

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

Bug ID: 90513
   Summary: Pwerplcelfv2 :R2 is not updated to the  TOC base .
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: umesh.kalappa0 at gmail dot com
  Target Milestone: ---

the attached case is failing with segfault  and found that r2 was not updated
with toc base ,since r12 doesn't point to Global entry point for the function
,since its local call (like bl func).

like eric mentioned,its the issue with vxworks kernel module and following fix
in the compiler 

#undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
#define TARGET_ASM_CAN_OUTPUT_MI_THUNK rs6000_can_output_mi_thunk

/* Return true if rs6000_output_mi_thunk would be able to output the
   assembler code for the thunk function specified by the arguments
   it is passed, and false otherwise.  */

static bool
rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT,
const_tree)
{
  /* The only possible issue is for VxWorks in kernel mode.  */
  if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP)
return true;

  /* The loader neither creates the glue code sequence that loads r12 nor uses
 the local entry point for the sibcall's target in the ELFv2 ABI.  */
  return DEFAULT_ABI != ABI_ELFv2;
}

will fix the issue ,but not optimal .

[Bug lto/90500] ICE error in copy_forbiden

[neochen.life at aliyun dot com]

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

Guobing  changed:

   What|Removed |Added

 CC||neochen.life at aliyun dot com

--- Comment #9 from Guobing  ---
After applied this patch, I get below errors during compiling with GCC9, while
I expect it should be pass as the same as GCC8.
../sysdeps/ieee754/dbl-64/s_tanh.c:97:247: error: clones for ‘target_clones’
attribute cannot be created
../sysdeps/ieee754/dbl-64/s_tanh.c:97:247: note: ‘target_clones’ cannot be
combined with ‘alias’ attribute
../sysdeps/ieee754/dbl-64/s_tanh.c:97:135: error: clones for ‘target_clones’
attribute cannot be created
../sysdeps/ieee754/dbl-64/s_tanh.c:97:135: note: ‘target_clones’ cannot be
combined with ‘alias’ attribute
../sysdeps/ieee754/dbl-64/s_tanh.c:97:26: error: clones for ‘target_clones’
attribute cannot be created
../sysdeps/ieee754/dbl-64/s_tanh.c:97:26: note: ‘target_clones’ cannot be
combined with ‘alias’ attribute

[Bug lto/90500] ICE error in copy_forbiden

[guobing.chen at intel dot com]

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

Guobing  changed:

   What|Removed |Added

 CC||guobing.chen at intel dot com

--- Comment #8 from Guobing  ---
Hi, I am the original reporter of this bug. This problem seems not happen on
GCC8 while do on GCC9. We try to use FMV (target_clone) for some of the GlibC
libm functions which leads us to this issue. From the Patch below, seems this
fix the GCC9 crash issue but still not allow target_clone to be used together
with alias. But this is allowed in GCC8 as we can compile and run well under
GCC8. So could you help to make the behavior the same as GCC8 or tell us a way
to walkaround it?

[Bug tree-optimization/90270] [8/9/10 Regression] Do not select best induction variable optimization

[rjiejie at me dot com]

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

--- Comment #13 from jojo  ---
Hi, guys,

Any solution for this issue ? 

My be the following patch is choice :) ?

Are there issue with applied this patch ?

--- tree-ssa-loop-ivopts-orig.c 2019-05-17 09:32:58.05200 +0800
+++ tree-ssa-loop-ivopts.c  2019-05-17 09:32:46.50800 +0800
@@ -4513,8 +4513,10 @@
generated invariant expression may not be hoisted out of loop by
following pass.  We penalize the cost by rounding up in order to
neutralize such effects.  */
+  #if 0
   cost.cost = adjust_setup_cost (data, cost.cost, true);
   cost.scratch = cost.cost;
+  #endif
 }

   cost += var_cost;

[Bug c/90511] New: bogus attributes silently accepted before struct or union

[msebor at gcc dot gnu.org]

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

Bug ID: 90511
   Summary: bogus attributes silently accepted before struct or
union
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When the attribute keyword is just before struct and union the GCC front-end
silently accepts any attribute, valid or not:

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic x.c
__attribute__ ((bogus)) struct A { int i; };
__attribute__ ((totally, bogus (with, "arguments"))) union U { int i; };

The C++ front-end issues warnings:

x.c:1:32: warning: attribute ignored in declaration of ‘struct A’
[-Wattributes]
1 | __attribute__ ((bogus)) struct A { int i; };
  |^
x.c:1:32: note: attribute for ‘struct A’ must follow the ‘struct’ keyword
x.c:2:60: warning: attribute ignored in declaration of ‘union U’ [-Wattributes]
2 | __attribute__ ((totally, bogus (with, "arguments"))) union U { int i;
};
  |^
x.c:2:60: note: attribute for ‘union U’ must follow the ‘union’ keyword


Clang does as well:

x.c:1:17: warning: attribute 'bogus' is ignored, place it after "struct" to
  apply attribute to type declaration [-Wignored-attributes]
__attribute__ ((bogus)) struct A { int i; };
^
x.c:2:26: warning: attribute 'bogus' is ignored, place it after "union" to
apply
  attribute to type declaration [-Wignored-attributes]
__attribute__ ((totally, bogus (with, "arguments"))) union U { int i; };
 ^
x.c:2:17: warning: attribute 'totally' is ignored, place it after "union" to
  apply attribute to type declaration [-Wignored-attributes]
__attribute__ ((totally, bogus (with, "arguments"))) union U { int i; };
^
3 warnings generated.

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Thu May 16 23:09:51 2019
New Revision: 271302

URL: https://gcc.gnu.org/viewcvs?rev=271302=gcc=rev
Log:
PR libstdc++/90299 make filesystem::absolute overloads consistent

In this implementation it is an error to pass the empty path to absolute,
because the empty path doesn't represent any file in the filesystem so
the function cannot meet its postcondition.

Currently the absolute(const path&, error_code&) overload reports an
error for the empty path, but using errc::no_such_file_or_directory, and
the other overload does not report an error. This patch makes them
consistntly report an errc::invalid_argument error for the empty path.

Backport from mainline
2019-05-04  Jonathan Wakely  

PR libstdc++/90299
* src/filesystem/std-ops.cc (absolute(const path&)): Report an error
if the argument is an empty path.
(absolute(const path&, error_code&)): Use invalid_argument as error
code instead of no_such_file_or_directory.
* testsuite/27_io/filesystem/operations/absolute.cc: Check handling
of non-existent paths and empty paths with both overloads of absolute.

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/src/filesystem/std-ops.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc

[Bug libstdc++/90509] failing typing std::transform with policies on std::insert_iterator

[maurizio.drocco at pnnl dot gov]

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

--- Comment #4 from Maurizio Drocco  ---
Sorry I was forgetting the requirement, thank you for remarking it.

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.4

--- Comment #9 from Jonathan Wakely  ---
Fixed for GCC 8.4 and 9.2

[Bug libstdc++/90299] std::filesystem::absolute("") and std::filesystem::absolute("", ec) behave differently

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Thu May 16 23:00:26 2019
New Revision: 271301

URL: https://gcc.gnu.org/viewcvs?rev=271301=gcc=rev
Log:
PR libstdc++/90299 make filesystem::absolute overloads consistent

In this implementation it is an error to pass the empty path to absolute,
because the empty path doesn't represent any file in the filesystem so
the function cannot meet its postcondition.

Currently the absolute(const path&, error_code&) overload reports an
error for the empty path, but using errc::no_such_file_or_directory, and
the other overload does not report an error. This patch makes them
consistntly report an errc::invalid_argument error for the empty path.

Backport from mainline
2019-05-04  Jonathan Wakely  

PR libstdc++/90299
* src/c++17/fs_ops.cc (absolute(const path&)): Report an error if the
argument is an empty path.
(absolute(const path&, error_code&)): Use invalid_argument as error
code instead of no_such_file_or_directory.
* testsuite/27_io/filesystem/operations/absolute.cc: Check handling
of non-existent paths and empty paths with both overloads of absolute.

Backport from mainline
2019-05-16  Jonathan Wakely  

* src/c++17/fs_ops.cc (absolute(const path&, error_code&))
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Remove bogus assertion.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/src/c++17/fs_ops.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/absolute.cc

[Bug libstdc++/90509] failing typing std::transform with policies on std::insert_iterator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Yes, and the overload that takes an exeution policy requires forward iterators
for the input range and the output range.

It doesn't matter if you use the sequential policy or not.

[Bug libstdc++/90509] failing typing std::transform with policies on std::insert_iterator

[maurizio.drocco at pnnl dot gov]

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

Maurizio Drocco  changed:

   What|Removed |Added

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

--- Comment #2 from Maurizio Drocco  ---
I am using the sequential version, without policy (working) and with policy
std::execution::seq (not working).

[Bug libstdc++/90509] failing typing std::transform with policies on std::insert_iterator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The parallel version of std::transform requires forward iterators, so this is
not a bug.

https://en.cppreference.com/w/cpp/algorithm/transform

[Bug libstdc++/90509] New: failing typing std::transform with policies on std::insert_iterator

[maurizio.drocco at pnnl dot gov]

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

Bug ID: 90509
   Summary: failing typing std::transform with policies on
std::insert_iterator
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maurizio.drocco at pnnl dot gov
  Target Milestone: ---

Created attachment 46367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46367=edit
source code

The attached code fails to compile due to a typing issue:

gcc/9.1.0/include/c++/9.1.0/pstl/glue_algorithm_impl.h:328:9:
error: invalid parameter type '_OutputType' {aka 'void'}

It looks like the transform with policy relies on the iterator traits to
extract a 'reference' type, that is not defined for insert iterators.



*** how to replicate:
- without execution policies: (working)
g++-9 -Wall -Wextra -std=c++17 -O3 -o transform transform.cc

- with execution policies: (failing)
g++-9 -Wall -Wextra -std=c++17 -O3 -DPOLICY -o transform transform.cc



*** GCC version:
g++-9 -v
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/9.1.0/libexec/gcc/x86_64-apple-darwin18/9.1.0/lto-wrapper
Target: x86_64-apple-darwin18
Configured with: ../configure --build=x86_64-apple-darwin18
--prefix=/usr/local/Cellar/gcc/9.1.0
--libdir=/usr/local/Cellar/gcc/9.1.0/lib/gcc/9 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-9 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC 9.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
gcc version 9.1.0 (Homebrew GCC 9.1.0)

[Bug c/90472] “extern int i;” declaration inside function isn't allowed to shadow “static int i;” at file scope

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
This is not a bug.

If 'i' is not redeclared in an intermediate scope, so the visible 
declaration is one at file scope, the rule that "if the prior declaration 
specifies internal or external linkage, the linkage of the identifier at 
the later declaration is the same as the linkage specified at the prior 
declaration" applies, both declarations have internal linkage and the code 
is valid.

If 'i' is redeclared in an intermediate scope with no linkage 
(function-local variable), the rule that "if the prior declaration 
specifies no linkage, then the identifier has external linkage" applies, 
which means that "If, within a translation unit, the same identifier 
appears with both internal and external linkage, the behavior is 
undefined." also applies, so a diagnostic is permitted (not required) as 
given by GCC.

See C17 6.2.2.  The reference given to 6.7p3 is irrelevant, since that's 
about declarations with no linkage in the same scope, and all declarations 
of 'i' are in different scopes.

[Bug tree-optimization/90510] New: [10 Regression] Unnecessary permutation

[hjl.tools at gmail dot com]

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

Bug ID: 90510
   Summary: [10 Regression] Unnecessary permutation
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86-64, r271153 caused:

[hjl@gnu-cfl-1 pr54855]$ cat 5.i
typedef double __v2df __attribute__ ((__vector_size__ (16)));

__v2df
_mm_add_sd (__v2df x, __v2df y)
{
  __v2df z = { (x[0] + y[0]), x[1] };
  return z;
}
[hjl@gnu-cfl-1 pr54855]$
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2  -S 5.i
[hjl@gnu-cfl-1 pr54855]$  cat 5.s
.file   "5.i"
.text
.p2align 4
.globl  _mm_add_sd
.type   _mm_add_sd, @function
_mm_add_sd:
.LFB0:
.cfi_startproc
movapd  %xmm0, %xmm2
addsd   %xmm1, %xmm2
unpcklpd%xmm2, %xmm2   This isn't needed.
movsd   %xmm2, %xmm0
ret
.cfi_endproc
.LFE0:
.size   _mm_add_sd, .-_mm_add_sd
.ident  "GCC: (GNU) 10.0.0 20190514 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr54855]$ 

instead of

_mm_add_sd:
.LFB0:
.cfi_startproc
movapd  %xmm0, %xmm2
addsd   %xmm1, %xmm2
movsd   %xmm2, %xmm0
ret
.cfi_endproc

[Bug tree-optimization/90510] [10 Regression] Unnecessary permutation

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-16
Version|9.0 |10.0
 Ever confirmed|0   |1

[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 16 21:45:34 2019
New Revision: 271299

URL: https://gcc.gnu.org/viewcvs?rev=271299=gcc=rev
Log:
PR c++/90484
* tree-ssa-scopedtables.c (equal_mem_array_ref_p): Don't assert that
sz0 is equal to sz1, instead return false in that case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-scopedtables.c

[Bug bootstrap/90497] [10 Regression] Broken bootstrap on i686-linux

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Looks good on i686-linux, results in
FAIL: gcc.target/i386/pr90497-2.c (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr90497-2.c:11:10: warning:
implicit declaration of function '__builtin_ia32_pavgusb'; did you mean
'__builtin_ia32_paddusb'? [-Wimplicit-function-declaration]
/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr90497-2.c:11:10: error:
incompatible types when returning type 'int' but '__v8qi' {aka '__vector(8)
char'} was expected
on x86_64-linux, so that test needs some work.

[Bug middle-end/89765] [9/10 Regression] Multiple problems with vec-insert implementation on PowerPC

[kelvin at gcc dot gnu.org]

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

--- Comment #14 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Thu May 16 21:10:32 2019
New Revision: 271297

URL: https://gcc.gnu.org/viewcvs?rev=271297=gcc=rev
Log:
gcc/ChangeLog:

2019-05-16  Kelvin Nilsen  

Backport from mainline.
2019-05-07  Kelvin Nilsen  

PR target/89765
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
In handling of ALTIVEC_BUILTIN_VEC_INSERT, use modular arithmetic
to compute vector element selector for both constant and variable
operands.

gcc/testsuite/ChangeLog:

2019-05-16  Kelvin Nilsen  

Backport from mainline.
2019-05-07  Kelvin Nilsen  

PR target/89765
* gcc.target/powerpc/pr89765-mc.c: New test.
* gcc.target/powerpc/vsx-builtin-10c.c: New test.
* gcc.target/powerpc/vsx-builtin-10d.c: New test.
* gcc.target/powerpc/vsx-builtin-11c.c: New test.
* gcc.target/powerpc/vsx-builtin-11d.c: New test.
* gcc.target/powerpc/vsx-builtin-12c.c: New test.
* gcc.target/powerpc/vsx-builtin-12d.c: New test.
* gcc.target/powerpc/vsx-builtin-13c.c: New test.
* gcc.target/powerpc/vsx-builtin-13d.c: New test.
* gcc.target/powerpc/vsx-builtin-14c.c: New test.
* gcc.target/powerpc/vsx-builtin-14d.c: New test.
* gcc.target/powerpc/vsx-builtin-15c.c: New test.
* gcc.target/powerpc/vsx-builtin-15d.c: New test.
* gcc.target/powerpc/vsx-builtin-16c.c: New test.
* gcc.target/powerpc/vsx-builtin-16d.c: New test.
* gcc.target/powerpc/vsx-builtin-17c.c: New test.
* gcc.target/powerpc/vsx-builtin-17d.c: New test.
* gcc.target/powerpc/vsx-builtin-18c.c: New test.
* gcc.target/powerpc/vsx-builtin-18d.c: New test.
* gcc.target/powerpc/vsx-builtin-19c.c: New test.
* gcc.target/powerpc/vsx-builtin-19d.c: New test.
* gcc.target/powerpc/vsx-builtin-20c.c: New test.
* gcc.target/powerpc/vsx-builtin-20d.c: New test.
* gcc.target/powerpc/vsx-builtin-9c.c: New test.
* gcc.target/powerpc/vsx-builtin-9d.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr89765-mc.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20d.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9c.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9d.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/90458] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
So this is an interaction between stack-clash protection and SEH.   I'm not *at
all* familiar with SEH, though obviously I know a bit about stack clash.

In general on x86 the compiler handles stack allocation (and probing when stack
clash protection is enabled).  However, on Windows targets that stuff is
actually handled by calls to __chkstk_ms.

One could easily argue that stack-clash-protection should be a NOP or generate
an error in a Windows environment.

[Bug c++/90508] New: GCC does not produce full template backtraces when instantiating but not calling virtual functions

[m101010a at gmail dot com]

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

Bug ID: 90508
   Summary: GCC does not produce full template backtraces when
instantiating but not calling virtual functions
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
template  struct a {
virtual b g() { return 0; }
};
template 
void foo() {
a();
}
void bar() {
foo();
}
$ g++ -fsyntax-only x.cpp
x.cpp: In instantiation of ‘b a::g() [with b = void]’:
x.cpp:2:15:   required from here
x.cpp:2:28: error: return-statement with a value, in function returning ‘void’
[-fpermissive]
 virtual b g() { return 0; }
^
$ cat y.cpp
template  struct a {
virtual b g() { return 0; }
};
template 
void foo() {
a().g();
}
void bar() {
foo();
}
$ g++ -fsyntax-only y.cpp
y.cpp: In instantiation of ‘b a::g() [with b = void]’:
y.cpp:6:5:   required from ‘void foo() [with T = void]’
y.cpp:9:15:   required from here
y.cpp:2:28: error: return-statement with a value, in function returning ‘void’
[-fpermissive]
 virtual b g() { return 0; }
^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.3.0 (GCC) 
$ 

Both x.cpp and y.cpp fail to instantiate a::g(), but y.cpp's failure
gives the full template stack whereas x.cpp's failure just gives the location
of g.  This also happens in GCC 9 and trunk.  However, in 7 and below it would
point at the end of the function at the bottom of the template stack (e.g.
x.cpp:10:1 instead of x.cpp:2:15).

[Bug libfortran/90038] execute_command_line should not use fork()

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-05/msg00992.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |jb at gcc dot gnu.org

--- Comment #1 from Janne Blomqvist  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00992.html

[Bug tree-optimization/88440] size optimization of memcpy-like code

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 16 May 2019, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440
> 
> --- Comment #7 from Martin Liška  ---
> (In reply to Richard Biener from comment #6)
> > Created attachment 45313 [details]
> > patch
> > 
> > This enables distribution of patterns at -O[2s]+ and optimizes the testcase
> > at -Os by adjusting the guards in loop distribution.
> > 
> > Note that the interesting bits are compile-time, binary-size and performance
> > at mainly -O2, eventually size at -Os.
> > 
> > I suspect that at -O2 w/o profiling most loops would be
> > optimize_loop_for_speed
> > anyways so changing the heuristics isn't so bad but of course enabling
> > distribution at -O2 might encour a penalty.
> 
> I have so far build numbers on a Zen machine with -j16:
... 
> There's only one difference:
> 
> 521.wrf_r: 310 -> 346s

Ick.  I currently see no limiting on the size of loops in
loop distribution, one easy would be to limit the worklist
size in find_seed_stmts_for_distribution with a --param
we can lower at -O[2s], another thing would be to limit
loop nest depth similarly.

A profile might be interesting here as well...

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

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

[Bug tree-optimization/90507] [10 regression] ICE in gdc.test/runnable/mars1.d test case after r271209

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
dup

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

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[ibuclaw at gdcproject dot org]

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

--- Comment #11 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #8)
> So the first question would be why D passes the return value as
> DECL_BY_REFERENCE if it doesn't have TREE_ADDRESSABLE type.

Looking at the places where DECL_BY_REFERENCE is set, this mismatch could
happen when the result should be returned using NRVO.

To memory, using a mixture of DECL_BY_REFERENCE and CALL_EXPR_RETURN_SLOT_OPT
gives a desired behaviour of eliding a copy.

Two things come to mind as alternatives:

1. Currently for NRVO, the DECL_RESULT is explicitly set as not addressable.

  TREE_TYPE (resdecl) = build_reference_type (TREE_TYPE (resdecl));
  DECL_BY_REFERENCE (resdecl) = 1;
  TREE_ADDRESSABLE (resdecl) = 0;

Is it allowed for the decl to be both DECL_BY_REFERENCE and TREE_ADDRESSABLE at
the same time?  Or will that just confuse things further.

  TREE_TYPE (resdecl) = build_reference_type (TREE_TYPE (resdecl));
  DECL_BY_REFERENCE (resdecl) = 1;
- TREE_ADDRESSABLE (resdecl) = 0;
+ if (TREE_ADDRESSABLE (TREE_TYPE (resdecl))
+   TREE_ADDRESSABLE (resdecl) = 0;


2. Redo handling of NRVO in the D front-end, to enforce a specific semantic for
trivial types that we want to elide a copy for.

i.e: Given,
---
S foo()
{
S result;
result.a = 3;
return result;
}

void test()
{
S s = foo();
}
---

Generate this explicitly as:
---
S* foo(S* hidden)
{
S result;
result.a = 3;
*hidden = result;
return hidden;
}

void test()
{
S tmp;
S s = *foo();
}
---

Obviously, that change would be a bit more involved on my side.

[Bug c++/90505] [9/10 Regression] g++ rejects a valid code

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Seems to be caused by this change:

@@ -16327,15 +16388,6 @@ cp_parser_template_name (cp_parser* parser,
}
 }

-  /* If DECL is dependent, and refers to a function, then just return
- its name; we will look it up again during template instantiation.  */
-  if (DECL_FUNCTION_TEMPLATE_P (decl) || !DECL_P (decl))
-{
-  tree scope = ovl_scope (decl);
-  if (TYPE_P (scope) && dependent_type_p (scope))
-   return identifier;
-}
-
   return decl;
 }

[Bug c++/67184] Missed optimization with C++11 final specifier

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #7 from Paolo Carlini  ---
Seems doable.

[Bug bootstrap/90497] [10 Regression] Broken bootstrap on i686-linux

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #46362|0   |1
is obsolete||

--- Comment #5 from H.J. Lu  ---
Created attachment 46366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46366=edit
A new patch

Please try this.

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #5 from ohaiziejohwahkeezuoz at xff dot cz ---
Since the assertion is in `ld`, I've also reported the issue with some new
details here https://sourceware.org/bugzilla/show_bug.cgi?id=24567

[Bug tree-optimization/88440] size optimization of memcpy-like code

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Richard Biener from comment #6)
> Created attachment 45313 [details]
> patch
> 
> This enables distribution of patterns at -O[2s]+ and optimizes the testcase
> at -Os by adjusting the guards in loop distribution.
> 
> Note that the interesting bits are compile-time, binary-size and performance
> at mainly -O2, eventually size at -Os.
> 
> I suspect that at -O2 w/o profiling most loops would be
> optimize_loop_for_speed
> anyways so changing the heuristics isn't so bad but of course enabling
> distribution at -O2 might encour a penalty.

I have so far build numbers on a Zen machine with -j16:

SPEC2006:

  Elapsed compile for '400.perlbench': 00:00:05 (5)
  Elapsed compile for '401.bzip2': 00:00:02 (2)
  Elapsed compile for '403.gcc': 00:00:11 (11)
  Elapsed compile for '429.mcf': 00:00:01 (1)
  Elapsed compile for '445.gobmk': 00:00:04 (4)
  Elapsed compile for '456.hmmer': 00:00:01 (1)
  Elapsed compile for '458.sjeng': 00:00:01 (1)
  Elapsed compile for '462.libquantum': 00:00:01 (1)
  Elapsed compile for '464.h264ref': 00:00:04 (4)
  Elapsed compile for '471.omnetpp': 00:00:05 (5)
  Elapsed compile for '473.astar': 00:00:01 (1)
  Elapsed compile for '483.xalancbmk': 00:00:21 (21)
  Elapsed compile for '410.bwaves': 00:00:01 (1)
  Elapsed compile for '416.gamess': 00:00:20 (20)
  Elapsed compile for '433.milc': 00:00:02 (2)
  Elapsed compile for '434.zeusmp': 00:00:02 (2)
  Elapsed compile for '435.gromacs': 00:00:06 (6)
  Elapsed compile for '436.cactusADM': 00:00:04 (4)
  Elapsed compile for '437.leslie3d': 00:00:04 (4)
  Elapsed compile for '444.namd': 00:00:09 (9)
  Elapsed compile for '447.dealII': 00:00:15 (15)
  Elapsed compile for '450.soplex': 00:00:03 (3)
  Elapsed compile for '453.povray': 00:00:04 (4)
  Elapsed compile for '454.calculix': 00:00:06 (6)
  Elapsed compile for '459.GemsFDTD': 00:00:09 (9)
  Elapsed compile for '465.tonto': 00:00:53 (53)
  Elapsed compile for '470.lbm': 00:00:02 (2)
  Elapsed compile for '481.wrf': 00:00:38 (38)
  Elapsed compile for '482.sphinx3': 00:00:01 (1)

All differences before and after are withing 1s, which is granularity.

SPEC 2017:

  Elapsed compile for '503.bwaves_r': 00:00:01 (1)
  Elapsed compile for '507.cactuBSSN_r': 00:00:25 (25)
  Elapsed compile for '508.namd_r': 00:00:09 (9)
  Elapsed compile for '510.parest_r': 00:00:46 (46)
  Elapsed compile for '511.povray_r': 00:00:04 (4)
  Elapsed compile for '519.lbm_r': 00:00:01 (1)
  Elapsed compile for '521.wrf_r': 00:05:46 (346)
  Elapsed compile for '526.blender_r': 00:00:25 (25)
  Elapsed compile for '527.cam4_r': 00:00:37 (37)
  Elapsed compile for '538.imagick_r': 00:00:11 (11)
  Elapsed compile for '544.nab_r': 00:00:01 (1)
  Elapsed compile for '549.fotonik3d_r': 00:00:07 (7)
  Elapsed compile for '554.roms_r': 00:00:06 (6)
  Elapsed compile for '500.perlbench_r': 00:00:09 (9)
  Elapsed compile for '502.gcc_r': 00:00:44 (44)
  Elapsed compile for '505.mcf_r': 00:00:01 (1)
  Elapsed compile for '520.omnetpp_r': 00:00:12 (12)
  Elapsed compile for '523.xalancbmk_r': 00:00:25 (25)
  Elapsed compile for '525.x264_r': 00:00:09 (9)
  Elapsed compile for '531.deepsjeng_r': 00:00:02 (2)
  Elapsed compile for '541.leela_r': 00:00:03 (3)
  Elapsed compile for '548.exchange2_r': 00:00:04 (4)
  Elapsed compile for '557.xz_r': 00:00:01 (1)

There's only one difference:

521.wrf_r: 310 -> 346s

[Bug target/58790] [missed optimization] reduction of masks of builtin vectors not transformed to ptest or movemask instructions

[kretz at kde dot org]

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

Matthias Kretz  changed:

   What|Removed |Added

Version|4.9.0   |10.0

--- Comment #2 from Matthias Kretz  ---
Completely different idea how to handle mask reduction and create more
potential for optimization:

Add a new builtin "__builtin_is_zero(x)" which takes any __vector(N) type and
returns true if all bits of x are 0.

none_equal(a, b) { return __builtin_is_zero(a == b); }
all_equal(a, b) { return __builtin_is_zero(~(a == b)); }
any_equal(a, b) { return !__builtin_is_zero(a == b); }
some_equal(a, b) { return !__builtin_is_zero(a == b) && !__bulitin_is_zero(~(a
== b)) }

The x86 backend could then translate those to movmsk or ptest/vtestp[sd].
Examples:
with SSE4:
__builtin_is_zero(x) -> ptest(x, x); return ZF
__builtin_is_zero(~x) -> ptest(x, -1); return CF
__builtin_is_zero(integer < 0) -> ptest(integer, signmask); return ZF
__builtin_is_zero(x & k) -> ptest(x, k); return ZF
__builtin_is_zero(~x & k) -> ptest(x, k); return CF
__builtin_is_zero((integer < 0) & k) -> ptest(integer, signmask & k); return ZF

without SSE4:
__builtin_is_zero(x) -> movmsk(x == 0) == 0
__builtin_is_zero(mask) -> movmsk(mask) == 0  // i.e. when the argument is
known
  // to have only 0 or -1 values
__builtin_is_zero(a == b) -> movmsk(a == b) == 0
__builtin_is_zero(~(a == b)) -> movmsk(a == b) == "full bitmask" // 0x3, 0xf,
0xff, 0x, or 0x depending on the actual movmsk instruction used.

I assume this would make PR90483 a lot more natural to implement.

[Bug c++/90462] Internal compiler error with deprecated-copy and json diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Thanks.

It's attempting to dereference a NULL file when erroneously attempting to
serialize UNKNOWN_LOCATION for the finish_loc of a location range.

Notice how:
  deprecated-copy-crash.cc:43:5: warning: implicitly-declared ‘constexpr G&
G::operator=(const G&)’ is deprecated [-Wdeprecated-copy]
   43 |   a = r();

doesn't have any caret or underlines.


The warning is emitted here at gcc/cp/decl2.c:

5349  warned = warning (opt, "implicitly-declared %qD is
deprecated",
5350decl);

(gdb) p /x input_location
$10 = 0x8003
(gdb) p line_table->location_adhoc_data_map.data[3]
$13 = {locus = 332768, src_range = {m_start = 332704, m_finish = 0}, data =
0x0}

/tmp/pr90462.C: In instantiation of ‘void h< ,
 >::o(const i*, const i*, unsigned int) [with i = char;
 = int]’:
/tmp/pr90462.C:22:5:   required from ‘void b< 
>::assign() [with i = char]’
/tmp/pr90462.C:28:12:   required from ‘s& s
>::p(const i*, const i*, f::g) [with i = char;  =
e; f::g = int]’
/tmp/pr90462.C:45:77:   required from here
/tmp/pr90462.C:43:5: note: caret
   43 |   a = r();
  | ^
(gdb) call inform
(line_table->location_adhoc_data_map.data[3].src_range.m_start, "start")
/tmp/pr90462.C:43:3: note: start
   43 |   a = r();
  |   ^
(gdb) call inform
(line_table->location_adhoc_data_map.data[3].src_range.m_finish, "finish")
cc1plus: note: finish

The unknown finish location is coming from rhs.get_finish () here:

9787  /* Build the assignment expression.  Its default
9788 location:
9789   LHS = RHS
9790   ^
9791 is the location of the '=' token as the
9792 caret, ranging from the start of the lhs to the
9793 end of the rhs.  */
9794  loc = make_location (loc,
9795   expr.get_start (),
9796   rhs.get_finish ());

(gdb) p rhs
$6 = {m_value = , m_loc = 0}

where the underlying CALL_EXPR *does* have a location, but the cp_expr isn't
using it for some reason.

So there are three issues here:
- bulletproofing the JSON output against UNKNOWN_LOCATION for
caret/start/finish of ranges
- bulletproofing the JSON output against a NULL file for an expanded_location
(if this somehow occurs)
- finding and fixing the bad finish location

[Bug lto/90500] ICE error in copy_forbiden

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Fixed.

[Bug tree-optimization/90507] New: [10 regression] ICE in gdc.test/runnable/mars1.d test case after r271209

[seurer at gcc dot gnu.org]

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

Bug ID: 90507
   Summary: [10 regression] ICE in gdc.test/runnable/mars1.d test
case after r271209
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gdc/../../gdc
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gdc/../../ runnable/mars1.d
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never
-I/home/seurer/gcc/gcc-test2/gcc/testsuite/../../libphobos/libdruntime
-I/home/seurer/gcc/gcc-test2/gcc/testsuite/../../libphobos/src
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -O2
-I/home/seurer/gcc/gcc-test2/gcc/testsuite/gdc.test/runnable -S -o mars1.s
In function 'test14782':
d21: error: address taken, but ADDRESSABLE bit not set
PHI argument

for PHI node
_19 = PHI <(2), _20(4)>
during GIMPLE pass: einline
d21: internal compiler error: verify_ssa failed
0x10e0b9cb verify_ssa(bool, bool)
/home/seurer/gcc/gcc-test2/gcc/tree-ssa.c:1193
0x109fd4d3 execute_function_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:1970
0x109fea4b do_per_function
/home/seurer/gcc/gcc-test2/gcc/passes.c:1638
0x109fec63 execute_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:2017

[Bug tree-optimization/90507] [10 regression] ICE in gdc.test/runnable/mars1.d test case after r271209

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64-unknown-linux-gnu
 CC||rguenth at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc64-unknown-linux-gnu
  Build||powerpc64-unknown-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
I saw this on powerpc64 but only on BE both on power 7 and power 8.

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[rguenth at gcc dot gnu.org]

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

--- Comment #38 from Richard Biener  ---
(In reply to Than McIntosh from comment #37)
> (In reply to rguent...@suse.de from comment #36)
> 
> > Thanks for the experiment.  I guess I will limit backporting things
> > to the GCC 9 branch then.  Am I correct that the 2127 seconds are
> > the same regardless of whether r271124 is applied to the branch or not?
> 
> The patch makes things slightly better -- without it the time is 2540
> seconds.

OK, so I am going to backport r270902 and r270940 to fix the introduced
quadraticness and make limiting effective to the GCC 9 branch but not
further since it may uncover other issues through code-gen changes caused
by r270902 and the issue wasn't noticed until now.

I'm considering the other two revs as well but only after some additional
soaking time.

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Richard Biener from comment #7)
> So we are already considering _some_ LHS of return-slot-opt calls as having
> their address taken:
> 
>   if (visit_addr
>   && gimple_call_return_slot_opt_p (call_stmt)
>   && gimple_call_lhs (call_stmt) != NULL_TREE
>   && TREE_ADDRESSABLE (TREE_TYPE (gimple_call_lhs (call_stmt
> ret |= visit_addr (stmt, gimple_call_lhs (call_stmt),
>gimple_call_lhs (call_stmt), data);
> 
> but only those with TREE_ADDRESSABLE type (non-copyable ones).  So not sure
> if the error lies with the D frontend here, I don't remember much around
> the design of the return-slot opt.
> 
> So we can either try to fixup during inlining (we already do for the
> !DECL_BY_REFERENCE case) or we can avoid removing TREE_ADDRESSABLE by
> adjusting the above.
> 
> IIRC at some point build_fold_addr_expr marked the base addressable,
> that might explain the lack of doing this during inlining.
> 
> Index: gcc/tree-inline.c
> ===
> --- gcc/tree-inline.c   (revision 271282)
> +++ gcc/tree-inline.c   (working copy)
> @@ -3540,6 +3540,7 @@ declare_return_variable (copy_body_data
>  taken by alias analysis.  */
>   gcc_assert (TREE_CODE (return_slot) != SSA_NAME);
>   var = return_slot_addr;
> + mark_addressable (return_slot);
> }
>else
> {
> 
> fixes the testcase.

Testing went fine for this (obviously).  Waiting for Iains feedback on the
question from Jakub.  Not sure if we should assert somewhere that the
type of a DECL_BY_REFERENCE decl has to be TREE_ADDRESSABLE (and what that
would break).

[Bug fortran/90506] New: rejects-valid: function with polymorphic return type

[juergen.reuter at desy dot de]

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

Bug ID: 90506
   Summary: rejects-valid: function with polymorphic return type
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

I don't know whether this already has been reported, it was discussed today
(May 16, 2019) on c.l.f. The following valid code is rejected by gfortran:

   13 |   call do_stuff(g_maker)
  |1
Error: Actual argument for 'f_maker' must be ALLOCATABLE at (1)

This is the code:
program test_poly

  implicit none

  type f_t
 real :: a
  end type f_t

  type, extends (f_t) :: g_t
 real :: b
  end type g_t

  call do_stuff(g_maker)

contains

  subroutine do_stuff (f_maker)

interface
   function f_maker () result (f)
 import f_t
 class(f_t), allocatable :: f
   end function f_maker
end interface

class(f_t), allocatable :: f

f = f_maker()

  end subroutine do_stuff

  function g_maker () result (g)

class(f_t), allocatable :: g

g = g_t(a=1.,b=1.)

  end function g_maker

end program test_poly

[Bug lto/90500] ICE error in copy_forbiden

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Fixed on trunk, not planning to backport that.

[Bug libstdc++/90046] [9 Regression] fails to build a epiphany-elf cross toolchain with C++ enabled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

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

[Bug lto/90500] ICE error in copy_forbiden

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu May 16 13:08:48 2019
New Revision: 271289

URL: https://gcc.gnu.org/viewcvs?rev=271289=gcc=rev
Log:
Do not allow target_clones with alias attr (PR lto/90500).

2019-05-16  Martin Liska  

PR lto/90500
* multiple_target.c (expand_target_clones): Do not allow
target_clones being used with a symbol that is an alias.
2019-05-16  Martin Liska  

PR lto/90500
* gcc.target/i386/pr90500-1.c: New test.
* gcc.target/i386/pr90500-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr90500-1.c
trunk/gcc/testsuite/gcc.target/i386/pr90500-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/multiple_target.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88789] epiphany: memory_resource.cc:235:62: error: static assertion failed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
It was reported again and I fixed it that time.

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

[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix, so far just verified on gcc-9-branch that without it it ICEs and
with it it doesn't.

[Bug target/88789] epiphany: memory_resource.cc:235:62: error: static assertion failed

[sebastian.hu...@embedded-brains.de]

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

Sebastian Huber  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||9.1.0
Version|9.0 |9.1.0
 Resolution|--- |FIXED

--- Comment #3 from Sebastian Huber  ---
The GCC 9.1.0 release and the current GCC 10 branch no longer have this issue.

[Bug tree-optimization/90394] [10 Regression] ICE in is_value_included_in, at tree-ssa-uninit.c:1055

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #8 from Alexander Monakov  ---
Should be resolved by Vlad's patch - thanks for the report!

[Bug tree-optimization/90394] [10 Regression] ICE in is_value_included_in, at tree-ssa-uninit.c:1055

[amonakov at gcc dot gnu.org]

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

--- Comment #7 from Alexander Monakov  ---
Author: amonakov
Date: Thu May 16 12:36:33 2019
New Revision: 271287

URL: https://gcc.gnu.org/viewcvs?rev=271287=gcc=rev
Log:
tree-ssa-uninit: avoid ICE with BIT_AND_EXPR (PR 90394)

2019-05-16  Vladislav Ivanishin  

PR tree-optimization/90394
* tree-ssa-uninit.c (is_pred_expr_subset_of): Potentially give false
positives rather than ICE for cases where (code2 == NE_EXPR
&& code1 == BIT_AND_EXPR).

testsuite/
* gcc.dg/uninit-pr90394-1-gimple.c: New test.
* gcc.dg/uninit-pr90394.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/uninit-pr90394-1-gimple.c
trunk/gcc/testsuite/gcc.dg/uninit-pr90394.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-uninit.c

[Bug c++/90505] [9/10 Regression] g++ rejects a valid code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Mine then.

[Bug c++/90505] [9/10 Regression] gcc 9.1 rejects valid code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-16
 CC||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0

--- Comment #1 from Martin Liška  ---
Started with r265734.

[Bug c++/90505] [9/10 Regression] gcc 9.1 rejects valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P2
  Known to work||8.3.0
   Target Milestone|--- |9.2
Summary|gcc 9.1 rejects valid code  |[9/10 Regression] gcc 9.1
   ||rejects valid code

[Bug c++/90484] [9/10 Regression] ICE in equal_mem_array_ref_p at gcc/tree-ssa-scopedtables.c:550 since r270433 on i586

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> I bet the above mentioned commit just tweaked things so that we now compare
> in a hash table something we didn't compare before.
> equal_mem_array_ref_p is called with:
> t0
> MEM[(struct BorderValue *) + 16B].m_isAuto
> with
>   size  bitsizetype> constant 8>
> unit-size  sizetype> constant 1>
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7fffe32ccb28 precision:1 min  max
> >
> type, and
> t1
> MEM[(bool *)this_59(D) + 722B]
> with a const bool type.
> As both types are unsigned integral types with precision 1, they are
> considered compatible.
> But because one is a COMPONENT_REF and m_isAuto is 1-bit bitfield, we get
> sz0 and max0 1-bit (for COMPONENT_REFs we use DECL_SIZE of the FIELD_DECL,
> so 1-bit), while the other is a MEM_REF with bool type and we use mode size
> of the QImode.
> types_compatible_p guarantees that the mode is the same and precision is the
> same, but it doesn't apply we use the mode or precision in both cases.
> 
> So, the
>   /* Types were compatible, so this is a sanity check.  */
>   gcc_assert (known_eq (sz0, sz1));
> looks bogus to me, either we should just punt if the sizes aren't equal, or
> we should ignore the sizes (just remove the assert).

Since we hash the size the correct thing to do is return false for
maybe_ne (sz0, sz1)

> I believe this bug is latent since r232559, before that change it used to
> handle just MEM_REF and ARRAY_REF and for those get_ref_base_and_extent uses
> always the TYPE_SIZE for BLKmode types or mode size otherwise, so for
> types_compatible_p necessarily the same thing.

[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Martin Liška  ---
Reopening..

[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to nsz from comment #8)
> i see
> 
> FAIL: gcc.dg/tree-ssa/pr90478-2.c (internal compiler error)
> 
> on
> 
> aarch64-none-elf, aarch64_be-none-elf, arm-none-eabi
> 
> targets.

Sorry for that. The test-case does not makes sense as it allows basically huge
jump tables by the parameter. That leads to a huge stack allocation here:
  labelvec = XALLOCAVEC (rtx, ncases);

I'm going to remove the test-case.

[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #8 from nsz at gcc dot gnu.org ---
i see

FAIL: gcc.dg/tree-ssa/pr90478-2.c (internal compiler error)

on

aarch64-none-elf, aarch64_be-none-elf, arm-none-eabi

targets.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

--- Comment #35 from Jakub Jelinek  ---
One more thing, if I add to start of the DTRTRI function
  INTERFACE
  SUBROUTINE DTRTI2( UPLO, DIAG, N, A, LDA, INFO )
  CHARACTER  DIAG, UPLO
  INTEGERINFO, LDA, N
  DOUBLE PRECISION   A( LDA, * )
  END SUBROUTINE
  END INTERFACE
  INTERFACE
  SUBROUTINE XERBLA( FOO, BAR )
  CHARACTER  FOO
  INTEGERBAR
  END SUBROUTINE
  END INTERFACE
  INTERFACE
  SUBROUTINE DTRMM ( S1, S2, S3, S4, I1, I2, D1, A, I3, D2, I4 )
  CHARACTER  S1, S2, S3, S4
  INTEGERI1, I2, I3, I4
  DOUBLE PRECISION   D1, D2
  DOUBLE PRECISION   A( I3, * )
  END SUBROUTINE
  END INTERFACE
  INTERFACE
  SUBROUTINE DTRSM ( S1, S2, S3, S4, I1, I2, D1, D2, I3, D3, I4 )
  CHARACTER  S1, S2, S3, S4
  INTEGERI1, I2, I3, I4
  DOUBLE PRECISION   D1, D2, D3
  END SUBROUTINE
  END INTERFACE
  INTERFACE
  FUNCTION LSAME ( S1, S2 )
  CHARACTER  S1, S2
  LOGICALLSAME
  END FUNCTION
  END INTERFACE
  INTERFACE
  FUNCTION ILAENV ( I1, S1, S2, I2, I3, I4, I5 )
  INTEGERI1, I2, I3, I4, I5, ILAENV
  CHARACTER  S1, S2
  END FUNCTION
  END INTERFACE
and remove
  LOGICALLSAME
  INTEGERILAENV
  EXTERNAL   LSAME, ILAENV
  EXTERNAL   DTRMM, DTRSM, DTRTI2, XERBLA
then it is tail call optimized back to somewhere in between r164328 (still
doesn't tail call it) and r164450 (already tail calls it).  What matters is not
whether the exact function/subroutine we are calling in the tail call position
has interface or not, tail call optimization doesn't care about that, but the
presence or absence of TYPE_ARG_TYPES on the function types that are called
matters for the alias analysis (r268991 vs. r268992):
-ESCAPED = uplo
-ESCAPED = 
+callarg(30) = uplo
+callarg(30) = callarg(30) + UNKNOWN
+callarg(30) = *callarg(30) + UNKNOWN
+CALLUSED(28) = callarg(30)
+CALLCLOBBERED(29) = callarg(30)
+*callarg(30) = NONLOCAL
+callarg(31) = 
+callarg(31) = callarg(31) + UNKNOWN
+callarg(31) = *callarg(31) + UNKNOWN
+CALLUSED(28) = callarg(31)
+CALLCLOBBERED(29) = callarg(31)
+*callarg(31) = NONLOCAL
and similarly for many other arguments.  So, if we wanted to narrow the
workaround more, we could do the DECL_HIDDEN_STRING_LENGTH setting conditional
on whether the function has any calls to Fortran implicitly prototyped
function.
Or if we add a command line switch, have different modes, one which would
assume sane callers, another one that would do it only for functions that call
implicitly prototyped functions and another that would do it always like the
committed workaround does.
On the other side, those unprototyped calls could come from inlined calls too,
though as a heuristics it could work, usually the codebase either is modern
fortran, or is not, and given that the workaround is for undefined behavior, we
are always free to do anything we want.

[Bug c++/90505] New: gcc 9.1 rejects valid code

[officesamurai at gmail dot com]

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

Bug ID: 90505
   Summary: gcc 9.1 rejects valid code
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: officesamurai at gmail dot com
  Target Milestone: ---

GCC 9.1 fails to compile the following code (previous versions compile it just
fine).

=== test.cpp ===
template 
struct S
{
template 
static void foo(V)
{
}

void bar()
{
foo(1);
}
};
===

=== Console ===
~/tmp$ g++-9.1.0 -c test.cpp
test.cpp: In member function ‘void S::bar()’:
test.cpp:11:20: error: no matching function for call to ‘S::foo(int)’
   11 | foo(1);
  |^
test.cpp:5:17: note: candidate: ‘template template
static void S::foo(V)’
5 | static void foo(V)
  | ^~~
test.cpp:5:17: note:   template argument deduction/substitution failed:
test.cpp:11:20: note:   mismatched types ‘V’ and ‘int’
   11 | foo(1);
  |   
===

=== Compiler version ===
~/tmp$ g++-9.1.0 -v
Using built-in specs.
COLLECT_GCC=g++-9.1.0
COLLECT_LTO_WRAPPER=/home/brd/soft/gcc-9.1.0/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/brd/soft/gcc-9.1.0
Thread model: posix
gcc version 9.1.0 (GCC) 
===

[Bug driver/90496] ICE in RTL pass pro_and_epilogue when all of `-flto -fsanitize=address -fstack-usage` are used on trivial source

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Eric Botcazou from comment #5)
> > it probably doesn't make sense to print stack usage for compiler-generated
> > functions?  Or at least UNKNOWN_LOCATION should be handled better.
> 
> The latter, the stack usage must be printed for every function if possible.

Then I'm going to send a patch to ML soon.

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #8)
> So the first question would be why D passes the return value as
> DECL_BY_REFERENCE if it doesn't have TREE_ADDRESSABLE type.

I guessed it's optimization (using the wrong machinery?).

[Bug driver/90496] ICE in RTL pass pro_and_epilogue when all of `-flto -fsanitize=address -fstack-usage` are used on trivial source

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> it probably doesn't make sense to print stack usage for compiler-generated
> functions?  Or at least UNKNOWN_LOCATION should be handled better.

The latter, the stack usage must be printed for every function if possible.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

--- Comment #34 from Jakub Jelinek  ---
Even the
subroutine foo (a, b, c, d, e, f)
  integer :: c, e, f
  character(len=1) :: a, b
  double precision :: d (e, *)
  call bar (a, b, c, d, e, f)
end subroutine foo
is tail call optimized by both older gfortran and ifort, and this one has the
same prototype as the lapack routine and so will be broken by both old gfortran
and ifort when called incorrectly without the hidden string length arguments.

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
So the first question would be why D passes the return value as
DECL_BY_REFERENCE if it doesn't have TREE_ADDRESSABLE type.

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
So we are already considering _some_ LHS of return-slot-opt calls as having
their address taken:

  if (visit_addr
  && gimple_call_return_slot_opt_p (call_stmt)
  && gimple_call_lhs (call_stmt) != NULL_TREE
  && TREE_ADDRESSABLE (TREE_TYPE (gimple_call_lhs (call_stmt
ret |= visit_addr (stmt, gimple_call_lhs (call_stmt),
   gimple_call_lhs (call_stmt), data);

but only those with TREE_ADDRESSABLE type (non-copyable ones).  So not sure
if the error lies with the D frontend here, I don't remember much around
the design of the return-slot opt.

So we can either try to fixup during inlining (we already do for the
!DECL_BY_REFERENCE case) or we can avoid removing TREE_ADDRESSABLE by
adjusting the above.

IIRC at some point build_fold_addr_expr marked the base addressable,
that might explain the lack of doing this during inlining.

Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 271282)
+++ gcc/tree-inline.c   (working copy)
@@ -3540,6 +3540,7 @@ declare_return_variable (copy_body_data
 taken by alias analysis.  */
  gcc_assert (TREE_CODE (return_slot) != SSA_NAME);
  var = return_slot_addr;
+ mark_addressable (return_slot);
}
   else
{

fixes the testcase.

[Bug tree-optimization/90488] OpenACC Profiling Interface: callbacks from the OpenACC implementation into user code

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
I filed  "OpenACC Profiling
Interface: callbacks branching out of an OpenACC construct/executable
directive", hoping to get some aspects of this clarified/restricted.


(In reply to my comment #0)
> I suppose this is due to the 'GOACC_parallel_keyed' function (implementing
> the OpenACC 'parallel' construct) being tagged as some kind of "leaf"
> function?  It's not in 'gcc/omp-builtins.def', however.  But indeed, if in
> 'gcc/tree-ssa-structalias.c' I disable the special handling for
> 'BUILT_IN_GOACC_PARALLEL' in function 'find_func_aliases_for_builtin_call'
> or 'ipa_pta_execute', then this example behaves as expected.  (Tom added
> this IPA-PTA handling in late 2015; CCed, in case you have any input.)

What this is doing, per my superficial understanding, is "look through" the
'BUILT_IN_GOACC_PARALLEL' internal-function call, into the attached region. 
Thus it doesn't notice that callbacks now may by triggered by the
'GOACC_parallel_keyed' function, before and after the attached region executes.

[Bug debug/90471] ICE Segmentation fault when compiling with debug info

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Known to work|7.3.0   |8.3.0
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
  Known to fail|8.3.0   |7.3.0

[Bug fortran/90504] New: Improved NORM2 algorithm

[jb at gcc dot gnu.org]

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

Bug ID: 90504
   Summary: Improved NORM2 algorithm
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference
Implementation for Carefully Computing the Euclidean Norm,
https://dl.acm.org/citation.cfm?id=3134441

Above article tests different algorithms for NORM2 and tests performance and
numerical accuracy.

[Bug tree-optimization/90491] simple operation with unsigned long integer and conversion to float not vectorized

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to g.peterhoff from comment #2)

> compile with gcc-9 and -O3 -march=native (avx/avx2 available @ ryzen 2 !)
> -mtune=intel -mno-vzeroupper

You need -mavx512dq to vectorize this.

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-16
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
OK, so the early inliner inlines

  result = fun (); [return slot optimization]

which results in result becoming address-taken after inlining:

static tree
declare_return_variable (copy_body_data *id, tree return_slot, tree
modify_dest,
 basic_block entry_bb)
{
...
  /* If there was a return slot, then the return value is the
 dereferenced address of that object.  */
  if (return_slot)
{
  /* The front end shouldn't have used both return_slot and
 a modify expression.  */
  gcc_assert (!modify_dest);
  if (DECL_BY_REFERENCE (result))
{
  tree return_slot_addr = build_fold_addr_expr (return_slot);
  STRIP_USELESS_TYPE_CONVERSION (return_slot_addr);

  /* We are going to construct *_slot and we can't do that
 for variables believed to be not addressable.

 FIXME: This check possibly can match, because values returned
 via return slot optimization are not believed to have address
 taken by alias analysis.  */
  gcc_assert (TREE_CODE (return_slot) != SSA_NAME);
  var = return_slot_addr;

note this bug was present before my changes with -fno-early-inlining.

Interesting we never hit this for other languages.  I guess most of the
time the addresses end up in places we do not require TREE_ADDRESSABLE
to be set (in dereferences).

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Richard Biener from comment #4)
> (In reply to Iain Buclaw from comment #3)
> > Do you need a minimized test case?
> 
> Hmm, I get
> 
> gcc> make check-d RUNTESTFLAGS="gdc-test.exp=mars1.d"
> ...
> === gdc tests ===
> 
> Schedule of variations:
> unix
> 
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for
> target.
> Using /space/rguenther/src/svn/trunk2/gcc/testsuite/config/default.exp as
> tool-and-target-specific interface file.
> Running /space/rguenther/src/svn/trunk2/gcc/testsuite/gdc.test/gdc-test.exp
> ...
> ERROR: GDC_UNDER_TEST (gdc) does not exist

Ah, it works - typoed --enable-lanugages=d ...

Can reproduce now.

[Bug tree-optimization/90437] Overflow detection too late for VRP

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to JunMa from comment #2)
> (In reply to Richard Biener from comment #1)
> > VRP obviously only sees a + b in [0, 20] and [0, 20] < [0, 10] as unknown.
> 
> we do have pattern x+y < y in match.pd, but it only worked with
> TYPE_OVERFLOW_UNDEFINED. 
> 
> I'm not sure wether we can use range info in match.pd.

We already do via expr_not_equal_to ().

[Bug tree-optimization/90437] Overflow detection too late for VRP

[JunMa at linux dot alibaba.com]

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

JunMa  changed:

   What|Removed |Added

 CC||JunMa at linux dot alibaba.com

--- Comment #2 from JunMa  ---
(In reply to Richard Biener from comment #1)
> VRP obviously only sees a + b in [0, 20] and [0, 20] < [0, 10] as unknown.

we do have pattern x+y < y in match.pd, but it only worked with
TYPE_OVERFLOW_UNDEFINED. 

I'm not sure wether we can use range info in match.pd.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

--- Comment #33 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 16 09:37:43 2019
New Revision: 271285

URL: https://gcc.gnu.org/viewcvs?rev=271285=gcc=rev
Log:
PR fortran/90329
* tree-core.h (struct tree_decl_common): Document
decl_nonshareable_flag for PARM_DECLs.
* tree.h (DECL_HIDDEN_STRING_LENGTH): Define.
* calls.c (expand_call): Don't try tail call if caller
has any DECL_HIDDEN_STRING_LENGTH PARM_DECLs that are or might be
passed on the stack and callee needs to pass any arguments on the
stack.
* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Use
else if instead of series of mutually exclusive ifs.  Handle
DECL_HIDDEN_STRING_LENGTH for PARM_DECLs.
* tree-streamer-out.c (pack_ts_decl_common_value_fields): Likewise.

* trans-decl.c (create_function_arglist): Set
DECL_HIDDEN_STRING_LENGTH on hidden string length PARM_DECLs if
len is constant.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/tree-core.h
trunk/gcc/tree-streamer-in.c
trunk/gcc/tree-streamer-out.c
trunk/gcc/tree.h

Re: mingw-w64 gcc 9.1.0 - cc1plus: internal compiler error: Segmentation fault

[Jonathan Wakely]

On 16/05/19 06:16 +, hien via gcc-bugs wrote:

Hi folks,

I've encounterd a bug with GCC 9.1.0 on the mingw-w64 target.
g++ is built as a cross-compiler running on 64-bit GNU/Linux (glibc 2.29, linux 
5.1.2)...
$ x86_64-w64-mingw32-g++ -v
.//configure --prefix=/usr --target=x86_64-w64-mingw32 
--enable-targets=x86_64-w64-mingw32,mingw32 --with-system-zlib 
--enable-languages=c,c++ --enable-c-mbchar --enable-__cxa_atexit 
--disable-libatomic --disable-libgomp --disable-libmpx --disable-libquadmath 
--disable-libssp --disable-libvtv

Steps to reproduce...

test.cpp:
static void __stdcall func() {}
template  struct foo {  virtual ~foo() {} };

int main() {
 foo x;
 return 0;
}

$ x86_64-w64-mingw32-g++ -Wall -Wextra -pedantic -std=c++11 -m32 test.cpp
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Hello,

This mailing list is for automated emails from our bug database, not
for reporting bugs.

To report a bug please do as GCC suggested and see
https://gcc.gnu.org/bugs/ for instructions.



This happens only with the -m32 flag and __stdcall functions.

Regards,
HY

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Iain Buclaw from comment #3)
> Do you need a minimized test case?

Hmm, I get

gcc> make check-d RUNTESTFLAGS="gdc-test.exp=mars1.d"
...
=== gdc tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /space/rguenther/src/svn/trunk2/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /space/rguenther/src/svn/trunk2/gcc/testsuite/gdc.test/gdc-test.exp ...
ERROR: GDC_UNDER_TEST (gdc) does not exist

how do I run a single testcase?  Building libphobos now to see if

> make check-target-libphobos RUNTESTFLAGS="gdc-test.exp=mars1.d"

works.

[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals

[patrickdepinguin at gmail dot com]

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

--- Comment #17 from Thomas De Schampheleire  ---
Thanks, see:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00922.html

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuclaw at gdcproject dot org

--- Comment #3 from Iain Buclaw  ---
Do you need a minimized test case?

[Bug middle-end/90478] [10 Regression] ICE in emit_case_dispatch_table at gcc/stmt.c:796

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #7 from Christophe Lyon  ---
The second new testcase (pr90478-2.c) fails with an ICE on aarch64 native
bootstrapped compilers (passes with a cross compiler)

FAIL: gcc.dg/tree-ssa/pr90478-2.c (internal compiler error)
FAIL: gcc.dg/tree-ssa/pr90478-2.c (test for excess errors)
Excess errors:
xgcc: internal compiler error: Segmentation fault signal terminated program cc1

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Trying to investigate.

[Bug testsuite/90502] [10 regression] gcc.dg/tree-ssa/vector-6.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug testsuite/90502] [10 regression] gcc.dg/tree-ssa/vector-6.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu May 16 09:12:53 2019
New Revision: 271283

URL: https://gcc.gnu.org/viewcvs?rev=271283=gcc=rev
Log:
2019-05-16  Richard Biener  

PR testsuite/90502
* gcc.dg/tree-ssa/vector-6.c: Adjust for half of the
transforms happening earlier now.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/vector-6.c

[Bug middle-end/90501] [10 regression] ICE: address taken, but ADDRESSABLE bit not set

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
It's probably Richi's issue.

[Bug driver/90496] ICE in RTL pass pro_and_epilogue when all of `-flto -fsanitize=address -fstack-usage` are used on trivial source

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Richard Biener from comment #2)
> Confirmed with GCC 8:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x01ce24bb in unix_lbasename (name=0x0)
> at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:53
> 53   for (base = name; *name; name++)
> (gdb) bt
> #0  0x01ce24bb in unix_lbasename (name=0x0)
> at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:53
> #1  0x01ce2561 in lbasename (name=0x0)
> at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:82
> #2  0x00ef0468 in output_stack_usage ()
> at /space/rguenther/src/svn/gcc-8-branch/gcc/toplev.c:1024
> #3  0x00aef817 in rest_of_handle_thread_prologue_and_epilogue ()
> at /space/rguenther/src/svn/gcc-8-branch/gcc/function.c:6546
> #4  0x00aef865 in (anonymous
> namespace)::pass_thread_prologue_and_epilogue::execute (this=0x2a7a6d0)
> at /space/rguenther/src/svn/gcc-8-branch/gcc/function.c:6576
> 
> where we seem to not consider that a location might have a NULL loc.file:
> 
> (gdb) p debug_tree (current_function_decl)
>   type  type  align:8 warn_if_not_align:0 symtab:0 alias-set -1
> structural-equality
> pointer_to_this >
> QI
> size 
> unit-size 
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
> arg-types  void>>
> pointer_to_this >
> asm_written used static ignored uninlinable QI (null):0:0 align:8
> warn_if_not_align:0 initial 
> result  void>
> VOID (null):0:0
> align:8 warn_if_not_align:0 context  _GLOBAL__sub_I_00099_0_main>>
> struct-function 0x766a3160>
> 
> (gdb) p current_function_decl->decl_minimal.locus 
> $5 = 0
> (gdb) p current_function_decl->decl_common.artificial_flag 
> $6 = 1
> 
> it probably doesn't make sense to print stack usage for compiler-generated
> functions?  Or at least UNKNOWN_LOCATION should be handled better.

Or I'm suggesting to print '(artificial)' as location of the function. One may
be theoretically
interested in the static [cd]tor stack usage.

> 
> Eric?
> 
> Probably not really LTO specific.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[marxin at gcc dot gnu.org]

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

--- Comment #42 from Martin Liška  ---
(In reply to Victor from comment #41)
> (In reply to Martin Liška from comment #40)
> > Fixed on all active branches.
> 
> I can confirm that coverage is working for us compiling gcc from
> gcc-9-branch from https://github.com/gcc-mirror/gcc mirror repository.
> 
> Thanks for the great work!

Glad to hear. I thank you, it was a nice cooperation.

[Bug target/90500] ICE error in copy_forbiden

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-16
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
(In reply to Richard Biener from comment #3)
> We're not really expecting to call
> tree_versionable_function_p/copy_forbidden for a function without a body. 
> So this is an error in the target cloning pass
> somehow looking at the wrong cgraph-node/function?

Issue is that we have an alias with copy attribute, which leads to have
target_clone on an alias. It's invalid. I've got a patch for it.

[Bug testsuite/90502] [10 regression] gcc.dg/tree-ssa/vector-6.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-16
  Component|middle-end  |testsuite
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug target/90503] [10 regression] gcc.target/i386/pr22076.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|testsuite   |target
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Err, the other one.

[Bug testsuite/90503] [10 regression] gcc.target/i386/pr22076.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-16
  Component|target  |testsuite
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
That's mine, failed to adjust the testcase.

[Bug target/90500] ICE error in copy_forbiden

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
We're not really expecting to call tree_versionable_function_p/copy_forbidden
for a function without a body.  So this is an error in the target cloning pass
somehow looking at the wrong cgraph-node/function?

[Bug fortran/90498] [8/9/10 Regression] ICE with select type/associate and derived type argument containing class(*)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
Version|unknown |9.1.0
   Target Milestone|--- |8.4
Summary|[8,9 Regression] ICE with   |[8/9/10 Regression] ICE
   |select type/associate and   |with select type/associate
   |derived type argument   |and derived type argument
   |containing class(*) |containing class(*)

[Bug driver/90496] ICE in RTL pass pro_and_epilogue when all of `-flto -fsanitize=address -fstack-usage` are used on trivial source

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
changes crossed, Eric may still have a preference here.

[Bug driver/90496] ICE in RTL pass pro_and_epilogue when all of `-flto -fsanitize=address -fstack-usage` are used on trivial source

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Confirmed with GCC 8:

Program received signal SIGSEGV, Segmentation fault.
0x01ce24bb in unix_lbasename (name=0x0)
at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:53
53   for (base = name; *name; name++)
(gdb) bt
#0  0x01ce24bb in unix_lbasename (name=0x0)
at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:53
#1  0x01ce2561 in lbasename (name=0x0)
at /space/rguenther/src/svn/gcc-8-branch/libiberty/lbasename.c:82
#2  0x00ef0468 in output_stack_usage ()
at /space/rguenther/src/svn/gcc-8-branch/gcc/toplev.c:1024
#3  0x00aef817 in rest_of_handle_thread_prologue_and_epilogue ()
at /space/rguenther/src/svn/gcc-8-branch/gcc/function.c:6546
#4  0x00aef865 in (anonymous
namespace)::pass_thread_prologue_and_epilogue::execute (this=0x2a7a6d0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/function.c:6576

where we seem to not consider that a location might have a NULL loc.file:

(gdb) p debug_tree (current_function_decl)
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
arg-types >
pointer_to_this >
asm_written used static ignored uninlinable QI (null):0:0 align:8
warn_if_not_align:0 initial 
result 
VOID (null):0:0
align:8 warn_if_not_align:0 context >
struct-function 0x766a3160>

(gdb) p current_function_decl->decl_minimal.locus 
$5 = 0
(gdb) p current_function_decl->decl_common.artificial_flag 
$6 = 1

it probably doesn't make sense to print stack usage for compiler-generated
functions?  Or at least UNKNOWN_LOCATION should be handled better.

Eric?

Probably not really LTO specific.

[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project

[vsande at cimne dot upc.edu]

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

--- Comment #41 from Victor  ---
(In reply to Martin Liška from comment #40)
> Fixed on all active branches.

I can confirm that coverage is working for us compiling gcc from gcc-9-branch
from https://github.com/gcc-mirror/gcc mirror repository.

Thanks for the great work!

[Bug c++/90494] [7/8/9/10 Regression] ICE using a released ssaname

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2
  Component|debug   |c++

--- Comment #2 from Richard Biener  ---
;; Function void localLayer(long int, long int, void*) (null)
;; enabled by -tree-original


{
  float[0:(sizetype) (SAVE_EXPR <(ssizetype) Y + -1>)][0:(sizetype) (SAVE_EXPR
<(ssizetype) X + -1>)] * ary = (float[0:(sizetype) (SAVE_EXPR <(ssizetype) Y +
-1>)][0:(sizetype) (SAVE_EXPR <(ssizetype) X + -1>)] *) region;

  # DEBUG BEGIN STMT;
float[0:(sizetype) (SAVE_EXPR <(ssizetype) Y + -1>)][0:(sizetype)
(SAVE_EXPR <(ssizetype) X + -1>)] * ary = (float[0:(sizetype) (SAVE_EXPR
<(ssizetype) Y + -1>)][0:(sizetype) (SAVE_EXPR <(ssizetype) X + -1>)] *)
region;
  # DEBUG BEGIN STMT;
  <) + 1) * ((sizetype)
(SAVE_EXPR <(ssizetype) Y + -1>) + 1);, (void *) ary;) >;
}


I see no DECL_EXPR for the type -> frontend bug with latent wrong-code before
the cited rev./ICE.

I also believe we have duplicates for this.

[Bug target/90492] simple array-copy not use available simd-registers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target|x86_64-suse-linux   |x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-16
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
Confirmed.  This is probably the generic block-copying (move_by_pieces)
code expanding

  MEM[(char * {ref-all})] = MEM[(char * {ref-all})];

and the target directing it to at most use SSE regs:

/* MOVE_MAX_PIECES is the number of bytes at a time which we can
   move efficiently, as opposed to  MOVE_MAX which is the maximum
   number of bytes we can move with a single instruction.

   ??? We should use TImode in 32-bit mode and use OImode or XImode
   if they are available.  But since by_pieces_ninsns determines the
   widest mode with MAX_FIXED_MODE_SIZE, we can only use TImode in
   64-bit mode.  */
#define MOVE_MAX_PIECES \
  ((TARGET_64BIT \
&& TARGET_SSE2 \
&& TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \
&& TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \
   ? GET_MODE_SIZE (TImode) : UNITS_PER_WORD)

not sure if the MAX_FIXED_MODE_SIZE comment is still valid.

[Bug tree-optimization/90491] simple operation with unsigned long integer and conversion to float not vectorized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-16
 CC||rguenth at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
 Blocks||53947
Summary|simple operation with   |simple operation with
   |unsigned integer and|unsigned long integer and
   |conversion to float/double  |conversion to float not
   |not vectorized  |vectorized
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
The issue is the target claims it has no support for vectorized
unsigned long int to float conversion.  Your int() cast makes it a
signed int to float conversion which is just cvtpd2ps.

What the vectorizer doesn't do but eventually could, with
knowledge of the value-range of i, is first truncate the unsigned long
vector to a unsigned int vector and then do the conversion to float.

Or alternatively use a vector long to vector double and then vector
double to vector float conversion series.

Or the target could hide these tricks from us.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/90503] [10 regression] gcc.target/i386/pr22076.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> Between 20190514 (r271183) and 20190515 (r271254), the
> gcc.target/i386/pr22076.c
> testcase regressed on several x86 targets:
>
> +FAIL: gcc.dg/tree-ssa/vector-6.c scan-tree-dump-times ccp1 "Now a gimple
> register: v" 4

Wrong line, of course:

+FAIL: gcc.target/i386/pr22076.c scan-assembler-times movq 3

[Bug target/90503] [10 regression] gcc.target/i386/pr22076.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0