[Bug tree-optimization/106297] stringop-overflow misbehaviour on atomic

[chipitsine at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Илья Шипицин  ---
I have provided repro steps, hope they can be used to find any answer.

I tried to add "-save-temps", but it gave another error (not seen without that
option):

  CC  src/slz.o
In file included from src/slz.c:29:
include/import/slz-tables.h: In function ‘dist_to_code’:
include/import/slz-tables.h:182:35: error: this statement may fall through
[-Werror=implicit-fallthrough=]
  182 | case 24577 ... 32768: code++; /* fall through */
  |   ^~
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
make: *** [Makefile:1004: src/slz.o] Error 1

[Bug target/106113] wrong codegen for _mm_[u]comineq_{ss,sd} and need to return PF result.

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Kong Lingling :

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

commit r13-1702-gae69e6f61b93dcb5b1e7ef609431f100c1b9b2e5
Author: konglin1 
Date:   Fri Jul 15 10:29:27 2022 +0800

i386: Fix _mm_[u]comixx_{ss,sd} codegen and add PF result. [PR106113]

gcc/ChangeLog:

PR target/106113
* config/i386/i386-builtin.def (BDESC): Fix [u]comi{ss,sd}
comparison due to intrinsics changed over time.
* config/i386/i386-expand.cc (ix86_ssecom_setcc):
Add unordered check and mode for sse comi codegen.
(ix86_expand_sse_comi): Add unordered check and check a different
CCmode.
(ix86_expand_sse_comi_round):Extract unordered check and mode part
in ix86_ssecom_setcc.

gcc/testsuite/ChangeLog:

PR target/106113
* gcc.target/i386/avx-vcomisd-pr106113-2.c: New test.
* gcc.target/i386/avx-vcomiss-pr106113-2.c: Ditto.
* gcc.target/i386/avx-vucomisd-pr106113-2.c: Ditto.
* gcc.target/i386/avx-vucomiss-pr106113-2.c: Ditto.
* gcc.target/i386/sse-comiss-pr106113-1.c: Ditto.
* gcc.target/i386/sse-comiss-pr106113-2.c: Ditto.
* gcc.target/i386/sse-ucomiss-pr106113-1.c: Ditto.
* gcc.target/i386/sse-ucomiss-pr106113-2.c: Ditto.
* gcc.target/i386/sse2-comisd-pr106113-1.c: Ditto.
* gcc.target/i386/sse2-comisd-pr106113-2.c: Ditto.
* gcc.target/i386/sse2-ucomisd-pr106113-1.c: Ditto.
* gcc.target/i386/sse2-ucomisd-pr106113-2.c: Ditto.

[Bug c++/106311] [12/13 Regression] internal compiler error in redeclare_class_template

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |12.2
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-07-15
Summary|internal compiler error in  |[12/13 Regression] internal
   |redeclare_class_template|compiler error in
   ||redeclare_class_template
   Keywords||ice-on-invalid-code
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
Started with r12-7562.  Patch:

--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -6377,7 +6377,8 @@ redeclare_class_template (tree type, tree parms, tree
cons)
{
  auto_diagnostic_group d;
  error ("template parameter %q+#D", tmpl_parm);
- inform (DECL_SOURCE_LOCATION (parm), "redeclared here as %q#D", parm);
+ inform (DECL_P (parm) ? DECL_SOURCE_LOCATION (parm) : input_location,
+ "redeclared here as %q#D", parm);
  return false;
}

[Bug c++/106311] New: internal compiler error in redeclare_class_template

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

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

Bug ID: 106311
   Summary: internal compiler error in redeclare_class_template
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Found while reducing bug 106309.

template  struct array;
template  struct array { };

$ ./cc1plus -quiet p.C
p.C:2:21: error: ‘size_t’ has not been declared
2 | template  struct array { };
  | ^~
p.C:1:21: error: template parameter ‘long int ’
1 | template  struct array;
  | ^~~~
p.C:2:38: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘error_mark’ in redeclare_class_template, at
cp/pt.cc:6380
2 | template  struct array { };
  |  ^
0x1bcc50c tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/mpolacek/src/gcc/gcc/tree.cc:8991
0xb06dc6 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/mpolacek/src/gcc/gcc/tree.h:3622
0xe136e1 redeclare_class_template(tree_node*, tree_node*, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:6380
0xc40a20 xref_tag(tag_types, tree_node*, TAG_how, bool)
/home/mpolacek/src/gcc/gcc/cp/decl.cc:15869
0xdaafdd cp_parser_class_head
/home/mpolacek/src/gcc/gcc/cp/parser.cc:26785

[Bug c++/106310] [12/13 Regregression] lookup after this-> seems wrong for dependent lookup

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Failure to resolve call to  |[12/13 Regregression]
   |template member function in |lookup after this-> seems
   |template base class.|wrong for dependent lookup
   Keywords||rejects-valid

--- Comment #3 from Andrew Pinski  ---
And yes there is a defect report in namelookup after this-> . I know there is a
resolution of it but I don't remember which way it went either.

Marking as a regression as GCC 11 and before accepted the code but it might be
invalid ...

[Bug c++/106310] Failure to resolve call to template member function in template base class.

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
template 
struct set{};

template< typename T >
struct Base
{
template< int > int set(T const &) { }
};

template< typename T >
struct Derived : Base< T >
{
void f(T const ) {
this->template set< 0 >(arg);
}
};

[Bug c++/106310] Failure to resolve call to template member function in template base class.

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

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

--- Comment #1 from Andrew Pinski  ---
There is a C++ defect report about this.

[Bug c++/106310] New: Failure to resolve call to template member function in template base class.

[lnicoara at thinkoid dot org via Gcc-bugs]

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

Bug ID: 106310
   Summary: Failure to resolve call to template member function in
template base class.
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lnicoara at thinkoid dot org
  Target Milestone: ---

The following test case fails to compile with gcc (and I believe it should
correctly resolve the call to Base< T >::set):

$ cat t.cc; g++ -c t.cc
#include 

using namespace std;

namespace X {

template< typename T >
struct Base
{
template< std::size_t > void set(T const &) { }
};

template< typename T >
struct Derived : Base< T >
{
void f(T const ) {
this->template set< 0 >(arg);
}
};

}
t.cc: In member function ‘void X::Derived::f(const T&)’:
t.cc:17:39: error: type/value mismatch at argument 1 in template parameter list
for ‘template class std::set’
   17 | this->template set< 0 >(arg);
  |   ^
t.cc:17:39: note:   expected a type, got ‘0’
t.cc:17:39: error: template argument 2 is invalid
t.cc:17:39: error: template argument 3 is invalid

[Bug c++/106309] ICE: error reporting routines re-entered

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-14
 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed, thanks.

I think the problem is ultimately that shorten_compare doesn't have the
'complain' parameter, so when it's called while we're outputting another
diagnostic and shorten_compare attempts to warn, we run into the crash above.

[Bug c++/106309] New: ICE: error reporting routines re-entered

[raffael at casagrande dot ch via Gcc-bugs]

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

Bug ID: 106309
   Summary: ICE: error reporting routines re-entered
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raffael at casagrande dot ch
  Target Milestone: ---

I tried for over 2 hours to get a minimal test case but it is quite involved
and for now I give up. I've created a file with the preprocessed source using
`-freport-bug` and uploaded it to my dropbox:
https://www.dropbox.com/s/oxx299jhx7yi3b2/ccFsUsUT.out?dl=0 . Unfortunately the
file is 11Kb large so I cannot attach it here in bugzilla.

The error message that GCC produces is the following:
--
‘
internal compiler error: error reporting routines re-entered.
0x1b9ca82 warning_at(unsigned int, int, char const*, ...)
???:0
0x95317a shorten_compare(unsigned int, tree_node**, tree_node**, tree_node**,
tree_code*)
???:0
0x915581 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
???:0
0x75f23c build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0x90c45f build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0x8b00a7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x78f993 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x8b9f69 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x1ba82ac pp_format(pretty_printer*, text_info*)
???:0
0x1ba9830 pp_verbatim(pretty_printer*, char const*, ...)
???:0
0x1b9bfa1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x1b9cd76 error(char const*, ...)
???:0
0x8ade04 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x924d0a build_functional_cast(unsigned int, tree_node*, tree_node*, int)
???:0
0x8b1c54 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x8c0d29 instantiate_decl(tree_node*, bool, bool)
???:0
0x8d575b instantiate_pending_templates(int)
???:0
0x7db28f c_parse_final_cleanups()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
--

As far as I can tell, the file which I uploaded to Dropbox should contain all
the information which is necessary to reproduce the bug (e.g. command line and
precompiled sources).
If you need more information to reproduce the bug, please let me know.

[Bug libstdc++/106308] New: Consider using statx(2) for std::filesystem

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

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

Bug ID: 106308
   Summary: Consider using statx(2) for std::filesystem
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-linux*

We don't need all the info that stat(2) provides.


Whenever we want to create a filesystem::file_status we only need st_mode. This
would speed up many operations that use filesystem::file_status or
filesystem::file_type.

filesystem::file_size only uses st_mode and st_size

filesystem::read_symlink only uses st_mode and st_size

filesystem::copy and filesystem::copy_file only use st_mode, st_dev, st_ino,
and st_size.

filesystem::equivalent only uses st_mode, st_dev, st_ino.

filesystem::last_write_time only uses st_mtim.


We never care about atim, ctim, uid, nlink, rdev, blocks, or blksize (although
maybe we should use blksize for filesystem::copy_file). Fetching those fields
for files on remote filesystems is wasteful.

[Bug tree-optimization/103798] memchr with a (small) constant string should be expanded inline.

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r13-1699-gc6cf555a88f8ffb8ec85c2b94fe656ab217260ea
Author: H.J. Lu 
Date:   Fri Jun 17 07:33:06 2022 -0700

Simplify memchr with small constant strings

When memchr is applied on a constant string of no more than the bytes of
a word, simplify memchr by checking each byte in the constant string.

int f (int a)
{
   return  __builtin_memchr ("AE", a, 2) != 0;
}

is simplified to

int f (int a)
{
  return ((char) a == 'A' || (char) a == 'E') != 0;
}

gcc/

PR tree-optimization/103798
* tree-ssa-forwprop.cc: Include "tree-ssa-strlen.h".
(simplify_builtin_call): Inline memchr with constant strings of
no more than the bytes of a word.
* tree-ssa-strlen.cc (use_in_zero_equality): Make it global.
* tree-ssa-strlen.h (use_in_zero_equality): New.

gcc/testsuite/

PR tree-optimization/103798
* c-c++-common/pr103798-1.c: New test.
* c-c++-common/pr103798-2.c: Likewise.
* c-c++-common/pr103798-3.c: Likewise.
* c-c++-common/pr103798-4.c: Likewise.
* c-c++-common/pr103798-5.c: Likewise.
* c-c++-common/pr103798-6.c: Likewise.
* c-c++-common/pr103798-7.c: Likewise.
* c-c++-common/pr103798-8.c: Likewise.
* c-c++-common/pr103798-9.c: Likewise.
* c-c++-common/pr103798-10.c: Likewise.

[Bug analyzer/106284] False positives from -Wanalyzer-tainted-array-index with optimized conditionals

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-07-14

--- Comment #1 from David Malcolm  ---
I'm testing a fix for this.

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed for gcc-13.

Thanks for the report!

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:748f8a8b145dde59c7b63aa68b5a59515b7efc49

commit r13-1698-g748f8a8b145dde59c7b63aa68b5a59515b7efc49
Author: Harald Anlauf 
Date:   Thu Jul 14 22:24:55 2022 +0200

Fortran: error recovery for bad initializers of implied-shape arrays
[PR106209]

gcc/fortran/ChangeLog:

PR fortran/106209
* decl.cc (add_init_expr_to_sym): Handle bad initializers for
implied-shape arrays.

gcc/testsuite/ChangeLog:

PR fortran/106209
* gfortran.dg/pr106209.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Thu, Jul 14, 2022 at 07:35:21PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #1)
> > Instead of an assert(), simply return false to give gfortran a chance to
> > emit an error.
> 
> Steve, your patch does fix z1, but not z2, which hits the
> 
>   gfc_internal_error ("gfc_array_size failed");

Sorry about that.  Your patch looks good to me.

[Bug target/100799] Stackoverflow in optimized code on PPC

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

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

Peter Bergner  changed:

   What|Removed |Added

   Assignee|bergner at gcc dot gnu.org |jskumari at gcc dot 
gnu.org

--- Comment #9 from Peter Bergner  ---
(In reply to Peter Bergner from comment #8)
> I'm sorry, this is still on my TODO to debug.  I have worked on this, but
> got side tracked on other things.  I'll try and refresh myself with where I
> was at and continue working this.

Actually, Surya from my team will take over looking at this.  Reassigning the
bug to her.

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Instead of an assert(), simply return false to give gfortran a chance to
> emit an error.

Steve, your patch does fix z1, but not z2, which hits the

  gfc_internal_error ("gfc_array_size failed");

a few lines later...

The following adjusted patch fixes the latter, too, regtests cleanly,
and gives nicer error messages :)

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 339f8b15035..b6400514731 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2129,10 +2129,21 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_
locus)
  /* The shape may be NULL for EXPR_ARRAY, set it.  */
  if (init->shape == NULL)
{
- gcc_assert (init->expr_type == EXPR_ARRAY);
+ if (init->expr_type != EXPR_ARRAY)
+   {
+ gfc_error ("Bad shape of initializer at %L", >where);
+ return false;
+   }
+
  init->shape = gfc_get_shape (1);
  if (!gfc_array_size (init, >shape[0]))
- gfc_internal_error ("gfc_array_size failed");
+   {
+ gfc_error ("Cannot determine shape of initializer at %L",
+>where);
+ free (init->shape);
+ init->shape = NULL;
+ return false;
+   }
}

  for (dim = 0; dim < sym->as->rank; ++dim)

[Bug analyzer/106301] RFE: analyzer support of mmap

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
mmap has some portability issues to be aware of:
https://www.gnu.org/software/gnulib/manual/html_node/mmap.html
(besides the ones listed there, another one I've come across is sometimes some
headers shortening their name for MAP_ANONYMOUS to just MAP_ANON)

[Bug analyzer/106299] RFE: analyzer handling of fdopen

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
As with other ideas for special-casing certain functions, I'd just be aware of
certain portability issues, as gnulib describes for fdopen here:
https://www.gnu.org/software/gnulib/manual/html_node/fdopen.html

[Bug analyzer/106298] RFE: analyzer handling of dup, dup2, and dup3

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Portability issues to be aware of with dup and dup2, per gnulib:
https://www.gnu.org/software/gnulib/manual/html_node/dup.html
https://www.gnu.org/software/gnulib/manual/html_node/dup2.html

[Bug libfortran/106295] INQUIRE statement bus error at runtime

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
I think the fix for PR83036 (INQUIRE specifier NEXTREC is a 4-byte integer,
should be 8), which changed the layout of struct st_parameter_inquire,
could explain what you observe.

I have no solution to your problem other than recommending not doing what
you did: mix vastly different compiler versions with legacy code.  You would
have been warned if you used modern Fortran with modules.

I bet that most other compilers require (recommend or advise) recompilation
of legacy code without explaining in detail which intrinsic might be affected.

[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to frankhb1989 from comment #4)
> With mingw-w64, the following program shows that the monotonic clock is far
> more precise:
> 
> #include 
> #include 
> 
> int main()
> {
>   using namespace std;
>   timespec ts;
> 
>   if(clock_getres(CLOCK_REALTIME, ) == 0)
>   cout << "CLOCK_REALTIME: " << ts.tv_sec << ',' << ts.tv_nsec << 
> endl;
>   if(clock_getres(CLOCK_MONOTONIC, ) == 0)
>   cout << "CLOCK_MONOTONIC: " << ts.tv_sec << ',' << ts.tv_nsec 
> << endl;
> }
> 
> The result on my machine:
> 
> CLOCK_REALTIME: 0,15625000
> CLOCK_MONOTONIC: 0,489

Is this still an issue in 2022?

Using a mingw-w64 cross-compiler and running under Wine I get:

CLOCK_REALTIME: 0,100
CLOCK_MONOTONIC: 0,100

Is that just because I'm using Wine not real Windows?

[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to frankhb1989 from comment #5)
> BTW, what if the clock_gettime call failed? The current implementation does
> nothing about error handling... (Though for QPC on Windows it should rarely
> fail for machines within a decade.)

None of the errors specified by POSIX or Linux are possible, because we don't
pass invalid clock IDs or invalid pointers to the function.

I don't know if the winpthreads wrapper has additional failure cases. It should
not be possible for it to fail when given valid arguments.

[Bug rtl-optimization/101347] [11/12/13 Regression] ICE in cfg_layout_initialize with __builtin_setjmp and -fprofile-generate -fprofile-use

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
The label at __builtin_setjmp_receiver was added to
nonlocal_goto_handler_labels twice (because __builtin_setjmp_setup was
duplicated), but remove_node_from_insn_list removed only the first copy. A
simple check would have caught this early:

@@ -2928,6 +2899,7 @@ remove_node_from_insn_list (const rtx_insn *node,
rtx_insn_list **listp)
  else
*listp = temp->next ();

+ gcc_checking_assert (!in_insn_list_p (temp->next (), node));
  return;
}


I think a reasonable solution is to move registration of receiver label from
expansion of __builtin_setjmp_setup to expansion of __builtin_setjmp_receiver:

@@ -7467,15 +7467,7 @@ expand_builtin (tree exp, rtx target, rtx subtarget,
machine_mode mode,
  tree label = TREE_OPERAND (CALL_EXPR_ARG (exp, 1), 0);
  rtx_insn *label_r = label_rtx (label);

- /* This is copied from the handling of non-local gotos.  */
  expand_builtin_setjmp_setup (buf_addr, label_r);
- nonlocal_goto_handler_labels
-   = gen_rtx_INSN_LIST (VOIDmode, label_r,
-nonlocal_goto_handler_labels);
- /* ??? Do not let expand_label treat us as such since we would
-not want to be both on the list of non-local labels and on
-the list of forced labels.  */
- FORCED_LABEL (label) = 0;
  return const0_rtx;
}
   break;
@@ -7488,6 +7480,13 @@ expand_builtin (tree exp, rtx target, rtx subtarget,
machine_mode mode,
  rtx_insn *label_r = label_rtx (label);

  expand_builtin_setjmp_receiver (label_r);
+ nonlocal_goto_handler_labels
+   = gen_rtx_INSN_LIST (VOIDmode, label_r,
+nonlocal_goto_handler_labels);
+ /* ??? Do not let expand_label treat us as such since we would
+not want to be both on the list of non-local labels and on
+the list of forced labels.  */
+ FORCED_LABEL (label) = 0;
  return const0_rtx;
}
   break;

[Bug c/106307] New: error when I do a test on a pointer on Arduino 1.8.19

[helene.blanquier at laposte dot net via Gcc-bugs]

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

Bug ID: 106307
   Summary: error when I do a test on a pointer on Arduino 1.8.19
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helene.blanquier at laposte dot net
  Target Milestone: ---

Hi,

Arduino : 1.8.19 (Windows Store 1.8.57.0) (Windows 10), Carte : "Arduino Uno"

C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\arduino-builder
-dump-prefs -logger=machine -hardware C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\hardware
-hardware C:\Users\Phil\Documents\ArduinoData\packages -tools C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\tools-builder
-tools C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\hardware\tools\avr
-tools C:\Users\Phil\Documents\ArduinoData\packages -built-in-libraries
C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\libraries
-libraries D:\Data_Phil\Arduino_programmes\libraries -fqbn=arduino:avr:uno
-vid-pid=2341_0043 -ide-version=10819 -build-path
C:\Users\Phil\AppData\Local\Temp\arduino_build_500670 -warnings=none
-build-cache C:\Users\Phil\AppData\Local\Temp\arduino_cache_742775
-prefs=build.warn_data_percentage=75
-prefs=runtime.tools.arduinoOTA.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\arduinoOTA\1.3.0
-prefs=runtime.tools.arduinoOTA-1.3.0.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\arduinoOTA\1.3.0
-prefs=runtime.tools.avr-gcc.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7
-prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7
-prefs=runtime.tools.avrdude.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino17
-prefs=runtime.tools.avrdude-6.3.0-arduino17.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino17
-verbose
D:\Data_Phil\Arduino_programmes\InMoove_2022_07_14\Arduino_Uno_EasyVR\Arduino_Uno_EasyVR.ino

C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\arduino-builder
-compile -logger=machine -hardware C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\hardware
-hardware C:\Users\Phil\Documents\ArduinoData\packages -tools C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\tools-builder
-tools C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\hardware\tools\avr
-tools C:\Users\Phil\Documents\ArduinoData\packages -built-in-libraries
C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.57.0_x86__mdqgnx93n4wtt\libraries
-libraries D:\Data_Phil\Arduino_programmes\libraries -fqbn=arduino:avr:uno
-vid-pid=2341_0043 -ide-version=10819 -build-path
C:\Users\Phil\AppData\Local\Temp\arduino_build_500670 -warnings=none
-build-cache C:\Users\Phil\AppData\Local\Temp\arduino_cache_742775
-prefs=build.warn_data_percentage=75
-prefs=runtime.tools.arduinoOTA.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\arduinoOTA\1.3.0
-prefs=runtime.tools.arduinoOTA-1.3.0.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\arduinoOTA\1.3.0
-prefs=runtime.tools.avr-gcc.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7
-prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino7
-prefs=runtime.tools.avrdude.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino17
-prefs=runtime.tools.avrdude-6.3.0-arduino17.path=C:\Users\Phil\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino17
-verbose
D:\Data_Phil\Arduino_programmes\InMoove_2022_07_14\Arduino_Uno_EasyVR\Arduino_Uno_EasyVR.ino

Using board 'uno' from platform in folder:
C:\Users\Phil\Documents\ArduinoData\packages\arduino\hardware\avr\1.8.5

Using core 'arduino' from platform in folder:
C:\Users\Phil\Documents\ArduinoData\packages\arduino\hardware\avr\1.8.5

Detecting libraries used...

"C:\\Users\\Phil\\Documents\\ArduinoData\\packages\\arduino\\tools\\avr-gcc\\7.3.0-atmel3.6.1-arduino7/bin/avr-g++"
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections
-fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E
-CC -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=10819 -DARDUINO_AVR_UNO
-DARDUINO_ARCH_AVR
"-IC:\\Users\\Phil\\Documents\\ArduinoData\\packages\\arduino\\hardware\\avr\\1.8.5\\cores\\arduino"
"-IC:\\Users\\Phil\\Documents\\ArduinoData\\packages\\arduino\\hardware\\avr\\1.8.5\\variants\\standard"

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #2 from Andrew Pinski  ---
*** Bug 106305 has been marked as a duplicate of this bug. ***

[Bug ipa/106305] ICE on valid code at -O1 with -funreachable-traps: verify_cgraph_node failed

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 106061.

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

[Bug tree-optimization/106249] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r13-1450-gd2a898666609452e

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #8 from Andrew Pinski  ---
*** Bug 106306 has been marked as a duplicate of this bug. ***

[Bug c/106306] ICE on valid code at -O1 with -funreachable-traps -floop-unroll-and-jam --param unroll-jam-min-percent=0: in execute_todo, at passes.cc:2140

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 106249.

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

[Bug c/106306] New: ICE on valid code at -O1 with -funreachable-traps -floop-unroll-and-jam --param unroll-jam-min-percent=0: in execute_todo, at passes.cc:2140

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106306
   Summary: ICE on valid code at -O1 with -funreachable-traps
-floop-unroll-and-jam --param
unroll-jam-min-percent=0: in execute_todo, at
passes.cc:2140
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/doY9jPM54


[547] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220714 (experimental) [master r13-1696-g29f40a8047f] (GCC) 
[548] % 
[548] % gcctk -O1 -funreachable-traps -floop-unroll-and-jam --param
unroll-jam-min-percent=0 small.c
during GIMPLE pass: ivcanon
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in execute_todo, at passes.cc:2140
2 | int main() {
  | ^~~~
0x719332 execute_todo
../../gcc-trunk/gcc/passes.cc:2140
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[549] % 
[549] % cat small.c
int a[2], b, c;
int main() {
  for (c = 0; c < 3; c++)
for (b = 0; b < 2; b++)
  a[b] = 1;
  return 0;
}

[Bug ipa/106305] New: ICE on valid code at -O1 with -funreachable-traps: verify_cgraph_node failed

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106305
   Summary: ICE on valid code at -O1 with -funreachable-traps:
verify_cgraph_node failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/WdMsGaG3b


[525] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220714 (experimental) [master r13-1696-g29f40a8047f] (GCC) 
[526] % 
[526] % gcctk -O1 -funreachable-traps small.c
small.c:10:1: error: edge points to wrong declaration:
   10 | }
  | ^
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f6e710c75e8
arg-types >>
volatile nothrow public external built-in decl_6 QI :0:0
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_TRAP context

attributes 
chain 
chain 
chain >>>> chain
>
 Instead of: 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f6e710b75e8 precision:32 min  max

pointer_to_this >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f6e710e0498
attributes 
value >
chain 
value 
chain 
chain >>>>>
arg-types >
pointer_to_this >
addressable used public external built-in decl_3 decl_5 QI small.c:1:5
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_PRINTF
context  chain >
b/4 (b) @0x7f6e71200330
  Type: function definition analyzed
  Visibility: semantic_interposition public
  next sharing asm name: 1
  References: a/0 (read) 
  Referring: 
  Function b/4 is inline copy in main/2
  Clone of b/1
  Availability: local
  Function flags: count:1073741824 (estimated locally) body local executed_once
  Called by: main/2 (inlined) (1073741824 (estimated locally),1.00 per call) 
  Calls: __builtin_trap/5 (0 (precise),0.00 per call) 
during IPA pass: inline
small.c:10:1: internal compiler error: verify_cgraph_node failed
0xa224a8 cgraph_node::verify_node()
../../gcc-trunk/gcc/cgraph.cc:3881
0xa112c4 symtab_node::verify()
../../gcc-trunk/gcc/symtab.cc:1359
0xa12507 symtab_node::verify_symtab_nodes()
../../gcc-trunk/gcc/symtab.cc:1387
0xcce301 symtab_node::checking_verify_symtab_nodes()
../../gcc-trunk/gcc/cgraph.h:682
0xcce301 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc-trunk/gcc/ipa.cc:678
0xde8781 execute_todo
../../gcc-trunk/gcc/passes.cc:2159
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[527] % 
[527] % cat small.c
int printf(const char *, ...);
char *a = "hello";
void b(int c) {
  if (c)
printf(a);
}
int main() {
  b(0);
  return 0;
}

[Bug c++/106304] New: [modules] ICE compiling dynamic_cast in constexpr function (in tree_node, at cp/module.cc:9183)

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 106304
   Summary: [modules] ICE compiling dynamic_cast in constexpr
function (in tree_node, at cp/module.cc:9183)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/xz4Mhd8Wc, which Clang accepts:
https://godbolt.org/z/saachff5d.

mod.cpp:
```C++
export module mod;

template struct A : T {
  constexpr A(T v) : T{v} { }
  ~A() = default; // Fixes GCC.
};

struct B {
  virtual ~B() = default;
};

export inline constexpr auto x = A{B{}};

export constexpr const A* y(const B& b) {
  return dynamic_cast*>();
}
```

test.cpp:
```C++
import mod;
static_assert( == y(x));
int main() { }
```

Output:
```
[ 50%] Building CXX object CMakeFiles/mod.dir/mod.cpp.o
mod.cpp:1:8: internal compiler error: in tree_node, at cp/module.cc:9183
1 | export module mod;
  |^~
0x221f229 internal_error(char const*, ...)
???:0
0x74c10d fancy_abort(char const*, int, char const*)
???:0
0x8fd00f trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
0x8fcf41 trees_out::tree_node(tree_node*)
???:0
0x8fde5f trees_out::core_vals(tree_node*)
???:0
0x902d6d trees_out::tree_value(tree_node*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug tree-optimization/106280] dom_oracle::register_transitives is expensive for deep dominator trees

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Andrew Macleod  ---
Created attachment 53300
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53300=edit
proposed patch

See if this helps.  

All of the lookup routines check to see first is there is an existing relation
for an SSA_NAME before deciding what to do.  I forgot to do that with the
transitive code.

So, this patch does 2 things. 
1) If a relation is being registered which already exist, the set routine now
returns NULL for the record as there will be no new work to do
2) IF this is a new relation, before calling register_transitives checks if
either operand was in a relation before (its just a quick bitmap check). If
neither was, there is no possibility of a transitive relation, so no need to
look.

This eliminates a lot of unnecessary work, and based on the pass times spits
out at the end, appears to save a lot of time in the various VRP passes (over
50% time reduction) in your test case.  It also makes some marginal
improvements in GCC source files compilation.

[Bug target/106303] [13 Regression] ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |13.0
   Target Milestone|--- |13.0
Summary|ICE on valid code at -O3|[13 Regression] ICE on
   |with|valid code at -O3 with
   |-fno-inline-small-functions |-fno-inline-small-functions
   |on x86_64-linux-gnu: in |on x86_64-linux-gnu: in
   |extract_insn, at|extract_insn, at
   |recog.cc:2791   |recog.cc:2791
 Target||x86_64-linux-gnu

[Bug rtl-optimization/106303] New: ICE on valid code at -O3 with -fno-inline-small-functions on x86_64-linux-gnu: in extract_insn, at recog.cc:2791

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106303
   Summary: ICE on valid code at -O3 with
-fno-inline-small-functions on x86_64-linux-gnu: in
extract_insn, at recog.cc:2791
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[557] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220714 (experimental) [master r13-1696-g29f40a8047f] (GCC)
[558] %
[558] % gcctk -O3 -fno-inline-small-functions small.c
small.c: In function ‘k’:
small.c:17:1: error: unrecognizable insn:
   17 | }
  | ^
(insn 55 58 66 7 (set (reg:V1TI 90 [ D.2002 ])
(mem/c:TI (symbol_ref:DI ("j") [flags 0x2] )
[2 j+0 S16 A128])) -1
 (nil))
during RTL pass: subreg3
small.c:17:1: internal compiler error: in extract_insn, at recog.cc:2791
0x722c42 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-trunk/gcc/rtl-error.cc:108
0x722c5e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-trunk/gcc/rtl-error.cc:116
0x721191 extract_insn(rtx_insn*)
../../gcc-trunk/gcc/recog.cc:2791
0x1d4e347 decompose_multiword_subregs
../../gcc-trunk/gcc/lower-subreg.cc:1555
0x1d4f1cd execute
../../gcc-trunk/gcc/lower-subreg.cc:1820
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[559] %
[559] % cat small.c
struct a {
  int b;
  int c;
  int d;
  int e;
} i, j;
int f, g, h;
struct a k() {
  while (f)
i = j;
  if (g) {
for (; h; h++)
  i = j;
return j;
  }
  return i;
}
int main() {
  k();
  return 0;
}

[Bug middle-end/85620] Missing ENDBR after swapcontext

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

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

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

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug tree-optimization/106297] stringop-overflow misbehaviour on atomic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed source as requested on
https://gcc.gnu.org/bugs/ ?

[Bug analyzer/106302] New: RFE: provide a way for -fanalyzer to use target flags

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

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

Bug ID: 106302
   Summary: RFE: provide a way for -fanalyzer to use target flags
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003, 106301
  Target Milestone: ---

As noted in the discussion here:
  https://gcc.gnu.org/pipermail/gcc/2022-June/238954.html
-fanalyzer sometimes uses specific target flags when modeling the behavior of
functions, see e.g.: sm-fd.cc, which currently has:

enum access_mode
fd_state_machine::get_access_mode_from_flag (int flag) const
{
  /* FIXME: this code assumes the access modes on the host and
  target are the same, which in practice might not be the case. */

  if ((flag & O_ACCMODE) == O_RDONLY)
{
  return READ_ONLY;
}
  else if ((flag & O_ACCMODE) == O_WRONLY)
{
  return WRITE_ONLY;
}
  return READ_WRITE;
}

where we are using the values of O_ACCMODE, O_RDONLY, and O_WRONLY from the
host's headers, rather than those of the target.

See also bug 106301, where properly supporting mmap would mean looking at
values of MAP_ANONYMOUS, and of the various PROT_ values.

Joseph suggested adding a target hook for this, though I think we'd need an
enum for it, so that we can add various different "well known" values that we'd
want to query for on the host.  Alternatively, perhaps we could directly query
the preprocessor somehow, though that wouldn't work for the LTO case.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106301
[Bug 106301] RFE: analyzer support of mmap

[Bug analyzer/106301] RFE: analyzer support of mmap

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

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

--- Comment #1 from David Malcolm  ---
Potentially we could also track the allocated region, and complain if it is
leaked.  I think this would require handling of mmap/munmap in sm-malloc.cc (so
that we can detect leaks), and support in the region-model code for
memory-mapped regions (for aliasing support)

[Bug analyzer/106301] New: RFE: analyzer support of mmap

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

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

Bug ID: 106301
   Summary: RFE: analyzer support of mmap
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

Now that the analyzer can track uses of file-descriptors, we may want to
special-case mmap:
  https://www.man7.org/linux/man-pages/man2/mmap.2.html

  void *mmap(void *addr, size_t length, int prot, int flags,
 int fd, off_t offset);

If (flags & MAP_ANONYMOUS) is false, then "fd" is required to be an open file
descriptor (and the access direction must match that expressed by "prot").

If (flags & MAP_ANONYMOUS) is true, then some implementations require "fd" to
be -1.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug analyzer/106300] New: RFE: analyzer support for more ways of obtaining an open file descriptor

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

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

Bug ID: 106300
   Summary: RFE: analyzer support for more ways of obtaining an
open file descriptor
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

Currently -fanalyzer special-cases "open" for obtaining a possibly-open file
descriptor (in sm-fd.cc).

We should probably support other ways of obtaining possibly-open file
descriptors, either by special-casing them, or via some new attribute:

creat()
  https://www.man7.org/linux/man-pages/man3/creat.3p.html

pipe() and friends:
  int pipe(int pipefd[2]);
  int pipe2(int pipefd[2], int flags);
  https://www.man7.org/linux/man-pages/man2/pipe.2.html

dup() and friends
  covered in bug 106298

fcntl()
  https://man7.org/linux/man-pages/man2/fcntl.2.html
  (though that's probably a deep rabbit-hole that we may not want to go down)

socket()
  https://www.man7.org/linux/man-pages/man3/socket.3p.html
  See also bug 106140.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug analyzer/106299] New: RFE: analyzer handling of fdopen

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

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

Bug ID: 106299
   Summary: RFE: analyzer handling of fdopen
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

Now that the analyzer supports checking both filedescriptor *and* FILE * usage,
we should probably add special-case handling of fdopen:

  https://www.man7.org/linux/man-pages/man3/fdopen.3p.html

I'm not quite sure how to model the interaction between the two state machines;
perhaps a successful fdopen on a fd should transition the fd from an open state
to the "stop" state (i.e. stop tracking state on this fd), and transition the
FILE * from the start state to the open state.

See also bug 101550, which has an example of using fdopen.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug analyzer/106298] New: RFE: analyzer handling of dup, dup2, and dup3

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

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

Bug ID: 106298
   Summary: RFE: analyzer handling of dup, dup2, and dup3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003
  Target Milestone: ---

Now that -fanalyzer has warnings for file descriptors (especially leaks), we
should probably special-case the following functions (rather than attempt to
express them via attributes):

 int dup(int oldfd);
 int dup2(int oldfd, int newfd);
 int dup3(int oldfd, int newfd, int flags);

https://man7.org/linux/man-pages/man2/dup.2.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[Bug analyzer/106286] fd_diagnostic should implement get_meaning_for_state_change vfunc

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

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

--- Comment #1 from David Malcolm  ---
Compare with e.g.:
  gcc/testsuite/gcc.dg/analyzer/file-meaning-1.c
which tests this for the sm-file.cc

[Bug c++/106086] ICE: trying to capture 'this' in instantiation of generic lambda

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-14
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Reduced C++17 ICE-on-valid testcase:

template
struct foo {
  int operator()(...) const;
};

template
struct bar : foo {
  auto operator()() const {
return [&](auto x) {
  return foo::operator()(decltype(x){});
};
  }
};

bar b;
int i = b()(0);

[Bug rtl-optimization/105041] '-fcompare-debug' failure w/ -mcpu=power6 -O2 -fharden-compares -frename-registers

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Surya Kumari Jangala
:

https://gcc.gnu.org/g:0380d008b1474373852fd2fc921886491304f854

commit r12-8568-g0380d008b1474373852fd2fc921886491304f854
Author: Surya Kumari Jangala 
Date:   Fri Jun 10 19:52:57 2022 +0530

regrename: Fix -fcompare-debug issue in check_new_reg_p [PR105041]

In check_new_reg_p, the nregs of a du chain is computed by obtaining the
MODE of the first element in the chain, and then calling
hard_regno_nregs() with the MODE. But the first element of the chain can
be a DEBUG_INSN whose mode need not be the same as the rest of the
elements in the du chain. This was resulting in fcompare-debug failure
as check_new_reg_p was returning a different result with -g for the same
candidate register. We can instead obtain nregs from the du chain
itself.

2022-06-10  Surya Kumari Jangala  

gcc/
PR rtl-optimization/105041
* regrename.cc (check_new_reg_p): Use nregs value from du chain.

gcc/testsuite/
PR rtl-optimization/105041
* gcc.target/powerpc/pr105041.c: New test.

(cherry picked from commit 3e16b4359e86b36676ed01219e6deafa95f3c16b)

[Bug c/106297] New: stringop-overflow misbehaviour on atomic

[chipitsine at gmail dot com via Gcc-bugs]

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

Bug ID: 106297
   Summary: stringop-overflow misbehaviour on atomic
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chipitsine at gmail dot com
  Target Milestone: ---

repro steps

git clone https://github.com/haproxy/haproxy
cd haproxy

export CC=/path/to/gcc
make CC=$CC ERR=1 TARGET=linux-glibc 

error reported:

src/haproxy.c: In function ‘run_poll_loop’:
include/haproxy/atomic.h:428:39: error: ‘__atomic_load_8’ writing 8 bytes into
a region of size 0 overflows the destination [-Werror=stringop-overflow=]
  428 | #define _HA_ATOMIC_LOAD(val)  __atomic_load_n(val,
__ATOMIC_RELAXED)
  |  
^~
src/haproxy.c:2843:46: note: in expansion of macro ‘_HA_ATOMIC_LOAD’
 2843 | if
((_HA_ATOMIC_LOAD(_tgroup_ctx[i].stopping_threads) &
ha_tgroup_info[i].threads_enabled) !=
  |  ^~~
compilation terminated due to -Wfatal-errors.




error was reviewed by Willy Tarreau in
https://github.com/haproxy/haproxy/issues/1767 and it is considered as false
positive.

I bisected gcc, breaking change is:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=88b504b7a8c5affb0ffa97990d22af2b199e36ed

[Bug libstdc++/106296] Consider using fsync or fdatasync in filesystem::copy_file

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

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

--- Comment #1 from Jonathan Wakely  ---
However, see https://github.com/boostorg/filesystem/issues/186

[Bug libstdc++/106296] New: Consider using fsync or fdatasync in filesystem::copy_file

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

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

Bug ID: 106296
   Summary: Consider using fsync or fdatasync in
filesystem::copy_file
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Writing the file to disk might be slow and could be interrupted by a signal. If
we don't flush explicitly, it will happen when closing the file descriptor, but
if that's interrupted by a signal we don't know if the file was closed or not.

Consider using fsync to flush the data explicitly, looping on EINTR, so that
there's nothing more to do when closing the file.

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

--- Comment #25 from Richard Earnshaw  ---
A quick status update.

I've managed to reduce the testcase to the latest attachment.  The program is
heavily reduced (so some bits likely don't make much sense), but the test still
'passes' when compiled with -fno-strict-aliasing, but fails with the same error
when that option is omitted.

Looking at the assembler output of void
hwy::N_EMU128::TestMulAdd::operator()
>(float, hwy::N_EMU128::Simd) [clone .isra.0]

we see (correct on left, incorrect on right):


add r3, sp, #148add r3, sp, #148
vmov.f32s14, #3.0e+0vmov.f32s14, #3.0e+0
[1] mov r6, r4  mov r6, r4
vmov.f32s15, #2.0e+0vmov.f32s15, #2.0e+0
add r8, sp, #100add r8, sp, #100
add lr, sp, #132add lr, sp, #132
ldm r3, {r0, r1, r2, r3}ldm r3, {r0, r1, r2, r3}
vstr.32 s14, [sp, #152] vstr.32 s14, [sp, #152]
vmov.f32s14, #4.0e+0vmov.f32s14, #4.0e+0
[2] stm r4, {r0, r1, r2, r3}  | stm r5, {r0, r1, r2, r3}
add ip, sp, #116add ip, sp, #116
vstr.32 s14, [sp, #156] vstr.32 s14, [sp, #156]
vmov.f32s14, #5.0e+0vmov.f32s14, #5.0e+0
stm r5, {r0, r1, r2, r3}  <
add r5, sp, #36 add r5, sp, #36
add r10, sp, #196   add r10, sp, #196
vstr.32 s14, [sp, #160] vstr.32 s14, [sp, #160]
add r9, sp, #152add r9, sp, #152
[3] vldr.32 s14, [r6]   vldr.32 s14, [r6]
[4] stm r8, {r0, r1, r2, r3}  | stm r4, {r0, r1, r2, r3}
vmul.f32s15, s14, s15   vmul.f32s15, s14, s15
  > stm r8, {r0, r1, r2, r3}

at [1] we see that r6 and r4 are the same value.  We also see that at [3] a
register is read using r6 as the base.  In the good code on the left, the STM
to r4 is at 2, but in the incorrect code is does not occur until 4, ie
immediately after the load at [3].

I need to dig a bit deeper now on this specific function to see if the alias
information is correct, or if it has somehow been lost/corrupted during the
compilation.

[Bug libfortran/106295] INQUIRE statement bus error at runtime

[ghlixo at gmail dot com via Gcc-bugs]

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

--- Comment #3 from ghlixo at gmail dot com ---
That first attachment contains both parts of the code (main, subroutine).  The
later ones are the individual pieces.

[Bug libfortran/106295] INQUIRE statement bus error at runtime

[ghlixo at gmail dot com via Gcc-bugs]

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

--- Comment #2 from ghlixo at gmail dot com ---
Created attachment 53298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53298=edit
subroutine (to be compiled with older libfortran)

[Bug libfortran/106295] INQUIRE statement bus error at runtime

[ghlixo at gmail dot com via Gcc-bugs]

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

--- Comment #1 from ghlixo at gmail dot com ---
Created attachment 53297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53297=edit
main program (to be compiled with latest release, e.g. 11.2.0)

[Bug libfortran/106295] New: INQUIRE statement bus error at runtime

[ghlixo at gmail dot com via Gcc-bugs]

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

Bug ID: 106295
   Summary: INQUIRE statement bus error at runtime
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ghlixo at gmail dot com
  Target Milestone: ---

Created attachment 53296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53296=edit
Main program (to be compiled with latest release, e.g. 11.2.0)

Fortran subroutine using INQUIRE(UNIT=..., OPENED=...) compiled with gfortran
4.9.2 fails with bus error when linked by gfortran 11.2.0 to main program. 
Works OK if subroutine recompiled with gfortran 11.2.0; clearly a run-time
library version skew; possibly a library versioning bug.

If not a bug, and instead a fact of life of libfortran evolution, there should
be better user-level documentation of when library incompatibilities happen,
ideally in the gfortran/news wiki.  Then those who provide subroutine packages
for general use can alert their users of runtime library compatibility issues. 
The only gfortran documentation I've seen discussing library version
incompatibilities is in

https://gcc.gnu.org/wiki/LibgfortranAbiCleanup

which mentions the ABI being broken in version 7 and again in version 8; I
wouldn't quite call this user-level information. 

Target:  x86_64-apple-darwin18.7.0

Debug output:
#/usr/local/bin/gfortran -g -c -o /tmp/inqtest.o /tmp/inqtest.f  # gfortran
4.9.2
#gfortran -g -o /tmp/inqmain /tmp/inqmain.o /tmp/inqtest.o   # gfortran
11.2.0
#gdb /tmp/inqmain
GNU gdb (GDB) 9.2-macos-20220204
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin18.7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/inqmain...
(gdb) run
Starting program: /private/tmp/inqmain 
[New Thread 0x2603 of process 92337]
[New Thread 0x1803 of process 92337]
[New Thread 0x2303 of process 92337]

Thread 3 received signal SIGBUS, Bus error.
0x0001002e6fe5 in ?? () from /opt/gfortran/lib/libgfortran.5.dylib
(gdb) where
#0  0x0001002e6fe5 in ?? () from /opt/gfortran/lib/libgfortran.5.dylib
#1  0x0001002e7f35 in ?? () from /opt/gfortran/lib/libgfortran.5.dylib
#2  0x00010d55 in zgtfun (nfun=19, nerr=0) at /tmp/inqtest.f:10
#3  0x00010c83 in MAIN__ () at /tmp/inqmain.f:6
(gdb) up
#1  0x0001002e7f35 in ?? () from /opt/gfortran/lib/libgfortran.5.dylib
(gdb) up
#2  0x00010d55 in zgtfun (nfun=19, nerr=0) at /tmp/inqtest.f:10
10  inquire(unit=nfun,opened=lopen)
(gdb) q
A debugging session is active.

Inferior 1 [process 92337] will be killed.

Quit anyway? (y or n) y
#

[Bug target/81652] [meta-bug] -fcf-protection=full bugs

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

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

Bug 85620 Summary: Missing ENDBR after swapcontext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85620

   What|Removed |Added

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

[Bug middle-end/85620] Missing ENDBR after swapcontext

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
 CC||aoliva at gcc dot gnu.org

--- Comment #10 from Alexandre Oliva  ---
ISTM that if you have to insert an endbr over indirect_return, a call should
only be eligible for sibcall if the caller is also marked with indirect_return,
otherwise the callee will indirectly return directly to an upstack caller that
may not have an endbr after the call, no?

[Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

Richard Earnshaw  changed:

   What|Removed |Added

  Attachment #53276|0   |1
is obsolete||
  Attachment #53277|0   |1
is obsolete||

--- Comment #24 from Richard Earnshaw  ---
Created attachment 53295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53295=edit
reduced testcase

[Bug middle-end/106190] [9/10/11/12/13 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug tree-optimization/106293] [13 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
-fno-split-loops makes both variants run at the same speed (but slower than
with splitting loops).  There are still some bogus profile counts/probabilities
with that, notably after ifcvt and vectorization :/

[Bug c++/106294] New: GCC accepts the undefined behavior operation in a constant expression

[xmh970252187 at gmail dot com via Gcc-bugs]

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

Bug ID: 106294
   Summary: GCC accepts the undefined behavior operation in a
constant expression
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xmh970252187 at gmail dot com
  Target Milestone: ---

cpp
enum A {a = 0};
constexpr A e = static_cast(1024);

According to [expr.static.cast p10
> If the enumeration type does not have a fixed underlying type, the value is 
> unchanged if the original value is within the range of the enumeration values 
> ([dcl.enum]), and **otherwise, the behavior is undefined**.

[dcl.enum] p8 defines the range of the enumeration values, which says
> Otherwise, the values of the enumeration are the values representable by a 
> hypothetical integer type with **minimal** width M such that all enumerators 
> can be represented.  

In this case, it is sufficient to represent the value `0` of the unique
enumerator if `M` is `1`. Apparently, the value `1024` cannot be representable
in the hypothetical integer type with minimal width M. So, the full-expression
of the initialization is not a constant expression since the violation of
[expr.const] p5
> an operation that would have undefined behavior as specified in [intro] 
> through [cpp];

However, GCC accepts this example without any diagnosis.

[Bug tree-optimization/106293] [13 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||luoxhu at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
I can reproduce a regression with -Ofast -march=znver2 running on Haswell as
well.  -fopt-info doesn't reveal anything interesting besides

-fast_algorithms.c:133:19: optimized: loop with 2 iterations completely
unrolled (header execution count 32987933)
+fast_algorithms.c:133:19: optimized: loop with 2 iterations completely
unrolled (header execution count 129072791)

obviously the slowdown is in P7Viterbi.  There's only minimal changes on the
GIMPLE side, one notable:

  niters_vector_mult_vf.205_2406 = niters.203_442 & 429496729 |   _2041 =
niters.203_438 & 3;
  _2408 = (int) niters_vector_mult_vf.205_2406;   |   if (_2041 ==
0)
  tmp.206_2407 = k_384 + _2408;   | goto ; [25.00%]
  _2300 = niters.203_442 & 3; <
  if (_2300 == 0) <
goto ; [25.00%]<
  elseelse
goto ; [75.00%]  goto ; [75.00%]

   [local count: 41646173]:|   
[local count: 177683003]:
  # k_2403 = PHI  |  
niters_vector_mult_vf.205_2409 = niters.203_438 & 429496729
  # DEBUG k => k_2403 |   _2411 = (int)
niters_vector_mult_vf.205_2409;
  >   tmp.206_2410
= k_382 + _2411;
  >
  >   
[local count: 162950122]:
  >   # k_2406 =
PHI 

the sink pass now does the transform where it did not do so before.

That's appearantly because of

  /* If BEST_BB is at the same nesting level, then require it to have
 significantly lower execution frequency to avoid gratuitous movement.  */
  if (bb_loop_depth (best_bb) == bb_loop_depth (early_bb)
  /* If result of comparsion is unknown, prefer EARLY_BB.
 Thus use !(...>=..) rather than (...<...)  */
  && !(best_bb->count * 100 >= early_bb->count * threshold))
return best_bb;

  /* No better block found, so return EARLY_BB, which happens to be the
 statement's original block.  */
  return early_bb;

where the SRC count is 96726596 before, 236910671 after and the
destination count is 72544947 before, 177683003 at the destination after.
The edge probabilities are 75% vs 25% and param_sink_frequency_threshold
is exactly 75 as well.  Since 236910671*0.75
is rounded down it passes the test while the previous state has an exact
match defeating it.

It's a little bit of an arbitrary choice,

diff --git a/gcc/tree-ssa-sink.cc b/gcc/tree-ssa-sink.cc
index 2e744d6ae50..9b368e13463 100644
--- a/gcc/tree-ssa-sink.cc
+++ b/gcc/tree-ssa-sink.cc
@@ -230,7 +230,7 @@ select_best_block (basic_block early_bb,
   if (bb_loop_depth (best_bb) == bb_loop_depth (early_bb)
   /* If result of comparsion is unknown, prefer EARLY_BB.
 Thus use !(...>=..) rather than (...<...)  */
-  && !(best_bb->count * 100 >= early_bb->count * threshold))
+  && !(best_bb->count * 100 > early_bb->count * threshold))
 return best_bb;

   /* No better block found, so return EARLY_BB, which happens to be the

fixes the missed sinking but not the regression :/

The count differences start to appear in when LC PHI blocks are added
only for virtuals and then pre-existing 'Invalid sum of incoming counts'
eventually lead to mismatches.  The 'Invalid sum of incoming counts'
start with the loop splitting pass.

fast_algorithms.c:145:10: optimized: loop split

Xionghu Lou did profile count updates there, not sure if that made things
worse in this case.

At least with broken BB counts splitting/unsplitting an edge can propagate
bogus counts elsewhere it seems.

[Bug bootstrap/106156] [13 Regression] libtool fails to link liblto_plugin.la on riscv64-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
Should be fixed now.

[Bug bootstrap/106156] [13 Regression] libtool fails to link liblto_plugin.la on riscv64-linux-gnu

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:29f40a8047fa9b6ccde2174ca126b78a535e1a61

commit r13-1696-g29f40a8047fa9b6ccde2174ca126b78a535e1a61
Author: Martin Liska 
Date:   Thu Jul 14 09:51:33 2022 +0200

lto-plugin: use -pthread only for detected targets

Use -pthread only if we are going to use pthread functionality.

PR bootstrap/106156

lto-plugin/ChangeLog:

* Makefile.am: Use ac_lto_plugin_extra_ldflags for AM_LDFLAGS.
* configure.ac: Use AC_SUBST(ac_lto_plugin_extra_ldflags).
* Makefile.in: Regenerate.
* configure: Regenerate.

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b

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

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

--- Comment #10 from Andreas Krebbel  ---
We generate the movstrict target operand with gen_lowpart. If the operand for
gen_lowpart is already a paradoxical subreg the two subregs cancel each other
out and we end up with a plain reg. I'm testing the following patch right now.
It falls back to a normal move in that case and fixes the testcase:

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 5aaf76a9490..d90ec1a6de1 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -6523,6 +6523,14 @@ s390_expand_insv (rtx dest, rtx op1, rtx op2, rtx src)
  rtx low_dest = gen_lowpart (smode, dest);
  rtx low_src = gen_lowpart (smode, src);

+ /* In case two subregs cancelled each other out, do a normal
+move.  */
+ if (!SUBREG_P (low_dest))
+   {
+ emit_move_insn (low_dest, low_src);
+ return true;
+   }
+
  switch (smode)
{
case E_QImode: emit_insn (gen_movstrictqi (low_dest, low_src));
return true;

[Bug tree-optimization/106293] [13 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Last reconfirmed||2022-07-14
   Keywords||missed-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Version|12.0|13.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
Summary|456.hmmer at -Ofast |[13 Regression] 456.hmmer
   |-march=native regressed by  |at -Ofast -march=native
   |19% on zen2 and zen3 in |regressed by 19% on zen2
   |July 2022   |and zen3 in July 2022

--- Comment #1 from Richard Biener  ---
I will have a look - the change should not have resulted in (major) code
generation changes.  Some effects result in slightly different CFG in some
cases (somewhat mitigated with r13-1503-gc3d2600cfb476e which I will
cherry-pick for investigating).

[Bug tree-optimization/106293] New: 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

Bug ID: 106293
   Summary: 456.hmmer at -Ofast -march=native regressed by 19% on
zen2 and zen3 in July 2022
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

The benchmark 456.hmmer from SPECINT 2006 suite has regressed on zen2 when
compiled with -Ofast -march=native, with or without LTO. See:

  https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=301.180.0
  https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.180.0

On zen3, LNT only reported a similar regression with LTO:

  https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=476.180.0


There may be some effect also on the Kabylake:
  https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=2.180.0

On Zen2 (with LTO), I have manually bisected the regression to:
  d2a89809452ef79a14feae1cadc3538e4b45 is the first bad commit
  commit d2a89809452ef79a14feae1cadc3538e4b45
  Author: Richard Biener 
  Date:   Tue Jun 21 16:17:58 2022 +0200

Put virtual operands into loop-closed SSA

When attempting to manually update SSA form after high-level loop
transforms such as loop versioning it is helpful when the loop-closed
SSA form includes virtual operands.  While we have the special
rewrite_virtuals_into_loop_closed_ssa function that doesn't
presently scale, invoking update_ssa by itself.  So the following
makes the regular loop-closed SSA form also cover virtual operands.
For users of loop_version this allows to use cheaper
TODO_update_ssa_no_phi, skipping dominance frontier compute
(for the whole function) and iterated dominance frontiers for each
copied def.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/106292] Wrong code with -O3

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

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

--- Comment #2 from Aldy Hernandez  ---
(In reply to Martin Liška from comment #1)
> Fixed with r13-1684-g554b21edb9ec91a8.

Thanks for tracking this down Martin.

Sorry for the pain.  It was a silly oversight.

[Bug target/106282] m68k: Problem with thread-local storage and -mcpu=5206 since r9-2326-gede9446c26a929

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-14
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||schwab at gcc dot gnu.org
Summary|m68k: Problem with  |m68k: Problem with
   |thread-local storage and|thread-local storage and
   |-mcpu=5206  |-mcpu=5206 since
   ||r9-2326-gede9446c26a929
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r9-2326-gede9446c26a929.

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

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

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

Bug 106292 Summary: Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106292

   What|Removed |Added

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

[Bug tree-optimization/106292] Wrong code with -O3

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||aldyh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Fixed with r13-1684-g554b21edb9ec91a8.

[Bug tree-optimization/106292] New: Wrong code with -O3

[vsevolod.livinskiy at gmail dot com via Gcc-bugs]

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

Bug ID: 106292
   Summary: Wrong code with -O3
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

The wrong optimization causes out-of-bounds array access, which leads to a
Segmentation fault. Unfortunately, I was not able to merge the reproducer into
a single file ([[gnu::noipa]] and __attribute__((noipa)) didn't work or I've
used them incorrectly). This looks like a recent bug because we started to
detect it on Tuesday (June 12th).

Reproducer:
//driver.cpp
#include 

bool var_0 = (bool)1;
unsigned int arr_44 = 3397135069U;
bool arr_8 [7];
short arr_61 [140];

void test();

int main() {
  test();
  printf("%u\n", arr_61[117]);
  if (arr_61[117] != 9)
__builtin_abort();
}

//func.cpp
extern bool var_0;
extern unsigned arr_44;
extern bool arr_8[];
extern short arr_61[];
const unsigned (const unsigned , unsigned ) { return f ? c : f; }
bool bar(bool c) { return c; }
void test() {
  for (int b = 0; b < 7; b += var_0)
arr_8[b] = 1;
  for (int d = 0; d < bar(var_0) + 9; d++)
for (unsigned e = 0; e < 14; e++)
  arr_61[d * e] = a(d, arr_44);
}

Error:
>$ g++ -O2 func.cpp driver.cpp && ./a.out 
9
>$ g++ -O3 func.cpp driver.cpp && ./a.out 
Segmentation fault (core dumped)

gcc version 13.0.0 20220713 (c479c40f8c8fee0fb70e8a365b61c55739f448e1)