[Bug ada/91995] gnat miscompilation and bootstrap failure on m68k-linux

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-07
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Ugh.  Defining_Entity is also called from gigi.

[Bug bootstrap/92002] [10 regression] -Wuninitialized warning in gcc/wide-int.cc

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|sparcv9-sun-solaris2.11 |sparcv9-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-07
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Likewise on Linux.

[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Oct  7 07:53:45 2019
New Revision: 276645

URL: https://gcc.gnu.org/viewcvs?rev=276645&root=gcc&view=rev
Log:
2019-10-07  Richard Biener  

PR tree-optimization/91975
* tree-ssa-loop-ivcanon.c (constant_after_peeling): Consistently
handle invariants.

* g++.dg/tree-ssa/ivopts-3.C: Adjust.
* gcc.dg/vect/vect-profile-1.c: Disable cunrolli.
* gcc.dg/vect/vect-double-reduc-6.c: Disable unrolling of
the innermost loop.
* gcc.dg/vect/vect-93.c: Likewise.
* gcc.dg/vect/vect-105.c: Likewise.
* gcc.dg/vect/pr79920.c: Likewise.
* gcc.dg/vect/no-vfa-vect-102.c: Likewise.
* gcc.dg/vect/no-vfa-vect-101.c: Likewise.
* gcc.dg/vect/pr83202-1.c: Operate on a larger array.
* gfortran.dg/vect/vect-8.f90: Likewise.
* gcc.dg/tree-ssa/cunroll-2.c: Scan early unrolling dump instead
of late one.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/ivopts-3.C
trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-2.c
trunk/gcc/testsuite/gcc.dg/vect/no-vfa-vect-101.c
trunk/gcc/testsuite/gcc.dg/vect/no-vfa-vect-102.c
trunk/gcc/testsuite/gcc.dg/vect/pr79920.c
trunk/gcc/testsuite/gcc.dg/vect/pr83202-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-105.c
trunk/gcc/testsuite/gcc.dg/vect/vect-93.c
trunk/gcc/testsuite/gcc.dg/vect/vect-double-reduc-6.c
trunk/gcc/testsuite/gcc.dg/vect/vect-profile-1.c
trunk/gcc/testsuite/gfortran.dg/vect/vect-8.f90
trunk/gcc/tree-ssa-loop-ivcanon.c

[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So in addition to the unrolling heuristics we can see that at -O2 PRE defeats
memcpy detection for g0 and f0 (but PRE does nothing to g1 and f1).  At -O3
PRE avoids this transform because of heuristics enabling vectorization so
loop distribution is happy.  Arguably what PRE does is on the border of being
never useful (and also artificial here because of the visible constant
initializer of T).  Loop distribution has no chance to re-discover the
memcpy here - loop splitting would need to peel off the first iteration
which now reads d[0] = 0 instead of d[0] = s[0]...

[Bug c++/92010] New: gcc internal error since 8x on warning write-strings

[mikolajmm at gmail dot com]

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

Bug ID: 92010
   Summary: gcc internal error since 8x on warning write-strings
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikolajmm at gmail dot com
  Target Milestone: ---

Created attachment 47002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47002&action=edit
internal compiler error with casting const char* to char*

In version 7.4 the code results with warning "warning: ISO C++ forbids
converting a string constant to 'char*' [-Wwrite-strings]"
https://godbolt.org/z/WKFPDA

Since 8.x (tested with all versions available on godbolt, and with 8.3.0 on
local machine - Windows Subsystem for Linux).
Attached file and console output are from local machine - Windows Subsystem for
Linux.


console output:


Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.3.0-6ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--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 8.3.0 (Ubuntu 8.3.0-6ubuntu1) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64 -Wall
-Wextra -fpch-preprocess -fstack-protector-strong -Wformat-security -o bug.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/8
 /usr/include/x86_64-linux-gnu/c++/8
 /usr/include/c++/8/backward
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -fpreprocessed bug.ii -quiet -dumpbase
bug.cpp -mtune=generic -march=x86-64 -auxbase bug -Wall -Wextra -version
-fstack-protector-strong -Wformat-security -o bug.s
GNU C++14 (Ubuntu 8.3.0-6ubuntu1) version 8.3.0 (x86_64-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 8.3.0-6ubuntu1) version 8.3.0 (x86_64-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1110442b7b958f151ae10a1cb5af9032
bug.cpp: In function ‘int main()’:
bug.cpp:8:35: internal compiler error: in tsubst_default_argument, at
cp/pt.c:12712
  TriggerInternalCompilerError();
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug rtl-optimization/91994] [10 Regression] r276327 breaks -mvzeroupper

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon Oct  7 08:36:06 2019
New Revision: 276648

URL: https://gcc.gnu.org/viewcvs?rev=276648&root=gcc&view=rev
Log:
[i386] Make the vzeroupper pattern describe its effects (PR91994)

The problem in this PR was that vzeroupper has an effect on register
contents, but those effects weren't modelled in the rtl pattern,
which was just an unspec_volatile.

This patch fixes that by running a subpass after vzeroupper insertion
to add SETs and CLOBBERs as appropriate.  See the comments in the patch
for more details.

2019-10-07  Richard Sandiford  

gcc/
PR target/91994
* config/i386/sse.md (avx_vzeroupper): Turn into a define_expand
and wrap the unspec_volatile in a parallel.
(*avx_vzeroupper): New define_insn.  Use a match_parallel around
the unspec_volatile.
* config/i386/predicates.md (vzeroupper_pattern): Expect the
unspec_volatile to be wrapped in a parallel.
* config/i386/i386-features.c (ix86_add_reg_usage_to_vzeroupper)
(ix86_add_reg_usage_to_vzerouppers): New functions.
(rest_of_handle_insert_vzeroupper): Use them to add register
usage information to the vzeroupper instructions.

gcc/testsuite/
PR target/91994
* gcc.target/i386/pr91994.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr91994.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c
trunk/gcc/config/i386/predicates.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/91994] [10 Regression] r276327 breaks -mvzeroupper

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Fixed for the reduced testcase.  Please reopen if there's still a problem with
the SPEC test itself.

[Bug fortran/42118] Slow forall

[guez at lmd dot ens.fr]

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

--- Comment #10 from Lionel GUEZ  ---
(In reply to kargl from comment #9)
> Fortran 2018 has declared FORALL to be an obsolescent feature.
> I doubt that anyone will ever try to improve the performance
> of FORALL, because the next standard is likely to delete it.
> 
> I think that this bug can be closed with WONTFIX or WORKSFORME.

OK for me.

[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-07
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|gcc internal error since 8x |[8/9/10 Regression] gcc
   |on warning write-strings|internal error since 8x on
   ||warning write-strings
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r251422.

[Bug c++/92009] [10 Regression] ICE: Segmentation fault (in is_really_empty_class)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-07
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with my r276563, so I'm afraid this is mine.

[Bug fortran/92004] [10 Regression] Rejection of different ranks for dummy array argument where actual argument is an element

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
Version|unknown |10.0
   Target Milestone|--- |10.0

[Bug tree-optimization/92005] [10 Regression] switch code generation regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c++ |tree-optimization

--- Comment #3 from Richard Biener  ---
Switch conversion should probably run late (again?).

[Bug c++/92011] New: '' may be used uninitialized in this function with std::optional()

[joerg.rich...@pdv-fs.de]

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

Bug ID: 92011
   Summary: '' may be used uninitialized in this
function with std::optional()
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

cat > t.cc <

struct Bar
{
int size_;
Bar( int size )
  : size_( size )
{}
};

template
Bar get( T const& val )
{
  return Bar( __builtin_strlen(val) );
}

class Foo
{
int size2_;
  public:
Foo()
{}

template
Foo( T const& t )
  : size2_( get( t ).size_ )
{}
};

enum Enum
{};

bool parseImpl2( Foo s, Enum* val )
{
  *val = Enum();
  for(;;)
  {
s = "aa";
if( true )
  return false;
return true;
  }
}

template std::optional parse2( Foo str )
{
  T res = T();
  if( parseImpl2( str, &res ) )
return res;
  return std::optional();
}

Enum transform()
{
  if( auto r = parse2( Foo() ) )
return *r;
  return {};
}

EOF

gcc -std=c++17 -c -o t.cc.o t.cc -Wall -O1


Gives:
t.cc: In function 'Enum transform()':
t.cc:50:27: warning: '' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   50 |   return std::optional();
  |   ^

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

[Bug c++/92009] [10 Regression] ICE: Segmentation fault (in is_really_empty_class)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
So, cxx_fold_indirect_ref is called with void * as type and &_ZTIi as op0 (with
some casts that are skipped).  Previously, before r276563, it would fail,
because for FIELD_DECLs we would check if the FIELD_DECL's type is similar to
type (it is not) and punt.
_ZTIi has type __fundamental_type_info_pseudo_2, which is a struct containing
(an anonymous) FIELD_DECL with __type_info_pseudo_0 type, which is again a
struct containing some FIELD_DECLs, an anynymous FIELD_DECL with void * type as
the first element.  So, the r276563 code in this case will recurse and find the
void * type in there.  The ICE later on is that constexpr.c code when
evaluating
_ZTIi VAR_DECL with that __fundamental_type_info_pseudo_2 calls
4758  if (COMPLETE_TYPE_P (TREE_TYPE (t))
4759  && is_really_empty_class (TREE_TYPE (t),
/*ignore_vptr*/false))
on it, and is_really_empty_class has:
8449  for (binfo = TYPE_BINFO (type), i = 0;
8450   BINFO_BASE_ITERATE (binfo, i, base_binfo); ++i)
8451if (!is_really_empty_class (BINFO_TYPE (base_binfo),
ignore_vptr))
8452  return false;
While __fundamental_type_info_pseudo_2 has CLASS_TYPE_P flag set (created
through
get_tinfo_desc
1461  /* Create the pseudo type.  */
1462  tree pseudo_type = make_class_type (RECORD_TYPE);
1463  /* Pass the fields chained in reverse.  */
1464  finish_builtin_struct (pseudo_type, pseudo_name, fields, NULL_TREE);
1465  CLASSTYPE_AS_BASE (pseudo_type) = pseudo_type;
it has NULL TYPE_BINFO.

So, shall is_really_empty_class not go through TYPE_BINFO if it is NULL, or
shall get_tinfo_desc fill in TYPE_BINFO, something else?
E.g. following (without needed reindentation) fixes the ICE:

--- gcc/cp/class.c.jj   2019-10-05 09:36:39.244674589 +0200
+++ gcc/cp/class.c  2019-10-07 12:04:04.555012116 +0200
@@ -8446,6 +8446,7 @@ is_really_empty_class (tree type, bool i
   if (!ignore_vptr && TYPE_CONTAINS_VPTR_P (type))
return false;

+  if (TYPE_BINFO (type))
   for (binfo = TYPE_BINFO (type), i = 0;
   BINFO_BASE_ITERATE (binfo, i, base_binfo); ++i)
if (!is_really_empty_class (BINFO_TYPE (base_binfo), ignore_vptr))


Another thing I'm worried about,
namespace std { class type_info {}; }

constexpr bool
foo ()
{
  return ((void **) &typeid (int))[0];
}

constexpr bool x = foo ();
used to be rejected due to the reinterpret_cast in there, but assuming this ICE
is fixed, it is rejected with another reason:
pr92009.C:9:24:   in ‘constexpr’ expansion of ‘foo()’
pr92009.C:9:25: error: the value of ‘_ZTIi’ is not usable in a constant
expression
9 | constexpr bool x = foo ();
  | ^
pr92009.C:6:33: note: ‘_ZTIi’ was not declared ‘constexpr’
6 |   return ((void **) &typeid (int))[0];
  | ^

Now, consider
struct S { void *p; };
struct T { S s; };
constexpr S s = { nullptr };
constexpr T t = { { nullptr } };

constexpr void *
foo ()
{
  return ((void **) &t)[0];
}

constexpr void *
bar ()
{
  return ((void **) &s)[0];
}

constexpr auto x = foo ();
constexpr auto y = bar ();
clang++ rejects here both the foo and bar calls as non-constexpr, as
reinterpret_cast is encountered.  GCC 9 will succeed with cxx_fold_indirect_ref
in the bar case and fail the foo case, so rejects foo, but (incorrectly?)
accepts bar call.  And GCC 10 with the change I've made will accept both. 
Makes me wonder if cxx_eval_indirect_ref shouldn't evaluate the argument as
constant expression no matter if cxx_fold_indirect_ref actually folds it into
something or not, so that what is non-constexpr is really diagnosed as such. 
But am also afraid of what all it will break.

Jason, thoughts on this?

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-07
 CC||iii at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r266734.
Guess CLEANUP_THREADING code isn't prepared to handle hot/cold partitioning,
which wasn't a problem before, when CLEANUP_THREADING was only invoked before
the hot/cold partitions are created.

[Bug rtl-optimization/91860] [10 Regression] ICE: in decompose, at rtl.h:2279 with -Og -fipa-cp -g --param=max-combine-insns=3

[zsojka at seznam dot cz]

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

--- Comment #7 from Zdenek Sojka  ---
Created attachment 47003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47003&action=edit
testcase that does not need any special compiler flag

$ riscv64-unknown-linux-gnu-gcc -O2 -g testcase.c
during RTL pass: combine
testcase.c: In function 'foo':
testcase.c:20:1: internal compiler error: in decompose, at rtl.h:2281
   20 | }
  | ^
0xd9eeb2 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
/repo/gcc-trunk/gcc/rtl.h:2279
0xd9eeb2 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:1022
0xd81e36 generic_wide_int
>::generic_wide_int >(std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:782
0xd81e36 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:1900
0xd8274e simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:868
0xd858b0 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:367
0xd96e17 simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.c:6845
0xd971f8 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
/repo/gcc-trunk/gcc/simplify-rtx.c:6873
0xd989b2 simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def*
(*)(rtx_def*, rtx_def const*, void*), void*)
/repo/gcc-trunk/gcc/simplify-rtx.c:479
0x1083c60 propagate_for_debug(rtx_insn*, rtx_insn*, rtx_def*, rtx_def*,
basic_block_def*)
/repo/gcc-trunk/gcc/valtrack.c:219
0x136555e try_combine
/repo/gcc-trunk/gcc/combine.c:4532
0x136a0c1 combine_instructions
/repo/gcc-trunk/gcc/combine.c:1326
0x136a0c1 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:15056
0x136a0c1 execute
/repo/gcc-trunk/gcc/combine.c:15101
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[nsz at gcc dot gnu.org]

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

--- Comment #7 from nsz at gcc dot gnu.org ---
i think the code snippet i posted is more efficient and significantly
smaller than using libgcc (which also sounds hard to wire up to do the
right thing). the code sequence can possibly be even inlined.
(and i don't mind if ucontrollers with single precision only fpu
don't have correct fenv behaviour)

[Bug rtl-optimization/91994] [10 Regression] r276327 breaks -mvzeroupper

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> Fixed for the reduced testcase.  Please reopen if there's still a problem
> with the SPEC test itself.

Please note that when the testcase from the comment #5 is compiled with
"-march=skylake -O2 -mavx512f", then a vzeroupper before the call to "foo" is
now missing:

bar:
pushq   %rbp
movq%rsp, %rbp
andq$-32, %rsp
subq$32, %rsp
vmovdqa x1(%rip), %ymm0
vmovdqa %ymm0, (%rsp)
callfoo
vmovdqa (%rsp), %ymm0
vmovdqa %ymm0, x3(%rip)
vzeroupper
leave
ret

gcc-9.2.1 compiles the function to:

bar:
pushq   %rbp
movq%rsp, %rbp
andq$-32, %rsp
subq$32, %rsp
vmovdqa x1(%rip), %ymm1
vmovdqa %ymm1, (%rsp)
vzeroupper  < here
callfoo
vmovdqa (%rsp), %ymm1
vmovdqa %ymm1, x3(%rip)
vzeroupper
leave
ret

(I would also expect that %ymm 16+ is uses as a temporary, as it is not
clobbered by a vzeroupper in "foo").

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

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

--- Comment #28 from Stas Sergeev  ---
(In reply to jos...@codesourcery.com from comment #22)
> The build system design is that where A and B are both built at the same 
> time, and the build of B uses A, it should use the *newly built* copy of A 
> as long as that is for _$host = $build_.

Indeed! I missed this "$host = $build" part initially.
When I build djgpp that _runs_ under DOS, then it is not
used during the compilation, as that would simply be impossible.
So such config is already supported.
Is there any way to convince the build system that the
resulting compiler is alien and cannot be used? I think
$host = $build check is just insufficient; there may be
more cases when the resulting compiler can't be used on
a build system, like different prefix.

If there is no such option currently, what do you think
about replacing the
if test "${build}" != "${host}"
with
if test "${build}" != "${host}" -o "$non_native_build"
or something like this?

[Bug target/77918] S390: Floating point comparisons don't raise invalid for unordered operands.

[iii at gcc dot gnu.org]

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

--- Comment #6 from iii at gcc dot gnu.org ---
Author: iii
Date: Mon Oct  7 14:59:00 2019
New Revision: 276659

URL: https://gcc.gnu.org/viewcvs?rev=276659&root=gcc&view=rev
Log:
Allow COND_EXPR and VEC_COND_EXPR condtions to trap

Right now gimplifier does not allow VEC_COND_EXPR's condition to trap
and introduces a temporary if this could happen, for example, generating

  _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
  _6 = VEC_COND_EXPR <_5, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;

from GENERIC

  VEC_COND_EXPR < (*b > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }) ,
  { -1, -1, -1, -1 } ,
  { 0, 0, 0, 0 } >

This is not necessary and makes the resulting GIMPLE harder to analyze.
Change the gimplifier so as to allow COND_EXPR and VEC_COND_EXPR
conditions to trap.

This patch takes special care to avoid introducing trapping comparisons
in GIMPLE_COND.  They are not allowed, because they would require 3
outgoing edges (then, else and EH), which is awkward to say the least.
Therefore, computations of such conditions should live in their own basic
blocks.

gcc/ChangeLog:

2019-10-07  Ilya Leoshkevich  

PR target/77918
* gimple-expr.c (gimple_cond_get_ops_from_tree): Assert that the
caller passes a non-trapping condition.
(is_gimple_condexpr): Allow trapping conditions.
(is_gimple_condexpr_1): New helper function.
(is_gimple_condexpr_for_cond): New function, acts like old
is_gimple_condexpr.
* gimple-expr.h (is_gimple_condexpr_for_cond): New function.
* gimple.c (gimple_could_trap_p_1): Handle COND_EXPR and
VEC_COND_EXPR. Fix an issue with statements like i = (fp < 1.).
* gimplify.c (gimplify_cond_expr): Use
is_gimple_condexpr_for_cond.
(gimplify_expr): Allow is_gimple_condexpr_for_cond.
* tree-eh.c (operation_could_trap_p): Assert on COND_EXPR and
VEC_COND_EXPR.
(tree_could_trap_p): Handle COND_EXPR and VEC_COND_EXPR.
* tree-ssa-forwprop.c (forward_propagate_into_gimple_cond): Use
is_gimple_condexpr_for_cond, remove pointless tmp check
(forward_propagate_into_cond): Remove pointless tmp check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-expr.c
trunk/gcc/gimple-expr.h
trunk/gcc/gimple.c
trunk/gcc/gimplify.c
trunk/gcc/tree-eh.c
trunk/gcc/tree-ssa-forwprop.c

[Bug target/77918] S390: Floating point comparisons don't raise invalid for unordered operands.

[iii at gcc dot gnu.org]

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

--- Comment #7 from iii at gcc dot gnu.org ---
Author: iii
Date: Mon Oct  7 15:01:15 2019
New Revision: 276660

URL: https://gcc.gnu.org/viewcvs?rev=276660&root=gcc&view=rev
Log:
Introduce can_vcond_compare_p function

z13 supports only non-signaling vector comparisons.  This means we
cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
However, we cannot express this restriction today: the code only checks
whether vcond$a$b optab exists, but this does not say anything about the
operation.

Introduce a function that checks whether back-end supports vector
comparisons with individual rtx codes by matching vcond expander's third
argument with a fake comparison with the corresponding rtx code.

gcc/ChangeLog:

2019-10-07  Ilya Leoshkevich  

PR target/77918
* optabs-tree.c (vcond_icode_p): New function.
(vcond_eq_icode_p): Likewise.
(expand_vec_cond_expr_p): Use vcond_icode_p and
vcond_eq_icode_p.
* optabs.c (can_vcond_compare_p): New function.
* optabs.h (can_vcond_compare_p): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs-tree.c
trunk/gcc/optabs.c
trunk/gcc/optabs.h

[Bug c++/92012] New: internal compiler error while using range v3

[voivoid at mail dot ru]

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

Bug ID: 92012
   Summary: internal compiler error while using range v3
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: voivoid at mail dot ru
  Target Milestone: ---

Created attachment 47004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47004&action=edit
preprocessed source

Hi!

There is an internal compiler error while trying to compile the attached
preprocessed file.


gcc (GCC) 9.2.0

Linux 5.3.4-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 5 13:44:11 UTC 2019 x86_64
GNU/Linux


compile with:
g++ -fconcepts -std=c++17 ./testcase.ii


output:
./testcase.ii: In substitution of 'template static constexpr
ranges::_size_::fn::non_member_size_t ranges::_size_::fn::impl_(R&&, long
int) requires  integral)()))> and
!(disable_sized_range::uncvref_t>) [with R = const
ranges::ref_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >&]':
./testcase.ii:98976:42:   required by substitution of 'template
constexpr decltype (ranges::_size_::fn::impl_((R&&)(r), 0))
ranges::_size_::fn::operator()(R&&) const [with R = const
ranges::ref_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >&]'
./testcase.ii:99269:101:   required by substitution of 'template constexpr decltype (__cont.size()) std::size(const _Container&)
[with _Container = ranges::transform_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >,
ranges::detail::get_first>]'
./testcase.ii:98941:53:   required by substitution of 'template using
non_member_size_t = decltype (+ ranges::_size_::size(declval())) [with R =
const ranges::transform_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >,
ranges::detail::get_first>&]'
./testcase.ii:98959:35:   required by substitution of 'template static
constexpr ranges::_size_::fn::non_member_size_t
ranges::_size_::fn::impl_(R&&, long int) requires 
integral)()))> and
!(disable_sized_range::uncvref_t>) [with R = const
ranges::transform_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >,
ranges::detail::get_first>&]'
./testcase.ii:98976:42:   required by substitution of 'template
constexpr decltype (ranges::_size_::fn::impl_((R&&)(r), 0))
ranges::_size_::fn::operator()(R&&) const [with R = const
ranges::transform_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >,
ranges::detail::get_first>&]'
./testcase.ii:99158:47:   [ skipping 15 instantiation contexts, use
-ftemplate-backtrace-limit=0 to disable ]
./testcase.ii:98941:53:   required by substitution of 'template using
non_member_size_t = decltype (+ ranges::_size_::size(declval())) [with R =
ranges::transform_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >,
ranges::detail::get_first>, std::__cxx11::basic_string
std::pair, std::__cxx11::basic_string
>::*>&]'
./testcase.ii:98959:35:   required by substitution of 'template static
constexpr ranges::_size_::fn::non_member_size_t
ranges::_size_::fn::impl_(R&&, long int) requires 
integral)()))> and
!(disable_sized_range::uncvref_t>) [with R =
ranges::transform_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >,
ranges::detail::get_first>, std::__cxx11::basic_string
std::pair, std::__cxx11::basic_string
>::*>&]'
./testcase.ii:98976:42:   required by substitution of 'template
constexpr decltype (ranges::_size_::fn::impl_((R&&)(r), 0))
ranges::_size_::fn::operator()(R&&) const [with R =
ranges::transform_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >,
ranges::detail::get_first>, std::__cxx11::basic_string
std::pair, std::__cxx11::basic_string
>::*>&]'
./testcase.ii:99269:101:   required from
'ranges::detail::to_container::fn::container_t
ranges::detail::to_container::fn::operator()(Rng&&) const requires 
input_range and convertible_to_cont_cont [with
Rng = ranges::transform_view,
std::__cxx11::basic_string >, int,
boost::hash,
std::__cxx11::basic_string > >, {anonymous}::NeighboursMapCmp> >,
ranges::detail::get_first>, std::__cxx11::basic_string
std::pair, std::__cxx11::basic_string
>::*>; ToContainer = ranges::detail::from_range;
ranges::detail::to_container::fn::container_t =
std::vector >]'
./testcase.ii:103467:46:   required from 'constexpr auto
ranges::detail::to_container_closure_base_ns::operator|(Rng&&,
ranges::detail::to_container::closure) [with Rng =
ranges::transform_view,
st

[Bug c++/92012] internal compiler error while using range v3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Quite possibly a duplicate of 91930.

[Bug c++/92013] New: _mm_broadcastsd_pd missing in avx2intrin.h

[DrTroll at gmx dot de]

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

Bug ID: 92013
   Summary: _mm_broadcastsd_pd missing in avx2intrin.h
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: DrTroll at gmx dot de
  Target Milestone: ---

_mm_broadcastsd_pd is missing in avx2intrin.h . It is listed in the intel
intrinsics guide:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_broadcastsd_pd

The following example won't compile with GCC (tried version 8.3 locally and 9.2
online at godbolt):


#include 

__m128d Test(__m128d a)
{
return _mm_broadcastsd_pd(a);
}


In contrast, _mm256_broadcastsd_pd is not missing.

[Bug c++/92013] _mm_broadcastsd_pd missing in avx2intrin.h

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
_mm_broadcastsd_pd is mapped to

MOVDDUP __m128d _mm_movedup_pd (__m128d a);

which is available with SSE3.

[Bug middle-end/92014] New: [10 Regression] bogus warning: writing 8 bytes into a region of size 1 in timezone/zic.c

[msebor at gcc dot gnu.org]

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

Bug ID: 92014
   Summary: [10 Regression] bogus warning: writing 8 bytes into a
region of size 1 in timezone/zic.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Last week's r276603 has introduced a bug into the count_nonzero_bytes function
that leads to a false positive -Wstringop-overflow in glibc's timezone/zic.c. 
The test case below reproduces the bogus warning.

$ cat zic.i && gcc -S -O2 -Wall zic.i
struct
{
  char *s1, *s2;
  char c;
} z;


void f (char **a, int i, int j)
{
  char * cp = __builtin_strchr (a[i], '%');

  if (cp && *++cp != 's')
return;

  z.s1 = __builtin_strdup (a[i]);
  if (!z.s1) __builtin_abort ();

  z.s2 = __builtin_strdup (a[j]);
  if (!z.s2) __builtin_abort ();

  z.c = cp ? *cp : '\0';
}
zic.i: In function ‘f’:
zic.i:21:7: warning: writing 8 bytes into a region of size 1
[-Wstringop-overflow=]
   21 |   z.c = cp ? *cp : '\0';
  |   ^
zic.i:4:8: note: destination object declared here
4 |   char c;
  |^

[Bug middle-end/92014] [10 Regression] bogus warning: writing 8 bytes into a region of size 1 in timezone/zic.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-07
 Blocks||88443
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug c++/92013] _mm_broadcastsd_pd missing in avx2intrin.h

[DrTroll at gmx dot de]

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

--- Comment #2 from DrTroll at gmx dot de ---
@H.J. Lu I am aware, that _mm_broadcastsd_pd does the same as _mm_movedup_pd.
However, maybe others are not. 
The fact that _mm_broadcastsd_pd is listed in the intel intrinsics guide and
won't compile with GCC while all other relevant compilers (Intel, Clang, MSVC -
tested all on Godbolt) accept it is probably suboptimal.

[Bug c++/92015] New: internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568

[ed at catmur dot uk]

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

Bug ID: 92015
   Summary: internal compiler error: in cxx_eval_array_reference,
at cp/constexpr.c:2568
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

when indexing a char array initialized from a string literal in constexpr
context:

struct S1 { char c[6] {'h', 'e', 'l', 'l', 'o', 0}; };
struct S2 { char c[6] = "hello"; };
static_assert(S1{}.c[0] == 'h');// OK
static_assert(S2{}.c[0] == 'h');// ICE

Expected: both static_asserts pass.

According to Godbolt, this ICE was introduced between 8.3 and 9.1, and is still
present in 10.0.

[Bug c++/92015] [9/10 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-07
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.3
Summary|internal compiler error: in |[9/10 Regression] internal
   |cxx_eval_array_reference,   |compiler error: in
   |at cp/constexpr.c:2568  |cxx_eval_array_reference,
   ||at cp/constexpr.c:2568
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r267272.

[Bug ipa/60243] IPA is slow on large cgraph tree

[jamborm at gcc dot gnu.org]

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

--- Comment #26 from Martin Jambor  ---
With new IPA-SRA, the situation has improved quite a bit, see below
where old-ipa-sra is trunk r275981 and new-ipa-sra is trunk r275982
(arrival of new IPA-SRA):

$ /usr/bin/time -f 'real=%e user=%U' taskset -c 0
~/gcc/old-ipa-sra/inst/bin/gcc -O0 -fno-inline -S pr60243.c
real=64.20 user=63.37

$ /usr/bin/time -f 'real=%e user=%U' taskset -c 0
~/gcc/old-ipa-sra/inst/bin/gcc -O1 -fno-inline -S pr60243.c 
real=90.80 user=89.84

$ /usr/bin/time -f 'real=%e user=%U' taskset -c 0
~/gcc/old-ipa-sra/inst/bin/gcc -O2 -S pr60243.c 
real=235.18 user=233.77

$ /usr/bin/time -f 'real=%e user=%U' taskset -c 0
~/gcc/old-ipa-sra/inst/bin/gcc -O2 -fno-inline -S pr60243.c 
real=198.59 user=197.27

$ /usr/bin/time -f 'real=%e user=%U' taskset -c 0
~/gcc/new-ipa-sra/inst/bin/gcc -O2 -S pr60243.c 
real=114.68 user=113.76

$ /usr/bin/time -f 'real=%e user=%U' taskset -c 0
~/gcc/new-ipa-sra/inst/bin/gcc -O2 -fno-inline -S pr60243.c 
real=88.40 user=87.41


$ taskset -c 0 ~/gcc/new-ipa-sra/inst/bin/gcc -O2 -S pr60243.c -ftime-report
(showing only IPA passes and passes taking more than 1% of usr time)
 phase parsing  :   9.57 (  8%)   6.93 ( 75%)  16.51 ( 13%)
 655448 kB ( 20%)
 phase opt and generate : 105.13 ( 92%)   2.34 ( 25%) 107.83 ( 87%)
2619926 kB ( 80%)
 callgraph functions expansion  :  18.05 ( 16%)   1.34 ( 14%)  19.71 ( 16%)
 302442 kB (  9%)
 callgraph ipa passes   :  77.51 ( 68%)   0.50 (  5%)  78.06 ( 63%)
 623696 kB ( 19%)
 ipa function summary   :   0.15 (  0%)   0.01 (  0%)   0.16 (  0%)
   1494 kB (  0%)
 ipa dead code removal  :   0.32 (  0%)   0.00 (  0%)   0.29 (  0%)
  0 kB (  0%)
 ipa cp :   1.10 (  1%)   0.05 (  1%)   1.13 (  1%)
 326688 kB ( 10%)
 ipa inlining heuristics:  17.85 ( 16%)   0.06 (  1%)  17.82 ( 14%)
  83762 kB (  3%)
 ipa function splitting :   0.00 (  0%)   0.00 (  0%)   0.03 (  0%)
  0 kB (  0%)
 ipa various optimizations  :   0.63 (  1%)   0.28 (  3%)   0.96 (  1%)
 131752 kB (  4%)
 ipa reference  :   0.06 (  0%)   0.00 (  0%)   0.06 (  0%)
  0 kB (  0%)
 ipa profile:  14.66 ( 13%)   0.00 (  0%)  14.67 ( 12%)
  0 kB (  0%)
 ipa pure const :   0.36 (  0%)   0.04 (  0%)   0.60 (  0%)
  0 kB (  0%)
 ipa icf:   0.17 (  0%)   0.01 (  0%)   0.19 (  0%)
  0 kB (  0%)
 ipa SRA:   0.21 (  0%)   0.00 (  0%)   0.23 (  0%)
102 kB (  0%)
 ipa free inline summary:   0.05 (  0%)   0.00 (  0%)   0.04 (  0%)
  0 kB (  0%)
 preprocessing  :   4.20 (  4%)   3.31 ( 36%)   7.77 (  6%)
 384133 kB ( 12%)
 lexical analysis   :   2.46 (  2%)   1.80 ( 19%)   3.95 (  3%)
  0 kB (  0%)
 parser function body   :   2.71 (  2%)   1.82 ( 20%)   4.57 (  4%)
 269874 kB (  8%)
 early inlining heuristics  :  12.82 ( 11%)   0.03 (  0%)  12.71 ( 10%)
   4031 kB (  0%)
 inline parameters  :   8.01 (  7%)   0.12 (  1%)   8.27 (  7%)
  30845 kB (  1%)
 tree CFG construction  :   5.23 (  5%)   0.04 (  0%)   5.03 (  4%)
 628095 kB ( 19%)
 tree SSA rewrite   :   3.42 (  3%)   0.02 (  0%)   3.39 (  3%)
  93305 kB (  3%)
 tree operand scan  :  17.53 ( 15%)   0.26 (  3%)  17.77 ( 14%)
  96568 kB (  3%)

Essentially, -O2 -fno-inline is now as fast as -O1 -fno-inline.

[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"

[chinoune.mehdi at hotmail dot com]

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

Chinoune  changed:

   What|Removed |Added

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

--- Comment #10 from Chinoune  ---
Thanks for fixing.

[Bug middle-end/92016] New: excess errors in Wstringop-overflow-17.c

[msebor at gcc dot gnu.org]

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

Bug ID: 92016
   Summary: excess errors in Wstringop-overflow-17.c
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The recently added gcc.dg/Wstringop-overflow-17.c test shows excess errors:
FAIL: gcc.dg/Wstringop-overflow-17.c (test for excess errors)

E.g.: https://gcc.gnu.org/ml/gcc-testresults/2019-10/msg00450.html

The output shows that the exact same warning is repeated for each past-the-end
write by the test (made in a loop).  This is  most likely the result of the
even more recent optimization improvement in r276645 (pr91975).  The warning is
correct but the output too noisy.  It would be much better to emit just a
single instance for all the invalid accesses.

In function ‘copy_n’,
inlined from ‘call_copy_n’ at gcc.dg/Wstringop-overflow-17.c:18:3:
gcc.dg/Wstringop-overflow-17.c:9:10: warning: writing 1 byte into a region of
size 0 [-Wstringop-overflow=]
9 | *d++ = *s++;
  | ~^~
gcc.dg/Wstringop-overflow-17.c: In function ‘call_copy_n’:
gcc.dg/Wstringop-overflow-17.c:17:8: note: destination object declared here
   17 |   char a[3];// { dg-message "destination object declared here"
}
  |^
In function ‘copy_n’,
inlined from ‘call_copy_n’ at gcc.dg/Wstringop-overflow-17.c:18:3:
gcc.dg/Wstringop-overflow-17.c:9:10: warning: writing 1 byte into a region of
size 0 [-Wstringop-overflow=]
9 | *d++ = *s++;
  | ~^~
gcc.dg/Wstringop-overflow-17.c: In function ‘call_copy_n’:
gcc.dg/Wstringop-overflow-17.c:17:8: note: destination object declared here
   17 |   char a[3];// { dg-message "destination object declared here"
}
  |^
In function ‘copy_n’,
inlined from ‘call_copy_n’ at gcc.dg/Wstringop-overflow-17.c:18:3:
gcc.dg/Wstringop-overflow-17.c:9:10: warning: writing 1 byte into a region of
size 0 [-Wstringop-overflow=]
9 | *d++ = *s++;
  | ~^~
gcc.dg/Wstringop-overflow-17.c: In function ‘call_copy_n’:
gcc.dg/Wstringop-overflow-17.c:17:8: note: destination object declared here
   17 |   char a[3];// { dg-message "destination object declared here"
}
  |^
In function ‘copy_n’,
inlined from ‘call_copy_n’ at gcc.dg/Wstringop-overflow-17.c:18:3:
gcc.dg/Wstringop-overflow-17.c:9:10: warning: writing 1 byte into a region of
size 0 [-Wstringop-overflow=]
9 | *d++ = *s++;
  | ~^~
gcc.dg/Wstringop-overflow-17.c: In function ‘call_copy_n’:
gcc.dg/Wstringop-overflow-17.c:17:8: note: destination object declared here
   17 |   char a[3];// { dg-message "destination object declared here"
}
  |^
In function ‘copy_n’,
inlined from ‘call_copy_n’ at gcc.dg/Wstringop-overflow-17.c:18:3:
gcc.dg/Wstringop-overflow-17.c:10:6: warning: writing 1 byte into a region of
size 0 [-Wstringop-overflow=]
   10 |   *d = 0;   // { dg-warning "writing 1 byte into a region of
size 0" }
  |   ~~~^~~
gcc.dg/Wstringop-overflow-17.c: In function ‘call_copy_n’:
gcc.dg/Wstringop-overflow-17.c:17:8: note: destination object declared here
   17 |   char a[3];// { dg-message "destination object declared here"
}
  |^

[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Oct  7 18:23:20 2019
New Revision: 276667

URL: https://gcc.gnu.org/viewcvs?rev=276667&root=gcc&view=rev
Log:
[gcc]

2019-10-07  Bill Schmidt  

Backport from mainline
2019-10-01  Bill Schmidt  

PR target/91275
* config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Don't swap
vpmsumd.

[gcc/testsuite]

2019-10-07  Bill Schmidt  

Backport from mainline
2019-10-01  Bill Schmidt  

PR target/91275
* gcc.target/powerpc/pr91275.c: New.


Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/powerpc/pr91275.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/rs6000/rs6000-p8swap.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/92011] '' may be used uninitialized in this function with std::optional()

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80635

--- Comment #1 from Martin Sebor  ---
Is this a dupe of bug 80635?

[Bug fortran/92017] New: ICE in gfc_expr_attr, at fortran/primary.c:2674

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

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

Bug ID: 92017
   Summary: ICE in gfc_expr_attr, at fortran/primary.c:2674
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Starting with gfortran-8 :


$ cat z1.f90
program p
   character(3), parameter :: a(4) = 'abc'
   integer, parameter :: b(1) = minloc(a)
   integer, parameter :: c = minloc(a, dim=1)
end


$ cat z2.f90
program p
   character(3), parameter :: a(4) = 'abc'
   integer, parameter :: b(1) = maxloc(a)
   integer, parameter :: c = maxloc(a, dim=1)
end


$ gfortran-10-20191006 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb5d4ef crash_signal
../../gcc/toplev.c:326
0x684278 gfc_expr_attr(gfc_expr*)
../../gcc/fortran/primary.c:2674
0x62516a gfc_extract_hwi(gfc_expr*, long*, int)
../../gcc/fortran/expr.c:698
0x6ae218 init_result_expr
../../gcc/fortran/simplify.c:329
0x6ae65e gfc_simplify_minmaxloc
../../gcc/fortran/simplify.c:5430
0x637a4f do_simplify
../../gcc/fortran/intrinsic.c:4574
0x64209e gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4942
0x699e61 resolve_unknown_f
../../gcc/fortran/resolve.c:2894
0x699e61 resolve_function
../../gcc/fortran/resolve.c:3231
0x696275 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6967
0x627ea4 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:3048
0x62b020 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:3096
0x617093 variable_decl
../../gcc/fortran/decl.c:2841
0x617093 gfc_match_data_decl()
../../gcc/fortran/decl.c:6087
0x6780c3 match_word
../../gcc/fortran/parse.c:65
0x6780c3 decode_statement
../../gcc/fortran/parse.c:376
0x679b0a next_free
../../gcc/fortran/parse.c:1263
0x679b0a next_statement
../../gcc/fortran/parse.c:1495
0x67b12b parse_spec
../../gcc/fortran/parse.c:3893
0x67df1c parse_progunit
../../gcc/fortran/parse.c:5812

[Bug fortran/92018] New: ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370

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

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

Bug ID: 92018
   Summary: ICE in gfc_conv_constant_to_tree, at
fortran/trans-const.c:370
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Follow-up of pr91943 :


$ cat z1.f90
subroutine sub (f)
   integer :: f
   print *, f(b'11')
   print *, f(o'11')
   print *, f(z'11')
end


$ gfortran-10-20191006 -c z1.f90
z1.f90:3:0:

3 |print *, f(b'11')
  |
internal compiler error: in gfc_conv_constant_to_tree, at
fortran/trans-const.c:370
0x6e9ab5 gfc_conv_constant_to_tree(gfc_expr*)
../../gcc/fortran/trans-const.c:370
0x6e9c17 gfc_conv_constant(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-const.c:422
0x6fd65a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8644
0x7040e5 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:8785
0x7060ba gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.c:5898
0x70a36c gfc_conv_function_expr
../../gcc/fortran/trans-expr.c:7536
0x6fd64a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8640
0x7040e5 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:8785
0x72c747 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2582
0x6cd527 trans_code
../../gcc/fortran/trans.c:2072
0x72a22e build_dt
../../gcc/fortran/trans-io.c:2026
0x6cd507 trans_code
../../gcc/fortran/trans.c:2044
0x6f65d4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6790
0x67fcb6 translate_all_program_units
../../gcc/fortran/parse.c:6266
0x67fcb6 gfc_parse_file()
../../gcc/fortran/parse.c:6505
0x6c9d0f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:206

[Bug fortran/92019] New: [10 Regression] ICE in find_inquiry_ref, at expr.c:1790

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

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

Bug ID: 92019
   Summary: [10 Regression] ICE in find_inquiry_ref, at
expr.c:1790
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Errors in z4/z3 are detected, z2 is silently accepted and z1 ICEs :
(also with a(z'1'))


$ cat z4.f90
program p
   character, parameter :: a(2) = 'a'
   integer :: b = a(3)%kind
end

$ gfortran-10-20191006 -c z4.f90
z4.f90:3:20:

3 |integer :: b = a(3)%kind
  |1
Warning: Array reference at (1) is out of bounds (3 > 2) in dimension 1

---

$ cat z3.f90
program p
   character, parameter :: a(2) = 'a'
   integer :: b = a(z'3')
end

$ gfortran-10-20191006 -c z3.f90
z3.f90:3:20:

3 |integer :: b = a(z'3')
  |1
Error: Array index at (1) must be of INTEGER type, found BOZ

---

$ cat z2.f90
program p
   character, parameter :: a(2) = 'a'
   integer :: b = a(z'3')%kind
   print *, b
end

$ gfortran-10-20191006 z2.f90 && ./a.out
   1

---

$ cat z1.f90
program p
   character, parameter :: a(2) = 'a'
   integer :: b = a(z'3')%len
end


$ gfortran-9 -c z1.f90
z1.f90:3:20:

3 |integer :: b = a(z'3')%len
  |1
Warning: Array reference at (1) is out of bounds (3 > 2) in dimension 1


$ gfortran-10-20191006 -c z1.f90
f951: internal compiler error: Segmentation fault
0xcdaddf crash_signal
../../gcc/toplev.c:326
0x64f4af find_inquiry_ref
../../gcc/fortran/expr.c:1790
0x6528cd simplify_ref_chain
../../gcc/fortran/expr.c:2023
0x65202d gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2227
0x6527cc simplify_parameter_variable
../../gcc/fortran/expr.c:2072
0x6525cd gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.c:2209
0x6ad18f gfc_match_varspec(gfc_expr*, int, bool, bool)
../../gcc/fortran/primary.c:2337
0x6aec2e gfc_match_rvalue(gfc_expr**)
../../gcc/fortran/primary.c:3484
0x68562e match_primary
../../gcc/fortran/matchexp.c:157
0x68562e match_level_1
../../gcc/fortran/matchexp.c:211
0x68562e match_mult_operand
../../gcc/fortran/matchexp.c:267
0x685878 match_add_operand
../../gcc/fortran/matchexp.c:356
0x685acc match_level_2
../../gcc/fortran/matchexp.c:480
0x685c22 match_level_3
../../gcc/fortran/matchexp.c:551
0x685d14 match_level_4
../../gcc/fortran/matchexp.c:599
0x685d14 match_and_operand
../../gcc/fortran/matchexp.c:693
0x685f02 match_or_operand
../../gcc/fortran/matchexp.c:722
0x685fd2 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x6860a4 match_level_5
../../gcc/fortran/matchexp.c:811
0x685481 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.c:870

[Bug rtl-optimization/91994] [10 Regression] r276327 breaks -mvzeroupper

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak  ---
Richard, since vzeroupper clobbers only xmm0-xmm15 (xmm0-xmm7 on 32it targets),
shouldn't we use SSE_REGS instead of ALL_SSE_REGS here:

Index: i386.c
===
--- i386.c  (revision 276660)
+++ i386.c  (working copy)
@@ -13530,7 +13530,7 @@ ix86_avx_u128_mode_needed (rtx_insn *insn)
 modes wider than 256 bits.  It's only safe to issue a
 vzeroupper if all SSE registers are clobbered.  */
   const function_abi &abi = insn_callee_abi (insn);
-  if (!hard_reg_set_subset_p (reg_class_contents[ALL_SSE_REGS],
+  if (!hard_reg_set_subset_p (reg_class_contents[SSE_REGS],
  abi.mode_clobbers (V4DImode)))
return AVX_U128_ANY;

[Bug c++/92001] missing -Wclass-memaccess with array as first argument to memset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-07
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Looks like a trivial oversight.   Thanks for pointing it out!

[Bug tree-optimization/90839] Detect lsb ones counting loop (final value replacement?)

[dpochepk at gmail dot com]

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

--- Comment #4 from Dmitrij Pochepko  ---
(In reply to Andrew Pinski from comment #3)
> ...

I haven't tracked deepsjeng data passed for logL function specifically. I only
measured totals. It might be not directly related to logL code execution time.

I also measured separate synthetic benchmarks with loop-based and
non-loop-based implementations (simple logL function calculation in a loop with
adding result into accumulator). For 0 and 1 arguments I see about 2% slower
numbers with synthetic benchmark on T99. Hope this info will help to anyone
who'll decide to work on this patch.

Re: [Bug rtl-optimization/91994] [10 Regression] r276327 breaks -mvzeroupper

[Richard Sandiford]

"ubizjak at gmail dot com"  writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91994
>
> --- Comment #10 from Uroš Bizjak  ---
> Richard, since vzeroupper clobbers only xmm0-xmm15 (xmm0-xmm7 on 32it 
> targets),
> shouldn't we use SSE_REGS instead of ALL_SSE_REGS here:
>
> Index: i386.c
> ===
> --- i386.c  (revision 276660)
> +++ i386.c  (working copy)
> @@ -13530,7 +13530,7 @@ ix86_avx_u128_mode_needed (rtx_insn *insn)
>  modes wider than 256 bits.  It's only safe to issue a
>  vzeroupper if all SSE registers are clobbered.  */
>const function_abi &abi = insn_callee_abi (insn);
> -  if (!hard_reg_set_subset_p (reg_class_contents[ALL_SSE_REGS],
> +  if (!hard_reg_set_subset_p (reg_class_contents[SSE_REGS],
>   abi.mode_clobbers (V4DImode)))
> return AVX_U128_ANY;

Ah, yeah.  LGTM, thanks.

[Bug rtl-optimization/91994] [10 Regression] r276327 breaks -mvzeroupper

[richard.sandiford at arm dot com]

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

--- Comment #11 from richard.sandiford at arm dot com ---
"ubizjak at gmail dot com"  writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91994
>
> --- Comment #10 from Uroš Bizjak  ---
> Richard, since vzeroupper clobbers only xmm0-xmm15 (xmm0-xmm7 on 32it 
> targets),
> shouldn't we use SSE_REGS instead of ALL_SSE_REGS here:
>
> Index: i386.c
> ===
> --- i386.c  (revision 276660)
> +++ i386.c  (working copy)
> @@ -13530,7 +13530,7 @@ ix86_avx_u128_mode_needed (rtx_insn *insn)
>  modes wider than 256 bits.  It's only safe to issue a
>  vzeroupper if all SSE registers are clobbered.  */
>const function_abi &abi = insn_callee_abi (insn);
> -  if (!hard_reg_set_subset_p (reg_class_contents[ALL_SSE_REGS],
> +  if (!hard_reg_set_subset_p (reg_class_contents[SSE_REGS],
>   abi.mode_clobbers (V4DImode)))
> return AVX_U128_ANY;

Ah, yeah.  LGTM, thanks.

[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Oct  7 19:34:41 2019
New Revision: 276669

URL: https://gcc.gnu.org/viewcvs?rev=276669&root=gcc&view=rev
Log:
[gcc]

2019-10-07  Bill Schmidt  

Backport from mainline
2019-10-01  Bill Schmidt  

PR target/91275
* config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Don't swap
vpmsumd.

[gcc/testsuite]

2019-10-07  Bill Schmidt  

Backport from mainline
2019-10-01  Bill Schmidt  

PR target/91275
* gcc.target/powerpc/pr91275.c: New.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr91275.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/rs6000/rs6000-p8swap.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/91829] compatibility.cc: syntax error lea (%pc, _GLOBAL_OFFSET_TABLE@GOTPC), a4 ignored

[jopadan at zohomail dot eu]

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

--- Comment #3 from Jon Daniel  ---

replacing
`return "lea (%%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %0";`
with
`return "lea (%%pc, #_GLOBAL_OFFSET_TABLE_@GOTPC), %0";`

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

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

--- Comment #27 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Oct  7 20:10:22 2019
New Revision: 276672

URL: https://gcc.gnu.org/viewcvs?rev=276672&root=gcc&view=rev
Log:
2019-10-07  Thomas Koenig 

Backport from trunk
PR fortran/84487
* trans-decl.c (gfc_get_symbol_decl): For __def_init, set
DECL_ARTIFICAL and do not set TREE_READONLY.

2019-10-07  Thomas Koenig 

Backport from trunk
PR fortran/84487
* gfortran.dg/typebound_call_22.f03: xfail.


Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-decl.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/typebound_call_22.f03

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

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

--- Comment #28 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Oct  7 20:12:00 2019
New Revision: 276673

URL: https://gcc.gnu.org/viewcvs?rev=276673&root=gcc&view=rev
Log:
2019-10-07  Thomas Koenig 

Backport from trunk
PR fortran/84487
* trans-decl.c (gfc_get_symbol_decl): For __def_init, set
DECL_ARTIFICAL and do not set TREE_READONLY.

2019-10-07  Thomas Koenig 

Backport from trunk
PR fortran/84487
* gfortran.dg/typebound_call_22.f03: xfail.


Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-decl.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/typebound_call_22.f03

[Bug fortran/92020] New: Improve handling of __def_init / xfail of typebound_call_22.f03

[tkoenig at gcc dot gnu.org]

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

Bug ID: 92020
   Summary: Improve handling of __def_init / xfail of
typebound_call_22.f03
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

To save space in rodata, the artificial __def_init variables are no longer
put into .rodata, but in BSS.  For most variables, these are full of
zeros anyway.  See PR 84487 for details.

This also serves as a note that typebound_call_22.f03 is xfailed due to this.

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

[tkoenig at gcc dot gnu.org]

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

Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto 
with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

   What|Removed |Added

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

[Bug other/84613] [meta-bug] SPEC compiler performance issues

[tkoenig at gcc dot gnu.org]

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

Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto 
with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

   What|Removed |Added

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

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #29 from Thomas Koenig  ---
Migitated on all open branches.

For the rest, see PR 92020.

[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Oct  7 20:50:05 2019
New Revision: 276678

URL: https://gcc.gnu.org/viewcvs?rev=276678&root=gcc&view=rev
Log:
[gcc]

2019-10-07  Bill Schmidt  

Backport from mainline
2019-10-01  Bill Schmidt  

PR target/91275
* config/rs6000/rs6000.c (rtx_is_swappable_p): Don't swap
vpmsumd.

[gcc/testsuite]

2019-10-07  Bill Schmidt  

Backport from mainline
2019-10-01  Bill Schmidt  

PR target/91275
* gcc.target/powerpc/pr91275.c: New.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr91275.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.4.0
 Resolution|--- |FIXED
  Known to fail|7.4.0   |

--- Comment #19 from Bill Schmidt  ---
Fixed everywhere.

[Bug target/91275] __builtin_crypto_vpmsumd gives different results -O[123] vs -O0

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #20 from Bill Schmidt  ---
So, closing.

[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:

template  struct basic_mixin {
  basic_mixin() requires true;
};

struct mixin : basic_mixin {
  using basic_mixin::basic_mixin;
};

auto test() {
  noexcept(mixin());
}

[Bug target/51751] COMPLEX16 tests fail in Lapack

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Works now (I didn't check for a long time).

My guess would be that this could be dup of PR87689, but I am certainly
not going to check :-)

[Bug fortran/91984] Handling of __def_init_*

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
*** Bug 92020 has been marked as a duplicate of this bug. ***

[Bug fortran/92020] Improve handling of __def_init / xfail of typebound_call_22.f03

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Koenig  ---
Ups, had already submitted PR 91984.

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

[Bug fortran/91984] Handling of __def_init_*

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Of course, don't forget the xfail on typebound_call_22.f03.

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com  ---
The code snippet you posted looks like exactly what libgcc2.c would 
typically do for __floatundidf.  Given that, I'd prefer building the 
relevant function from libgcc2.c rather than having an Arm-specific 
duplicate.

  /* When the word size is small, we never get any rounding error.  */
  FSTYPE f = (UWtype) (u >> W_TYPE_SIZE);
  f *= Wtype_MAXp1_F;
  f += (UWtype)u;
  return f;

[Bug fortran/66910] allocatable character in derived type gives segfault

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2015-09-06 00:00:00 |2019-10-7

--- Comment #2 from Thomas Koenig  ---
Still present.

[Bug other/91879] --with-build-time-tools doesn't work as expected

[joseph at codesourcery dot com]

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

--- Comment #29 from joseph at codesourcery dot com  ---
On Mon, 7 Oct 2019, stsp at users dot sourceforge.net wrote:

> Is there any way to convince the build system that the
> resulting compiler is alien and cannot be used? I think

A common way of doing that is to make $host and $build textually different 
(after passing through config.sub) while still logically the same.  E.g. 
x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu.

Likewise if you want to configure a compiler for the same target as the 
host but still want it to be configured as a cross compiler, make $target 
textually different from $host.

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

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

--- Comment #30 from Stas Sergeev  ---
(In reply to jos...@codesourcery.com from comment #29)
> A common way of doing that is to make $host and $build textually different 
> (after passing through config.sub) while still logically the same.  E.g. 
> x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu.

Thanks, I'll explore that and will post back in a day or 2.
But... this one and your sysroot suggestion are _tricks_.
I wonder why the one should use tricks for just the basic
task of building a cross-compiler, this just looks strange.

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

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

--- Comment #31 from Stas Sergeev  ---
(In reply to jos...@codesourcery.com from comment #29) 
> A common way of doing that is to make $host and $build textually different 
> (after passing through config.sub) while still logically the same.  E.g. 
> x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu.

And being a trick, it appears non-trivial.
I would want the CPU part to be the same.
I.e.
x86_64-pc-linux-gnu --> x86_64-unknown-linux-gnu
i686-pc-linux-gnu --> i686-unknown-linux-gnu

The problem here is that I can't hard-code $host
to any of that value. It must be evaluated from
$build somehow. Do you have a trick also for that?
Probing manually for uname before configure?
Or maybe its time to add a new option after all? :)

[Bug tree-optimization/91532] [SVE] Redundant predicated store in gcc.target/aarch64/fmla_2.c

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Mon Oct  7 23:44:49 2019
New Revision: 276681

URL: https://gcc.gnu.org/viewcvs?rev=276681&root=gcc&view=rev
Log:
2019-10-07  Prathamesh Kulkarni  
Richard Biener  

PR tree-optimization/91532
* tree-if-conv.c: Include tree-ssa-dse.h.
(ifcvt_local_dce): Change param from bb to loop,
and call dse_classify_store.
(tree_if_conversion): Pass loop instead of loop->header as arg
to ifcvt_local_dce.
* tree-ssa-dse.c: Include tree-ssa-dse.h.
(delete_dead_or_redundant_assignment): Remove static qualifier from
declaration, and add prototype in tree-ssa-dse.h.
(dse_store_status): Move to tree-ssa-dse.h.
(dse_classify_store): Remove static qualifier and add new tree param
stop_at_vuse, and add prototype in tree-ssa-dse.h.
* tree-ssa-dse.h: New header.

Added:
trunk/gcc/tree-ssa-dse.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-if-conv.c
trunk/gcc/tree-ssa-dse.c

[Bug middle-end/92014] [10 Regression] bogus warning: writing 8 bytes into a region of size 1 in timezone/zic.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00509.html

[Bug c++/92001] missing -Wclass-memaccess with array as first argument to memset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00508.html

[Bug fortran/92006] storage_size() returns incorrect value on unlimited polymorphic variable (CLASS(*)) when passed a CHARACTER variable

[urbanjost at comcast dot net]

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

--- Comment #3 from urbanjost at comcast dot net ---
(In reply to kargl from comment #2)
> Depends on, if not a duplicate, of 84006

84006 is showing an ICE when calling STORAGE_SIZE() with an unallocated
variable, which I believe is invalid code. This problem only occurs with an
unlimited polymorphic variable that has been called with a CHARACTER variable,
and produces an incorrect result, not an ICE. Is it certain the problems are
related? If I change the CHARACTER variable to any other type including
user-defined types I did not get a problem.

[Bug fortran/92006] storage_size() returns incorrect value on unlimited polymorphic variable (CLASS(*)) when passed a CHARACTER variable

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Oct 08, 2019 at 03:22:01AM +, urbanjost at comcast dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92006
> 
> --- Comment #3 from urbanjost at comcast dot net ---
> (In reply to kargl from comment #2)
> > Depends on, if not a duplicate, of 84006
> 
> 84006 is showing an ICE when calling STORAGE_SIZE() with an unallocated
> variable, which I believe is invalid code. This problem only occurs with an
> unlimited polymorphic variable that has been called with a CHARACTER variable,
> and produces an incorrect result, not an ICE. Is it certain the problems are
> related? If I change the CHARACTER variable to any other type including
> user-defined types I did not get a problem.
> 

I don't use CLASS.  I know nothing about CLASS or
how it's implemented.  I see only what is in bugzilla.
If someone fixes one problem, s/he might fix both.

Feel free to remove the link between the PRs.

[Bug c/46635] c-family/c-common.c uses BITS_PER_UNIT in lieu of TYPE_PRECISION (char_type_node)

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Jorn Wolfgang Rennecke from comment #1)
> As Joseph S. Myers bentioned in comment 1 of PR46633, 

(this is the last bug open blocking that one, btw)

[Bug other/46633] [meta-bug] frontends use BITS_PER_UNIT when they mean TYPE_PRECISION (char_type_node)

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
Does "frontends" in the title really need to be pluralized when there's only
one left?

[Bug libbacktrace/88745] Darwin lacks an implementation for libbacktrace

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> I tried to start doing this in my fork of gdb but I didn't get very far;
> here's a brief TODO:
> 
> 1. Get filetype.awk to recognize mach-o binaries
> 2. Add a mach-o case to the switch on libbacktrace_cv_sys_filetype in
> configure.ac
> 3. Add a macho.c file to compile to macho.lo to use as the FORMAT_FILE in
> that case

Of those, it's really (1) where I'm stuck... (2) is easy, it can just look like
this:

mach-o*) FORMAT_FILE="macho.lo" ;;

...and (3) can be just a stub to start with (like unknown.c currently is) until
someone's ready to do the trickier parts of getting it to actually work. But
anyways, back to (1)... how do you even go about adding a new filetype to
filetype.awk, anyways? Is that documented somewhere? I don't get how it
works...

[Bug libbacktrace/88745] Darwin lacks an implementation for libbacktrace

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #3 from Ian Lance Taylor  ---
filetype.awk is just an AWK script.  See
https://www.gnu.org/software/gawk/manual/gawk.html.  A Mach-O file starts with
0xfeedface (32-bit Mach-O) or 0xfeedfacf (64-bit Mach-O) in either big-endian
or little-endian order.

[Bug c++/80518] -Wsuggest-override does not warn about missing override on destructor

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #7)
> The guideline might be changing:
> https://github.com/isocpp/CppCoreGuidelines/pull/1448
> If that pull request is merged we might want to change -Wsuggest-override
> too, without needing a separate option.

That pull request has since been merged (on August 1st)

[Bug libbacktrace/88745] Darwin lacks an implementation for libbacktrace

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Ian Lance Taylor from comment #3)
> filetype.awk is just an AWK script.  See
> https://www.gnu.org/software/gawk/manual/gawk.html.  A Mach-O file starts
> with 0xfeedface (32-bit Mach-O) or 0xfeedfacf (64-bit Mach-O) in either
> big-endian or little-endian order.

Does the endianness actually matter? Neither the elf nor pecoff cases seem to
be duplicated for their opposite endiannesses... Also are the octal escape
sequences necessary?