[Bug target/100014] New: MSDOS DJGPP host endian unknown

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 100014
   Summary: MSDOS DJGPP host endian unknown
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Configuring in ./gcc
configure: loading cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... i586-pc-msdosdjgpp
checking target system type... i586-pc-msdosdjgpp

...
checking whether byte ordering is bigendian... unknown
configure: error: unknown endianness
 presetting ac_cv_c_bigendian=no (or yes) will help
make[1]: *** [Makefile:4395: configure-gcc] Error 1
make[1]: Leaving directory '/home/cqwrteur/myhome/msdos_hosted_toolchain/gcc'
make: *** [Makefile:979: all] Error 2

[Bug bootstrap/100013] libiberty error PATH_MAX does not exist on DJGPP host.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
https://sourceware.org/bugzilla/show_bug.cgi?id=27716

[Bug bootstrap/100013] libiberty error PATH_MAX does not exist on DJGPP host.

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

 Target||i586-msdosdjgpp
   Host||i586-msdosdjgpp
  Build||x86_64-w64-mingw32 (windows
   ||10) and x86_64-linux-gnu or
   ||any other
 CC||unlvsur at live dot com

--- Comment #1 from cqwrteur  ---
https://sourceware.org/bugzilla/show_bug.cgi?id=27716

[Bug bootstrap/100013] New: libiberty error PATH_MAX does not exist on DJGPP host.

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 100013
   Summary: libiberty error PATH_MAX does not exist on DJGPP host.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

The same issue happens on binutils-gdb too because they both include libiberty.
However, I do not know where to report this to libiberty upstream.



In file included from ../../../gcc/libiberty/getpwd.c:33:
../../../gcc/libiberty/getpwd.c: In function 'getpwd':
../../../gcc/libiberty/getpwd.c:55:23: error: 'PATH_MAX' undeclared (first use
in this function)
   55 | #define GUESSPATHLEN (MAXPATHLEN + 1)
  |   ^~
../../../gcc/libiberty/getpwd.c:87:18: note: in expansion of macro
'GUESSPATHLEN'
   87 | for (s = GUESSPATHLEN;  !getcwd (p = XNEWVEC (char, s), s);  s
*= 2)
  |  ^~~~
../../../gcc/libiberty/getpwd.c:55:23: note: each undeclared identifier is
reported only once for each function it appears in
   55 | #define GUESSPATHLEN (MAXPATHLEN + 1)
  |   ^~
../../../gcc/libiberty/getpwd.c:87:18: note: in expansion of macro
'GUESSPATHLEN'
   87 | for (s = GUESSPATHLEN;  !getcwd (p = XNEWVEC (char, s), s);  s
*= 2)
  |  ^~~~
make[2]: *** [Makefile:873: getpwd.o] Error 1
make[2]: *** Waiting for unfinished jobs
/home/cqwrteur/myhome/gcc/isl/configure: line 3468: cd:
/home/cqwrteur/i586-msdosdjgpp_host: No such file or directory
make[1]: *** [Makefile:9700: all-libiberty] Error 2
make[1]: *** Waiting for unfinished jobs
configure: WARNING: using cross tools not prefixed with host triplet
configure: WARNING: using cross tools not prefixed with host triplet
make: *** [Makefile:979: all] Error 2

[Bug c++/100012] MSDOS DJGPP host no socket while libcody does not block this

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
Created attachment 50542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50542=edit
disable networking on MSDOS

[Bug c++/100012] New: MSDOS DJGPP host no socket while libcody does not block this

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 100012
   Summary: MSDOS DJGPP host no socket while libcody does not
block this
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

../../../gcc/libcody/cody.hh:33:10: fatal error: sys/socket.h: No such file or
directory
   33 | #include 
  |  ^~
compilation terminated.
yes
make[2]: *** [Makefile:58: packet.o] Error 1
In file included from ../../../gcc/libcody/internal.hh:5,
 from ../../../gcc/libcody/resolver.cc:6:
../../../gcc/libcody/cody.hh:33:10: fatal error: sys/socket.h: No such file or
directory
   33 | #include 

[Bug c++/99180] [10 Regression] ICE with alias template and empty parameter pack

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #7 from Jason Merrill  ---
*** Bug 93295 has been marked as a duplicate of this bug. ***

[Bug c++/93295] ICE in alias_ctad_tweaks

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #12 from Jason Merrill  ---
Let's call this a duplicate of the one that already has the regression tag.

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

[Bug c++/93295] ICE in alias_ctad_tweaks

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||mateusz.pusz at gmail dot com

--- Comment #11 from Jason Merrill  ---
*** Bug 96873 has been marked as a duplicate of this bug. ***

[Bug c++/96873] Internal compiler error in alias_ctad_tweaks

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Dup.

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

[Bug c++/93295] ICE in alias_ctad_tweaks

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||wang_feng at live dot com

--- Comment #10 from Jason Merrill  ---
*** Bug 99118 has been marked as a duplicate of this bug. ***

[Bug c++/99118] ICE in alias_ctad_tweaks, at cp/pt.c:28569

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Dup.

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

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93295

--- Comment #7 from Jason Merrill  ---
(In reply to Johel Ernesto Guerrero Peña from comment #5)
> Thank you. I was under the mistaken impression that the above was only a
> partial solution. Adding the following deduction guide restores the ICE. See
> https://godbolt.org/z/fej7WT.
> ```C++
> template
> X(U) -> X;
> ```

That's bug 93295; let's leave this PR as the issue Patrick fixed.

[Bug c++/99180] [10 Regression] ICE with alias template and empty parameter pack

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[10/11 Regression] ICE with |[10 Regression] ICE with
   |alias template and empty|alias template and empty
   |parameter pack  |parameter pack

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

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1a19d334ce493ec2ce2daeac74beef63fd67e2bc

commit r11-8104-g1a19d334ce493ec2ce2daeac74beef63fd67e2bc
Author: Jason Merrill 
Date:   Fri Apr 9 18:02:38 2021 -0400

c++: deduction guide using alias [PR99180]

alias_ctad_tweaks was expecting that all deduction guides for the class
would be suitable for deduction from the alias definition; in this case,
the
deduction guide uses 'true' and the alias B uses 'false', so deduction
fails.  But that's OK, we just don't use that deduction guide.  I also
noticed that we were giving up on deduction entirely if substitution failed
for some guide; we should only give up on that particular deduction guide.

We ought to give a better diagnostic about this case when deduction fails,
but that can wait.

gcc/cp/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/99118
PR c++/96873
* pt.c (alias_ctad_tweaks): Handle failure better.

gcc/testsuite/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/95486
* g++.dg/cpp2a/class-deduction-alias5.C: New test.
* g++.dg/cpp2a/class-deduction-alias6.C: New test.
* g++.dg/cpp2a/class-deduction-alias7.C: New test.
* g++.dg/cpp2a/class-deduction-alias8.C: New test.

[Bug c++/96873] Internal compiler error in alias_ctad_tweaks

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1a19d334ce493ec2ce2daeac74beef63fd67e2bc

commit r11-8104-g1a19d334ce493ec2ce2daeac74beef63fd67e2bc
Author: Jason Merrill 
Date:   Fri Apr 9 18:02:38 2021 -0400

c++: deduction guide using alias [PR99180]

alias_ctad_tweaks was expecting that all deduction guides for the class
would be suitable for deduction from the alias definition; in this case,
the
deduction guide uses 'true' and the alias B uses 'false', so deduction
fails.  But that's OK, we just don't use that deduction guide.  I also
noticed that we were giving up on deduction entirely if substitution failed
for some guide; we should only give up on that particular deduction guide.

We ought to give a better diagnostic about this case when deduction fails,
but that can wait.

gcc/cp/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/99118
PR c++/96873
* pt.c (alias_ctad_tweaks): Handle failure better.

gcc/testsuite/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/95486
* g++.dg/cpp2a/class-deduction-alias5.C: New test.
* g++.dg/cpp2a/class-deduction-alias6.C: New test.
* g++.dg/cpp2a/class-deduction-alias7.C: New test.
* g++.dg/cpp2a/class-deduction-alias8.C: New test.

[Bug c++/99118] ICE in alias_ctad_tweaks, at cp/pt.c:28569

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1a19d334ce493ec2ce2daeac74beef63fd67e2bc

commit r11-8104-g1a19d334ce493ec2ce2daeac74beef63fd67e2bc
Author: Jason Merrill 
Date:   Fri Apr 9 18:02:38 2021 -0400

c++: deduction guide using alias [PR99180]

alias_ctad_tweaks was expecting that all deduction guides for the class
would be suitable for deduction from the alias definition; in this case,
the
deduction guide uses 'true' and the alias B uses 'false', so deduction
fails.  But that's OK, we just don't use that deduction guide.  I also
noticed that we were giving up on deduction entirely if substitution failed
for some guide; we should only give up on that particular deduction guide.

We ought to give a better diagnostic about this case when deduction fails,
but that can wait.

gcc/cp/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/99118
PR c++/96873
* pt.c (alias_ctad_tweaks): Handle failure better.

gcc/testsuite/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/95486
* g++.dg/cpp2a/class-deduction-alias5.C: New test.
* g++.dg/cpp2a/class-deduction-alias6.C: New test.
* g++.dg/cpp2a/class-deduction-alias7.C: New test.
* g++.dg/cpp2a/class-deduction-alias8.C: New test.

[Bug c++/93867] ICE using class type NTTPs and class template argument deduction

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1a19d334ce493ec2ce2daeac74beef63fd67e2bc

commit r11-8104-g1a19d334ce493ec2ce2daeac74beef63fd67e2bc
Author: Jason Merrill 
Date:   Fri Apr 9 18:02:38 2021 -0400

c++: deduction guide using alias [PR99180]

alias_ctad_tweaks was expecting that all deduction guides for the class
would be suitable for deduction from the alias definition; in this case,
the
deduction guide uses 'true' and the alias B uses 'false', so deduction
fails.  But that's OK, we just don't use that deduction guide.  I also
noticed that we were giving up on deduction entirely if substitution failed
for some guide; we should only give up on that particular deduction guide.

We ought to give a better diagnostic about this case when deduction fails,
but that can wait.

gcc/cp/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/99118
PR c++/96873
* pt.c (alias_ctad_tweaks): Handle failure better.

gcc/testsuite/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/95486
* g++.dg/cpp2a/class-deduction-alias5.C: New test.
* g++.dg/cpp2a/class-deduction-alias6.C: New test.
* g++.dg/cpp2a/class-deduction-alias7.C: New test.
* g++.dg/cpp2a/class-deduction-alias8.C: New test.

[Bug c++/93295] ICE in alias_ctad_tweaks

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1a19d334ce493ec2ce2daeac74beef63fd67e2bc

commit r11-8104-g1a19d334ce493ec2ce2daeac74beef63fd67e2bc
Author: Jason Merrill 
Date:   Fri Apr 9 18:02:38 2021 -0400

c++: deduction guide using alias [PR99180]

alias_ctad_tweaks was expecting that all deduction guides for the class
would be suitable for deduction from the alias definition; in this case,
the
deduction guide uses 'true' and the alias B uses 'false', so deduction
fails.  But that's OK, we just don't use that deduction guide.  I also
noticed that we were giving up on deduction entirely if substitution failed
for some guide; we should only give up on that particular deduction guide.

We ought to give a better diagnostic about this case when deduction fails,
but that can wait.

gcc/cp/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/99118
PR c++/96873
* pt.c (alias_ctad_tweaks): Handle failure better.

gcc/testsuite/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/95486
* g++.dg/cpp2a/class-deduction-alias5.C: New test.
* g++.dg/cpp2a/class-deduction-alias6.C: New test.
* g++.dg/cpp2a/class-deduction-alias7.C: New test.
* g++.dg/cpp2a/class-deduction-alias8.C: New test.

[Bug c++/99180] [10/11 Regression] ICE with alias template and empty parameter pack

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:1a19d334ce493ec2ce2daeac74beef63fd67e2bc

commit r11-8104-g1a19d334ce493ec2ce2daeac74beef63fd67e2bc
Author: Jason Merrill 
Date:   Fri Apr 9 18:02:38 2021 -0400

c++: deduction guide using alias [PR99180]

alias_ctad_tweaks was expecting that all deduction guides for the class
would be suitable for deduction from the alias definition; in this case,
the
deduction guide uses 'true' and the alias B uses 'false', so deduction
fails.  But that's OK, we just don't use that deduction guide.  I also
noticed that we were giving up on deduction entirely if substitution failed
for some guide; we should only give up on that particular deduction guide.

We ought to give a better diagnostic about this case when deduction fails,
but that can wait.

gcc/cp/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/99118
PR c++/96873
* pt.c (alias_ctad_tweaks): Handle failure better.

gcc/testsuite/ChangeLog:

PR c++/99180
PR c++/93295
PR c++/93867
PR c++/95486
* g++.dg/cpp2a/class-deduction-alias5.C: New test.
* g++.dg/cpp2a/class-deduction-alias6.C: New test.
* g++.dg/cpp2a/class-deduction-alias7.C: New test.
* g++.dg/cpp2a/class-deduction-alias8.C: New test.

[Bug c++/100006] [8/9/10/11 Regression] ICE: in dependent_type_p, at cp/pt.c:26745

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-8103-ge89055f90cff9fb6f565b9374e1ab74f805682fb
Author: Jason Merrill 
Date:   Fri Apr 9 16:43:50 2021 -0400

c++: pack in base-specifier in lambda [PR16]

Normally cp_parser_base_clause prevents unexpanded packs, but in a lambda
check_for_bare_parameter_packs allows it.  Then we weren't finding the
pack when scanning the lambda body.

This doesn't fix a valid variant like

  template  void sink (Ts&&...);
  template 
  void f() {
sink ([] { struct S : Ts { }; }...);
  }
  int main() {
f();
  }

but that's a much bigger project.

gcc/cp/ChangeLog:

PR c++/16
* pt.c (find_parameter_packs_r) [TAG_DEFN]: Look into bases.

gcc/testsuite/ChangeLog:

PR c++/16
* g++.dg/cpp0x/lambda/lambda-variadic13.C: New test.

[Bug web/98898] [wwwdocs] typo in announcements web page of gcc-10

[icalder.76d8f at torfree dot net via Gcc-bugs]

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

Iain Calder  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Iain Calder  ---
The erroneous text was overwritten by the announcement for the subsequent
release (10.3).  The new text is not in error.

[Bug analyzer/100011] internal compiler error in analyzer during IPA pass

[raj.khem at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Khem Raj  ---
this one seems to be the cause

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3a66c289a3f395e50de79424e1e6f401a4dc1ab7

[Bug analyzer/100011] New: internal compiler error in analyzer during IPA pass

[raj.khem at gmail dot com via Gcc-bugs]

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

Bug ID: 100011
   Summary: internal compiler error in analyzer during IPA pass
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

I am seeing a ICE in gcc when compiling attached reduced testcase from gnutls
project. This is caused by 3a66c289a3f395e50de79424e1e6f401a4dc1ab7

done for #99042, #99774

a.i
=
void terminate(int sig)
{
 char buf[64] = { 0 };
 exit(1);
}

int main(int argc, char **argv)
{
 signal(0, terminate);
 return 0;
}
=

$ /tmp/gcc/gcc/cc1 a.i -fanalyzer

Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 884k}  {heap 884k} 
{heap 884k}  {heap 884k}  {heap 1076k}
 {heap 1076k}  {heap 1076k}Streaming LTO
 during IPA pass: analyzer
a.i: At top level:
a.i:10:9: internal compiler error: Segmentation fault
   10 |  return 0;
  | ^
0xdf96cf crash_signal
/home/kraj/work/gcc/gcc/toplev.c:327
0x11b4e06 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/home/kraj/work/gcc/gcc/analyzer/region-model.cc:729
0x195128a ana::diagnostic_manager::add_events_for_eedge(ana::path_builder
const&, ana::exploded_edge const&, ana::checker_path*) const
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1554
0x1951c04 ana::diagnostic_manager::build_emission_path(ana::path_builder
const&, ana::exploded_path const&, ana::checker_path*) const
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1183
0x1951dcb ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1128
0x195527f ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1051
0x1952250 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1100
0x119650c ana::impl_run_checkers(ana::logger*)
/home/kraj/work/gcc/gcc/analyzer/engine.cc:4887
0x11972dc ana::run_checkers()
/home/kraj/work/gcc/gcc/analyzer/engine.cc:4944
0x1189af8 execute
/home/kraj/work/gcc/gcc/analyzer/analyzer-pass.cc:87

[Bug lto/100010] New: ICE in lto_output_node, at lto-cgraph.c:447 (-fdevirtualize-at-ltrans)

[alex.miller at gmx dot de via Gcc-bugs]

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

Bug ID: 100010
   Summary: ICE in lto_output_node, at lto-cgraph.c:447
(-fdevirtualize-at-ltrans)
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex.miller at gmx dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Building lcdf-typetools-2.108 fails with an ICE while linking the mmafm tool
(with gcc-10 using the flags "-O3 -flto -fdevirtualize-at-ltrans").

Here's a reduced sample that reproduces the issue (even with -O2):
---
struct String {
String(char);
~String();
};
struct ErrorHandler {
virtual String decorate(const String &);
};
String ErrorHandler::decorate(const String ) {
decorate(str);
return 0;
}
struct LandmarkErrorHandler : ErrorHandler {
String _landmark;
LandmarkErrorHandler();
String decorate(const String &);
};
String LandmarkErrorHandler::decorate(const String &) {
return ErrorHandler::decorate(0);
}
struct Charstring {
virtual ~Charstring();
virtual void process() = 0;
} *interpret_cs;
Charstring::~Charstring() {}
struct : Charstring {
void process() {}
} _cdv;
int main() {
LandmarkErrorHandler();
interpret_cs->process();
}
---

$ g++ -O2 -flto -fdevirtualize-at-ltrans a.cc
during IPA pass: static-var
lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:447
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Reducing the sources seems a bit brittle, like often with LTO:
* Combining all sources in a single file changed the error message to
  "lto1: internal compiler error: Segmentation fault", but minimizing made
  the error location reappear. The result is very similar to a multi-file
  reduction.
* Reduced sample fails with -O2, full sources need -O3.
* With g++-9.3.0 the reduced sample doesn't trigger the ICE, but the original
  sources do (at lto-cgraph.c:453).
Let me know if you need another sample.

[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless

[ahuszagh at gmail dot com via Gcc-bugs]

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

Alexander Huszagh  changed:

   What|Removed |Added

 CC||ahuszagh at gmail dot com

--- Comment #13 from Alexander Huszagh  ---
Any chance we can merge the proposed patch on this? This still triggers in
GCC-10.2.1, and the proposed patch works if applied to both `sort()` and
`sort(cmp)` implementations in `include/bits/list.tcc`.

Version Info:
gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)

[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'

[chrisonian at gmail dot com via Gcc-bugs]

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

chrisonian at gmail dot com changed:

   What|Removed |Added

 CC||chrisonian at gmail dot com

--- Comment #1 from chrisonian at gmail dot com ---
This bug is still present in versions 8.3.0, 9.3.0, 10.1.0 


Testing on Cori (NERSC):

module load gcc/8.3.0
or
module load gcc/9.3.0
or
module load gcc/10.1.0

The result is the same:

gfortran test.f90 
test.f90:30:8:

 y = sqrt(x)
1
Error: Name 'sqrt' at (1) is an ambiguous reference to 'sqrt' from module
'(intrinsic)'

[Bug c++/97973] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19577 since r265609

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed in GCC 10.4 too.

[Bug c++/97973] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19577 since r265609

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:18f103bd9e5465a10caeb70e2c7890a80c79d60a

commit r10-9692-g18f103bd9e5465a10caeb70e2c7890a80c79d60a
Author: Marek Polacek 
Date:   Fri Apr 9 20:03:45 2021 -0400

c++: ICE with real-to-int conversion in template [PR97973]

In this test we are building a call in a template, but since neither
the function nor any of its arguments are dependent, we go down the
normal path in finish_call_expr.  convert_arguments sees that we're
binding a reference to int to double and therein convert_to_integer
creates a FIX_TRUNC_EXPR.  Later, we call check_function_arguments
which folds the arguments, and, in a template, fold_for_warn calls
fold_non_dependent_expr.  But tsubst_copy_and_build should not see
a FIX_TRUNC_EXPR (see the patch discussed in
)
or we crash.

So let's not create a FIX_TRUNC_EXPR in a template in the first place
and instead use IMPLICIT_CONV_EXPR.

gcc/cp/ChangeLog:

PR c++/97973
* call.c (conv_unsafe_in_template_p): New.
(convert_like): Use it.

gcc/testsuite/ChangeLog:

PR c++/97973
* g++.dg/conversion/real-to-int1.C: New test.

[Bug tree-optimization/97108] [9/10/11 Regression] -Wmaybe-uninitialized false positive

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|Wmaybe-uninitialized false  |[9/10/11 Regression]
   |positive|-Wmaybe-uninitialized false
   ||positive

--- Comment #3 from Martin Sebor  ---
It's a regression introduced in GCC 4.7.

[Bug tree-optimization/97108] Wmaybe-uninitialized false positive

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2020-11-06 00:00:00 |2021-4-9
 CC||msebor at gcc dot gnu.org
  Known to fail||10.2.0, 11.0, 4.7.0, 4.8.4,
   ||4.9.4, 5.5.0, 6.4.0, 7.2.0,
   ||8.3.0, 9.1.0
   Keywords||diagnostic

--- Comment #2 from Martin Sebor  ---
Reconfirming with a slightly more simplified test case below.

$ cat pr97108.c && gcc -O2 -S -Wall -fdump-tree-uninit-details=/dev/stdout
pr97108.c
int z;

void f (int flags, int i, int j)
{
  int x;
  _Bool f = !flags;

  if (f)
x = j;

  if (i != 0)
z = i;

  if (f && x != 2)
z = 0;
}

;; Function f (f, funcdef_no=0, decl_uid=1946, cgraph_uid=1, symbol_order=1)

[WORKLIST]: add to initial list: x_18 = PHI 
[CHECK]: examining phi: x_18 = PHI 
[CHECK]: Found unguarded use: x_19 = PHI 
[WORKLIST]: Update worklist with phi: x_19 = PHI 
[CHECK]: examining phi: x_19 = PHI 
[CHECK]: Found unguarded use: _1 = x_19 != 2;
pr97108.c: In function ‘f’:
pr97108.c:14:14: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   14 |   if (f && x != 2)
  |~~^~~~
pr97108.c:5:7: note: ‘x’ was declared here
5 |   int x;
  |   ^
void f (int flags, int i, int j)
{
  _Bool f;
  int x;
  _Bool _1;
  _Bool _2;

   [local count: 1073741824]:
  f_7 = flags_6(D) == 0;
  if (flags_6(D) == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  if (i_10(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

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

   [local count: 268435456]:

   [local count: 536870913]:
  # x_18 = PHI 
  z = i_10(D);

   [local count: 805306368]:
  # x_19 = PHI 
  _1 = x_19 != 2;
  _2 = _1 & f_7;
  if (_2 != 0)
goto ; [66.67%]
  else
goto ; [33.33%]

   [local count: 268435458]:

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

   [local count: 536870913]:
  z = 0;

   [local count: 1073741824]:
  return;

   [local count: 536870912]:
  if (i_10(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

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

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

}


Bisection indicates either r180295 or r180298 introduced the warning.  Before
then the dump was:

;; Function f (f, funcdef_no=0, decl_uid=1598, cgraph_uid=0)

[WORKLIST]: add to initial list: x_1 = PHI 
[CHECK]: examining phi: x_1 = PHI 

Use in stmt if (x_1 != 2)
is guarded by :
if (f_3 != 0)

[CHECK] Found def edge 1 in x_1 = PHI 
Operand defs of phi x_1 = PHI 
is guarded by :
if (f_3 != 0)
f (int flags, int i, int j)
{
  _Bool f;
  int x;

:
  f_3 = flags_2(D) == 0;
  if (f_3 != 0)
goto ;
  else
goto ;

:

:
  # x_1 = PHI 
  if (i_7(D) != 0)
goto ;
  else
goto ;

:
  z = i_7(D);

:
  if (f_3 != 0)
goto ;
  else
goto ;

:
  if (x_1 != 2)
goto ;
  else
goto ;

:
  z = 0;

:
  return;

}

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[hp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Hans-Peter Nilsson  ---
(In reply to Richard Biener from comment #8)
> xfail/pass depending on sizeof (int) might be possible but as said it might
> be that cris doesn't have sizeof (int) == 1

You meant something else here than what you wrote.  If you meant (effectively)
sizeof (int) == 4, then "every port" has INT_TYPE_SIZE 32 (bits), including
those mentioned in this PR.

> but instead just lays out
> struct ubits in a way to have its size being 1.

It's true that sizeof (struct ubits) == 1 (byte) for cris-elf.

FWIW, I don't know what it is that pru-elf, cris-elf and m68k-linux have in
common that matters here.  First I was dead sure it was they got "#define
PCC_BITFIELD_TYPE_MATTERS false" but that doesn't seem to grep to true for
pru-elf.  cris-elf and m68k include config/elfos.h then #undef
PCC_BITFIELD_TYPE_MATTERS, so you get the quoted defaults.h line, but pru
doesn't have the #undef.

[Bug c++/98899] [10 Regression] ICE in tsubst_copy, at cp/pt.c:16198 since r10-1280-g78f7607db4c53f8c

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Not backporting to GCC 10.4 since it depends on another patch.

[Bug c++/99806] [10 Regression] ICE: in tsubst_copy, at cp/pt.c:17247

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/99806] [10 Regression] ICE: in tsubst_copy, at cp/pt.c:17247

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:8f4f2fbc17c2a225c29ea20a2b6046cbdc7b3155

commit r10-9691-g8f4f2fbc17c2a225c29ea20a2b6046cbdc7b3155
Author: Marek Polacek 
Date:   Thu Apr 8 14:39:28 2021 -0400

c++: Fix two issues with auto function parameter [PR99806]

When we have a member function with auto parameter like this:

  struct S {
void f(auto);
  };

cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
"void S::foo(auto:1)", and then finish_fully_implicit_template turns
that FUNCTION_DECL into a TEMPLATE_DECL.  The bug here is that we only
call cp_parser_save_default_args for a FUNCTION_DECL.  As a consequence,
abbrev10.C is rejected because we complain that the default argument has
not been defined, and abbrev11.C ICEs, because we don't re-parse the
delayed noexcept, so the DEFERRED_PARSE tree leaks into tsubst* where we
crash.  This patch fixes both issues.

gcc/cp/ChangeLog:

PR c++/99806
* parser.c (cp_parser_member_declaration): Call
cp_parser_save_default_args even for function templates.  Use
STRIP_TEMPLATE on the declaration we're passing.

gcc/testsuite/ChangeLog:

PR c++/99806
* g++.dg/concepts/abbrev10.C: New test.
* g++.dg/concepts/abbrev11.C: New test.

(cherry picked from commit 625dadaf5df5a2ae0d8c5660fd1eec8ba354479c)

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #13 from Marek Polacek  ---
Fixed in GCC 10.4 too.

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

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

commit r10-9690-g0d4128a514186ac5c41fde10085acb2dcc9118fd
Author: Marek Polacek 
Date:   Fri Apr 2 17:11:32 2021 -0400

c++: GC during late parsing collects live data [PR91416]

Coming back to
:

This is a crash that points to a GC problem.  Consider this test:

  __attribute__ ((unused)) struct S {
S() { }
  } s;

We're parsing a simple-declaration.  While parsing the decl specs, we parse
the attribute, which means creating a TREE_LIST using ggc_alloc_*.

A function body is a complete-class context so when parsing the
member-specification of this class-specifier, we parse the bodies of the
functions we'd queued in cp_parser_late_parsing_for_member.  This then
leads to this call chain:
cp_parser_function_definition_after_declarator -> expand_or_defer_fn ->
expand_or_defer_fn_1 -> maybe_clone_body -> expand_or_defer_fn ->
cgraph_node::finalize_function -> ggc_collect.

In this test, the ggc_collect call collects the TREE_LIST we had
allocated, and a crash duly ensues.

I couldn't do what Richard suggested, that is, attach the attribute list
to struct S, because we don't pass decl_specs from cp_parser_type_specifier
down to cp_parser_class_specifier.  Therefore I've attempted to do "push
the
decl_specifiers onto a vec that is a GC root", except I couldn't really
push
the decl_specifiers, because first I'd have to mark cp_decl_specifier_seq
with
GTY(()) and even that wouldn't be enough for me to be able to create

  static GTY(()) vec

But here we only care about cp_decl_specifier_seq::attributes, so the
patch is just this.  I've also extended the test so now we test a nested
class too.

gcc/cp/ChangeLog:

PR c++/91416
* parser.c: Create a GC root for attributes in a decl specifier.
(cp_parser_type_specifier): Push/pop ->attributes onto/from it.

gcc/testsuite/ChangeLog:

PR c++/91416
* g++.dg/other/gc7.C: New test.

(cherry picked from commit a809d8a737da1ccebcd93065fc57fc0f4d94894a)

[Bug c++/99831] [10 Regression] ICE: in reshape_init, at cp/decl.c:6720

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/99831] [10 Regression] ICE: in reshape_init, at cp/decl.c:6720

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:3252b78f7ef7847b109e7b43daf7ca1a6f0d6fab

commit r10-9689-g3252b78f7ef7847b109e7b43daf7ca1a6f0d6fab
Author: Marek Polacek 
Date:   Thu Apr 1 10:42:43 2021 -0400

c++: GC collects live data when synthesizing operator== [PR99831]

Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:

  if (kind == sfk_comparison)
{
  /* If the function was declared constexpr, check that the definition
 qualifies.  Otherwise we can define the function lazily.  */
  if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
synthesize_method (fn);
  return;
}

which in this test triggers when we're processing the string<"a">{} in
the static_assert.  First, we create a CONSTRUCTOR for the "{}" in
cp_parser_functional_cast, then we call finish_compound_literal which
calls complete_type and that results in garbage collection, which then
frees the CONSTRUCTOR {} we created when parsing the braced-list in
string<"a">{} -- at this point, it's not referenced by anything.
(That's not the case for 'type' in finish_compound_literal: the symbol
table contains a node for operator==, so ggc_mark_roots goes and marks
the fn decl, its type, its arguments etc., as used, so we don't collect
it.)

We could just bump function_depth around the new call to synthesize_method
to prevent GC.

gcc/cp/ChangeLog:

PR c++/99831
* method.c (defaulted_late_check): ++ and -- function_depth around
the call to synthesize_method.
* pt.c: Remove the saved_trees global.

gcc/testsuite/ChangeLog:

PR c++/99831
* g++.dg/other/gc6.C: New test.

(cherry picked from commit 6a60ffc297b9d4903543a25538e62e7fb39420a9)

[Bug c++/99331] [8/9/10 Regression] -Wconversion false-positive in immediate context

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Fixed in GCC 10.4 too.

[Bug c++/99331] [8/9/10 Regression] -Wconversion false-positive in immediate context

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

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

commit r10-9688-gb281edd801018ed703ce7bb0d49fef59ff8cef8b
Author: Marek Polacek 
Date:   Thu Mar 4 20:20:40 2021 -0500

c++: -Wconversion vs value-dependent expressions [PR99331]

This PR complains that we issue a -Wconversion warning in

  template  struct X {};
  template  X foo();

saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not technically wrong, I suspect -Wconversion warnings aren't
all that useful for value-dependent expressions.  So this patch disables
them.  This is a regression that started with r241425:

@@ -7278,7 +7306,7 @@ convert_template_argument (tree parm,
  val = error_mark_node;
}
}
-  else if (!dependent_template_arg_p (orig_arg)
+  else if (!type_dependent_expression_p (orig_arg)
   && !uses_template_parms (t))
/* We used to call digest_init here.  However, digest_init
   will report errors, which we don't want when complain

Here orig_arg is SIZEOF_EXPR; dependent_template_arg_p (orig_arg) was
true, but type_dependent_expression_p (orig_arg) is false so we warn in
convert_nontype_argument.

gcc/cp/ChangeLog:

PR c++/99331
* call.c (build_converted_constant_expr_internal): Don't emit
-Wconversion warnings.

gcc/testsuite/ChangeLog:

PR c++/99331
* g++.dg/warn/Wconversion5.C: New test.

(cherry picked from commit 9efd72d28956eb79c7fca38e3c959733a3bb25bb)

[Bug c++/99176] [8/9/10 Regression] GCC rejects const_cast of null pointer in constant expressions

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed in GCC 10.4 too.

[Bug c++/99176] [8/9/10 Regression] GCC rejects const_cast of null pointer in constant expressions

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:581e87b67233556d566df3a0ea33be9c19fbcb2f

commit r10-9687-g581e87b67233556d566df3a0ea33be9c19fbcb2f
Author: Marek Polacek 
Date:   Fri Apr 9 18:41:21 2021 -0400

c++: const_cast of null pointer in constant expr [PR99176]

Here we reject

  constexpr const int *p = nullptr;
  constexpr int *q = const_cast(p);

with "conversion of 'const int*' null pointer to 'int*' is not a
constant expression", which seems bogus.  This code has been rejected
since r238909 which added the can_convert check when converting a null
pointer.  I'm not finding any standard rule that this check was supposed
to enforce.  The original discussion was here

and here
.

Since can_convert never assumes a C-style cast, it rejects casting
away constness as in the test above and in:

  constexpr int *q = (int *)(const int *) nullptr;

Removing the check only breaks constexpr-nullptr-2.C by not giving any
diagnostic for line 229:

  constexpr B *pb2 = static_cast(pa0);  // { dg-error "not a constant
expression" }

but the cast seems to be valid: we do [expr.static.cast]/7, and
[expr.const] only says that a reinterpreter_cast and converting from
void* is invalid in constexpr.  The can_convert check rejected convering
from void *, but only when converting from a null pointer, so it's not
good enough.  So I've added a check to catch conversions from cv void*.
I realize it's not a great time to be adding additional checking, but
removing the can_convert check would then technically be a regression.

Let's limit the new check to only trigger for integer_zerop and then remove
it in GCC 12.

gcc/cp/ChangeLog:

DR 1312
PR c++/99176
* constexpr.c (is_std_construct_at): New overload.
(is_std_allocator_allocate): New overload.
(cxx_eval_call_expression): Use the new overloads.
(cxx_eval_constant_expression): Reject casting
from void * as per DR 1312.  Don't check can_convert.

gcc/testsuite/ChangeLog:

DR 1312
PR c++/99176
* g++.dg/cpp0x/constexpr-nullptr-2.C: Adjust dg-error.
* g++.dg/cpp0x/constexpr-cast2.C: New test.
* g++.dg/cpp0x/constexpr-cast3.C: New test.

[Bug c/100009] New: -march=native doesn't recognize tigerlake

[cdotts at planetiq dot com via Gcc-bugs]

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

Bug ID: 19
   Summary: -march=native doesn't recognize tigerlake
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cdotts at planetiq dot com
  Target Milestone: ---

Copied from email chain: 
We're using GCC v9.3.0 on a newer laptop, as packaged by Ubuntu for
20.04 LTS.  Our build for host-native tools naturally enables
cpu-specific optimization with `-march=native`.  The gcc driver is
passing -march=tigerlake down to cc1 (or cc1plus).  The driver
program's auto-detection is correct in that this is tiger lake
hardware.  However, it is not supported in this release of GCC.

How exactly is the driver coming up with this code name?  I'd like to
keep the Makefile set up as-is for the whole team.  Can we override
the definition of `native` through an environment variable or
something?  Ice lake client optimizations and instruction selection
appear to be working for our usage.  We can modify the Makefile to be
sensitive to an environment variable, but I'm wondering if GCC itself
can also be overridden in this way.

Response from Jim Wilson: 
Looks like a bug in gcc-9.  tigerlake was added to
gcc/config/i386/driver-i386.c but not to the arch_names_table in i386.c.  I
would suggest filing a bug report.  I don't think there is a way to workaround
this.  It needs to be fixed in the gcc source tree.

[Bug c++/99120] [8/9/10 Regression] ICE in -Wshadow in templated member function

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed in GCC 10.4 too.

[Bug c++/99120] [8/9/10 Regression] ICE in -Wshadow in templated member function

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

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

commit r10-9686-gc7d7c15540d5173f76b570bd457e866f09a17722
Author: Marek Polacek 
Date:   Fri Mar 5 10:41:41 2021 -0500

c++: ICE with -Wshadow and enumerator in template [PR99120]

We crash here, because in a template, an enumerator doesn't have
a type until we've called finish_enum_value_list.  But our -Wshadow
implementation, check_local_shadow, is called when we pushdecl in
build_enumerator, which takes place before finish_enum_value_list.

gcc/cp/ChangeLog:

PR c++/99120
* name-lookup.c (check_local_shadow): Check if the type of decl
is non-null before checking TYPE_PTR*.

gcc/testsuite/ChangeLog:

PR c++/99120
* g++.dg/warn/Wshadow-17.C: New test.

(cherry picked from commit c2e64c33d9d903f0a52565ad98300feea0ffc580)

[Bug c++/99374] [8/9/10 Regression] C++17/20 mode fails to recognise pointer-to-member functions of incomplete types in conditional expression

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed in GCC 10.4 too.

[Bug c++/99374] [8/9/10 Regression] C++17/20 mode fails to recognise pointer-to-member functions of incomplete types in conditional expression

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:6fcf6e5977541b2383760cb4e15ff0403055b13a

commit r10-9685-g6fcf6e5977541b2383760cb4e15ff0403055b13a
Author: Marek Polacek 
Date:   Thu Mar 4 14:25:01 2021 -0500

c++: Pointer-to-member fn conversion with noexcept [PR99374]

The issue in this PR is that we wrongly reject converting pointers to
member function of incomplete types, one of which has noexcept.  Recall
that pointers (including pointers to member functions) to non-throwing
functions can be implicitly converted to potentially-throwing functions
(but not vice versa).

We reject the conversion when called from can_convert_arg_bad because
standard_conversion can't create such a conversion.  It comes down to
the DERIVED_FROM_P check in the TYPE_PTRMEMFUNC_P block.  It considers
every class derived from itself, but not when the class is incomplete.
But surely we want to reach fnptr_conv_p when tbase is fbase (one of
them could be an alias to the other so use same_type_p instead of ==).

Another approach would be to not perform DERIVED_FROM_P at all when
either tbase or fbase are incomplete (so perhaps something like at the
end of ptr_reasonably_similar).

gcc/cp/ChangeLog:

PR c++/99374
* call.c (standard_conversion): When converting pointers to
member, don't return NULL when the bases are equivalent but
incomplete.

gcc/testsuite/ChangeLog:

PR c++/99374
* g++.dg/cpp1z/noexcept-type23.C: New test.

(cherry picked from commit 02a3554879001e8f1405d17e096ed68fc3f76975)

[Bug c++/98947] [10 Regression] Incorrect warning when using a ternary operator to select one of two volatile variables to write to

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed in GCC 10.4 too.

[Bug c++/98947] [10 Regression] Incorrect warning when using a ternary operator to select one of two volatile variables to write to

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

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

commit r10-9684-gf0f62557c3de0313673d7c0527277e86231ee95b
Author: Marek Polacek 
Date:   Wed Feb 3 17:57:22 2021 -0500

c++: Fix bogus -Wvolatile warning in C++20 [PR98947]

Since most of volatile is deprecated in C++20, we are required to warn
for compound assignments to volatile variables and so on.  But here we
have

  volatile int x, y, z;
  (b ? x : y) = 1;

and we shouldn't warn, because simple assignments like x = 24; should
not provoke the warning when they are a discarded-value expression.

We warn here because when ?: is used as an lvalue, we transform it in
cp_build_modify_expr/COND_EXPR from (a ? b : c) = rhs to

  (a ? (b = rhs) : (c = rhs))

and build_conditional_expr then calls mark_lvalue_use for the new
artificial assignments, which then evokes the warning.  The calls
to mark_lvalue_use were added in r160289 to suppress warnings in
Wunused-var-10.c, but looks like they're no longer needed.

To warn on

(b ? (x = 2) : y) = 1;
(b ? x : (y = 5)) = 1;

I've tweaked a check in mark_use/MODIFY_EXPR.

I'd argue this is a regression because GCC 9 doesn't warn.

gcc/cp/ChangeLog:

PR c++/98947
* call.c (build_conditional_expr_1): Don't call mark_lvalue_use
on arg2/arg3.
* expr.c (mark_use) : Don't check read_p when
issuing the -Wvolatile warning.  Only set TREE_THIS_VOLATILE if
a warning was emitted.

gcc/testsuite/ChangeLog:

PR c++/98947
* g++.dg/cpp2a/volatile5.C: New test.

(cherry picked from commit 7a18bc4ae62081021f4fd90d591a588cac931f77)

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed in GCC 10.4 too.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:6f45079013256ed730c92bf35af4e6394cb5a2c0

commit r10-9683-g6f45079013256ed730c92bf35af4e6394cb5a2c0
Author: Marek Polacek 
Date:   Fri Apr 9 18:31:12 2021 -0400

c++: ICE with delayed noexcept and attribute used [PR97966]

Another ICE with delayed noexcept parsing, but a bit gnarlier.

A function definition marked with __attribute__((used)) ought to be
emitted even when it is not referenced in the TU.  For a member function
template marked with __attribute__((used)) this means that it will
be instantiated: in instantiate_class_template_1 we have

11971   /* Instantiate members marked with attribute used.  */
11972   if (r != error_mark_node && DECL_PRESERVE_P (r))
11973 mark_used (r);

It is not so surprising that this doesn't work well with delayed
noexcept parsing: when we're processing the function template we delay
the parsing, so the member "foo" is found, but then when we're
instantiating it, "foo" hasn't yet been seen, which creates a
discrepancy and a crash ensues.  "foo" hasn't yet been seen because
instantiate_class_template_1 just loops over the class members and
instantiates right away.

To make it work, this patch uses a vector to keep track of members
marked with attribute used and uses it to instantiate such members
only after we're done with the class; in particular, after we have
called finish_member_declaration for each member.  And we ought to
be verifying that we did emit such members, so I've added a bunch
of dg-finals.

gcc/cp/ChangeLog:

PR c++/97966
* pt.c (instantiate_class_template_1): Instantiate members
marked with attribute used only after we're done instantiating
the class.

gcc/testsuite/ChangeLog:

PR c++/97966
* g++.dg/cpp0x/noexcept63.C: New test.

[Bug c++/98333] [10 Regression] ICE in check_qualified_type, at tree.c:6593 since r10-1280-g78f7607db4c53f8c

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed for GCC 10.4/11.

[Bug c++/98333] [10 Regression] ICE in check_qualified_type, at tree.c:6593 since r10-1280-g78f7607db4c53f8c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

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

commit r10-9682-g3bb551c6751304fb2d51cc8569f066dd8a9090e2
Author: Marek Polacek 
Date:   Fri Jan 8 15:48:41 2021 -0500

c++: ICE when late parsing noexcept/NSDMI [PR98333]

Since certain members of a class are a complete-class context
[class.mem.general]p7, we delay their parsing untile the whole class has
been parsed.  For instance, NSDMIs and noexcept-specifiers.  The order
in which we perform this delayed parsing matters; we were first parsing
NSDMIs and only they did we parse noexcept-specifiers.   That turns out
to be wrong: since NSDMIs may use noexcept-specifiers, we must process
noexcept-specifiers first.  Otherwise we'll ICE in code that doesn't
expect to see DEFERRED_PARSE.

This doesn't just shift the problem, noexcept-specifiers can use members
with a NSDMI just fine, and I've also tested a similar test with this
member function:

  bool f() { return __has_nothrow_constructor (S); }

and that compiled fine too.

gcc/cp/ChangeLog:

PR c++/98333
* parser.c (cp_parser_class_specifier_1): Perform late-parsing
of NSDMIs before late-parsing of noexcept-specifiers.

gcc/testsuite/ChangeLog:

PR c++/98333
* g++.dg/cpp0x/noexcept62.C: New test.

(cherry picked from commit c37f1d4081f5a19e39192d13e2a3acea13662e5a)

[Bug fortran/94446] Bogus "type mismatch" with TYPE(c_ptr) and sizeof()

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
Created attachment 50541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50541=edit
Draft patch

I wonder whether something like that would work.

The only known failure is gfortran.dg/gomp/use_device_ptr-1.f90 which fails as
instead of
  void * x;
  #pragma omp target data map(alloc:x)
the wrong
  #pragma omp target data map(alloc:*x) map(alloc:x [pointer assign, bias: 0])
is generated (ICE as sizeof 'void' does not make sense).
(Fix should be in the code block below 'case OMP_LIST_MAP:' in trans-openmp.c)

I wonder what else goes wrong with 'type(c_ptr)' and 'type(c_ptr),pointer'
besides this issue and the one 'fn spec' issue (already fixed in the attached
patch).

[Bug c++/99742] Parameter packs not expanded with nested requirements

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-04-09
 Status|UNCONFIRMED |NEW

--- Comment #1 from Patrick Palka  ---
Confirmed, it never worked so not a regression.

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #13)
> Seems the exact spot where the clobber is optimized away is e.g. when
> simplify_and_const_int_1 (SImode, (ashift:SI (subreg:SI (and:TI (clobber:TI
> (const_int 0 [0])) (const_int 255 [0xff])) 0) (const_int 16 [0x10])), 255);
> is called.
> It calls nonzero_bits, nonzero_bits sees VARYING << 16 and so returns
> 0x,
>   /* Turn off all bits in the constant that are known to already be zero.
>  Thus, if the AND isn't needed at all, we will have CONSTOP ==
> NONZERO_BITS
>  which is tested below.  */
> 
>   constop &= nonzero;
> 
>   /* If we don't have any bits left, return zero.  */
>   if (constop == 0)
> return const0_rtx;
> 
> So, are you suggesting that in all such spots we need to test side_effects_p
> and punt?

Yes, you need to do check side_effects_p *everywhere* you can potentially
remove a side effect.  This is not specific to combine, even.

> Note, simplify_and_const_int_1 already starts with:
>   if (GET_CODE (varop) == CLOBBER)
> return NULL_RTX;
> so it would need to use
>   if (side_effects_p (varop))
> return NULL_RTX;
> instead.

Yeah.  This no longer disallows a VOIDmode clobber, but we should not see
those here anyway.

You'll need the same change a few lines later, btw:

  varop = force_to_mode (varop, mode, constop, 0);

  /* If VAROP is a CLOBBER, we will fail so return it.  */
  if (GET_CODE (varop) == CLOBBER)
return varop;

(you only need that second one, even, force_to_mode immediately returns
its arg if it is a clobber).

[Bug c++/97134] partial specialization not more specialized when using CNTTP

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/99180] [10/11 Regression] ICE with alias template and empty parameter pack

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/100006] [8/9/10/11 Regression] ICE: in dependent_type_p, at cp/pt.c:26745

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/100005] undefined reference to `_rdrand64_step'

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Jakub Jelinek  ---
Andrew, this isn't really specific to a single target, rough numbers of
extern inline __gnu_inline__ intrinsics are:
 14 config/s390
120 config/sparc
603 config/rs6000
   4044 config/aarch64
   5659 config/i386
   7338 config/arm
and rough numbers of static inline intrinsics are:
 24 config/c6x
 26 config/rs6000
 69 config/arm
 99 config/mips
112 config/aarch64

[Bug libstdc++/100008] std::clamp generates suboptimal assembly for primitive types

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jonathan Wakely  ---
Dup of bug 96733?

[Bug c++/99547] [11 regression] g++.dg/modules/xtreme-header-5_c.C -std=c++2a ICE

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
 CC||jason at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
(In reply to Christophe Lyon from comment #3)
> Apparently not, the last occurrence was with r11-7662
> (g:9844eeff5abd129fab5a4cbd004b814c073a95a1)

Closing, then, thanks.

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

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #20 from Marek Polacek  ---
I think I won't backport as the fix caused bug 99510.  Perhaps I could backport
both if someone really wants me to.

For now, fixed in GCC 11.

[Bug libstdc++/100008] New: std::clamp generates suboptimal assembly for primitive types

[vittorio.romeo at outlook dot com via Gcc-bugs]

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

Bug ID: 18
   Summary: std::clamp generates suboptimal assembly for primitive
types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

`std::clamp` generates poor assembly compared to hand-written counterpart for
primitive types like `float`, even with `-Ofast -ffast-math`:

stdclamp(float, float, float):
comiss  xmm0, xmm1
jb  .L2
movaps  xmm1, xmm0
minss   xmm1, xmm2
.L2:
movaps  xmm0, xmm1
ret

myclamp(float, float, float):
maxss   xmm0, xmm1
minss   xmm0, xmm2
ret

Live example:
https://godbolt.org/z/5oxvocevK

More information on:
https://secret.club/2021/04/09/std-clamp.html

[Bug libgcc/98952] powerpc*: __trampoline_setup inverted test for trampoline size

[meissner at gcc dot gnu.org via Gcc-bugs]

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

Michael Meissner  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-04-09
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org

[Bug middle-end/98049] False positive when compiling with -Os -Wmaybe-uninitialized (compile-time limit)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85872
Summary|False positive when |False positive when
   |compiling with -Os  |compiling with -Os
   |-Wmaybe-uninitialized   |-Wmaybe-uninitialized
   ||(compile-time limit)

--- Comment #3 from Martin Sebor  ---
See also pr85872 for a similar problem caused by the same limit.

[Bug middle-end/98049] False positive when compiling with -Os -Wmaybe-uninitialized

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2020-11-30 00:00:00 |2021-4-9
  Known to fail||10.2.0, 11.0
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
The false positive is due to the algorithm exceeding the hardcoded conservative
internal MAX_CHAIN_LEN limit.  Bumping it up from the current 5 to 6 avoids the
warning in this case.

As far as I can tell, the limit keeps the algorithm from becoming O(n^2) while
detecting cycles in the dependency graph.  But it looks to me like we might be
able to achieve the same result by using a more efficient data structure, such
as bitmap rather than iterating over the elements of a vector (the edges of the
graph).

[Bug target/97726] simd intrinsics tests fail on armeb

[ramana at gcc dot gnu.org via Gcc-bugs]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #2 from Ramana Radhakrishnan  ---
Fixed now ?

[Bug target/96372] [11 regression] arm/ivopts.c fails since r11-2012

[akrl at gcc dot gnu.org via Gcc-bugs]

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

akrl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from akrl at gcc dot gnu.org ---
Yes AFAIK it is, closing thanks.

[Bug target/96372] [11 regression] arm/ivopts.c fails since r11-2012

[ramana at gcc dot gnu.org via Gcc-bugs]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  ---
Is this now fixed ?

[Bug middle-end/97858] avoid mentioning va_list internal fields in -Wuninitialized

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2020-11-17 00:00:00 |2021-4-9
Summary|Bogus warnings about|avoid mentioning va_list
   |va_list |internal fields in
   ||-Wuninitialized
 CC||msebor at gcc dot gnu.org

--- Comment #12 from Martin Sebor  ---
(In reply to Jan Hubicka from comment #7)
> Thanks, my original intention was to mostly track the fact that we do not
> want
> to warn about fields of va_list type that is internal to compiler though
> :)

To be clear: for the following test case you suggest to issue just the one
warning below:

$ cat pr97858.c && gcc -O2  -S -Wall pr97858.c
void f (__builtin_va_list);

int g (int i, ...)
{
  __builtin_va_list ap;
  // __builtin_va_start (ap, i);

  int x = __builtin_va_arg (ap, int);
  __builtin_va_end (ap);

  return x;
}
pr97858.c: In function ‘g’:
pr97858.c:8:7: warning: ‘ap’ is used uninitialized [-Wuninitialized]
8 |   int x = __builtin_va_arg (ap, int);
  |   ^
pr97858.c:5:21: note: ‘ap’ declared here
5 |   __builtin_va_list ap;
  | ^~

as opposed to the three GCC issues now:

pr97858.c: In function ‘g’:
pr97858.c:8:7: warning: ‘ap[0].gp_offset’ is used uninitialized
[-Wuninitialized]
8 |   int x = __builtin_va_arg (ap, int);
  |   ^
pr97858.c:5:21: note: ‘ap’ declared here
5 |   __builtin_va_list ap;
  | ^~
pr97858.c:8:7: warning: ‘ap[0].reg_save_area’ may be used uninitialized
[-Wmaybe-uninitialized]
8 |   int x = __builtin_va_arg (ap, int);
  |   ^
pr97858.c:5:21: note: ‘ap’ declared here
5 |   __builtin_va_list ap;
  | ^~
pr97858.c:8:7: warning: ‘ap[0].overflow_arg_area’ may be used uninitialized
[-Wmaybe-uninitialized]
8 |   int x = __builtin_va_arg (ap, int);
  |   ^
pr97858.c:5:21: note: ‘ap’ declared here
5 |   __builtin_va_list ap;
  | ^~

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|jakub at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #13 from Jakub Jelinek  ---
Seems the exact spot where the clobber is optimized away is e.g. when
simplify_and_const_int_1 (SImode, (ashift:SI (subreg:SI (and:TI (clobber:TI
(const_int 0 [0])) (const_int 255 [0xff])) 0) (const_int 16 [0x10])), 255);
is called.
It calls nonzero_bits, nonzero_bits sees VARYING << 16 and so returns
0x,
  /* Turn off all bits in the constant that are known to already be zero.
 Thus, if the AND isn't needed at all, we will have CONSTOP == NONZERO_BITS
 which is tested below.  */

  constop &= nonzero;

  /* If we don't have any bits left, return zero.  */
  if (constop == 0)
return const0_rtx;

So, are you suggesting that in all such spots we need to test side_effects_p
and punt?

Note, simplify_and_const_int_1 already starts with:
  if (GET_CODE (varop) == CLOBBER)
return NULL_RTX;
so it would need to use
  if (side_effects_p (varop))
return NULL_RTX;
instead.

[Bug c/100005] undefined reference to `_rdrand64_step'

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #9 from H.J. Lu  ---
I don't think we need to support taking address of intrinsic.
By definition, there is no intrinsic address to take.

[Bug c/100005] undefined reference to `_rdrand64_step'

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jakub Jelinek  ---
Looking at clang, they have significantly more intrinsics than GCC implemented
as macros (GCC typically only implements those that have to be macros at -O0
for immediates, while I can't find any particular pattern on why some clang
intrinsics are macros and others inlines), but they do use static inline rather
than extern inline __attribute__((gnu_inline)).  So for some intrinsics you
might be lucky and it will work, but for many others it won't work.
Using wrappers, whether lambdas for C++ or something else, is IMNSHO the only
portable way for the intrinsics if you want to take their addresses.

[Bug c++/100007] New: Parameter packs not expanded with bit field

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 17
   Summary: Parameter packs not expanded with bit field
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/ccb69heP9

template 
auto f() {
  ([] { struct U { int x : Ns; }; }, ...);
  ([] { union  U { int x : Ns; }; }, ...);
}

gcc rejects it.

[Bug c/100005] undefined reference to `_rdrand64_step'

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
CCing H.J. on this.

[Bug c/100005] undefined reference to `_rdrand64_step'

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #6 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #5)
> then one would get an out of line copy when taking their address, but it 
> would 
> duplicated in all the TUs that did this.

That's not a problem, since that's only for debug mode builds. In release
builds, they should get properly inlined.

> Anyway, your assumption that intrinsics can be used the way you expect them
> is just wrong.

If you say so, then please close as WONTFIX or NOTABUG. And indeed the ones
that are implemented as macros can't have their address taken anyway, since
macros don't have address.

I would suggest a better error message, though, if "just works" is not
possible.

[Bug middle-end/47307] Uninitialized in this function: warning for initialized, no warning for uninitialized

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2017-12-30 00:00:00 |2021-4-9
 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
The warning has disappeared at -O1 and above.  The expected one for the
uninitialized read from the lopt array is issued now but only at -O0.  With
optimization the read is eliminated.  Given the large number of open bugs for
-Wuninitialized (pr24639) I'm not sure it's worth keeping this open as well.

$ gcc -O0 -S -Wall pr47307.f90 
../pr47307.f90:13:13:

   13 |  if ( lopt(j,i) < 0 ) then
  | ^
Warning: ‘lopt’ may be used uninitialized [-Wmaybe-uninitialized]
../pr47307.f90:8:34:

8 |integer, dimension(3,5) :: lopt
  |  ^
note: ‘lopt’ declared here

[Bug c/100005] undefined reference to `_rdrand64_step'

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jakub Jelinek  ---
Neither always_inline nor artificial attribute means that you can't take
addresses of those inlines, but
1) I don't think anything implies the intrinsics must be implemented as inline
functions, after all, gcc implements hundreds of intrinsics as preprocessor
macros e.g. at -O0
2) as those intrinsics that are implemented as inline functions are implemented
by gcc as
extern inline __attribute__((gnu_inline, artificial, always_inline)),
they have the GNU extern inline semantics, i.e. the header provides definitions
for inlining purposes and when it can't be inline, something different must
supply the definitions somewhere else (either the user, or perhaps GCC in some
library; but GCC doesn't do that).
Now, GCC could instead define them as static inline __attribute((artificial,
always_inline)) and then one would get an out of line copy when taking their
address, but it would duplicated in all the TUs that did this.

Anyway, your assumption that intrinsics can be used the way you expect them is
just wrong.

[Bug c/100005] undefined reference to `_rdrand64_step'

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #4 from Thiago Macieira  ---
That's an artificial (pun intended) limitation.

In C++:

template 
int fill_array(Generator generator, unsigned long long *rand_array)

Also errors out with the same error, but works if you do:

fill_array([](auto x) { return _rdrand64_step(x); }, rand_array);

The extra indirection shouldn't be required.

PS: clang compiles the same code just fine.

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #11)
> I don't understand what is wrong about that.
> (clobber:TI (const_int 0 [0])) in there stands for couldn't figure out what
> this value is or how to represent it, so it is wildcard for I don't know
> what the value is.

That is not what it means.  It means "This instruction is invalid".  It should
never be "optimised" away.

> I'd think if one has say (and:TI (clobber:TI (const_int 0 [0])) (const_int 0
> [0])) one should be able to still simplify it into 0, etc.,

No.  That RTL has no meaning at all, you cannot use a clobber as a RHS!

> and what happens
> here is the same thing, the clobber value, whatever it is, doesn't influence
> in any way the whole expression value, therefore it is optimized away.
> If it remained there, sure, the instruction would fail recog_for_combine.

Yes.  And that is why it should never be removed!

[Bug c++/100006] [8/9/10/11 Regression] ICE: in dependent_type_p, at cp/pt.c:26745

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #3 from 康桓瑋  ---
https://godbolt.org/z/o6h8GP6ae

Maybe same form:

template 
auto f() {
  [] { struct S : Ts {}; };
}

int main() {
  f<>();
}

:3:15: internal compiler error: in dependent_type_p, at cp/pt.c:26745
3 |   [] { struct S : Ts {}; };
  |   ^
0x1d00959 internal_error(char const*, ...)
???:0
0x6bb099 fancy_abort(char const*, int, char const*)
???:0
0x8fa338 dependent_type_p(tree_node*)
???:0
0x7a9464 xref_basetypes(tree_node*, tree_node*)
???:0
0x95aa80 instantiate_class_template(tree_node*)
???:0
0x94abba tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91d54f instantiate_decl(tree_node*, bool, bool)
???:0
0x7c7a3e maybe_instantiate_decl(tree_node*)
???:0
0x7c91a0 mark_used(tree_node*, int)
???:0
0x6de907 build_new_function_call(tree_node*, vec**, int)
???:0
0x981c3c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x8e224d c_parse_file()
???:0
0xa612e2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug middle-end/99989] [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[11 regression] False   |[11 regression]
   |maybe-uninitialized warning |-Wmaybe-uninitialized
   |breaks bootstrap on riscv64 |warning breaks bootstrap on
   ||riscv64

--- Comment #7 from Martin Sebor  ---
The warning is a true positive caused by assigning a struct with an
uninitialized member.  Adjusting Summary.

[Bug c++/100006] [8/9/10/11 Regression] ICE: in dependent_type_p, at cp/pt.c:26745

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-09
   Keywords||ice-on-invalid-code
   Target Milestone|--- |8.5
 Status|UNCONFIRMED |NEW
   Priority|P3  |P2
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
Summary|ICE: in dependent_type_p,   |[8/9/10/11 Regression] ICE:
   |at cp/pt.c:26745|in dependent_type_p, at
   ||cp/pt.c:26745

--- Comment #2 from Marek Polacek  ---
(In reply to 康桓瑋 from comment #0)
> Congratulations on hitting the 10,000 reports mark!

You helped :).

Started with r251433.

[Bug c++/100006] ICE: in dependent_type_p, at cp/pt.c:26745

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
(In reply to 康桓瑋 from comment #0)
> Congratulations on hitting the 10,000 reports mark!
> 
> https://godbolt.org/z/dhPqd4595
> 
> template 
> auto f(Ts...) {
>   [] { enum class e : Ts {}; };
> }
> 
> int main() {
>   f(0, true);
> }
> 
> :3:19: internal compiler error: in dependent_type_p, at cp/pt.c:26745
> 3 |   [] { enum class e : Ts {}; };
>   |   ^
> 0x1d00959 internal_error(char const*, ...)
>   ???:0
> 0x6bb099 fancy_abort(char const*, int, char const*)
>   ???:0
> 0x8fa338 dependent_type_p(tree_node*)
>   ???:0
> 0x78b617 start_enum(tree_node*, tree_node*, tree_node*, tree_node*, bool,
> bool*)
>   ???:0
> 0x92ae1d lookup_template_class(tree_node*, tree_node*, tree_node*,
> tree_node*, int, int)
>   ???:0
> 0x91766d tsubst(tree_node*, tree_node*, int, tree_node*)
>   ???:0
> 0x917717 tsubst(tree_node*, tree_node*, int, tree_node*)
>   ???:0
> 0x94abba tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
>   ???:0
> 0x91d54f instantiate_decl(tree_node*, bool, bool)
>   ???:0
> 0x7c7a3e maybe_instantiate_decl(tree_node*)
>   ???:0
> 0x7c91a0 mark_used(tree_node*, int)
>   ???:0
> 0x6de907 build_new_function_call(tree_node*, vec vl_embed>**, int)
>   ???:0
> 0x981c3c finish_call_expr(tree_node*, vec**,
> bool, bool, int)
>   ???:0
> 0x8e224d c_parse_file()
>   ???:0
> 0xa612e2 c_common_parse_file()
>   ???:0
> Please submit a full bug report,
> with preprocessed source if appropriate.

100,000

[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
--- gcc/simplify-rtx.c.jj   2021-04-09 16:18:24.275668496 +0200
+++ gcc/simplify-rtx.c  2021-04-09 19:26:24.963134240 +0200
@@ -7059,12 +7059,19 @@ simplify_immed_subreg (fixed_size_mode o
   while (buffer.length () < buffer_bytes)
buffer.quick_push (filler);
 }
-  else
+  else if (!native_encode_rtx (innermode, x, buffer, first_byte, inner_bytes))
+return NULL_RTX;
+  rtx ret = native_decode_rtx (outermode, buffer, 0);
+  if (ret && MODE_COMPOSITE_P (outermode))
 {
-  if (!native_encode_rtx (innermode, x, buffer, first_byte, inner_bytes))
+  auto_vec buffer2 (buffer_bytes);
+  if (!native_encode_rtx (outermode, ret, buffer2, 0, buffer_bytes))
return NULL_RTX;
-  }
-  return native_decode_rtx (outermode, buffer, 0);
+  for (unsigned int i = 0; i < buffer_bytes; ++i)
+   if (buffer[i] != buffer2[i])
+ return NULL_RTX;
+}
+  return ret;
 }

 /* Simplify SUBREG:OUTERMODE(OP:INNERMODE, BYTE)

Makes simplify_subreg fail when trying to subreg a constant into a composite
floating mode that doesn't decode back.
Unfortunately, this causes ICE:
pr71522.c: In function ‘main’:
pr71522.c:27:1: error: unrecognizable insn:
   27 | }
  | ^
(insn 5 2 6 2 (set (reg/v:TF 118 [ d ])
(subreg:TF (const_vector:V16QI [
(const_int 65 [0x41]) repeated x15
(const_int 0 [0])
]) 0)) "pr71522.c":20:3 -1
 (nil))
during RTL pass: vregs

store_bit_field_1 calls simplify_gen_subreg and that when simplify_immed_subreg
fails will happily create the above subreg.
So I'm quite afraid the above change could break quite a lot and so might be
better to defer it for GCC12.

[Bug c++/100006] New: ICE: in dependent_type_p, at cp/pt.c:26745

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 16
   Summary: ICE: in dependent_type_p, at cp/pt.c:26745
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Congratulations on hitting the 10,000 reports mark!

https://godbolt.org/z/dhPqd4595

template 
auto f(Ts...) {
  [] { enum class e : Ts {}; };
}

int main() {
  f(0, true);
}

:3:19: internal compiler error: in dependent_type_p, at cp/pt.c:26745
3 |   [] { enum class e : Ts {}; };
  |   ^
0x1d00959 internal_error(char const*, ...)
???:0
0x6bb099 fancy_abort(char const*, int, char const*)
???:0
0x8fa338 dependent_type_p(tree_node*)
???:0
0x78b617 start_enum(tree_node*, tree_node*, tree_node*, tree_node*, bool,
bool*)
???:0
0x92ae1d lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x91766d tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x917717 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x94abba tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91d54f instantiate_decl(tree_node*, bool, bool)
???:0
0x7c7a3e maybe_instantiate_decl(tree_node*)
???:0
0x7c91a0 mark_used(tree_node*, int)
???:0
0x6de907 build_new_function_call(tree_node*, vec**, int)
???:0
0x981c3c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x8e224d c_parse_file()
???:0
0xa612e2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/55288] Improve handling/suppression of maybe-uninitialized warnings

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-8099-gb04093adb28bd6ee8b0390e840219fd2bba134db
Author: Martin Sebor 
Date:   Fri Apr 9 11:40:48 2021 -0600

PR middle-end/55288 - Improve handling/suppression of maybe-uninitialized
warnings

gcc/testsuite/ChangeLog:
PR middle-end/55288
* g++.dg/warn/uninit-pr55288.C: New test.

[Bug libgomp/99984] bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Sebor  ---
The same change should be made there (in uclibc).  FWIW, I looked for a bug
database to report the problem there but, AFAICS, uclibc-ng is the currently
maintained fork, but it has no bug database (https://bugs.uclibc.org looks like
the old one).  If you know where to report bugs I'd suggest you open a request
there.

Short of changing the upstream headers, the two alternatives to avoid this
problem in GCC that come to mind are: 1) add a pthread_setspecific declaration
with the attribute to GCC source code, or 2) add a pthread_setspecific built-in
to GCC.

(But I mention all this to raise awareness of the problem and the available
suppression mechanism, not to lecture anyone.  If you don't find it helpful
feel free to disregard it.)

[Bug c++/100003] internal compiler error: in merge_exception_specifiers

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Marek Polacek  ---
The problem is that, when we're in a system header,
check_redeclaration_exception_specification doesn't emit an error:

 1242   if (DECL_IN_SYSTEM_HEADER (old_decl))
 1243 complained = pedwarn (new_loc, OPT_Wsystem_headers, msg,
new_decl);

so then we crash here:

2420   gcc_checking_assert (!TREE_PURPOSE (add)
2421|| errorcount || !flag_exceptions
2422|| cp_tree_equal (noex, TREE_PURPOSE (add)));

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Jakub Jelinek  ---
I don't understand what is wrong about that.
(clobber:TI (const_int 0 [0])) in there stands for couldn't figure out what
this value is or how to represent it, so it is wildcard for I don't know what
the value is.
I'd think if one has say (and:TI (clobber:TI (const_int 0 [0])) (const_int 0
[0])) one should be able to still simplify it into 0, etc., and what happens
here is the same thing, the clobber value, whatever it is, doesn't influence in
any way the whole expression value, therefore it is optimized away.
If it remained there, sure, the instruction would fail recog_for_combine.

[Bug c/100005] undefined reference to `_rdrand64_step'

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Segher Boessenkool  ---
I'm not sure how/why "artificial" should prevent taking the address though?

[Bug tree-optimization/100004] Dead write not removed when indirection is introduced.

[dancol at dancol dot org via Gcc-bugs]

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

Daniel Colascione  changed:

   What|Removed |Added

 CC||dancol at dancol dot org

--- Comment #2 from Daniel Colascione  ---
Let's talk about this. GCC might, surprisingly, actually be correct here:
pointers are allowed to be cast from one object type to another object type and
then back while retaining their validity; in principle, w1 and w2 might be
"fake" wrapper instances created by casts from a struct Foo --- it's legal to
form these fake pointers as long as no access occurs through them. If
assign_via_pointer had reinterpret_cast()-ed w1 and w2 to Foo* (yielding
f1 and f2 respectively) and then accessed f1->x and f2->x, I think we'd agree 
that f1->x and f2->x could alias. 

The difference between the code in this bug and the reinterpret_cast<> scenario
is that here we're deriving f1 and f2 *not* via reinterpet_cast, but via
regular member access --- >foo and >foo. Should the use of a member
access instead of a cast propagate aliasing information? On one hand, it seems
logical to do so; on the other hand, the standard *does* say that access
through legally-derived same-type pointers can alias, and we *really do* have
two legally-derived same-type pointers here.

So what's the correct interpretation of the standard?

[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs

[rodgertq at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Thomas Rodgers  ---
I believe it is addressed in the most recent patch I have submitted for the
atomic wait/notify, barriers, latches, semaphores functionality.

[Bug libgomp/99984] bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
(In reply to Martin Sebor from comment #4)
> The following Glibc bug calls for suppressing the warning by adding
> attribute access none to the function declaration:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27714

well. this is an issue related to uclibc. Not glibc nor musl nor bionic.

I built glibc on windows, no issue at all tbh.

[Bug c/100005] undefined reference to `_rdrand64_step'

[segher at gcc dot gnu.org via Gcc-bugs]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
So the only bug here is that we should give a better error message?  One
when taking the address, already.

[Bug middle-end/36823] missing uninitialized warning (IPA, inlining)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2019-02-24 00:00:00 |2021-4-9
  Known to fail||10.2.0, 11.0, 4.9.4, 5.5.0,
   ||6.4.0, 7.2.0, 8.3.0, 9.1.0

--- Comment #6 from Martin Sebor  ---
Reconfirmed with GCC 11.

[Bug fortran/27589] Add compiler flag to check for uninitalized values at runtime

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks|24639   |
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
Runtime checking isn't the job of -Wuninitialized so removing the dependency on
the meta bug pr27589.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues