[Bug tree-optimization/102058] [12 regression] 450.soplex regressed on x86_64 with -Ofast -march=generic (by 8-15%)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug libstdc++/102962] shared locks / mutexes differ between linux and windows

[Marco.Mengelkoch1 at ibm dot com via Gcc-bugs]

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

--- Comment #2 from Marco Mengelkoch  ---
> No, that's not a safe assumption at all. Libstdc++ uses the platform's 
> pthread types, it doesn't define them itself.

I would understand if just the order is different or if one is much faster than
the other. But on linux, this example code waits for an unlimited amount of
time, while it finishes quickly on windows. And it still looks like the code is
valid.

To make it work as on windows, I would need an additional unique lock.

While I would prefer the behavior of windows, it seems that the documentation
doesn't look accurate for windows

> // https://en.cppreference.com/w/cpp/thread/shared_mutex
> If one thread has acquired the shared lock (through lock_shared, 
> try_lock_shared), no other thread can acquire the exclusive lock, but can 
> acquire the shared lock.

On windows, no shared lock can be acquired anymore once a UniqueLock requested
a lock.

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

[c25devbiz at aol dot com via Gcc-bugs]

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

--- Comment #2 from c25devbiz at aol dot com ---
i686-linux-gnu
if change c_f to long double and use llf, brings c_f down and brings c down to
b

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

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

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

--- Comment #3 from luoxhu at gcc dot gnu.org ---
This hack could restore the previous phi order to put nondfs phi args before
dfs_edge args.  But I am not sure whether this is the correct direction.  At
least  it proves that the phi order matters for later vectorizer code.


diff --git a/gcc/cfgloopmanip.c b/gcc/cfgloopmanip.c
index 455c3ef8db9..2ca256c15fa 100644
--- a/gcc/cfgloopmanip.c
+++ b/gcc/cfgloopmanip.c
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimplify-me.h"
 #include "tree-ssa-loop-manip.h"
 #include "dumpfile.h"
+#include "ssa.h"

 static void copy_loops_to (class loop **, int,
   class loop *);
@@ -1577,6 +1578,41 @@ lv_adjust_loop_entry_edge (basic_block first_head,
basic_block second_head,
   e1->probability = then_prob;
   e->probability = else_prob;

+  edge le, dfs = NULL, nondfs = NULL;
+  edge_iterator ei;
+
+  if (EDGE_COUNT (e1->dest->preds) > 1)
+  {
+FOR_EACH_EDGE (le, ei, e1->dest->preds)
+  {
+   if (le->flags & EDGE_DFS_BACK)
+ dfs = le;
+   else
+ nondfs = le;
+  }
+if (dfs && nondfs && dfs->dest_idx < nondfs->dest_idx)
+  {
+   gphi_iterator psi;
+   gphi *phi;
+   tree dfsdef, nondfsdef;
+   for (psi = gsi_start_phis (e1->dest); !gsi_end_p (psi); gsi_next
(&psi))
+ {
+   phi = psi.phi ();
+   dfsdef = PHI_ARG_DEF (phi, dfs->dest_idx);
+   nondfsdef = PHI_ARG_DEF (phi, nondfs->dest_idx);
+   SET_PHI_ARG_DEF (phi, dfs->dest_idx, nondfsdef);
+   SET_PHI_ARG_DEF (phi, nondfs->dest_idx, dfsdef);
+ }
+
+   EDGE_PRED (e1->dest, dfs->dest_idx) = nondfs;
+   EDGE_PRED (e1->dest, nondfs->dest_idx) = dfs;
+
+   unsigned int temp = nondfs->dest_idx;
+   nondfs->dest_idx = dfs->dest_idx;
+   dfs->dest_idx = temp;
+  }
+  }
+

[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
   Severity|normal  |trivial
 CC||rearnsha at arm dot com

--- Comment #2 from Eric Gallager  ---
git blame says it's been there since Richard Earnshaw first committed the file
in g:743d4d8; cc-ing him

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

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

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org,
   ||rguenther at suse dot de

--- Comment #2 from luoxhu at gcc dot gnu.org ---
Confirmed.

P7's extra option -mno-allow-movmisalign makes this ICE happens.  If add this
option on P9 also ICEs. Reason is the phi arguments order changes if switch the
sequence of loopify and lv_adjust_loop_entry_edge.

the constant input argument from bb 18 is in phi index 1 now makes the followed
vectorize code fail to handle?

if (_42 != 0)
  goto ; [80.00%]
else
  goto ; [20.00%]

 [local count: 67276368]:

 [local count: 611603351]:
# i_76 = PHI  // here
# y_lsm.6_74 = PHI <_61(10), 0.0(18)>  // here
# w_lsm.7_73 = PHI <_58(10), 0.0(18)>  // here
i.0_72 = (unsigned int) i_76;
_70 = (long unsigned int) i.0_72;
_69 = _70 * 80;
x_68 = r_22(D) + _69;
fpred_67 = x_68->f_pred;
fexp_66 = x_68->f_exp;
tem_65 = fpred_67 - fexp_66;
_64 = x_68->f_sigma;
_63 = tem_65 / _64;
_62 = ABS_EXPR <_63>;
_61 = _62 + y_lsm.6_74;
_60 = tem_65 / fexp_66;
_59 = ABS_EXPR <_60>;
_58 = _59 + w_lsm.7_73;
i_57 = i_76 + 1;
if (n_19(D) > i_57)
  goto ; [89.00%]
else
  goto ; [11.00%]

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



It was:


if (_42 != 0)
  goto ; [80.00%]
else
  goto ; [20.00%]

 [local count: 67276368]:

 [local count: 611603351]:
# i_76 = PHI <1(18), i_57(10)>   
# y_lsm.6_74 = PHI <0.0(18), _61(10)>
# w_lsm.7_73 = PHI <0.0(18), _58(10)>
i.0_72 = (unsigned int) i_76;
_70 = (long unsigned int) i.0_72;
_69 = _70 * 80;
x_68 = r_22(D) + _69;
fpred_67 = x_68->f_pred;
fexp_66 = x_68->f_exp;
tem_65 = fpred_67 - fexp_66;
_64 = x_68->f_sigma;
_63 = tem_65 / _64;
_62 = ABS_EXPR <_63>;
_61 = _62 + y_lsm.6_74;
_60 = tem_65 / fexp_66;
_59 = ABS_EXPR <_60>;
_58 = _59 + w_lsm.7_73;
i_57 = i_76 + 1;
if (n_19(D) > i_57)
  goto ; [89.00%]
else
  goto ; [11.00%]

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


The comments in function gimple_lv_adjust_loop_header_phi says 

  /* Browse all 'second' basic block phi nodes and add phi args to
 edge 'e' for 'first' head. PHI args are always in correct order.  */ 

Any function to fix the phi order?

[Bug libstdc++/102912] [12 Regression] Not full support of const arguments in std::variant

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||11.2.1
Summary|Not full support of const   |[12 Regression] Not full
   |arguments in std::variant   |support of const arguments
   ||in std::variant
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |12.0
 Status|NEW |ASSIGNED

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

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

--- Comment #8 from Jonathan Wakely  ---
Done.

[Bug middle-end/103036] incorrect #pragma GCC diagnostic suppression for macro expansion and -Wuninitialized

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||24639
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90400

--- Comment #1 from Martin Sebor  ---
See also pr90400 which is about using a _Pragma to suppress
-Wmaybe-uninitialized in macros.  Removing the linemap_resolve_location() calls
from tree-ssa-uninit.c isn't enough to fix that bug but it's prerequisite for a
consistent behavior for the suppression of all warnings.


Referenced Bugs:

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

gcc-bugs@gcc.gnu.org

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

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

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

https://gcc.gnu.org/g:09bc98098e4ad474d2ba9da52457b29bbd08874b

commit r12-4833-g09bc98098e4ad474d2ba9da52457b29bbd08874b
Author: Jonathan Wakely 
Date:   Mon Nov 1 11:32:39 2021 +

libstdc++: Reorder constraints on std::span::span(Range&&) constructor.

In PR libstdc++/103013 Tim Song pointed out that we could reorder the
constraints of this constructor. That's worth doing just to reduce the
work the compiler has to do during overload resolution, even if it isn't
needed to make the code in the PR work.

libstdc++-v3/ChangeLog:

* include/std/span (span(Range&&)): Reorder constraints.

[Bug middle-end/103036] New: incorrect #pragma GCC diagnostic suppression for macro expansion and -Wuninitialized

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

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

Bug ID: 103036
   Summary: incorrect #pragma GCC diagnostic suppression for macro
expansion and -Wuninitialized
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The test case below shows that suppressing -Wuninitialized by #pragma GCC
diagnostic doesn't work the same as it does for other warnings (-Wrray-bounds
in this instance, but most other warnings behave like it).  This makes it
difficult for users to control -Wuninitialized (and -Wmaybe-uninitialized),
compounding their frustration when they run into one of its false positives.

The reason for the difference is that tree-ssa-uninit.c calls
linemap_resolve_location (line_table, location, LRK_SPELLING_LOCATION, NULL)
before using location, which other warnings don't do.  The call was introduced
in r186971 along with a test for its effect, gcc.dg/cpp/pragma-diagnostic-2.c,
with the goal to improve the macro expansion output printed by GCC with
-ftrack-macro-expansion as well as its interaction with on #pragma GCC
diagnostic.  It seems to me that the change was ill thought out: I can think of
no reason why -Wunitialized should be treated differently from all other
warnings.

$ cat a.c && gcc -O2 -S -Wall -Werror a.c
#define X(i) f (a[i]);

int f (int);

int g (void)
{
  int a[3];
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wuninitialized"
  return X (1);
#pragma GCC diagnostic pop
}

int h (void)
{
  int a[] = { 1, 2, 3 };
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Warray-bounds"
  return X (3);
#pragma GCC diagnostic pop
}
a.c: In function ‘g’:
a.c:1:14: error: ‘a’ is used uninitialized [-Werror=uninitialized]
1 | #define X(i) f (a[i]);
  |  ^~~~
a.c:10:10: note: in expansion of macro ‘X’
   10 |   return X (1);
  |  ^
a.c:7:7: note: ‘a’ declared here
7 |   int a[3];
  |   ^
a.c: In function ‘h’:
a.c:1:14: warning: array subscript 3 is above array bounds of ‘int[3]’
[-Warray-bounds]
1 | #define X(i) f (a[i]);
  |  ^~~~
a.c:19:10: note: in expansion of macro ‘X’
   19 |   return X (3);
  |  ^
a.c:16:7: note: while referencing ‘a’
   16 |   int a[] = { 1, 2, 3 };
  |   ^
cc1: all warnings being treated as errors

[Bug tree-optimization/95916] [11 Regression] ICE during GIMPLE pass: slp : verify_ssa failed

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

Vsevolod Livinskiy  changed:

   What|Removed |Added

 Blocks||103035

--- Comment #6 from Richard Biener  ---
*** Bug 95987 has been marked as a duplicate of this bug. ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
[Bug 103035] [meta-bug] YARPGen bugs

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

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Bug ID: 103035
   Summary: [meta-bug] YARPGen bugs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

This is a meta-bug that is supposed to keep track of bugs that were found with
YARPGen (https://github.com/intel/yarpgen).

YARPGen is a random program generator, which produces correct runnable C/C++.
We use it to fuzz GCC and other compilers.

Special thanks to Martin Liška for submitting some of them.

If you use YARPGen to report a bug, please add it to this meta-bug.

[Bug libgcc/103034] New: implement multiply with overflow (__muloti4/__mulodi4/__mulosi4)

[ndesaulniers at google dot com via Gcc-bugs]

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

Bug ID: 103034
   Summary: implement multiply with overflow
(__muloti4/__mulodi4/__mulosi4)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndesaulniers at google dot com
  Target Milestone: ---

LLVM's compiler-rt has support for 3 functions for doing multiplication with
overflow checks (__muloti4/__mulodi4/__mulosi4); libcalls to these were emitted
generally when doing multiplication with operands larger than the target's word
size with UBSAN enabled, or via calls to __builtin_mul_overflow().  These seem
to be a pretty potentially a win for code size.

Unfortunately, I had to scale back LLVM's codegen from emitting libcalls to
these; clang doesn't always use LLVM's compiler-rt for many platforms and
targets, so these libcalls are a bit of a portability mess ATM as they do not
exist in libgcc.

For example:
__int128_t a;
int main (void) {
  a = a * a;
  return 0;
}
compiled with -O2 -fsanitize=undefined comes out to about:
gcc-11: 41 instructions
clang-13: 36 instructions
clang-14: 73 instructions

They're generally useful and might be handy for libgcc to implement (then gcc
to implement libcalls to).

The implementations and tests for LLVM can be found in:
compiler-rt/lib/builtins/mulo{tds}i4.c
compiler-rt/lib/builtins/int_mulo_impl.inc
compiler-rt/test/builtins/Unit/mulo{tds}_test.c

[Bug c/63272] GCC should warn when using pointer to dead scoped variable within the same function

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||msebor at gcc dot gnu.org
   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583045.html

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

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

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

--- Comment #1 from Andrew Pinski  ---
You should be able to hit this without -fharden-conditional-branches

Try something like:

unsigned char x;
int foo(void)
{
  unsigned long long i = x;
  i = i + 0x8000;
  unsigned long long t = 0x;
  unsigned long long tt, ii;
  asm("":"=g"(tt):"g"(t));
  asm("":"=g"(ii):"g"(i));
  if (i > t) {
if ((ii <= tt))  __builtin_trap();
return x;
 } else if (!(ii <= tt))  __builtin_trap();
  return 0;
}

[Bug tree-optimization/103033] New: [12 regression] c-c++-common/auto-init-4.c ICEs starting with r12-4829

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

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

Bug ID: 103033
   Summary: [12 regression] c-c++-common/auto-init-4.c ICEs
starting with r12-4829
   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:429e3b7d8bf6609ddf7c7b1e49244997e9ac76b8, r12-4829

make  -k check-gcc RUNTESTFLAGS="dg.exp=c-c++-common/auto-init-4.c"
FAIL: c-c++-common/auto-init-4.c  -Wc++-compat  (internal compiler error)
FAIL: c-c++-common/auto-init-4.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/auto-init-4.c  -std=gnu++98 (internal compiler error)
FAIL: c-c++-common/auto-init-4.c  -std=gnu++98 (test for excess errors)
FAIL: c-c++-common/auto-init-4.c  -std=gnu++14 (internal compiler error)
FAIL: c-c++-common/auto-init-4.c  -std=gnu++14 (test for excess errors)
FAIL: c-c++-common/auto-init-4.c  -std=gnu++17 (internal compiler error)
FAIL: c-c++-common/auto-init-4.c  -std=gnu++17 (test for excess errors)
FAIL: c-c++-common/auto-init-4.c  -std=gnu++2a (internal compiler error)
FAIL: c-c++-common/auto-init-4.c  -std=gnu++2a (test for excess errors)


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/c-c++-common/auto-init-4.c
-fdiagnostics-plain-output -Wc++-compat -ftrivial-auto-var-init=pattern
-fdump-tree-gimple -S -o auto-init-4.s
during RTL pass: expand
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/auto-init-4.c: In
function 'foo':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/auto-init-4.c:11:15:
internal compiler error: Segmentation fault
0x10bd8533 crash_signal
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:322
0x10687390 location_wrapper_p(tree_node const*)
/home/seurer/gcc/git/gcc-test/gcc/tree.h:4136
0x10687390 tree_strip_any_location_wrapper(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/tree.h:4148
0x10687390 operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
/home/seurer/gcc/git/gcc-test/gcc/fold-const.c:2969
0x10682e33 operand_compare::verify_hash_value(tree_node const*, tree_node
const*, unsigned int, bool*)
/home/seurer/gcc/git/gcc-test/gcc/fold-const.c:3956
0x106875ff operand_compare::verify_hash_value(tree_node const*, tree_node
const*, unsigned int, bool*)
/home/seurer/gcc/git/gcc-test/gcc/tree.h:4149
0x106875ff operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
/home/seurer/gcc/git/gcc-test/gcc/fold-const.c:2965
0x106638cf expand_assignment(tree_node*, tree_node*, bool)
/home/seurer/gcc/git/gcc-test/gcc/expr.c:5366
0x10809b4f expand_DEFERRED_INIT
/home/seurer/gcc/git/gcc-test/gcc/internal-fn.c:3101
0x10810c4b expand_internal_call(internal_fn, gcall*)
/home/seurer/gcc/git/gcc-test/gcc/internal-fn.c:4220
0x10810c4b expand_internal_call(gcall*)
/home/seurer/gcc/git/gcc-test/gcc/internal-fn.c:4228
0x1048c2a7 expand_call_stmt
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:2749
0x1048c2a7 expand_gimple_stmt_1
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:3876
0x1048c2a7 expand_gimple_stmt
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:4040
0x10494dab expand_gimple_basic_block
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:6085
0x10497d47 execute
/home/seurer/gcc/git/gcc-test/gcc/cfgexpand.c:6811
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


commit 429e3b7d8bf6609ddf7c7b1e49244997e9ac76b8 (HEAD, refs/bisect/bad)
Author: Oracle Public Cloud User

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

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

[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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-November/056914.html

[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header

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

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

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
> (In reply to kargl from comment #7)
> > diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> 
> The patch unfortunately seems incomplete.  It fails when using IMPLICIT NONE
> or -fimplicit-none with:
> 
> pr78219.f90:3:30:
> 
> 3 |   forall (integer(kind=4) :: i = 1:10)
>   |  1
> Error: Symbol 'i' at (1) has no IMPLICIT type
> 
> and similarly for pr102371.

https://gcc.gnu.org/pipermail/gcc-bugs/2021-September/757723.html

[Bug c++/98936] [DR1734] Incorrect computation of trivially copyable for class with user-declared move assignment operator, defined as deleted

[roland at rschulz dot eu via Gcc-bugs]

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

Roland Schulz  changed:

   What|Removed |Added

 CC||roland at rschulz dot eu

--- Comment #2 from Roland Schulz  ---
This might be a duplicate of #96288 .

[Bug analyzer/103032] New: false positive diagnostic from -fanalyzer about double-free

[rhialto at falu dot nl via Gcc-bugs]

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

Bug ID: 103032
   Summary: false positive diagnostic from -fanalyzer about
double-free
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: rhialto at falu dot nl
  Target Milestone: ---

Created attachment 51719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51719&action=edit
the preprocessed source file

gcc 10.3.0's -fanalyze produces diagnostics about double-frees that look
incorrect to me. Maybe they are correct but if so, the message doesn't
convince me at all.

Instead the message makes me suspect that gcc thinks the loop variable i
doesn't change through the loop. And if it doesn't do that, this makes
me doubt if the generated code is even correct.

Expected behaviour: either no diagnostic, or one that convinces me there
is an actual problem with the program.

Command line invocation:

/usr/pkg/gcc10/bin/gcc --v std=gnu99 -Wall -Wshadow -Wextra -pedantic
-Woverflow -Wstrict-overflow -ggdb -fanalyzer -O3 -DDEFAULT_OBJECTFORMAT_RT11=0
-save-temps -c -o dumpobj.o dumpobj.c


Script started on Mon Nov  1 21:43:37 2021
$ /usr/pkg/gcc10/bin/gcc -v -std=gnu99 -Wall -Wshadow -Wextra -pedantic
-Woverflow -Wstrict-overflow -ggdb -fanalyzer -O3 -DDEFAULT_OBJECTFORMAT_RT11=0
-save-temps -c -o dumpobj.o dumpobj.c
[?2004lUsing built-in specs.
COLLECT_GCC=/usr/pkg/gcc10/bin/gcc
Target: x86_64--netbsd
Configured with: ../gcc-10.3.0/configure --disable-libstdcxx-pch --enable-nls
--with-libiconv-prefix=/usr --enable-__cxa_atexit
--with-gxx-include-dir=/usr/pkg/gcc10/include/c++/ --disable-libssp
--enable-languages='c obj-c++ objc fortran c++' --enable-shared
--enable-long-long --with-local-prefix=/usr/pkg/gcc10 --enable-threads=posix
--with-boot-ldflags='-static-libstdc++ -static-libgcc
-Wl,-R/usr/pkg/gcc8/lib/gcc/x86_64--netbsd/8.4.0 -Wl,-R/usr/pkg/lib  '
--with-system-zlib --without-zstd --with-arch=nocona --with-tune=nocona
--with-fpmath=sse --with-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as
--with-as=/usr/bin/as --prefix=/usr/pkg/gcc10 --build=x86_64--netbsd
--host=x86_64--netbsd --infodir=/usr/pkg/gcc10/info --mandir=/usr/pkg/gcc10/man
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=gnu99' '-Wall' '-Wshadow' '-Wextra' '-Wpedantic'
'-Woverflow' '-Wstrict-overflow' '-ggdb' '-fanalyzer' '-O3' '-D'
'DEFAULT_OBJECTFORMAT_RT11=0' '-save-temps' '-c' '-o' 'dumpobj.o'
'-mtune=nocona' '-march=nocona'
 /usr/pkg/gcc10/libexec/gcc/x86_64--netbsd/10.3.0/cc1 -E -quiet -v -D
DEFAULT_OBJECTFORMAT_RT11=0 dumpobj.c -mtune=nocona -march=nocona -std=gnu99
-Wall -Wshadow -Wextra -Wpedantic -Woverflow -Wstrict-overflow -fanalyzer -ggdb
-fworking-directory -O3 -fpch-preprocess -o dumpobj.i
ignoring nonexistent directory
"/usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.3.0/../../../../x86_64--netbsd/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.3.0/include
 /usr/pkg/gcc10/include
 /usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.3.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-std=gnu99' '-Wall' '-Wshadow' '-Wextra' '-Wpedantic'
'-Woverflow' '-Wstrict-overflow' '-ggdb' '-fanalyzer' '-O3' '-D'
'DEFAULT_OBJECTFORMAT_RT11=0' '-save-temps' '-c' '-o' 'dumpobj.o'
'-mtune=nocona' '-march=nocona'
 /usr/pkg/gcc10/libexec/gcc/x86_64--netbsd/10.3.0/cc1 -fpreprocessed dumpobj.i
-quiet -dumpbase dumpobj.c -mtune=nocona -march=nocona -auxbase-strip dumpobj.o
-ggdb -O3 -Wall -Wshadow -Wextra -Wpedantic -Woverflow -Wstrict-overflow
-std=gnu99 -version -fanalyzer -o dumpobj.s
GNU C99 (GCC) version 10.3.0 (x86_64--netbsd)
compiled by GNU C version 10.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C99 (GCC) version 10.3.0 (x86_64--netbsd)
compiled by GNU C version 10.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: edfbc059e6267e32b59f120c0ada0d16
[01m[Kdumpobj.c:[m[K In function '[01m[Kgot_endgsd.part.0[m[K':
[01m[Kdumpobj.c:428:9:[m[K [01;35m[Kwarning:
[m[Kdouble-'[01m[Kfree[m[K' of '[01m[K[m[K'
[[01;35m[K]8;;https://cwe.mitre.org/data/definitions/415.htmlCWE-415]8;;[m[K]
[[01;35m[K]8;;https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-double-free-Wanalyzer-double-free]8;;[m[K]
  428 | [01;35m[Kfree(all_gsds[i])[m[K;
  | [01;35m[K^[m[K
  '[01m[Kgot_endgsd[m[K': events 1-3
[01;36m[K|[m[K
[01;36m[K|[m[K[01m[Kdumpobj.c:409:6:[m[K
[01;36m[K|[m[K  409 | void [01;36m[Kgot_

[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 #2 from David Malcolm  ---
Initial version of patch posted for discussion to:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583039.html

[Bug tree-optimization/103024] ICE in execute, at gimple-harden-conditionals.cc:424 with -fnon-call-exceptions -fharden-compares -fsignaling-nans

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

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

--- Comment #1 from Andrew Pinski  ---
Yes with -fnon-call-exceptions and -fsignaling-nans conditionals can (and
might) throw an exception.  Maybe a sorry early during option processing should
happen and turn off hardening of condtionals.

[Bug target/103009] [9 only] Weakness in stack-protector with no-pie active on ARM.

[sylw.bar at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Sylwester Baranski  ---
OK. Thank you for connecting those problems.
Sylwester

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|12.0|---

[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison

[sylw.bar at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Sylwester Baranski  ---
(In reply to Andrew Pinski from comment #9)
> *** Bug 103009 has been marked as a duplicate of this bug. ***

OK. Thank you for connecting those problems.
Sylwester

[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

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 9.5, 10.4 and 11.3

[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 #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:12f7864eff882cba2720d8871d8b136bd7a1d3cd

commit r9-9807-g12f7864eff882cba2720d8871d8b136bd7a1d3cd
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.
* 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 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 #26 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #25)
> (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.

I added to the openradars site here:
https://openradar.appspot.com/FB9733712
(that doesn't make any difference to visibility of if/when it will be fixed, of
course)

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96862
   Keywords||rejects-valid

--- Comment #1 from Andrew Pinski  ---
The C++ front-end was changed to support this via PR 96862.

[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

[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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 #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 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 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 #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 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 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 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 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 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

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

[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 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 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] 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] 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 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 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 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 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/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/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 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 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 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 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 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

[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 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/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 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 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 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 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 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 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 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 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 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.

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 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.

[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||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 #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 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 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 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 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 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 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 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 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] 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.