[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/26241] [8/9 Regression] None of the IPA passes are documented in passes.texi

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|8.4 |10.0
  Known to fail||9.2.0

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Thu, 14 Nov 2019, ch3root at openwall dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
> 
> --- Comment #9 from Alexander Cherepanov  ---
> > Now as an exercise build a complete testcase for the DSE issue above.
> 
> Source code:
> 
> --
> #include 
> #include 
> 
> struct s {
> char c;
> int i;
> };
> 
> __attribute__((noinline,noclone))
> void f(struct s *p, struct s *q)
> {
> struct s w;
> 
> memset(, 0, sizeof(struct s));
> w = *q;
> 
> memset(p, 0, sizeof(struct s));
> *p = w;
> }
> 
> int main()
> {
> struct s x;
> memset(, 1, sizeof(struct s));
> 
> struct s y;
> memset(, 2, sizeof(struct s));
> 
> f(, );
> 
> for (unsigned char *p = (unsigned char *) p < (unsigned char *) +
> sizeof(struct s); p++)
> printf("%d", *p);
> printf("\n");
> }
> --
> 
> Results:
> 
> --
> $ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
> 
> $ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
> 1222
> --
> 
> gcc x86-64 version: gcc (GCC) 10.0.0 20191114 (experimental)
> 
> 
> But from the C standard POV this case is much more clear: there is no problem
> as stores into a struct make its padding unspecified (C11, 6.2.6.1p6). OTOH
> this sample demonstrates the problem with trunc, so it could be more 
> convenient
> for testing.

Yeah, I think the C standard is clear here but the question is about
GIMPLE IL semantics where making things "unspecified" is a bit awkward.

[Bug tree-optimization/92516] ice in vect_schedule_slp_instance, at tree-vect-slp.c:4095

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Agreed. 

Since code is fine with -O2, but not with -O3, then
it looks like an optimiser problem to me.

About 2 hours of reduction has already been done. More is in progress.
Current size is about 2.2 Megs.

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 14 Nov 2019, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
> 
> Martin Sebor  changed:
> 
>What|Removed |Added
> 
>  CC||msebor at gcc dot gnu.org
> 
> --- Comment #8 from Martin Sebor  ---
> Whether memcpy needs to preserve the value of padding bits is debatable (and
> has been debated in WG14 for a couple of decades now).  The value of padding
> bits is described as unspecified, and an unspecified value is described as a
> "valid value of the relevant type where this International Standard imposes no
> requirements on which value is chosen in any instance."  The "chosen in any
> instance" has been interpreted as permitting the observed value to change from
> one read to another.  Examples of this effect are in DR #260 and DR #451. 
> Although they deal with uninitialized objects whose value is indeterminate,
> since objects of types like char have no trap representation, their
> uninitialized and indeterminate value is simply unspecified, same as that of
> padding bits.

Note within GIMPLE it's difficult to 1:1 apply such rules since we
usually do not know the effective type of the memory object we are
about to scalarize (that is, GIMPLE assumes even C has placement new
and even plain decls are just "storage")

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 14 Nov 2019, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
> 
> --- Comment #7 from Andrew Pinski  ---
> I have another idea, cant we add fake field decls while doing structure 
> layout?
> Then sra total scalarization will just work. And there is no other magic in 
> the
> compiler needed?

I suppose code-gen would suck for the 3-byte padding field between
a char and an int.  But total scalarization works with the premise
that we don't see any direct accesses to source or destination so
I think we should simply change "total scalarization" to be
"emit the block-copy on GIMPLE".  Preferably without "crossing"
field boundaries but covering padding by choosing larger accesses.

[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #11 from sandra at gcc dot gnu.org ---
I think that to confirm this is fixed, somebody would have to go through
passes.def and compare it to the docs.

It would really be nice if we could make this self-documenting, though --
include a short pass description in the code where the pass is declared which
we could extract via a script that also massages passes.def into a table to
insert into the manual, etc.

[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date

[egallager at gcc dot gnu.org]

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

--- Comment #10 from Eric Gallager  ---
Update: the last bug that was open that this bug depends upon has been closed.
So, ok to close this one as well?

[Bug middle-end/26241] [8/9 Regression] None of the IPA passes are documented in passes.texi

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #25 from Eric Gallager  ---
(In reply to Xiong Hu XS Luo from comment #24)
> closing this since no need backport?

OK.

[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date

[egallager at gcc dot gnu.org]

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

Bug 26241 Summary: [8/9 Regression] None of the IPA passes are documented in 
passes.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26241

   What|Removed |Added

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

[Bug c++/90466] Documentation: -Wconversion-extra not documented

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> That's a fortran option; it's documented in the gfortran manual:
> https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html#Error-and-Warning-Options

...thus, I'm gonna say this isn't actually a bug, since -Wconversion-extra is
actually documented.

[Bug c++/81159] New warning idea: -Wself-move

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Marek Polacek from comment #3)
> Ok, this shouldn't be too hard.  I guess I could implement it for GCC 10.

last chance to get it in before stage 1 closes...

[Bug target/92132] new test case gcc.dg/vect/vect-cond-reduc-4.c fails with its introduction in r277067

[helijia at gcc dot gnu.org]

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

Li Jia He  changed:

   What|Removed |Added

 CC||helijia at gcc dot gnu.org

--- Comment #6 from Li Jia He  ---
*** Bug 92098 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/92098] [10 Regression] After r262333, the following code cannot be vectorized on powerpc64le.

[helijia at gcc dot gnu.org]

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

Li Jia He  changed:

   What|Removed |Added

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

--- Comment #1 from Li Jia He  ---
We can solve this issue by support full condition reduction vectorization. And
PowerPC full condition reduction vectorization supported by PR92132.

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

[Bug c++/92524] New: ICE in short program with constexpr and std::array

[gnu at kosak dot com]

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

Bug ID: 92524
   Summary: ICE in short program with constexpr and std::array
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu at kosak dot com
  Target Milestone: ---

Hello,

This program gives an internal compiler error.

=
#include 

constexpr char wildcard = '*';

struct Foo {
  char ch_ = wildcard;
};

void func(Foo value) {
  std::array x = {value};
}
==


$ g++ qwe.cc
qwe.cc: In function ‘void func(Foo)’:
qwe.cc:10:32: internal compiler error: in build_class_member_access_expr, at
cp/typeck.c:2384
   10 |   std::array x = {value};
  |^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--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-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=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,hsa
--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 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)

[Bug c++/92523] New: Unhelpful error messages when requires-clause contains function call

[boostcpp at gmail dot com]

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

Bug ID: 92523
   Summary: Unhelpful error messages when requires-clause contains
function call
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boostcpp at gmail dot com
  Target Milestone: ---

Following code produce unhelpful error messages:

constexpr bool f() { return true ; }

template < typename T >
requires f()
void g(){}

https://wandbox.org/permlink/bH2Eo2aTC2JeueZt

prog.cc:4:14: error: constraint expression does not have type 'bool'
4 | requires f()
  |  ^
prog.cc:4:16: error: expected unqualified-id before ')' token
4 | requires f()
  |^

If the requires-clause was like this:

requires 2 + 2 == 5

It does produce helpful error messages which clearly show what's wrong here.

https://wandbox.org/permlink/xIMiqWVcVrDkMU55

prog.cc:4:14: error: constraint expression does not have type 'bool'
4 | requires 2 + 2 == 5
  |  ^
prog.cc:4:16: error: expression after 'requires' must be enclosed in
parentheses
4 | requires 2 + 2 == 5
  |  ~~^~~~
  |  ( )


function call expression inside the requires-clause should produce helpful
messages like it already does in other expressions.

[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Blocks||67491

--- Comment #7 from Eric Gallager  ---
(In reply to Hannes Hauswedell from comment #6)
> (In reply to Jason Merrill from comment #5)
> > Author: jason
> > Date: Tue Nov  5 11:46:54 2019
> > New Revision: 277825
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=277825=gcc=rev
> > Log:
> > PR c++/88075 - Don't require 'bool' in a concept definition.
> > 
> > * parser.c (cp_parser_decl_specifier_seq): Support C++20
> > concept-definition syntax without 'bool'.
> > 
> > Added:
> > branches/gcc-8-branch/gcc/testsuite/g++.dg/concepts/no-bool1.C
> > Modified:
> > branches/gcc-8-branch/gcc/cp/ChangeLog
> > branches/gcc-8-branch/gcc/cp/parser.c
> 
> 
> Thanks a lot for this change!
> 
> Does this work with -fconcepts and if yes can we also get it for GCC7?
> Thanks a lot!

Well, the branch for GCC7 just closed, so, looks like not...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/67491] [meta-bug] concepts issues

[egallager at gcc dot gnu.org]

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

Bug 92403 Summary: [concepts] requires expression in if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92403

   What|Removed |Added

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

[Bug c++/55004] [meta-bug] constexpr issues

[egallager at gcc dot gnu.org]

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

Bug 92403 Summary: [concepts] requires expression in if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92403

   What|Removed |Added

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

[Bug c++/92186] [concepts] requires expression outside of concept definition cannot return false

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||pilarlatiesa at gmail dot com

--- Comment #2 from Eric Gallager  ---
*** Bug 92403 has been marked as a duplicate of this bug. ***

[Bug c++/92403] [concepts] requires expression in if constexpr

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-11/msg01051.ht
   ||ml
 CC||egallager at gcc dot gnu.org
 Blocks||55004
 Resolution|--- |DUPLICATE

--- Comment #3 from Eric Gallager  ---
(In reply to Andrew Sutton from comment #2)
> This seems like a duplicate of 92186.

ok, closing as such then

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/92439] [concepts] trunk crashes on constraint satisfaction failure

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-11/msg01034.ht
   ||ml
   Last reconfirmed||2019-11-15
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/80105] [6/7/8 Regression] ICE in outer_projection_mupa, at graphite-sese-to-poly.c:1019

[egallager at gcc dot gnu.org]

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

Bug 69728 Summary: [7 Regression] internal compiler error: in 
outer_projection_mupa, at graphite-sese-to-poly.c:1175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728

   What|Removed |Added

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

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[egallager at gcc dot gnu.org]

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

Bug 69728 Summary: [7 Regression] internal compiler error: in 
outer_projection_mupa, at graphite-sese-to-poly.c:1175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728

   What|Removed |Added

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

[Bug other/80069] ICE at graphite-sese-to-poly.c:1176

[egallager at gcc dot gnu.org]

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

Bug 69728 Summary: [7 Regression] internal compiler error: in 
outer_projection_mupa, at graphite-sese-to-poly.c:1175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728

   What|Removed |Added

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

[Bug tree-optimization/69728] [7 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #27 from Eric Gallager  ---
(In reply to Arseny Solokha from comment #26)
> This this PR be closed now?

Yeah I think that's what Richard meant to do

[Bug tree-optimization/83325] Compile time hog w/ -Os -fwrapv

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
Is it still an issue? I cannot reproduce it anywhere anymore. Maybe related
PR82952 could be more appropriate for tracking it further.

[Bug middle-end/26241] [8/9 Regression] None of the IPA passes are documented in passes.texi

[luoxhu at cn dot ibm.com]

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

--- Comment #24 from Xiong Hu XS Luo  ---
closing this since no need backport?

[Bug c++/54367] [meta-bug] lambda expressions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
  Alias||lambdas

--- Comment #1 from Eric Gallager  ---
alias lambdas

[Bug libstdc++/92522] New: valid code using deque throws bad_alloc when compiled with -flto

[johnilacqua at hotmail dot com]

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

Bug ID: 92522
   Summary: valid code using deque throws bad_alloc when compiled
with -flto
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johnilacqua at hotmail dot com
  Target Milestone: ---

Minimal example:

//sample.cc
#include 
std::deque test;

//main.cc
#include 
extern std::deque test;
static const auto sample = test;
int main() {}

compile command:
g++-9 -flto sample.cc main.cc

g++-9 --version
g++-9 (Ubuntu 9.2.1-17ubuntu1~16.04) 9.2.1 20191102

Running the resulting binary throws bad_alloc.
Running with valgrind displays output:
**168** new/new[] failed and should throw an exception, but Valgrind
**168**cannot throw exceptions and so is aborting instead.  Sorry.
==168==at 0x4C2D96C: ??? (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==168==by 0x4C2E165: operator new(unsigned long) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==168==by 0x40113F: __gnu_cxx::new_allocator::allocate(unsigned long,
void const*) (in /home/john/test/a.out)
==168==by 0x40103D: std::allocator_traits
>::allocate(std::allocator&, unsigned long) (in /home/john/test/a.out)
==168==by 0x400E43: std::_Deque_base
>::_M_allocate_map(unsigned long) (in /home/john/test/a.out)
==168==by 0x400B7B: std::_Deque_base
>::_M_initialize_map(unsigned long) (in /home/john/test/a.out)
==168==by 0x4015E6: std::_Deque_base
>::_Deque_base(std::allocator const&, unsigned long) (in
/home/john/test/a.out)
==168==by 0x40145A: std::deque
>::deque(std::deque > const&) (in
/home/john/test/a.out)
==168==by 0x402005: __static_initialization_and_destruction_0(int, int)
[clone .lto_priv.1] (in /home/john/test/a.out)
==168==by 0x40202E: _GLOBAL__sub_I_main (in /home/john/test/a.out)
==168==by 0x402039: _sub_I_65535_0.4643 (in /home/john/test/a.out)
==168==by 0x40209C: __libc_csu_init (in /home/john/test/a.out)

[Bug c/92507] False positives with -Wsign-compare

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=38470,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=66773

--- Comment #3 from Eric Gallager  ---
some related bugs include bug 66773 and bug 38470

[Bug c++/91182] deprecated attribute string-literal

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-14
 CC||jsm28 at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Joseph S. Myers  ---
I rediscovered this bug (and found bug 92521) while implementing support for
[[deprecated]] for C. While it's filed as a C++ bug, it's actually a bug in
language-independent code for this warning in tree.c, so applies to both C and
C++.

[Bug c++/92521] New: [[deprecated(("string-literal"))]] accepted with extra parentheses

[jsm28 at gcc dot gnu.org]

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

Bug ID: 92521
   Summary: [[deprecated(("string-literal"))]] accepted with extra
parentheses
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

The C++ standard says the only valid attribute-argument-clause for the
"deprecated" attribute is (string-literal). In particular, redundantly
parenthesized string literals are not permitted. However, the C++ front end
accepts invalid code such as:

int a [[deprecated""]];

[Bug testsuite/92520] New: new test case gcc/testsuite/gcc.dg/ipa/inline-9.c in r278220 is unresolved

[seurer at gcc dot gnu.org]

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

Bug ID: 92520
   Summary: new test case gcc/testsuite/gcc.dg/ipa/inline-9.c in
r278220 is unresolved
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/ipa/inline-9.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -Os -fdump-ipa-inline -S
-o inline-9.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/ipa/inline-9.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -Os -fdump-ipa-inline -S -o
inline-9.s
PASS: gcc.dg/ipa/inline-9.c (test for excess errors)
gcc.dg/ipa/inline-9.c: dump file does not exist
UNRESOLVED: gcc.dg/ipa/inline-9.c scan-tree-dump inline "Inlined 1 calls"
testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/ipa/ipa.exp completed
in 0 seconds

=== gcc Summary ===

# of expected passes1
# of unresolved testcases   1

[Bug c++/92519] New: Spurious "note: ... has no user-provided default constructor"

[patrick at motec dot com.au]

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

Bug ID: 92519
   Summary: Spurious "note: ... has no user-provided default
constructor"
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at motec dot com.au
  Target Milestone: ---

When built with -std=c++17 the following example emits a spurious note.
Changing the lambda argument from 'auto' to 'int' no longer emits the note.

#include 

void foo()
{
[](auto v) {
std::array bar;
}(42);
}

% g++ -c -std=c++17 test.cpp
In file included from warning.cpp:1:
warning.cpp: In instantiation of ‘foo():: [with auto:1 = int]’:
warning.cpp:7:6:   required from here
/usr/include/c++/9.2.0/array:94:12: note: ‘struct std::array’ has no
user-provided default constructor
   94 | struct array
  |^
/usr/include/c++/9.2.0/array:110:56: note: and the implicitly-defined
constructor does not initialize ‘int std::array::_M_elems [3]’
  110 |   typename _AT_Type::_Type _M_elems;
  |^~~~

% g++ -v   
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.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++,d --enable-shared
--enable-threads=posix --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 gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[ch3root at openwall dot com]

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

--- Comment #9 from Alexander Cherepanov  ---
> Now as an exercise build a complete testcase for the DSE issue above.

Source code:

--
#include 
#include 

struct s {
char c;
int i;
};

__attribute__((noinline,noclone))
void f(struct s *p, struct s *q)
{
struct s w;

memset(, 0, sizeof(struct s));
w = *q;

memset(p, 0, sizeof(struct s));
*p = w;
}

int main()
{
struct s x;
memset(, 1, sizeof(struct s));

struct s y;
memset(, 2, sizeof(struct s));

f(, );

for (unsigned char *p = (unsigned char *) p < (unsigned char *) +
sizeof(struct s); p++)
printf("%d", *p);
printf("\n");
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out

$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
1222
------

gcc x86-64 version: gcc (GCC) 10.0.0 20191114 (experimental)


But from the C standard POV this case is much more clear: there is no problem
as stores into a struct make its padding unspecified (C11, 6.2.6.1p6). OTOH
this sample demonstrates the problem with trunc, so it could be more convenient
for testing.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Sylvain Korzennik from comment #11)
> I'll try rebuilding it w/  ./configure
> --host=x86_64-pc-linux-gnu

Or let GCC build them for you, by putting their sources in the GCC source tree,
as recommended at https://gcc.gnu.org/wiki/InstallingGCC

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[xry111 at mengyan1223 dot wang]

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

--- Comment #39 from Xi Ruoyao  ---
(In reply to Jan Hubicka from comment #38)

> Internally in GCC the symver is handled just as normal alias only output
> differntly.  I think GCC, just like static linker, does not really need
> to understand the versions because there are no direct ways to bind to
> those symbols.
> 
> I wonder if someone sees limitations to this design (in particular
> attaching the symver directly to the definition). 

I think this design is correct.  "symver" attribute is introduced to "bind" a
symver to a definition.  If they can be seperated LTO will do stupid things.

I prefer "symver" than "version_def".

[Bug target/92518] [10 regression] ppc rounding tests fail after r278207

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|[10 regression] ppc |[10 regression] ppc
   |rounding tests fail on  |rounding tests fail after
   |power 7 (only) after|r278207
   |r278207 |

--- Comment #1 from seurer at gcc dot gnu.org ---
Upon further testing they fail on power 8 and 9 as well as power 7 both BE and
LE.

[Bug target/92518] New: [10 regression] ppc rounding tests fail on power 7 (only) after r278207

[seurer at gcc dot gnu.org]

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

Bug ID: 92518
   Summary: [10 regression] ppc rounding tests fail on power 7
(only) after r278207
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Not sure if this is an indication of a real problem or if the tests just need
to be adjusted on power 7.

FAIL: gcc.target/powerpc/ppc-round.c scan-assembler-times
mfctiwuzM|mxscvdpuxwsM 2
FAIL: gcc.target/powerpc/ppc-round.c scan-assembler-times
mfctiwzM|mxscvdpsxwsM 2
FAIL: gcc.target/powerpc/ppc-round.c scan-assembler-times
mlfiwaxM|mlxsiwaxM 2
FAIL: gcc.target/powerpc/ppc-round.c scan-assembler-times
mlfiwzxM|mlxsiwzxM 2
FAIL: gcc.target/powerpc/ppc-round2.c scan-assembler-times mmfvsrwzM 2
FAIL: gcc.target/powerpc/ppc-round2.c scan-assembler-times mmtvsrwzM 2
FAIL: gcc.target/powerpc/ppc-round2.c scan-assembler-times mvupkhswM 2
FAIL: gcc.target/powerpc/ppc-round2.c scan-assembler-times mxxpermdiM 2
FAIL: gcc.target/powerpc/ppc-round2.c scan-assembler-times fctiwuz |xscvdpuxws 
2
FAIL: gcc.target/powerpc/ppc-round2.c scan-assembler-times fctiwz |xscvdpsxws 
2
FAIL: gcc.target/powerpc/ppc-round3.c scan-assembler-times mvextsw2dM 2
FAIL: gcc.target/powerpc/ppc-round3.c scan-assembler-times
mxxextractuwM 2
FAIL: gcc.target/powerpc/ppc-round3.c scan-assembler-times fctiwuz |xscvdpuxws 
2
FAIL: gcc.target/powerpc/ppc-round3.c scan-assembler-times fctiwz |xscvdpsxws 
2

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[hubicka at ucw dot cz]

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

--- Comment #38 from Jan Hubicka  ---
Hi,
I am attaching prototype patch.  It implements "symver" attribute which
can be attached to a definition such as:

hubicka@lomikamen-jh:/aux/hubicka/trunk5/build4/gcc$ cat t.c
__attribute__ ((symver("bar@2.2")))
int t()
{
}
hubicka@lomikamen-jh:/aux/hubicka/trunk5/build4/gcc$ ./xgcc -B ./ -O2 t.c -S
hubicka@lomikamen-jh:/aux/hubicka/trunk5/build4/gcc$ cat t.s
.file   "t.c"
.text
.p2align 4
.globl  t
.type   t, @function
t:
.LFB0:
.cfi_startproc
ret
.cfi_endproc
.LFE0:
.size   t, .-t
.symver t, bar@2.2
    .ident  "GCC: (GNU) 10.0.0 20191114 (experimental)"
.section.note.GNU-stack,"",@progbits

Internally it defines a new kind of alias (symver alias) with assembler
name "bar@2.2" so LTO symbol table match ELF symbol table for the unit:

hubicka@lomikamen-jh:/aux/hubicka/trunk5/build4/gcc$ nm t.o
 T bar@2.2
 T t
hubicka@lomikamen-jh:/aux/hubicka/trunk5/build4/gcc$ ./xgcc -B ./ -O2
t.c -c -flto
hubicka@lomikamen-jh:/aux/hubicka/trunk5/build4/gcc$ gcc-nm t.o
 T bar@2.2
 T t

Internally in GCC the symver is handled just as normal alias only output
differntly.  I think GCC, just like static linker, does not really need
to understand the versions because there are no direct ways to bind to
those symbols.

I wonder if someone sees limitations to this design (in particular
attaching the symver directly to the definition). 

In PR66825 Carlos proposed "version_def" attribute which can be
implemented too (I suppose all I need is to concatenate the strings into
the actual name).  I wonder what would be preferred and easier for
users?

Also Carlos proposes "version_ref" that can be used for external
definitions.  I am not quite sure how to do that with existing GAS and
LTO since different translation units can reffer to different versions.
But my understnading is that for LTO it is critical to implement the def
part.

Hopefully I can turn this into a patch proposal tomorrow to meet the
stage1 deadline, so comments are welcome especially if they come really
soon :)

Honza

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||carlos at redhat dot com

--- Comment #37 from Jan Hubicka  ---
*** Bug 66825 has been marked as a duplicate of this bug. ***

[Bug c/66825] RFE: Add attributes for symbol versioning.

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||hubicka at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Jan Hubicka  ---
We have earlier bug on this. I am going to attach WIP patch there.

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

[Bug fortran/92463] Cleanups due to minimum MPFR version bump to 3.1.0

[jb at gcc dot gnu.org]

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

--- Comment #1 from Janne Blomqvist  ---
Seems r269139 can be reverted, that's apparently a patch to fix some accidental
breakage due to depending on a too new MPFR version.

[Bug tree-optimization/92516] ice in vect_schedule_slp_instance, at tree-vect-slp.c:4095

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #2 from Marek Polacek  ---
vect_* -> not a C++ FE issue.

[Bug c++/92516] ice in vect_schedule_slp_instance, at tree-vect-slp.c:4095

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Problem first seems to occur sometime between revision 278200
and 278250.

Code reduction now in progress, but since the size of the partially
reduced code is currently 5.4 Megs, this is expected to take quite some time.

[Bug debug/80646] [8/9/10 Regression] wrong type info for extern inline function when compiling Emacs

[eggert at gnu dot org]

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

Paul Eggert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |MOVED

--- Comment #7 from Paul Eggert  ---
(In reply to Richard Biener from comment #6)

I still see the problem on Fedora 31 x86-64, but you're right that it appears
to be a GDB bug rather than a GCC bug. I added a note to that effect to the GDB
bug report  and am
marking the GCC bug as RESOLVED MOVED (moved to GDB, that is). The bug appears
to be low priority on the GDB side, but I don't know how to fix that

[Bug c++/92517] New: ICE on incorrect syntax involving requires and decltype

[sbence92 at gmail dot com]

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

Bug ID: 92517
   Summary: ICE on incorrect syntax involving requires and
decltype
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbence92 at gmail dot com
  Target Milestone: ---

Naively adding decltype with wrong syntax in order fix "expected a type, got
'I'" results in segfault with following code:

template 
concept C = true;

template
requires C decltype
void f() {}

flags: -std=c++2a -fconcepts

gcc 9.2 produces correct error message

[Bug c++/92516] New: ice in vect_schedule_slp_instance, at tree-vect-slp.c:4095

[dcb314 at hotmail dot com]

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

Bug ID: 92516
   Summary: ice in vect_schedule_slp_instance, at
tree-vect-slp.c:4095
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 47267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47267=edit
gzipped C++ source code

The attached C++ code, when compiled by recent gcc trunk
and compiler flags -O3 -std=c++1z, does this:

internal compiler error: in vect_schedule_slp_instance, at tree-vect-slp.c:4095
 1447 | void QGtkStyle::drawComplexControl(ComplexControl control, const
QStyleOptionComplex *option,
  |  ^
0x80978a vect_schedule_slp_instance
../../trunk/gcc/tree-vect-slp.c:4095
0x13c0013 vect_schedule_slp_instance
../../trunk/gcc/tree-vect-slp.c:4077
0x13c0013 vect_schedule_slp_instance
../../trunk/gcc/tree-vect-slp.c:4077
0x13c0013 vect_schedule_slp_instance
../../trunk/gcc/tree-vect-slp.c:4077

[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #10 from Jim Wilson  ---
Fixed on mainline.  No backport requested.

[Bug tree-optimization/92515] New: [10 regression] ICE in many test cases after r278235

[seurer at gcc dot gnu.org]

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

Bug ID: 92515
   Summary: [10 regression] ICE in many test cases after r278235
   Product: gcc
   Version: 9.2.1
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: ---

One example:

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -O3  -lm  -o
./vshift-5.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3 -lm -o ./vshift-5.exe
during GIMPLE pass: slp
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c: In function 'f2':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vshift-5.c:26:1: internal
compiler error: in operator[], at vec.h:859
0x10e0c707 vec::operator[](unsigned int)
/home/seurer/gcc/gcc-test2/gcc/vec.h:859
0x10e0c707 vec::operator[](unsigned int)
/home/seurer/gcc/gcc-test2/gcc/vec.h:1425
0x10e0c707 vectorizable_shift
/home/seurer/gcc/gcc-test2/gcc/tree-vect-stmts.c:5867
0x10e2694b vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
/home/seurer/gcc/gcc-test2/gcc/tree-vect-stmts.c:10914
0x10e5a15f vect_schedule_slp_instance
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:4088
0x10e59e6b vect_schedule_slp_instance
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3982
0x10e5cac3 vect_schedule_slp(vec_info*)
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:4209
0x10e617cf vect_slp_bb_region
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3206
0x10e617cf vect_slp_bb(basic_block_def*)
/home/seurer/gcc/gcc-test2/gcc/tree-vect-slp.c:3300
0x10e64f5b execute
/home/seurer/gcc/gcc-test2/gcc/tree-vectorizer.c:1320

Full list of failures:
> FAIL: gcc.dg/vect/pr46126.c (internal compiler error)
> FAIL: gcc.dg/vect/pr46126.c (test for excess errors)
> FAIL: gcc.dg/vect/pr46126.c -flto -ffat-lto-objects (internal compiler error)
> FAIL: gcc.dg/vect/pr46126.c -flto -ffat-lto-objects (test for excess errors)
> FAIL: gcc.dg/vect/slp-multitypes-13.c (internal compiler error)
> FAIL: gcc.dg/vect/slp-multitypes-13.c (test for excess errors)
> FAIL: gcc.dg/vect/slp-multitypes-13.c -flto -ffat-lto-objects (internal 
> compiler error)
> FAIL: gcc.dg/vect/slp-multitypes-13.c -flto -ffat-lto-objects (test for 
> excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O0  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O0  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O1  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O1  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O3 -g  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -Os  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -Os  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O0  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O0  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O1  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O1  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O3 -g  (test for excess errors)
> 

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Current patch (modulo testsuite changes) that seems to work pretty well:

diff --git gcc/c-family/c-cppbuiltin.c gcc/c-family/c-cppbuiltin.c
index 76d1e4a380e..9766d7f96c4 100644
--- gcc/c-family/c-cppbuiltin.c
+++ gcc/c-family/c-cppbuiltin.c
@@ -972,7 +972,8 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, "__cpp_fold_expressions=201603L");
  cpp_define (pfile, "__cpp_nontype_template_args=201411L");
  cpp_define (pfile, "__cpp_range_based_for=201603L");
- cpp_define (pfile, "__cpp_constexpr=201603L");
+ if (cxx_dialect <= cxx17)
+   cpp_define (pfile, "__cpp_constexpr=201603L");
  cpp_define (pfile, "__cpp_if_constexpr=201606L");
  cpp_define (pfile, "__cpp_capture_star_this=201603L");
  cpp_define (pfile, "__cpp_inline_variables=201606L");
@@ -991,6 +992,7 @@ c_cpp_builtins (cpp_reader *pfile)
{
  /* Set feature test macros for C++2a.  */
  cpp_define (pfile, "__cpp_conditional_explicit=201806L");
+ cpp_define (pfile, "__cpp_constexpr=201907L");
  cpp_define (pfile, "__cpp_constinit=201907L");
  cpp_define (pfile, "__cpp_nontype_template_parameter_class=201806L");
  cpp_define (pfile, "__cpp_impl_destroying_delete=201806L");
diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 8c79b0484fc..5bfbc1f7ce5 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -765,7 +765,7 @@ massage_constexpr_body (tree fun, tree body)
bases/fields are uninitialized, and complain if COMPLAIN.  */

 static bool
-cx_check_missing_mem_inits (tree ctype, tree body, bool complain)
+cx_check_missing_mem_inits (tree ctype, tree body, bool complain, bool
allow_missing = true)
 {
   unsigned nelts = 0;

@@ -815,13 +815,15 @@ cx_check_missing_mem_inits (tree ctype, tree body, bool
complain)
continue;
  if (ANON_AGGR_TYPE_P (TREE_TYPE (field)))
{
- /* Recurse to check the anonummous aggregate member.  */
+ /* Recurse to check the anonymous aggregate member.  */
  bad |= cx_check_missing_mem_inits
-   (TREE_TYPE (field), NULL_TREE, complain);
+   (TREE_TYPE (field), NULL_TREE, complain, allow_missing);
  if (bad && !complain)
return true;
  continue;
}
+ if (cxx_dialect >= cxx2a && allow_missing)
+   continue;
  ftype = strip_array_types (TREE_TYPE (field));
  if (type_has_constexpr_default_constructor (ftype))
{
@@ -829,6 +831,10 @@ cx_check_missing_mem_inits (tree ctype, tree body, bool
complain)
 A constexpr ctor that isn't trivial should have been
 added in by now.  */
  gcc_checking_assert (!TYPE_HAS_COMPLEX_DFLT (ftype)
+  /* If we're only checking for missing
+ inits, non-trivial ctors have not been
+ added yet.  */
+  || (cxx_dialect >= cxx2a && !allow_missing)
   || errorcount != 0);
  continue;
}
@@ -847,7 +853,7 @@ cx_check_missing_mem_inits (tree ctype, tree body, bool
complain)
{
  /* Check the anonymous aggregate initializer is valid.  */
  bad |= cx_check_missing_mem_inits
-   (TREE_TYPE (index), CONSTRUCTOR_ELT (body, i)->value, complain);
+   (TREE_TYPE (index), CONSTRUCTOR_ELT (body, i)->value, complain,
allow_missing);
  if (bad && !complain)
return true;
}
@@ -2150,8 +2156,18 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
 }

   /* The result of a constexpr function must be completely initialized.  */
+  // XXX not in C++20 constructor
+  // XXX pedwarn somewhere
   if (TREE_CODE (result) == CONSTRUCTOR)
-clear_no_implicit_zero (result);
+{
+  clear_no_implicit_zero (result);
+  if (cxx_dialect >= cxx2a
+ && DECL_CONSTRUCTOR_P (fun)
+ && DECL_DECLARED_CONSTEXPR_P (fun)
+ && NON_UNION_CLASS_TYPE_P (TREE_TYPE (result))
+ && cx_check_missing_mem_inits (TREE_TYPE (result), result, false,
false))
+  CONSTRUCTOR_NO_CLEARING (result) = true;
+}

   pop_cx_call_context ();
   return result;
@@ -2903,8 +2919,7 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, tree
t,

   /* Not found.  */

-  if (TREE_CODE (ary) == CONSTRUCTOR
-  && CONSTRUCTOR_NO_CLEARING (ary))
+  if (TREE_CODE (ary) == CONSTRUCTOR && CONSTRUCTOR_NO_CLEARING (ary))
 {
   /* 'ary' is part of the aggregate initializer we're currently
 building; if there's no initializer for this element yet,
diff --git gcc/cp/decl.c gcc/cp/decl.c
index 86e38f4af69..ab6da6080a5 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -5835,8 +5835,12 @@ 

[Bug other/92366] new test case gcc.dg/vect/bb-slp-41.c fails with its introduction in r277784

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Nov 14 19:24:21 2019
New Revision: 278262

URL: https://gcc.gnu.org/viewcvs?rev=278262=gcc=rev
Log:
Tweak gcc.dg/vect/bb-slp-4[01].c (PR92366)

gcc.dg/vect/bb-slp-40.c was failing on some targets because the
explicit dg-options overrode things like -maltivec.  This patch
uses dg-additional-options instead.

Also, it seems safer not to require exactly 1 instance of each message,
since that depends on the target vector length.

gcc.dg/vect/bb-slp-41.c contained invariant constructors that are
vectorised on AArch64 (foo) and constructors that aren't (bar).
This meant that the number of times we print "Found vectorizable
constructor" depended on how many vector sizes we try, since we'd
print it for each failed attempt.

In foo, we create invariant { b[0], ... } and { b[1], ... },
and the test is making sure that the two separate invariant vectors
can be fed from the same vector load at b.  This is a different case
from bb-slp-40.c, where the constructors are naturally separate.
(The expected count is 4 rather than 2 because we can vectorise the
epilogue too.)

However, due to limitations in the loop vectoriser, we still do the
addition of { b[0], ... } and { b[1], ... } in the loop.  Hopefully
that'll be fixed at some point, so this patch adds an alternative test
that directly needs 4 separate invariant constructors.  E.g. with Joel's
SLP optimisation, the new test generates:

ldr q4, [x1]
dup v7.4s, v4.s[0]
dup v6.4s, v4.s[1]
dup v5.4s, v4.s[2]
dup v4.4s, v4.s[3]

instead of the somewhat bizarre:

ldp s6, s5, [x1, 4]
ldr s4, [x1, 12]
ld1r{v7.4s}, [x1]
dup v6.4s, v6.s[0]
dup v5.4s, v5.s[0]
dup v4.4s, v4.s[0]

The patch then disables vectorisation of the original foo in
bb-vect-slp-41.c, so that we get the same correctness testing
for bar but don't need to test for specific counts.

2019-11-14  Richard Sandiford  

gcc/testsuite/
PR testsuite/92366
* gcc.dg/vect/bb-slp-40.c: Use dg-additional-options instead
of dg-options.  Remove expected counts.
* gcc.dg/vect/bb-slp-41.c: Remove dg-options and explicit
dg-do run.  Suppress vectorization of foo.
* gcc.dg/vect/bb-slp-42.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-42.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-40.c
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-41.c

[Bug c++/91366] Implement P1816R0: Class template argument deduction for aggregates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[skorzennik at cfa dot harvard.edu]

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

--- Comment #11 from Sylvain Korzennik  ---
Thx - for GMP, /config.guess returns
  skylake-pc-linux-gnu
not
  x86_64-pc-linux-gnu
hence the mess... I'll try rebuilding it w/  ./configure
--host=x86_64-pc-linux-gnu

  Cheers,
Sylvain
--

On Thu, Nov 14, 2019 at 2:00 PM pinskia at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
>
> --- Comment #10 from Andrew Pinski  ---
> (In reply to Sylvain Korzennik from comment #9)
> > 1- that page does not tell me how to build a generic version
> >./config.guess returns the same value on ea machine, as does gcc
> > -dumpmachine
> > x86_64-pc-linux-gnu
> >
> > do I add --build=XX --host-XX or --target=XX and what XX to use? The
> > doc is quite thin.
>
> Well this is no longer a GCC question but rather a GMP question and you should
> ask in their mailing list.  But when built inside GCC, the following configure
> options are passed to GMP:
> --build=${build_alias} --host=none-${host_vendor}-${host_os} \
>   --target=none-${host_vendor}-${host_os}
>
>
>
> > 2- you're not telling me if I need to rebuild all 4 components.
>
>
> It depends on if you built them as shared libraries are static libraries.  If
> as shared, 99% sure you don't need to rebuild all 4, just GMP.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug tree-optimization/92506] [10 Regression] Wrong code with -fwrapv since r277979

[amacleod at redhat dot com]

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

--- Comment #3 from Andrew Macleod  ---
Author: amacleod
Date: Thu Nov 14 19:02:48 2019
New Revision: 278259

URL: https://gcc.gnu.org/viewcvs?rev=278259=gcc=rev
Log:
2019-11-14  Andrew MacLeod  

PR tree-optimization/92506
* range-op.cc (range_operator::fold_range): Start with range undefined.
(operator_abs::wi_fold): Fix wrong line copy... With wrapv, abs with
overflow is varying.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/range-op.cc

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Sylvain Korzennik from comment #9)
> 1- that page does not tell me how to build a generic version
>./config.guess returns the same value on ea machine, as does gcc
> -dumpmachine
> x86_64-pc-linux-gnu
> 
> do I add --build=XX --host-XX or --target=XX and what XX to use? The
> doc is quite thin.

Well this is no longer a GCC question but rather a GMP question and you should
ask in their mailing list.  But when built inside GCC, the following configure
options are passed to GMP:
--build=${build_alias} --host=none-${host_vendor}-${host_os} \
  --target=none-${host_vendor}-${host_os} 



> 2- you're not telling me if I need to rebuild all 4 components.


It depends on if you built them as shared libraries are static libraries.  If
as shared, 99% sure you don't need to rebuild all 4, just GMP.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[skorzennik at cfa dot harvard.edu]

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

--- Comment #9 from Sylvain Korzennik  ---
1- that page does not tell me how to build a generic version
   ./config.guess returns the same value on ea machine, as does gcc
-dumpmachine
x86_64-pc-linux-gnu

do I add --build=XX --host-XX or --target=XX and what XX to use? The
doc is quite thin.

2- you're not telling me if I need to rebuild all 4 components.

  Cheers,
Sylvain
--

On Thu, Nov 14, 2019 at 1:39 PM pinskia at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
>
> --- Comment #8 from Andrew Pinski  ---
> (In reply to Andrew Pinski from comment #7)
> > Please read:
> > https://gmplib.org/manual/Build-Options.html
>
> NOTE also if you compile GMP/MPF/MPC as part of the GCC build, it will do the
> correct thing and compile it for a generic cpu.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
Please read:
https://gmplib.org/manual/Build-Options.html

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Please read:
> https://gmplib.org/manual/Build-Options.html

NOTE also if you compile GMP/MPF/MPC as part of the GCC build, it will do the
correct thing and compile it for a generic cpu.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[skorzennik at cfa dot harvard.edu]

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

--- Comment #6 from Sylvain Korzennik  ---
Thanks for your prompt replies!

1- we use a NSF mounted disk to serve ~90 servers (~4100 cores), w/ a
set of diff CPUs. It does compile fine on the server the code was
built on.

2- what flags do I use to built it for all the servers pn my system?
Do I need to redo this for all 4 (gcc/gmp/mpc/mpfr)?
  This cluster hosts the following CPUs
bulldozer,haswell,piledriver,sandybridge,skylake

  Cheers,
Sylvain
--

  Cheers,
Sylvain
--


On Thu, Nov 14, 2019 at 1:17 PM pinskia at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
>
> --- Comment #4 from Andrew Pinski  ---
> Is your MPFR/GMP/MPC compiled on a different computer and then copied over?  
> If
> so you need an extra configure flag to them; otherwise they will be compiled
> for that computer (CPU) and will not always work on all x86_64 processors.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[skorzennik at cfa dot harvard.edu]

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

--- Comment #5 from Sylvain Korzennik  ---
Thanks for your prompt replies!

1- we use a NSF mounted disk to serve ~90 servers (~4100 cores), w/ a set
of diff CPUs. It does compile fine on the server the code was built on.

2- what flags do I use to built it for all the servers pn my system? Do I
need to redo this for all 4 (gcc/gmp/mpc/mpfr)?
  This cluster hosts the following CPUs
bulldozer,haswell,piledriver,sandybridge,skylake

  Cheers,
Sylvain
--


On Thu, Nov 14, 2019 at 1:17 PM pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
>
> --- Comment #4 from Andrew Pinski  ---
> Is your MPFR/GMP/MPC compiled on a different computer and then copied
> over?  If
> so you need an extra configure flag to them; otherwise they will be
> compiled
> for that computer (CPU) and will not always work on all x86_64 processors.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[aleksei.voity...@bell-sw.com]

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

--- Comment #17 from Aleksei Voitylov  ---
(In reply to Andrew Pinski from comment #14)
> Have you tested gcc 7.5.0 that was just released?  How about gcc 8.x? Have
> you tried that.  There has been aliasing bugs in gcc before and this might
> already been fixed.

I just built ToT cross-gcc and the result is the same.

$ arm-linux-gnueabihf-gcc  --version
arm-linux-gnueabihf-gcc (GCC) 10.0.0 20191023 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Is your MPFR/GMP/MPC compiled on a different computer and then copied over?  If
so you need an extra configure flag to them; otherwise they will be compiled
for that computer (CPU) and will not always work on all x86_64 processors.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[skorzennik at cfa dot harvard.edu]

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

--- Comment #3 from Sylvain Korzennik  ---
=> gcc-9.2.0/do-configure.sou <==
module load gcc/8.2.0
./configure --prefix=/share/apps/tools/gcc/9.2.0 \
--enable-shared \
--disable-multilib \
--enable-threads=posix \
--enable-__cxa_atexit \
--disable-bootstrap \
--with-mpc=/share/apps/tools/gcc/mpc-1.0.3   \
--with-gmp=/share/apps/tools/gcc/gmp-6.1.0   \
--with-mpfr=/share/apps/tools/gcc/mpfr-3.1.4 \
 |& tee do-configure.log

==> gmp-6.1.0/do-configure.sou <==
module load gcc/8.2.0
./configure --prefix=/share/apps/tools/gcc/gmp-6.1.0   \
 |& tee do-configure.log

==> mpc-1.0.3/do-configure.sou <==
module load gcc/8.2.0
./configure --prefix=/share/apps/tools/gcc/mpc-1.0.3 \
--with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \
--with-mpfr=/share/apps/tools/gcc/mpfr-3.1.4 \
 |& tee do-configure.log

==> mpfr-3.1.4/do-configure.sou <==
module load gcc/8.2.0
./configure --prefix=/share/apps/tools/gcc/mpfr-3.1.4 \
--with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \
 |& tee do-configure.log

I used my build of gcc 8.2.0 - compiling the same test code  works w/ 8.2.0.

  Cheers,
Sylvain
--

  Cheers,
Sylvain
--


On Thu, Nov 14, 2019 at 12:43 PM pinskia at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
>
> Andrew Pinski  changed:
>
>What|Removed |Added
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2019-11-14
>  Ever confirmed|0   |1
>
> --- Comment #1 from Andrew Pinski  ---
> Usually this crash is a sign that MPFR/GMP was compiled for the wrong CPU.
>
> How did you compile GCC here?  How was MPFR/GMP compiled too?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[skorzennik at cfa dot harvard.edu]

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

--- Comment #2 from Sylvain Korzennik  ---
==> gcc-9.2.0/do-configure.sou <==
module load gcc/8.2.0
./configure --prefix=/share/apps/tools/gcc/9.2.0 \
--enable-shared \
--disable-multilib \
--enable-threads=posix \
--enable-__cxa_atexit \
--disable-bootstrap \
--with-mpc=/share/apps/tools/gcc/mpc-1.0.3   \
--with-gmp=/share/apps/tools/gcc/gmp-6.1.0   \
--with-mpfr=/share/apps/tools/gcc/mpfr-3.1.4 \
 |& tee do-configure.log

==> gmp-6.1.0/do-configure.sou <==
module load gcc/8.2.0
./configure --prefix=/share/apps/tools/gcc/gmp-6.1.0   \
 |& tee do-configure.log

==> mpc-1.0.3/do-configure.sou <==
module load gcc/8.2.0
./configure --prefix=/share/apps/tools/gcc/mpc-1.0.3 \
--with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \
--with-mpfr=/share/apps/tools/gcc/mpfr-3.1.4 \
 |& tee do-configure.log

==> mpfr-3.1.4/do-configure.sou <==
module load gcc/8.2.0
./configure --prefix=/share/apps/tools/gcc/mpfr-3.1.4 \
--with-gmp=/share/apps/tools/gcc/gmp-6.1.0 \
 |& tee do-configure.log

I used my build of gcc 8.2.0 - compiling the same test code  works w/ 8.2.0.

  Cheers,
Sylvain
--


On Thu, Nov 14, 2019 at 12:43 PM pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92514
>
> Andrew Pinski  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2019-11-14
>  Ever confirmed|0   |1
>
> --- Comment #1 from Andrew Pinski  ---
> Usually this crash is a sign that MPFR/GMP was compiled for the wrong CPU.
>
> How did you compile GCC here?  How was MPFR/GMP compiled too?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/92514] limits:1668:7: internal compiler error: Illegal instruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-11-14
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Usually this crash is a sign that MPFR/GMP was compiled for the wrong CPU.

How did you compile GCC here?  How was MPFR/GMP compiled too?

[Bug middle-end/88226] missing warning on fprintf, fputs, and puts with an unterminated array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.0

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01238.html

[Bug tree-optimization/92501] strncmp with constant unterminated arrays not folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-14
   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  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01233.html

[Bug c++/92514] New: limits:1668:7: internal compiler error: Illegal instruction

[skorzennik at cfa dot harvard.edu]

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

Bug ID: 92514
   Summary: limits:1668:7: internal compiler error: Illegal
instruction
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skorzennik at cfa dot harvard.edu
  Target Milestone: ---

Created attachment 47266
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47266=edit
.ii and .log files

In file included from
/share/apps/tools/gcc/9.2.0/include/c++/9.2.0/bits/uniform_int_dist.h:35,
 from
/share/apps/tools/gcc/9.2.0/include/c++/9.2.0/bits/stl_algo.h:66,
 from
/share/apps/tools/gcc/9.2.0/include/c++/9.2.0/algorithm:62,
 from test-array.cpp:4:
/share/apps/tools/gcc/9.2.0/include/c++/9.2.0/limits:1668:7: internal compiler
error: Illegal instruction
 1668 |   max() _GLIBCXX_USE_NOEXCEPT { return __FLT_MAX__; }
  |   ^~~
0xb5775f crash_signal
../.././gcc/toplev.c:326

attached is the output of 
g++ -v -std=c++11 -save-temps test-array.cpp -o test-array
and the resulting
test-array.ii
the test code (test-array.cpp) is measly 17 lines long.

[Bug tree-optimization/92506] [10 Regression] Wrong code with -fwrapv since r277979

[amacleod at redhat dot com]

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

--- Comment #2 from Andrew Macleod  ---
Created attachment 47265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47265=edit
patch to resolve the issue

Traced it back to a typo in operator_abs::fold_range() when I did the
conversion where the wrong line got copied in..  

Instead of returning value_range (type) when a overflow happens, it was
returning the same result of the previous check, which was the case for all
positives.
This had EVRP setting the range of an ABS to [-MIN, -1] instead of varying,
which later caused VRP to intersect that with 0 - [-MIN, -1] and all heck broke
loose. doh.

I also stumbled across a case where we should be starting with undefined in the
default fold_range() and building with union for each sub-range.  We previously
declared a local value_range to work with, and that defaulted to undefined. 
When I changed it to a reference parameter, I need to explicitly initialize it.

I will check this in once it passes bootstrap

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
Whether memcpy needs to preserve the value of padding bits is debatable (and
has been debated in WG14 for a couple of decades now).  The value of padding
bits is described as unspecified, and an unspecified value is described as a
"valid value of the relevant type where this International Standard imposes no
requirements on which value is chosen in any instance."  The "chosen in any
instance" has been interpreted as permitting the observed value to change from
one read to another.  Examples of this effect are in DR #260 and DR #451. 
Although they deal with uninitialized objects whose value is indeterminate,
since objects of types like char have no trap representation, their
uninitialized and indeterminate value is simply unspecified, same as that of
padding bits.

[Bug rtl-optimization/92430] [9 Regression] Compile-time hog w/ -Os -fno-if-conversion -fno-tree-dce -fno-tree-loop-optimize -fno-tree-vrp

[iii at gcc dot gnu.org]

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

--- Comment #7 from iii at gcc dot gnu.org ---
Author: iii
Date: Thu Nov 14 16:40:33 2019
New Revision: 278254

URL: https://gcc.gnu.org/viewcvs?rev=278254=gcc=rev
Log:
Make flag_thread_jumps a gate of pass_jump_after_combine

This is a follow-up to
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00919.html (r278095).
Dominance info is deleted even if we don't perform jump threading.
Since the whole point of this pass is to perform jump threading (other
cleanups are not valuable at this point), skip it completely when
flag_thread_jumps is not set.

gcc/ChangeLog:

2019-11-14  Ilya Leoshkevich  

PR rtl-optimization/92430
* cfgcleanup.c (pass_jump_after_combine::gate): New function.
(pass_jump_after_combine::execute): Perform jump threading
unconditionally.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
I have another idea, cant we add fake field decls while doing structure layout?
Then sra total scalarization will just work. And there is no other magic in the
compiler needed?

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On November 14, 2019 5:11:55 PM GMT+01:00, "jamborm at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
>
>--- Comment #5 from Martin Jambor  ---
>While I don't share this preference about assignments, SRA only
>ignores padding when doing "total scalarization" aka the poor man's
>aggregate copy propagation because in that mode it would have to
>invent small accesses to copy padding and I'm sure some people would
>be unhappy about those.

Doing total scalarization as block copy in naturally aligned pieces would be
another option, no?

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
While I don't share this preference about assignments, SRA only
ignores padding when doing "total scalarization" aka the poor man's
aggregate copy propagation because in that mode it would have to
invent small accesses to copy padding and I'm sure some people would
be unhappy about those.

[Bug libgomp/92511] [OpenACC] Support subset subarray mappings

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-14
   Assignee|unassigned at gcc dot gnu.org  |jules at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Julian, please fix this in GCC trunk, and we shall later see about backporting
to other release branches.

[Bug c++/92509] auto deduction on different types does not emit diagnostic message

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
We fail to diagnose it in a template when the initializers are dependent.

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

[Bug c++/79009] Missing 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||g...@nicholas-schwab.de

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

[Bug tree-optimization/92512] New: [10 Regression] ICE in gimple_op, at gimple.h:2436

[asolokha at gmx dot com]

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

Bug ID: 92512
   Summary: [10 Regression] ICE in gimple_op, at gimple.h:2436
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20191110 snapshot (r278028) ICEs when compiling the following
testcase w/ -O1 -ftree-loop-vectorize:

long int
nl (long int fy, int k3, int zr)
{
  while (k3 < 1)
{
  if (zr == 0)
fy = 0;

  fy *= fy < zr;
  ++k3;
}

  return fy;
}

% gcc-10.0.0-alpha20191110 -O1 -ftree-loop-vectorize -c hgqw913o.c
during GIMPLE pass: vect
hgqw913o.c: In function 'nl':
hgqw913o.c:2:1: internal compiler error: in gimple_op, at gimple.h:2436
2 | nl (long int fy, int k3, int zr)
  | ^~
0x6baea6 gimple_op
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/gimple.h:2436
0x6bccb3 gimple_op
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/is-a.h:197
0x6bccb3 vectorizable_reduction(_stmt_vec_info*, _slp_tree*, _slp_instance*,
vec*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-vect-loop.c:5807
0xe99582 vect_analyze_loop_operations
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-vect-loop.c:1567
0xe9a94f vect_analyze_loop_2
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-vect-loop.c:2106
0xe9a94f vect_analyze_loop(loop*, vec_info_shared*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-vect-loop.c:2417
0xeb72c2 try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-vectorizer.c:892
0xeb7c6d vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-vectorizer.c:1125

[Bug tree-optimization/92513] New: [10 Regression] ICE: tree check: expected ssa_name, have integer_cst in maybe_replace_use, at tree-into-ssa.c:1817

[asolokha at gmx dot com]

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

Bug ID: 92513
   Summary: [10 Regression] ICE: tree check: expected ssa_name,
have integer_cst in maybe_replace_use, at
tree-into-ssa.c:1817
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20191110 snapshot (r278028) ICEs when compiling the following
testcase w/ -O2 -ftree-loop-vectorize:

int lo;

void
wx (int a6)
{
  int iv;
  short int *ea = (short int *) 

  *ea <<= 16;
  for (iv = 0; iv < 73; ++iv)
{
  lo *= *ea;
  ea = (short int *) 
}
}

% gcc-10.0.0-alpha20191110 -O2 -ftree-loop-vectorize -c isyxzv5m.c
during GIMPLE pass: vect
isyxzv5m.c: In function 'wx':
isyxzv5m.c:4:1: internal compiler error: tree check: expected ssa_name, have
integer_cst in maybe_replace_use, at tree-into-ssa.c:1817
4 | wx (int a6)
  | ^~
0x6c3069 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree.c:9685
0x681310 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree.h:3272
0x681310 maybe_replace_use
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-into-ssa.c:1817
0x681310 rewrite_update_stmt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-into-ssa.c:2041
0x681310 rewrite_update_dom_walker::before_dom_children(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-into-ssa.c:
0x681310 rewrite_update_dom_walker::before_dom_children(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-into-ssa.c:2162
0x1419c7a dom_walker::walk(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/domwalk.c:309
0xcf90b2 rewrite_blocks
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-into-ssa.c:2286
0xcfdcc0 update_ssa(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-into-ssa.c:3489
0xda8d1d rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-ssa-loop-manip.c:639
0xeb7b45 vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/tree-vectorizer.c:1196

[Bug libgomp/92511] New: [OpenACC] Support subset subarray mappings

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92511
   Summary: [OpenACC] Support subset subarray mappings
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, patch
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---

As discussed in
, we have to
support "subset" subarray mappings.

[Bug rtl-optimization/83361] [7 Regression ?] ICE: verify_flow_info failed (error: non-cold basic block 3 reachable only by paths crossing the cold partition) on 32-bit BE powerpc targets

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #10 from Segher Boessenkool  ---
Yup, done.  Thanks!

[Bug other/92366] new test case gcc.dg/vect/bb-slp-41.c fails with its introduction in r277784

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Taking this since I need to update the test for
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02063.html

[Bug tree-optimization/92163] [10 Regression] ICE: Segmentation fault (in bitmap_set_bit)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #9 from Arseny Solokha  ---
Fixed.

[Bug target/80938] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #13 from Segher Boessenkool  ---
Okay, closing.  Thanks.

[Bug rtl-optimization/92510] New: [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272

[asolokha at gmx dot com]

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

Bug ID: 92510
   Summary: [10 Regression] ICE in native_encode_rtx, at
simplify-rtx.c:6272
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20191110 snapshot (r278028) ICEs when compiling the following
testcase w/ -O1 -ftree-loop-vectorize -fno-forward-propagate
-fno-tree-scev-cprop:

int cg;

long int
fp (long int sq)
{
  signed char z1;

  for (z1 = 0; z1 < 8; ++z1)
sq |= !!cg;

  return sq + z1;
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191110 -O1 -ftree-loop-vectorize
-fno-forward-propagate -fno-tree-scev-cprop -c nh0rq49t.c
during RTL pass: combine
nh0rq49t.c: In function 'fp':
nh0rq49t.c:12:1: internal compiler error: in native_encode_rtx, at
simplify-rtx.c:6272
   12 | }
  | ^
0x665fd0 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/simplify-rtx.c:6272
0xc561be simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/simplify-rtx.c:6714
0xc5673e simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/simplify-rtx.c:7003
0x13eb54a if_then_else_cond
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:9474
0x13eb3c1 if_then_else_cond
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:9339
0x13f7c4f combine_simplify_rtx
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:5839
0x13fa5ac subst
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:5721
0x13fa1f9 subst
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:5654
0x13fa421 subst
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:5583
0x13fc2e5 try_combine
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:3413
0x14023a1 combine_instructions
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:1305
0x14023a1 rest_of_handle_combine
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:15058
0x14023a1 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191110/work/gcc-10-20191110/gcc/combine.c:15103

[Bug target/92462] [arm32] -ftree-pre makes a variable to be wrongly hoisted out

[wilco at gcc dot gnu.org]

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

--- Comment #16 from Wilco  ---
(In reply to Richard Biener from comment #15)
> I can't find PRE doing anything wrong and on 32bit x86_64 the testcase
> executes
> correctly with GCC 7.3 and GCC 9 (when I add the missing return to
> Bar::cmpxchg).
> So -ftree-pre, if it triggers a bug, triggers it elsewhere, the bug isn't in
> PRE itself AFAICS.

Well the difference is that one of the loads is removed by dse1:


**scanning insn=26
cselib lookup (reg/f:SI 102 sfp) => 8:8
cselib lookup (reg/f:SI 126) => 9:4339
cselib lookup (reg/f:SI 102 sfp) => 8:8
cselib lookup (reg/f:SI 102 sfp) => 8:8
cselib lookup (plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8])) => 9:4339
  mem: (plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8]))

   after canon_rtx address: (plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8]))
  gid=1 offset=-8
 processing const load gid=1[-8..-4)
trying to replace SImode load in insn 26 from SImode store in insn 16
deferring rescan insn with uid = 26.
deferring rescan insn with uid = 77.
 -- replaced the loaded MEM with (reg 144)
mems_found = 0, cannot_delete = true
cselib lookup (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -8 [0xfff8])) [1 curD.6314+0 S4 A64]) => 0:0

[Bug c++/92509] New: auto deduction on different types does not emit diagnostic message

[g...@nicholas-schwab.de]

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

Bug ID: 92509
   Summary: auto deduction on different types does not emit
diagnostic message
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@nicholas-schwab.de
  Target Milestone: ---

Created attachment 47264
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47264=edit
Preprocessed file on which the error occurs.

By the standard, "if the type that replaces the placeholder type is not the
same in each deduction, the program is ill-formed." Hence the declaration 

auto i = 0l, j = 0.0;

should emit a diagnostic message, as it does with an error message. In a more
complex case (prepocessed file attached) this compiles without warning or
error. Was discussed on
https://stackoverflow.com/questions/58855626/mismatched-deduction-of-auto-types-between-different-c-compilers/58856708#58856708

Compiler call:
g++ -v  -Wextra -Wall dot.cpp
(preprocessed file created with g++ -save-temps  -Wextra -Wall dot.cpp)

Compiler Output:
None

GCC information:
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++,d --enable-shared
--enable-threads=posix --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 gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Marek Polacek from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > (In reply to Marek Polacek from comment #2)
> > > The quux case: CONSTRUCTOR_NO_CLEARING is cleared here
> > > 
> > > 2154   /* The result of a constexpr function must be completely 
> > > initialized.
> > > */
> > > 2155   if (TREE_CODE (result) == CONSTRUCTOR)
> > > 2156 clear_no_implicit_zero (result);
> > > 
> > > but we can no longer assume that a constexpr constructor has initialized 
> > > all
> > > the members.
> > 
> > I'd think we can still assume it for non-constructors (because if a function
> > returns some aggregate, it went through the lvalue to rvalue conversion and
> > therefore shouldn't refer to uninitialized members).  Constructors don't
> > really
> > return the object they are initializing.  Though, perhaps we should make a
> > difference between constructors that do have member initializers for all
> > members and those that don't.
> 
> I'm experimenting with the last -- add an allow_missing param to
> cx_check_missing_mem_inits and don't clear the flag when there are inits
> missing.

... unless the initializer is { } in which case we're performing aggregate-init
or value-init so the flag ought to be cleared.

[Bug fortran/69654] ICE in gfc_trans_structure_assign

[talebi.hossein at gmail dot com]

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

--- Comment #8 from Hossein Talebi  ---
Hi Paul,

Thanks for following up on this. I actually changed my programming language
for this bug, just kidding :-).

Cheers
Hossein


On Thu, 14 Nov 2019, 16:05 pault at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654
>
> --- Comment #7 from Paul Thomas  ---
> Dear Hossein,
>
> This news is probably 1,379 days too late for you - I am just about to
> post a
> fix for this bug. I do apologise for the long delay but, for some reason,
> I saw
> the problem right away today having failed to do so on my previous
> explorations.
>
> Best regards
>
> Paul
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug rtl-optimization/80491] [7 Regression] Compiler regression for long-add case.

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #18 from Segher Boessenkool  ---
Reopening then, comments 15..17 say it is not fixed yet.

[Bug tree-optimization/80520] [8/9/10 Regression] Performance regression from missing if-conversion

[segher at gcc dot gnu.org]

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

Bug 80491 Summary: [7 Regression] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491

   What|Removed |Added

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

[Bug target/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

[segher at gcc dot gnu.org]

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

Bug 80491 Summary: [7 Regression] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491

   What|Removed |Added

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

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Marek Polacek from comment #2)
> > The quux case: CONSTRUCTOR_NO_CLEARING is cleared here
> > 
> > 2154   /* The result of a constexpr function must be completely initialized.
> > */
> > 2155   if (TREE_CODE (result) == CONSTRUCTOR)
> > 2156 clear_no_implicit_zero (result);
> > 
> > but we can no longer assume that a constexpr constructor has initialized all
> > the members.
> 
> I'd think we can still assume it for non-constructors (because if a function
> returns some aggregate, it went through the lvalue to rvalue conversion and
> therefore shouldn't refer to uninitialized members).  Constructors don't
> really
> return the object they are initializing.  Though, perhaps we should make a
> difference between constructors that do have member initializers for all
> members and those that don't.

I'm experimenting with the last -- add an allow_missing param to
cx_check_missing_mem_inits and don't clear the flag when there are inits
missing.

Something to consider: unions will never have initialized all its members.

[Bug tree-optimization/69728] [7 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[asolokha at gmx dot com]

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

--- Comment #26 from Arseny Solokha  ---
This this PR be closed now?

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #2)
> The quux case: CONSTRUCTOR_NO_CLEARING is cleared here
> 
> 2154   /* The result of a constexpr function must be completely initialized.
> */
> 2155   if (TREE_CODE (result) == CONSTRUCTOR)
> 2156 clear_no_implicit_zero (result);
> 
> but we can no longer assume that a constexpr constructor has initialized all
> the members.

I'd think we can still assume it for non-constructors (because if a function
returns some aggregate, it went through the lvalue to rvalue conversion and
therefore shouldn't refer to uninitialized members).  Constructors don't really
return the object they are initializing.  Though, perhaps we should make a
difference between constructors that do have member initializers for all
members and those that don't.

[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #12 from Paul Thomas  ---
This indeed appears to be fixed. Closing.

Paul

[Bug fortran/69654] ICE in gfc_trans_structure_assign

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Dear Hossein,

This news is probably 1,379 days too late for you - I am just about to post a
fix for this bug. I do apologise for the long delay but, for some reason, I saw
the problem right away today having failed to do so on my previous
explorations.

Best regards

Paul

[Bug tree-optimization/71144] [8/9/10 Regression] isl_aff.c:1001: position out of bounds

[asolokha at gmx dot com]

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

--- Comment #12 from Arseny Solokha  ---
I believe this PR can be closed, per comment 9 (and likely comment 7).