[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r13-1083-gf907cf4c07cf51863dadbe90894e2ae3382bada5
Author: Kewen Lin 
Date:   Tue Jun 14 00:57:01 2022 -0500

vect: Move suggested_unroll_factor applying [PR105940]

As PR105940 shown, when rs6000 port tries to assign
m_suggested_unroll_factor by 4 or so, there will be ICE on:

  exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
 loop_vinfo->suggested_unroll_factor);

In function vect_analyze_loop_2, the current place of
suggested_unroll_factor applying can't guarantee it's
applied for all cases.  As the case shows, vectorizer
could retry with SLP forced off, the vf is reset by
saved_vectorization_factor which isn't applied with
suggested_unroll_factor before.  It means it can end
up with one vf which neglects suggested_unroll_factor.
I think it's off design, we should move the applying
of suggested_unroll_factor after start_over.

PR tree-optimization/105940

gcc/ChangeLog:

* tree-vect-loop.cc (vect_analyze_loop_2): Move the place of
applying suggested_unroll_factor after start_over.

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

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

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

--- Comment #23 from Siddhesh Poyarekar  ---
(In reply to Siddhesh Poyarekar from comment #22)
> An arbitrary N will only make it abuse-friendly and potentially mask bugs. 
> IMO if we choose to make multiple levels here it should only be
> -fstrict-flex-arrays={1,2} where 1 (the default) only allows "[]" and 2
> allows "[0]", disabling all other size values.  For anything else,

That could be ""[0]" or "[1]", disabling all other size values" if we want to
build gcc and vim with -fstrict-flex-arrays and keep fortification enabled. 
Vim explicitly disables fortification right now for this reason.

> -fno-strict-flex-arrays.  My opinion on the default is not strong FWIW.

Also I wonder if there should be an analogous -Wstrict-flex-arrays to issue
warnings alongside changing codegen.

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

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

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

--- Comment #22 from Siddhesh Poyarekar  ---
(In reply to Kees Cook from comment #21)
> How about "-fnot-flex-arrays=N" to mean "trailing arrays with N or more
> elements will NOT be treated like a flex array"?
> 
> Then code with sockaddr can use "-fnot-flex-arrays=15", code with "[1]"
> arrays can use "-fnot-flex-arrays=2", code with only "[0]" arrays can use
> "-fnot-flex-arrays=1", and "-fstrict-flex-arrays" can be an alias for
> "-fnot-flex-arrays=0", which Linux would use.

An arbitrary N will only make it abuse-friendly and potentially mask bugs.  IMO
if we choose to make multiple levels here it should only be
-fstrict-flex-arrays={1,2} where 1 (the default) only allows "[]" and 2 allows
"[0]", disabling all other size values.  For anything else,
-fno-strict-flex-arrays.  My opinion on the default is not strong FWIW.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com via Gcc-bugs]

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

--- Comment #8 from John Kanapes  ---
True. I was confused that sources were needed only by the GNAT subsystem.
I am working to recreate the issue in a smaller, more portable, easier to
understand code. I hope, I have a couple of days before closing this ticket:)

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #21 from Kees Cook  ---
(In reply to Martin Sebor from comment #20)
> Well, I just "asked" for such an option the same way you asked for
> -fstrict-flex-arrays in comment #3, because I believe it would be useful to
> make the BOS improvements you're looking for available even to code that
> can't do a whole-hog replacement of all trailing arrays with flexible array

Right, sorry, I meant, "I have a project waiting to use this feature right
now", where as other projects might, upon discovering this feature, decide they
also only need "-fstrict-flex-arrays". e.g. what option would GCC itself use?

> members.  The spelling of the option names doesn't seem important to me
> (they could be separate options, or the same one with an argument).

How about "-fnot-flex-arrays=N" to mean "trailing arrays with N or more
elements will NOT be treated like a flex array"?

Then code with sockaddr can use "-fnot-flex-arrays=15", code with "[1]" arrays
can use "-fnot-flex-arrays=2", code with only "[0]" arrays can use
"-fnot-flex-arrays=1", and "-fstrict-flex-arrays" can be an alias for
"-fnot-flex-arrays=0", which Linux would use.

[Bug c++/105964] [12/13 Regression] Return type deduction fails during NTTP use of function dependent on template parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.2

[Bug c++/105964] [12/13 Regression] Return type deduction fails during NTTP use of function dependent on template parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105779

--- Comment #1 from Andrew Pinski  ---
Well PR 105779 is related but this testcase is not fixed ...

[Bug c++/105964] New: [12/13 Regression] Return type deduction fails during NTTP use of function dependent on template parameter

[enolan at alumni dot cmu.edu via Gcc-bugs]

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

Bug ID: 105964
   Summary: [12/13 Regression] Return type deduction fails during
NTTP use of function dependent on template parameter
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: enolan at alumni dot cmu.edu
  Target Milestone: ---

Created attachment 53132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53132=edit
Proof of concept that reproduces the bug

"It seems that, in a nested template expansion context, for SFINAE purposes,
when filling in default arguments, the compiler is declining to instantiate a
function which has a deduced return type.  Because it declines to instantiate
that function, it can't wind up with a function to implicitly convert to a
pointer-to-function which is a valid NTTP."

However, as can be seen in the attached expanded POC, using an ampersand to
force taking the address of the function when using it as an NTTP causes it to
work again.

Godbolt link: https://godbolt.org/z/j8e6Y5Pq9

Minimal reproduction (godbolt link and attachment contain more context):

struct token {};

struct example {};

template< typename >
struct helper
{
static constexpr auto c() { return 42; }
};

struct impostor_c
{
template< typename T, auto= helper< T >::c >
static example func();
};

example c= impostor_c::func< token >();



> the exact version of gcc

gcc version 12.1.1 20220507 (Red Hat 12.1.1-1) (GCC)

> the system type

Fedora release 37 (rawhide)

> the options given when GCC was configured/built

Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.1.1-20220507/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1

> the complete command line that triggers the bug

g++ -std=c++17 poc.cpp

> the compiler output

poc.cpp:55:37: error: no matching function for call to
‘impostor_c::func()’
   55 | example c= impostor_c::func< token >();
  |~^~
poc.cpp:28:20: note: candidate: ‘template > static
example impostor_c::func()’
   28 | static example func();
  |^~~~
poc.cpp:28:20: note:   template argument deduction/substitution failed:

[Bug libquadmath/105101] incorrect rounding for sqrtq

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #24 from joseph at codesourcery dot com  ---
On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:

> > For long double it's sysdeps/ieee754/soft-fp/s_fmal.c in glibc - some 
> > adjustments would be needed to be able to use that as a version for 
> > _Float128 (where sysdeps/ieee754/float128/s_fmaf128.c currently always 
> > uses the ldbl-128 version), in appropriate cases.
> >
> 
> Way to complicated for mere gcc user like myself.
> Hopefully, Thomas Koenig will understand better.

glibc needs to handle a lot of different configurations with various 
choices of supported floating-point types - resulting in complexity around 
how the particular function implementations are chosen for a given system 
- as well as other portability considerations.  There is also complexity 
resulting from the functions covering many different use cases - and thus 
needing to follow all the IEEE 754 requirements for those functions 
although many users may only care about some of those requirements.

> > The underlying arithmetic (in libgcc, not libquadmath) uses the hardware 
> > rounding mode and exceptions (if the x87 and SSE rounding modes disagree, 
> > things are liable to go wrong), via various macros defined in 
> > sfp-machine.h.
> 
> Oh, a mess!
> With implementation that is either 99% or 100% integer being controlled by SSE
> control is WRONG. x87 control word, of course, is no better than SSE.
> But BOTH  I have no words.

Any given libgcc build will only use one of the rounding modes (SSE for 
64-bit, x87 for 32-bit) - but which exception state gets updated in the 
32-bit case depends on whether libgcc was built for SSE arithmetic.

As far as IEEE 754 is concerned, there is only one rounding mode for all 
operations with a binary result (and a separate rounding mode for decimal 
FP results).  As far as the C ABI is concerned, it's not valid for the two 
rounding modes to be different at any ABI boundary; fesetround will always 
set both, while fetestexcept etc. handle both sets of exception flags by 
ORing them together.  *But* glibc's internal optimizations for code that 
saves and restores floating-point state internally try to manipulate only 
SSE state, or only x87 state, in functions that should only use one of 
those two sets of state, so code called from within those functions may 
need to work properly when the two rounding modes are different.  
Together with the above point about which exception state gets used in 
libgcc support for _Float128, this results in those optimizations, in the 
float128 case, sometimes only needing to handle SSE state but sometimes 
needing to handle both sets of state (see glibc's 
sysdeps/x86/fpu/fenv_private.h).

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

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

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

--- Comment #20 from Martin Sebor  ---
Well, I just "asked" for such an option the same way you asked for
-fstrict-flex-arrays in comment #3, because I believe it would be useful to
make the BOS improvements you're looking for available even to code that can't
do a whole-hog replacement of all trailing arrays with flexible array members. 
The spelling of the option names doesn't seem important to me (they could be
separate options, or the same one with an argument).

[Bug c/105963] New: -Woverlength-strings: don't underline the entire offending string

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

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

Bug ID: 105963
   Summary: -Woverlength-strings: don't underline the entire
offending string
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

So I have been trying to enable -Woverlength-strings in my GCC build, just to
see if it would work, and ran into this warning:

In file included from ../../fixincludes/fixincl.c:91:
../../fixincludes/fixincl.x:189:1: warning: string length ‘4756’ is greater
than the length ‘4095’ ISO C99 compilers are required to support
[-Woverlength-strings]
  189 | "/* This file prototypes the long double functions available on Mac
OS\n\
  |
^
  190 |10.3.9.  */\n\
  |~~
  191 | #ifndef __MATH__\n\
  | ~~~
  192 | # undef __APPLE_CC__\n\
  | ~~~
  193 | # define __APPLE_CC__  1345\n\
  | ~~
  194 | # include_next \n\
  | ~~~
  195 | # undef __APPLE_CC__\n\
  | ~~~
  196 | # define __APPLE_CC__ 1\n\
  | ~~
  197 | # ifndef __LIBMLDBL_COMPAT\n\
  | ~
  198 | #  ifdef __LONG_DOUBLE_128__\n\
  | ~~~
  199 | #   define __LIBMLDBL_COMPAT(sym) __asm(\"_\" #sym \"$LDBL128\")\n\
  | ~~~
  200 | #  else\n\
  | ~~
  201 | #   define __LIBMLDBL_COMPAT(sym)\n\
  | 
  202 | #  endif /* __LONG_DOUBLE_128__ */\n\
  | ~
  203 | # endif /* __LIBMLDBL_COMPAT */\n\
  | ~~
  204 | # ifdef __cplusplus\n\
  | ~~
  205 |extern \"C\" {\n\
  |~
  206 | # endif\n\
  | ~~
  207 |   extern long double acosl( long double ) __LIBMLDBL_COMPAT(acosl);\n\
  |   
  208 |   extern long double asinl( long double ) __LIBMLDBL_COMPAT(asinl);\n\
  |   
  209 |   extern long double atanl( long double ) __LIBMLDBL_COMPAT(atanl);\n\
  |   
  210 |   extern long double atan2l( long double, long double )
__LIBMLDBL_COMPAT(atan2l);\n\
  |  
~~~
  211 |   extern long double cosl( long double ) __LIBMLDBL_COMPAT(cosl);\n\
  |   ~~
  212 |   extern long double sinl( long double ) __LIBMLDBL_COMPAT(sinl);\n\
  |   ~~
  213 |   extern long double tanl( long double ) __LIBMLDBL_COMPAT(tanl);\n\
  |   ~~
  214 |   extern long double acoshl( long double )
__LIBMLDBL_COMPAT(acoshl);\n\
  |  
~~
  215 |   extern long double asinhl( long double )
__LIBMLDBL_COMPAT(asinhl);\n\
  |  
~~
  216 |   extern long double atanhl( long double )
__LIBMLDBL_COMPAT(atanhl);\n\
  |  
~~
  217 |   extern long double coshl( long double ) __LIBMLDBL_COMPAT(coshl);\n\
  |   
  218 |   extern long double sinhl( long double ) __LIBMLDBL_COMPAT(sinhl);\n\
  |   
  219 |   extern long double tanhl( long double ) __LIBMLDBL_COMPAT(tanhl);\n\
  |   
  220 |   extern long double expl( long double ) __LIBMLDBL_COMPAT(expl);\n\
  |   ~~
  221 |   extern long double exp2l( long double ) __LIBMLDBL_COMPAT(exp2l);\n\
  |   
  222 |   extern long double expm1l( long double )
__LIBMLDBL_COMPAT(expm1l);\n\
  |  
~~
  223 |   extern long double logl( long double ) __LIBMLDBL_COMPAT(logl);\n\
  |   ~~
  224 |   extern long double log10l( long 

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

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

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

--- Comment #4 from David Malcolm  ---
As well as the false positive, the diagnostic path is rather unreadable due to
inlining.  I've filed a separate bug about this (PR 105962).

[Bug analyzer/105962] New: Unhelpful diagnostics paths from analyzer in the face of inlining

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

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

Bug ID: 105962
   Summary: Unhelpful diagnostics paths from analyzer in the face
of inlining
   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
  Target Milestone: ---

Consider this double-free:


void foo (void *p)
{
  __builtin_free (p);
}

void bar (void *q)
{
  foo (q);
  foo (q);
}


Below -O2, -fanalyzer shows the calls and returns:

../../src/gcc/testsuite/gcc.dg/analyzer/inline-1.c: In function ‘foo’:
../../src/gcc/testsuite/gcc.dg/analyzer/inline-1.c:3:3: warning: double-‘free’
of ‘p’ [CWE-415] [-Wanalyzer-double-free]
3 |   __builtin_free (p);
  |   ^~
  ‘bar’: events 1-2
|
|6 | void bar (void *q)
|  |  ^~~
|  |  |
|  |  (1) entry to ‘bar’
|7 | {
|8 |   foo (q);
|  |   ~~~
|  |   |
|  |   (2) calling ‘foo’ from ‘bar’
|
+--> ‘foo’: events 3-4
   |
   |1 | void foo (void *p)
   |  |  ^~~
   |  |  |
   |  |  (3) entry to ‘foo’
   |2 | {
   |3 |   __builtin_free (p);
   |  |   ~~
   |  |   |
   |  |   (4) first ‘free’ here
   |
<--+
|
  ‘bar’: events 5-6
|
|8 |   foo (q);
|  |   ^~~
|  |   |
|  |   (5) returning to ‘bar’ from ‘foo’
|9 |   foo (q);
|  |   ~~~
|  |   |
|  |   (6) passing freed pointer ‘q’ in call to ‘foo’ from ‘bar’
|
+--> ‘foo’: events 7-8
   |
   |1 | void foo (void *p)
   |  |  ^~~
   |  |  |
   |  |  (7) entry to ‘foo’
   |2 | {
   |3 |   __builtin_free (p);
   |  |   ~~
   |  |   |
   |  |   (8) second ‘free’ here; first ‘free’ was at (4)
   |


but at -O2 and above, we show the unhelpful:

In function ‘foo’,
inlined from ‘bar’ at
../../src/gcc/testsuite/gcc.dg/analyzer/inline-1.c:9:3:
../../src/gcc/testsuite/gcc.dg/analyzer/inline-1.c:3:3: warning: double-‘free’
of ‘q’ [CWE-415] [-Wanalyzer-double-free]
3 |   __builtin_free (p);
  |   ^~
  ‘bar’: events 1-2
|
|3 |   __builtin_free (p);
|  |   ^~
|  |   |
|  |   (1) first ‘free’ here
|  |   (2) second ‘free’ here; first ‘free’ was at (1)

which is somewhat mystifying.

This is happening because -fanalyzer is running after inlining and sees this at
the gimple level:

void bar (void * q)
{
   [local count: 1073741824]:
  __builtin_free (q_2(D));
  __builtin_free (q_2(D));
  return;

}

We can probably improve the readability by fixing up the events in the
diagnostic path based on the LOCATION_BLOCK inlining information captured in
the stmt location values.

I tried a version of this years ago in:
 
https://dmalcolm.fedorapeople.org/gcc/2020-02-20/gcc-newgit-analyzer-gcc10-analysis-gcc10-v52-relative-to-bc0f8df124f6ee12c82c5a6c1335868a15bcaecb/0012-FIXME-WIP-on-inlining-and-paths.patch

[Bug libquadmath/105101] incorrect rounding for sqrtq

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #23 from Michael_S  ---
(In reply to jos...@codesourcery.com from comment #22)
> On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> 
> > > The function should be sqrtf128 (present in glibc 2.26 and later on 
> > > x86_64, x86, powerpc64le, ia64).  I don't know about support in non-glibc 
> > > C libraries.
> > 
> > x86-64 gcc on Godbolt does not appear to know about it.
> > I think, Godbolt uses rather standard Linux with quite new glibc and 
> > headers.
> > https://godbolt.org/z/Y4YecvxK6
> 
> Make sure to define _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__ to 
> get these declarations.
> 

Thank you.
It made a difference on Goldbolt.
Does not help MSYS2, but at least I will be able to test on Linux.


> > May be. I don't know how to get soft-fp version.
> 
> For long double it's sysdeps/ieee754/soft-fp/s_fmal.c in glibc - some 
> adjustments would be needed to be able to use that as a version for 
> _Float128 (where sysdeps/ieee754/float128/s_fmaf128.c currently always 
> uses the ldbl-128 version), in appropriate cases.
>

Way to complicated for mere gcc user like myself.
Hopefully, Thomas Koenig will understand better.

> > It seems, you didn't pay attention that in my later posts I am giving
> > implementations of binary128 *division* rather than sqrtq().
> 
> Ah - binary128 division is nothing to do with libquadmath at all (the 
> basic arithmetic operations go in libgcc, not libquadmath).  Using a PR 
> about one issue as an umbrella discussion of various vaguely related 
> things is generally confusing and unhelpful to tracking the status of what 
> is or is not fixed.

You are right.
Again, hopefully, Thomas Koenig will open a thread in which a discussion of all
issues related to libquadmath and binary128 will be on topic.
But, formally speaking, slowness of division or of fma are not bugs. 
So, may be, there are better places than bugzilla to discuss them.
I just don't know what place it is.
The good thing about bugzilla is a convenient forum-like user interface.


> 
> In general, working out how to optimize the format-generic code in soft-fp 
> if possible would be preferred to writing format-specific implementations.  
> Note that for multiplication and division there are already various 
> choices of implementation approaches that can be selected via macros 
> defined in sfp-machine.h.
> 

I am not sure that I like an idea of format-generic solution for specific case
of soft binary128.
binary128 isvery special, because it is the smallest. It can gain ALOT of speed 
from format-specific handling. Not sure if 3x, but pretty certain about 2x.

> > BTW, I see no mentioning of rounding control or of any sort of exceptions in
> > GCC libquadmath docs. No APIs with names resembling fesetround() or
> > mpfr_set_default_rounding_mode().
> 
> The underlying arithmetic (in libgcc, not libquadmath) uses the hardware 
> rounding mode and exceptions (if the x87 and SSE rounding modes disagree, 
> things are liable to go wrong), via various macros defined in 
> sfp-machine.h.

Oh, a mess!
With implementation that is either 99% or 100% integer being controlled by SSE
control is WRONG. x87 control word, of course, is no better than SSE.
But BOTH  I have no words.

Hopefully, libquadmath is saner than that, but I am unable to figure it out
from docs.

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-06-13
 Ever confirmed|0   |1

--- Comment #3 from David Malcolm  ---
Thanks - I can see the reproduce the bug with that (tested with trunk).

[Bug c++/105956] [13 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819

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

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

--- Comment #5 from Marek Polacek  ---
So far reduced to

template  struct index_tuple;
template > struct build_number_seq;
template 
struct build_number_seq>
: build_number_seq> {};
template  struct build_number_seq<0, index_tuple> {
  typedef index_tuple type;
};
template  struct typelist;
template  struct typelist_element;
template 
struct typelist_element<0, typelist> {
  typedef Head type;
};
template  struct sizeof_typelist;
template  struct sizeof_typelist> {
  static const long value = sizeof...(Types);
};
template  struct invert_typelist_impl;
template 
struct invert_typelist_impl> {
  static const long last_idx = sizeof_typelist::value - 1;
  typedef typelist<
  typename typelist_element::type...>
  type;
};
template  struct invert_typelist;
template  struct invert_typelist> {
  typedef typename invert_typelist_impl<
  typelist,
  typename build_number_seq::type>::type type;
};
template  struct do_pack;
struct hook_defaults;
typedef do_pack>::type> type;

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[eggert at cs dot ucla.edu via Gcc-bugs]

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

--- Comment #2 from eggert at cs dot ucla.edu ---
Created attachment 53131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53131=edit
reproducer for the bug (compressed with xz)

The uncompressed t.i was too large for bugzilla, so here's the same file,
compressed with xz.

[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

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

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

--- Comment #1 from David Malcolm  ---
(In reply to eggert from comment #0)

[...snip...]

> Compile the attached program (derived from bleeding-edge Emacs) with:

I'm not seeing an attachment - do you still have this file, and can you try
attaching it again please?

Thanks!

[...snip...]

[Bug libquadmath/105101] incorrect rounding for sqrtq

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #22 from joseph at codesourcery dot com  ---
On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:

> > The function should be sqrtf128 (present in glibc 2.26 and later on 
> > x86_64, x86, powerpc64le, ia64).  I don't know about support in non-glibc 
> > C libraries.
> 
> x86-64 gcc on Godbolt does not appear to know about it.
> I think, Godbolt uses rather standard Linux with quite new glibc and headers.
> https://godbolt.org/z/Y4YecvxK6

Make sure to define _GNU_SOURCE or __STDC_WANT_IEC_60559_TYPES_EXT__ to 
get these declarations.

> May be. I don't know how to get soft-fp version.

For long double it's sysdeps/ieee754/soft-fp/s_fmal.c in glibc - some 
adjustments would be needed to be able to use that as a version for 
_Float128 (where sysdeps/ieee754/float128/s_fmaf128.c currently always 
uses the ldbl-128 version), in appropriate cases.

> It seems, you didn't pay attention that in my later posts I am giving
> implementations of binary128 *division* rather than sqrtq().

Ah - binary128 division is nothing to do with libquadmath at all (the 
basic arithmetic operations go in libgcc, not libquadmath).  Using a PR 
about one issue as an umbrella discussion of various vaguely related 
things is generally confusing and unhelpful to tracking the status of what 
is or is not fixed.

In general, working out how to optimize the format-generic code in soft-fp 
if possible would be preferred to writing format-specific implementations.  
Note that for multiplication and division there are already various 
choices of implementation approaches that can be selected via macros 
defined in sfp-machine.h.

> BTW, I see no mentioning of rounding control or of any sort of exceptions in
> GCC libquadmath docs. No APIs with names resembling fesetround() or
> mpfr_set_default_rounding_mode().

The underlying arithmetic (in libgcc, not libquadmath) uses the hardware 
rounding mode and exceptions (if the x87 and SSE rounding modes disagree, 
things are liable to go wrong), via various macros defined in 
sfp-machine.h.

[Bug analyzer/105961] New: -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"

[eggert at cs dot ucla.edu via Gcc-bugs]

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

Bug ID: 105961
   Summary: -Wanalyzer-use-of-uninitialized-value false positive
after "= {0}"
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

This is gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1) on x86-64. I do not
observe the bug with gcc-12 (Ubuntu 12-20220319-1ubuntu1) 12.0.1 20220319
(experimental) [master r12-7719-g8ca61ad148f] on x86-64.

Compile the attached program (derived from bleeding-edge Emacs) with:

gcc -O2 -S -fanalyzer t.i

GCC complains:

In function ‘dump_mmap_release’,
inlined from ‘pdumper_load’ at t.i:50527:5:
t.i:49512:10: warning: use of uninitialized value ‘sections[i].release’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
49512 |   if (map->release)
  |   ~~~^
  ‘pdumper_load’: events 1-9
|
|50318 | pdumper_load (const char *dump_filename, char *argv0)
|  | ^~~~
|  | |
|  | (1) entry to ‘pdumper_load’
|..
|50331 |   struct dump_memory_map sections[NUMBER_DUMP_SECTIONS] = { 0 };
|  |  
|  |  |
|  |  (2) region created on stack here
|..


The region is obviously initialized, via the "= { 0 }" at the end. The
following change pacifies GCC, but should not be necessary.

--- t.i 2022-06-13 13:06:59.0 -0700
+++ u.i 2022-06-13 13:09:18.0 -0700
@@ -50329,6 +50329,7 @@
   struct dump_header header_buf = { 0 };
   struct dump_header *header = _buf;
   struct dump_memory_map sections[NUMBER_DUMP_SECTIONS] = { 0 };
+  memset (sections, 0, sizeof sections);

   const struct timespec start_time = current_timespec ();
   char *dump_filename_copy;

[Bug target/105960] Crash in 32-bit mode

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #4 from M Welinder  ---
And added to the link lines too, btw.

[Bug target/105960] Crash in 32-bit mode

[terra at gnome dot org via Gcc-bugs]

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

M Welinder  changed:

   What|Removed |Added

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

--- Comment #3 from M Welinder  ---
This happens with -fPIC added to COMPILE too.  (It got dropped somewhere in the
minimization of the sample.)

[Bug libquadmath/105101] incorrect rounding for sqrtq

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #21 from Michael_S  ---
(In reply to jos...@codesourcery.com from comment #20)
> On Sat, 11 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> 
> > On MSYS2 _Float128 and __float128 appears to be mostly the same thing, 
> > mapped
> > to the same library routines with significant difference that _Float128 is 
> > not
> > accessible from C++. Since all my test benches are written in C++ I can't 
> > even
> > validate that what I wrote above is 100% true.
> > 
> > Also according to my understanding of glibc docs (not the clearest piece of
> > text that I ever read) a relevant square root routine should be named
> > sqrtf128().
> > Unfortunately, nothing like that appears to be present in either math.h or 
> > in
> > library. Am I doing something wrong?
> 
> The function should be sqrtf128 (present in glibc 2.26 and later on 
> x86_64, x86, powerpc64le, ia64).  I don't know about support in non-glibc 
> C libraries.

x86-64 gcc on Godbolt does not appear to know about it.
I think, Godbolt uses rather standard Linux with quite new glibc and headers.
https://godbolt.org/z/Y4YecvxK6


> 
> > Right now, there are only two [gcc] platforms with hw binary128 - IBM POWER 
> > and
> > IBM z. I am not sure about the later, but the former has xssqrtqp 
> > instruction
> > which is likely the right way to do sqrtq()/sqrtf128() on this platform. If 
> > z
> > is the same, which sound likely, then implementation based on binary128
> > mul/add/fma by now has no use cases at all.
> 
> That may well be the case for sqrt.
> 
> > > fma is a particularly tricky case because it *is* required to be 
> > > correctly 
> > > rounding, in all rounding modes, and correct rounding implies correct 
> > > exceptions, *and* correct exceptions for fma includes getting right the 
> > > architecture-specific choice of whether tininess is detected before or 
> > > after rounding.
> > 
> > I suspect that by strict IEEE-754 rules sqrt() is the same as fma(), i.e. 
> > you
> > have to calculate a root to infinite precision and then to round with
> > accordance to current mode.
> 
> Yes, but fma has the extra complication of the architecture-specific 
> tininess detection rules (to quote IEEE 754, "The implementer shall choose 
> how tininess is detected [i.e. from the two options listed immediately 
> above this quote in IEEE 754], but shall detect tininess in the same way 
> for all operations in radix two"), which doesn't apply to sqrt because 
> sqrt results can never underflow.
> 
> (I expect the existing soft-fp version of fma in glibc to be rather better 
> optimized than the soft-fp version of sqrt.)
> 

May be. I don't know how to get soft-fp version.
What I do know is that version of fmaq() shipped with gcc/gfortran on MSYS2
x86-64 is absurdly slow - order of 4 microsecond on quite fast modern CPUs.
I don't know how you call this variant, hard, soft or may be freezing.
sqrtq() is also slow, but 3 or 5 times faster than that.

> > I don't quite or understand why you say that. First, I don't remember using 
> > any
> > double math in the variant of sqrtq() posted here. So, may be, you meant
> > division?
> > Here I use doable math, but IMO, I use it in a way that never causes
> > exceptions.
> 
> Yes, the double division.  If that division can ever be inexact when the 
> result of the square root itself is exact, you have a problem (which in 
> turn could lead to actual incorrectly rounded results from other functions 
> such as the square root operations rounding to a narrower type, when the 
> round-to-odd versions of those functions are used, because the 
> round-to-odd technique relies on correct "inexact" exceptions).

It seems, you didn't pay attention that in my later posts I am giving
implementations of binary128 *division* rather than sqrtq().

sqrtq() is in Comment 9. It's pure integer, no FP (double) math involved.

Comment 12 is pure integer implementation of binary128 division. Again, no FP
(double) math involved.

Comment 13 is again implementation of binary128 division. It does use double
math (division) internally. On modern Intel and AMD CPUs it is a little faster
than one from Comment 12, but not radically so. Both arguments and result of
double division are well-controlled, they never come close to subnormal range.

All three implementations support only one rounding mode, a default (round to
nearest with tie broken to even). They do not generate any exceptions, neither
underflow nor even overflow. In case of overflow a division silently returns
Inf with proper sign.
Support for exceptions and for non-default rounding can be added relatively
easily, but would undoubtedly cause a slowdown. I'd expect that the main
performance bottleneck would be not even an additional tests and ifs (modern
branch predictors are very good in sorting out uncommon cases), but reading of
control "register" in thread-safe manner.

BTW, I see no mentioning of 

[Bug target/105960] Crash in 32-bit mode

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
> $COMPILE -c -o crash32.o crash32.c
> $COMPILE -c -o expref.o expref.c

> $CC -m32 -o liboink32.so   -shared expref.o

You didn't use -fPIC which is required if you are compiling a shared library.

[Bug target/105960] Crash in 32-bit mode

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

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

--- Comment #1 from Andrew Pinski  ---
```
COMPILE="$CC -m32 -O2 -I. -Wall"

# Preprocessed files were created thus:
# $COMPILE -E crash32.c > crash32-preprocessed.c
# $COMPILE -E expref.c > expref-preprocessed.c

$COMPILE -c -o crash32.o crash32.c
$COMPILE -c -o expref.o expref.c

$CC -m32 -o liboink32.so   -shared expref.o

$CC -m32 -o crash32 -g crash32.o $PWD/liboink32.so -lm
```

[Bug c/105960] New: Crash in 32-bit mode

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 105960
   Summary: Crash in 32-bit mode
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 53130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53130=edit
Source files and compile script

The attached archive shows a crash when running 32-bit binaries compiled with
gcc 12.1

I am preliminarily blaming the C compiler.




0. Unpack tar file

1. Edit "compile" to point at the desired compiler

2. ./compile

3. ./crash32

Expected: immediate return
Observed: Segmentation fault (core dumped)

(gdb) where
#0  0xf7fc73d0 in *ABS*@plt () from /home/welinder/crash32/liboink32.so
#1  0x0804841d in main ()


Observations (probably more "anecdote" than "data"):

* Doesn't happen in 64-bit mode
* Doesn't happen without optimization
* The shared library appears to be a required part
* The use target_clones appears to be a required part
* This did not happen with gcc 11.1


# uname -a
Linux xx 5.3.18-150300.59.63-default #1 SMP Tue Apr 5 12:47:31 UTC 2022
(d77db66) x86_64 x86_64 x86_64 GNU/Linux


# /usr/local/products/gcc/12.1.0/bin/gcc --version
gcc (GCC) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug testsuite/105959] New: new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails

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

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

Bug ID: 105959
   Summary: new test case
c-c++-common/diagnostic-format-sarif-file-4.c from
r13-967-g6cf276ddf22066 fails
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:6cf276ddf22066af780335cd0072d2c27aabe468, r13-967-g6cf276ddf22066
make  -k check-gcc
RUNTESTFLAGS="dg.exp=c-c++-common/diagnostic-format-sarif-file-4.c"
FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -Wc++-compat  
scan-sarif-file "text": "  int \\u6587\\u5b57\\u5316\\u3051 = 
FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++98 
scan-sarif-file "text": "  int \\u6587\\u5b57\\u5316\\u3051 = 
FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++14 
scan-sarif-file "text": "  int \\u6587\\u5b57\\u5316\\u3051 = 
FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++17 
scan-sarif-file "text": "  int \\u6587\\u5b57\\u5316\\u3051 = 
FAIL: c-c++-common/diagnostic-format-sarif-file-4.c  -std=gnu++20 
scan-sarif-file "text": "  int \\u6587\\u5b57\\u5316\\u3051 = 
# of expected passes4
# of expected passes16
# of unexpected failures1
# of unexpected failures4


commit 6cf276ddf22066af780335cd0072d2c27aabe468 (HEAD, refs/bisect/bad)
Author: David Malcolm 
Date:   Thu Jun 2 15:40:22 2022 -0400

diagnostics: add SARIF output format

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to John Kanapes from comment #2)
> The missing info, gcc -v -save-temps is provided as an attachment.

But we're still missing the code that triggers the bug.

A bug report that just says something goes wrong will be closed. We need the
code to figure out what goes wrong and fix it.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

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

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

--- Comment #6 from Jonathan Wakely  ---
Line numbers in the source code aren't relevant here, you need to add the
-fsanitize=undefined flag to your link command to solve those undefined
references.

[Bug analyzer/105958] New: Stray events emitted by state machine tests (e.g. "'VAR' is NULL")

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

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

Bug ID: 105958
   Summary: Stray events emitted by state machine tests  (e.g.
"'VAR' is NULL")
   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
  Target Milestone: ---

Given:
  #include 
  int main (void)
  {
int *p = NULL;
*p = 42;

int *q = NULL;

return 0;
  }


-fanalyzer trunk emits:

: In function 'main':
:5:8: warning: dereference of NULL 'p' [CWE-476]
[-Wanalyzer-null-dereference]
5 | *p = 42;
  | ~~~^~~~
  'main': events 1-3
|
|4 | int *p = NULL;
|  |  ^
|  |  |
|  |  (1) 'p' is NULL
|5 | *p = 42;
|  | ~~~
|  ||
|  |(3) dereference of NULL 'p'
|6 | 
|7 | int *q = NULL;
|  |  ~
|  |  |
|  |  (2) 'p' is NULL
|

In the above, event (2) is redundant, and misleading; presumably it happens due
to the way sm-state-change events are implemented.

https://godbolt.org/z/76K4668dn

Tim Lange reports seeing an extra event here with gcc 12.1:
  https://gcc.gnu.org/pipermail/gcc/2022-June/238867.html
for four events in total (rather than two):

/home/tim/Projects/simple_c/main.c: In function ‘main’:
/home/tim/Projects/simple_c/main.c:12:6: warning: dereference of NULL 
‘p’ [CWE-476] [-Wanalyzer-null-dereference]
   12 |   *p = 42;
  |   ~~~^~~~
  ‘main’: events 1-4
|
|   11 |   int *p = NULL;
|  |^
|  ||
|  |(1) ‘p’ is NULL
|   12 |   *p = 42;
|  |   ~~~
|  |  |
|  |  (4) dereference of NULL ‘p’
|   13 |
|   14 |   int *q = NULL;
|  |~
|  ||
|  |(2) ‘p’ is NULL
|  |(3) ‘p’ is NULL


gcc 10.3 only has:

: In function 'main':
:5:8: warning: dereference of NULL 'p' [CWE-690]
[-Wanalyzer-null-dereference]
5 | *p = 42;
  | ~~~^~~~
  'main': events 1-2
|
|4 | int *p = NULL;
|  |  ^
|  |  |
|  |  (1) 'p' is NULL
|5 | *p = 42;
|  | ~~~
|  ||
|  |(2) dereference of NULL 'p'
|

This seems to have regressed with gcc 11.

[Bug libstdc++/105957] New: __n * sizeof(_Tp) might overflow under consteval context for std::allocator

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 105957
   Summary: __n * sizeof(_Tp) might overflow under consteval
context for std::allocator
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://github.com/gcc-mirror/gcc/blob/b3dd7d8b48227d3489039ca66b6c0ea2da743255/libstdc%2B%2B-v3/include/bits/allocator.h#L187

__n * sizeof(_Tp) can overflow under consteval context. Need checks i believe.
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));

[Bug c++/105956] [13 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-13
Summary|internal compiler error: in |[13 Regression] internal
   |iterative_hash_template_arg |compiler error: in
   |, at cp/pt.cc:1819  |iterative_hash_template_arg
   ||, at cp/pt.cc:1819
   Priority|P3  |P1

--- Comment #4 from Marek Polacek  ---
Thanks, reproduced.

[Bug c++/105956] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819

[msc at linux dot ibm.com via Gcc-bugs]

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

--- Comment #3 from Matheus Castanho  ---
Sorry, looks like the original file was too large and didn't get attached when
I created the bug. I attached a gzip compressed version now.

[Bug c++/105956] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819

[msc at linux dot ibm.com via Gcc-bugs]

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

--- Comment #2 from Matheus Castanho  ---
Created attachment 53129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53129=edit
pre-processed source generated by -freport-bug

[Bug c++/105956] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I don't actually see the pre-processed source, can you attach it?

[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

[torvalds--- via Gcc-bugs]

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

--- Comment #14 from Linus Torvalds  ---
(In reply to Samuel Neves from comment #13)
> Something simple like this -- https://godbolt.org/z/61orYdjK7 -- already
> exhibits the effect. 

Yup.

That's a much better test-case. I think you should attach it to the gcc
bugzilla, I don't know how long godbolt remembers those links.

But godbolt here is good for another thing: select clang-14 as the compiler,
and you realize how even gcc-11 is actually doing a really really bad job.

And I'm not saying that to shame anybody: I think it's more a sign that maybe
the issue is actually much deeper, and that the problem already exists in
gcc-11, but some small perturbation then just makes an already existing problem
much worse in gcc-12.

So that commit I bisected to is probably almost entirely unrelated, and it is
just the thing that turns up the bad behavior to 11.

[Bug c++/105956] New: internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819

[msc at linux dot ibm.com via Gcc-bugs]

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

Bug ID: 105956
   Summary: internal compiler error: in
iterative_hash_template_arg, at cp/pt.cc:1819
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msc at linux dot ibm.com
  Target Milestone: ---

Bumped into this error while compiling boost.fiber with upstream GCC:

$ git gcc-descr HEAD
r12-9379-g1158fe43407568

$ "/tmp/gcc-install/bin/gcc" -freport-bug  -fvisibility-inlines-hidden -fPIC
-m64 -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden 
-DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_FIBERS_DYN_LINK=1
-DBOOST_FIBERS_SOURCE -DBOOST_FILESYSTEM_DYN_LINK=1  -I"../../.."  -c -o
"../../../bin.v2/libs/fiber/build/gcc-custom/debug/threading-multi/visibility-hidden/scheduler.o"
"../../../libs/fiber/src/scheduler.cpp"
In file included from ../../../boost/intrusive/options.hpp:19,
 from ../../../boost/intrusive/list_hook.hpp:22,
 from ../../../boost/intrusive/list.hpp:20,
 from ../../../boost/fiber/scheduler.hpp:17,
 from ../../../libs/fiber/src/scheduler.cpp:7:
../../../boost/intrusive/pack_options.hpp: In instantiation of ‘struct
boost::intrusive::invert_typelist_impl,
::fibers::waker_with_hook::waker_queue_hook_>,
boost::intrusive::constant_time_size, boost::intrusive::cache_last
>, boost::intrusive::index_tuple<0, 1, 2, 3> >’:
../../../boost/intrusive/pack_options.hpp:190:71:   required from ‘struct
boost::intrusive::invert_typelist,
::fibers::waker_with_hook::waker_queue_hook_>,
boost::intrusive::constant_time_size, boost::intrusive::cache_last
> >’
../../../boost/intrusive/pack_options.hpp:230:55:   required from ‘struct
boost::intrusive::pack_options,
::fibers::waker_with_hook::waker_queue_hook_>,
boost::intrusive::constant_time_size, boost::intrusive::cache_last
>’
../../../boost/intrusive/slist.hpp:2149:15:   required from ‘struct
boost::intrusive::make_slist,
::fibers::waker_with_hook::waker_queue_hook_>,
boost::intrusive::constant_time_size, boost::intrusive::cache_last
>’
../../../boost/intrusive/slist.hpp:2173:7:   required from ‘class
boost::intrusive::slist,
::fibers::waker_with_hook::waker_queue_hook_>,
boost::intrusive::constant_time_size, boost::intrusive::cache_last
>’
../../../boost/fiber/waker.hpp:73:36:   required from here
../../../boost/intrusive/pack_options.hpp:164:29: internal compiler error: in
iterative_hash_template_arg, at cp/pt.cc:1819
  164 |static const std::size_t last_idx = sizeof_typelist::value
- 1;
  | ^~~~
0x6ec942 iterative_hash_template_arg(tree_node*, unsigned int)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:1819
0xb105c5 iterative_hash_template_arg(tree_node*, unsigned int)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:1829
0xb10fc8 hash_tmpl_and_args
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:1769
0xb10fc8 spec_hasher::hash(tree_node*, tree_node*)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:1776
0xb3389b tsubst_decl
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:14991
0xb26d87 tsubst_copy
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:17066
0xb2a720 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:21390
0xb2a2f6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:20434
0xb2bb15 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:20283
0xb35d08 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:19595
0xb4b4dc tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:13580
0xb54d8f tsubst_aggr_type
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:13796
0xb54d8f tsubst_aggr_type
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:13753
0xb49154 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:16282
0xb35497 gen_elem_of_pack_expansion_instantiation
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:12749
0xb35497 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:13417
0xb4b6e2 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:13566
0xb4b905 tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:13517
0xb4b6b4 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:13578
0xb54d8f tsubst_aggr_type
/home/mscastanho/dev/gcc/gcc/cp/pt.cc:13796
Please submit a full bug report, with preprocessed source.
Please include the 

[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

[sneves at dei dot uc.pt via Gcc-bugs]

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

--- Comment #13 from Samuel Neves  ---
Something simple like this -- https://godbolt.org/z/61orYdjK7 -- already
exhibits the effect. 

Furthermore, and this also applies to the full BLAKE2b compression function, if
you replace all the xors in the rounds by adds, the stack size goes back to
normal. 

On the other hand, replacing the adds by xors, making the whole round function
bitwise ops, does not have any effect on stack size.

[Bug target/105955] New: ICE when using __attribute__((__sysv_abi__)) on Cygwin

[mikulas at artax dot karlin.mff.cuni.cz via Gcc-bugs]

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

Bug ID: 105955
   Summary: ICE when using __attribute__((__sysv_abi__)) on Cygwin
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Target Milestone: ---

Compile this piece of code on 64-bit Cygwin distribution with gcc 11.3.0 with
or without optimizations.

The result is:
during RTL pass: pro_and_epilogue
gcc-crash.e: In function 'fn3':
gcc-crash.e:16:1: internal compiler error: in choose_baseaddr, at
config/i386/i386.c:6915
   16 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


float fabsf(float x);

void * __attribute__((__sysv_abi__)) fn1(void);

_Bool __attribute__((__sysv_abi__)) fn2(float val)
{
if (!(fabsf(val) < __builtin_huge_valf()))
return 1;
return 0;
}

_Bool fn3(void)
{
void *p = fn1();
return 1;
}

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #19 from Kees Cook  ---
(In reply to Martin Sebor from comment #18)
> The zero size case exists (and is documented) solely as a substitute for
> flexible array members.  Treating is as an ordinary array would disable that
> extension.  It might be appropriate to provide a separate option to control
> it but conflating it with the other cases (one or more elements) doesn't
> seem like the robust design.
> 
> As I mentioned in the review of the Clang change,
> https://reviews.llvm.org/D126864, so that code bases that use some larger
> number of elements than zero, such as one, and that can't easily change, can
> still benefit from the BOS enhancement for the remaining cases, it would be
> helpful for the new option to accept the minimum number of elements at which
> a trailing array ceases to be considered a poor-man's flexible array member.

I see your point about gaining the "trailing array" fix without breaking the
older code bases, but that doesn't seem to fit the name (nor purpose) of
-fstrict-flex-arrays, which should be considered a "complete" fix.

To me it looks like -fstrict-flex-arrays should kill the [0] extension, the
ancient [1] misuse, and the "anything trailing is flex" logic. If fixing _only_
the latter is desired, perhaps add an option for that, but no one is actually
asking for it yet. :) The Linux kernel wants the "fully correct" mode.

[Bug libquadmath/105101] incorrect rounding for sqrtq

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #20 from joseph at codesourcery dot com  ---
On Sat, 11 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:

> On MSYS2 _Float128 and __float128 appears to be mostly the same thing, mapped
> to the same library routines with significant difference that _Float128 is not
> accessible from C++. Since all my test benches are written in C++ I can't even
> validate that what I wrote above is 100% true.
> 
> Also according to my understanding of glibc docs (not the clearest piece of
> text that I ever read) a relevant square root routine should be named
> sqrtf128().
> Unfortunately, nothing like that appears to be present in either math.h or in
> library. Am I doing something wrong?

The function should be sqrtf128 (present in glibc 2.26 and later on 
x86_64, x86, powerpc64le, ia64).  I don't know about support in non-glibc 
C libraries.

> Right now, there are only two [gcc] platforms with hw binary128 - IBM POWER 
> and
> IBM z. I am not sure about the later, but the former has xssqrtqp instruction
> which is likely the right way to do sqrtq()/sqrtf128() on this platform. If z
> is the same, which sound likely, then implementation based on binary128
> mul/add/fma by now has no use cases at all.

That may well be the case for sqrt.

> > fma is a particularly tricky case because it *is* required to be correctly 
> > rounding, in all rounding modes, and correct rounding implies correct 
> > exceptions, *and* correct exceptions for fma includes getting right the 
> > architecture-specific choice of whether tininess is detected before or 
> > after rounding.
> 
> I suspect that by strict IEEE-754 rules sqrt() is the same as fma(), i.e. you
> have to calculate a root to infinite precision and then to round with
> accordance to current mode.

Yes, but fma has the extra complication of the architecture-specific 
tininess detection rules (to quote IEEE 754, "The implementer shall choose 
how tininess is detected [i.e. from the two options listed immediately 
above this quote in IEEE 754], but shall detect tininess in the same way 
for all operations in radix two"), which doesn't apply to sqrt because 
sqrt results can never underflow.

(I expect the existing soft-fp version of fma in glibc to be rather better 
optimized than the soft-fp version of sqrt.)

> I don't quite or understand why you say that. First, I don't remember using 
> any
> double math in the variant of sqrtq() posted here. So, may be, you meant
> division?
> Here I use doable math, but IMO, I use it in a way that never causes
> exceptions.

Yes, the double division.  If that division can ever be inexact when the 
result of the square root itself is exact, you have a problem (which in 
turn could lead to actual incorrectly rounded results from other functions 
such as the square root operations rounding to a narrower type, when the 
round-to-odd versions of those functions are used, because the 
round-to-odd technique relies on correct "inexact" exceptions).

[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

For reference :

$ cat zz1.f90
program p
   real :: a(3,2:-1)
   real :: b(3,2:0)
   print *, size(a), sizeof(a)
   print *, size(b), sizeof(b)
end

$ gfortran-13-20220612 zz1.f90 ; a.out
   00
   00

[Bug fortran/105954] New: ICE in gfc_element_size, at fortran/target-memory.cc:132

[gscfq--- via Gcc-bugs]

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

Bug ID: 105954
   Summary: ICE in gfc_element_size, at
fortran/target-memory.cc:132
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   type t
  real :: a(3,2:-1)
   end type
   type t2
  type(t) :: b(2)
   end type
   type(t2) :: c
   integer, parameter :: n = sizeof(c%b)
end


$ cat z2.f90
program p
   type t
  real :: a(3,2:0)
   end type
   type t2
  type(t) :: b(2)
   end type
   type(t2) :: c
   integer :: n = sizeof(c%b)
end


$ cat z3.f90
program p
   type t
  real :: a(3,2:-1)
   end type
   type t2
  type(t) :: b
   end type
   type(t2) :: c
   integer, parameter :: n = sizeof(c%b)
end


$ gfortran-13-20220612 -c z1.f90
f951: internal compiler error: in gfc_element_size, at
fortran/target-memory.cc:132
0x79f574 gfc_element_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.cc:132
0x79f5b3 gfc_target_expr_size(gfc_expr*, unsigned long*)
../../gcc/fortran/target-memory.cc:165
0x79340b gfc_simplify_sizeof(gfc_expr*)
../../gcc/fortran/simplify.cc:7637
0x70e392 do_simplify
../../gcc/fortran/intrinsic.cc:4663
0x7192da gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5056
0x76de18 resolve_unknown_f
../../gcc/fortran/resolve.cc:2990
0x76de18 resolve_function
../../gcc/fortran/resolve.cc:3347
0x76de18 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7187
0x6fe2b4 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.cc:3163
0x701240 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.cc:3211
0x6eb584 variable_decl
../../gcc/fortran/decl.cc:3004
0x6eb584 gfc_match_data_decl()
../../gcc/fortran/decl.cc:6299
0x756333 match_word
../../gcc/fortran/parse.cc:67
0x756333 decode_statement
../../gcc/fortran/parse.cc:378
0x757d7a next_free
../../gcc/fortran/parse.cc:1397
0x757d7a next_statement
../../gcc/fortran/parse.cc:1629
0x75930b parse_spec
../../gcc/fortran/parse.cc:4168
0x75c4ac parse_progunit
../../gcc/fortran/parse.cc:6210
0x75db71 gfc_parse_file()
../../gcc/fortran/parse.cc:6755
0x7ab8cf gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug c++/105953] New: [12/13 Regression] ICE in extract_insn, at recog.cc:2791

[gscfq--- via Gcc-bugs]

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

Bug ID: 105953
   Summary: [12/13 Regression] ICE in extract_insn, at
recog.cc:2791
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211212 and 20211219,
with file g++.target/i386/pr100738-1.C :


$ g++-13-20220612 -c pr100738-1.C -O2 -mavx512vl -mabi=ms
pr100738-1.C: In function 'v4si foo_1(v16qi, v4si, v4si, v4si)':
pr100738-1.C:13:1: error: unrecognizable insn:
   13 | }
  | ^
(insn 28 27 21 2 (set (subreg:V16QI (reg:V4SI 84 [  ]) 0)
(unspec:V16QI [
(reg:V16QI 101)
(mem/c:V16QI (reg:DI 100) [1 d+0 S16 A128])
(subreg:V16QI (lt:V4SI (mem/c:V4SI (reg:DI 98) [0 a+0 S16
A128])
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])) 0)
] UNSPEC_BLENDV)) "pr100738-1.C":12:31 -1
 (expr_list:REG_DEAD (reg:V16QI 101)
(expr_list:REG_DEAD (reg:DI 100)
(expr_list:REG_DEAD (reg:DI 98)
(nil)
during RTL pass: ira
pr100738-1.C:13:1: internal compiler error: in extract_insn, at recog.cc:2791
0x698229 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.cc:108
0x698248 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.cc:116
0xd24317 extract_insn(rtx_insn*)
../../gcc/recog.cc:2791
0xbe6c10 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
../../gcc/ira.cc:5356
0xbe78f5 remove_scratches
../../gcc/ira.cc:5400
0xbe78f5 ira
../../gcc/ira.cc:5724
0xbe78f5 execute
../../gcc/ira.cc:6083

[Bug c/105952] New: [12/13 Regression] ICE in sel_redirect_edge_and_branch, at sel-sched-ir.cc:5680

[gscfq--- via Gcc-bugs]

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

Bug ID: 105952
   Summary: [12/13 Regression] ICE in
sel_redirect_edge_and_branch, at sel-sched-ir.cc:5680
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220306 and 20220327, affects file pr27531-1.c :
(gcc configured with --enable-checking=yes)


$ gcc-13-20220612 -c pr27531-1.c -O -fno-inline -fschedule-insns
-fselective-scheduling
during RTL pass: sched1
pr27531-1.c: In function 'main':
pr27531-1.c:59:1: internal compiler error: Segmentation fault
   59 | }
  | ^
0xe13ecf crash_signal
../../gcc/toplev.cc:322
0xdbd165 sel_redirect_edge_and_branch(edge_def*, basic_block_def*)
../../gcc/sel-sched-ir.cc:5680
0xdbe0a8 maybe_tidy_empty_bb
../../gcc/sel-sched-ir.cc:3804
0xdbec65 purge_empty_blocks()
../../gcc/sel-sched-ir.cc:3948
0xdd1b4c sel_sched_region_1
../../gcc/sel-sched.cc:7519
0xdd2ff0 sel_sched_region(int)
../../gcc/sel-sched.cc:7634
0xdd3899 run_selective_scheduling()
../../gcc/sel-sched.cc:7720
0xdafa1d rest_of_handle_sched
../../gcc/sched-rgn.cc:3720
0xdafa1d execute
../../gcc/sched-rgn.cc:3830

[Bug c/105951] New: [12/13 Regression] ICE in emit_store_flag, at expmed.cc:6027

[gscfq--- via Gcc-bugs]

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

Bug ID: 105951
   Summary: [12/13 Regression] ICE in emit_store_flag, at
expmed.cc:6027
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211219 and 20220109, at -O1+,
with gcc.target/i386/pr98737-2.c and gcc.target/i386/pr98737-4.c :


$ gcc-13-20220612 -c pr98737-2.c -O2 -m32 -march=i386
during RTL pass: expand
pr98737-2.c: In function 'f1':
pr98737-2.c:20:10: internal compiler error: Segmentation fault
   20 |   return __atomic_sub_fetch (, x, __ATOMIC_RELEASE) <= 0;
  |  ^~
0xc2a33f crash_signal
../../gcc/toplev.cc:322
0x8cf362 emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode,
int, int)
../../gcc/expmed.cc:6027
0x8cffd8 emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
../../gcc/expmed.cc:6170
0x7a9946 expand_ifn_atomic_op_fetch_cmp_0(gcall*)
../../gcc/builtins.cc:6374
0x7d0557 expand_call_stmt
../../gcc/cfgexpand.cc:2737
0x7d0557 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3869
0x7d0557 expand_gimple_stmt
../../gcc/cfgexpand.cc:4033
0x7d5707 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6085
0x7d81ce execute
../../gcc/cfgexpand.cc:6811

[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

[torvalds--- via Gcc-bugs]

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

--- Comment #12 from Linus Torvalds  ---
(In reply to Jakub Jelinek from comment #11)
> Anyway, I think we need to understand what makes it spill that much more,
> and unfortunately the testcase is too large to find that out easily, I think
> we should investigate commenting out some rounds.

I think you can comment out all the rounds except for one, and still see the
effects of this.

At least when I try it on godbolt with just ROUND(0) in place and rounds 1-12
deleted, for gcc-11.3 I get a stack frame of 388.

And with gcc-12.1 I get a stack frame of 516. Obviously that's not nearly as
huge, but it's still a fairly significant expansion and is presumably due to
the same basic issue.

I used godbolt just because I no longer have 11.3 installed to compare against,
so it was the easiest way to verify that the stack expansion is still there.

Just to clarify: that's still with

   -O2 -m32 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx

I'm sure it depends on the flags.

The code is still not exactly trivial with just one round in place. It's a
cryptographic hash, after all. But when compiling for 64-bit mode it all looks
fairly straightforward, it really is that DImode stuff that makes it really
ungainly when using -m32.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com via Gcc-bugs]

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

--- Comment #5 from John Kanapes  ---
Thank you for taking the time to look at it, and responding so fast:)

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com via Gcc-bugs]

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

--- Comment #4 from John Kanapes  ---
I don't know UBSan. What's more these are not user-friendly, compiler errors.
It reminds me of assemblers:( I need readable errors with line numbers,
otherwise I don't know what to change:(

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
For UBSan, you can't just compile with -fsanitize=undefined, you need to link
with that flag as well.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com via Gcc-bugs]

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

--- Comment #2 from John Kanapes  ---
Hi,

The missing info, gcc -v -save-temps is provided as an attachment.
Of the flags, Wextra, -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations did nothing.
-fsanitize=undefined creates the following output for main:

usr/bin/ld: capture.o: in function `main.cold':
capture.c:(.text.unlikely+0x112): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.c:(.text.unlikely+0x13a): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x16b): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x19c): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x1cd): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x1f6): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.o:capture.c:(.text.unlikely+0x21f): more undefined
references to `__ubsan_handle_nonnull_arg' follow
/usr/bin/ld: capture.o: in function `main.cold':
capture.c:(.text.unlikely+0x35e): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.c:(.text.unlikely+0x381): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.c:(.text.unlikely+0x3a1): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x3c1): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x3e1): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x409): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.c:(.text.unlikely+0x42a): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.o: in function `main':
capture.c:(.text.startup+0xa2d): undefined reference to
`__ubsan_handle_pointer_overflow'
/usr/bin/ld: capture.c:(.text.startup+0x1042): undefined reference to
`__ubsan_handle_sub_overflow'
/usr/bin/ld: capture.c:(.text.startup+0x1053): undefined reference to
`__ubsan_handle_out_of_bounds'
/usr/bin/ld: capture.c:(.text.startup+0x1067): undefined reference to
`__ubsan_handle_pointer_overflow'
/usr/bin/ld: capture.c:(.text.startup+0x107e): undefined reference to
`__ubsan_handle_pointer_overflow'
/usr/bin/ld: capture.c:(.text.startup+0x1092): undefined reference to
`__ubsan_handle_type_mismatch_v1'
collect2: error: ld returned 1 exit status

[Bug rtl-optimization/104777] [9/10 Regression] gcc crashes while compiling a custom coroutine library sample

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #18 from Marek Polacek  ---
Done.

[Bug rtl-optimization/104777] [9/10 Regression] gcc crashes while compiling a custom coroutine library sample

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

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

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

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

commit r10-10828-gf2851a7cff4d74edca26d39c7bfa1264355a22ed
Author: Marek Polacek 
Date:   Mon Mar 7 16:15:46 2022 -0500

rtl: ICE with thread_local and inline asm  [PR104777]

In r270550, Jakub fixed classify_insn to handle asm goto: if the asm can
jump to a label, the insn should be a JUMP_INSN.

However, as the following testcase shows, non-null ASM_OPERANDS_LABEL_VEC
doesn't guarantee that the rtx has any actual labels it can branch to.
Here, the rtvec has 0 elements because expand_asm_stmt created it:

  rtvec labelvec = rtvec_alloc (nlabels); // nlabels == 0

This causes an ICE in update_br_prob_note: BRANCH_EDGE (bb) crashes
because there's no branch edge.  I think we can fix this by checking
that there is at least one label the asm can jump to before wrapping
the ASM_OPERANDS in a JUMP_INSN.

PR rtl-optimization/104777

gcc/ChangeLog:

* rtl.c (classify_insn): For ASM_OPERANDS, return JUMP_INSN only if
ASM_OPERANDS_LABEL_VEC has at least one element.

gcc/testsuite/ChangeLog:

* gcc.dg/torture/tls/pr104777.c: New test.

(cherry picked from commit e1133c0205a7e2a65834a1af780b8da15eead2a9)

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-13

--- Comment #1 from Jonathan Wakely  ---
Please provide the missing info requested by https://gcc.gnu.org/bugs and also
try using -fsanitize=undefined and the other flags suggested there.

[Bug target/105927] ICE: RTL check: expected code 'reg', have 'mem' in rhs_regno, at rtl.h:1932 with -mtune=k6-3 -msse

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug target/105927] ICE: RTL check: expected code 'reg', have 'mem' in rhs_regno, at rtl.h:1932 with -mtune=k6-3 -msse

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r13-1071-gb3dd7d8b48227d3489039ca66b6c0ea2da743255
Author: Uros Bizjak 
Date:   Mon Jun 13 17:08:18 2022 +0200

i386: Return true for (SUBREG (MEM)) in register_no_elim_operand
[PR105927]

Under certain conditions register_operand predicate also allows
subregs of memory operands.  When RTL checking is enabled, these
will fail with REGNO (op).

Allow subregs of memory operands, these are guaranteed
to be reloaded to a register.

2022-06-13  Uroš Bizjak  

gcc/ChangeLog:

PR target/105927
* config/i386/predicates.md (register_no_elim_operand):
Return true for subreg of a memory operand.

gcc/testsuite/ChangeLog:

PR target/105927
* gcc.target/i386/pr105927.c: New test.

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

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

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

--- Comment #18 from Martin Sebor  ---
The zero size case exists (and is documented) solely as a substitute for
flexible array members.  Treating is as an ordinary array would disable that
extension.  It might be appropriate to provide a separate option to control it
but conflating it with the other cases (one or more elements) doesn't seem like
the robust design.

As I mentioned in the review of the Clang change,
https://reviews.llvm.org/D126864, so that code bases that use some larger
number of elements than zero, such as one, and that can't easily change, can
still benefit from the BOS enhancement for the remaining cases, it would be
helpful for the new option to accept the minimum number of elements at which a
trailing array ceases to be considered a poor-man's flexible array member.

[Bug rtl-optimization/104777] [9/10 Regression] gcc crashes while compiling a custom coroutine library sample

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

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

--- Comment #16 from Marek Polacek  ---
I'll backport to 10.

[Bug c/105950] New: > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com via Gcc-bugs]

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

Bug ID: 105950
   Summary: >  O2 optimization causes runtime (SIGILL) during main
initialization
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jkanapes at yahoo dot com
  Target Milestone: ---

Created attachment 53128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53128=edit
gcc -v -save -temps

Recently upgraded to Ubuntu 20.04, and a program that compiled & ran fine in
Ubuntu 14.04, now coredumps in execution when optimization greater than -O2 is
used during compilation. No warnings in compilation.
When compiled with -O3 -g flags I get gdb output to the offending code
(SIGILL):
size_t channel = 0;
uhd_stream_args_t stream_args =
  {
 .cpu_format = "fc32",
 .otw_format = "sc16",
 .args = "",
 .channel_list = ,
 .n_channels = 1
  };
uhd_stream_atgs_t is defined in the included header:
typedef struct {
//! Format of host memory
char* cpu_format;
//! Over-the-wire format
char* otw_format;
//! Other stream args
char* args;
//! Array that lists channels
size_t* channel_list;
//! Number of channels
int n_channels;
} uhd_stream_args_t;

The offending code is the next block. This initialization code used to work
fine. It bow works fine with -O2 or less optimization. It compiles fine. Why
does gcc create the wrong executable?

Attaching the gcc -v -save-temps output

[Bug analyzer/105949] New: RFE: analyzer could warn about calls to vfuncs within a ctor/dtor

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

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

Bug ID: 105949
   Summary: RFE: analyzer could warn about calls to vfuncs within
a ctor/dtor
   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: 97110, 105887
  Target Milestone: ---

Perhaps -fanalyzer should complain about vfunc calls within a ctor/dtor (and
check interprocedurally)

clang's static analyzer has:
 
https://clang.llvm.org/docs/analyzer/checkers.html#optin-cplusplus-virtualcall-c

and various C++ guides make recommendations to avoid such calls (including
Scott Meyers', if I remember correctly)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110
[Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887
[Bug 105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could
implement

[Bug analyzer/99667] RFE: complain about uninitialized member variables in constructor

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

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

David Malcolm  changed:

   What|Removed |Added

 Blocks||105887

--- Comment #1 from David Malcolm  ---
Clang's analyzer does something like this:
https://clang.llvm.org/docs/analyzer/checkers.html#optin-cplusplus-uninitializedobject-c


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887
[Bug 105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could
implement

[Bug analyzer/105948] New: RFE: analyzer could check c++ placement-new sizes

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

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

Bug ID: 105948
   Summary: RFE: analyzer could check c++ placement-new sizes
   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: 97110, 105887
  Target Milestone: ---

clang's static analyzer has:
 
https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-placementnewchecker-c

We should check that placement new's memory region is large enough (for both
static and dynamic allocation cases).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110
[Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887
[Bug 105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could
implement

[Bug analyzer/105947] New: RFE: -fanalyzer should complain about jumps through NULL function pointers

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

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

Bug ID: 105947
   Summary: RFE: -fanalyzer should complain about jumps through
NULL function pointers
   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: 105887
  Target Milestone: ---

-fanalyzer already complains about jumps through uninitialized function
pointers:

uninit-1.c: In function ‘calling_uninit_fn_ptr_2’:
uninit-1.c:140:10: warning: use of uninitialized value ‘fn_ptr’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
  140 |   return fn_ptr ();
  |  ^
  ‘calling_uninit_fn_ptr_2’: events 1-2
|
|  139 |   int (*fn_ptr) (void);
|  | ^~
|  | |
|  | (1) region created on stack here
|  140 |   return fn_ptr ();
|  |  ~
|  |  |
|  |  (2) use of uninitialized value ‘fn_ptr’ here
|

but it fails to complain about jumps through NULL function pointers, e.g. it is
silent for:

$ cat gcc/testsuite/gcc.dg/analyzer/function-ptr-5.c

#define NULL ((void *)0)

void calling_null_fn_ptr_1 (void)
{
  void (*fn_ptr) (void) = NULL;
  fn_ptr ();
}

int calling_uninit_fn_ptr_2 (void)
{
  int (*fn_ptr) (void) = NULL;
  return fn_ptr ();
}

We should complain about jumps through known-to-be-NULL function pointers
(probably with a new warning e.g. -Wanalyzer-jump-through-null or somesuch).

Compare with:
 
https://clang.llvm.org/docs/analyzer/checkers.html#core-callandmessage-c-c-objc


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887
[Bug 105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could
implement

[Bug target/105941] --enable-fix-cortex-a53-835769 fails with -fuse-ld=lld

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

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

--- Comment #3 from Richard Earnshaw  ---
If you really wanted this to be made to work, I think you'd need to use spec
files.  Then you could provide a spec for each supported linker.  It still
wouldn't be trivial, but it seems to me it's the only way to do it unless you
build knowledge of each tool into the driver itself.

[Bug rtl-optimization/104777] [9/10 Regression] gcc crashes while compiling a custom coroutine library sample

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
9.x and 8.x are not supported anymore, nothing can be backported to those
(upstream, some vendors do support those on their own).

[Bug c++/105864] storing nullptr_t to memory should not generate any instructions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Reads from nullptr_t are replaced with just zero:
void foo (decltype(nullptr) *p) { *p = nullptr; }
decltype(nullptr) bar () { return nullptr; }
decltype(nullptr) baz (decltype(nullptr) *p) { return *p; }
so I don't see a reason why we couldn't omit the stores of nullptr_t, at least
with flag_strict_aliasing on.
Storing nullptr to another pointer type shouldn't be affected, the type of the
store then is that pointer type, not nullptr_t.  And passing nullptr to ...
isn't a store in the GENERIC or GIMPLE IL.

[Bug fortran/102003] [PDT] Length of character component not simplified

[wileamyp at outlook dot com via Gcc-bugs]

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

Wileam Yonatan Phan  changed:

   What|Removed |Added

 CC||wileamyp at outlook dot com

--- Comment #1 from Wileam Yonatan Phan  ---
Behavior confirmed with master@ff91735a5b8. The error message seems to change
if this code block is commented out in gcc/fortran/expr.cc

---

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index be94c18c836..e5a3df214d7 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3201,12 +3201,14 @@ gfc_match_init_expr (gfc_expr **result)
   return m;
 }

+  #if 0
   if (gfc_derived_parameter_expr (expr))
 {
   *result = expr;
   gfc_init_expr_flag = false;
   return m;
 }
+  #endif

   t = gfc_reduce_init_expr (expr);
   if (!t)

---

Anyway, the new error message is

pr102003.f90:6:33:

6 |   integer, parameter :: m = len (p% c)  ! rejected
  | 1
Error: Parameter ‘p’ at (1) has not been declared or is a variable, which does
not reduce to a constant expression

Maybe something doesn't work properly in gfc_reduce_init_expr()?

[Bug lto/105877] GNU strip breaks -flto -g .o files

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
(In reply to hubicka from comment #2)
> > "strip -g" removed .gnu.debuglto_.debug_info sections. Should LTO remove the
> > references of stripped debug info?  Or should "strip -g" keep LTO debug 
> > info?
> 
> I suppose we should try to immitate what happens without -flto, so
> probably check for the presence of debuglto sections and avoid producing
> debug info when they have been stripped?
> I am not sure how hard would be to implement this especially in
> situations where part of object files were stripped and others not?

I think it might be possible to detect whether the compiled objects are
stripped and then avoid streaming references to its debug sections by
magically turning it to -g0.  But not sure how awkward this will be.

Not sure why strip now strips .gnu.debuglto_.debug_info, it didn't do that
before.

[Bug c++/105864] storing nullptr_t to memory should not generate any instructions

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I don't think we can elide stores to nullptr_t typed storage unless the
frontends would replace all nullptr_t values with constant zero.

[Bug c++/105931] [12/13 regression] ICE in cxx_eval_constant_expression

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Started with r12-7564-gec0f53a3a542e7:

commit ec0f53a3a542e762f8fc8c22b9d345f922be5867
Author: Patrick Palka 
Date:   Wed Mar 9 08:42:37 2022 -0500

c++: non-constant non-dependent decltype folding [PR104823]

Valid code:

template  decltype(0 % ElemSize == 0) x;

[Bug tree-optimization/105943] [12/13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2640

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization

--- Comment #1 from Andrew Pinski  ---
-fdisable-tree-vect

I don't think this is supported this way.
Ifcvt adds LOOP_VECTORIZED as a way to version (at compile time) the converted
loop and only keep around one version of it post vectorizer.
And now you disabled the vectorizer pass.

Also the reason why it is a regression is because the vectorizer is now turned
on at -O2.
You would run into the same issue before with -O3 and then that would date to
either when the option -fdisable was added or when LOOP_VECTORIZED internal
function was added (I don't know which one was first).

[Bug c/105863] RFE: __attribute__((incbin("file"))) or __builtin_incbin("file")

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Version|unknown |13.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-13
   Severity|normal  |enhancement

--- Comment #3 from Richard Biener  ---
And it could assemble to include directives for the assembler as well (where
supported).

With toplevel asm and gas you could probably arrange things already.

[Bug c++/105946] New: [12/13 Regression] ICE in maybe_warn_pass_by_reference, at tree-ssa-uninit.cc:843

[gscfq--- via Gcc-bugs]

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

Bug ID: 105946
   Summary: [12/13 Regression] ICE in
maybe_warn_pass_by_reference, at
tree-ssa-uninit.cc:843
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210627 and 20210704,
with g++.dg/pr100253.C or g++.dg/tree-ssa/pr46228.C :


$ gcc-13-20220612 -c pr100253.C -O2 -fdisable-ipa-inline -W
cc1plus: note: disable pass ipa-inline for functions in the range of [0,
4294967295]
during GIMPLE pass: uninit
In file included from .../gcc-13-20220612/include/c++/13.0.0/vector:64,
 from pr100253.C:4:
.../gcc-13-20220612/include/c++/13.0.0/bits/stl_vector.h: In function
'std::vector<_Tp, _Alloc>::pointer std::vector<_Tp,
_Alloc>::_M_allocate_and_copy(size_type, _ForwardIterator, _ForwardIterator)
[with _ForwardIterator = __gnu_cxx::__normal_iterator*,
std::vector > >; _Tp = std::vector; _Alloc =
std::allocator >]':
.../gcc-13-20220612/include/c++/13.0.0/bits/stl_vector.h:1611:9: internal
compiler error: Segmentation fault
 1611 | _M_allocate_and_copy(size_type __n,
  | ^~~~
0xdb3fff crash_signal
../../gcc/toplev.cc:322
0xfb5cd8 maybe_warn_pass_by_reference
../../gcc/tree-ssa-uninit.cc:843
0xfb5cd8 warn_uninitialized_vars
../../gcc/tree-ssa-uninit.cc:1050
0xfb637e execute_late_warn_uninitialized
../../gcc/tree-ssa-uninit.cc:1343
0xfb637e execute
../../gcc/tree-ssa-uninit.cc:1396

[Bug c/105945] New: [12/13 Regression] ICE in maybe_gen_insn, at optabs.cc:7956

[gscfq--- via Gcc-bugs]

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

Bug ID: 105945
   Summary: [12/13 Regression] ICE in maybe_gen_insn, at
optabs.cc:7956
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211003 and 20211010, with gcc.c-torture/compile/20051216-1.c
:
(older with -Ofast)


$ gcc-13-20220612 -c 20051216-1.c -O2 -fdisable-tree-vect
cc1: note: disable pass tree-vect for functions in the range of [0, 4294967295]
$
$ gcc-13-20220612 -c 20051216-1.c -O2 -fdisable-tree-vect -mavx
cc1: note: disable pass tree-vect for functions in the range of [0, 4294967295]
during RTL pass: expand
20051216-1.c: In function 'test':
20051216-1.c:70:48: internal compiler error: in maybe_gen_insn, at
optabs.cc:7956
   70 |   vp->segs[asi].points[cursor[asi]].y == y)
  |   ~^~
0xb0c69e maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../gcc/optabs.cc:7956
0xb0bd48 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/optabs.cc:8000
0xb0bd48 expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/optabs.cc:8031
0x9bb008 expand_partial_load_optab_fn
../../gcc/internal-fn.cc:2737
0x7d0557 expand_call_stmt
../../gcc/cfgexpand.cc:2737
0x7d0557 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3869
0x7d0557 expand_gimple_stmt
../../gcc/cfgexpand.cc:4033
0x7d5707 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6085
0x7d81ce execute
../../gcc/cfgexpand.cc:6811

[Bug c/105944] New: [10/11/12/13 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.cc:2648

[gscfq--- via Gcc-bugs]

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

Bug ID: 105944
   Summary: [10/11/12/13 Regression] ICE in
expand_LOOP_DIST_ALIAS, at internal-fn.cc:2648
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8, using test case gcc.dg/tree-ssa/pr95804.c
(or gcc.dg/torture/pr104676.c and some more), at -O3 :


$ gcc-13-20220612 -c pr95804.c -O3 -fdisable-tree-vect
cc1: note: disable pass tree-vect for functions in the range of [0, 4294967295]
during RTL pass: expand
pr95804.c: In function 'g':
pr95804.c:6:6: internal compiler error: in expand_LOOP_DIST_ALIAS, at
internal-fn.cc:2648
6 | void g() {
  |  ^
0x9b7387 expand_LOOP_DIST_ALIAS
../../gcc/internal-fn.cc:2648
0x7d0557 expand_call_stmt
../../gcc/cfgexpand.cc:2737
0x7d0557 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3869
0x7d0557 expand_gimple_stmt
../../gcc/cfgexpand.cc:4033
0x7d5707 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6085
0x7d81ce execute
../../gcc/cfgexpand.cc:6811

[Bug c/105943] New: [12/13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2640

[gscfq--- via Gcc-bugs]

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

Bug ID: 105943
   Summary: [12/13 Regression] ICE in expand_LOOP_VECTORIZED, at
internal-fn.cc:2640
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211003 and 20211010, with following test case
(pr98177 and roughly 500 more from gcc/testsuite), at -O2+ :


$ cat z1.c
int a, b, c;

void foo(long e) {
  for (int f = 0; f < b; f ++)
for (int g = 0; g < c; g ++)
  a = (short)e;
}


$ gcc-13-20220612 -c z1.c -O2 -fdisable-tree-vect
cc1: note: disable pass tree-vect for functions in the range of [0, 4294967295]
during RTL pass: expand
z1.c: In function 'foo':
z1.c:3:6: internal compiler error: in expand_LOOP_VECTORIZED, at
internal-fn.cc:2640
3 | void foo(long e) {
  |  ^~~
0x9b73a7 expand_LOOP_VECTORIZED
../../gcc/internal-fn.cc:2640
0x7d0557 expand_call_stmt
../../gcc/cfgexpand.cc:2737
0x7d0557 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3869
0x7d0557 expand_gimple_stmt
../../gcc/cfgexpand.cc:4033
0x7d5707 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6085
0x7d81ce execute
../../gcc/cfgexpand.cc:6811

[Bug c++/105838] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.3.0

--- Comment #2 from Richard Biener  ---
GCC 10 is also an order of magnitude slower.

[Bug c++/105852] [11/12/13 Regression] ice in instantiate_decl

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
Fixed(?)

[Bug c++/105838] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-13

--- Comment #1 from Richard Biener  ---
Confirmed with -O1.  At -O0 I see

> /usr/bin/time /space/rguenther/install/gcc-12.1/bin/g++ -S t.C
13.44user 0.34system 0:15.71elapsed 87%CPU (0avgtext+0avgdata
1139560maxresident)k
65584inputs+23864outputs (77major+275588minor)pagefaults 0swaps

with -O1 it uses >20GB of memory in cleanup_all_empty_eh.  It might be
the order of optimizing this is exposing some quadratic amount of
edge redirection, I have not yet analyzed this in detail but trimming down
the testcase should help here.  There isn't much allocation done here
besides the edge redirection SSA update stuff for PHIs.

[Bug tree-optimization/105835] [13 Regression] Dead Code Elimination Regression at -O1 (trunk vs. 12.1.0)

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O1 (trunk|Elimination Regression at
   |vs. 12.1.0) |-O1 (trunk vs. 12.1.0)
   Target Milestone|--- |13.0

[Bug tree-optimization/105834] [13 Regression] Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O2 (trunk|Elimination Regression at
   |vs. 12.1.0) |-O2 (trunk vs. 12.1.0)
   Keywords||missed-optimization
   Target Milestone|--- |13.0

[Bug tree-optimization/105833] [13 Regression] Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O2 (trunk|Elimination Regression at
   |vs. 12.1.0) |-O2 (trunk vs. 12.1.0)
   Target Milestone|--- |13.0

[Bug target/105941] --enable-fix-cortex-a53-835769 fails with -fuse-ld=lld

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That is the usual design flaw of the -fuse-ld= option, we detect various linker
capabilities at gcc configure time and rely on them being present, whether in
what we emit or how we invoke the linker.
And if the alternate linkers don't support what we've detected, we are out of
luck.

[Bug tree-optimization/105832] [13 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Dead Code Elimination   |[13 Regression] Dead Code
   |Regression at -O3 (trunk|Elimination Regression at
   |vs. 12.1.0) |-O3 (trunk vs. 12.1.0)
   Last reconfirmed||2022-06-13
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |13.0
   Keywords||missed-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  GCC 12:

t.c:12:23: optimized: Unswitching loop on condition: if (iftmp.0_9 <= 1)

t.c:12:23: optimized: Unswitching loop on condition: if (iftmp.0_9 == 1)

t.c:12:23: optimized: Unswitching loop on condition: if (iftmp.1_10 != 0)

t.c:12:23: optimized: Unswitching loop on condition: if (iftmp.1_10 != 0)

and trunk:

t.c:12:23: optimized: unswitching loop 1 on ‘if’ with condition: iftmp.0_9 <= 1
t.c:12:23: optimized: unswitching loop 1 on ‘if’ with condition: iftmp.1_10 !=
0
t.c:12:23: optimized: unswitching loop 1 on ‘if’ with condition: iftmp.0_9 == 1

somehow trunk doesn't consider the 2nd iftmp.1_10 != 0 condition.

[Bug tree-optimization/86339] DOM does not handle RHS COND_EXPRs well

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Probably fixed, doesn't have a testcase and DOM should be retired.

[Bug rtl-optimization/54525] Recognize (vec_)cond_expr in mask operation

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2016-01-04 00:00:00 |2022-6-13
  Component|tree-optimization   |rtl-optimization

--- Comment #3 from Richard Biener  ---
Re-confirmed for 'f', the vector case now is recognized with the help of some
match.pd patterns.  Since we generally perform if-conversion for scalar code on
RTL this is rtl-optimization now.

[Bug rtl-optimization/104777] [9/10 Regression] gcc crashes while compiling a custom coroutine library sample

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #14 from Stas Sergeev  ---
(In reply to Uroš Bizjak from comment #13)
> Please backport the patch also to gcc-10 branch.

9.4.0 fails for me on ubuntu-20.
8.5.0 also fails.
Please back-port to all possible
branches.

[Bug d/105942] New: [12 Regression] d: internal compiler error: in visit, at d/expr.cc:945

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 105942
   Summary: [12 Regression] d: internal compiler error: in visit,
at d/expr.cc:945
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

---
void ice()
{   
struct hasDtor
{
int i;
~this() { }
}
hasDtor[4] arr = hasDtor(4);
}
---

0x9baaa0 ExprVisitor::visit(AssignExp*)
../../src/gcc/d/expr.cc:945
0x9b6a23 build_expr(Expression*, bool, bool)
../../src/gcc/d/expr.cc:3040
0x9b65e8 DeclVisitor::visit(VarDeclaration*)
../../src/gcc/d/decl.cc:735
0x9b06ba DeclVisitor::build_dsymbol(Dsymbol*)
../../src/gcc/d/decl.cc:146
0x9b06ba build_decl_tree(Dsymbol*)
../../src/gcc/d/decl.cc:1010
0x9b6ddd ExprVisitor::visit(DeclarationExp*)
../../src/gcc/d/expr.cc:2008
0x9b6a23 build_expr(Expression*, bool, bool)
../../src/gcc/d/expr.cc:3040
0x9b6abf build_expr_dtor(Expression*)
../../src/gcc/d/expr.cc:3063
0x9c31e5 IRVisitor::visit(ExpStatement*)
../../src/gcc/d/toir.cc:1052
0x9c3157 IRVisitor::build_stmt(Statement*)
../../src/gcc/d/toir.cc:274
0x9c3157 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1069
0x9c3157 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1059
0x9c3157 IRVisitor::build_stmt(Statement*)
../../src/gcc/d/toir.cc:274
0x9c3157 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1069
0x9c3157 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1059
0x9c2842 IRVisitor::build_stmt(Statement*)
../../src/gcc/d/toir.cc:274
0x9c2842 build_function_body(FuncDeclaration*)
../../src/gcc/d/toir.cc:1481
0x9b5b72 DeclVisitor::visit(FuncDeclaration*)
../../src/gcc/d/decl.cc:969
0x9b06ba DeclVisitor::build_dsymbol(Dsymbol*)
../../src/gcc/d/decl.cc:146
0x9b06ba build_decl_tree(Dsymbol*)
../../src/gcc/d/decl.cc:1010

[Bug rtl-optimization/104777] [9/10 Regression] gcc crashes while compiling a custom coroutine library sample

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #13 from Uroš Bizjak  ---
Please backport the patch also to gcc-10 branch.

[Bug libstdc++/105934] [9/10/11/12/13 Regression] C++11 pointer versions of atomic_fetch_add missing because of P0558

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||8.5.0
  Known to fail||10.3.0, 11.2.0, 12.0, 9.1.0

--- Comment #4 from Jonathan Wakely  ---
I've raised this for discussion with LWG.

FWIW libc++ and MSVC reject the example too. It looks like everybody treats
P0558 as a DR.

It's valid as C++11 and C++17, with old and new implementations, if changed to
use std::atomic_fetch_add(static_cast*>(*ap), 1); }
i.e. using an explicit conversion instead of an explicit template argument
list.

[Bug target/105941] --enable-fix-cortex-a53-835769 fails with -fuse-ld=lld

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

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

--- Comment #1 from Richard Earnshaw  ---
The correct thing to do would be to implement the option in lld.  If lld claims
to be a replacement for ld, then it really should support all the command-line
options that ld supports.

[Bug rtl-optimization/105936] [10 Regression] ICE with inline-asm and TLS on x86_64 and -O2 in move_insn

[stsp at users dot sourceforge.net via Gcc-bugs]

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

Stas Sergeev  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #6 from Stas Sergeev  ---
But no patch is back-ported,
and already closing the ticket?

[Bug libstdc++/105934] [9/10/11/12/13 Regression] C++11 pointer versions of atomic_fetch_add missing because of P0558

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

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

--- Comment #3 from Jonathan Wakely  ---
Created attachment 53127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53127=edit
Restore atomic_fetch_{add,sub} partial specializations for pointers

This patch restores the partial specializations for pointers for C++11 and
C++14 modes. It also changes the atomic::value_type parameters to use
type_identity_t instead, which avoids the problematic instantiation of
atomic>. This fixes both issues described above.

[Bug rtl-optimization/104777] [9/10 Regression] gcc crashes while compiling a custom coroutine library sample

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||stsp at users dot 
sourceforge.net

--- Comment #12 from Uroš Bizjak  ---
*** Bug 105936 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/105936] [10 Regression] ICE with inline-asm and TLS on x86_64 and -O2 in move_insn

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Dup of PR104777, the patch from the PR should be backported to gcc-10.

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

[Bug libstdc++/105934] [9/10/11/12/13 Regression] C++11 pointer versions of atomic_fetch_add missing because of P0558

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

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

--- Comment #2 from Jonathan Wakely  ---
Somewhat related:

The MSVC testsuite has an example using atomic_store that fails with
libstdc++:

https://github.com/microsoft/STL/blob/main/tests/std/tests/Dev11_1066589_shared_ptr_atomic_deadlock/test.cpp

atomic_store(shared_ptr, shared_ptr) gives an error
outside the immediate context, because the typename atomic::value_type
parameter causes instantiation of atomic> which is ill-formed.

I think MSVC has some workaround for this, which deviates from what P0558 did.

[Bug libstdc++/105934] [9/10/11/12/13 Regression] C++11 pointer versions of atomic_fetch_add missing because of P0558

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

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

--- Comment #1 from Jonathan Wakely  ---
I think this is actually expected post-P0558, and I would prefer to treat that
paper as a DR, because the original spec for the atomic_xxx free functions was
weird and inconsistent. The partial specializations for pointer types are
explicitly called out in P0558 as being broken (by allowing arithmetic on types
like atomic and atomic).

Those free functions exist to allow writing code that is valid in both C and
C++, so I don't see much motivation for supporting C++-specific syntax like
explicit template arguments.

[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
Confirmed it is r12-7502-g8ea4a34bd0b0a462 on our bisect seed.
Perhaps for !TARGET_STV || !TARGET_SSE2 we could keep the optabs, but split
right away during expansion?
Anyway, I think we need to understand what makes it spill that much more, and
unfortunately the testcase is too large to find that out easily, I think we
should investigate commenting out some rounds.

[Bug rtl-optimization/105936] [10 Regression] ICE with inline-asm and TLS on x86_64 and -O2 in move_insn

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Uroš Bizjak  ---
Digging a bit further with current gcc-10 branch...

Instrumenting a TLS address splitter in i386.md with some creative printfs:

(define_split
  [(match_operand 0 "tls_address_pattern")]
  "TARGET_TLS_DIRECT_SEG_REFS"
  [(match_dup 0)]
{
  debug_rtx (curr_insn);
  debug_rtx (operands[0]);
  printf ("%s\n", GET_RTX_NAME (classify_insn (operands[0])));
  operands[0] = ix86_rewrite_tls_address (operands[0]);
  debug_rtx (operands[0]);
  printf ("%s\n", GET_RTX_NAME (classify_insn (operands[0])));
})

we get:

(insn 54 51 109 9 (parallel [
(asm_operands/v ("btrl %1,%0") ("") 0 [
(mem/c:BLK (plus:DI (plus:DI (unspec:DI [
(const_int 0 [0])
] UNSPEC_TP)
(reg:DI 100))
(const_int 96 [0x60])) [21 MEM[(struct
revectored_struct *) + 96B]+0 S32 A32])
(reg:SI 101)
]
 [
(asm_input:BLK ("m") ../../../src/include/cpu.h:355)
(asm_input:SI ("r") ../../../src/include/cpu.h:355)
]
 [] ../../../src/include/cpu.h:355)
(clobber (reg:CC 17 flags))
]) "../../../src/include/cpu.h":355:2 -1
 (expr_list:REG_DEAD (reg:SI 101)
(expr_list:REG_DEAD (reg:DI 100)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(parallel [
(asm_operands/v ("btrl %1,%0") ("") 0 [
(mem/c:BLK (plus:DI (plus:DI (unspec:DI [
(const_int 0 [0])
] UNSPEC_TP)
(reg:DI 100))
(const_int 96 [0x60])) [21 MEM[(struct
revectored_struct *) + 96B]+0 S32 A32])
(reg:SI 101)
]
 [
(asm_input:BLK ("m") ../../../src/include/cpu.h:355)
(asm_input:SI ("r") ../../../src/include/cpu.h:355)
]
 [] ../../../src/include/cpu.h:355)
(clobber (reg:CC 17 flags))
])
jump_insn
(parallel [
(asm_operands/v ("btrl %1,%0") ("") 0 [
(mem/c:BLK (plus:DI (reg:DI 100)
(const_int 96 [0x60])) [21 MEM[(struct
revectored_struct *) + 96B]+0 S32 A32 AS1])
(reg:SI 101)
]
 [
(asm_input:BLK ("m") ../../../src/include/cpu.h:355)
(asm_input:SI ("r") ../../../src/include/cpu.h:355)
]
 [] ../../../src/include/cpu.h:355)
(clobber (reg:CC 17 flags))
])
jump_insn

Please note that classify_insn declares the pattern as JUMP_INSN due to:

  if (GET_CODE (x) == ASM_OPERANDS && ASM_OPERANDS_LABEL_VEC (x))
return JUMP_INSN;

but no label is defined in asm operands.

[Bug target/105911] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (error: unrecognizable insn)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.