[Bug libquadmath/105101] incorrect rounding for sqrtq

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #10 from Michael_S  ---
BTW, the same ideas as in the code above could improve speed of division
operation (on modern 64-bit HW) by factor of 3 (on Intel) or 2 (on AMD).

[Bug c++/105297] [12 Regression] new modules 'xtreme' test cases FAILs

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Target||*-darwin*, x86_64-linux-gnu
   Last reconfirmed||2022-4-16
   Keywords||testsuite-fail

[Bug c++/105297] New: [12 Regression] new modules 'xtreme' test cases FAILs

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

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

Bug ID: 105297
   Summary: [12 Regression] new modules 'xtreme' test cases  FAILs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

between r12-8146 and r12-8179. for each std= tested

g++.dg/modules/xtreme-header-4_a.H -std=c++* (internal compiler error: in
insert, at cp/module.cc:4800)

likewise
g++.dg/modules/xtreme-header_a.H

[Bug jit/105296] New: libgccjit crashes when creating a struct constructor for an aligned struct type

[marc--- via Gcc-bugs]

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

Bug ID: 105296
   Summary: libgccjit crashes when creating a struct constructor
for an aligned struct type
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: m...@nieper-wisskirchen.de
  Target Milestone: ---

Consider the following example program:

#include 

int
main (void)
{
  gcc_jit_context *ctxt = gcc_jit_context_acquire ();
  gcc_jit_type *int_type
= gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
  gcc_jit_field *field = gcc_jit_context_new_field (ctxt, NULL, int_type,
"int");
  gcc_jit_struct *struct_
= gcc_jit_context_new_struct_type (ctxt, NULL, "struct", 1, (gcc_jit_field
*[]) {field});
  gcc_jit_type *struct_type
= gcc_jit_struct_as_type (struct_);
  gcc_jit_type *aligned_struct_type
= gcc_jit_type_get_aligned (struct_type, 16);
  gcc_jit_lvalue *global
= gcc_jit_context_new_global (ctxt, NULL, GCC_JIT_GLOBAL_EXPORTED,
  aligned_struct_type, "global");
  gcc_jit_rvalue *val
= gcc_jit_context_new_rvalue_from_int (ctxt, int_type, 42);
  gcc_jit_rvalue *ctor
= gcc_jit_context_new_struct_constructor (ctxt, NULL,
  aligned_struct_type,
  1,
  (gcc_jit_field *[]) {field},
  (gcc_jit_rvalue *[]) {val});
  gcc_jit_global_set_initializer_rvalue (global, ctor);

  gcc_jit_result *res = gcc_jit_context_compile (ctxt);
  gcc_jit_context_release (ctxt);
  gcc_jit_result_release (res);
}


On my system, I get:

$ gcc -lgccjit struct.c && valgrind ./a.out 
==1022902== Memcheck, a memory error detector
==1022902== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1022902== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==1022902== Command: ./a.out
==1022902== 
==1022902== Invalid read of size 8
==1022902==at 0x4B7F3CF: get_fields (jit-recording.h:968)
==1022902==by 0x4B7F3CF: gcc_jit_context_new_struct_constructor
(libgccjit.cc:1436)
==1022902==by 0x4012F7: main (in /home/mnieper/tmp/a.out)
==1022902==  Address 0x6fbbfc8 is 0 bytes after a block of size 56 alloc'd
==1022902==at 0x4843839: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1022902==by 0x5EC26AB: operator new(unsigned long) (new_op.cc:50)
==1022902==by 0x4B90F47: gcc::jit::recording::type::get_aligned(unsigned
long) (jit-recording.cc:2295)
==1022902==by 0x4B853FE: gcc_jit_type_get_aligned (libgccjit.cc:3950)
==1022902==by 0x401278: main (in /home/mnieper/tmp/a.out)
==1022902== 
==1022902== Invalid read of size 8
==1022902==at 0x4B7F3D3: length (vec.h:1473)
==1022902==by 0x4B7F3D3: length (jit-recording.h:1033)
==1022902==by 0x4B7F3D3: gcc_jit_context_new_struct_constructor
(libgccjit.cc:1437)
==1022902==by 0x4012F7: main (in /home/mnieper/tmp/a.out)
==1022902==  Address 0x28 is not stack'd, malloc'd or (recently) free'd
==1022902== 
==1022902== 
==1022902== Process terminating with default action of signal 11 (SIGSEGV)
==1022902==  Access not within mapped region at address 0x28
==1022902==at 0x4B7F3D3: length (vec.h:1473)
==1022902==by 0x4B7F3D3: length (jit-recording.h:1033)
==1022902==by 0x4B7F3D3: gcc_jit_context_new_struct_constructor
(libgccjit.cc:1437)
==1022902==by 0x4012F7: main (in /home/mnieper/tmp/a.out)
==1022902==  If you believe this happened as a result of a stack
==1022902==  overflow in your program's main thread (unlikely but
==1022902==  possible), you can try to increase the size of the
==1022902==  main thread stack using the --main-stacksize= flag.
==1022902==  The main thread stack size used in this run was 8388608.
==1022902== 
==1022902== HEAP SUMMARY:
==1022902== in use at exit: 79,354 bytes in 46 blocks
==1022902==   total heap usage: 48 allocs, 2 frees, 79,466 bytes allocated
==1022902== 
==1022902== LEAK SUMMARY:
==1022902==definitely lost: 0 bytes in 0 blocks
==1022902==indirectly lost: 0 bytes in 0 blocks
==1022902==  possibly lost: 0 bytes in 0 blocks
==1022902==still reachable: 79,354 bytes in 46 blocks
==1022902== suppressed: 0 bytes in 0 blocks
==1022902== Rerun with --leak-check=full to see details of leaked memory
==1022902== 
==1022902== For lists of detected and suppressed errors, rerun with: -s
==1022902== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Speicherzugriffsfehler (Speicherabzug geschrieben)

[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var

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

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

--- Comment #3 from Iain Sandoe  ---
Initial analysis ...

1. The coroutines code is supposed to ensure that the local variables are given
the context of the enclosing function (whether that is the ramp or the outlined
actor).

coroutines.cc:
   2023   /* Re-write the variable's context to be in the actor func. 
*/
   2024   DECL_CONTEXT (lvar) = lvd->context;

So, one issue to resolve is why that is apparently not working for the
temporary condition variable in question.

2. DECL_CONTEXT can validly be NULL_TREE (when the decl is in the global
namespace)

GCC internals:

DECL_CONTEXT
This macro returns the enclosing namespace. The DECL_CONTEXT for the
global_namespace is NULL_TREE.

Both things need to be addressed (even if fixing [1] will make the ICE go away
for this code, there will surely be code that intentionally places vars in the
global namespace).



FWIW, I looked at the output of the analyser with my WIP branch (for which the
ICE does not fire) - and TBH suspect that it will not be terribly useful until
we can teach it about the outlining done for coroutines (the fact that some
values persist, intentionally, beyond the closing brace of the initial call is
going to be an interesting thing to figure out).

[Bug tree-optimization/105295] New: missed optimization with -ftrapv for conditional constants

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 105295
   Summary: missed optimization with -ftrapv for conditional
constants
   Product: gcc
   Version: 12.0
   URL: https://godbolt.org/z/4rojo77a7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

~~~c
int sum_const(_Bool a, _Bool b)
{
return (a ? 1 : 0 ) + (b ? 1 : 0);
}

int sum_unknown(int a, int b)
{
return a + b;
}
~~~

For both functions, GCC calls __addvsi3, even though in sum_const, it is easy
to see that no overflow can ever happen since the sum is always in the range [0
... 2].

Clang optimizes this code reasonably.

ICC apparently does not care about -ftrapv at all.

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org via Gcc-bugs]

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

Elmar Stellnberger  changed:

   What|Removed |Added

  Attachment #52821|0   |1
is obsolete||

--- Comment #1 from Elmar Stellnberger  ---
Created attachment 52822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52822=edit
command line to evoke the error

[Bug c/105294] New: restrict pointer - disagreement with specification

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 105294
   Summary: restrict pointer - disagreement with specification
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

Here is an example where GCC/Clang assume that variables
may not alias where the C spec seems to say otherwise.

This example is based on one found by Hubert Tong
after discussions with him (and Ralf Jung).

Probably the spec should be changed instead of the
compilers.

Note that when removing the first restrict, clang but
not GCC still does the optimization, which hints at
a missed optimization opportunity (assuming a
change in spec which generally makes this valid).

https://godbolt.org/z/K89jdd473

int f(int * q, int * restrict p, int * restrict s)
{
  int x;
  int *r = 
  if (p == q)
r = s;
  *p = 13;
  *r = 42; // `&(*r)` is based on both `p`, `s`!
  return *p;
}

int main(void)
{
  int q;
  return f(, , );
}

[Bug c++/105293] New: g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org via Gcc-bugs]

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

Bug ID: 105293
   Summary: g++-8/i586: internal compiler error trying to compile
with g++ (evtl. related to qt5/moc bug)
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: estellnb at elstel dot org
  Target Milestone: ---

Created attachment 52821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52821=edit
command line to evoke the error

If I try to compile firefox-esr-91.8.0esr I get the following error in (command
line in evoke-compilererr):

In file included from src/gl.cc:2643:
src/rasterize.h: In function ‘void draw_quad_spans(int, Point2D*, uint32_t,
glsl::Interpolants*, Texture&, Texture&, const ClipRect&) [with P = unsigned
char]’:
src/rasterize.h:782:20: internal compiler error: in convert_move, at expr.c:218
 static inline void draw_quad_spans(int nump, Point2D p[4], uint32_t z,
^~~
0xf78b7b40 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,

  If I run /bin/g++ (g++ 4:8.3.0-1 i386 Debian10/Buster) in gdb:
(gdb) l
1   ../sysdeps/unix/sysv/linux/i386/init-first.c: file not found
(gdb) bt
No stack.

  The error is known and does not appear in the same version of amd64 Debian.
It does not appear with newer versions like Debian11/Bullseye/g++ 4:10.2.1-1

  I get another type of error with Qt5/moc (meta object compiler for generating
signal handler procedure signatures):
usr/include/c++/8/bits/stl_relops.:67: Parse error at "std"

  /usr/include/c++/8/bits/stl_relops.h start like any .h in bits/ and should be
correct. Like the internal compiler error from above this one appears only in
i586, but with a wide variety of distributions:
i586 Debian10 gcc 8.3.0-1: bad  (likewise bad Ubuntu19.04)
i586 Ubuntu19.10 gcc 9.2.1: good

  I will appreciate any hint to what the bug could have been related to. I
would like to develop a patch to fix things for Debian10/i386 but do not really
know on where to start looking for. I could neither find init-first.c nor
libc-start.c looking for such files in the source directory gcc-8-8.3.0.

[Bug c/105292] New: [sparc64] ICE in expand_expr_real_2 on sparc64 when compiling with -mcpu=niagara4

[koachan+gccbugs at protonmail dot com via Gcc-bugs]

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

Bug ID: 105292
   Summary: [sparc64] ICE in expand_expr_real_2 on sparc64 when
compiling with -mcpu=niagara4
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koachan+gccbugs at protonmail dot com
  Target Milestone: ---

Created attachment 52820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52820=edit
Preprocessed source of ctf-open.c

Hello~

I'm getting this error on sparc64-linux-gnu when compiling gdb (commit
f0072f79e12 from git), in ctf-open.c:

gcc -O3 -mcpu=niagara4 -c libctf_la-ctf-open.c 
during RTL pass: expand
../../libctf/ctf-open.c: In function ‘ctf_bufopen_internal.part.0’:
../../libctf/ctf-open.c:1117:69: internal compiler error: in
expand_expr_real_2, at expr.c:9867
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

As far as I know, compiling with -mcpu=niagara3 and -mcpu=niagara2 also fails
with the same error.
I'm using "gcc version 11.2.0 (GCC)". Attached is the preprocessed source of
the offending file.

[Bug gcov-profile/105282] [11/12 Regression] V_INDIR overflow causes ICE on -O0 -flto in stream_out_histogram_value, at value-prof.cc:340

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

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

--- Comment #3 from Sergei Trofimovich  ---
Created attachment 52819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52819=edit
0001-gcov-profile-Allow-negative-counts-of-indirect-calls.patch

[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

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

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

--- Comment #3 from Jonathan Wakely  ---
https://github.com/cplusplus/CWG/issues/31

[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

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

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

--- Comment #2 from Jonathan Wakely  ---
Clang implements the wording correctly:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2036r3.html#pnum_3

So int a = 0; [a] (decltype(a)) { }; is ill-formed now. But I'm not convinced
that's a good change to make as a DR.

[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

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

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

--- Comment #1 from Jonathan Wakely  ---
> > +   using __local_end_t = __decltype(__local_end);

This code isn't valid pre-C++11 so we can just use decltype, not __decltype.

[Bug libstdc++/105291] New: include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 105291
   Summary: include/c++/12.0.1/debug/safe_unordered_container.h:71
:28: error: captured variable '__local_end' cannot
appear here
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

Since

"[clang] Implement Change scope of lambda trailing-return-type", Clang 15 trunk
implements
 "Change
scope of lambda trailing-return-type" as a DR (in line with
 "N4902
Editors’ Report – Programming Languages – C++"; so enabled with all -std=
versions).

That stated to cause

> $ cat test.cc 
> #define _GLIBCXX_DEBUG
> #include 

> $ clang++ -fsyntax-only test.cc
> In file included from test.cc:2:
> In file included from 
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/unordered_map:52:
> In file included from 
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/unordered_map:49:
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:71:28:
>  error: captured variable '__local_end' cannot appear here
> [__local_end](__decltype(__local_end) __it)
>  ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:71:4:
>  note: variable '__local_end' is explicitly captured here
> [__local_end](__decltype(__local_end) __it)
>  ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:69:2:
>  note: '__local_end' declared here
> auto __local_end = _M_cont()._M_base().cend(0);
> ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:169:44:
>  error: captured variable '__end' cannot appear here
> this->_M_invalidate_if([__end](__decltype(__end) __it)
>   ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:169:26:
>  note: variable '__end' is explicitly captured here
> this->_M_invalidate_if([__end](__decltype(__end) __it)
> ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:168:2:
>  note: '__end' declared here
> auto __end = _M_cont()._M_base().cend();
> ^
> 2 errors generated.

to fail.

The relevant code in libstdc++-v3/include/debug/safe_unordered_container.h got
added with

"2018-10-24  François Dumont  ".

What made things work for me is

> diff --git a/libstdc++-v3/include/debug/safe_unordered_container.h 
> b/libstdc++-v3/include/debug/safe_unordered_container.h
> index 91be256611a..71468198573 100644
> --- a/libstdc++-v3/include/debug/safe_unordered_container.h
> +++ b/libstdc++-v3/include/debug/safe_unordered_container.h
> @@ -67,8 +67,9 @@ namespace __gnu_debug
>_M_invalidate_locals()
>{
> auto __local_end = _M_cont()._M_base().cend(0);
> +   using __local_end_t = __decltype(__local_end);
> this->_M_invalidate_local_if(
> -   [__local_end](__decltype(__local_end) __it)
> +   [__local_end](__local_end_t __it)
> { return __it != __local_end; });
>}
>  
> @@ -166,7 +167,8 @@ namespace __gnu_debug
>_M_invalidate_all()
>{
> auto __end = _M_cont()._M_base().cend();
> -   this->_M_invalidate_if([__end](__decltype(__end) __it)
> +   using __end_t = __decltype(__end);
> +   this->_M_invalidate_if([__end](__end_t __it)
>{ return __it != __end; });
> _M_invalidate_locals();
>}

[Bug c++/105290] "Purely syntactic" disambiguation but GCC applies semantic rules for constant expressions

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

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

--- Comment #1 from Andrew Pinski  ---
There is another bug related to how array types are messed up when it comes to
parsing. I suspect this is a dup of that one.