[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[dumoulin.thibaut at gmail dot com via Gcc-bugs]

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

Thibaut M.  changed:

   What|Removed |Added

 CC||dumoulin.thibaut at gmail dot 
com

--- Comment #10 from Thibaut M.  ---
I understand the patch
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-12/msg01158.html has not been
applied.

The dynamic constructor of global variable `pool emergency_pool;` in
`libstdc++-v3/libsupc++/eh_alloc.cc` remains and is still allocating
unconditionally at least 2.5ko on the heap.

> see the "performance of exception handling" / "size of exception handling"
> thread in this month's archive of the gcc mailing list
I was not able to find the thread about "exception handling" of 2020-05, could
you point it out or detail the conclusion please?

Has a solution been found for embedded systems with very limited resources? In
this case for example, C++ exceptions can be disabled and this emergency pool
not needed.

[Bug tree-optimization/107055] [13 Regression] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8415

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
Hmm, vectorizable_nonlinear_induction doesn't guard nonlinear iv vectorization.

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #1 from Francois-Xavier Coudert  ---
Can you run this on the target, and post the output here?

$ cat a.f90 
  use ieee_arithmetic
  integer, parameter :: k1 = &
max(ieee_selected_real_kind(precision(0.d0) + 1), kind(0.))
  integer, parameter :: k2 = &
max(ieee_selected_real_kind(precision(0._k1) + 1), kind(0.d0))

  print *, k1, k2
  end
$ gfortran a.f90 && ./a.out
  16   8

[Bug c++/107065] New: GCC treats rvalue like lvalue

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 107065
   Summary: GCC treats rvalue like lvalue
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

In the following program gcc incorrectly treats the expression `!(!b)` as
lvalue. Demo: https://godbolt.org/z/zv5En5hjG

```
#include 
template
struct value_category {
// Or can be an integral or enum value
static constexpr auto value = "prvalue";
};

template
struct value_category {
static constexpr auto value = "lvalue";
};

template
struct value_category {
static constexpr auto value = "xvalue";
};

// Double parens for ensuring we inspect an expression,
// not an entity
#define VALUE_CATEGORY(expr) value_category::value

int main() {
bool b = true;

std::cout << VALUE_CATEGORY(!(!b)); //gcc wrongly prints lvalue
}

```

[Bug tree-optimization/107055] [13 Regression] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8415

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
vect_peel_nonlinear_iv_init in vect_update_ivs_after_vectorizer should be
guarded by vect_can_peel_nonlinear_iv_p

[Bug tree-optimization/107055] [13 Regression] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8415

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #3)
> vect_peel_nonlinear_iv_init in vect_update_ivs_after_vectorizer should be
> guarded by vect_can_peel_nonlinear_iv_p

typo vect_can_advance_ivs_p

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org
   Host|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||aarch64-linux-gnu
 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||aarch64-linux-gnu
  Build|powerpc64le-linux-gnu   |powerpc64le-linux-gnu,
   ||aarch64-linux-gnu

--- Comment #12 from Tamar Christina  ---
I have the same problem, no special flags nothing. but bootstrap and
non-bootstrap are still broken.

In file included from /usr/include/stdlib.h:55,
 from
/opt/buildAgent/temp/buildTmp/aarch64-unknown-linux-gnu/libstdc++-v3/include/cstdlib:79,
 from
/opt/buildAgent/work/5c94c4ced6ebfcd0/libstdc++-v3/libsupc++/del_op.cc:38:
/usr/include/aarch64-linux-gnu/bits/floatn.h:80:14: error: multiple types in
one declaration
   80 | typedef long double _Float128;

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #13 from Jakub Jelinek  ---
I wonder how it works for Tobias then.
If the fixincluded headers go to
/home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/powerpc64le-linux-gnu/bits/floatn{,-common}.h
and search path is:
...
 /home/seurer/gcc/git/build/gcc-test/./gcc/include
 /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed
 /usr/local/include
 /usr/include/powerpc64le-linux-gnu
 /usr/include
then I think it can't find those headers for #include 
Given the above, I think the search paths should be:
...
 /home/seurer/gcc/git/build/gcc-test/./gcc/include
 /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/powerpc64le-linux-gnu
 /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed
 /usr/local/include
 /usr/include/powerpc64le-linux-gnu
 /usr/include
because the multiarch subdir sits below /usr/include and so is fixincluded
together with it.  I'd be afraid we fixinclude all the other arches if they
are, so if one has
/usr/include/powerpc64le-linux-gnu/bits/floatn.h
/usr/include/x86_64-linux-gnu/bits/floatn.h
both would go to:
/home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/powerpc64le-linux-gnu/bits/floatn.h
/home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/x86_64-linux-gnu/bits/floatn.h
so making fixincludes itself multiarch aware is going to be difficult.

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

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

commit r13-2914-gb48d7ff3570fa0ebe7790275cf020d8885120338
Author: Xi Ruoyao 
Date:   Sat Sep 24 20:47:22 2022 +0800

LoongArch: Use UNSPEC for fmin/fmax RTL pattern [PR105414]

I made a mistake defining fmin/fmax RTL patterns in r13-2085: I used
smin and smax in the definition mistakenly.  This causes the optimizer
to perform constant folding as if fmin/fmax was "really" smin/smax
operations even with -fsignaling-nans.  Then pr105414.c fails.

We don't have fmin/fmax RTL codes for now (PR107013) so we can only use
an UNSPEC for fmin and fmax patterns.

gcc/ChangeLog:

PR tree-optimization/105414
* config/loongarch/loongarch.md (UNSPEC_FMAX): New unspec.
(UNSPEC_FMIN): Likewise.
(fmax3): Use UNSPEC_FMAX instead of smax.
(fmin3): Use UNSPEC_FMIN instead of smin.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #14 from Jakub Jelinek  ---
cppdefault.cc has:
#ifdef FIXED_INCLUDE_DIR
/* This is the dir for fixincludes.  */
{ FIXED_INCLUDE_DIR, "GCC", 0, 0, 0,
  /* A multilib suffix needs adding if different multilibs use
 different headers.  */
#ifdef SYSROOT_HEADERS_SUFFIX_SPEC
  1
#else
  0
#endif
},
#endif
...
#ifdef NATIVE_SYSTEM_HEADER_DIR
/* /usr/include comes dead last.  */
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
#endif
where that 2 in the last column of the penultimate entry is what I think adds
for multi-arch the multiarch suffixes to /usr/include and 1 in the penultimate
column says to prefix that with sysroot.
So, I wonder if we don't want a
{ FIXED_INCLUDE_DIR, "GCC", 0, 0, 0, 2 },
entry somewhere.  SYSROOT_HEADERS_SUFFIX_SPEC is defined I think on vxworks and
mti-linux, neither of which can be multiarch, so I think we could do:
--- gcc/cppdefault.cc.jj2022-01-18 11:58:59.411984500 +0100
+++ gcc/cppdefault.cc   2022-09-28 12:11:47.923603783 +0200
@@ -74,6 +74,9 @@ const struct default_include cpp_include
 #endif
 #ifdef FIXED_INCLUDE_DIR
 /* This is the dir for fixincludes.  */
+#ifndef SYSROOT_HEADERS_SUFFIX_SPEC
+{ FIXED_INCLUDE_DIR, "GCC", 0, 0, 0, 2 },
+#endif
 { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0,
   /* A multilib suffix needs adding if different multilibs use
 different headers.  */

[Bug target/106961] Testsuite failures after Command Line Tools update to v14

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #6 from simon at pushface dot org ---
Installing the Command Line Tools 14.1 beta 3 fixes this problem.

[Bug tree-optimization/107066] New: Field initialized before ctor is mis-optimized away by DSE

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

Bug ID: 107066
   Summary: Field initialized before ctor is mis-optimized away by
DSE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

By means of user-defined new operator, it is possible that a field is
initialized before constructor.

#include 

class A {
public:
  int f1;
  int f2;

  A() : f2(2) { }

  void *operator new(size_t size)
  {
  void *mem = ::operator new(size);
  A *obj = static_cast(mem);

  obj->f1 = 1;
  return obj;
  }

};

A* foo ()
{
  return new A();
}


The original gimple code of foo() is:

struct A * foo ()
{
  void * D.2444;
  void * _9;

   :
  _9 = operator new (8); 
  MEM[(struct A *)_9].f1 = 1;
  MEM[(struct A *)_9] ={v} {CLOBBER};
  MEM[(struct A *)_9].f2 = 2;
  return _9;

}

In gimple, there exists a pseudo clobber statement marking beginning of
constructor code. Although the statement is of no side effect, it is regarded
as normal store by DSE when determining store redundancy. Consequently, DSE
thought that "MEM[(struct A *)_9].f1 = 1" was killed by "MEM[(struct A *)_9]
={v} {CLOBBER}", and removed it. After DSE pass,the foo becomes:

struct A * foo ()
{
  void * D.2444;
  void * _9;

   :
  _9 = operator new (8);
  MEM[(struct A *)_9] ={v} {CLOBBER};
  MEM[(struct A *)_9].f2 = 2;
  return _9;

}

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #15 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #13)
> I wonder how it works for Tobias then.

Bootstrap
* works on x86_64  with Ubuntu 20.04.5 LTS (focal) with glibc 2.31-0ubuntu9.9
* fails on ppc64le  with Ubuntu 18.04.3 LTS (bionic) with glibc 2.27-3ubuntu1

I have now done some debugging. The reason it works on x86-64 is that I have
there
in the $BUILD directory:
  gcc/include-fixed/bits -> x86_64-linux-gnu/bits

That matches:
  /usr/include/bits -> x86_64-linux-gnu/bits 

dpkg -S find
* the symbolic link in package libc6-dev-i386
* the real 'bits' directory in package libc6-dev:amd64


On PowerPC, I see /usr/include/powerpc64le-linux-gnu/bits but no associated
/usr/include/bits symbolic link. (The existing directory is in package
libc6-dev:ppc64el)

 * * *

Before finding this, I wondered whether --enable-multiarch makes a difference,
but it doesn't.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #16 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #14)
> ..., so I think we could do:
> --- gcc/cppdefault.cc.jj  2022-01-18 11:58:59.411984500 +0100
> +++ gcc/cppdefault.cc 2022-09-28 12:11:47.923603783 +0200

It tried this now on ppc64le with Ubuntu 18.04.3 LTS (bionic) with glibc
2.27-3ubuntu1
and - because I have used it last - with --enable-multiarch.

However, it still fails. According to strace, it searches:

/tmp/tburnus-gcc-test/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed/.
/tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed/.
/tmp/tburnus-gcc-test/gcc/../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed/powerpc64le-linux-gnu

but not
  /tmp/tburnus-gcc-test/gcc/include-fixed/powerpc64le-linux-gnu

A solution would be
  target=powerpc64le-linux-gnu
  cd $BUILD/gcc
  if [[ -d include-fixed/$target ]]; then
mkdir $target;
ln -s include-fixed/$target $target/include-fixed
  fi
or something similar in the fix-include machinery.

[Bug target/106961] Testsuite failures after Command Line Tools update to v14

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #7 from Iain Sandoe  ---
closing as invalid - because it is not a GCC bug, and now we have a newer CLT
that works.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #17 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #16)
> ln -s include-fixed/$target $target/include-fixed

That should have been:
  ln -s ../include-fixed/$target $target/include-fixed

with that change, ./gcc/xgcc -v -B`pwd`/gcc foo.c  works and shows:

#include "..." search starts here:
#include <...> search starts here:
 /tmp/tburnus-gcc-test/gcc/include
 /tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed
 /tmp/tburnus-gcc-test/gcc/include-fixed
 /usr/local/include
 /usr/include/powerpc64le-linux-gnu
 /usr/include
End of search list.
...
# 30 "/usr/include/complex.h" 2 3 4
# 1
"/tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed/bits/floatn.h" 1
3 4

and when continuing the bootstrap build, it now successfully finished with
Stage 1 and I am positive that it will also finish building Stage 2 + 3.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #18 from Jakub Jelinek  ---
You mean the #c14 change incorrectly adds
/tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed
rather than
/tmp/tburnus-gcc-test/gcc/include-fixed/powerpc64le-linux-gnu
to search path?

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-09-28

--- Comment #1 from Jonathan Wakely  ---
Reduced to remove the library dependency:

enum Cat { prvalue, lvalue, xvalue };

template
struct value_category {
// Or can be an integral or enum value
static constexpr auto value = prvalue;
};

template
struct value_category {
static constexpr auto value = lvalue;
};

template
struct value_category {
static constexpr auto value = xvalue;
};

// Double parens for ensuring we inspect an expression,
// not an entity
#define VALUE_CATEGORY(expr) value_category::value

constexpr bool global = true;
static_assert( VALUE_CATEGORY(!(!global)) == prvalue, "GCC gets this right" );

int main()
{
  bool b = true;
  if ( VALUE_CATEGORY(!(!b)) != prvalue )
throw 1;
}

[Bug target/99723] [11/12/13 Regression] arm: ICE in build_function_type during selftests

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

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

--- Comment #3 from akrl at gcc dot gnu.org ---
A fix was proposed here:

[Bug c++/107065] GCC treats rvalue as an lvalue

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jason Liam  ---
Here is another reduced demo: https://godbolt.org/z/hGhfrKrad


```
#include 
int main() {
bool b = true;
std::cout << std::is_same::value << "\n";

auto bb = (!(!b));
std::cout << std::is_same::value << "\n";
}


```

[Bug c++/107065] GCC treats rvalue as an lvalue

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Jason Liam  ---
(In reply to Jonathan Wakely from comment #1)
> Reduced to remove the library dependency:
> 
> enum Cat { prvalue, lvalue, xvalue };
> 
> template
> struct value_category {
> // Or can be an integral or enum value
> static constexpr auto value = prvalue;
> };
> 
> template
> struct value_category {
> static constexpr auto value = lvalue;
> };
> 
> template
> struct value_category {
> static constexpr auto value = xvalue;
> };
> 
> // Double parens for ensuring we inspect an expression,
> // not an entity
> #define VALUE_CATEGORY(expr) value_category::value
> 
> constexpr bool global = true;
> static_assert( VALUE_CATEGORY(!(!global)) == prvalue, "GCC gets this right"
> );
> 
> int main()
> {
>   bool b = true;
>   if ( VALUE_CATEGORY(!(!b)) != prvalue )
> throw 1;
> }

Here is another reduced demo: https://godbolt.org/z/hGhfrKrad

```
#include 
int main() {
bool b = true;
std::cout << std::is_same::value << "\n";

auto bb = (!(!b));
std::cout << std::is_same::value << "\n";
}


```

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

--- Comment #4 from Jonathan Wakely  ---
Or as a compile-time test, not run-time:

template struct is_same { static constexpr bool value = false; };
template struct is_same { static constexpr bool value = true; };

int main() {
bool b = true;
static_assert( is_same::value, "");

auto bb = (!(!b));
static_assert( is_same::value, "");
}


: In function 'int main()':
:5:52: error: static assertion failed
5 | static_assert( is_same::value, "");
  |^

[Bug fortran/107067] New: [OpenMP] ICE with metadirective block statements

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

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

Bug ID: 107067
   Summary: [OpenMP] ICE with metadirective block statements
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: parras at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53636&action=edit
Test case triggering an ICE

The current OG12 implementation handles OMP metadirectives, but it fails to
parse the following code:

```
   !$OMP begin metadirective &
   !$OMP   when ( user = { condition ( UseDevice ) } &
   !$OMP : nothing ) &
   !$OMP   default ( parallel )
   block
  call foo()
   end block
   call bar()
   !$omp end metadirective
```

The `call bar()` statement cannot be parsed properly as the parser expects the
`end block` to be immediately followed by `!$omp end metadirective`:

```
f951: internal compiler error: in parse_omp_metadirective_body, at
fortran/parse.cc:5895
0x6d6d6f parse_omp_metadirective_body
   
/scratch/pauarr3t/build_17657/src/gcc-og12-branch/gcc/fortran/parse.cc:5895
0x6d6d6f parse_executable
   
/scratch/pauarr3t/build_17657/src/gcc-og12-branch/gcc/fortran/parse.cc:6051
0x7dafb0 parse_progunit
   
/scratch/pauarr3t/build_17657/src/gcc-og12-branch/gcc/fortran/parse.cc:6349
0x7dc670 gfc_parse_file()
   
/scratch/pauarr3t/build_17657/src/gcc-og12-branch/gcc/fortran/parse.cc:6872
0x835acf gfc_be_parse_file
   
/scratch/pauarr3t/build_17657/src/gcc-og12-branch/gcc/fortran/f95-lang.cc:224
```

On the other hand, if `call bar()` comes before the block, it is parsed
correctly.

[Bug tree-optimization/107066] Field initialized before ctor is mis-optimized away by DSE

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You need -fno-lifetime-dse as documented

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Options.html#index-flifetime-dse

C++ is defined this way otherwise.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #19 from Tobias Burnus  ---
(In reply to Jakub Jelinek from comment #18)
> You mean the #c14
comment 14 (< this adds a link)

> change incorrectly adds
>   /tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed
> rather than
>   /tmp/tburnus-gcc-test/gcc/include-fixed/powerpc64le-linux-gnu
> to search path?

Maybe. Or rather: Yes, for the *being* *build* compiler (with "xgcc -B
$BUILD/gcc")
it *either* adds the wrong directory
*or* fixinclude creates the wrong directory.

However, for the *installed* compiler, we have:

#include "..." search starts here:
#include <...> search starts here:

/tmp/tburnus-gcc-test-inst/lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include
 /usr/local/include
 /tmp/tburnus-gcc-test-inst/include

/tmp/tburnus-gcc-test-inst/lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed/powerpc64le-linux-gnu

/tmp/tburnus-gcc-test-inst/lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed
 /usr/include/powerpc64le-linux-gnu
 /usr/include
End of search list.

And as the fix-include floatn.h is under
/tmp/tburnus-gcc-test-inst/lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed/powerpc64le-linux-gnu/bits/floatn.h

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #20 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #19)
> However, for the *installed* compiler, we have:
...
> And as the fix-include floatn.h is under
...

(To finish the sentence: Thus,)

the *installed* compiler *finds* the fixed-include fixed header file,
contrary to the being build compiler.

A quick testing (delete 'bits' symlink on x86-64) shows that that's due to the
patch from comment 14 - as x86-64 otherwise uses
/usr/include/x86-64*/bits/floatn.h.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #21 from Jakub Jelinek  ---
(In reply to Tobias Burnus from comment #19)
Ah, so it is then correct for the installed compiler and we just need to figure
out where the search paths for the build compiler come from and how they are
determined.

[Bug fortran/107068] New: Run-time error when reading logical arrays with a namelist

[r.m.potvliege at durham dot ac.uk via Gcc-bugs]

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

Bug ID: 107068
   Summary: Run-time error when reading logical arrays with a
namelist
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r.m.potvliege at durham dot ac.uk
  Target Milestone: ---

[Bug c++/107069] New: string assignment triggers warning

[joerg.richter--- via Gcc-bugs]

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

Bug ID: 107069
   Summary: string assignment triggers warning
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

cat > t.cc <

std::string f()
{
  std::string r;
  r = "C";
  return r;
}
EOF

/tools/pkg/gcc/12.2.0/bin/g++ -Wall -Wextra -Werror -std=gnu++20 -O2 -c -o
t.cc.o t.cc

gives:

...gcc/12.2.0/include/c++/12.2.0/bits/char_traits.h:431:56: error: 'void*
__builtin_memcpy(void*, const void*, long unsigned int)' accessing
9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 17
may overlap up to 9223372036854775813 bytes at offset -3 [-Werror=restrict]
  431 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
  |   
^

[Bug fortran/107068] Run-time error when reading logical arrays with a namelist

[r.m.potvliege at durham dot ac.uk via Gcc-bugs]

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

--- Comment #1 from Robert Potvliege  ---
Reading a logical array through a namelist triggers an (apparently) spurious
run time error in some cases. E.g., when I am compiling the following code with
gfortran,

  program test
  logical, dimension(3,3) :: flc,flp
  namelist/inputdata/flc,flp
!
  read(5,inputdata)
!
  end program test

and read the following file,

&INPUTDATA
 FLC = T,
 FLP(1,2) = T,
/

the execution stops with the error message

At line 5 of file progtest.f90 (unit = 5, file = 'stdin')
Fortran runtime error: Bad repeat count in item 1 of list input

However, there is no error for the following input file

&INPUTDATA
 FLC = T,
 FLP = T,
/

or the following one

&INPUTDATA
 FLP(1,2) = T,
/

etc. No error is produced for any of these input files if I compile this short
program with the Intel compiler I can access rather than gfortran.

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Even GCC 4.8 rejects #c4, so doesn't look like a regression.

We deduce bool& in the first decltype: finish_decltype_type gets a VAR_DECL 'b'
(that's wrong I think), id_expression_or_member_access_p is false (that is
correct).  lvalue_kind then of course reports that the VAR_DECL is an ordinary
lvalue, and we deduce to bool&, just like it were decltype((b)).  So the
problem must be that we strip both NEGATE_EXPRs.

[Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs

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

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

--- Comment #4 from David Malcolm  ---
(In reply to David Malcolm from comment #3)
> perf shows that 64% of the time is taken by this ctor:
>   shortest_paths::shortest_paths

This is in the "find shortest feasible path for a diagnostic" code.

FWIW, adding -fno-analyzer-feasibility reduces the time for me from 10 minutes
to about 4.5 minutes (better, but still far too slow), and makes it emit a
false positive.

I'm investigating where the slowdowns are.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[rdiezmail-gcc at yahoo dot de via Gcc-bugs]

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

--- Comment #11 from R. Diez  ---

> Has a solution been found for embedded systems with very limited resources?
> In this case for example, C++ exceptions can be disabled and this
> emergency pool not needed.

Contrary to popular belief, C++ exception handling does not need many
resources. I have been generating dynamic error messages in readable English
using C++ exceptions on microcontrollers with as little as 16 KiB SRAM for
years, with 'plenty' of memory to spare.

To that effect, I have been using the patch that I mentioned above. Here is an
updated URL for it:

https://github.com/rdiez/JtagDue/blob/master/Toolchain/Patches/GccDisableCppExceptionEmergencyBuffer-GCC-5.3.0.patch

[Bug c++/107065] GCC treats rvalue as an lvalue

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Jason Liam  ---
The bug was discovered here:
https://stackoverflow.com/questions/73877384/stdis-same-different-results-beween-compilers

[Bug middle-end/106776] Unexpected use-after-free warning

[drfiemost at email dot it via Gcc-bugs]

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

--- Comment #2 from Leandro Nini  ---
Oh, now I see it, it wasn't that obvious in the first test. But why is the
compiler allowed to postpone the store after deleting the pointer? Is there
some undefined behavior involved here or what?

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[dumoulin.thibaut at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Thibaut M.  ---
Thank you for the updated link!

The problem with the original code is that it malloc unconditionally at least
2.4ko on the heap. This cannot be avoided when liking with libstdc++.
This malloc is done very early, when initializing `.init_array` section (in
ResetHandler on an ARM Cortex M for example).

As 2.4ko is a lot for some embedded systems, it would be nice to avoid this
behavior.
Also, even if this code is never used in your project, none of the symbols in
eh_malloc.cc are called; the constructor of the global variable `pool
emergency_pool;` calls a non-pure functions, compiler cannot get rid of this
function.

If you do not use this code in your project, it will cost you, unconditionally,
2.4ko of heap.
This is the problem.

This patch https://gcc.gnu.org/legacy-ml/gcc-patches/2016-12/msg01158.html
seems a nice solution, it allocates a static buffer and if nobody is using it,
it can be stripped by the linker.

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
seurer@rain6p1:~/gcc/git/build/gcc-test$ cat a.f90
  use ieee_arithmetic
  integer, parameter :: k1 = &
max(ieee_selected_real_kind(precision(0.d0) + 1), kind(0.))
  integer, parameter :: k2 = &
max(ieee_selected_real_kind(precision(0._k1) + 1), kind(0.d0))

  print *, k1, k2
  end
seurer@rain6p1:~/gcc/git/build/gcc-test$ $GCC_INSTALL/bin/gfortran a.f90 &&
./a.out
  16   8

[Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs

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

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

David Malcolm  changed:

   What|Removed |Added

 Depends on||99390

--- Comment #5 from David Malcolm  ---
The real issue here is that -fanalyzer-call-summaries is off by default (due to
being buggy).  Poring over the dumps shows that without trying to summarize the
effects of calls, the analyzer is brute-forcing the exploration of the call
graph, leading to an explosion of deep paths, expensively achieving very poor
coverage.

Enabling -fanalyzer-call-summaries speeds things up from ~10 minutes to ~1m20s
(7.5x), but makes it emit lots of -Wanalyzer-use-of-uninitialized-value false
positives.  Am about to file a bug about that...

Sorry about this; I'd recommend disabling -fanalyzer on Emacs until it's
reasonable to enable -fanalyzer-call-summaries on it.

The dumps show some other issues, like the analyzer seems to be creating lots
of regions for tracking "alloca" (~45000 of them in one dump), so I may need to
also fix how alloca is handled.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99390
[Bug 99390] [meta-bug] tracker bug for call summaries in -fanalyzer

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[rdiezmail-gcc at yahoo dot de via Gcc-bugs]

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

--- Comment #13 from R. Diez  ---
It is hard to automatically tell whether nobody else is using such a
statically-allocated emergency buffer. In my case, I am using C++ exceptions,
so the linker will probably always include the buffer.

My patch makes sure that no emergency buffer is allocated. As long as your
firmware does not run out of malloc RAM, C++ exceptions continue to work fine.

About implementing a proper solution (my patch is just a workaround): There are
probably guys who want to control the size of the emergency buffer, but for
really constrained environments, I would like an option to disable it
completely.

As a bonus, the code that allocates and uses the emergency buffer could be
optimised away too, but that is not critical for me. RAM / SRAM is often tight,
but Flash/program memory (where the code resides) tends to be much bigger. So
optimising the buffer away from RAM would be enough in most scenarios.

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

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

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

--- Comment #3 from Francois-Xavier Coudert  ---
Hum, that one test for FMA is really unreliable. I think I need to remove it
altogether, it fails on x86 as well for float and double, if it also fails on
powerpc for long double, then let's get rid of it.

Can you confirm that the test pass if you apply the patch below? That will make
sure there is no failure further down the test.


diff --git a/gcc/testsuite/gfortran.dg/ieee/fma_1.f90
b/gcc/testsuite/gfortran.dg/ieee/fma_1.f90
index 34636426c98..320c73a0c3c 100644
--- a/gcc/testsuite/gfortran.dg/ieee/fma_1.f90
+++ b/gcc/testsuite/gfortran.dg/ieee/fma_1.f90
@@ -38,7 +38,6 @@
   print *, sx1 * sx2 + sx3
   print *, ieee_fma(sx1, sx2, sx3)
   if (ieee_fma(sx1, sx2, sx3) /= real(3, kind(sx1)) / 2) stop 4
-  !if (ieee_fma(sx1, sx2, sx3) == sx1 * sx2 + sx3) stop 5

   ! Double

@@ -57,7 +56,6 @@
   print *, dx1 * dx2 + dx3
   print *, ieee_fma(dx1, dx2, dx3)
   if (ieee_fma(dx1, dx2, dx3) /= real(3, kind(dx1)) / 2) stop 4
-  !if (ieee_fma(dx1, dx2, dx3) == dx1 * dx2 + dx3) stop 5

   ! Large kind 1

@@ -76,7 +74,6 @@
   print *, lx1 * lx2 + lx3
   print *, ieee_fma(lx1, lx2, lx3)
   if (ieee_fma(lx1, lx2, lx3) /= real(3, kind(lx1)) / 2) stop 4
-  if (ieee_fma(lx1, lx2, lx3) == lx1 * lx2 + lx3) stop 5

   ! Large kind 2

@@ -95,6 +92,5 @@
   print *, wx1 * wx2 + wx3
   print *, ieee_fma(wx1, wx2, wx3)
   if (ieee_fma(wx1, wx2, wx3) /= real(3, kind(wx1)) / 2) stop 4
-  if (ieee_fma(wx1, wx2, wx3) == wx1 * wx2 + wx3) stop 5

 end

[Bug c++/107070] New: GCC thinks !!b is an lvalue (bool b;)

[nir.livne at gmail dot com via Gcc-bugs]

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

Bug ID: 107070
   Summary: GCC thinks !!b is an lvalue (bool b;)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nir.livne at gmail dot com
  Target Milestone: ---

#include 

// gcc   result: 0 1 
// clang result: 1 1
// msvc  result: 1 1

int main() {
bool b = true;

// #1 GCC result with 0 while it should be 1
std::cout << std::is_same::value << "\n";

auto bb = (!(!b));
std::cout << std::is_same::value << "\n";

// #2 this should not compile
// !!b = true;
}

[Bug c++/107070] GCC thinks !!b is an lvalue (bool b;)

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Marek Polacek  ---
.

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

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||nir.livne at gmail dot com

--- Comment #7 from Marek Polacek  ---
*** Bug 107070 has been marked as a duplicate of this bug. ***

[Bug fortran/107071] New: gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

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

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

Bug ID: 107071
   Summary: gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

According to
https://gcc.gnu.org/pipermail/gcc-testresults/2022-September/768757.html
the new test gfortran.dg/ieee/modes_1.f90 fails on aarch64-suse-linux-gnu.

I do not have access to this target, so I cannot test. Could someone run it and
let me know what the output is?

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
STOP 3

[Bug analyzer/107072] New: Analyzer call summarization not taking into account side-effects of calls

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

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

Bug ID: 107072
   Summary: Analyzer call summarization not taking into account
side-effects of calls
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 99390, 107060
  Target Milestone: ---

Created attachment 53637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53637&action=edit
Reproducer reduced from PR 107060

-fanalyzer-call-summaries doesn't seem to be taking account of the side-effects
of calls; it emit lots of -Wanalyzer-use-of-uninitialized-value false positives
on the reproducer for PR 107060.

Am attaching a minimized version, which emits these false positives:

$ ./xgcc -B. -S -fanalyzer ../../src/uninit.c -fanalyzer-call-summaries
../../src/uninit.c: In function ‘fetch_string_char_advance’:
../../src/uninit.c:52:7: warning: use of uninitialized value ‘chlen’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   52 | b += chlen;
  |   ^~
  ‘fetch_string_char_advance’: events 1-5
|
|   49 |   if (STRING_MULTIBYTE(string)) {
|  |  ~   
|  |  |
|  |  (3) following ‘true’ branch...
|   50 | int chlen;
|  | ^
|  | |
|  | (1) region created on stack here
|  | (2) capacity: 4 bytes
|   51 | output = string_char_and_length(chp, &chlen);
|  |  ~~~
|  |  |
|  |  (4) ...to here
|   52 | b += chlen;
|  |   ~~ 
|  |   |
|  |   (5) use of uninitialized value ‘chlen’ here
|
../../src/uninit.c: In function ‘fetch_string_char_as_multibyte_advance’:
../../src/uninit.c:70:7: warning: use of uninitialized value ‘chlen’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
   70 | b += chlen;
  |   ^~
  ‘fetch_string_char_as_multibyte_advance’: events 1-5
|
|   67 |   if (STRING_MULTIBYTE(string)) {
|  |  ~   
|  |  |
|  |  (3) following ‘true’ branch...
|   68 | int chlen;
|  | ^
|  | |
|  | (1) region created on stack here
|  | (2) capacity: 4 bytes
|   69 | output = string_char_and_length(chp, &chlen);
|  |  ~~~
|  |  |
|  |  (4) ...to here
|   70 | b += chlen;
|  |   ~~ 
|  |   |
|  |   (5) use of uninitialized value ‘chlen’ here
|

...despite string_char_and_length writing back to chlen (aka *length) on every
possible outcome.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99390
[Bug 99390] [meta-bug] tracker bug for call summaries in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060
[Bug 107060] -fanalyzer unbearably slow when compiling GNU Emacs

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #2 from Francois-Xavier Coudert  ---
Oups, there are two lines that trigger this in the test. Can you try with this
patch?

diff --git a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
index b6ab28847f7..205c47f3800 100644
--- a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
+++ b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
@@ -81,15 +81,15 @@ program foo
   ! Check again
   if (ieee_support_underflow_control()) then
 call ieee_get_underflow_mode(f)
-if (.not. f) stop 3
+if (.not. f) stop 4
   endif
   if (ieee_support_rounding(ieee_down)) then
 call ieee_get_rounding_mode(rmode)
-if (rmode /= ieee_down) stop 4
+if (rmode /= ieee_down) stop 5
   endif
   if (ieee_support_halting(ieee_overflow)) then
 call ieee_get_halting_mode(ieee_overflow, f)
-if (f) stop 5
+if (f) stop 6
   endif

 end program foo

[Bug fortran/107062] [13 regression] gfortran.dg/ieee/fma_1.f90 fails after r13-2577-g7c4c65d11469d2

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

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

--- Comment #4 from seurer at gcc dot gnu.org ---
With that patch the test case passes.

[Bug tree-optimization/107066] Field initialized before ctor is mis-optimized away by DSE

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

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

--- Comment #2 from Andrew Pinski  ---
See https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse also. Which
documented when the change happened back in GCC 6.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #22 from joseph at codesourcery dot com  ---
Even with the fixincluded headers properly being used, the powerpc64le 
issue still applies because of the issue I noted in 
https://sourceware.org/pipermail/libc-alpha/2022-September/142259.html 
with certain required changes to the powerpc version of bits/floatn.h not 
being covered by the fixincludes fixes added.  You get errors such as:

/scratch/jmyers/glibc-bot/build/compilers/powerpc64le-linux-gnu/gcc/gcc/include-fixed/bits/floatn.h:88:9:
error: multiple types in one declaration
   88 | typedef __float128 _Float128;
  | ^~

while building libstdc++.  (Whereas other architectures can build GCC OK 
but then run into failures building glibc that my glibc patch is intended 
to address.)

[Bug testsuite/107073] New: New test case gcc.dg/tree-ssa/gen-vect-34.c fails

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

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

Bug ID: 107073
   Summary: New test case gcc.dg/tree-ssa/gen-vect-34.c fails
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:ca8f4e8af148694ae2fd444a0cdcf713910d23fd, r13-2333-gca8f4e8af14869

This fails on powerpc64 big endian.

make  -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/gen-vect-34.c"
FAIL: gcc.dg/tree-ssa/gen-vect-34.c scan-tree-dump-times vect "vectorized 1
loops" 1
# of expected passes1
# of unexpected failures1


commit ca8f4e8af148694ae2fd444a0cdcf713910d23fd
Author: konglin1 
Date:   Thu Sep 1 14:40:42 2022 +0800

middle-end: Add MULT_EXPR recognition for cond scalar reduction

[Bug fortran/107074] New: ICE: Bad IO basetype (8)

[gscfq--- via Gcc-bugs]

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

Bug ID: 107074
   Summary: ICE: Bad IO basetype (8)
   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 :
(a is a procedure/function)


$ cat z1.f90
program p
   implicit none
   integer :: a
   print *, a(1)
   print *, merge(a, a, .true.)
end


$ cat z2.f90
program p
   implicit none
   integer :: a
   print *, a()
   print *, merge(a, a, .true.)
end


$ gfortran-13-20220925 -c z1.f90
f951: internal compiler error: Bad IO basetype (8)
0x7f4459 gfc_report_diagnostic
../../gcc/fortran/error.cc:883
0x7f5fd7 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.cc:1503
0x9308f6 transfer_expr
../../gcc/fortran/trans-io.cc:2532
0x934b3e gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.cc:2686
0x8b1cd7 trans_code
../../gcc/fortran/trans.cc:2170
0x9323d2 build_dt
../../gcc/fortran/trans-io.cc:2051
0x8b1cf7 trans_code
../../gcc/fortran/trans.cc:2142
0x8e95d9 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7655
0x85afae translate_all_program_units
../../gcc/fortran/parse.cc:6671
0x85afae gfc_parse_file()
../../gcc/fortran/parse.cc:6977
0x8a925f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/107075] New: ICE in get, at cgraph.h:461

[gscfq--- via Gcc-bugs]

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

Bug ID: 107075
   Summary: ICE in get, at cgraph.h:461
   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 :
(both valid, works without block construct)


$ cat z1.f90
program p
   implicit none
   integer, target :: a(3)
   block
  integer, pointer :: z => a(2)
  a = [1, 2, 3]
  z = 7
  print *, a, z
   end block
end


$ cat z2.f90
program p
   implicit none
   integer, target :: a(3)
   integer, pointer :: z => a(2)
   a = [1, 2, 3]
   z = 7
   print *, a, z
end


$ gfortran-13-20220925 z2.f90 && ./a.out
   1   7   3   7


$ gfortran-13-20220925 -c z1.f90
f951: internal compiler error: in get, at cgraph.h:461
0x131212f symtab_node::get(tree_node const*)
../../gcc/cgraph.h:458
0x131212f varpool_node::get(tree_node const*)
../../gcc/cgraph.h:2785
0x131212f varpool_node::get_create(tree_node*)
../../gcc/varpool.cc:145
0xa1e20f record_reference
../../gcc/cgraphbuild.cc:82
0x12ad193 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11249
0xa1ecb5 record_references_in_initializer(tree_node*, bool)
../../gcc/cgraphbuild.cc:386
0x1313037 varpool_node::analyze()
../../gcc/varpool.cc:537
0xa2506e analyze_functions
../../gcc/cgraphunit.cc:1294
0xa2624d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2500

[Bug c/107076] New: ICE in gen_untyped_call, at config/i386/i386.md:15992

[gscfq--- via Gcc-bugs]

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

Bug ID: 107076
   Summary: ICE in gen_untyped_call, at config/i386/i386.md:15992
   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: ---

Affects versions down to r6 :


$ cat z1.c
void *h ();
void g ();
__attribute__ ((target_clones ("default", "arch=slm")))
void f ()
{
  g (__builtin_apply(h(), __builtin_apply_args(), 0));
}


$ gcc-13-20220925 -c z1.c
during RTL pass: expand
z1.c: In function 'f.arch_slm':
z1.c:6:3: internal compiler error: Segmentation fault
6 |   g (__builtin_apply(h(), __builtin_apply_args(), 0));
  |   ^~~
0xce3e8f crash_signal
../../gcc/toplev.cc:314
0x14a2403 gen_untyped_call(rtx_def*, rtx_def*, rtx_def*)
../../gcc/config/i386/i386.md:15992
0xff0da8 target_gen_untyped_call
../../gcc/config/i386/i386.md:16199
0x860621 expand_builtin_apply
../../gcc/builtins.cc:1750
0x86d346 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.cc:7521
0x991cd0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11689
0x99ba63 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.cc:6155
0x99d06e expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.cc:5876
0x88dcc2 expand_call_stmt
../../gcc/cfgexpand.cc:2829
0x88dcc2 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3880
0x88dcc2 expand_gimple_stmt
../../gcc/cfgexpand.cc:4044
0x892cf7 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6096
0x8957be execute
../../gcc/cfgexpand.cc:6822

[Bug c/107077] New: ICE in get_expr_operands, at tree-ssa-operands.cc:940

[gscfq--- via Gcc-bugs]

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

Bug ID: 107077
   Summary: ICE in get_expr_operands, at tree-ssa-operands.cc:940
   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 r9 and file gcc.dg/vect/vect-cond-arith-2.c :


$ gcc-13-20220925 -c vect-cond-arith-2.c -m32 -std=c89 -fgimple
unhandled expression in get_expr_operands():
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ff51aceb498 precision:64
pointer_to_this >

arg:0 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ff51aceb540 precision:80
pointer_to_this >
constant 0.0>
vect-cond-arith-2.c:20:25 start: vect-cond-arith-2.c:20:25 finish:
vect-cond-arith-2.c:20:27>

vect-cond-arith-2.c: In function 'neg_xi':
vect-cond-arith-2.c:36:2: internal compiler error: in get_expr_operands, at
tree-ssa-operands.cc:940
   36 |  __BB(3):
  |  ^~~~
0x10bcb61 operands_scanner::get_expr_operands(tree_node**, int)
../../gcc/tree-ssa-operands.cc:940
0x10bd8d5 operands_scanner::parse_ssa_operands()
../../gcc/tree-ssa-operands.cc:990
0x10bee21 operands_scanner::build_ssa_operands()
../../gcc/tree-ssa-operands.cc:1005
0x10bf650 update_stmt_operands(function*, gimple*)
../../gcc/tree-ssa-operands.cc:1147
0xb35df4 update_stmt_if_modified
../../gcc/gimple-ssa.h:185
0xb35df4 update_modified_stmts(gimple*)
../../gcc/gimple-iterator.cc:58
0xb35f14 gsi_insert_seq_after(gimple_stmt_iterator*, gimple*,
gsi_iterator_update)
../../gcc/gimple-iterator.cc:332
0x85b5bb c_parser_gimple_compound_statement
../../gcc/c/gimple-parser.cc:584
0x85cbf9 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
../../gcc/c/gimple-parser.cc:253
0x84626c c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2548
0x85141f c_parser_external_declaration
../../gcc/c/c-parser.cc:1789
0x851d4b c_parser_translation_unit
../../gcc/c/c-parser.cc:1662
0x851d4b c_parse_file()
../../gcc/c/c-parser.cc:23694
0x8c1631 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1255

[Bug c/107077] __GIMPLE vs excess precision setting in std C with -m32 on x86_64 (ICE)

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

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

--- Comment #1 from Andrew Pinski  ---
The problem here is the C front-end adds a wrapper for double, float types (and
sometimes half float types) and the gimple front-end part does not understand
that.

[Bug target/107061] ENCODEKEY128 clobbers xmm4-xmm6

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

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

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

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

commit r13-2919-gdb288230db55dc1ff626f46c708b555847013a41
Author: H.J. Lu 
Date:   Tue Sep 27 16:19:11 2022 -0700

i386: Mark XMM4-XMM6 as clobbered by encodekey128/encodekey256

encodekey128 and encodekey256 operations clear XMM4-XMM6.  But it is
documented that XMM4-XMM6 are reserved for future usages and software
should not rely upon them being zeroed.  Change encodekey128 and
encodekey256 to clobber XMM4-XMM6.

gcc/

PR target/107061
* config/i386/predicates.md (encodekey128_operation): Check
XMM4-XMM6 as clobbered.
(encodekey256_operation): Likewise.
* config/i386/sse.md (encodekey128u32): Clobber XMM4-XMM6.
(encodekey256u32): Likewise.

gcc/testsuite/

PR target/107061
* gcc.target/i386/keylocker-encodekey128.c: Don't check
XMM4-XMM6.
* gcc.target/i386/keylocker-encodekey256.c: Likewise.

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

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

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> (In reply to Steve Kargl from comment #6)
> > Yes, that would work!  I was thinking of something more complex
> > such as looking at the types of the operand(s), but simplification
> > probably handles +1 and -1 correctly and punts on +'1' and -'1'.
> 
> I played some more and found that we would regress on e.g.
> 
>   print *, [real :: 1, +real(2.0)]
> 
> while
> 
>   print *, [real :: 1,  real(2.0)]
> 
> is fine.
> 
> So we need a better solution...

This is the type of solution I had in mind.  It allows the above
and catches +.false. and -.true.

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..8b689f28612 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1205,6 +1205,21 @@ walk_array_constructor (gfc_typespec *ts,
gfc_constructor_base head)
   for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
 {
   e = c->expr;
+
+  /* Special case unary operators to catch [real :: +'1'].  */
+  if (e->expr_type == EXPR_OP && e->ts.type == BT_UNKNOWN)
+   {
+ gfc_expr *op1 = e->value.op.op1;
+ if ((op1->value.op.op == INTRINSIC_UMINUS
+  || op1->value.op.op == INTRINSIC_UPLUS)
+ && !gfc_numeric_ts (&op1->ts))
+   {
+ gfc_error("Invalid operand of unary operator at %L",
+   &op1->where);
+ return MATCH_ERROR;
+   }
+   }
+
   if (e->expr_type == EXPR_ARRAY && e->ts.type == BT_UNKNOWN
  && !e->ref && e->value.constructor)
{

Unfortunately, it ICEs with 

 print *, [real :: 1, +(.true)]

[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|fortran |libfortran
   Last reconfirmed||2022-09-28

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

Renaming the second variable (e.g. flp -> xlp) works around the problem,
as well as interchanging the lines in the namelist input.

It appears that while scanning the namelist input we first see the T,
then F, for which we try to determine if it means .false. or is part of
a variable name, and then possibly screw up because we see a comma when
referring to an element of rank-2 array flp.

There is also no error when using a rank-1 array for flp and referring
to flp(2) etc.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #23 from Tobias Burnus  ---
Regarding the $BUILD/gcc/include-fixed and xgcc -B $BUILD/gcc:

In gcc.cc's driver_handle_option:

add_prefix (&include_prefixes, arg, NULL,
PREFIX_PRIORITY_B_OPT, 0, 0);
Adds "$BUILD/gcc/" to the prefix list in include_prefix.plist (priority =
PREFIX_PRIORITY_B_OPT, require_machine_suffix = os_multilib = 0)
the include_prefixes.name is "include".

This is later processed in do_spec_1 as:
  info.option = "-isystem";
  info.append = "include";
...
  for_each_path (&include_prefixes, false, info.append_len,
 spec_path, &info);
...
  info.append = "include-fixed";
  for_each_path (&include_prefixes, false, info.append_len,
 spec_path, &info);
which in turn runs with ( = "$BUILD/gcc/"):

  /x86_64-pc-linux-gnu/13.0.0/
  /x86_64-linux-gnu/
  

It also sets -iprefix $BUILD/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/
 -isystem $BUILD/gcc/{include,include-fixed}

Without -B, include_prefix.plist is NULL and also no -iprefix is set. Thus, cc1
has to find the paths itself. – The iprefix does not really matter, except that
with the installed compiler, the include-fixed can be found at
  /include-fixed
which is $INSTALL/lib/gcc/$target/13.0.0/include-fixed
and is part of the 'cpp_include_defaults' array.

With the in-build compiler,  $BUILD/lib/gcc/$target/13.0.0/include-fixed
is checked for - but does not exist.


The additionally specified -isystem is processed - but not under the multiarch
processing. 

 * * *

Thus, one possibility that should work as well is to create the include-fixed
not under gcc/ but under lib/gcc/$target/$version/include-fixed

Or to change the   for_each_path + spec_path such that it puts "include-fixed'
between
plist->name and the multiarch and then uses "" as suffix (alias info.append)

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #24 from Jakub Jelinek  ---
(In reply to jos...@codesourcery.com from comment #22)
> Even with the fixincluded headers properly being used, the powerpc64le 
> issue still applies because of the issue I noted in 
> https://sourceware.org/pipermail/libc-alpha/2022-September/142259.html 
> with certain required changes to the powerpc version of bits/floatn.h not 
> being covered by the fixincludes fixes added.  You get errors such as:
> 
> /scratch/jmyers/glibc-bot/build/compilers/powerpc64le-linux-gnu/gcc/gcc/
> include-fixed/bits/floatn.h:88:9: error: multiple types in one declaration
>88 | typedef __float128 _Float128;
>   | ^~
> 
> while building libstdc++.  (Whereas other architectures can build GCC OK 
> but then run into failures building glibc that my glibc patch is intended 
> to address.)

Posted patch for this in
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602431.html

[Bug fortran/107074] ICE: Bad IO basetype (8)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

(gdb) p ts->type 
$3 = BT_PROCEDURE

We don't have an implementation for printing the address(?) of a procedure,
which is what NVidia does.

Intel does not like the code, but for different reasons.

Looking at the standard, I only found:

C1233 (R1217) An expression that is an output-item shall not have a value that
is a procedure pointer.

While a is not a procedure pointer, I don't see why such a procedure reference
can be allowed.

[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243

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

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #8)
> (In reply to anlauf from comment #7)
> > (In reply to Steve Kargl from comment #6)
> > > Yes, that would work!  I was thinking of something more complex
> > > such as looking at the types of the operand(s), but simplification
> > > probably handles +1 and -1 correctly and punts on +'1' and -'1'.
> > 
> > I played some more and found that we would regress on e.g.
> > 
> >   print *, [real :: 1, +real(2.0)]
> > 
> > while
> > 
> >   print *, [real :: 1,  real(2.0)]
> > 
> > is fine.
> > 
> > So we need a better solution...
> 
> This is the type of solution I had in mind.  It allows the above
> and catches +.false. and -.true.
> 
> diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
> index bbdb5b392fc..8b689f28612 100644
> --- a/gcc/fortran/array.cc
> +++ b/gcc/fortran/array.cc
> @@ -1205,6 +1205,21 @@ walk_array_constructor (gfc_typespec *ts,
> gfc_constructor_base head)
>for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
>  {
>e = c->expr;
> +
> +  /* Special case unary operators to catch [real :: +'1'].  */
> +  if (e->expr_type == EXPR_OP && e->ts.type == BT_UNKNOWN)
> + {
> +   gfc_expr *op1 = e->value.op.op1;
> +   if ((op1->value.op.op == INTRINSIC_UMINUS
> +|| op1->value.op.op == INTRINSIC_UPLUS)
> +   && !gfc_numeric_ts (&op1->ts))
> + {
> +   gfc_error("Invalid operand of unary operator at %L",
> + &op1->where);
> +   return MATCH_ERROR;
> + }
> + }
> +
>if (e->expr_type == EXPR_ARRAY && e->ts.type == BT_UNKNOWN
> && !e->ref && e->value.constructor)
>   {
> 
> Unfortunately, it ICEs with 
> 
>  print *, [real :: 1, +(.true)]


This catches the parenthesis.

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..21027844f84 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -1205,6 +1205,24 @@ walk_array_constructor (gfc_typespec *ts,
gfc_constructor_base head)
   for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
 {
   e = c->expr;
+
+  /* Special case unary operators to catch [real :: +'1'].  */
+  if (e->expr_type == EXPR_OP && e->ts.type == BT_UNKNOWN)
+   {
+ gfc_expr *op1 = e->value.op.op1;
+ if ((op1->value.op.op == INTRINSIC_UMINUS
+   || op1->value.op.op == INTRINSIC_UPLUS
+   || (op1->expr_type == EXPR_OP
+   && op1->value.op.op == INTRINSIC_PARENTHESES))
+ && (op1->ts.type == BT_CHARACTER
+ || op1->ts.type == BT_LOGICAL))
+   {
+ gfc_error("Invalid operand of unary operator at %L",
+   &op1->where);
+ return MATCH_ERROR;
+   }
+   }
+
   if (e->expr_type == EXPR_ARRAY && e->ts.type == BT_UNKNOWN
  && !e->ref && e->value.constructor)
{

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #25 from Tobias Burnus  ---
(In reply to jos...@codesourcery.com from comment #22)
> with certain required changes to the powerpc version of bits/floatn.h not 
> being covered by the fixincludes fixes added.

Jakub has posted a patch for this one:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602431.html

(Side note: As I have glibc 2.27 on PowerPC and the "#   if __LDBL_MANT_DIG__
== 113"
change went into 2.28, the pattern matching did work here.)

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

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

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

--- Comment #26 from Jakub Jelinek  ---
(In reply to Tobias Burnus from comment #23)
> Regarding the $BUILD/gcc/include-fixed and xgcc -B $BUILD/gcc:
> 
> In gcc.cc's driver_handle_option:
> 
> add_prefix (&include_prefixes, arg, NULL,
> PREFIX_PRIORITY_B_OPT, 0, 0);
> Adds "$BUILD/gcc/" to the prefix list in include_prefix.plist (priority =
> PREFIX_PRIORITY_B_OPT, require_machine_suffix = os_multilib = 0)
> the include_prefixes.name is "include".
> 
> This is later processed in do_spec_1 as:
>   info.option = "-isystem";
>   info.append = "include";
> ...
>   for_each_path (&include_prefixes, false, info.append_len,
>  spec_path, &info);
> ...
>   info.append = "include-fixed";
>   for_each_path (&include_prefixes, false, info.append_len,
>  spec_path, &info);
> which in turn runs with ( = "$BUILD/gcc/"):
>   
>   /x86_64-pc-linux-gnu/13.0.0/
>   /x86_64-linux-gnu/
>   
> 
> It also sets -iprefix $BUILD/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/
>  -isystem $BUILD/gcc/{include,include-fixed}

Well, the upper directories to include/include-fixed should stay as they are,
that is how to find the include-fixed directory.
But for multi-arch we need to search both include-fixed/
and include-fixed, so I think we need in addition to the comment 14 patch
also (completely untested):
--- gcc/gcc.cc  2022-09-23 09:02:56.809314447 +0200
+++ gcc/gcc.cc  2022-09-28 21:02:29.751933657 +0200
@@ -6400,6 +6400,18 @@ do_spec_1 (const char *spec, int inswitc
  if (*sysroot_hdrs_suffix_spec)
info.append = concat (info.append, dir_separator_str,
  multilib_dir, NULL);
+ else if (multiarch_dir)
+   {
+ /* For multiarch, search include-fixed/
+before include-fixed.  */
+ info.append = concat (info.append, dir_separator_str,
+   multiarch_dir, NULL);
+ info.append_len = strlen (info.append);
+ for_each_path (&include_prefixes, false, info.append_len,
+spec_path, &info);
+
+ info.append = "include-fixed";
+   }
  info.append_len = strlen (info.append);
  for_each_path (&include_prefixes, false, info.append_len,
 spec_path, &info);
It is roughly what the comment 14 patch does, just in a different spot.

[Bug fortran/107074] ICE: Bad IO basetype (8)

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
We also crash in the same place on:

program p
  implicit none
  procedure(real), pointer :: a
  print *, merge(a, a, .true.)
end

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[manuel.lauss at googlemail dot com via Gcc-bugs]

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

--- Comment #27 from Manuel Lauss  ---
(In reply to Jakub Jelinek from comment #24)
> (In reply to jos...@codesourcery.com from comment #22)
> > Even with the fixincluded headers properly being used, the powerpc64le 
> > issue still applies because of the issue I noted in 
> > https://sourceware.org/pipermail/libc-alpha/2022-September/142259.html 
> > with certain required changes to the powerpc version of bits/floatn.h not 
> > being covered by the fixincludes fixes added.  You get errors such as:
> > 
> > /scratch/jmyers/glibc-bot/build/compilers/powerpc64le-linux-gnu/gcc/gcc/
> > include-fixed/bits/floatn.h:88:9: error: multiple types in one declaration
> >88 | typedef __float128 _Float128;
> >   | ^~
> > 
> > while building libstdc++.  (Whereas other architectures can build GCC OK 
> > but then run into failures building glibc that my glibc patch is intended 
> > to address.)
> 
> Posted patch for this in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602431.html

for me the x86-64 build remains broken the same way as the ppc64 build.

[Bug fortran/107075] ICE in get, at cgraph.h:461

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Small variation:

program p
  implicit none
  integer, target :: a(3)
! save :: a
  a = [1, 2, 3]
  block
integer, pointer :: z => a(2)
z = 7
  end block
end

Uncommenting the 'save' also avoids the ICE, as does adding -fno-automatic .

[Bug c++/107069] string assignment triggers warning

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

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

--- Comment #1 from Jonathan Wakely  ---
This is a dup, but I don't have the PR number right now.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #14 from Jonathan Wakely  ---
(In reply to R. Diez from comment #13)
> About implementing a proper solution (my patch is just a workaround): There
> are probably guys who want to control the size of the emergency buffer, but
> for really constrained environments, I would like an option to disable it
> completely.

Yeah, tunable size would be good to do as part of PR 88264, but having a
build-time configuration to disable it completely is also valuable. And we can
do that more easily.

Let's try to do that for GCC 13.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Thibaut M. from comment #10)
> > see the "performance of exception handling" / "size of exception handling"
> > thread in this month's archive of the gcc mailing list
> I was not able to find the thread about "exception handling" of 2020-05,
> could you point it out or detail the conclusion please?

This thread:
https://gcc.gnu.org/pipermail/gcc/2020-May/thread.html#232358

[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist

[r.m.potvliege at durham dot ac.uk via Gcc-bugs]

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

--- Comment #3 from Robert Potvliege  ---
Thanks for looking into this so quickly and for the work-round.

[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist

[r.m.potvliege at durham dot ac.uk via Gcc-bugs]

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

--- Comment #4 from Robert Potvliege  ---
Thanks for looking into this so quickly and for the work-round.

[Bug target/64215] -Os misses an opportunity to merge two ret instructions

[tommy_murphy at hotmail dot com via Gcc-bugs]

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

Tommy Murphy  changed:

   What|Removed |Added

 CC||tommy_murphy at hotmail dot com

--- Comment #2 from Tommy Murphy  ---
FWIW this issue was also noticed in the context of the RISC-V GCC toolchain:

https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1048

[Bug target/64215] -Os misses an opportunity to merge two ret instructions

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

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

--- Comment #3 from Andrew Pinski  ---
Hmm, I thought this would have been fixed by r13-2871-g1b74b5cb4e9d71 but it
was not ...

[Bug lto/107078] New: LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

Bug ID: 107078
   Summary: LTO is causing that firebird build is core dumping
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kloczko.tomasz at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

firebird  4.0.2 and gcc-c++ 12.2.1-2 from fedora rawhide.
Build is crashing with sigsegv on execution of the linked binary

Quote from firebird maintainer comment:
"That's almost for sure (99%) pure virtual function call. Usual bug for
dtor/ctor - but I doubt half-constructed node was passed into node
copier. I try to lower compiler optimization level first of all in such
cases (taking into an account that this stuff builds and works OK for
some years)."

More details is in https://github.com/FirebirdSQL/firebird/issues/7308

I found that fedora spec file has disabled LTO as well with comment

# firebird is mis-compiled when LTO is enabled. A root
# cause analysis has not yet been completed. Reported upstream.
# Disable LTO for now

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

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

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

--- Comment #17 from Thomas Rodgers  ---
Created attachment 53638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53638&action=edit
benchmark main.cc

[Bug c++/107079] New: ICE initializing lifetime-extended constexpr variable that stores its this pointer

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 107079
   Summary: ICE initializing lifetime-extended constexpr variable
that stores its this pointer
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/5asqcnoMe.

```C++
struct X {
  const X* x = this;
};
constexpr const X& x = X{};
```

```
:4:26: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.cc:7591
4 | constexpr const X& x = X{};
  |  ^
0x23507de internal_error(char const*, ...)
???:0
0xa9ea08 fancy_abort(char const*, int, char const*)
???:0
0xd4f2da store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0xb78f38 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0xc786f7 c_parse_file()
???:0
0xdb4a19 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1
```

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

[valera.mironow at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Mkkt Bkkt  ---
Thanks for provide source of your benchmarks!

Can you also provide some example of usage atomic::notify where this
optimization is needed?

If it exists I think you right and it is necessary.

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

[valera.mironow at gmail dot com via Gcc-bugs]

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

--- Comment #19 from Mkkt Bkkt  ---
An example with a futex or other syscall would also work, because atomic::wait
is still not widely used.

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |12.2.1

--- Comment #1 from Andrew Pinski  ---
Try -O2 -fno-strict-aliasing with -flto.

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Tomasz Kłoczko from comment #0)
> I found that fedora spec file has disabled LTO as well with comment
> 
> # firebird is mis-compiled when LTO is enabled. A root
> # cause analysis has not yet been completed. Reported upstream.
> # Disable LTO for now

https://src.fedoraproject.org/rpms/firebird/c/4c04d2ce892bcf0d2e7015dbeeb6069789ed4396

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

[valera.mironow at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Mkkt Bkkt  ---
My main concern with this optimization it's not zero-overhead.

It's not necessary when we expect we have some waiters, in that case it just
additional synchronization and contention in waiter pool (that have small fixed
size, just imagine system with 100+ cores, if we have > 16 waiting threads some
of them make fetch_add/sub on the same atomic, that can be expensive,
especially on numa)

And at the same time, I don't understand when I need to notify and cannot know
notification not needed.
I don't understand when it useful.

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

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

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

--- Comment #21 from Thomas Rodgers  ---
(In reply to Mkkt Bkkt from comment #16)
> > it with sarcasm
> 
> I started with sarcasm because you restart this thread with some doubtful
> benchmarks without code for them.
> 
> I think it's very disrespectfully.

I wasn't sarcastic in what I posted. As I noted, this question has come up
before in different contexts, Bugzilla is a useful historical archive, so
updating this issue with my reasoning and a bit of data was primarily a capture
task.

So, let's try this again.

I did not post the original source because it required hacking on the libstdc++
headers. I have posted a version that does not require that, the results are
identical.

In this test, it is the example Jonathan cited in #14; incrementing an atomic
int and calling notify.

This isn't about semaphore or any other synchronization primitive. Those types
are free to make different choices that may be more appropriate to the
constrained usage of the type just like Lewis' lightweight manual reset event
does (I will also note that Lewis has reviewed this implementation, and has
written a paper to be discussed at the Fall meeting, p2616). 

There are, as Jonathan has pointed out, use cases where notify can and will be
called without a notifier having any way to determine it will wake a waiter.
One example I, as the person that is going to have to implement C++26 executors
care about is a wait free work-stealing deque, it certainly doesn't require
anything more than spinning for work on an empty queue to be algorithmically
correct, but after spinning on an empty queue, making the rounds trying to
steal work from other deques, maybe spinning a bit more, just to be sure, the
de-queuing thread which hasn't been able to acquire more work is probably going
to want to enter a wait until such time as it knows it can do productive work.
Another thread pushing work into that queue won't be able to determine if the
dequeue-ing thread is spinning for new work, work stealing, or has entered a
wait, but atomic::notify() does know that, and can avoid penalizing the
thread submitting work with a syscall, if there is no thread in a wait on the
other end of the deque, which is the expected case for this algorithm.

p1135 was the paper that added atomic wait/notify. One of the co-authors of
that paper wrote the libc++ implementation. That implementation, as with
libstdc++, is not simply a wrapper over the underlying platform's wait
primitive. It has two 'backends', an exponentially timed backoff and ulock
wait/wake. libstdc++ currently has a Futex and condvar backend. Both
implementations make the choice of having a short-term spinning strategy and
long term waiting strategy (spinning, futex/ulock, condvar).

I have confirmed with the libc++ implementation's author, (who also chairs the
C++ committee's Concurrency and Parallelism study group), that it was never the
intention of p1135 or the subsequently standardized language in C++20 to imply
that wait/notify were direct portable analogs to the platform's waiting
primitives. There are users, such as yourself that want exactly that, there are
other users (like in my prior industry) where busy waiting is the desired
strategy, and in between those two choices are people who want it to work as
advertised in the standard, and to do so 'efficiently'. Both libc++ and
libstdc++ take a balanced approach somewhere between always going to OS and
always spinning.

There is an open question here that your original issue raises -

* At what point do collisions on the waiter pool, with the cache invalidation
traffic and spurious wakeups that result, swamp the gain of doing this empty
waiter check on notify?

I also, made a comment about the 'size of the waiter pool not withstanding'. I
chose a smaller size than libc++ chose, in part because Jonathan and I did not
want to make any sort of ABI commitment until this had been in a few GCC
releases. This implementation is header only at present, and still considered
experimental. libc++ committed to an ABI early.

In the sizing of the libc++ waiter pool there is the comment that 'there is no
magic in this value'. 

Not only is there no magic, there is no test of any sort that I have done, or
that has been done on libc++ to determine what effect different size pools have
under different load scenarios. So, all of it is a guess at this point. I will
likely match libc++ when I do move this into the .so.

Finally, in the most recent mailing there is p2643 which proposes additional
changes to atomic waiting. One proposal is to add a 'hinted' wait that can
allow the caller to steer the choices atomic wait/notify uses. I have conferred
with the other authors of the paper and this latter option is not without
controversy, and likely some sharp edges for the user, but I plan to raise the
discussion at the Fall WG21 meeting to see what the other members of SG1 think.

[Bug target/64215] -Os misses an opportunity to merge two ret instructions

[tommy_murphy at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from Tommy Murphy  ---
I meant to say that maybe the target needs to be widened/generalised beyond
just "Target:   x86_64-*-*"? As per my previous comment and link, the same
issue has been observed with RISC-V and this comment also mentions it being
observed with AVR and MIPS64:

https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1048#issuecomment-1091943956

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

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

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

--- Comment #22 from Thomas Rodgers  ---
(In reply to Mkkt Bkkt from comment #20)
> My main concern with this optimization it's not zero-overhead.
> 
> It's not necessary when we expect we have some waiters, in that case it just
> additional synchronization and contention in waiter pool (that have small
> fixed size, just imagine system with 100+ cores, if we have > 16 waiting
> threads some of them make fetch_add/sub on the same atomic, that can be
> expensive, especially on numa)
> 
> And at the same time, I don't understand when I need to notify and cannot
> know notification not needed.
> I don't understand when it useful.

You are correct, it is not zero overhead. It also isn't clear what those
overheads are, either. As I noted in comment #21, there is no test over a
variety of workloads to inform this discussion, either.

Your example of '100+ core' systems especially on NUMA is certainly a valid
one. I would ask, at what point do those collisions and the resulting cache
invalidation traffic swamp the cost of just making the syscall? I do plan to
put these tests together, because there is another algorithm that I am
exploring, that I believe will reduce the likelihood of spurious wakeups, and
achieves the same result as this particular approach, without generating the
same invalidation traffic. At this point, I don't anticipate doing that work
until after GCC13 stage1 closes.

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

[valera.mironow at gmail dot com via Gcc-bugs]

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

--- Comment #23 from Mkkt Bkkt  ---
(In reply to Thomas Rodgers from comment #21)
> I wasn't sarcastic in what I posted. As I noted, this question has come up
> before in different contexts, Bugzilla is a useful historical archive, so
> updating this issue with my reasoning and a bit of data was primarily a
> capture task.

Ok, sorry

> In this test, it is the example Jonathan cited in #14; incrementing an
> atomic int and calling notify.

incrementing atomic int here doesn't touch waiter pool atomic.
I think in reality it possible that you have contention between load in notify
and fetch_add/sub in some wait (maybe on other atomics)

> This isn't about semaphore or any other synchronization primitive. Those
> types are free to make different choices that may be more appropriate to the
> constrained usage of the type just like Lewis' lightweight manual reset
> event does (I will also note that Lewis has reviewed this implementation,
> and has written a paper to be discussed at the Fall meeting, p2616). 

Ok, but it just means at least before C++26 devs should use own kludge.

> There are, as Jonathan has pointed out, use cases where notify can and will
> be called without a notifier having any way to determine it will wake a
> waiter. One example I, as the person that is going to have to implement
> C++26 executors care about is a wait free work-stealing deque, it certainly
> doesn't require anything more than spinning for work on an empty queue to be
> algorithmically correct, but after spinning on an empty queue, making the
> rounds trying to steal work from other deques, maybe spinning a bit more,
> just to be sure, the de-queuing thread which hasn't been able to acquire
> more work is probably going to want to enter a wait until such time as it
> knows it can do productive work. Another thread pushing work into that queue
> won't be able to determine if the dequeue-ing thread is spinning for new
> work, work stealing, or has entered a wait, but atomic::notify() does
> know that, and can avoid penalizing the thread submitting work with a
> syscall, if there is no thread in a wait on the other end of the deque,
> which is the expected case for this algorithm.

It's good example, but I think it will be better to have own "waiter pool" in
executor for that.
I try to explain why:
1) In that case you can control size of waiter pool, for example just create
separate atomic per threadpool's thread.
2) you avoid contention/and false-positive with other atomics because its not
global 

> p1135 was the paper that added atomic wait/notify. One of the co-authors of
> that paper wrote the libc++ implementation. That implementation, as with
> libstdc++, is not simply a wrapper over the underlying platform's wait
> primitive. It has two 'backends', an exponentially timed backoff and ulock
> wait/wake. libstdc++ currently has a Futex and condvar backend. Both
> implementations make the choice of having a short-term spinning strategy and
> long term waiting strategy (spinning, futex/ulock, condvar).

I know (one moment that I was wrong libc++ also use waiter pool in platform
case), and I don't think its good.
>From my point of view better to have something like
std::wait_spin waiter;
bool std::wait_spin::wait(Condition condition_func);
void std::wait_spin::reset();

Also libc++ implementation make timed wait on futex (but not on ulock), I don't
why, do you know?
https://discourse.llvm.org/t/why-do-atomic-int-wait-use-timed-futex/65341

But in general it's not about this thread.

> I have confirmed with the libc++ implementation's author, (who also chairs
> the C++ committee's Concurrency and Parallelism study group), that it was
> never the intention of p1135 or the subsequently standardized language in
> C++20 to imply that wait/notify were direct portable analogs to the
> platform's waiting primitives. There are users, such as yourself that want
> exactly that, there are other users (like in my prior industry) where busy
> waiting is the desired strategy, and in between those two choices are people
> who want it to work as advertised in the standard, and to do so
> 'efficiently'. Both libc++ and libstdc++ take a balanced approach somewhere
> between always going to OS and always spinning.

It's a good point, despite though atomic wait/notify is too low-level to that
make sense in my opinion.
As a result, it seems to me that in this form they aren't very suitable for
developers who know what they want (syscall).

And at the same time, developers who write business code aren't particularly
needed them (they generally use some library for coroutines/callbacks, for
example, like p2300)


> There is an open question here that your original issue raises -
> 
> * At what point do collisions on the waiter pool, with the cache
> invalidation traffic and spurious wakeups that result, swamp the gain of
> doing this empty waiter check on notify?

Just start threadpool with dequ

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

[valera.mironow at gmail dot com via Gcc-bugs]

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

--- Comment #24 from Mkkt Bkkt  ---
(In reply to Thomas Rodgers from comment #22)
> Your example of '100+ core' systems especially on NUMA is certainly a valid
> one. I would ask, at what point do those collisions and the resulting cache
> invalidation traffic swamp the cost of just making the syscall? I do plan to
> put these tests together, because there is another algorithm that I am
> exploring, that I believe will reduce the likelihood of spurious wakeups,
> and achieves the same result as this particular approach, without generating
> the same invalidation traffic. At this point, I don't anticipate doing that
> work until after GCC13 stage1 closes.

I try to explain: 

syscall overhead is some constant commonly like 10-30ns (futex syscall can be
more expensive like 100ns in your example)

But numbers of cores are grow, arm also makes more popular (fetch_add/sub have
more cost on it compares to x86)
And people already faced with situation where fetch_add have a bigger cost than
syscall overhead:

https://pkolaczk.github.io/server-slower-than-a-laptop/
https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html

I don't think we will faced with problem like in these links in
atomic::wait/notify in real code, but I'm pretty sure in some cases it can be
more expansive than syscall part of atomic::wait/notify

Of course better to prove it, maybe someday I will do it :(

[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary

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

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

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

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

commit r13-2922-gfa9bda3ea4315a7285edbc99323e3fa7885cbbb8
Author: Jonathan Wakely 
Date:   Tue Sep 27 20:59:05 2022 +0100

libstdc++: Make INVOKE refuse to create dangling references [PR70692]

This is the next part of the library changes from P2255R2. This makes
INVOKE ill-formed if converting the INVOKE expression to R would bind
a reference to a temporary object.

The is_invocable_r trait is now false if the invocation would create a
dangling reference. This is done by adding the dangling check to the
__is_invocable_impl partial specialization used for INVOKE
expressions. This change also slightly simplifies the nothrow checking
recently added to that partial specialization.

This change also removes the is_invocable_r checks from the pre-C++17
implementation of std::__invoke_r, because there is no need for it to be
SFINAE-friendly. None of our C++11 and C++14 uses of INVOKE require
those constraints. The std::function constructor needs to check
is_invocable_r, but that's already done explicitly, so we don't need to
recheck when calling __is_invoke_r in std::function::operator(). The
other uses of std::__is_invoke_r do not need to be constrained and can
just be ill-formed if the INVOKE expression is ill-formed.

libstdc++-v3/ChangeLog:

PR libstdc++/70692
* include/bits/invoke.h [__cplusplus < 201703] (__invoke_r):
Remove is_invocable and is_convertible constraints.
* include/std/type_traits (__is_invocable_impl::_S_conv): Use
non-deduced context for parameter.
(__is_invocable_impl::_S_test): Remove _Check_noex template
parameter and use deduced noexcept value in its place. Add bool
parameter to detect dangling references.
(__is_invocable_impl::type): Adjust call to _S_test to avoid
deducing unnecessary noexcept property..
(__is_invocable_impl::__nothrow_type): Rename to ...
(__is_invocable_impl::__nothrow_conv): ... this. Adjust call
to _S_test to deduce noexcept property.
* testsuite/20_util/bind/dangling_ref.cc: New test.
* testsuite/20_util/function/cons/70692.cc: New test.
* testsuite/20_util/function_objects/invoke/dangling_ref.cc:
New test.
* testsuite/20_util/is_invocable/dangling_ref.cc: New test.
* testsuite/30_threads/packaged_task/cons/dangling_ref.cc:
New test.

[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for GCC 13 by implementing the changes from https://wg21.link/P2255R2

The original example is now ill-formed.

[Bug tree-optimization/90556] [meta-bug] bogus/missing -Wreturn-local-addr

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

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

Bug 70692 Summary: No warning when std::function binds a 
reference to a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692

   What|Removed |Added

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

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

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

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

--- Comment #25 from Thomas Rodgers  ---
(In reply to Mkkt Bkkt from comment #24)
> (In reply to Thomas Rodgers from comment #22)
> > Your example of '100+ core' systems especially on NUMA is certainly a valid
> > one. I would ask, at what point do those collisions and the resulting cache
> > invalidation traffic swamp the cost of just making the syscall? I do plan to
> > put these tests together, because there is another algorithm that I am
> > exploring, that I believe will reduce the likelihood of spurious wakeups,
> > and achieves the same result as this particular approach, without generating
> > the same invalidation traffic. At this point, I don't anticipate doing that
> > work until after GCC13 stage1 closes.
> 
> I try to explain: 
> 
> syscall overhead is some constant commonly like 10-30ns (futex syscall can
> be more expensive like 100ns in your example)
> 
> But numbers of cores are grow, arm also makes more popular (fetch_add/sub
> have more cost on it compares to x86)
> And people already faced with situation where fetch_add have a bigger cost
> than syscall overhead:
> 
> https://pkolaczk.github.io/server-slower-than-a-laptop/
> https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html
> 
> I don't think we will faced with problem like in these links in
> atomic::wait/notify in real code, but I'm pretty sure in some cases it can
> be more expansive than syscall part of atomic::wait/notify
> 
> Of course better to prove it, maybe someday I will do it :(

So to your previous comment, I don't the discussion is at all pointless. i plan
to raise some of these issues at the next SG1 meeting in November. Sure, that
doesn't help *you* or any developer with your specific intent until C++26, and
maybe Boost's implementation is a better choice, I also get how unsatisfying of
an aswer that is.

I'm well aware of the potential scalability problems, and I have a longer term
plan to get concrete data on how different implementation choices impact
scalability. The barrier implementation (which is the same algorithm as in
libc++), for example spreads this traffic over 64 individual atomic_refs, for
this very reason, and that implementation has been shown to scale quite well on
ORNL's Summit. But not all users of libstdc++ have those sorts of problems
either.

[Bug c++/107080] New: ICE in verify_symtab_nodes using _Float64x with long double

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

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

Bug ID: 107080
   Summary: ICE in verify_symtab_nodes using _Float64x with long
double
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-* i?86-* ia64-*

Compiling the following C++ test for x86_64 (or i686 or ia64) produces an ICE,
no optimization or other options required (presumably introduced by the _FloatN
/ _FloatNx support for C++).


template struct S;

template<> struct S
{
  static int call (long double x, long double y) throw ()
  {
return 3;
  }
};

template<> struct S<_Float64x>
{
  static int call (_Float64x x, _Float64x y) throw ()
  {
return 3;
  }
};

template
inline int
g (T1 x, T2 y) throw ()
{
  typedef decltype (x + y) T3;
  return S::call (x, y);
}

int
f ()
{
  return g (0.0f64x, 0.0f64x) + g (0.0f64x, 0.0L);
}



t.cc:31:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   31 | }
  | ^
_Z1gIeeEiT_T0_/4 (int g(T1, T2) [with T1 = _Float64x; T2 = long double])
  Type: function definition analyzed
  Visibility: semantic_interposition no_reorder public weak comdat
comdat_group:_Z1gIeeEiT_T0_ one_only
  previous sharing asm name: 3
  References: __gxx_personality_v0/5 (addr) 
  Referring: 
  Function flags: body
  Called by: _Z1fv/2 
  Calls: _ZN1SIeE4callEee/1 
_Z1gIeeEiT_T0_/3 (int g(T1, T2) [with T1 = _Float64x; T2 = _Float64x])
  Type: function definition analyzed
  Visibility: semantic_interposition no_reorder public weak comdat
comdat_group:_Z1gIeeEiT_T0_ one_only
  next sharing asm name: 4
  References: __gxx_personality_v0/5 (addr) 
  Referring: 
  Function flags: body
  Called by: _Z1fv/2 
  Calls: _ZN1SIeE4callEee/1 
t.cc:31:1: internal compiler error: symtab_node::verify failed
0xc9ba69 symtab_node::verify_symtab_nodes()
/scratch/jmyers/glibc/many13/src/gcc/gcc/symtab.cc:1410
0xcb4ab3 symtab_node::checking_verify_symtab_nodes()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraph.h:682
0xcb4ab3 symbol_table::compile()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2264
0xcb80cd symbol_table::compile()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2261
0xcb80cd symbol_table::finalize_compilation_unit()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2529
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/107066] Field initialized before ctor is mis-optimized away by DSE

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #3 from Feng Xue  ---
Got it. Thanks for that.

[Bug c/107081] New: ctime fct used twice in printf

[francois.hebert001 at videotron dot ca via Gcc-bugs]

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

Bug ID: 107081
   Summary: ctime fct used  twice in printf
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: francois.hebert001 at videotron dot ca
  Target Milestone: ---

If I use twice the ctime fct in the same printf, only the first value is print
twice.
If I use two printf both val;ue are printed correctly :
...
time_t now,now_beg,now_fin;
...
 printf("Beginning time ->%s Finishing time>%s\n",ctime(&now_beg),  
ctime(&now_fin));
  printf("Beginning time->%s\n",ctime(&now_beg));
  printf("Finishing time->%s\n",ctime(&now_fin));

The result  is :

Sep 28 20:37:17 2022

Beginning time ->Wed Sep 28 20:37:15 2022
 Finishing time->Wed Sep 28 20:37:15 2022 <- should be not 20:37:15 but
20:37:17

Beginning time->Wed Sep 28 20:37:15 2022

Finishing time->Wed Sep 28 20:37:17 2022


Here is the Linux and gcc versions and the complete source used
/*

gcc -o test_ctime test_ctime.c
   ./test_ctime
Fedora 36 astronomy 5.17.5-300
gcc --version
gcc (GCC) 12.0.1 20220413 (Red Hat 12.0.1-0)
Copyright © 2022 Free Software Foundation, Inc.

*/

#include 
#include 
#include 



long cpt;
long j,limit;
time_t now,now_beg,now_fin;

/***

  Main section

***/
int main()
{
  cpt=0;
  j=0;
  /*limite=LONG_MAX;*/
  limit=9;

  printf("Limit->%d\n",limit);
  time(&now_beg);
  printf("Begining time -> %s\n",ctime(&now_beg));
  for  (cpt=0;cpt%s\n",cpt,ctime(&now));
 }
  }
  time(&now_fin);

  printf("Beginning time ->%s Finishing time->%s\n", 
 ctime(&now_beg),ctime(&now_fin));
  printf("Beginning time->%s\n",ctime(&now_beg));
  printf("Finishing time->%s\n",ctime(&now_fin));

  return 0;

}  /* end main section */

[Bug c/107081] ctime fct used twice in printf

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
ctime returns the same pointer no matter what. It 


https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf

The ctime function returns the pointer returned by the asctime function with
that
broken-down time as argument.

"Execution of
any of the functions that return a pointer to one of these object types may
overwrite the
information in any object of the same type pointed to by the value returned
from any
previous call to any of them and the functions are not required to avoid data
races.
"

[Bug c++/107080] ICE in verify_symtab_nodes using _Float64x with long double

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Here is a reduced testcase:
```
template 
int f (T x, T1 y) throw ()
{
return 3;
}

int
main ()
{
  return (f (0.0f64x, 0.0f64x) + f (0.0f64x, 0.0L)) != 6;
}
```
This ICEs and with release checking it produces an assembler error:
```
/tmp/ccJDRaEi.s: Assembler messages:
/tmp/ccJDRaEi.s:93: Error: symbol `_Z1fIeeEiT_T0_' is already defined
```

I can only assume the issue is _Float64x is not treated the same as long double
for type comparison but is treated the same for mangling (which is why I marked
it as an ABI issue).

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

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

--- Comment #16 from Richard Biener  ---
(In reply to Alexander Monakov from comment #15)
> (In reply to Richard Biener from comment #14)
> > I can't
> > seem to reproduce any vectorization for your smaller example though.
> 
> My small C samples omit some detail as they were meant to illustrate what
> happened in the IR. Is that a problem?

Not a Problem - it would have made life easier of course ;)

> By the way, I noticed that tree-ssa-math-opts incorrectly handles
> -ffp-contract:
> 
>   if (FLOAT_TYPE_P (type)
>   && flag_fp_contract_mode == FP_CONTRACT_OFF)
> return false;
> 
> It should be 'flag_fp_contract_mode != FP_CONTRACT_FAST' instead (the pass
> doesn't have any idea about expression boundaries). It dates back to
> g:1694907238eb

Ah - feel free to fix that (I think such change would be obvious, even better
when accompanied by a comment).  I do think that since the only way to
preserve expression boundaries is by PAREN_EXPR that the middle-end
shouldn't care about FAST vs. ON (well, it cannot), but the language
frontends need to ensure to emit PAREN_EXPRs for =ON and omit them for
=FAST.

Since we don't implement ON the above check should indeed be changed until
that's fixed.