[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #2)
> The backwards threader discovers the threads, but refuses to optimize them
> because it thinks doing so will create an irreducible loop without enough
> benefit.

The reason is now:

Checking profitability of path (backwards):  bb:3 (2 insns) bb:7 (4 insns) bb:6
(1 insns) (latch) bb:5
  Control statement insns: 2
  Overall: 5 insns

 Registering value_relation (path_oracle) (j_17 < m_23(D)) (root: bb5)
path: 5->6->7->3->xx REJECTED (unreachable)

it seems the path oracle is confused here.


   [local count: 955630225]:
  if (running_14 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112]:
  _1 = (long unsigned int) i_16;
  _2 = _1 * 4;
  _3 = p_25(D) + _2;
  _4 = *_3;
  _5 = (long unsigned int) j_17;
  _6 = _5 * 4;
  _7 = q_26(D) + _6;
  _8 = *_7;
  _9 = _4 * _8;
  sum_27 = _9 + sum_11;
  if (sum_27 > 1)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 238907556]:

   [local count: 955630225]:
  # sum_10 = PHI 
  # running_13 = PHI <0(3), 0(5), 1(4)>
  j_28 = j_17 + 1;

   [local count: 1073741824]:
  # sum_11 = PHI 
  # running_14 = PHI 
  # j_17 = PHI <0(11), j_28(6)>
  if (j_17 < m_23(D))
goto ; [89.00%]
  else
goto ; [11.00%]

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #6 from Kewen Lin  ---
It's certainly an issue reported here, for one complete fix I did some more
investigation how the option -ftrapping-math affects things, from what LLVM
generates, it looks to me that:
  1) with -ftrapping-math, we can assume fp operations can raise exceptions
(user visible as doc said), here __builtin_isnan should not raise exception
even for sNaN, so it uses vector int instructions instead.
  2) while with -fno-trapping-math, we can assume fp operations can't raise
exceptions, and as doc said "This option requires that -fno-signaling-nans be
in effect", so there is no sNaN at all, safe to use vector fp instructions
which don't trap for qNaN.

It's concluded that __builtin_isnan is supposed not to trap even if the given
value is sNaN.

But with one simple scalar version of case with __builtin_isnan, I don't see
GCC honor -ftrapping-math from the code generated on both Power and aarch64:


#define _GNU_SOURCE
#include "math.h"

int func(double x)
{
  return __builtin_isnan (x);
}


w/ -ftrapping-math or -fno-trapping-math, it gets the same insns like:

aarch64:
fcmpd0, d0
csetw0, vs
ret

ppc64le:
fcmpu 0,1,1
mfcr 3,128
rlwinm 3,3,4,1

Both fcmpu and fcmp would trap for sNaN, is it expected with the current GCC
implementation?

Tested with compiler explorer, I saw LLVM generates insns without fcmpu on
Power, like:

mffprd  4, 1
li 3, 2047
rldic 3, 3, 52, 1
clrldi  4, 4, 1
subc4, 3, 4
subfe 3, 3, 3
neg 3, 3
blr

though I did still see LLVM uses fcmp on aarch64 (maybe a warning saying
"overriding currently unsupported use of floating point exceptions on this
target" can explain it).

Another question in mind is that I saw GCC lowed __builtin_isnan with tree code
UNORDERED_EXPR, does it mean that UNORDERED_EXPR has the same semantic as 
what's concluded for __builtin_isnan above (that is not to trap for both qNaN
and sNaN)? It seems internal documentation doesn't say much on this.

[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops

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

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

--- Comment #4 from Richard Biener  ---
It's

edge
back_threader::maybe_register_path (back_threader_profitability &profit)
{
  edge taken_edge = find_taken_edge (m_path);

  if (taken_edge && taken_edge != UNREACHABLE_EDGE)
{
  if (m_visited_bbs.contains (taken_edge->dest))
{
  // Avoid circular paths by indicating there is nothing to
  // see in this direction.
  taken_edge = UNREACHABLE_EDGE;

not sure why though?  If we remove the above we get

Checking profitability of path (backwards):  bb:3 (2 insns) bb:7 (4 insns) bb:6
(1 insns) (latch) bb:5
  Control statement insns: 2
  Overall: 5 insns

 Registering value_relation (path_oracle) (j_17 < m_23(D)) (root: bb5)
Checking profitability of path (backwards):
Path crosses loop header but does not exit it:   Cancelling jump thread: (5, 6)
incoming edge;  (6, 7) normal (back) (7, 3) normal (3, 6) nocopy;

path: 5->6->7->3->xx REJECTED

so we refuse the thread because .. well, not exactly sure why.
r12-4526-gd8edfadfc7a979 added

+  if (crossed_loop_header)
+{
+  cancel_thread (&path, "Path crosses loop header but does not exit it");
+  return true;
+}

>From the look we want to avoid creating sub-loops here and that's indeed
what would happen here if we elide this.  It also makes the loop have two
exits instead of one and one jump thread is still not done but we eventually
get to do the desired simplification.

diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc
index 2a8cfa3ee01..31c3eef9bb3 100644
--- a/gcc/tree-ssa-threadbackward.cc
+++ b/gcc/tree-ssa-threadbackward.cc
@@ -249,7 +249,7 @@ back_threader::maybe_register_path
(back_threader_profitabil
ity &profit)

   if (taken_edge && taken_edge != UNREACHABLE_EDGE)
 {
-  if (m_visited_bbs.contains (taken_edge->dest))
+  if (0 && m_visited_bbs.contains (taken_edge->dest))
{
  // Avoid circular paths by indicating there is nothing to
  // see in this direction.
diff --git a/gcc/tree-ssa-threadupdate.cc b/gcc/tree-ssa-threadupdate.cc
index 59c268a3567..14df3ee42a7 100644
--- a/gcc/tree-ssa-threadupdate.cc
+++ b/gcc/tree-ssa-threadupdate.cc
@@ -2765,7 +2765,6 @@ jt_path_registry::cancel_invalid_paths
(vec &path)
   bool seen_latch = false;
   int loops_crossed = 0;
   bool crossed_latch = false;
-  bool crossed_loop_header = false;
   // Use ->dest here instead of ->src to ignore the first block.  The
   // first block is allowed to be in a different loop, since it'll be
   // redirected.  See similar comment in profitable_path_p: "we don't
@@ -2799,14 +2798,6 @@ jt_path_registry::cancel_invalid_paths
(vec &path)
  ++loops_crossed;
}

-  // ?? Avoid threading through loop headers that remain in the
-  // loop, as such threadings tend to create sub-loops which
-  // _might_ be OK ??.
-  if (e->dest->loop_father->header == e->dest
- && !flow_loop_nested_p (exit->dest->loop_father,
- e->dest->loop_father))
-   crossed_loop_header = true;
-
   if (flag_checking && !m_backedge_threads)
gcc_assert ((path[i]->e->flags & EDGE_DFS_BACK) == 0);
 }
@@ -2842,11 +2833,6 @@ jt_path_registry::cancel_invalid_paths
(vec &path)
   cancel_thread (&path, "Path rotates loop");
   return true;
 }
-  if (crossed_loop_header)
-{
-  cancel_thread (&path, "Path crosses loop header but does not exit it");
-  return true;
-}
   return false;
 }

[Bug debug/95414] Wrong debug info for argc at -O2

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Known to fail||10.3.0, 11.2.0
  Known to work||10.4.0, 11.3.0, 12.1.0

--- Comment #2 from Richard Biener  ---
Even GCC 10.4.0 now prints , so fixed (possibly a dup).

[Bug target/107581] ICE on sparc-leon-uclibc during go build

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

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

--- Comment #4 from Marc Poulhiès  ---
You're correct, builtin_decl_explicit returns NULL.

As for the lib and fcode:

8186  {
8187enum built_in_function lib;
8188mode = get_builtin_sync_mode (fcode -
BUILT_IN_ATOMIC_ADD_FETCH_1);
8189lib = (enum built_in_function)((int)BUILT_IN_ATOMIC_FETCH_ADD_1
+ 
8190   (fcode -
BUILT_IN_ATOMIC_ADD_FETCH_1));
> 8191  target = expand_builtin_atomic_fetch_op (mode, exp, target, 
> PLUS, true,
8192 ignore, lib);
8193if (target)
8194  return target;
8195break;
(rr) p lib
$8 = BUILT_IN_ATOMIC_FETCH_ADD_4
(rr) p fcode
$9 = BUILT_IN_ATOMIC_ADD_FETCH_4

Let me know if I can do anything else to help.

[Bug target/107568] Bootstrap failure on macOS 12.6 (monterey)

[sam at gentoo dot org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #4 from Sam James  ---
See also Iain's bug at https://github.com/iains/gcc-darwin-arm64/issues/98.

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Kewen Lin from comment #6)
> It's certainly an issue reported here, for one complete fix I did some more
> investigation how the option -ftrapping-math affects things, from what LLVM
> generates, it looks to me that:
>   1) with -ftrapping-math, we can assume fp operations can raise exceptions
> (user visible as doc said), here __builtin_isnan should not raise exception
> even for sNaN, so it uses vector int instructions instead.
>   2) while with -fno-trapping-math, we can assume fp operations can't raise
> exceptions, and as doc said "This option requires that -fno-signaling-nans
> be in effect", so there is no sNaN at all, safe to use vector fp
> instructions which don't trap for qNaN.
> 
> It's concluded that __builtin_isnan is supposed not to trap even if the
> given value is sNaN.
> 
> But with one simple scalar version of case with __builtin_isnan, I don't see
> GCC honor -ftrapping-math from the code generated on both Power and aarch64:
> 
> 
> #define _GNU_SOURCE
> #include "math.h"
> 
> int func(double x)
> {
>   return __builtin_isnan (x);
> }
> 
> 
> w/ -ftrapping-math or -fno-trapping-math, it gets the same insns like:
> 
> aarch64:
> fcmpd0, d0
> csetw0, vs
> ret
> 
> ppc64le:
> fcmpu 0,1,1
> mfcr 3,128
> rlwinm 3,3,4,1
> 
> Both fcmpu and fcmp would trap for sNaN, is it expected with the current GCC
> implementation?

But the key is -fsignalling-nans (default off)

> Tested with compiler explorer, I saw LLVM generates insns without fcmpu on
> Power, like:
> 
> mffprd  4, 1
> li 3, 2047
> rldic 3, 3, 52, 1
> clrldi  4, 4, 1
> subc4, 3, 4
> subfe 3, 3, 3
> neg 3, 3
> blr
> 
> though I did still see LLVM uses fcmp on aarch64 (maybe a warning saying
> "overriding currently unsupported use of floating point exceptions on this
> target" can explain it).
> 
> Another question in mind is that I saw GCC lowed __builtin_isnan with tree
> code UNORDERED_EXPR, does it mean that UNORDERED_EXPR has the same semantic
> as  what's concluded for __builtin_isnan above (that is not to trap for both
> qNaN and sNaN)? It seems internal documentation doesn't say much on this.

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

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

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

--- Comment #8 from Kewen Lin  ---
(In reply to Richard Biener from comment #7)
> (In reply to Kewen Lin from comment #6)
> > Both fcmpu and fcmp would trap for sNaN, is it expected with the current GCC
> > implementation?
> 
> But the key is -fsignalling-nans (default off)
> 

Thanks for the hint, but the behaviors don't change with one more explicit
option -fsignalling-nans (before or after the option for trapping-math). I saw
the option description saying "This option is experimental and does not
currently guarantee to disable all GCC optimizations that affect signaling NaN
behavior.", does it mean target codes don't honor it much so far?

[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops

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

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

--- Comment #5 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #4)
> It's
> 
> edge
> back_threader::maybe_register_path (back_threader_profitability &profit)
> {
>   edge taken_edge = find_taken_edge (m_path);
> 
>   if (taken_edge && taken_edge != UNREACHABLE_EDGE)
> {
>   if (m_visited_bbs.contains (taken_edge->dest))
> {
>   // Avoid circular paths by indicating there is nothing to
>   // see in this direction.
>   taken_edge = UNREACHABLE_EDGE;
> 
> not sure why though?  If we remove the above we get

There was a test we were failing because we were threading ircular paths, but
you know more about this than me ;-).  So if there are no regressions, feel
free to nuke it.

[Bug sanitizer/107586] New: gcc trunk missed a stack-buffer-overflow

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 107586
   Summary: gcc trunk missed a stack-buffer-overflow
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, `gcc-tk -fsanitize=address -O2` successfully detected
the buffer-overflow in `memcpy()`. However, I found that when you uncomment the
line `int *f = &e[0]`, the ASAN warning went away.
I checked gcc-9, which detected the error in both cases but not for gcc-10 and
above.

I wonder if this is due to some optimizations going on that change the memory
layout, which disables ASAN's detection in this case.

Compiler explorer: https://godbolt.org/z/zfGv5378a


% cat a.c
struct a
{
int x;
};

void h(struct a *b)
{
struct a c[70];
int i;
for (i = 0; i < 70; i++)
c[i].x = 1;
__builtin_memcpy(b, c, 70*sizeof(struct a));
__builtin_printf("%d\n", b->x);
};
void g()
{
struct a * d = (struct a *)__builtin_alloca(69*sizeof(struct a));
int e[20] ;
// int *f = &e[0];
h(d);
}

int main()
{
g();
return 0;
}

%

[Bug c++/107587] New: Explicit specializations of user-defined deduction guides in unnamed namespaces trigger -Wunused-function

[development at jordi dot vilar.cat via Gcc-bugs]

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

Bug ID: 107587
   Summary: Explicit specializations of user-defined deduction
guides in unnamed namespaces trigger -Wunused-function
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: development at jordi dot vilar.cat
  Target Milestone: ---

After https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53711, functions in unnamed
namespace may trigger -Wunused-function.

Explicit (full) specializations of member functions don't have the `template<>`
prefix. User-defined deduction guides follow the same syntax, and maybe this
confuses the compiler as they trigger -Wunused-function when inside an unnamed
namespace, but (maybe partially specialized) templated user-defined deduction
guides, that is, those with the `template<...>` prefix, don't.

The following valid code compiles cleanly with clang (and even msvc!!!), but
triggers -Wunued-function in gcc-12 (and older) just compiling wit -Wall:

```
template struct X { X(T) {} };
X(bool) -> X;

namespace
{
template struct Y { Y(T) {} };
Y(bool) -> Y;
}

void test()
{
[[maybe_unused]] X x = X{false};
[[maybe_unused]] Y y = Y{false};
}
```


It is demoed in Compiler Explorer: https://godbolt.org/z/rf3zrEzsd.

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

[yangyibiao at nju dot edu.cn via Gcc-bugs]

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

--- Comment #6 from Yibiao Yang  ---
Hi, Richard Biener. 

I updated gcc to the latest trunk version and also found that this bug seems
have been fixed in the following trunk version.

$ gcc --version
gcc (GCC) 13.0.0 20221107 (experimental)

I was wondering whether this bug can be also closed as fixed.

[Bug debug/90586] [gdb] gdb wrongly set the breakpoint as expected

[yangyibiao at nju dot edu.cn via Gcc-bugs]

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

--- Comment #2 from Yibiao Yang  ---
(In reply to Richard Biener from comment #1)
> The reason is that somehow the only stmt with line 9 prevailing is one
> not originally having it:
> 
>:
>   [t.c:11:14] D.1918 = 0;
>   [t.c:11:14] // predicted unlikely by early return (on trees) predictor.
>   [t.c:9:11] g = {CLOBBER};
>   goto ; [INV]
> 
>:
>   [t.c:14:10] D.1918 = 0;
> 
>:
> :
>   return D.1918;
> 
> so the return stmt will end up inheriting it if we are "lucky".  try-finally
> lowering assigns the location, possibly simply taking the location of the
> last stmt from the "throw".

Thanks for the explanation. Thus, I was wondering that this bug should be
marked as "invalid"

[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops

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

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

--- Comment #6 from Richard Biener  ---
I'm testing a patch removing the premature rejection of the cycle in the
backwards threader but will leave the cancellation code for now.

[Bug c/107588] New: Tt

[dieearget at heisei dot be via Gcc-bugs]

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

Bug ID: 107588
   Summary: Tt
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dieearget at heisei dot be
  Target Milestone: ---

Ggg

[Bug c/107588] Tt

[dieearget at heisei dot be via Gcc-bugs]

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

Rolex  changed:

   What|Removed |Added

 CC||dieearget at heisei dot be

--- Comment #1 from Rolex  ---
Created attachment 53859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53859&action=edit
Fuck

Gg

[Bug debug/90584] [gdb] gdb is not stopped at a breakpoint in an executed line of code

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Confirmed fixed with GCC 10.4 and gdb 11.1

[Bug debug/90586] [gdb] gdb wrongly set the breakpoint as expected

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

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

--- Comment #3 from Richard Biener  ---
I think it is a genuine bug

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

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

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

--- Comment #9 from Richard Biener  ---
(In reply to Kewen Lin from comment #8)
> (In reply to Richard Biener from comment #7)
> > (In reply to Kewen Lin from comment #6)
> > > Both fcmpu and fcmp would trap for sNaN, is it expected with the current 
> > > GCC
> > > implementation?
> > 
> > But the key is -fsignalling-nans (default off)
> > 
> 
> Thanks for the hint, but the behaviors don't change with one more explicit
> option -fsignalling-nans (before or after the option for trapping-math). I
> saw the option description saying "This option is experimental and does not
> currently guarantee to disable all GCC optimizations that affect signaling
> NaN behavior.", does it mean target codes don't honor it much so far?

That could be very well the case.

[Bug c/107589] New: [C2x] `-Wold-style-declaration' triggers warning on `const auto'

[pexu--- via Gcc-bugs]

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

Bug ID: 107589
   Summary: [C2x] `-Wold-style-declaration' triggers warning on
`const auto'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Hi.

`-Wold-style-declaration' currently triggers warning when used with C2x `const
auto' (`auto const' is not affected).

Apparently the standard is a bit vague about this case.  Grammar `const auto'
is accepted by LLVM [1].  Also, the corresponding GCC testcases (c2x-auto-1.c
and c2x-auto-2.c) use `const auto' (not `auto const').

Using version `13.0.0 20221109 (experimental)':

# echo 'void f() { const auto x [[maybe_unused]] = 0; }' | gcc -c -xc -std=c2x
-Wold-style-declaration -
: In function 'f':
:1:1: warning: 'auto' is not at beginning of declaration
[-Wold-style-declaration]

[1] https://reviews.llvm.org/D133289

[Bug c/107583] Missing fixit for struct members (e.g. time_t, missing include)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
FWIW it works as expected for C++.

[Bug libstdc++/107538] std::pow(10, std::complex(NaN, 1)) aborts with -D_GLIBCXX_ASSERTIONS

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> #define _GLIBCXX_ASSERTIONS
> #include 
> #include 
> 
> int main()
> {
>   double nan = std::numeric_limits::quiet_NaN();
>   std::pow(10, std::complex(nan, 1));

Actually maybe the assertion is OK. This violates [complex.numbers] p3:

"If the result of a function is not mathematically defined or not in the range
of representable values for its type, the behavior is undefined."

10^(nan + 1i) is not mathematically defined, an assertion seems OK.

If we want to prevent the assertion here we could do:

--- a/libstdc++-v3/include/std/complex
+++ b/libstdc++-v3/include/std/complex
@@ -699,12 +699,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
&& !_GLIBCXX_FAST_MATH>::_S_do_it(__z);
 }

+  template
+inline complex<_Tp>
+__polar(const _Tp& __rho, const _Tp& __theta)
+{ return complex<_Tp>(__rho * cos(__theta), __rho * sin(__theta)); }
+
   template
 inline complex<_Tp>
 polar(const _Tp& __rho, const _Tp& __theta)
 {
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2459. std::polar should require a non-negative rho
   __glibcxx_assert( __rho >= 0 );
-  return complex<_Tp>(__rho * cos(__theta), __rho * sin(__theta));
+  return std::__polar<_Tp>(__rho, __theta);
 }

   template
@@ -778,7 +785,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 inline complex<_Tp>
 __complex_exp(const complex<_Tp>& __z)
-{ return std::polar<_Tp>(exp(__z.real()), __z.imag()); }
+{ return std::__polar<_Tp>(exp(__z.real()), __z.imag()); }

 #if _GLIBCXX_USE_C99_COMPLEX
   inline __complex__ float
@@ -1038,7 +1045,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 return pow(__x.real(), __y);

   complex<_Tp> __t = std::log(__x);
-  return std::polar<_Tp>(exp(__y * __t.real()), __y * __t.imag());
+  return std::__polar<_Tp>(exp(__y * __t.real()), __y * __t.imag());
 }

   template
@@ -1075,8 +1082,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline complex<_Tp>
 pow(const _Tp& __x, const complex<_Tp>& __y)
 {
-  return __x > _Tp() ? std::polar<_Tp>(pow(__x, __y.real()),
-  __y.imag() * log(__x))
+  return __x > _Tp() ? std::__polar<_Tp>(pow(__x, __y.real()),
+__y.imag() * log(__x))
 : std::pow(complex<_Tp>(__x), __y);
 }

[Bug target/107585] [13 Regression] ICE: in decompose, at rtl.h:2288 at -O

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2022-11-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Jakub Jelinek  ---
Created attachment 53860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53860&action=edit
gcc13-pr107585.patch

Untested fix.

[Bug analyzer/99671] RFE: analyzer could complain about ptr derefs that occur before the ptr is checked

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77432
   Last reconfirmed||2022-11-09

--- Comment #1 from David Malcolm  ---
I have a mostly-working -fanalyzer implementation of this.

I now see that PR 77432 tracks implementing this, albeit for the middle-end.

[Bug middle-end/77432] warn about null check after pointer dereference

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #5 from David Malcolm  ---
I hadn't seen this, and I filed PR analyzer/99671 last year to track adding a
-fanalyzer warning for this.  I now have a mostly-working implementation of the
latter which I'm hoping to post for stage 1.

Not sure if these are dupes or not (would we want a non-analyzer implementation
of this warning?)

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #11 from Aldy Hernandez  ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > The cdce case is something I've mentioned today:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605338.html
> > The comparisons in there are artificial and so unlike user comparisons we
> > should (if they were marked somehow) be able to optimize them away if frange
> > can prove their result.
> > But that isn't something happening on the #c0 testcase, is it?
> 
> in vrp2 I see:
> 384  range_of_stmt () at stmt if (_9 u>= 0.0)
> 385range_of_expr(_9) at stmt if (_9 u>= 0.0)
>TRUE : (385) range_of_expr (_9) [frange] double [-0.0
> (-0x0.0p+0), +Inf] +-NAN
>  TRUE : (384) range_of_stmt () [irange] bool VARYING
> 
> so we think that 
> [frange] double [-0.0 (-0x0.0p+0), +Inf] +-NAN  u>=   0.0  does not fold.  
> 
> possibly some signalling NaN thing not allowing us to remove it?

By vrp2 I see:

=== BB 2 
Imports: _6  _8  
Exports: _6  _8  _9  
 _9 : _6(I)  _8(I)  
 [local count: 1073741824]:
_3 = u_2(D)->x;
_6 = _3 * _3;
_7 = u_2(D)->y;
_8 = _7 * _7;
_9 = _6 + _8;
if (_9 u>= 0.0)
  goto ; [99.95%]
else
  goto ; [0.05%]

_9 : [frange] double [-0.0 (-0x0.0p+0), +Inf] +-NAN
2->4  (F) _9 :  [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
2->3  (T) _9 :  [frange] double [-0.0 (-0x0.0p+0), +Inf] +-NAN

We can't fold the u>= 0.0 because that would remove a possible NAN at runtime,
and it would be user-visible for signalling NANs.  At least, that's been my
understanding all along.  You'll notice most of folding of relops in
range-op-float.cc is predicated by !maybe_isnan(op1, op2) to disable them if
NAN is a possibility, which in the case of _9 could happen:

  else if (!maybe_isnan (op1, op2))
{
  if (real_compare (GE_EXPR, &op1.lower_bound (), &op2.upper_bound ()))
r = range_true (type);
  else if (!real_compare (GE_EXPR, &op1.upper_bound (), &op2.lower_bound
()))
r = range_false (type);
  else
r = range_true_and_false (type);
}

However, we should be able to mark that the 2->4 edge as undefined.  For
example, on the 2->4 edge, _9 is technically UNDEFINED.  But we can't do that
because frange's are represented as closed intervals, so we can't represent <
0.0 on the false side.  Instead we represent it as +-0.0 which intersected with
_9 is still +-0.0.

If we could represent < 0.0 with one less ulp, say -0.001 (or
whatever), intersecting that with the known _9 would yield UNDEFINED.  I don't
know if that would help in this PR, but ISTM the threader would be able to do
something (or some other pass??).

Unfortunately, we don't represent < and > very well.  Technically all we would
need is to tweak range-op-float.cc's build_gt() and build_lt() to do
real_nexafter, but as with everything FP, the devil is in the details (what do
we do when we go past the representable range for -ffinite-math-only, etc etc).
 It does seem a bit late in the cycle to fudge with this, but it is possible.

Again, I don't know if this helps the PR, but these are the 2 issues I see.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #12 from Aldy Hernandez  ---
It looks like the code reading from the blob in SSA_NAME_RANGE_INFO and
populating an frange is always leaving the NAN bit toggled even if it wasn't in
the stored range.

Does this help?

diff --git a/gcc/value-range-storage.cc b/gcc/value-range-storage.cc
index 462447ba250..7ba7a16edc2 100644
--- a/gcc/value-range-storage.cc
+++ b/gcc/value-range-storage.cc
@@ -283,6 +283,8 @@ frange_storage_slot::get_frange (frange &r, tree type)
const
   // make sure to set the NAN sign if known.
   if (HONOR_NANS (type) && (m_pos_nan ^ m_neg_nan) == 1)
 r.update_nan (m_neg_nan);
+  else if (!m_pos_nan && !m_neg_nan)
+r.clear_nan ();
 }

 bool

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #13 from Aldy Hernandez  ---
Created attachment 53861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53861&action=edit
preprocessed testcase for comment #2

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Pilar Latiesa  ---
I have tested the testcase in comment #1 with Clang, and I realized that Clang
trunk avoids the tailcall to sqrt even without any hint with
__builtin_unreachable: https://godbolt.org/z/5sb8bYcoq 

Clang is somehow smart enough to realize that dot(u, u) is always non-negative.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #15 from Jakub Jelinek  ---
We don't have multiplication wired in frange, that is something we talked about
today on gcc-patches.

[Bug target/107590] New: __atomic_test_and_set broken on PowerPC

[vital.had at gmail dot com via Gcc-bugs]

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

Bug ID: 107590
   Summary: __atomic_test_and_set broken on PowerPC
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vital.had at gmail dot com
CC: iains at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-apple-darwin

The bug was discovered while trying to build i2pd on Darwin PPC. Build itself
succeeded, but the binary failed with Bus error. I thought it was caused by
Boost, however it turned out that Boost was fine, while Bus error was a result
of broken GCC builtin.

Details here:
https://github.com/PurpleI2P/i2pd/issues/1726#issuecomment-1305536144

In particular, simple spin lock tests fail with Bus error when built with
default usage of GCC atomics. Like this:
https://github.com/boostorg/smart_ptr/blob/develop/test/spinlock_test.cpp

36-87:boost svacchanda$ /opt/local/bin/g++-mp-11 spinlock_test.cpp
-I/opt/local/libexec/boost/1.76/include -L/opt/local/libexec/boost/1.76/lib -o
spinlock_test
36-87:boost svacchanda$ /Users/svacchanda/Dev/boost/spinlock_test 
Bus error
36-87:boost svacchanda$ /opt/local/bin/g++-mp-11 spinlock_test.cpp
-DBOOST_SP_USE_STD_ATOMIC -I/opt/local/libexec/boost/1.76/include
-L/opt/local/libexec/boost/1.76/lib -o spinlock_test
36-87:boost svacchanda$ /Users/svacchanda/Dev/boost/spinlock_test

No error when Boost is forced to use its own atomics instead of GCC builtins.

Boost developer suggested that __atomic_test_and_set is broken on PPC, and GDB
output proved that:

(gdb) run
Starting program: /Users/svacchanda/Dev/boost/a.out 
Reading symbols for shared libraries +++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 259 at address: 0x208d
0x1b2c in boost::detail::spinlock::try_lock (this=0x208d) at
spinlock_gcc_atomic.hpp:39
39  return __atomic_test_and_set( &v_, __ATOMIC_ACQUIRE ) == 0;
(gdb) quit

Same failure confirmed on 10.5.8 and 10.6. gcc11 and gcc7 were tried, likely to
apply to other versions.

GCC output from 10.5.8:

Using built-in specs.
COLLECT_GCC=/opt/local/bin/gcc-mp-11
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/ppc-apple-darwin9/11.3.0/lto-wrapper
Target: ppc-apple-darwin9
Configured with:
/opt/local/var/macports/build/_opt_PPCLeopardPorts_lang_gcc11/gcc11/work/gcc-11.3.0/configure
--prefix=/opt/local --build=ppc-apple-darwin9
--enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc11
--includedir=/opt/local/include/gcc11 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-11
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-11 --with-gxx-include-dir=/opt/local/include/gcc11/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-isl=/opt/local --with-zstd=/opt/local --enable-stage1-checking
--enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-bugurl=https://trac.macports.org/newticket --enable-host-shared
--with-tune-cpu=G5 --disable-tls --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-pkgversion='MacPorts gcc11 11.3.0_1+universal'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (MacPorts gcc11 11.3.0_1+universal)

[Bug tree-optimization/107591] New: range-op{,-float}.cc for x * x

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

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

Bug ID: 107591
   Summary: range-op{,-float}.cc for x * x
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int
foo (int x)
{
  if (x < -13 || x > 26)
return -1;
  return x * x;
}

results in
x_4(D) :  [irange] int [-13, 26]
_5  : [irange] int [-338, 676]
That is unnecessarily pessimized, because it only computes [-13, 26] * [-13,
26]
range without taking into account that both operands are the same.
For the powi (x, 2) case the range is actually [0, 26 * 26], i.e. we shouldn't
do a cross product for it, just compute the -13 * -13, 0 * 0 (if 0 is in the
range) and 26 * 26 products and form from that the range (I admit I haven't
thought about unsigned or wrapping stuff).

On the PR107569 testcase it is on frange:
  _3 = u_2(D)->x;
  _6 = _3 * _3;
  _7 = u_2(D)->y;
  _8 = _7 * _7;
  _9 = _6 + _8;
  if (_9 u>= 0.0)
If we don't know anything further about u_2(D)->x and u_2(D)->y, VARYING *
VARYING is [0, +Inf] +-NAN, added twice is the same (note, unless
-fno-signed-zeros, it should be really [+0, +Inf] +-NAN, not [-0, +Inf] +-NAN,
but it doesn't matter for the u>= 0.0 comparison).
And then we can fold u>= 0.0 to true.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #16 from Jakub Jelinek  ---
I've filed PR107591 for the lack of x * x range optimization.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
This seems like an alignment issue.
That is GCC thinks the alignment of the variables are one thing but the reality
is something different.

We need more information than this since the atomics are run part of the
testsuite and we have not seen any issues related to them either. Plus
libstdc++ uses the atomics too.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #2 from Andrew Pinski  ---
>Reason: 259 at address: 0x3109

Yes that does seem like an alignment disagreement.

I suspect the code is broken for allocation and it is allocating unaligned
structs.

Also inside gdb can you do the following:

disassemble $pc-0x10 $pc+0x10
info registers

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

Aldy Hernandez  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #1 from Aldy Hernandez  ---
pinskia is a god.  How does he keep track of all these bugs, plus the cross
reference between them?  I knew PR91645 was related, but it was specifically
something on my radar, not the 5 trillion bugs in pinskia's head :-).  Kudos!

[Bug target/79365] tile*: incorrect result for expressions where result of a vector compare is used as a scalar

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
The tile* targets were removed in r13-1267-gfc259b522c0f8b so closing as won't
fix.

[Bug target/62139] Tilera tilepro: useless stack pointer operations

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
The tile* targets were removed in r13-1267-gfc259b522c0f8b so closing as won't
fix.

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #2 from Jakub Jelinek  ---
Perhaps before we try to map MULT_EXPR into some irange/frange op the usual
way,
while we still have access to gimple statement check if it is MULT_EXPR with
the same operands and use a different artificial unary op for pow2.
We could do this for PLUS_EXPR x + x as well and handle it as 2 * x if we don't
do that already or if match.pd doesn't already canonicalize x + x that way.

[Bug target/78862] tile*: ICE with -fstack-protetor-strong

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |WONTFIX

--- Comment #4 from Andrew Pinski  ---
The tile* targets were removed in r13-1267-gfc259b522c0f8b so closing as won't
fix.

[Bug target/78117] gcc on tilegx builds faulty strstr() function (from glibc)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #9 from Andrew Pinski  ---
The tile* targets were removed in r13-1267-gfc259b522c0f8b so closing as won't
fix.

[Bug rtl-optimization/55360] [TileGX] Passing structure by value on stack needlessly writes to and reads from memory

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |WONTFIX

--- Comment #3 from Andrew Pinski  ---
The tile* targets were removed in r13-1267-gfc259b522c0f8b so closing as won't
fix.

[Bug target/78222] target-tilegx: Incorrect bundle: let addli in y pipe

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0

--- Comment #2 from Andrew Pinski  ---
The tile* targets were removed in r13-1267-gfc259b522c0f8b so closing as won't
fix.

[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753

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

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

Bug 86808 Summary: tilegx port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86808

   What|Removed |Added

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

[Bug target/86809] tilepro port needs updating for CVE-2017-5753

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.0

--- Comment #1 from Andrew Pinski  ---
The tile* targets were removed in r13-1267-gfc259b522c0f8b so closing as won't
fix.

[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753

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

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

Bug 86809 Summary: tilepro port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86809

   What|Removed |Added

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

[Bug middle-end/101926] [meta-bug] struct/complex argument passing and return should be improved

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

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

Bug 55360 Summary: [TileGX] Passing structure by value on stack needlessly 
writes to and reads from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55360

   What|Removed |Added

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

[Bug target/86808] tilegx port needs updating for CVE-2017-5753

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Andrew Pinski  ---
The tile* targets were removed in r13-1267-gfc259b522c0f8b so closing as won't
fix.

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Aldy Hernandez from comment #1)
> pinskia is a god.  How does he keep track of all these bugs, plus the cross
> reference between them?  I knew PR91645 was related, but it was specifically
> something on my radar, not the 5 trillion bugs in pinskia's head :-).  Kudos!

I remembered seeing a different "x * x" issue and I just did a search. There is
at least one more about "x * x" too but I need to find it still.

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #5 from Aldy Hernandez  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #1)
> > pinskia is a god.  How does he keep track of all these bugs, plus the cross
> > reference between them?  I knew PR91645 was related, but it was specifically
> > something on my radar, not the 5 trillion bugs in pinskia's head :-).  
> > Kudos!
> 
> I remembered seeing a different "x * x" issue and I just did a search. There
> is at least one more about "x * x" too but I need to find it still.

I think you're just being humble.  Either that or maybe you're just a bot with
superpowers :-P.

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
PR 56355 is related but it is definitely more complex.

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #6 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps before we try to map MULT_EXPR into some irange/frange op the usual
> way,
> while we still have access to gimple statement check if it is MULT_EXPR with
> the same operands and use a different artificial unary op for pow2.
> We could do this for PLUS_EXPR x + x as well and handle it as 2 * x if we
> don't do that already or if match.pd doesn't already canonicalize x + x that
> way.

FYI, the range operators have a relation field, so it should be able to tell
you that both operands are equal with VREL_EQ (?).  You could use that to
optimize things.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Sergey Fedorov  ---
(In reply to Andrew Pinski from comment #2)
> >Reason: 259 at address: 0x3109
> 
> Yes that does seem like an alignment disagreement.
> 
> I suspect the code is broken for allocation and it is allocating unaligned
> structs.

The code in Boost shared pointer tests looks pretty simple. Since the bus error
happens on those, no need to look into i2pd case.
I don’t really know how alignment works there, but hopefully someone can look
at that.

But the error was reproducible on several tests plus i2pd itself. All fixed by
switching to Boost own atomics. I am not qualified to judge if the code is
broken, but this looks like it is worth investigation.

> Also inside gdb can you do the following:
> 
> disassemble $pc-0x10 $pc+0x10
> info registers

I could try that tomorrow, provided an ancient GBD we have on PPC supports
that.

[Bug d/107592] New: ICE: gdc segfault on label continue

[zorael at gmail dot com via Gcc-bugs]

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

Bug ID: 107592
   Summary: ICE: gdc segfault on label continue
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: zorael at gmail dot com
  Target Milestone: ---

Manjaro/Arch x86_64, gdc from gcc-d 12.2.0-1 from official repositories.

The following code ICEs with a segmentation fault.

```
void main()
{
foo(string.init);
}

void foo(Things...)(Things things)
{
label:
foreach (thing; things)
{
continue label;
}
}
```

`gdc -v -save-temps -freport-bug app.d` output:

```
Using built-in specs.
COLLECT_GCC=gdc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-o' 'a.out'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/d21 app.d -quiet -dumpdir a- -dumpbase
app.d -dumpbase-ext .d -mtune=generic -march=x86-64 -version -freport-bug -v -o
a-app.s
GNU D (GCC) version 12.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU D (GCC) version 12.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
binary/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/d21
version   v2.100.1

predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown
GNU_InlineAsm D_LP64 D_PIC D_PIE assert D_PreConditions D_PostConditions
D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86_64 D_HardFloat Posix
linux CRuntime_Glibc CppRuntime_Gcc
parse app
importall app
importobject   
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/object.d)
importcore.attribute   
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/attribute.d)
importgcc.attributes   
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/gcc/attributes.d)
importcore.internal.hash   
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/hash.d)
importcore.internal.traits 
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/traits.d)
importcore.internal.entrypoint 
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/entrypoint.d)
importcore.internal.array.appending
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/array/appending.d)
importcore.internal.array.comparison   
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/array/comparison.d)
importcore.internal.array.equality 
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/array/equality.d)
importcore.internal.array.casting  
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/array/casting.d)
importcore.internal.array.concatenation
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/array/concatenation.d)
importcore.internal.array.construction 
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/array/construction.d)
importcore.internal.array.capacity 
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/array/capacity.d)
importcore.internal.dassert
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/dassert.d)
importcore.atomic  
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/atomic.d)
importcore.internal.attributes 
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/attributes.d)
importcore.internal.atomic 
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/core/internal/atomic.d)
importgcc.builtins 
(/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/d/gcc/builtins.d)
importgcc.config   
(/usr/lib/gcc/x86_

[Bug target/107581] ICE on sparc-leon-uclibc during go build

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

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

--- Comment #5 from Marc Poulhiès  ---
Created attachment 53862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53862&action=edit
naive patch

[Bug target/107581] ICE on sparc-leon-uclibc during go build

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

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

--- Comment #6 from Marc Poulhiès  ---
IIUC, the builtin for ADD_FETCH_4 is correctly defined (there's an entry with a
corresponding decl), but there's no builtin for FETCH_ADD_4.

When looking in go-gcc.cc, I see that only the ADD_FETCH is defined, and not
the FETCH_ADD. I'm testing a simple patch. It fixes the segfault but the libgo
still won't build because of missing symbols (probably an issue in uclibc? Not
sure it's worth the effort...).

I'm now regtesting the patch on x86_64.

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

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

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

--- Comment #5 from Gaius Mulley  ---
thanks for this excellent analysis.  Here is a patch which will fix the passing
of binop.proc in M2GenGCC.c.

diff --git a/gcc/m2/gm2-gcc/m2expr.def b/gcc/m2/gm2-gcc/m2expr.def
index 8988c78d575..e622d31d09b 100644
--- a/gcc/m2/gm2-gcc/m2expr.def
+++ b/gcc/m2/gm2-gcc/m2expr.def
@@ -19,7 +19,7 @@ You should have received a copy of the GNU General Public
License
 along with GNU Modula-2; see the file COPYING3.  If not see
 .  *)

-DEFINITION MODULE m2expr ;
+DEFINITION MODULE FOR "C" m2expr  ;

 FROM SYSTEM IMPORT ADDRESS ;
 FROM m2tree IMPORT Tree ;

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #7 from Jakub Jelinek  ---
To answer my own question:
int
foo (int x)
{
  return x + x;
}

int
bar (int x)
{
  return x * x * x * x * x * x;
}

float
baz (float x)
{
  return x + x;
}

float
qux (float x)
{
  return x * x * x * x * x * x;
}

float
corge (float x)
{
  return x * x;
}
match.pd or fold-const.cc canonicalizes x + x to x * 2, so no need to special
case that, x * x isn't canonicalized for integral types nor without -ffast-math
for floats either, with -ffast-math reassoc1 canonicalizes the multiplications
into __builtin_powif (x, 6) resp. __builtin_powif (x, 2) until powcabs pass
later on splits those into multiplications again.
So, for frange, if we implement good range op for CASE_CFN_POWI, we could just
use that, perhaps for VREL_EQ on mult.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Sergey Fedorov from comment #3)
> > Also inside gdb can you do the following:
> > 
> > disassemble $pc-0x10 $pc+0x10
> > info registers
> 
> I could try that tomorrow, provided an ancient GBD we have on PPC supports
> that.

It should because the above commands have been there for a long time (over 20
years).

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Aldy Hernandez from comment #6)
> FYI, the range operators have a relation field, so it should be able to tell
> you that both operands are equal with VREL_EQ (?).  You could use that to
> optimize things.

You're right, at least for irange trio.op1_op2 () in the mult fold_range is
VREL_EQ and we could just go from that.
For frange perhaps it isn't as perfect because of signed zeros, so in
float
foo (float x, float y)
{
  if (x == y)
return x * y;
  return 42.0f;
}
trio.op1_op2 () could be VREL_EQ even if one is signed and the other unsigned
zero, and in that case -0.0 would need to be in the range too.  But maybe that
is good enough for now.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #5 from Iain Sandoe  ---

I'm away from my usual sources of information but I'd suggest exploring the
possibility that someone has assumed that either the spinlock or a bool is
8bits; As far as my memory serves both are 32b on power darwin.

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

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

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

Surya Kumari Jangala  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #21 from Surya Kumari Jangala  ---
There are two options to resolve the issue:

1. Use the BIND(C) directive on the fortran callee (DGEBAL) to make it
interoperable with the caller which is written in C. As described in comment
19, using this directive removed accesses to the caller's frame.

2. As described in
(https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html),
since the first parameter to DGEBAL is of type CHARACTER, there is an extra
hidden argument. Change the call to DGEBAL from dgebal (the flexiBLAS wrapper
routine) to take an extra argument. This causes the compiler to allocate a
parameter save area in dgebal's frame, as there are now 9 parameters but only 8
parameter registers.

[Bug c++/107593] New: ice with -Wduplicated-cond

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 107593
   Summary: ice with -Wduplicated-cond
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This C++ code:

template  void SaturatingCast() {
  if (T() && T() && int())
;
  else if (T() && T() && int())
;
}

when compiled with recent gcc trunk and flag -Wduplicated-cond:

$ ~/gcc/results/bin/g++ -c -Wduplicated-cond bug860.cc 
bug860.cc: In function ‘void SaturatingCast()’:
bug860.cc:4:31: internal compiler error: Segmentation fault
4 |   else if (T() && T() && int())
  |   ^
0x106b5d9 crash_signal(int)
../../trunk.d1/gcc/toplev.cc:314
0x6f9f54 location_wrapper_p(tree_node const*)
../../trunk.d1/gcc/tree.h:4235
0x6f9f54 tree_strip_any_location_wrapper(tree_node*)
../../trunk.d1/gcc/tree.h:4247

I don't have a git hash range for this bug. It seems to have existed for at
least a few weeks.

[Bug rtl-optimization/105586] [11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-if-conversion -mtune=power4 -fno-guess-branch-probability

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

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

Surya Kumari Jangala  changed:

   What|Removed |Added

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

--- Comment #13 from Surya Kumari Jangala  ---
Closing the bug as it is fixed on trunk and we don't plan to backport it.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Iain Sandoe from comment #5)
> I'm away from my usual sources of information but I'd suggest exploring the
> possibility that someone has assumed that either the spinlock or a bool is
> 8bits; As far as my memory serves both are 32b on power darwin.

Oh yes I forgot about bool being 32bit due to an ABI choice early on with
Apple's GCC 2.95 because of not having a bool type but defining it to int.
So there might be still a mismatch there still ...

[Bug middle-end/106123] ICE in walk_tree_1, at tree.cc:11243

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
the minimized testing case:

struct S { int t; int a; void foo (); };

void
S::foo ()
{
#pragma omp parallel
  {
#pragma omp taskloop firstprivate (a) 
for (int i = 0; i < a; i++)
  t++;
  }
}

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:4eadbe80060ab6c45193a1a57fac84b035e1c328

commit r13-3860-g4eadbe80060ab6c45193a1a57fac84b035e1c328
Author: Aldy Hernandez 
Date:   Wed Nov 9 16:05:08 2022 +0100

Clear NAN when reading back a global range if necessary.

When reading back from the global store, we must clear the NAN bit if
necessary.  The reason it's not happening is because the constructor
sets a NAN by default (when HONOR_NANS).  We must be careful to clear
the NAN bit if the original range didn't have a NAN.

I have commented the reason we use the constructor instead of filling
out the fields by hand, because it wasn't clear at re-reading this
code.

PR 107569/tree-optimization

gcc/ChangeLog:

* value-range-storage.cc (frange_storage_slot::get_frange): Clear
NAN if appropriate.
* value-range.cc (range_tests_floats): New test.

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #10 from joseph at codesourcery dot com  ---
For scalar isnan see bug 66462.  (The claim in bug 66462 comment 19 that 
there was ever a working version of that patch ready to go in is 
incorrect: November 2016 is older than June 2017.)

[Bug d/107592] ICE: gdc segfault on label continue

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
Generated function:
---
void foo (struct  _param_0)
{
  void label = <<< error >>>;

  label:;
  while (1)
{
  {
struct  thing;

thing = _param_0;
goto ;
  }
  goto ;
}
  :;
}

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #6)
> > FYI, the range operators have a relation field, so it should be able to tell
> > you that both operands are equal with VREL_EQ (?).  You could use that to
> > optimize things.
> 
> You're right, at least for irange trio.op1_op2 () in the mult fold_range is
> VREL_EQ and we could just go from that.
> For frange perhaps it isn't as perfect because of signed zeros, so in
> float
> foo (float x, float y)
> {
>   if (x == y)
> return x * y;
>   return 42.0f;
> }
> trio.op1_op2 () could be VREL_EQ even if one is signed and the other
> unsigned zero, and in that case -0.0 would need to be in the range too.  But
> maybe that is good enough for now.

you could also test whether op1_range contains + and/or - 0, as well as
op2_range.  VREL_EQ is a symbolic equality.. the ranges can still be distinct
and individually testable to see if you have a +0 and -0..   I guess you could
also test for equality of the ranges.. op1_range == op2_range

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #9)
> you could also test whether op1_range contains + and/or - 0, as well as
> op2_range.  VREL_EQ is a symbolic equality.. the ranges can still be
> distinct and individually testable to see if you have a +0 and -0..   I
> guess you could also test for equality of the ranges.. op1_range == op2_range

Equality of the ranges doesn't imply equality of the values.

int
foo (int x, y)
{
  if (x < -13 || x > 26)
return -1;
  if (y < -13 || y > 26)
return -1;
  return x * y;
}

In the above testcase, both x and y have [-13, 26] ranges, but here the range
[-338, 676] is correct, while [0, 676] is right for the #c0 testcase.

[Bug c++/107594] New: ICE in module_state, at cp/module.cc:3810

[gscfq--- via Gcc-bugs]

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

Bug ID: 107594
   Summary: ICE in module_state, at cp/module.cc:3810
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r11 :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
import ;


$ gcc-13-20221106 -c z1.cc -fmodules-ts -nostdinc
z1.cc:1:8: error: no include path in which to search for nix
1 | import ;
  |^
z1.cc:1:1: internal compiler error: in module_state, at cp/module.cc:3810
1 | import ;
  | ^~
0x98332e module_state::module_state(tree_node*, module_state*, bool)
../../gcc/cp/module.cc:3808
0x99b3a1 get_module(tree_node*, module_state*, bool)
../../gcc/cp/module.cc:13952
0x95554c module_token_filter::resume(int, int, tree_node*, unsigned int)
../../gcc/cp/lex.cc:513
0x95554c module_token_lang(int, int, tree_node*, unsigned int, unsigned long)
../../gcc/cp/lex.cc:563
0xa3b56b cp_lexer_new_main
../../gcc/cp/parser.cc:728
0xa3b56b c_parse_file()
../../gcc/cp/parser.cc:48815
0xbe0a71 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1244

[Bug fortran/107595] New: ICE in ix86_push_argument, at config/i386/i386.cc:4335

[gscfq--- via Gcc-bugs]

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

Bug ID: 107595
   Summary: ICE in ix86_push_argument, at config/i386/i386.cc:4335
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(GNU Extension: Old-style initialization )


$ cat z1.f90
program p
   type t
  integer :: a
  integer, pointer :: b
   end type
   type(t) x /t(4, null())/
   print *, x%b
end


$ cat z2.f90
program p
   type t
  integer :: a
  integer, pointer :: b
   end type
   type(t) :: x = t(4, null())
   print *, x%b
end


$ gfortran-13-20221106 -c z2.f90
$
$ gfortran-13-20221106 -c z1.f90
z1.f90:8:3:

8 | end
  |   ^
internal compiler error: Segmentation fault
0xf4697f crash_signal
../../gcc/toplev.cc:314
0x134e81d ix86_push_argument
../../gcc/config/i386/i386.cc:4335
0x9bcce3 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.cc:2688
0xb1cb29 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11868
0x13138ac expand_expr
../../gcc/expr.h:310
0x13138ac output_constant
../../gcc/varasm.cc:5250
0x1314d97 output_constant
../../gcc/varasm.cc:5158
0x1314d97 output_constructor_regular_field
../../gcc/varasm.cc:5545
0x1314d97 output_constructor
../../gcc/varasm.cc:5812
0x1316ba9 output_constant
../../gcc/varasm.cc:5158
0x1316ba9 assemble_variable_contents
../../gcc/varasm.cc:2231
0x13218dc assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.cc:2410
0x1324f84 varpool_node::assemble_decl()
../../gcc/varpool.cc:596
0xa2b037 output_in_order
../../gcc/cgraphunit.cc:2151
0xa2b037 symbol_table::compile()
../../gcc/cgraphunit.cc:2355
0xa2e97f symbol_table::compile()
../../gcc/cgraphunit.cc:2546
0xa2e97f symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2543

[Bug fortran/107596] New: ICE in gfc_match_submodule, at fortran/module.cc:773

[gscfq--- via Gcc-bugs]

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

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

Started with r6 :


$ cat z1.f90
submodule(m)
submodule(m)


$ cat z2.f90
module m
end
submodule(m)1
submodule(m)2
end


$ gfortran-13-20221106 -c z1.f90
z1.f90:1:12:

1 | submodule(m)
  |1
Error: Syntax error in SUBMODULE statement at (1)
f951: internal compiler error: in gfc_match_submodule, at fortran/module.cc:773
0x83b802 gfc_match_submodule()
../../gcc/fortran/module.cc:773
0x855df1 match_word
../../gcc/fortran/parse.cc:67
0x85b8cd decode_statement
../../gcc/fortran/parse.cc:564
0x85be8a next_free
../../gcc/fortran/parse.cc:1402
0x85be8a next_statement
../../gcc/fortran/parse.cc:1634
0x861e39 gfc_parse_file()
../../gcc/fortran/parse.cc:6765
0x8b0c8f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #18 from Jakub Jelinek  ---
Ok, just so that I don't just kibbitz/review frange stuff but also try to do
something, here is my so far untested attempt at normal multiplication
fold_range  (not the x * x stuff discussed elsewhere):

--- range-op-float.cc.jj1   2022-11-09 18:00:28.612247613 +0100
+++ range-op-float.cc   2022-11-09 19:06:11.075716000 +0100
@@ -1908,6 +1908,88 @@ class foperator_minus : public range_ope
   }
 } fop_minus;

+/* Wrapper around frange_arithmetics, that computes the result
+   if inexact rounded to both directions.  Also, if one of the
+   operands is +-0.0 and another +-inf, return +-0.0 rather than
+   NAN.  */
+
+static void
+frange_mult (tree type, REAL_VALUE_TYPE &result_lb, REAL_VALUE_TYPE
&result_ub,
+const REAL_VALUE_TYPE &op1, const REAL_VALUE_TYPE &op2)
+{
+  if (real_iszero (&op1) && real_isinf (&op2))
+{
+  result_lb = op1;
+  if (real_isneg (&op2))
+   real_value_negate (&result_lb);
+  result_ub = result_lb;
+}
+  else if (real_isinf (&op1) && real_iszero (&op2))
+{
+  result_lb = op2;
+  if (real_isneg (&op1))
+   real_value_negate (&result_lb);
+  result_ub = result_lb;
+}
+  else
+{
+  frange_arithmetic (MULT_EXPR, type, result_lb, op1, op2, dconstninf);
+  frange_arithmetic (MULT_EXPR, type, result_ub, op1, op2, dconstinf);
+}
+}
+
+class foperator_mult : public range_operator_float
+{
+  void rv_fold (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, bool &maybe_nan,
+   tree type,
+   const REAL_VALUE_TYPE &lh_lb,
+   const REAL_VALUE_TYPE &lh_ub,
+   const REAL_VALUE_TYPE &rh_lb,
+   const REAL_VALUE_TYPE &rh_ub) const final override
+  {
+REAL_VALUE_TYPE cp[8];
+// Do a cross-product.
+frange_mult (type, cp[0], cp[4], lh_lb, rh_lb);
+frange_mult (type, cp[1], cp[5], lh_lb, rh_ub);
+frange_mult (type, cp[2], cp[6], lh_ub, rh_lb);
+frange_mult (type, cp[3], cp[7], lh_ub, rh_ub);
+for (int i = 1; i < 3; ++i)
+  {
+   if (real_less (&cp[i], &cp[0])
+   || (real_iszero (&cp[0]) && real_isnegzero (&cp[i])))
+ std::swap (cp[i], cp[0]);
+   if (real_less (&cp[4], &cp[i + 4])
+   || (real_isnegzero (&cp[4]) && real_iszero (&cp[i + 4])))
+ std::swap (cp[i + 4], cp[4]);
+  }
+lb = cp[0];
+ub = cp[4];
+
+// [+-0, +-0] * [+INF,+INF] (or [-INF,-INF] or swapped is a known NaN.
+if ((real_iszero (&lh_lb) && real_iszero (&lh_ub)
+&& real_isinf (&rh_lb) && real_isinf (&rh_ub, real_isneg (&rh_lb)))
+   || (real_iszero (&rh_lb) && real_iszero (&rh_ub)
+   && real_isinf (&lh_lb) && real_isinf (&lh_ub, real_isneg
(&lh_lb
+  {
+   real_nan (&lb, NULL, 0, TYPE_MODE (type));
+   ub = lb;
+   maybe_nan = true;
+  }
+// Otherwise, if one range includes zero and the other ends with +-INF,
+// it is a maybe NaN.
+else if (real_compare (LE_EXPR, &lh_lb, &dconst0)
+&& real_compare (GE_EXPR, &lh_ub, &dconst0)
+&& (real_isinf (&rh_lb) || real_isinf (&rh_ub)))
+  maybe_nan = true;
+else if (real_compare (LE_EXPR, &rh_lb, &dconst0)
+&& real_compare (GE_EXPR, &rh_ub, &dconst0)
+&& (real_isinf (&lh_lb) || real_isinf (&lh_ub)))
+  maybe_nan = true;
+else
+  maybe_nan = false;
+  }
+} fop_mult;
+
 // Instantiate a range_op_table for floating point operations.
 static floating_op_table global_floating_table;

@@ -1942,6 +2024,7 @@ floating_op_table::floating_op_table ()
   set (NEGATE_EXPR, fop_negate);
   set (PLUS_EXPR, fop_plus);
   set (MINUS_EXPR, fop_minus);
+  set (MULT_EXPR, fop_mult);
 }

 // Return a pointer to the range_operator_float instance, if there is

For
float
foo (float x, float y)
{
  if (x < -17.0f || x > 19.5f || y < -25.0f || y > 15.5f)
return 0.0;
  return x * y;
}

float
bar (float x, float y)
{
  if (x > -17.0f && x < 19.5f && y > -25.0f && y < 15.5f)
return x * y;
  return 0.0;
}
the product range is
[frange] float [-4.875e+2 (-0x0.f3cp+9), 4.25e+2 (0x0.d48p+9)] +-NAN
in the first case and
[frange] float [-4.875e+2 (-0x0.f3cp+9), 4.25e+2 (0x0.d48p+9)]
in the latter (where NAN can't appear).  And while +-0.0 is in the range of
even both operands, neither range includes any infinities.

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #11 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > you could also test whether op1_range contains + and/or - 0, as well as
> > op2_range.  VREL_EQ is a symbolic equality.. the ranges can still be
> > distinct and individually testable to see if you have a +0 and -0..   I
> > guess you could also test for equality of the ranges.. op1_range == 
> > op2_range
> 
> Equality of the ranges doesn't imply equality of the values.
> 
> int
> foo (int x, y)
> {
>   if (x < -13 || x > 26)
> return -1;
>   if (y < -13 || y > 26)
> return -1;
>   return x * y;
> }
> 
> In the above testcase, both x and y have [-13, 26] ranges, but here the
> range [-338, 676] is correct, while [0, 676] is right for the #c0 testcase.

no, I meant in addition to the VREL_EQ.  so 
  if (rel == VREL_EQ && op1_range != op2_range)
 then you know you have something like  if (x == y) z=x*y and may have to
check for various signed zero cobinations in each range, 
whereas is op1_range == op2_range in this case, it should be perfectly safe..

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #11)
> no, I meant in addition to the VREL_EQ.  so 
>   if (rel == VREL_EQ && op1_range != op2_range)
>  then you know you have something like  if (x == y) z=x*y and may have
> to check for various signed zero cobinations in each range, 
> whereas is op1_range == op2_range in this case, it should be perfectly safe..

I don't understand.  Let's modify the testcase to:
float
foo (float x, y)
{
  if (x < -13.f || x > 26.f)
return -1.0f;
  if (y < -13.f || y > 26.f)
return -1.0f;
  if (x == y)
return x * y;
  return 42.0f;
}
I'd expect that fold_range on the x * y should see trio.op1_op2 () == VREL_EQ
because of the guarding x == y condition.  And the ranges of both are [-13.f,
26.f] +-NAN too.  Still, x could be -0.0f and y 0.0f or vice versa, and so
x * y could be -0.0f, so we need [-0.f, 676.f] +-NAN.  While if it is x * x, we
know the result will have always sign bit of 0 (except if NAN), so [0.f, 676.f]
+-NAN.

[Bug libstdc++/107580] std::vector parameter cannot be inferred with -D_GLIBCXX_USE_CXX11_ABI=0

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ABI
   Assignee|redi at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #3 from Jonathan Wakely  ---
Unfortunately this changes the mangled name of the function, and so breaks the
library ABI. Maybe that's why I didn't do it sooner.

There are ways to solve that, but it's not as trivial as I thought.

[Bug c++/107597] New: LTO causes static inline variables to get a non-uniqued global symbol

[cfsteefel at arista dot com via Gcc-bugs]

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

Bug ID: 107597
   Summary: LTO causes static inline variables to get a
non-uniqued global symbol
   Product: gcc
   Version: 8.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cfsteefel at arista dot com
  Target Milestone: ---

The following was seen with gcc 11.3.1 (centos7 based) and gcc 8.4 (also
centos7 based).

The following code produces a GNU extension unique symbol for NonTemplated::x
when flto is not used ('u' in nm), but a global non-unique symbol when flto is
used, even when building a shared library ('B' in nm).

class NonTemplated {
   static inline int x;
   public:
   void doFoo() {
  x++;
   }
};

int main() {
   NonTemplated n;
   n.doFoo();
   return 0;
}

> g++ -std=gnu++17 -O2 -shared -fPIC -o libFoo.so -flto test.cpp
> nm ./libFoo.so | c++filt | grep NonTemplated
0020102c B NonTemplated::x


> g++ -std=gnu++17 -O2 -shared -fPIC -o libFoo.so test.cpp
> nm ./libFoo.so | c++filt | grep NonTemplated
0020102c u NonTemplated::x

When compiled under clang++, the symbol is `V` (weak) regardless of flto is
used or not.

The resulting symptom of this is that Address Sanitizer will flag the variable
NonTemplated::X as an ODR violation, if the class is included into more than
one flto compiled shared library.

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #13 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Andrew Macleod from comment #11)
> > no, I meant in addition to the VREL_EQ.  so 
> >   if (rel == VREL_EQ && op1_range != op2_range)
> >  then you know you have something like  if (x == y) z=x*y and may have
> > to check for various signed zero cobinations in each range, 
> > whereas is op1_range == op2_range in this case, it should be perfectly 
> > safe..
> 
> I don't understand.  Let's modify the testcase to:

> I'd expect that fold_range on the x * y should see trio.op1_op2 () == VREL_EQ
> because of the guarding x == y condition.  And the ranges of both are
> [-13.f, 26.f] +-NAN too.  Still, x could be -0.0f and y 0.0f or vice versa,
> and so
> x * y could be -0.0f, so we need [-0.f, 676.f] +-NAN.  While if it is x * x,
> we know the result will have always sign bit of 0 (except if NAN), so [0.f,
> 676.f] +-NAN.

gah. Clearly it is I who does not understand. -0.0 and +0.0 interactions remind
me of all the signed single bit crud we (ie Aldy) went thru.  The same team
must have come up with both concepts :-P  At least they deserve the same award.

Move along and ignore me.

[Bug c++/107598] New: implicitly-defined copy/move assignment op not constexpr

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

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

Bug ID: 107598
   Summary: implicitly-defined copy/move assignment op not
constexpr
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The following test is rejected with:

bug1.C: In function ‘constexpr void g()’:
bug1.C:11:7: error: call to non-‘constexpr’ function ‘S& S::operator=(const
S&)’
   11 |   b = a;
  |   ^
bug1.C:5:4: note: ‘S& S::operator=(const S&)’ is not usable as a ‘constexpr’
function because:
5 | S& S::operator=(const S&) = default;
  |^

...because what?

I think it should be accepted, at least in C++23, because
[class.copy.assign]/10:
"A copy/move assignment operator for a class X that is defaulted and not
defined as deleted is implicitly defined when it is odr-used ([basic.def.odr])
(e.g., when it is selected by overload resolution to assign to an object of its
class type), when it is needed for constant evaluation ([expr.const]), or when
it is explicitly defaulted after its first declaration.
The implicitly-defined copy/move assignment operator is constexpr."

Here it is explicitly defaulted after its first declaration.


struct S {
  constexpr S() {}
  S& operator=(const S&);
};
S& S::operator=(const S&) = default;

constexpr void
g ()
{
  S a, b;
  b = a;
}

[Bug c++/107599] New: [13 regression] c-c++-common/diagnostic-format-json-4.c fails after r13-3853-g9c3bc557995463

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

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

Bug ID: 107599
   Summary: [13 regression]
c-c++-common/diagnostic-format-json-4.c fails after
r13-3853-g9c3bc557995463
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:9c3bc557995463fe1dcc37ec503af780a6c1a341, r13-3853-g9c3bc557995463

make  -k check-gcc
RUNTESTFLAGS="dg.exp=c-c++-common/diagnostic-format-json-4.c"
"]*#index-Wmisleading-indentation""t-json-4.c  -Wc++-compat   dg-regexp 45 not
found: ""option_url": "https:[^\n
FAIL: c-c++-common/diagnostic-format-json-4.c  -Wc++-compat  (test for excess
errors)
"]*#index-Wmisleading-indentation""t-json-4.c  -std=gnu++98  dg-regexp 45 not
found: ""option_url": "https:[^\n
FAIL: c-c++-common/diagnostic-format-json-4.c  -std=gnu++98 (test for excess
errors)
"]*#index-Wmisleading-indentation""t-json-4.c  -std=gnu++14  dg-regexp 45 not
found: ""option_url": "https:[^\n
FAIL: c-c++-common/diagnostic-format-json-4.c  -std=gnu++14 (test for excess
errors)
"]*#index-Wmisleading-indentation""t-json-4.c  -std=gnu++17  dg-regexp 45 not
found: ""option_url": "https:[^\n
FAIL: c-c++-common/diagnostic-format-json-4.c  -std=gnu++17 (test for excess
errors)
"]*#index-Wmisleading-indentation""t-json-4.c  -std=gnu++20  dg-regexp 45 not
found: ""option_url": "https:[^\n
FAIL: c-c++-common/diagnostic-format-json-4.c  -std=gnu++20 (test for excess
errors)

commit 9c3bc557995463fe1dcc37ec503af780a6c1a341 (HEAD, refs/bisect/bad)
Author: Martin Liska 
Date:   Wed Nov 9 13:10:11 2022 +0100

sphinx: update diagnostics URLs

[Bug c++/107599] [13 regression] c-c++-common/diagnostic-format-json-4.c fails after r13-3853-g9c3bc557995463

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-11-09
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

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

[Bug c++/107593] [12/13 Regression] ice with -Wduplicated-cond

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-11-09
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
Summary|ice with -Wduplicated-cond  |[12/13 Regression] ice with
   ||-Wduplicated-cond
   Priority|P3  |P2
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r12-6022-gbb2a7f80a98de3:

commit bb2a7f80a98de3febefbb32b1e4898062bdb6af8
Author: Patrick Palka 
Date:   Thu Dec 16 13:40:42 2021 -0500

c++: two-stage name lookup for overloaded operators [PR51577]

but it's -Wduplicated-cond so probably mine.

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

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

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

commit r13-3863-ge805adaa283129604a1fb305d0a1cf1e8a90c76e
Author: Harald Anlauf 
Date:   Fri Oct 28 21:58:08 2022 +0200

Fortran: ordering of hidden procedure arguments [PR107441]

The gfortran ABI specifies the order of given and hidden procedure
arguments,
where the hidden presence status flags of optional+value scalar arguments
shall come before character length, coarray token and offset.  Respect
that.

gcc/fortran/ChangeLog:

PR fortran/107441
* trans-decl.cc (create_function_arglist): Adjust the ordering of
automatically generated hidden procedure arguments to match the
documented ABI for gfortran.
* trans-types.cc (gfc_get_function_type): Separate hidden
parameters
so that the presence flag for optional+value arguments come before
string length, coarray token and offset, as required.

gcc/testsuite/ChangeLog:

PR fortran/107441
* gfortran.dg/coarray/pr107441-caf.f90: New test.
* gfortran.dg/optional_absent_6.f90: New test.
* gfortran.dg/optional_absent_7.f90: New test.

[Bug c++/107599] [13 regression] c-c++-common/diagnostic-format-json-4.c fails after r13-3853-g9c3bc557995463

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

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

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

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

commit r13-3864-gf94c2eff6b0e000ee2feadedf354590958308760
Author: Martin Liska 
Date:   Wed Nov 9 20:56:41 2022 +0100

docs: Fix expected diagnostics URL [PR107599]

PR c++/107599

gcc/testsuite/ChangeLog:

* c-c++-common/diagnostic-format-json-2.c: Fix expected URL.
* c-c++-common/diagnostic-format-json-3.c: Likewise.
* c-c++-common/diagnostic-format-json-4.c: Likewise.
* gfortran.dg/diagnostic-format-json-2.F90: Likewise.
* gfortran.dg/diagnostic-format-json-3.F90: Likewise.

[Bug c++/107599] [13 regression] c-c++-common/diagnostic-format-json-4.c fails after r13-3853-g9c3bc557995463

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug fortran/107559] ICE in resolve_equivalence, at fortran/resolve.cc:17230

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

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

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

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

commit r13-3865-ge505f7493bed1395d121d2f53137ec11706fa42e
Author: Harald Anlauf 
Date:   Wed Nov 9 21:05:28 2022 +0100

Fortran: avoid NULL pointer dereference on bad EQUIVALENCEs [PR107559]

gcc/fortran/ChangeLog:

PR fortran/107559
* resolve.cc (resolve_equivalence): Avoid NULL pointer dereference
while emitting diagnostics for bad EQUIVALENCEs.

gcc/testsuite/ChangeLog:

PR fortran/107559
* gfortran.dg/pr107559.f90: New test.

[Bug fortran/107559] ICE in resolve_equivalence, at fortran/resolve.cc:17230

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Fixed on mainline.  Closing.

Thanks for the report!

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #14 from Jakub Jelinek  ---
Incremental patch on top of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569#c18 patch which optimizes
the floating point x * x:

--- gcc/range-op-float.cc.jj2022-11-09 19:06:11.075716000 +0100
+++ gcc/range-op-float.cc   2022-11-09 21:11:52.468256045 +0100
@@ -51,7 +51,7 @@ along with GCC; see the file COPYING3.
 bool
 range_operator_float::fold_range (frange &r, tree type,
  const frange &op1, const frange &op2,
- relation_trio) const
+ relation_trio trio) const
 {
   if (empty_range_varying (r, type, op1, op2))
 return true;
@@ -65,7 +65,7 @@ range_operator_float::fold_range (frange
   bool maybe_nan;
   rv_fold (lb, ub, maybe_nan, type,
   op1.lower_bound (), op1.upper_bound (),
-  op2.lower_bound (), op2.upper_bound ());
+  op2.lower_bound (), op2.upper_bound (), trio);

   // Handle possible NANs by saturating to the appropriate INF if only
   // one end is a NAN.  If both ends are a NAN, just return a NAN.
@@ -103,8 +103,8 @@ range_operator_float::rv_fold (REAL_VALU
   const REAL_VALUE_TYPE &lh_lb ATTRIBUTE_UNUSED,
   const REAL_VALUE_TYPE &lh_ub ATTRIBUTE_UNUSED,
   const REAL_VALUE_TYPE &rh_lb ATTRIBUTE_UNUSED,
-  const REAL_VALUE_TYPE &rh_ub ATTRIBUTE_UNUSED)
-  const
+  const REAL_VALUE_TYPE &rh_ub ATTRIBUTE_UNUSED,
+  relation_trio) const
 {
   lb = dconstninf;
   ub = dconstinf;
@@ -1868,7 +1868,8 @@ class foperator_plus : public range_oper
const REAL_VALUE_TYPE &lh_lb,
const REAL_VALUE_TYPE &lh_ub,
const REAL_VALUE_TYPE &rh_lb,
-   const REAL_VALUE_TYPE &rh_ub) const final override
+   const REAL_VALUE_TYPE &rh_ub,
+   relation_trio) const final override
   {
 frange_arithmetic (PLUS_EXPR, type, lb, lh_lb, rh_lb, dconstninf);
 frange_arithmetic (PLUS_EXPR, type, ub, lh_ub, rh_ub, dconstinf);
@@ -1892,7 +1893,8 @@ class foperator_minus : public range_ope
const REAL_VALUE_TYPE &lh_lb,
const REAL_VALUE_TYPE &lh_ub,
const REAL_VALUE_TYPE &rh_lb,
-   const REAL_VALUE_TYPE &rh_ub) const final override
+   const REAL_VALUE_TYPE &rh_ub,
+   relation_trio) const final override
   {
 frange_arithmetic (MINUS_EXPR, type, lb, lh_lb, rh_ub, dconstninf);
 frange_arithmetic (MINUS_EXPR, type, ub, lh_ub, rh_lb, dconstinf);
@@ -1910,7 +1912,7 @@ class foperator_minus : public range_ope

 /* Wrapper around frange_arithmetics, that computes the result
if inexact rounded to both directions.  Also, if one of the
-   operands is +-0.0 and another +-inf, return +-0.0 rather than
+   operands is +-0.0 and another +-INF, return +-0.0 rather than
NAN.  */

 static void
@@ -1945,13 +1947,42 @@ class foperator_mult : public range_oper
const REAL_VALUE_TYPE &lh_lb,
const REAL_VALUE_TYPE &lh_ub,
const REAL_VALUE_TYPE &rh_lb,
-   const REAL_VALUE_TYPE &rh_ub) const final override
+   const REAL_VALUE_TYPE &rh_ub,
+   relation_trio trio) const final override
   {
 REAL_VALUE_TYPE cp[8];
+bool is_square
+  = (trio.op1_op2 () == VREL_EQ
+&& real_equal (&lh_lb, &rh_lb)
+&& real_equal (&lh_ub, &rh_ub)
+&& real_isneg (&lh_lb) == real_isneg (&rh_lb)
+&& real_isneg (&lh_ub) == real_isneg (&rh_ub));
 // Do a cross-product.
 frange_mult (type, cp[0], cp[4], lh_lb, rh_lb);
-frange_mult (type, cp[1], cp[5], lh_lb, rh_ub);
-frange_mult (type, cp[2], cp[6], lh_ub, rh_lb);
+if (is_square)
+  {
+   // For x * x we can just do max (lh_lb * lh_lb, lh_ub * lh_ub)
+   // as maximum and -0.0 as minimum if 0.0 is in the range,
+   // otherwise min (lh_lb * lh_lb, lh_ub * lh_ub).
+   // -0.0 rather than 0.0 because VREL_EQ doesn't prove that
+   // x and y are bitwise equal, just that they compare equal.
+   if (real_compare (LE_EXPR, &lh_lb, &dconst0)
+   && real_compare (GE_EXPR, &lh_ub, &dconst0))
+ {
+   cp[1] = dconst0;
+   real_value_negate (&cp[1]);
+ }
+   else
+ cp[1] = cp[0];
+   cp[2] = cp[0];
+   cp[5] = cp[4];
+   cp[6] = cp[4];
+  }
+else
+  {
+   frange_mult (type, cp[1], cp[5], lh_lb, rh_ub);
+   frange_mult (type, cp[2], cp[6], lh_ub, rh_lb);
+  }
 frange_mult (type, cp[3], cp[7], lh_ub, rh_ub);
 for (int i = 1; i < 3; ++i)
   {
@@ -1965,18 +1996,27 @@ class foperator_mult : public range_oper
 lb = cp[0];
 ub = cp[4];

-// [+-0, +-0] * [+INF,+INF] (or [-INF,-INF] or

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

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

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

--- Comment #15 from Jakub Jelinek  ---
I've screwed up the real_value_negate calls, they need to assign the result.

Anyway, yet another option would be for cdce to ask the ranger if the sqrt
argument can be smaller than -0.0 (and only if it can, emit the comparison).
Then we don't need to deal with removing the comparison again.
Of course, such removals might be still useful for user code.

[Bug fortran/94104] Request for diagnostic improvement

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Pinged here: https://gcc.gnu.org/pipermail/fortran/2022-November/058471.html

[Bug fortran/107444] ICE on character, value, optional dummy argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-11-09
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #4 from anlauf at gcc dot gnu.org ---
Working on a patch.

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

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

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-09
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
I can't reproduce it on x86-64.  The code is

static bool
ix86_push_argument (unsigned int npush)
{
  /* If SSE2 is available, use vector move to put large argument onto
 stack.  NB:  In 32-bit mode, use 8-byte vector move.  */
  return ((!TARGET_SSE2 || npush < (TARGET_64BIT ? 16 : 8)) 
  && TARGET_PUSH_ARGS
  && !ACCUMULATE_OUTGOING_ARGS);
}

It shouldn't segfault.

[Bug fortran/107596] ICE in gfc_match_submodule, at fortran/module.cc:773

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-11-09
 Status|UNCONFIRMED |NEW

--- Comment #1 from kargl at gcc dot gnu.org ---
Instead of an assert, just jump to a syntax error.

diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
index 5ddabdcff4d..b41e425ac8f 100644
--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.cc
@@ -770,7 +770,8 @@ gfc_match_submodule (void)
 }

   gfc_new_block = NULL;
-  gcc_assert (module_list == NULL);
+  if (module_list == NULL)
+goto syntax;

   if (gfc_match_char ('(') != MATCH_YES)
 goto syntax;

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #16 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #15)
> I've screwed up the real_value_negate calls, they need to assign the result.
> 
> Anyway, yet another option would be for cdce to ask the ranger if the sqrt
> argument can be smaller than -0.0 (and only if it can, emit the comparison).
> Then we don't need to deal with removing the comparison again.
> Of course, such removals might be still useful for user code.

even checking the global range from cdce at this point should show that its >=
-0.0...

[Bug analyzer/99671] RFE: analyzer could complain about ptr derefs that occur before the ptr is checked

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

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

--- Comment #2 from David Malcolm  ---
Created attachment 53863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53863&action=edit
Implementation of this (not yet ported to Sphinx)

This patch implements the new warning; still uses texinfo rather than sphinx. 
Not yet posted to mailing list; am waiting on dust to settle from the
texinfo->sphinx transition on trunk.

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Keywords|ice-on-valid-code   |

--- Comment #2 from kargl at gcc dot gnu.org ---
I've remove the ice-on-valid-code designation.
Restore it if you believe otherwise.

Allowing old style (aka nonstandard) initialization of variable
declared with a user-defined derived type should be deprecated.
There is no reason to avoid standard conforming code:

   type(t) x /t(4, null())/
   type(t) :: x = t(4, null())



diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..5627ea24245 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2969,6 +2977,14 @@ variable_decl (int elem)
  goto cleanup;
}

+  if (current_ts.type == BT_DERIVED)
+   {
+ gfc_error ("Old style initialization incompatiable with a variable "
+"declared with a user-defined derived type at %C");
+ m = MATCH_ERROR;
+ goto cleanup;
+   }
+
   /* For structure components, read the initializer as a special
  expression and let the rest of this function apply the initializer
  as usual.  */

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from kargl at gcc dot gnu.org ---
Change status to NEW as I see the same issue as Gerhard.