[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

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

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

--- Comment #4 from Tamar Christina  ---
Yes a lane check size is missing from fms, will be fixed in a bit.

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

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

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

Tamar Christina  changed:

   What|Removed |Added

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

[Bug middle-end/102948] [12 Regression] 60% build time regression on gamess in range g:31855ba6b16cd138d7484076a08cd40d609654b8

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-01
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
> OK, so user time regressed more so the LNT numbers are wall-clock?

Yes, I use normal stopwatch in Python.

@Richi: Are you done with the bisection, right?

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

[hboetes at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Han Boetes  ---
Yay, problem solved. :-)
Thanks everyone!

[Bug other/102657] libcody makefile is missing a mostlyclean target

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug target/103017] New: Fix redundant check in aut insn generation

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

Bug ID: 103017
   Summary: Fix redundant check in aut insn generation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ashimida at linux dot alibaba.com
  Target Milestone: ---

During the generation of the epilogue of aarch64(aarch64_expand_epilogue),
the value of crtl->calls_eh_return does not need to be checked again.

This value has been checked during aarch64_return_address_signing_enabled.

[Bug c++/103018] New: ICE: in pop_local_binding, at cp/name-lookup.c:2496

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 103018
   Summary: ICE: in pop_local_binding, at cp/name-lookup.c:2496
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Hi.

template
concept C = requires (T t, void (&f)(auto)) 
{ true; };

https://godbolt.org/z/f4bf7nohd

[Bug target/103017] Fix redundant check in aut insn generation

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

--- Comment #1 from ashimida  ---
Submitted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/582997.html

[Bug target/103008] poor inlined builtin_fmod on x86_64

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
IMO, inlined fmod (and drem) should eventually be expanded in a generic way in
the middle-end as:

fmod (a, p) = a - trunc (a/p) * p
drem (a, p) = a - roundeven (a/p) * p

so division can be later simplified to multiplication with reciprocal, either
constant or implemented with rcp instruction.

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Gabriel Ravier  ---
(In reply to Hans-Peter Nilsson from comment #3)
> (In reply to Gabriel Ravier from comment #0)
> ...
> > #define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3
> > #define PTR5 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4
> > #define PTR6 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5
> > 
> > int PTR4 q3_var = 0;
> ...
> 
> Is the use of PTR4 instead of PTR6 or PTR5, intended to provoke comments
> such as this one, or are there untold additional related observations?

It's just a leftover I forgot to remove from when I was first testing this
(with the bigger macros, which just had worse results).

[Bug c++/103019] New: ICE on invalid code with template non-type arugment

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

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

Bug ID: 103019
   Summary: ICE on invalid code with template non-type arugment
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

While reducing PR 102990, I accidently reduced such that I got invalid code
with an ICE without an error message.
Reduced testcase all the way:
struct range_t {  double init;  };
template struct knob_t {
  int value = setup.init;
};
struct Helpers
{
  knob_t inputs;
};
template   auto detect_fields_count_dispatch() noexcept ->
decltype(sizeof(T{}));
int t = detect_fields_count_dispatch();


--- CUT 
If you fix the code such that detect_fields_count_dispatch has the correct
template arguments (either removing N from the definition or adding ", 1" to
the usage), the ICE goes away.  Also note if you change the type of value to be
a similar type (that is both are integer types or both real types), the ICE
goes away.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #12 from Jürgen Reuter  ---
I'm not an expert on the I/O system, but could it be that the unit to which the
stdout of a compiled Fortran program goes does not provide the unit that the
redirect function (now) expects under macOS 12?

[Bug target/103020] New: ICE with V1TImode on x86_32

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 103020
   Summary: ICE with V1TImode on x86_32
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
typedef int __v1ti __attribute__((mode (V1TI)));

__v1ti foo (__v1ti a)
{
  return a + a;
}
--cut here--

ICEs with gcc -O2 -msse2 -m32:

v1ti.c:1:1: warning: specifying vector types with ‘__attribute__ ((mode))’ is
deprecated [-Wattributes]
1 | typedef int __v1ti __attribute__((mode (V1TI)));
  | ^~~
v1ti.c:1:1: note: use ‘__attribute__ ((vector_size))’ instead
during RTL pass: expand
v1ti.c: In function ‘foo’:
v1ti.c:5:12: internal compiler error: in expand_shift_1, at expmed.c:2668
5 |   return a + a;
  |  ~~^~~
0x66ec09 expand_shift_1
/home/uros/git/gcc/gcc/expmed.c:2668
0xa948f5 expand_shift(tree_code, machine_mode, rtx_def*, poly_int<1u, long>,
rtx_def*, int)
/home/uros/git/gcc/gcc/expmed.c:2683
0xa948f5 expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
/home/uros/git/gcc/gcc/expmed.c:3522
0xaada10 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/uros/git/gcc/gcc/expr.c:10500
...

Similar testcase:

--cut here--
typedef int __v1ti __attribute__((mode (V1TI)));

__v1ti foo (__v1ti a)
{
  return a;
}
--cut here--

does not finish compilation.

When using TI and V2TI mode, the expected error is produced:

_.c:1:1: error: unable to emulate ‘TI’

or

_.c:1:1: error: unable to emulate ‘V2TI’

[Bug c++/103019] ICE on invalid code with template non-type arugment

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

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

--- Comment #1 from Andrew Pinski  ---
Here is one slightly more reduced, removing range_t struct even:
template struct knob_t {
  int value = setup;
};
struct Helpers
{
  knob_t<1.0> inputs;
};
template   auto h() noexcept -> decltype(sizeof(T{}));
int t = h();

 CUT

[Bug c++/102990] ICE in tsubst_copy_and_build with coroutines and concepts

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-01

--- Comment #3 from Andrew Pinski  ---
Reduced testcase:
template  struct f{};

template struct knob_t {
  int value = setup;
};
struct Helpers
{
  knob_t<1.0> inputs;
};
template   auto h(f a) noexcept -> decltype(sizeof(T{}));
int t = h(f<1>{});

[Bug c++/103019] ICE on invalid code with template non-type arugment

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Actually this is a dup of bug 102990, the template argument is detected after
the return value is detected.

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

[Bug c++/102990] ICE in tsubst_copy_and_build with coroutines and concepts

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

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

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

[Bug c++/102990] ICE in tsubst_copy_and_build with coroutines and concepts

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #5 from Andrew Pinski  ---
Note you can also invoke this on invalid code too:
template struct knob_t {
  int value = setup;
};
struct Helpers
{
  knob_t<1.0> inputs;
};
template   auto h() noexcept -> decltype(sizeof(T{}));
int t = h();

[Bug c++/103018] ICE: in pop_local_binding, at cp/name-lookup.c:2496

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/101898] [concepts] ICE with auto in concept definition

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

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

[Bug c++/103012] ICE with #pragma GCC optimize followed by long line

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-01
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
I'm reducing that right now.

[Bug target/103020] ICE with V1TImode on x86_32

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I guess that is a consequence of ix86_scalar_mode_supported_p returning false
for TImode (it uses default_scalar_mode_supported_p for it and that supports at
most 2 * BITS_PER_WORD precision modes), while ix86_vector_mode_supported_p
returns true for V1TImode (but not V2TImode etc.).
I think it has been introduced by PR32280 fix.
Seems the backend wants to use V1TImode shifts by constant for
__builtin_ia32_pslldqi128 etc.  The question is, will that keep working if we
keep V1TImode in VALID_SSE_REG_MODE etc., but add to start of
ix86_vector_mode_supported_p something like
  if (!TARGET_64BIT && GET_MODE_INNER (mode) == TImode)
return false;

[Bug c++/103012] ICE with #pragma GCC optimize followed by long line

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

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

--- Comment #4 from Martin Liška  ---
I've reduced that to:

#pragma GCC optimize"Og"
  template inline void template void
__valarray_copy_construct0 template inline void __valarray_fill
0 template inline void __valarray_fill0
template inline void templatetypename _Tp> inline
__valarray_copy0  typename > inline void __valarray_copy0  
   templatetypename _Tp> inline void templatetypename _Tp> inline
__valarray_copy0  typename > inline void __valarray_copy0  
   templatetypename _Tp> inline void templatetypename _Tp> inline
__valarray_copy0 template inline _Tp>::_Array0 : _M_data 0 
   template inline _Array<_Tp>::_Array0 : _M_data 0  
  template inline _Array<_Tp>::_Array0 : _M_data0
template inline _Tp* _Array<_Tp>::begin 0 const  
  template inline void template inline void
_Array_augmented___plus0  template void _Array_augmented___plus0  template
inline void _Array_augmented___plus0  template inline void
_Array_augmented___plus0  template void _Array_augmented___plus0  template
inline void _Array_augmented___plus0  _Tp void template void
_Array_augmented___plus0  templatetypename _Tpvoid _Array_augmented___plus0 
typename _Tp> _Array_augmented___plus0  templatetypename _Tp, _Dom> void
typename inline void template<_Tpinline template<_Tpclass > void
templatetypename _Tpinline void _Array_augmented___minus0  typename inline void
template _Array_augmented___minus  typename _Tp>
_Array_augmented___minus  template inline void
_Array_augmented___minus  template void
_Array_augmented___minus  template void _Array_augmented___minus 
template void _Array_augmented___minus  template void _Array_augmented___minus template inline
void template<_Tpinline _Array_augmented___multiplies  templatetypename _Tp,
_Dom> void template<_Tpinline template<_Tpinline _Array_augmented___multiplies 
templatetypename _Tp, _Dom> void template<_Tpinline
_Array_augmented___multiplies  templatetypename _Tp> inline templatetypename
_Tpclass _Dom> void _Array_augmented___multiplies0  typename void
_Array_augmented___multiplies0  template void
_Array_augmented___multiplies0  template void
_Array_augmented___multiplies0 template inline void
_Array_augmented___divides0  template inline void
_Array_augmented___divides0  template void
_Array_augmented___divides0  template inline void
_Array_augmented___divides0  template inline void
_Array_augmented___divides0  template void
_Array_augmented___divides0  template inline void
_Array_augmented___divides0  template inline void
_Array_augmented___divides0  template void
_Array_augmented___divides()  template void
_Array_augmented___divides()  template void
_Array_augmented___divides0  template void _Array_augmented___divides0
template inline void _Array_augmented___modulus0  template inline void
_Array_augmented___modulus0  template void _Array_augmented___modulus0 
template inline void _Array_augmented___modulus0  template inline void
_Array_augmented___modulus0  template void _Array_augmented___modulus0 
template inline void _Array_augmented___modulus0  template inline void
_Array_augmented___modulus0  template void _Array_augmented___modulus0 
template void _Array_augmented___modulus0  template void
_Array_augmented___modulus0  template void _Array_augmented___modulus0
template inline void _Array_augmented___bitwise_xor0  template void inline
inline inline _Array_augmented___bitwise_xor0  template void
_Array_augmented___bitwise_xor0  template void _Array_augmented___bitwise_xor0 
template void _Array_augmented___bitwise_xor0  template void

[Bug target/103020] ICE with V1TImode on x86_32

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

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

--- Comment #2 from Jakub Jelinek  ---
That target hook is used mostly before expansion or during expansion:
gcc/gcc/expmed.c:   && targetm.vector_mode_supported_p (new_mode))
gcc/gcc/stor-layout.c:&& targetm.vector_mode_supported_p (trial))
gcc/gcc/targhooks.c:  && targetm.vector_mode_supported_p (result_mode))
gcc/gcc/tree.c:  && (!targetm.vector_mode_supported_p (mode)
gcc/gcc/c-family/c-attribs.c:  if (targetm.vector_mode_supported_p (mode))
gcc/gcc/d/d-target.cc:  if (!targetm.vector_mode_supported_p (TYPE_MODE
(ctype)))
so maybe using the mode in the backend only will be fine.

[Bug middle-end/102970] [11/12 Regression] stable_sort uninitialized value with -funroll-loops -fno-tree-vectorize since r11-2963-gd6a05b494b4b714e

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|[11/12 Regression]  |[11/12 Regression]
   |stable_sort uninitialized   |stable_sort uninitialized
   |value with -funroll-loops   |value with -funroll-loops
   |-fno-tree-vectorize |-fno-tree-vectorize since
   ||r11-2963-gd6a05b494b4b714e
   Keywords|needs-bisection |

--- Comment #3 from Martin Liška  ---
Started with r11-2963-gd6a05b494b4b714e.

[Bug target/102974] GCC optimization is very poor for add carry and multiplication combos

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #10 from Martin Liška  ---
(In reply to cqwrteur from comment #9)
> (In reply to Richard Biener from comment #8)
> > As mentioned in the other bug STV might make things only worse.
> 
> what is stv?

$ gcc --help=target | grep mstv
  -mstv   Disable Scalar to Vector optimization pass
transforming 64-bit integer computations into a vector ones.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Z

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
@Honza: Please do not paste all the revision changes in the bugzilla comment.
One  can easily investigate that from git revision range.

[Bug target/103020] ICE with V1TImode on x86_32

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 51715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51715&action=edit
gcc12-pr103020.patch

Full untested patch.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast between ce4d1f632ff3f680550d3b186b60176022f41190 and 6fca1761a16c68740f875fc487b98b6bde8e9be7 on Z

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
(In reply to Richard Biener from comment #2)
> Btw, IIRC calculix train data and ref data do not match up wrt the hottest
> loops, so not sure whether any regression here is considered important. 
> Maybe the profile is now preserved better.
> 
> I can't reproduce any slowdown w/o PGO.

Yes, it's PR87166.

[Bug libstdc++/103005] experimental simd sin and cos with big arguments returns values bigger than 1

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-01
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug other/103021] New: Make the path to etags used in the build system configurable

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

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

Bug ID: 103021
   Summary: Make the path to etags used in the build system
configurable
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: other
  Assignee: egallager at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

While doing g:4ca446a I had some trouble getting the Makefiles to find my etags
properly; it would have been easier if the paths to it were configurable
instead of being hardcoded into the Makefiles as just 'etags'. This is
something I intend to handle myself, so I'm self-assigning.

[Bug other/103021] Make the path to etags used in the build system configurable

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

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

Eric Gallager  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-01
 Status|UNCONFIRMED |ASSIGNED

[Bug other/103021] Make the path to etags used in the build system configurable

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

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

Eric Gallager  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libstdc++/103022] New: std::begin on empty std::valarray causes _GLIBCXX_DEBUG assertion

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 103022
   Summary: std::begin on empty std::valarray causes
_GLIBCXX_DEBUG assertion
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with GCC 11.2.1:

> $ cat test.cc
> #include 
> int main() {
> std::valarray v;
> std::begin(v);
> }

> $ g++ -D_GLIBCXX_DEBUG test.cc
> $ ./a.out
> /usr/include/c++/11/valarray:594: _Tp& 
> std::valarray<_Tp>::operator[](std::size_t) [with _Tp = double; std::size_t = 
> long unsigned int]: Assertion '__i < this->size()' failed.
> Aborted

because the std::begin overload is implemented via

  return std::__addressof(__va[0]);

ever since

"[multiple changes]" and the std::valarray subscript operator calls

  __glibcxx_requires_subscript(__i);

ever since

"[multiple changes]".

(See

"crashtesting: assert on conversion of fdo67521-1.odg to pdf" for an issue this
caused in LibreOffice.)

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

[juergen.reuter at desy dot de via Gcc-bugs]

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

Jürgen Reuter  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

--- Comment #5 from Jürgen Reuter  ---
I can confirm this ICE also with (legacy) Fortran code, cf. below.
The full code is attached. 

C***

C...PYQQBH
C...Calculates the matrix element for the processes
C...g + g or q + qbar -> Q + Qbar + H (normally with Q = t).
C...REDUCE output and part of the rest courtesy Z. Kunszt, see
C...Z. Kunszt, Nucl. Phys. B247 (1984) 339.

  SUBROUTINE PYQQBH(WTQQBH)

C...Double precision and integer declarations.
  IMPLICIT DOUBLE PRECISION(A-H, O-Z)
  IMPLICIT INTEGER(I-N)
  INTEGER PYK,PYCHGE,PYCOMP
C...Commonblocks.
  COMMON/PYDAT1/MSTU(200),PARU(200),MSTJ(200),PARJ(200)
  COMMON/PYDAT2/KCHG(500,4),PMAS(500,4),PARF(2000),VCKM(4,4)
  COMMON/PYPARS/MSTP(200),PARP(200),MSTI(200),PARI(200)
  COMMON/PYINT1/MINT(400),VINT(400)
  COMMON/PYINT2/ISET(500),KFPR(500,2),COEF(500,20),ICOL(40,4,2)
  SAVE /PYDAT1/,/PYDAT2/,/PYPARS/,/PYINT1/,/PYINT2/
C...Local arrays and function.
  DIMENSION PP(15,4),CLR(8,8),FM(10,10),RM(8,8),DX(8)
  DOT(I,J)=PP(I,4)*PP(J,4)-PP(I,1)*PP(J,1)-PP(I,2)*PP(J,2)-
 &PP(I,3)*PP(J,3)

C...Mass parameters.
  WTQQBH=0D0
  ISUB=MINT(1)
  SHPR=SQRT(VINT(26))*VINT(1)
  PQ=PMAS(PYCOMP(KFPR(ISUB,2)),1)
  PH=SQRT(VINT(21))*VINT(1)
  SPQ=PQ**2
  SPH=PH**2

C...Set up outgoing kinematics: 1=t, 2=tbar, 3=H.
  DO 100 I=1,2
PT=SQRT(MAX(0D0,VINT(197+5*I)))
PP(I,1)=PT*COS(VINT(198+5*I))
PP(I,2)=PT*SIN(VINT(198+5*I))
  100 CONTINUE
  PP(3,1)=-PP(1,1)-PP(2,1)
  PP(3,2)=-PP(1,2)-PP(2,2)
  PMS1=SPQ+PP(1,1)**2+PP(1,2)**2
  PMS2=SPQ+PP(2,1)**2+PP(2,2)**2
  PMS3=SPH+PP(3,1)**2+PP(3,2)**2
  PMT3=SQRT(PMS3)
  PP(3,3)=PMT3*SINH(VINT(211))
  PP(3,4)=PMT3*COSH(VINT(211))
  PMS12=(SHPR-PP(3,4))**2-PP(3,3)**2
  PP(1,3)=(-PP(3,3)*(PMS12+PMS1-PMS2)+
 &VINT(213)*(SHPR-PP(3,4))*VINT(220))/(2D0*PMS12)
  PP(2,3)=-PP(1,3)-PP(3,3)
  PP(1,4)=SQRT(PMS1+PP(1,3)**2)
  PP(2,4)=SQRT(PMS2+PP(2,3)**2)

C...Set up incoming kinematics and derived momentum combinations.
  DO 110 I=4,5
PP(I,1)=0D0
PP(I,2)=0D0
PP(I,3)=-0.5D0*SHPR*(-1)**I
PP(I,4)=-0.5D0*SHPR
  110 CONTINUE
  DO 120 J=1,4
PP(6,J)=PP(1,J)+PP(2,J)
PP(7,J)=PP(1,J)+PP(3,J)
PP(8,J)=PP(1,J)+PP(4,J)
PP(9,J)=PP(1,J)+PP(5,J)
PP(10,J)=-PP(2,J)-PP(3,J)
PP(11,J)=-PP(2,J)-PP(4,J)
PP(12,J)=-PP(2,J)-PP(5,J)
PP(13,J)=-PP(4,J)-PP(5,J)
  120 CONTINUE

C...Derived kinematics invariants.
  X1=DOT(1,2)
  X2=DOT(1,3)
  X3=DOT(1,4)
  X4=DOT(1,5)
  X5=DOT(2,3)
  X6=DOT(2,4)
  X7=DOT(2,5)
  X8=DOT(3,4)
  X9=DOT(3,5)
  X10=DOT(4,5)

C...Propagators.
  SS1=DOT(7,7)-SPQ
  SS2=DOT(8,8)-SPQ
  SS3=DOT(9,9)-SPQ
  SS4=DOT(10,10)-SPQ
  SS5=DOT(11,11)-SPQ
  SS6=DOT(12,12)-SPQ
  SS7=DOT(13,13)
  DX(1)=SS1*SS6
  DX(2)=SS2*SS6
  DX(3)=SS2*SS4
  DX(4)=SS1*SS5
  DX(5)=SS3*SS5
  DX(6)=SS3*SS4
  DX(7)=SS7*SS1
  DX(8)=SS7*SS4

C...Define colour coefficients for g + g -> Q + Qbar + H.
  IF(ISUB.EQ.121.OR.ISUB.EQ.181.OR.ISUB.EQ.186) THEN
DO 140 I=1,3
  DO 130 J=1,3
CLR(I,J)=16D0/3D0
CLR(I+3,J+3)=16D0/3D0
CLR(I,J+3)=-2D0/3D0
CLR(I+3,J)=-2D0/3D0
  130 CONTINUE
  140   CONTINUE
DO 160 L=1,2
  DO 150 I=1,3
CLR(I,6+L)=-6D0
CLR(I+3,6+L)=6D0
CLR(6+L,I)=-6D0
CLR(6+L,I+3)=6D0
  150 CONTINUE
  160   CONTINUE
DO 180 K1=1,2
  DO 170 K2=1,2
CLR(6+K1,6+K2)=12D0
  170 CONTINUE
  180   CONTINUE

C...Evaluate matrix elements for g + g -> Q + Qbar + H.
FM(1,1)=64*PQ**6+16*PQ**4*PH**2+32*PQ**4*(X1+2*X2+X4+X9+2*
 &  X7+X5)+8*PQ**2*PH**2*(-X1-X4+2*X7)+16*PQ**2*(X2*X9+4*X2*
 &  X7+X2*X5-2*X4*X7-2*X9*X7)+8*PH**2*X4*X7-16*X2*X9*X7
FM(1,2)=16*PQ**6+8*PQ**4*(-2*X1+X2-2*X3-2*X4-4*X10+X9-X8+2
 &  *X7-4*X6+X5)+8*PQ**2*(-2*X1*X2-2*X2*X4-2*X2*X10+X2*X7-2*
 &  X2*X6-2*X3*X7+2*X4*X7+4*X10*X7-X9*X7-X8*X7)+16*X2*X7*(X4+
 &  X10)
FM(1,3)=16*PQ**6-4*PQ**4*PH**2+8*PQ**4*(-2*X1+2*X2-2*X3-4*
 &  X4-8*X10+X9+X8-2*X7-4*X6+2*X5)-(4*PQ**2*PH**2)*(X1+X4+X10
 &  +X6)+8*PQ**2*(-2*X1*X2-2*X1*X10+X1*X9+X1*X8-2*X1*X5+X2**2
 &  -4*X2*X4-5*X2*X10+X2*X8-X2*X7-3*X2*X6+X2*X5+X3*X9+2*X3*X7
 &  -X3*X5+X4*X8+2*X4*X6-3*X4*X5-5*X10*X5+X9*X8+X9*X6+X9*X5+
 &  X8*X7-4*X6*X5+X5**2)-(16*X2*X5)*(X1+X4+X10+X6)
FM(1,4)=16*PQ**6+4*PQ**4*PH**2+16*PQ**4*(-X1+X2-X3-X4+X10-
 &  X9-X8+2*X7+2*X6-X5)+4*PQ**2*

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #6 from Jürgen Reuter  ---
Created attachment 51716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51716&action=edit
gfortran appearance of the ICE

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #13 from Thomas Koenig  ---
Here is a complete strace of a "Hello, world" program on Linux, compiled
with -static-libgfortran (to remove some of the shared library loading :-)
and executed with

$ strace ./a.out > hello.dat

execve("./a.out", ["./a.out"], 0x7fff23679850 /* 52 vars */) = 0
brk(NULL)   = 0x55795af28000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffef37f68b0) = -1 EINVAL (Invalid
argument)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=137154, ...}) = 0
mmap(NULL, 137154, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f6b9f05a000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\3405\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=104984, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f6b9f058000
mmap(NULL, 107592, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f6b9f03d000
mmap(0x7f6b9f04, 73728, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f6b9f04
mmap(0x7f6b9f052000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x15000) = 0x7f6b9f052000
mmap(0x7f6b9f056000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f6b9f056000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libquadmath.so.0", O_RDONLY|O_CLOEXEC)
= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200:\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=297784, ...}) = 0
mmap(NULL, 299712, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f6b9eff3000
mmap(0x7f6b9eff6000, 184320, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f6b9eff6000
mmap(0x7f6b9f023000, 98304, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x3) = 0x7f6b9f023000
mmap(0x7f6b9f03b000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x47000) = 0x7f6b9f03b000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\363\0\0\0\0\0\0"..., 832) =
832
fstat(3, {st_mode=S_IFREG|0644, st_size=1369352, ...}) = 0
mmap(NULL, 1368336, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f6b9eea4000
mmap(0x7f6b9eeb3000, 684032, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x7f6b9eeb3000
mmap(0x7f6b9ef5a000, 618496, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0xb6000) = 0x7f6b9ef5a000
mmap(0x7f6b9eff1000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14c000) = 0x7f6b9eff1000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360q\2\0\0\0\0\0"...,
832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"...,
784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0",
32, 848) = 32
pread64(3,
"\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\t\233\222%\274\260\320\31\331\326\10\204\276X>\263"...,
68, 880) = 68
fstat(3, {st_mode=S_IFREG|0755, st_size=2029224, ...}) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"...,
784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0",
32, 848) = 32
pread64(3,
"\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\t\233\222%\274\260\320\31\331\326\10\204\276X>\263"...,
68, 880) = 68
mmap(NULL, 2036952, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f6b9ecb2000
mprotect(0x7f6b9ecd7000, 1847296, PROT_NONE) = 0
mmap(0x7f6b9ecd7000, 1540096, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f6b9ecd7000
mmap(0x7f6b9ee4f000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x19d000) = 0x7f6b9ee4f000
mmap(0x7f6b9ee9a000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f6b9ee9a000
mmap(0x7f6b9eea, 13528, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f6b9eea
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f6b9ecb
arch_prctl(ARCH_SET_FS, 0x7f6b9ecb0b80) = 0
mprotect(0x7f6b9ee9a000, 12288, PROT_READ) = 0
mprotect(0x7f6b9eff1000, 4096, PROT_READ) = 0
mprotect(0x7f6b9f03b000, 4096, PROT_READ) = 0
mprotect(0x7f6b9f056000, 4096, PROT_READ) = 0
mprotect(0x557959277000, 4096, PROT_READ) = 0
mprotect(0x7f6b9f0a9000, 4096, PROT_READ) = 0
munmap(0x7f6b9f05a000, 137154)  = 0
brk(NULL)   = 0x55795af28000
brk(0x55795af49000) = 0x55795af49000
fstat(0, {st_mode=S_IFCHR

[Bug libstdc++/103022] std::begin on empty std::valarray causes _GLIBCXX_DEBUG assertion

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-01

--- Comment #1 from Jonathan Wakely  ---
The obvious solution is to not use std::valarray, like all sensible people :-P

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

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

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

--- Comment #7 from Tamar Christina  ---
Yes, I've posted a patch for this already
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583008.html

waiting review.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #14 from Thomas Koenig  ---
(In reply to Iain Sandoe from comment #6)
> I had a brief look at some new fails on macOS12 / Darwin21 for gcov.
> 
> It seems that .mod_term_funcs entries are not being run - so if libgfortran
> relies on something defined as __attribute__((destructor)) [e.g. to flush
> file output] that might explain the issue.

Well, there is (at the end of main.c)

/* Cleanup the runtime library.  */

static void __attribute__((destructor))
cleanup (void)
{
  close_units ();
}

I guess that could be put into main, after the call to __MAIN, instead.

[Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu by r7-7101

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Doesn't look to me like RA issue, but rather incorrect coalescing of temporary
vars.
Optimized dump has:
   [local count: 1652516]:
  ivtmp.40_47 = (unsigned long) &h;
  _30 = ivtmp.40_47 + 96;

   [local count: 13370357]:
  # ivtmp.40_38 = PHI 
  _21 = (void *) ivtmp.40_38;
  MEM[(long int *)_21] = 1;
  MEM[(long int *)_21 + 8B] = 1;
  ivtmp.40_44 = ivtmp.40_38 + 16;
  if (_30 != ivtmp.40_44)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 1652516]:
  h ={v} {CLOBBER};

   [local count: 13370357]:
  # ivtmp.30_29 = PHI 
  _31 = (void *) ivtmp.30_29;
  MEM[(long int *)_31] = 1;
  MEM[(long int *)_31 + 8B] = 1;
  ivtmp.30_48 = ivtmp.30_29 + 16;
  if (_30 != ivtmp.30_48)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 1652516]:
  f = 2;
  e = 6;
  c = 1;
  b = &d;
  d[6] = &d;
  ff ();
  d ={v} {CLOBBER};
  _5 = h[3][0];
  _18 = (int) _5;
  h ={v} {CLOBBER};
  return _18;

So, the code initializes the whole h array, then has h ={v} {CLOBBER};, then
initializes it again, but unfortunately without mentioning the var in the IL -
it reuses ivtmp.40_47 for that, then sets various vars, including d[6]
initialization with &d escaping, clobbers d, reads from h and finally clobbers
h again.  I guess the var partitioning code from the above thinks h isn't
really live in between the first h clobber and h[3][0] load and so decides:
Partition 0: size 96 align 16
h   d
and places both h and d into the same stack slot.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #15 from Thomas Koenig  ---
Hmm, to test this further: What does

program main
  use, intrinsic :: iso_fortran_env, only: output_unit
  write (*,'(A)') 'Hello, world!'
  flush output_unit
end program main

yield, does that create the file as expected?

[Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu by r7-7101

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
What we see is an effect of 3 different optimizations, one is loop unrolling
(cunroll in this case), another one is ivopts that moves the h array references
out of the loops but still has separate:
  ivtmp.40_47 = (unsigned long) &h;
  _17 = (unsigned long) &h;
  _30 = _17 + 96;
...
  h ={v} {CLOBBER};
  ivtmp.30_33 = (unsigned long) &h;
  _41 = (unsigned long) &h;
  _36 = _41 + 96;
and finally dom3's VN which replaces ivtmp.30_33 initializer with ivtmp.40_47
and _36 with _30.
If what the cfg expand var partition code is as designed (I think other passes
do it too, e.g. compute_live_vars/live_vars_at_stmt relies on it too), then we
need to somehow avoid VN of &var across var ={v} {CLOBBER} stmt, but it isn't
really clear to me how.
Unless we change loop unrolling so that the different loop iterations if there
is a var clobber in the loop actually have different variables (the first
iteration the original var and other iterations that var's copies; perhaps only
for addressable vars?).  Then naturally VN couldn't merge those and the RTL
partitioning code could decide to put them into the same or different partition
and later RTL opts could CSE the addresses.

gcc-bugs@gcc.gnu.org

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-01
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #6 from Jonathan Wakely  ---
(In reply to TC from comment #4)
> I don't think this needs an extra constraint, just reordering the existing
> ones to check not-a-span (14.3, "remove_­cvref_­t is not a specialization
> of span") first.

Good point - we should do that just because it's cheaper to evaluate the
!is_span check before we waste time determining if it's a contiguous range.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #16 from Iain Sandoe  ---
(In reply to Thomas Koenig from comment #14)
> (In reply to Iain Sandoe from comment #6)
> > I had a brief look at some new fails on macOS12 / Darwin21 for gcov.
> > 
> > It seems that .mod_term_funcs entries are not being run - so if libgfortran
> > relies on something defined as __attribute__((destructor)) [e.g. to flush
> > file output] that might explain the issue.
> 
> Well, there is (at the end of main.c)
> 
> /* Cleanup the runtime library.  */
> 
> static void __attribute__((destructor))
> cleanup (void)
> {
>   close_units ();
> }

That would seem a very likely candidate for the issue.

NOTE: I have been discussing the non-running of mod_term_funcs with my
"downstream" and Apple folks.  The consensus is that this is 99.99% likely an
unintentional bug that just happens not to show with clang-based toolchains
because they queue DTORs on atexit (as does GCC for C++).

> I guess that could be put into main, after the call to __MAIN, instead.

Well, unless there's a good reason to have it in a DTOR, it makes for a more
robust solution to call it directly (there are various other differences that
could occur in mixed code bases esp. c++ + fortran even without the Darwin21.1
bug).

will try your alternate code later.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #17 from Iain Sandoe  ---
(In reply to Thomas Koenig from comment #15)
> Hmm, to test this further: What does
> 
> program main
>   use, intrinsic :: iso_fortran_env, only: output_unit
>   write (*,'(A)') 'Hello, world!'
>   flush output_unit
> end program main
> 
> yield, does that create the file as expected?

yup, indeed it does.

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #8 from Jürgen Reuter  ---
(In reply to Jürgen Reuter from comment #6)
> Created attachment 51716 [details]
> gfortran appearance of the ICE

Just for completeness, this example needs to be compiled with -O2, while
-O0 and -O1 work fine.

[Bug fortran/103023] New: ICE (Segmentation fault) with !$OMP DECLARE SIMD(func) linear(ref(u))

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

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

Bug ID: 103023
   Summary: ICE (Segmentation fault) with !$OMP DECLARE SIMD(func)
linear(ref(u))
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bartoldeman at users dot sourceforge.net
  Target Milestone: ---

Created attachment 51717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51717&action=edit
Test case for crash

For the following Fortran code gfortran gives a SIGSEGV (tested GCC 9.3,10.3
locally, 11.2 and trunk on Godbolt)

subroutine func(u,ndim)
  !$OMP DECLARE SIMD(func) linear(ref(u))
  integer, intent(in) :: ndim
  double precision, intent(in) :: u(ndim)
end subroutine func

Here's the output for 10.3:

$ gfortran -c -fopenmp-simd openfun2.f90
openfun2.f90:1:15:

1 | subroutine func(u,ndim)
  |   1
internal compiler error: Segmentation fault

0xc147cf crash_signal
../../gcc/toplev.c:328
0x948ae6 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/fold-const.c:1906
0x7b8258 gfc_trans_omp_clauses
../../gcc/fortran/trans-openmp.c:2324
0x7bb168 gfc_trans_omp_declare_simd(gfc_namespace*)
../../gcc/fortran/trans-openmp.c:5838
0x77b767 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:3069
0x77b767 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6744
0x6f679e translate_all_program_units
../../gcc/fortran/parse.c:6306
0x6f679e gfc_parse_file()
../../gcc/fortran/parse.c:6567
0x74dfbf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-01
 Ever confirmed|0   |1
Summary|[12 Regression] 45% |[12 Regression] 45%
   |454.calculix regression |454.calculix regression
   |with LTO+PGO -march=native  |with LTO+PGO -march=native
   |-Ofast between  |-Ofast on Zen since
   |ce4d1f632ff3f680550d3b186b6 |r12-4526-gd8edfadfc7a9795b6
   |0176022f41190 and   |5177a50ce44fd348858e844
   |6fca1761a16c68740f875fc487b |
   |98b6bde8e9be7 on Zen|
 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |
 CC||aldyh at gcc dot gnu.org

--- Comment #8 from Martin Liška  ---
Started with Aldy's commit r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #18 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #13)
> Here is a complete strace of a "Hello, world" program on Linux, compiled
> with -static-libgfortran (to remove some of the shared library loading :-)
> and executed with
> 
> $ strace ./a.out > hello.dat
> 
> execve("./a.out", ["./a.out"], 0x7fff23679850 /* 52 vars */) = 0
> brk(NULL)   = 0x55795af28000
>
> Is it possible to run an equivalent command on MacOS to see
> what is going on there?

Seems that dtruss is doing the same under macOS, here I get this output for the
Hello, world! program:
SYSCALL(args)= return
 Hello, world!\n
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2
bsdthread_register(0x7FF805E18020, 0x7FF805E1800C, 0x2000)   =
1073742303 0
shm_open(0x7FF805CE6F5D, 0x0, 0x5CE57BA) = 3 0
fstat64(0x3, 0x7FF7BDDDE820, 0x0)= 0 0
mmap(0x0, 0x2000, 0x1, 0x40001, 0x3, 0x0)= 0x102231000 0
close(0x3)   = 0 0
ioctl(0x2, 0x4004667A, 0x7FF7BDDDE8D4)   = 0 0
mprotect(0x102238000, 0x1000, 0x0)   = 0 0
mprotect(0x10223F000, 0x1000, 0x0)   = 0 0
mprotect(0x10224, 0x1000, 0x0)   = 0 0
mprotect(0x102247000, 0x1000, 0x0)   = 0 0
mprotect(0x102233000, 0x90, 0x1) = 0 0
mprotect(0x102233000, 0x90, 0x3) = 0 0
mprotect(0x102233000, 0x90, 0x1) = 0 0
mprotect(0x102248000, 0x1000, 0x1)   = 0 0
mprotect(0x102249000, 0x90, 0x1) = 0 0
mprotect(0x102249000, 0x90, 0x3) = 0 0
mprotect(0x102249000, 0x90, 0x1) = 0 0
mprotect(0x102233000, 0x90, 0x3) = 0 0
mprotect(0x102233000, 0x90, 0x1) = 0 0
mprotect(0x102248000, 0x1000, 0x3)   = 0 0
mprotect(0x102248000, 0x1000, 0x1)   = 0 0
issetugid(0x0, 0x0, 0x0) = 0 0
getentropy(0x7FF7BDDDE6D0, 0x20, 0x0)= 0 0
getentropy(0x7FF7BDDDE730, 0x40, 0x0)= 0 0
getpid(0x0, 0x0, 0x0)= 61321 0
stat64("/AppleInternal\0", 0x7FF7BDDDEDF0, 0x0)  = -1 Err#2
csops_audittoken(0xEF89, 0x7, 0x7FF7BDDDE920)= -1 Err#22
proc_info(0x2, 0xEF89, 0xD)  = 64 0
csops_audittoken(0xEF89, 0x7, 0x7FF7BDDDEA10)= -1 Err#22
sysctlbyname(kern.osvariant_status, 0x15, 0x7FF7BDDDEE40, 0x7FF7BDDDEE38, 0x0) 
 = 0 0
csops(0xEF89, 0x0, 0x7FF7BDDDEE74)   = 0 0
fstat64(0x0, 0x7FF7BDDDEBF0, 0x0)= 0 0
fstat64(0x1, 0x7FF7BDDDEBF0, 0x0)= 0 0
fstat64(0x2, 0x7FF7BDDDEBF0, 0x0)= 0 0
mprotect(0x10212F000, 0x10, 0x1) = 0 0
sigaction(0x3, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)   = 0 0
sigaction(0x4, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)   = 0 0
sigaction(0x6, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)   = 0 0
sigaction(0x8, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)   = 0 0
sigaction(0xB, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)   = 0 0
sigaction(0xA, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)   = 0 0
sigaction(0xC, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)   = 0 0
sigaction(0x5, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)   = 0 0
sigaction(0x18, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0)  = 0 0
sigaction(0x19, 0x7FF7BDDDFFB8, 0x7FF7BDDDFFE0)  = 0 0
write(0x1, " Hello, world!\\n\n\0", 0x11)= 17 0

[Bug c++/102990] [9/10/11/12 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to work||8.5.0
Summary|ICE in  |[9/10/11/12 Regression] ICE
   |tsubst_copy_and_build with  |in tsubst_copy_and_build
   |template non-type arugment  |with NSDMI and double to
   |and double to int   |int conversion
   |conversion  |
   Target Milestone|--- |9.5
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
  Known to fail||10.3.0, 11.2.0, 12.0, 9.4.0

--- Comment #6 from Patrick Palka  ---
Reduced C++11 ICE-on-valid testcase:

struct knob_t {
  int value = 1.0;
};

struct Helpers {
  knob_t inputs;
};

template void f(decltype(Helpers{}));

ICEs with -std=c++14 since r9-5678 (but -std=c++11 is ok)

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[manfred99 at gmx dot ch via Gcc-bugs]

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

--- Comment #24 from Manfred Schwarb  ---
Sandra,
I will look into this. Probably streamlining the patch to only use *4 and *8
is appropriate.

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

[mario-baumann at web dot de via Gcc-bugs]

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

Mario Baumann  changed:

   What|Removed |Added

 CC||mario-baumann at web dot de

--- Comment #9 from Mario Baumann  ---
Created attachment 51718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51718&action=edit
smaller Fortran example

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

[mario-baumann at web dot de via Gcc-bugs]

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

--- Comment #10 from Mario Baumann  ---
Added smaller Fortran example foo.F.
Same behaviour, fails with ICE for -O2 and works with -O1 and -O0

[Bug fortran/103023] ICE (Segmentation fault) with !$OMP DECLARE SIMD(func) linear(ref(u))

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
I think we should warn and ignore the declare simd in this case, this can't be
expressed in the Intel Vector Function ABI mangling we are using, where for
linear the options are:
::
/* empty */ // linear_step is equal to 1
's' non-negative-decimal-number // linear_step is passed in another argument,
// decimal number is the position # of
// linear_step argument, which starts from 0
| number // linear_step is literally constant stride
While at the source level the linear-step is 1 which is constant, it actually
is
1 * type size of u, and that isn't constant.  And the s number isn't an option
in this case either, because it needs to refer to an uniform argument and needs
to be specified as the linear-step.  So e.g. uniform(ndim) linear(ref(u):ndim)
would work, but would do something different.
ifort rejects this with a weird message.

Anyway, besides not ICEing on this, I don't understand what you expect from
this, you'll never get optimized code if each SIMD lane needs to work with its
own arrays, whether fixed or variable sized.

[Bug tree-optimization/103003] [12 regression] ice in set_relation, at value-relation.cc:592

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:0187c03be31a58ba561d535687dc00c94f0ff1aa

commit r12-4821-g0187c03be31a58ba561d535687dc00c94f0ff1aa
Author: Andrew MacLeod 
Date:   Sat Oct 30 11:00:49 2021 -0400

Don't register nonsensical relations.

gcc/
PR tree-optimization/103003
* value-relation.cc (dom_oracle::register_relation): If the 2
ssa names are the same, don't register any relation.

gcc/testsuite/
* gcc.dg/pr103003.c: New.

[Bug libstdc++/103022] std::begin on empty std::valarray causes _GLIBCXX_DEBUG assertion

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:91bac9fed5d082f0b180834110ebc0f46f97599a

commit r12-4824-g91bac9fed5d082f0b180834110ebc0f46f97599a
Author: Jonathan Wakely 
Date:   Mon Nov 1 11:06:51 2021 +

libstdc++: Fix range access for empty std::valarray [PR103022]

The std::begin and std::end overloads for std::valarray are defined in
terms of std::addressof(v[0]) which is undefined for an empty valarray.

libstdc++-v3/ChangeLog:

PR libstdc++/103022
* include/std/valarray (begin, end): Do not dereference an empty
valarray. Add noexcept and [[nodiscard]].
* testsuite/26_numerics/valarray/range_access.cc: Check empty
valarray. Check iterator properties. Run as well as compiling.
* testsuite/26_numerics/valarray/range_access2.cc: Likewise.
* testsuite/26_numerics/valarray/103022.cc: New test.

[Bug tree-optimization/103003] [12 regression] ice in set_relation, at value-relation.cc:592

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Macleod  ---
fixed.

[Bug testsuite/103000] Some updated test cases from r12-4786 fail

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r12-4826-g8a260d652c421e212818efc3c0f487cf9cdbcc2c
Author: Tamar Christina 
Date:   Mon Nov 1 13:42:51 2021 +

testsuite: fix failing complex add testcases PR103000

Some targets have overriden the default unroll factor and so do not have
enough
data to succeed for SLP vectorization if loop vect is turned off.

To fix this just always unroll in these testcases.

gcc/testsuite/ChangeLog:

PR testsuite/103000
* gcc.dg/vect/complex/fast-math-bb-slp-complex-add-double.c:
Force unroll.
* gcc.dg/vect/complex/fast-math-bb-slp-complex-add-float.c:
likewise
* gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-float.c:
Likewise
*
gcc.dg/vect/complex/fast-math-bb-slp-complex-add-pattern-half-float.c:
Likewise.

[Bug testsuite/103000] Some updated test cases from r12-4786 fail

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
This should be fixed. Please re-open if not the case and if so could you attach
the output of -fdump-tree-slp-all.

[Bug target/102957] [riscv64] ICE on bogus -march value

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

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

Kito Cheng  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |kito at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-01

--- Comment #1 from Kito Cheng  ---
Confirmed, thanks for report this issue :)

[Bug tree-optimization/103024] New: ICE in execute, at gimple-harden-conditionals.cc:424

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

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

Bug ID: 103024
   Summary: ICE in execute, at gimple-harden-conditionals.cc:424
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat ice.ii
struct G4ErrorMatrix {
  G4ErrorMatrix(int);
  ~G4ErrorMatrix();
};
double PropagateError_charge;
void PropagateError() {
  G4ErrorMatrix transf(0);
  int field(PropagateError_charge && field);
}

$ g++ ice.ii -c -fnon-call-exceptions -fharden-compares -fsignaling-nans
during GIMPLE pass: hardcmp
ice.ii: In function ‘void PropagateError()’:
ice.ii:6:6: internal compiler error: in execute, at
gimple-harden-conditionals.cc:424
6 | void PropagateError() {
  |  ^~
0x96aa89 execute
/home/marxin/Programming/gcc/gcc/gimple-harden-conditionals.cc:424
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/103024] ICE in execute, at gimple-harden-conditionals.cc:424

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-11-01
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/103025] New: ICE in insert_stmt_after, at tree-ssa-reassoc.c:1524

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

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

Bug ID: 103025
   Summary: ICE in insert_stmt_after, at tree-ssa-reassoc.c:1524
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following ICEs:

$ cat vect.i
static void __get_cpuid_count(int __leaf) {
  unsigned __eax;
  __asm__ __volatile__("" : "=a"(__eax));
  if (__eax == 0 || __eax < __leaf)
__asm__("");
}
void main() {
  int want_b;
  __get_cpuid_count(7);
}

$ gcc vect.i -fno-tree-ccp -ftrivial-auto-var-init=pattern -fno-tree-dce
-fnon-call-exceptions -fno-tree-forwprop -fno-tree-fre -O1
during GIMPLE pass: reassoc
vect.i: In function ‘main’:
vect.i:7:6: internal compiler error: in insert_stmt_after, at
tree-ssa-reassoc.c:1524
7 | void main() {
  |  ^~~~
0x7b2b4a insert_stmt_after
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:1524
0x10d0a4b build_and_add_sum
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:1589
0x10dcebb eliminate_redundant_comparison
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:2312
0x10dcebb optimize_ops_list
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:2450
0x10e290b reassociate_bb
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:6634
0x10e2f7b reassociate_bb
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:6796
0x10e52fe do_reassoc
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:6908
0x10e52fe execute_reassoc
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:6997
0x10e52fe execute
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:7038
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/103025] ICE in insert_stmt_after, at tree-ssa-reassoc.c:1524

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-01
   Target Milestone|--- |12.0
 CC||qinzhao at gcc dot gnu.org

[Bug c++/103026] Implement warning for Unicode bidi override characters [CVE-2021-42574]

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-01
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Marek Polacek  ---
I have a patch.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

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

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

--- Comment #9 from Aldy Hernandez  ---
(In reply to Martin Liška from comment #8)
> Started with Aldy's commit
> r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844.

Hmmm, this commit disables problematic threads we've agreed are detrimental to
loop form.  So it's not something the threader did, but something it's not
allowed to do.  This PR may need a loop expert to analyze.

I guess, technically it could be something we could catch past the loop
optimizers, but that's usually rarer.

[Bug preprocessor/103027] New: Implement warning for homoglyphs in identifiers [CVE-2021-42694]

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

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

Bug ID: 103027
   Summary: Implement warning for homoglyphs in identifiers
[CVE-2021-42694]
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

An issue was discovered in the character definitions of the Unicode
Specification through 14.0. The specification allows an adversary to produce
source code identifiers such as function names using homoglyphs that render
visually identical to a target identifier. Adversaries can leverage this to
inject code via adversarial identifier definitions in upstream software
dependencies invoked deceptively in downstream software.

We ought to have a diagnostic the warns about such problematic identifiers.

More info:
https://nvd.nist.gov/vuln/detail/CVE-2021-42694
https://trojansource.codes/

[Bug target/103028] New: ICE in extract_constrain_insn, at recog.c:2670

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

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

Bug ID: 103028
   Summary: ICE in extract_constrain_insn, at recog.c:2670
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, krebbel at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: s390x-linux-gnu

The following fails:

$ s390x-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp37.c
-fif-conversion2 -Og -fharden-conditional-branches -march=z9-ec -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp37.c: In function
‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp37.c:12:1: error:
insn does not satisfy its constraints:
   12 | }
  | ^
(insn 64 28 65 5 (set (reg:CCU 33 %cc)
(compare:CCU (reg/v:DI 1 %r1 [orig:63 i ] [63])
(const_int 4294967296 [0x1])))
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp37.c":9:6 1428
{*cmpdi_ccu}
 (nil))
during RTL pass: cprop_hardreg
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp37.c:12:1:
internal compiler error: in extract_constrain_insn, at recog.c:2670
0x5cc39e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/rtl-error.c:108
0x5cc3c4 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/rtl-error.c:118
0x5cb800 extract_constrain_insn(rtx_insn*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/recog.c:2670
0xaa5d3e copyprop_hardreg_forward_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/regcprop.c:825
0xaa6afd execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/regcprop.c:1390
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug preprocessor/103027] Implement warning for homoglyphs in identifiers [CVE-2021-42694]

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-01
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103026
   Keywords||diagnostic

[Bug target/103028] ICE in extract_constrain_insn, at recog.c:2670

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Last reconfirmed||2021-11-01
 Status|UNCONFIRMED |NEW

[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice

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

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Qing Zhao :

https://gcc.gnu.org/g:429e3b7d8bf6609ddf7c7b1e49244997e9ac76b8

commit r12-4829-g429e3b7d8bf6609ddf7c7b1e49244997e9ac76b8
Author: Oracle Public Cloud User

Date:   Mon Nov 1 15:14:26 2021 +

PR 102281 (-ftrivial-auto-var-init=zero causes ice)

Do not add call to __builtin_clear_padding when a variable is a gimple
register or it might not have padding.

gcc/ChangeLog:

2021-11-01  qing zhao  

* gimplify.c (gimplify_decl_expr): Do not add call to
__builtin_clear_padding when a variable is a gimple register
or it might not have padding.
(gimplify_init_constructor): Likewise.

gcc/testsuite/ChangeLog:

2021-11-01  qing zhao  

* c-c++-common/pr102281.c: New test.
* gcc.target/i386/auto-init-2.c: Adjust testing case.
* gcc.target/i386/auto-init-4.c: Likewise.
* gcc.target/i386/auto-init-6.c: Likewise.
* gcc.target/aarch64/auto-init-6.c: Likewise.

[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice

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

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

--- Comment #18 from qinzhao at gcc dot gnu.org ---
fixed

[Bug preprocessor/103027] Implement warning for homoglyphs in identifiers [CVE-2021-42694]

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

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

--- Comment #1 from David Malcolm  ---
I have a work-in-progress patch for this, though it has some issues that need
discussion; I hope to post it soon.

[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #19 from qinzhao at gcc dot gnu.org ---
fixed.

[Bug middle-end/102997] [12 Regression] 45% 454.calculix regression with LTO+PGO -march=native -Ofast on Zen since r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844

[hubicka at kam dot mff.cuni.cz via Gcc-bugs]

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

--- Comment #10 from hubicka at kam dot mff.cuni.cz ---
> 
> Hmmm, this commit disables problematic threads we've agreed are detrimental to
> loop form.  So it's not something the threader did, but something it's not
> allowed to do.  This PR may need a loop expert to analyze.
> 
> I guess, technically it could be something we could catch past the loop
> optimizers, but that's usually rarer.

In the patch you introduce crossed_loop_header variable which is only
set to true when loop header is visited but it does not seem to be
cleared when the loop is leaved.

I would expect that one wants to keep track of outermost loop entered
and check if the path left it later.

Honza

[Bug preprocessor/103026] Implement warning for Unicode bidi override characters [CVE-2021-42574]

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

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

--- Comment #2 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583031.html

[Bug fortran/103023] ICE (Segmentation fault) with !$OMP DECLARE SIMD(func) linear(ref(u))

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

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

--- Comment #2 from bartoldeman at users dot sourceforge.net ---
Yes this is about the ICE mainly.

It was stripped down from this, which HAS uniform.

subroutine func(u,f,ndim)
  !$OMP DECLARE SIMD(func) uniform(ndim) linear(ref(f,u):1)
  integer, intent(in) :: ndim
  double precision, intent(in) :: u(ndim)
  double precision, intent(out) :: f(ndim)
  f(1) = u(1) + u(2)
  f(2) = u(1) - u(2)
end subroutine func

subroutine main(u,f)
  double precision, intent(in) :: u(8)
  double precision, intent(out) :: f(8)
!$OMP SIMD
  do i=1,8,2
 call func(u(i),f(i),2)
  enddo
end subroutine main

If I leave out ndim and hardcode "2" in func (:: u(2) and :: f(2)), or let the
auto-vectorizer and inliner do its work this produces good code (though it
would be better with u and f transposed, as basically the code transposes it to
two ymm registers in the asm output.

With general "ndim" that could still work, e.g. with ndim=3 and 3 equations for
u(1:3) -> f(1:3), you'd work with 3 vector registers.

Now you may wonder why "ndim" here, since we know it's "2": this comes from
feeding a user-defined function into a larger program (that processes e.g.
maps) where that same user needs to specify ndim as a parameter.

Intel (ifort) doesn't like this at all from what I can see:

openfun.f90(1): error #6080: Only scalar variables may be referenced in a
LINEAR or MONOTONIC clause.   [U]
subroutine func(u,f)
^
openfun.f90(1): error #6080: Only scalar variables may be referenced in a
LINEAR or MONOTONIC clause.   [F]
subroutine func(u,f)
--^
compilation aborted for openfun.f90 (code 1)

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #19 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #18)

> write(0x1, " Hello, world!\\n\n\0", 0x11)  = 17 0

Hmm, was this actually the string that you put into the Fortran
program, or is something very strange going on here?

[Bug c++/102990] [9/10/11/12 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Oof, mine then.  Thanks for reducing this.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #20 from Thomas Koenig  ---
(In reply to Iain Sandoe from comment #16)
> (In reply to Thomas Koenig from comment #14)

> NOTE: I have been discussing the non-running of mod_term_funcs with my
> "downstream" and Apple folks.  The consensus is that this is 99.99% likely
> an unintentional bug that just happens not to show with clang-based
> toolchains because they queue DTORs on atexit (as does GCC for C++).
> 
> > I guess that could be put into main, after the call to __MAIN, instead.
> 
> Well, unless there's a good reason to have it in a DTOR, it makes for a more
> robust solution to call it directly (there are various other differences
> that could occur in mixed code bases esp. c++ + fortran even without the
> Darwin21.1 bug).

There is always the reason of not breaking compatibility, a quick look
at close_units() shows that it is not meant to be called twice,
so combining both methods is likely to cause headaches.

So, something for the next incompatible libgfortran update, maybe.

Maybe flushing all units on program termination would be safer, but
I am not sure we should put in a workaround for what appears to
be a bug in the underlying system (hopefully soon to be fixed),
especially since there seems to be a workaround in user code.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #21 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #19)
> (In reply to Jürgen Reuter from comment #18)
> 
> > write(0x1, " Hello, world!\\n\n\0", 0x11)= 17 0
> 
> Hmm, was this actually the string that you put into the Fortran
> program, or is something very strange going on here?

Yes, the program was 

program main
   print *, "Hello, world!\n"
end program main
sorry, about the backslash \n, that was accidental. 
Doing just
program main
   print *, "Hello, world!"
end program main

# dtruss ./a.out > out.008
SYSCALL(args)  = return
 Hello, world!
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2
bsdthread_register(0x7FF805E18020, 0x7FF805E1800C, 0x2000) = 1073742303
0
shm_open(0x7FF805CE6F5D, 0x0, 0x5CE57BA) = 3 0
fstat64(0x3, 0x7FF7BE646820, 0x0) = 0 0
mmap(0x0, 0x2000, 0x1, 0x40001, 0x3, 0x0) = 0x1019C9000 0
close(0x3) = 0 0
ioctl(0x2, 0x4004667A, 0x7FF7BE6468D4) = 0 0
mprotect(0x1019D, 0x1000, 0x0) = 0 0
mprotect(0x1019D7000, 0x1000, 0x0) = 0 0
mprotect(0x1019D8000, 0x1000, 0x0) = 0 0
mprotect(0x1019DF000, 0x1000, 0x0) = 0 0
mprotect(0x1019CB000, 0x90, 0x1) = 0 0
mprotect(0x1019CB000, 0x90, 0x3) = 0 0
mprotect(0x1019CB000, 0x90, 0x1) = 0 0
mprotect(0x1019E, 0x1000, 0x1) = 0 0
mprotect(0x1019E1000, 0x90, 0x1) = 0 0
mprotect(0x1019E1000, 0x90, 0x3) = 0 0
mprotect(0x1019E1000, 0x90, 0x1) = 0 0
mprotect(0x1019CB000, 0x90, 0x3) = 0 0
mprotect(0x1019CB000, 0x90, 0x1) = 0 0
mprotect(0x1019E, 0x1000, 0x3) = 0 0
mprotect(0x1019E, 0x1000, 0x1) = 0 0
issetugid(0x0, 0x0, 0x0) = 0 0
getentropy(0x7FF7BE6466D0, 0x20, 0x0) = 0 0
getentropy(0x7FF7BE646730, 0x40, 0x0) = 0 0
getpid(0x0, 0x0, 0x0) = 61408 0
stat64("/AppleInternal\0", 0x7FF7BE646DF0, 0x0) = -1 Err#2
csops_audittoken(0xEFE0, 0x7, 0x7FF7BE646920) = -1 Err#22
proc_info(0x2, 0xEFE0, 0xD) = 64 0
csops_audittoken(0xEFE0, 0x7, 0x7FF7BE646A10) = -1 Err#22
sysctlbyname(kern.osvariant_status, 0x15, 0x7FF7BE646E40, 0x7FF7BE646E38, 0x0) 
   = 0 0
csops(0xEFE0, 0x0, 0x7FF7BE646E74) = 0 0
fstat64(0x0, 0x7FF7BE646BF0, 0x0) = 0 0
fstat64(0x1, 0x7FF7BE646BF0, 0x0) = 0 0
fstat64(0x2, 0x7FF7BE646BF0, 0x0) = 0 0
mprotect(0x1018C7000, 0x10, 0x1) = 0 0
sigaction(0x3, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0x4, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0x6, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0x8, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0xB, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0xA, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0xC, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0x5, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0x18, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0
sigaction(0x19, 0x7FF7BE647FB8, 0x7FF7BE647FE0) = 0 0
write(0x1, " Hello, world!\n\0", 0xF) = 15 0

[Bug preprocessor/103026] Implement warning for Unicode bidi override characters [CVE-2021-42574]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This affects also other language FEs (Fortran, Go, D, ...).
E.g. for Go it has been mentioned already a few years ago:
https://github.com/golang/go/issues/20209
Some testcases from the reporters:
https://github.com/nickboucher/trojan-source

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #22 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #20)
> (In reply to Iain Sandoe from comment #16)
> > (In reply to Thomas Koenig from comment #14)

> 
> There is always the reason of not breaking compatibility, a quick look
> at close_units() shows that it is not meant to be called twice,
> so combining both methods is likely to cause headaches.
> 
> So, something for the next incompatible libgfortran update, maybe.
> 
> Maybe flushing all units on program termination would be safer, but
> I am not sure we should put in a workaround for what appears to
> be a bug in the underlying system (hopefully soon to be fixed),
> especially since there seems to be a workaround in user code.

I agree that if this an OS bug, then workarounds in libgfortran that might
jeopardize the integrity are hard to justify. Do we know that this will be
fixed let's say for macOS 12.0.2 or so, and when will that come? At the moment
these things do break quite a lot of build scripts for software that rely on
redirecting output from test programs. Changing all those test programs to
iso_fortan_env is tedious (but doable).

[Bug libbacktrace/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #4 from Ian Lance Taylor  ---
I think you are misreading the make output slightly due to the use of the -j
option.  pex-unix.c is not built as part of libbacktrace.  The build is failing
while building build-libiberty.  Changing the component.

[Bug other/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32

[ian at airs dot com via Gcc-bugs]

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

--- Comment #5 from Ian Lance Taylor  ---
Can you add some output from make without the -j option?  I don't understand
how this error is possible.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #23 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #22)
> (In reply to Thomas Koenig from comment #20)
> > (In reply to Iain Sandoe from comment #16)
> > > (In reply to Thomas Koenig from comment #14)
> 
> > 
> > There is always the reason of not breaking compatibility, a quick look
> > at close_units() shows that it is not meant to be called twice,
> > so combining both methods is likely to cause headaches.
> > 
> > So, something for the next incompatible libgfortran update, maybe.
> > 
> > Maybe flushing all units on program termination would be safer, but
> > I am not sure we should put in a workaround for what appears to
> > be a bug in the underlying system (hopefully soon to be fixed),
> > especially since there seems to be a workaround in user code.
> 
> I agree that if this an OS bug, then workarounds in libgfortran that might
> jeopardize the integrity are hard to justify. 

Well, we certainly would not want to do compromise integrity, in any event;
that would not be a solution.  However, ensuring a single call to the function
ought to be feasible.  the secondary point I made was that the phasing of DTORs
called from cxa_atexit (C++) c.f. directly from a destructor can cause subtle
issues in any case.

>Do we know that this will be
> fixed let's say for macOS 12.0.2 or so, and when will that come? 

I have filed a bug report, (FB9733712).  It is impossible to know what the OS
release priorities are (or schedules), but I do know that the Apple OSS folks
are very supportive of gfortran, so I expect they will help.

> At the
> moment these things do break quite a lot of build scripts for software that
> rely on redirecting output from test programs. Changing all those test
> programs to iso_fortan_env is tedious (but doable).

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[vvinayag at arm dot com via Gcc-bugs]

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

vvinayag at arm dot com changed:

   What|Removed |Added

 CC||vvinayag at arm dot com

--- Comment #29 from vvinayag at arm dot com ---
Can we expect a patch for this upstream?

[Bug tree-optimization/103029] New: [12 regression] gcc.dg/vect/pr82436.c ICEs on r12-4818

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

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

Bug ID: 103029
   Summary: [12 regression] gcc.dg/vect/pr82436.c ICEs on r12-4818
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f35af8df241a9eb9c2edf7da26d3c5f53d6e2511, r12-4818

This occurs on power 7 (powerpc64 big endian):

make  -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr82436.c"
FAIL: gcc.dg/vect/pr82436.c (internal compiler error)
FAIL: gcc.dg/vect/pr82436.c (test for excess errors)
FAIL: gcc.dg/vect/pr82436.c -flto -ffat-lto-objects (internal compiler error)
FAIL: gcc.dg/vect/pr82436.c -flto -ffat-lto-objects (test for excess errors)
# of unexpected failures4


Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/pr82436.c   
-fdiagnostics-plain-output   -maltivec -mvsx -mno-allow-movmisalign
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -Ofast -fno-tree-scev-cprop -S -o
pr82436.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/pr82436.c
-fdiagnostics-plain-output -maltivec -mvsx -mno-allow-movmisalign
-ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -Ofast -fno-tree-scev-cprop -S -o
pr82436.s
during GIMPLE pass: vect
dump file: pr82436.c.169t.vect
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/pr82436.c: In function
'foo':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/pr82436.c:20:5:
internal compiler error: Segmentation fault
0x10ba1eeb crash_signal
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:322
0x10dc5b88 find_uses_to_rename_use
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:391
0x10dc5b88 find_uses_to_rename_bb
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:466
0x10dc9623 find_uses_to_rename
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:498
0x10dc9623 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int,
loop*)
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:664
0x10dc9623 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int,
loop*)
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:629
0x10fabbdb vectorize_loops()
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1320
0x10def927 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop.c:413
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/vect/pr82436.c (internal compiler error)

[Bug tree-optimization/103029] [12 regression] gcc.dg/vect/pr82436.c ICEs on r12-4818

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64-linux-gnu
 CC||bergner at gcc dot gnu.org,
   ||luoxhu at cn dot ibm.com
  Build||powerpc64-linux-gnu
   Host||powerpc64-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
commit f35af8df241a9eb9c2edf7da26d3c5f53d6e2511
Author: Xionghu Luo 
Date:   Mon Nov 1 00:12:36 2021 -0500

Refactor loop_version

[Bug c/103030] New: floating point to int inconsistency

[c25devbiz at aol dot com via Gcc-bugs]

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

Bug ID: 103030
   Summary: floating point to int inconsistency
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: c25devbiz at aol dot com
  Target Milestone: ---

#include 
typedef long long llong;
int main(int argc,char **argv){;
int ex=0;
llong num_z=0xf70694892bddbb3f,num_x=0x00f88640;double *z_p=(void
*)&num_z,*x_p=(void *)&num_x;
static int le_v=1;char *le=(void *)&le_v;if(le[0])
{   llong num_z2=0,num_x2=0;int n=0;while(n>=8;
num_x2<<=8;num_x2|=num_x&0xFF;num_x>>=8;n+=1;
}   num_z=num_z2;num_x=num_x2;
}double c_f=z_p[0]*x_p[0];int
a=floor(z_p[0]*x_p[0]),b=z_p[0]*x_p[0],c=c_f;if(a!=b)dprintf(2,"%d %d
%d\n",a,b,c);
if(1)dprintf(2,"%.15lf %.15lf %.15lf\n",z_p[0],x_p[0],c_f);
return ex;};
/*fn=;gcc $fn.c -o $fn -lm -include stdio.h&&$fn*/

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #24 from Jürgen Reuter  ---
(In reply to Iain Sandoe from comment #23)
> (In reply to Jürgen Reuter from comment #22)
> > (In reply to Thomas Koenig from comment #20)
> > > (In reply to Iain Sandoe from comment #16)
> > > > (In reply to Thomas Koenig from comment #14)

> 
> >Do we know that this will be
> > fixed let's say for macOS 12.0.2 or so, and when will that come? 
> 
> I have filed a bug report, (FB9733712).  It is impossible to know what the
> OS release priorities are (or schedules), but I do know that the Apple OSS
> folks are very supportive of gfortran, so I expect they will help.
> 

Could you post the link to this bug report? I cannot find it. Or is this not
publicly visible.

> > At the
> > moment these things do break quite a lot of build scripts for software that
> > rely on redirecting output from test programs. Changing all those test
> > programs to iso_fortan_env is tedious (but doable).

I just started to look a bit, changing all of your configure script would be
really tedious. So I really would prefer a fixed OS or a workaround inside
gcc/gfortran.

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

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

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

--- Comment #25 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #24)
> (In reply to Iain Sandoe from comment #23)

> > I have filed a bug report, (FB9733712).  It is impossible to know what the
> > OS release priorities are (or schedules), but I do know that the Apple OSS
> > folks are very supportive of gfortran, so I expect they will help.

> Could you post the link to this bug report? I cannot find it. Or is this not
> publicly visible.

"radars" are not publicly visible, but the ID is significant if you are
reporting something to Apple / an Apple OSS person.

[Bug other/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32

[schwab--- via Gcc-bugs]

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

--- Comment #6 from Andreas Schwab  ---
Please attach the file build-x86_64-pc-linux-gnu/libiberty/config.log

[Bug libstdc++/103022] std::begin on empty std::valarray causes _GLIBCXX_DEBUG assertion

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:0111975c07233512e63371b2bc99f88d9670bbc9

commit r11-9198-g0111975c07233512e63371b2bc99f88d9670bbc9
Author: Jonathan Wakely 
Date:   Mon Nov 1 11:06:51 2021 +

libstdc++: Fix range access for empty std::valarray [PR103022]

The std::begin and std::end overloads for std::valarray are defined in
terms of std::addressof(v[0]) which is undefined for an empty valarray.

libstdc++-v3/ChangeLog:

PR libstdc++/103022
* include/std/valarray (begin, end): Do not dereference an empty
valarray. Add noexcept and [[nodiscard]].
* testsuite/26_numerics/valarray/range_access.cc: Check empty
valarray. Check iterator properties. Run as well as compiling.
* testsuite/26_numerics/valarray/range_access2.cc: Likewise.
* testsuite/26_numerics/valarray/103022.cc: New test.

(cherry picked from commit 91bac9fed5d082f0b180834110ebc0f46f97599a)

[Bug middle-end/103030] floating point to int inconsistency

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Last reconfirmed||2021-11-01
  Component|c   |middle-end
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
I get the result of 80 for a, b and c on x86_64-linux-gnu (even with -m32) and
across compilers, GCC, clang and ICC.

What target are you using?

[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

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

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

--- Comment #2 from Christophe Lyon  ---
Yes, I can still see failures with r12-4820

[Bug libstdc++/103022] std::begin on empty std::valarray causes _GLIBCXX_DEBUG assertion

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

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

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

https://gcc.gnu.org/g:2374dfc907a9eb6ae2940c0d49de37bcf96bd5e5

commit r10-10246-g2374dfc907a9eb6ae2940c0d49de37bcf96bd5e5
Author: Jonathan Wakely 
Date:   Mon Nov 1 11:06:51 2021 +

libstdc++: Fix range access for empty std::valarray [PR103022]

The std::begin and std::end overloads for std::valarray are defined in
terms of std::addressof(v[0]) which is undefined for an empty valarray.

libstdc++-v3/ChangeLog:

PR libstdc++/103022
* include/std/valarray (begin, end): Do not dereference an empty
valarray. Add noexcept and [[nodiscard]].
* testsuite/26_numerics/valarray/range_access.cc: Check empty
valarray. Check iterator properties. Run as well as compiling.
* testsuite/26_numerics/valarray/range_access2.cc: Likewise.
* testsuite/26_numerics/valarray/103022.cc: New test.

(cherry picked from commit 91bac9fed5d082f0b180834110ebc0f46f97599a)

[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 since r12-4278-g74ccca380cde5e79

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
I'm testing the following fix:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 4dea840e348..c5360dfaede 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2129,6 +2129,7 @@ simplify_parameter_variable (gfc_expr *p, int type)
return false;

   e->rank = p->rank;
+  e->shape = gfc_copy_shape (p->shape, p->rank);

   if (e->ts.type == BT_CHARACTER && p->ts.u.cl)
e->ts = p->ts;

[Bug middle-end/103031] New: [12 Regression] Missing static initializer folding with -frounding-math

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

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

Bug ID: 103031
   Summary: [12 Regression] Missing static initializer folding
with -frounding-math
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

One of the recent fixes to avoid inappropriate constant folding with
-frounding-math caused the following test to produce an error when building
with -frounding-math.  Static initializers in C are evaluated at translation
time, in the default rounding mode and with exceptions discarded;
-frounding-math should not affect this.  Indeed, fold-const.c has
START_FOLD_INIT and END_FOLD_INIT that are supposed to be used for static
initializer folding to implement this, but apparently aren't being effective in
this case.

Test case:

double x = -1ULL;

Errors:

t.c:1:12: error: initializer element is not computable at load time
1 | double x = -1ULL;
  |^

Note: if the initializer is cast to double, things work fine; it's only the
case of implicit conversion that has the problem, so maybe something is handled
differently for folding an implicit conversion of a static initializer.

This breaks building glibc tests for some platforms:
https://sourceware.org/pipermail/libc-alpha/2021-October/132475.html