Request for comments : GSoC Project Proposal - Constant folding in Rust-GCC (Draft)

[M V V S Manoj Kumar via Gcc]

Greetings,
I am M V V S Manoj Kumar, an Open Source Contributor to Rust-GCC (GitHub
,  contributions
),
and I want to pursue a GSoC project regarding constant folding in Rust-GCC.
I have included the draft of my project proposal here
.
I would be grateful for any suggestions you have regarding it and will try
to implement them in my final submission.

Thank you.
M V V S Manoj Kumar
BTech Student, Electronics and Communication Engineering
Thapar Institute of Engineering and Technology
Patiala, Punjab
India

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

[hstong at ca dot ibm.com via Gcc-bugs]

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

Bug ID: 105290
   Summary: "Purely syntactic" disambiguation but GCC applies
semantic rules for constant expressions
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, rejects-valid, wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

As far as parsing is concerned, a _constant-expression_ is just a
_conditional-expression_. There is no statement that a _constant-expression_
has to be semantically a constant expression to be parsed as one.

Every use of _constant-expression_ in the grammar is associated with a
case-specific (semantic) statement that applies the semantic constant
expression requirements.

It looks like GCC applies the semantic rules for constant expressions while
performing vexing parse disambiguation, which the standard says is "purely
syntactic".

Compiler Explorer link: https://godbolt.org/z/Ms38PPsqh

### SOURCE (``):
typedef int *Ptr;
int idx(unsigned *) { return 0; }
constexpr int idx(short *) { return 1; }
void zip(void **p) {
  int val(Ptr (*p)[idx((short *)0)]); // constant expression in array
declarator
  val(nullptr);
}
void zap(void **p) {
  int val(Ptr(*p)[idx((unsigned *)0)]); // non-constant expression in subscript
expression?!
  val(nullptr);
}


### ACTUAL OUTPUT:
: In function 'void zap(void**)':
:10:6: error: 'val' cannot be used as a function


### EXPECTED OUTPUT:
(Clean compile)


### COMPILER INVOCATION:
g++ -fsyntax-only -Wno-vexing-parse -xc++ -


### COMPILER VERSION INFO (`g++ -v`):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220415 (experimental) (GCC)

[Bug target/105288] AVX/AVX512 casts should use the "v" constraint

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongyu Wang  ---
I think should be these 2?

(define_insn_and_split "avx512f__"
  [(set (match_operand:AVX512MODE2P 0 "nonimmediate_operand" "=x,m")
(vec_concat:AVX512MODE2P
  (vec_concat:
(match_operand: 1 "nonimmediate_operand" "xm,x")
(unspec: [(const_int 0)] UNSPEC_CAST))
  (unspec: [(const_int 0)] UNSPEC_CAST)))]
  "TARGET_AVX512F && !(MEM_P (operands[0]) && MEM_P (operands[1]))"

(define_insn_and_split "avx512f__256"
  [(set (match_operand:AVX512MODE2P 0 "nonimmediate_operand" "=x,m")
(vec_concat:AVX512MODE2P
  (match_operand: 1 "nonimmediate_operand" "xm,x")
  (unspec: [(const_int 0)] UNSPEC_CAST)))]
  "TARGET_AVX512F && !(MEM_P (operands[0]) && MEM_P (operands[1]))"

The AVX insn shouldn't have constraints "v"

[Bug c++/105289] New: ICE on partial specialization

[michsteinb at gmail dot com via Gcc-bugs]

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

Bug ID: 105289
   Summary: ICE on partial specialization
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michsteinb at gmail dot com
  Target Milestone: ---

Created attachment 52818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52818=edit
Self-contained reproduction of the ICE, compile with -std=c++20

arm-none-eabi-g++ 11.2 crashes on attached self-contained code with following
prompt on win64:
```
PS H:\projects\install\arm-embedded-gcc\11.2-2022.02\bin>
.\arm-none-eabi-g++.exe -save-temps -std=c++20 -c repro.cxx
repro.cxx:14:8: internal compiler error: Segmentation fault
   14 | struct push_front_vlist, Arg>
  |^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

The 10.x release cycle compilers accepted this code, so does clang, so this is
a regression introduced with 11.0.

Further checks on godbolt showed the same behaviour on all 11.x compilers I
tried.

The problem stems from the primary template using a meta-function of its first
parameter as type for its second. If I do not constrain the type of Arg, the
crash disappears.

[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken

[esgergn at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from Esger Abbink  ---
Building a real project with the patched gcc9.4 and ccache 4.5.1 (replacing
-fprofile-dir with -fprofile-prefix-map=${CMAKE_SOURCE_DIR}=.) it looks ok at
first sight:

- 100% cache hits for the second compilation in a different directory
- gcda created next to .o & .gcda for both first and second
compilations/directories

However when running the unittests binaries there are quite a number of gcov
warnings:

[==] 2807 tests from 297 test suites ran. (272928 ms total)
[  PASSED  ] 2807 tests.

libgcov profiling error:
:overwriting an existing profile data with a different timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:
:overwriting an existing profile data with a different timestamp
libgcov profiling error::overwriting an existing profile data with a different
timestamp
libgcov profiling error::overwriting an existing profile data with a different
timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:&:overwriting an existing profile data with a different
timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:':overwriting an existing profile data with a different
timestamp
profiling::Cannot open
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error:#:overwriting an existing profile data with a different
timestamp
libgcov profiling error::overwriting an existing profile data with a different
timestamp
...
[this continues for quite a number of lines]

Note that these warnings are produced both for the directory where compilation
really took place as for the directory where .o & .gcno were taken from the
cache.

Since the gcda files are created next to the .o * .gcno there should not be any
name clashes (for identical names the path would still be different). So I am
not sure what is happening here? Unfortunately, the warning lines do not
include any information about which file is being written or which file is
clashing.



Still, gcovr is able to produce a coverage report with information that looks
sane, but there are differences with the gcc7.5 reports. I would assume because
of the above warnings. 

The coverage report for the second compilation (using cached .o & .gcno) is for
all intents and purposes the same as the one for the first compilation. The
difference being 2 lines and 2 branches on totals of 17515 and 14727.

gcc-10-20220415 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20220415 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20220415/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision 9646582e8e4f7b6ad01175ada9cc2482ba8007af

You'll find:

 gcc-10-20220415.tar.xz   Complete GCC

  SHA256=ca3f32cb053b98cc251cefc6341b011479d060fe74d525b2ef0e7fed42bde60a
  SHA1=772b1c5dbadbdc0eefc25d9f29438dbc22901383

Diffs from 10-20220408 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: GCC 11.3 Release Candidate available from gcc.gnu.org

[William Seurer via Gcc]

I tested the release candidate on power 7 and 8 BE as well as power 8, 
9, and 10 LE and saw nothing unexpected.


On 4/14/22 2:08 AM, Richard Biener via Gcc wrote:

The first release candidate for GCC 11.3 is available from

  https://gcc.gnu.org/pub/gcc/snapshots/11.3.0-RC-20220414/
  ftp://gcc.gnu.org/pub/gcc/snapshots/11.3.0-RC-20220414/

and shortly its mirrors.  It has been generated from git commit
r11-9879-g53254184bda630.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, I'd like to release 11.3 on Thursday, April 21th.

Go patch commited: Fix initialization ordering

[Ian Lance Taylor via Gcc-patches]

compiler: revert `for package-scope "a = b; b = x" just set "a = x"`

This patch to the Go frontend reverts https://go.dev/cl/245098, which
introduced incorrect initialization ordering.  This patch adjusts the
runtime package to work even with that change reverted.

Original description of change 245098:

This avoids requiring an init function to initialize the variable.
This can only be done if x is a static initializer.

The go1.15rc1 runtime package relies on this optimization.
The package has a variable "var maxSearchAddr = maxOffAddr".
The maxSearchAddr variable is used by code that runs before package
initialization is complete.

This is for https://golang.org/issue/51913.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
5d6db440fd8ec4089fba83760874d70f449037a6
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 75ee2e3aaca..bcb526c85b9 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-323ab0e6fab89978bdbd83dca9c2ad9c5dcd690f
+62fc90f52da2f52cbe3b4f10e560dc6aa59baeb5
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/gogo.cc b/gcc/go/gofrontend/gogo.cc
index 30d5c9fcb0b..d35c6baf582 100644
--- a/gcc/go/gofrontend/gogo.cc
+++ b/gcc/go/gofrontend/gogo.cc
@@ -1612,31 +1612,16 @@ Gogo::write_globals()
   // The initializer is constant if it is the zero-value of the
   // variable's type or if the initial value is an immutable value
   // that is not copied to the heap.
- Expression* init = var->init();
-
- // If we see "a = b; b = x", and x is a static
- // initializer, just set a to x.
- while (init != NULL && init->var_expression() != NULL)
-   {
- Named_object* ino = init->var_expression()->named_object();
- if (!ino->is_variable() || ino->package() != NULL)
-   break;
- Expression* ino_init = ino->var_value()->init();
- if (ino->var_value()->has_pre_init()
- || ino_init == NULL
- || !ino_init->is_static_initializer())
-   break;
- init = ino_init;
-   }
-
-  bool is_static_initializer;
-  if (init == NULL)
+  bool is_static_initializer = false;
+  if (var->init() == NULL)
 is_static_initializer = true;
   else
 {
   Type* var_type = var->type();
-  init = Expression::make_cast(var_type, init, 
var->location());
-  is_static_initializer = init->is_static_initializer();
+  Expression* init = var->init();
+  Expression* init_cast =
+  Expression::make_cast(var_type, init, var->location());
+  is_static_initializer = init_cast->is_static_initializer();
 }
 
  // Non-constant variable initializations might need to create
@@ -1655,15 +1640,7 @@ Gogo::write_globals()
 }
  var_init_fn = init_fndecl;
}
-
- Bexpression* var_binit;
- if (init == NULL)
-   var_binit = NULL;
- else
-   {
- Translate_context context(this, var_init_fn, NULL, NULL);
- var_binit = init->get_backend();
-   }
+  Bexpression* var_binit = var->get_init(this, var_init_fn);
 
   if (var_binit == NULL)
;
diff --git a/libgo/go/runtime/mpagealloc.go b/libgo/go/runtime/mpagealloc.go
index 2725e3b7c7b..5e40da45d17 100644
--- a/libgo/go/runtime/mpagealloc.go
+++ b/libgo/go/runtime/mpagealloc.go
@@ -87,7 +87,9 @@ const (
 //
 // We alias maxOffAddr just to make it clear that this is the maximum address
 // for the page allocator's search space. See maxOffAddr for details.
-var maxSearchAddr = maxOffAddr
+func maxSearchAddr() offAddr {
+   return maxOffAddr
+}
 
 // Global chunk index.
 //
@@ -331,13 +333,13 @@ func (p *pageAlloc) init(mheapLock *mutex, sysStat 
*sysMemStat) {
p.sysInit()
 
// Start with the searchAddr in a state indicating there's no free 
memory.
-   p.searchAddr = maxSearchAddr
+   p.searchAddr = maxSearchAddr()
 
// Set the mheapLock.
p.mheapLock = mheapLock
 
// Initialize scavenge tracking state.
-   p.scav.scavLWM = maxSearchAddr
+   p.scav.scavLWM = maxSearchAddr()
 }
 
 // tryChunkOf returns the bitmap data for the given chunk.
@@ -760,7 +762,7 @@ nextLevel:
}
if l == 0 {
// We're at level zero, so that means we've exhausted 
our search.
-   return 0, maxSearchAddr
+   return 0, 

[Bug target/105288] New: AVX/AVX512 casts should the "v" constraint

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

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

Bug ID: 105288
   Summary: AVX/AVX512 casts should the "v" constraint
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
Target: x86-64

There are

(define_insn_and_split "avx__"
  [(set (match_operand:AVX256MODE2P 0 "nonimmediate_operand" "=x,m")
(vec_concat:AVX256MODE2P
  (match_operand: 1 "nonimmediate_operand" "xm,x")
  (unspec: [(const_int 0)] UNSPEC_CAST)))]
  "TARGET_AVX && !(MEM_P (operands[0]) && MEM_P (operands[1]))"

where the "x" constraint should be "v".

[Bug c/100545] ICE with -g: in gen_typedef_die with mode attribute and aligned attribute

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #10 from Jan Hubicka  ---
Fixed.

GSoC thoughts on C++ static analyzer support

[Φώτης Βαλασιάδης via Gcc]

Hello all,

I am interested in said project, and I'd like to ask.

Is said project limited to providing static analysis for heap allocations
and file handles?  To be clear I am asking whether or not there are goals
beyond these two.

This pattern could pretty much be used for all resource-like objects such
as sockets, mutexes et cetera and point is that said problems in C++ are
already tackled by using RAII
. Now I understand that
RAII isn't always an option nor does it solve all problems (for example,
dangling references) so I am still fascinated by all of it and would like
to share my thoughts.

C++11 mutexes(locks, and generally speaking all thread header facilities)
could really use a static analyzer. Not only for the standard lock(),
unlock() checks but also for "enforcing" lock ordering and other important
guidelines. Read Anthony William's "Concurrency in Action" a while ago and
honestly if I had a compiler that performed all those checks he describes
in the book for me, which half of them I don't even remember anymore, THAT
would be something else.

Now I understand that this might be really complicated for a GSoC project,
but food for thought. Looking forward to hearing your thoughts on this.

Thanks for your time!

[Bug libstdc++/104858] ranges::minmax double dereferences first

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

Re: [PATCH] libstdc++: Avoid double-deref of __first in ranges::minmax [PR104858]

[Patrick Palka via Gcc-patches]

On Thu, 14 Apr 2022, Jonathan Wakely wrote:

> On Thu, 14 Apr 2022 at 16:21, Patrick Palka via Libstdc++
>  wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and 11/10
> > once the branch is unfrozen?
> >
> > PR libstdc++/104858
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/ranges_algo.h (__minmax_fn): Avoid dereferencing
> > __first twice at the start.
> > * testsuite/25_algorithms/minmax/constrained.cc (test06): New test.
> > ---
> >  libstdc++-v3/include/bits/ranges_algo.h   |  2 +-
> >  .../25_algorithms/minmax/constrained.cc   | 23 +++
> >  2 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
> > b/libstdc++-v3/include/bits/ranges_algo.h
> > index 62dc605080a..3d30fb1428c 100644
> > --- a/libstdc++-v3/include/bits/ranges_algo.h
> > +++ b/libstdc++-v3/include/bits/ranges_algo.h
> > @@ -3084,7 +3084,7 @@ namespace ranges
> > auto __last = ranges::end(__r);
> > __glibcxx_assert(__first != __last);
> > auto __comp_proj = __detail::__make_comp_proj(__comp, __proj);
> > -   minmax_result> __result = {*__first, 
> > *__first};
> > +   minmax_result> __result = {*__first, 
> > __result.min};
> 
> Clever ... I'm surprised this even works. I would have expected it to
> evaluate both initializers before actually initializing the members.
> TIL.

Indeed, it seems to do the right thing, practically speaking at least :)
FWIW the alternative approach

-   minmax_result> __result = {*__first, *__first};
+   minmax_result> __result;
+   __result.max = __result.min = *__first;

wouldn't be right because the value type is not necessarily default
constructible.  I beefed up the new testcase to verify we don't demand
default constructibility here.

[Bug libstdc++/104858] ranges::minmax double dereferences first

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:7e76cef873342a66408c126abceaf7dbddd3f477

commit r12-8178-g7e76cef873342a66408c126abceaf7dbddd3f477
Author: Patrick Palka 
Date:   Fri Apr 15 14:41:14 2022 -0400

libstdc++: Avoid double-deref of __first in ranges::minmax [PR104858]

PR libstdc++/104858

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__minmax_fn): Avoid dereferencing
__first twice at the start.
* testsuite/25_algorithms/minmax/constrained.cc (test06): New test.

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

[i at rvalue dot moe via Gcc-bugs]

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

--- Comment #15 from rvalue  ---
Hi, Kito:

I've tried these patches and found that it doesn't work with isa-spec
20190608/20191213.

Release 11.2.0 with following patches applied: 9871d39f752b, f41871dfdbd9,
f049717d8d50, 330aff0a9f7b, fa21fcfb6758

Verbose output:

$ cat > test.c
int main(){
asm volatile("fence.i" ::: "memory");
}
$ gcc test.c -o test -v -march=rv64gc -misa-spec=20191213
Using built-in specs.
COLLECT_GCC=/usr/sbin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--disable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--enable-link-serialization=1 gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-march=rv64gc' '-misa-spec=20191213'
'-mabi=lp64d' '-march=rv64imafdc'
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/cc1 -quiet -v test.c -quiet
-dumpbase test.c -dumpbase-ext .c -march=rv64gc -misa-spec=20191213 -mabi=lp64d
-march=rv64imafdc -version -o /tmp/ccQTUxnc.s
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/../../../../riscv64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/include
 /usr/local/include
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/include-fixed
 /usr/include
End of search list.
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7a7a4553dc5ab0b4f8fc26761070a0ed
COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-march=rv64gc' '-misa-spec=20191213'
'-mabi=lp64d' '-march=rv64imafdc'
 as -v --traditional-format -fpic -march=rv64gc -march=rv64imafdc -mabi=lp64d
-misa-spec=20191213 -o /tmp/cc2my6Or.o /tmp/ccQTUxnc.s
GNU assembler version 2.38 (riscv64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
test.c: Assembler messages:
test.c:2: Error: unrecognized opcode `fence.i'

[Bug jit/105279] Using libgccjit produces a null pointer access in GCC's tree-optimization code

[marc--- via Gcc-bugs]

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

--- Comment #1 from Marc Nieper-Wißkirchen  ---
The internal compiler error also seems to go away if I remove the pointer
subtraction around line 1833 in reproducer.c.  Maybe this is the real problem
because I am not subtracting pointers the way I should do in libgccjit (but
still, it shouldn't crash).  But if this is not the way to do it, is there
another way to achieve pointer subtraction (besides bitcasting the pointers to
integers)?

Re: [PATCH] testsuite: Skip pr105250.c for powerpc and s390 [PR105266]

[Segher Boessenkool]

On Thu, Apr 14, 2022 at 11:10:43AM +0800, Kewen.Lin wrote:
> Hi,
> 
> The test case pr105250.c is like its related pr105140.c, which
> suffers the error with message like "{AltiVec,vector} argument
> passed to unprototyped" on powerpc and s390.  So like commits
> r12-8025 and r12-8039, this fix is to add the dg-skip-if for
> powerpc*-*-* and s390*-*-*.
> 
> Tested on powerpc64le-linux-gnu P9 and it should work on s390
> as its similar PR105147.
> 
> Is it ok for trunk?

Yes.  Thanks!


Segher

Re: GSoC proposal for extending static analyzer

[Mir Immad via Gcc]

I've updated the link on the repo -- https://mirimmad.github.io/zeta-lang.

> You don't give many specifics in your personal decription.  One thing
> I'm not seeing is a sense of how proficient you are in various
> programming languages.  In particular, how is your C and C++?  How
> familiar are you with the debugger?  Looking at your github, you seem
> to have relevant experience in compilers, which is great, but all your
> code appears to be with "managed" languages such as Ruby, Java, and
> Python  [and Zeta :)].

 I'm pretty comfortable with both C and C++ and manual mem management .
Unfortunately, I don't have any project in C/C++ to show. Maybe I can use
the time before May 20 to write something in cpp?
About the debugger, I'm okay-ish with it. In fact, it was due to the
debugger (and your blog on it) that I was initially able to walk through
the codebase.


> That said, I got
> the sense from your previous emails that you're not very familiar with
> the APIs, and that you chose them because that was the suggestion I had
> made on the wiki page.

thats right.


>  Obviously it's something you can learn on the
>  way, but it would be better to accurately identify which areas you're
> going need to learn along the way, and the timetable and scope should
> reflect that.

If I understand the statement correctly; currently I'm thinking of
extending the support for open() (for creating the fd), write/read (for
working on the fd) and close(). This is quite analogous to what we have in
sm-file. Please let me know how do you want the analyzer to be extended and
if you expect support for any other FD APIs  too as I understand there are
many other APIs for creating and working wiith FDs?

Thank you.



On Fri, Apr 15, 2022 at 9:35 PM David Malcolm  wrote:

> On Fri, 2022-04-15 at 19:58 +0530, Mir Immad wrote:
> > I've submitted a proposal for extending the static analyzer to support
> > posix fd APIs on GSoC website. Here is the Google docs link (gdocs
> > <
> >
> https://docs.google.com/document/d/188zxPUsuYcF-uGVYL_G1s2RVtHhJSZeQ4sha40H7374/edit?usp=sharing
> > >).
> >
> >
> > Please take a look and let me know what you think.
> >
> > Thank you.
>
> Thanks.
>
> FWIW, I'm getting an error when trying the URL given in your github
> repo: http://mirimmad.me/
> but https://mirimmad.github.io/ seems to work  - but it's almost empty.
>
> You don't give many specifics in your personal decription.  One thing
> I'm not seeing is a sense of how proficient you are in various
> programming languages.  In particular, how is your C and C++?  How
> familiar are you with the debugger?  Looking at your github, you seem
> to have relevant experience in compilers, which is great, but all your
> code appears to be with "managed" languages such as Ruby, Java, and
> Python  [and Zeta :)].
>
> Also, the proposal is to extend the analyzer to cover a specific
> domain: various POSIX APIs.  Can you please give a sense of your level
> of expertise with these APIs?  I was pleased at your initiative in
> trying to reuse the existing code to work with them.  That said, I got
> the sense from your previous emails that you're not very familiar with
> the APIs, and that you chose them because that was the suggestion I had
> made on the wiki page.  Obviously it's something you can learn on the
> way, but it would be better to accurately identify which areas you're
> going need to learn along the way, and the timetable and scope should
> reflect that.
>
> Hope this is constructive
> Dave
>
>
>

[PATCH] PR target/89125

[Steve Kargl via Gcc-patches]

Can someone, anyone, please commit the attach patch, which is 
also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
where one can read the audit trail.  The original patch was 
submitted 2 years ago, and required manual intervention due to
the recent *.c to *.cc rename.

Back story: When GCC is configured and built on non-glibc platforms,
it seems very little to no effort is made to enumerate the available
C99 libm functions.  It is all or nothing for C99 libm.  The patch
introduces a new function, used on only FreeBSD, to inform gcc that
it has C99 libm functions (minus a few which clearly GCC does not check
nor test).

The patch introduces no regression on x86_64-*-freebsd while
allowing an additional 31 new passes.

=== gcc Summary ===
w/o patch  w patch
# of expected passes175405 175434
# of unexpected failures1081   1051
# of unexpected successes   20 20
# of expected failures  1459   1459
# of unresolved testcases   10 10
# of unsupported tests  3252   3252

=== g++ Summary ===
w/o patch  w patch
# of expected passes225338 225341
# of unexpected failures678676
# of expected failures  2071   2071
# of unresolved testcases   11 11
# of unsupported tests  10353  10353

=== gfortran Summary ===
w/o patch  w patch
# of expected passes65901  65901
# of unexpected failures12 12
# of expected failures  272272
# of unsupported tests  100100


2022-04-15  Steven G. Kargl  

PR target/89125
* config/freebsd.h: Define TARGET_LIBC_HAS_FUNCTION to be
bsd_libc_has_function.
* gcc/targhooks.cc(bsd_libc_has_function): New function.
Expand the supported math functions to inclue C99 libm.
* gcc/targhooks.h: Prototype for bsd_libc_has_function.

-- 
Steve
diff --git a/gcc/config/freebsd.h b/gcc/config/freebsd.h
index 28ebcad88d4..d89ee7dfc97 100644
--- a/gcc/config/freebsd.h
+++ b/gcc/config/freebsd.h
@@ -55,7 +55,7 @@ along with GCC; see the file COPYING3.  If not see
 #endif
 
 #undef TARGET_LIBC_HAS_FUNCTION
-#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
+#define TARGET_LIBC_HAS_FUNCTION bsd_libc_has_function
 
 /* Use --as-needed -lgcc_s for eh support.  */
 #ifdef HAVE_LD_AS_NEEDED
diff --git a/gcc/targhooks.cc b/gcc/targhooks.cc
index e22bc66a6c8..ff127763cf2 100644
--- a/gcc/targhooks.cc
+++ b/gcc/targhooks.cc
@@ -1843,6 +1843,20 @@ no_c99_libc_has_function (enum function_class fn_class ATTRIBUTE_UNUSED,
   return false;
 }
 
+/* Assume some c99 functions are present at the runtime including sincos.  */ 
+bool
+bsd_libc_has_function (enum function_class fn_class,
+		   tree type ATTRIBUTE_UNUSED)
+{
+  if (fn_class == function_c94
+  || fn_class == function_c99_misc
+  || fn_class == function_sincos)
+return true;
+
+  return false;
+}
+
+
 tree
 default_builtin_tm_load_store (tree ARG_UNUSED (type))
 {
diff --git a/gcc/targhooks.h b/gcc/targhooks.h
index ecfa11287ef..ecce55ebe79 100644
--- a/gcc/targhooks.h
+++ b/gcc/targhooks.h
@@ -212,6 +212,7 @@ extern bool default_libc_has_function (enum function_class, tree);
 extern bool default_libc_has_fast_function (int fcode);
 extern bool no_c99_libc_has_function (enum function_class, tree);
 extern bool gnu_libc_has_function (enum function_class, tree);
+extern bool bsd_libc_has_function (enum function_class, tree);
 
 extern tree default_builtin_tm_load_store (tree);
 

Re: GSoC proposal for extending static analyzer

[David Malcolm via Gcc]

On Fri, 2022-04-15 at 19:58 +0530, Mir Immad wrote:
> I've submitted a proposal for extending the static analyzer to support
> posix fd APIs on GSoC website. Here is the Google docs link (gdocs
> <
> https://docs.google.com/document/d/188zxPUsuYcF-uGVYL_G1s2RVtHhJSZeQ4sha40H7374/edit?usp=sharing
> >).
> 
> 
> Please take a look and let me know what you think.
> 
> Thank you.

Thanks.

FWIW, I'm getting an error when trying the URL given in your github
repo: http://mirimmad.me/
but https://mirimmad.github.io/ seems to work  - but it's almost empty.

You don't give many specifics in your personal decription.  One thing
I'm not seeing is a sense of how proficient you are in various
programming languages.  In particular, how is your C and C++?  How
familiar are you with the debugger?  Looking at your github, you seem
to have relevant experience in compilers, which is great, but all your
code appears to be with "managed" languages such as Ruby, Java, and
Python  [and Zeta :)].

Also, the proposal is to extend the analyzer to cover a specific
domain: various POSIX APIs.  Can you please give a sense of your level
of expertise with these APIs?  I was pleased at your initiative in
trying to reuse the existing code to work with them.  That said, I got
the sense from your previous emails that you're not very familiar with
the APIs, and that you chose them because that was the suggestion I had
made on the wiki page.  Obviously it's something you can learn on the
way, but it would be better to accurately identify which areas you're
going need to learn along the way, and the timetable and scope should
reflect that.

Hope this is constructive
Dave

[Bug c++/101500] [C++17] [DR2311] gcc accepts the code with extra curly braces

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] gcc |[C++17] [DR2311] gcc
   |accepts the code with extra |accepts the code with extra
   |curly braces|curly braces
 Status|NEW |SUSPENDED
URL||wg21.link/cwg2311

--- Comment #2 from Jason Merrill  ---
This seems like an instance of issue 2311: with C++17 mandatory copy elision,
do we really want an actual call to the move constructor in this case?  The
testcase is rejected in C++14 mode, as expected.

The standard says that we try to call a constructor, initializing the argument
with {A{}}.  So we in turn look for an A constructor to initialize the
argument, initializing its argument from A{}.  Under 2311, does this result in
still an rvalue?  And the enclosing constructor call, still the same rvalue?

This seems parallel to

const A a = A(A(A()));

which is also accepted by clang in C++17 mode.

Perhaps we want to raise the priority of issue 2311.

[Bug c++/105268] type/value mismatch when using variadic concept

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 12.

[Bug c++/105268] type/value mismatch when using variadic concept

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r12-8176-gccae4443c8322d9d82a19a1e7c689413a122a478
Author: Marek Polacek 
Date:   Thu Apr 14 13:48:15 2022 -0400

c++: wrong error with variadic concept [PR105268]

Here we issue a wrong error for the

  template>> void g();

line in the testcase.  I surmise that's because we mistakenly parse
C_many as a placeholder-type-specifier, and things go wrong from
there.  We are in a default argument so we should reject parsing
C_many
as a placeholder-type-specifier, which would mean creating a new parameter.
We want C_many to be a concept-id instead.

It's interesting to see why the same problem didn't occur for C_one.
In that case, cp_parser_placeholder_type_specifier ->
finish_type_constraints
-> build_type_constraint -> build_concept_check -> build_standard_check ->
coerce_template_parms fails the parse here:

 8916   nargs = inner_args ? NUM_TMPL_ARGS (inner_args) : 0;
 8917   if ((nargs - variadic_args_p > nparms && !variadic_p)
 8918   || (nargs < nparms - variadic_p
 8919   && require_all_args
 8920   && !variadic_args_p
 8921   && (!use_default_args
 8922   || (TREE_VEC_ELT (parms, nargs) != error_mark_node
 8923   && !TREE_PURPOSE (TREE_VEC_ELT (parms, nargs))
 8924 {
 8925 bad_nargs:
 ...
 8943   return error_mark_node;

because nargs is 2 (the targs are ) while nparms is
1 (for the one 'typename' in the tparam list of C_one).  But for
C_many variadic_p is true so we don't return error_mark_node but
.

This patch does not issue any error for the !tentative case because
I didn't figure out how to trigger that.  So it adds an assert instead.

PR c++/105268

gcc/cp/ChangeLog:

* parser.cc (cp_parser_placeholder_type_specifier): Return
error_mark_node when trying to build up a constrained parameter in
a default argument.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/variadic6.C: New test.

[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 #2 from Iain Sandoe  ---
(In reply to David Malcolm from comment #1)
> Confirmed; it's an assertion failing in
> ana::frame_region::get_region_for_local, due to a variable having NULL for
> its DECL_CONTEXT:
> 
> (gdb) list
> 869   case SSA_NAME:
> 870 {
> 871   if (tree var = SSA_NAME_VAR (expr))
> 872 {
> 873   if (DECL_P (var))
> 874 gcc_assert (DECL_CONTEXT (var) == m_fun->decl);
> 875 }
> 
> This is probably benign if assertions are disabled (perhaps the analyzer is
> being more fussy than the rest of the middle-end?)
> 
> (gdb) call debug_tree(var)
>   type  type_6 QI
> size 
> unit-size 
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7fffea665b28 precision:1 min  max
> 
> pointer_to_this >
> unsigned QI ../../src/gcc/testsuite/g++.dg/analyzer/pr105287.C:35:73
> size  unit-size 
> align:8 warn_if_not_align:0>
> (gdb) p var.decl_minimal.context 
> $2 = 
> 
> 
> The var_decl is "cond_var" created here in the C++ FE:
> 
> #4  0x00b30ec2 in flatten_await_stmt (n=0x317b9b0,
> promoted=0x7fffcc40, temps_used=0x7fffcc70, replace_in= out>)
> at ../../src/gcc/cp/coroutines.cc:2792
> 2792tree cond_var  = build_lang_decl (VAR_DECL, NULL_TREE,
> cond_type);
> (gdb) list
> 2787/* If the condition contains an await expression, then we 
> need to
> 2788   set that first and use a separate var.  */
> 2789if (cp_walk_tree (, find_any_await, , NULL))
> 2790  {
> 2791tree cond_type = TREE_TYPE (cond);
> 2792tree cond_var  = build_lang_decl (VAR_DECL, NULL_TREE,
> cond_type);
> 2793DECL_ARTIFICIAL (cond_var) = true;
> 2794layout_decl (cond_var, 0);
> 2795gcc_checking_assert (!TYPE_NEEDS_CONSTRUCTING 
> (cond_type));
> 2796cond = build2 (INIT_EXPR, cond_type, cond_var, cond);
> 2797var_nest_node *ins
> 2798  = new var_nest_node (cond_var, cond, n->prev, n);
> 2799COND_EXPR_COND (n->init) = cond_var;
> 2800flatten_await_stmt (ins, promoted, temps_used, NULL);
> 2801  }
> 
> Iain: shouldn't the DECL_CONTEXT be being set on var_decls created here?

I'd expect so; does build_lang_decl() not add them to the current context? [I
didn't look at the code, and memory might be faulty there].  If it doesn't then
I need to take a pass through and add the appropriate one.

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

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

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

--- Comment #3 from David Malcolm  ---
Thanks for filing this bug; I can reproduce it with the initial attachment;
it's unclear to me yet what's going on.

[Bug c++/102651] [9/10/11/12 Regression] typeid(X**) instantiates X caused by r0-109856

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/102651] [9/10/11/12 Regression] typeid(X**) instantiates X caused by r0-109856

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
Created attachment 52817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52817=edit
fix

Here's a fix, but I'm going to hold it for stage 1, probably backport for 12.2
etc.

[Bug analyzer/105287] [12 Regression] ICE in get_region_for_local, at analyzer/region.cc:874

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-04-15
 CC||iains at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
Confirmed; it's an assertion failing in
ana::frame_region::get_region_for_local, due to a variable having NULL for its
DECL_CONTEXT:

(gdb) list
869 case SSA_NAME:
870   {
871 if (tree var = SSA_NAME_VAR (expr))
872   {
873 if (DECL_P (var))
874   gcc_assert (DECL_CONTEXT (var) == m_fun->decl);
875   }

This is probably benign if assertions are disabled (perhaps the analyzer is
being more fussy than the rest of the middle-end?)

(gdb) call debug_tree(var)
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea665b28 precision:1 min  max 
pointer_to_this >
unsigned QI ../../src/gcc/testsuite/g++.dg/analyzer/pr105287.C:35:73 size
 unit-size 
align:8 warn_if_not_align:0>
(gdb) p var.decl_minimal.context 
$2 = 


The var_decl is "cond_var" created here in the C++ FE:

#4  0x00b30ec2 in flatten_await_stmt (n=0x317b9b0,
promoted=0x7fffcc40, temps_used=0x7fffcc70, replace_in=)
at ../../src/gcc/cp/coroutines.cc:2792
2792  tree cond_var  = build_lang_decl (VAR_DECL, NULL_TREE,
cond_type);
(gdb) list
2787  /* If the condition contains an await expression, then we
need to
2788 set that first and use a separate var.  */
2789  if (cp_walk_tree (, find_any_await, , NULL))
2790{
2791  tree cond_type = TREE_TYPE (cond);
2792  tree cond_var  = build_lang_decl (VAR_DECL, NULL_TREE,
cond_type);
2793  DECL_ARTIFICIAL (cond_var) = true;
2794  layout_decl (cond_var, 0);
2795  gcc_checking_assert (!TYPE_NEEDS_CONSTRUCTING
(cond_type));
2796  cond = build2 (INIT_EXPR, cond_type, cond_var, cond);
2797  var_nest_node *ins
2798= new var_nest_node (cond_var, cond, n->prev, n);
2799  COND_EXPR_COND (n->init) = cond_var;
2800  flatten_await_stmt (ins, promoted, temps_used, NULL);
2801}

Iain: shouldn't the DECL_CONTEXT be being set on var_decls created here?

GSoC proposal for extending static analyzer

[Mir Immad via Gcc]

I've submitted a proposal for extending the static analyzer to support
posix fd APIs on GSoC website. Here is the Google docs link (gdocs
).


Please take a look and let me know what you think.

Thank you.

Re: [wwwdocs] Add Ada's changelog entry

[Fernando Oleo Blanco via Gcc-patches]

Am Wed, 13 Apr 2022 23:04:17 -0600 (MDT)
schrieb "Gerald Pfeifer" :

> On Wed, 13 Apr 2022, Gerald Pfeifer wrote:
> > This is the first batch of fixes. Pushed.
>
> Hmm, there is one issue that confused me a bit. What did you want to
> relay by the following?
>
>+Pattern matching
>+
>+  The case statement has been extended to
> cover
>
> Currently that is a  within a , which does not work. Did you
> mean to skip the  and have that after the nested ?
>
> Gerald

Hi Gerald,

thank you for your comments. As you have picked up, HTML is not my
strongest language.

I did not know that "<" and ">" had to scaped in HTML, I will try to
remember that.

Regarding the nested . Since I did not know HTML, I looked at how
nested structure/lists are generated. Since the changelog uses
sequences of  and  to indent/create a nested list, so I did. I
wanted to have a "title" (Pattern matching) and then have the
explanation with the code. Therefore, I copied the ,  sequence
to get another level of nesting.

I checked my results by opening the file in Firefox (latest version)
and it renders properly as I would expect/as I just explained. Is this
not correct? Is Firefox trying to make it work/trying to understand
what I meant and reproducing it as such?

Thank you for your feedback. Regards,
Fer

[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken

[esgergn at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from Esger Abbink  ---
After patching ccache 4.5.1 to understand -fprofile-prefix-map it does cache .o
and .gcno:

$ ccache -z -C

$ cd /home/esger/src/application/coverage_test/dir1/source/ && CCACHE_DEBUG=
CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir1 ccache
/usr/bin/g++-9.4p --coverage
-fprofile-prefix-map=/home/esger/src/application/coverage_test/dir1=.
-fdebug-prefix-map=/home/esger/src/application/coverage_test/dir1=. -c
/home/esger/src/application/coverage_test/dir1/source/main.cpp

$ ccache -s
Summary:
  Hits:   0 /1 (0.00 %)
Direct:   0 /1 (0.00 %)
Preprocessed: 0 /1 (0.00 %)
  Misses: 1
Direct:   1
Preprocessed: 1
Primary storage:
  Hits:   0 /2 (0.00 %)
  Misses: 2
  Cache size (GB): 0.00 / 5.00 (0.00 %)
  Cleanups:   4

$ cd /home/esger/src/application/coverage_test/dir2/source/ && CCACHE_DEBUG=
CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir2 ccache
/usr/bin/g++-9.4p --coverage
-fprofile-prefix-map=/home/esger/src/application/coverage_test/dir2=.
-fdebug-prefix-map=/home/esger/src/application/coverage_test/dir2=. -c
/home/esger/src/application/coverage_test/dir2/source/main.cpp

$ ccache -s
Summary:
  Hits:   1 /2 (50.00 %)
Direct:   1 /2 (50.00 %)
Preprocessed: 0 /1 (0.00 %)
  Misses: 1
Direct:   1
Preprocessed: 1
Primary storage:
  Hits:   2 /4 (50.00 %)
  Misses: 2
  Cache size (GB): 0.00 / 5.00 (0.00 %)
  Cleanups:   4

Using the cached .o/.gcno also generates a gcda in the correct location:

$ cd /home/esger/src/application/coverage_test/dir2/source/ && CCACHE_DEBUG=
CCACHE_BASEDIR=/home/esger/src/application/coverage_test/dir2 ccache
/usr/bin/g++-9.4p --coverage
-fprofile-prefix-map=/home/esger/src/application/coverage_test/dir2=.
-fdebug-prefix-map=/home/esger/src/application/coverage_test/dir2=. main.o -o
../bin/a.out

$ cd /home/esger/src/application/coverage_test/dir2 && ./bin/a.out

$ ls source/
main.cpp  main.gcda  main.gcno  main.o

$ gcovr --html coverage.html .
[ coverage report OK ]



Though the gcno of source still contains a wrong CWD:

$ gcov-dump-9.4p source/main.gcno |more
main.gcno:note:magic `gcno':version `A94*'
main.gcno:stamp 761679940
main.gcno:cwd: /home/esger/src/application/coverage_test/dir1/source
main.gcno:  0100:  20:FUNCTION ident=1826217343,
lineno_checksum=0x36a9d8e5, cfg_checksum=0xc0bbb23e, `_GLOBAL__sub_I__Z5funcAi'
main.cpp:21:1-21:1, artificial
main.gcno:0141:   1:BLOCKS 4 blocks
main.gcno:0143:   3:ARCS 1 arcs
main.gcno:0143:   5:ARCS 2 arcs
main.gcno:0143:   3:ARCS 1 arcs
main.gcno:0145:   9:LINES
main.gcno:0145:   9:LINES
...


Not sure though what (negative) impact that will/could have?

[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 #9 from Michael_S  ---
(In reply to Michael_S from comment #4)
> If you want quick fix for immediate shipment then you can take that:
> 
> #include 
> #include 
> 
> __float128 quick_and_dirty_sqrtq(__float128 x)
> {
>   if (isnanq(x))
> return x;
> 
>   if (x==0)
> return x;
> 
>   if (x < 0)
> return nanq("");
> 
>   if (isinfq(x))
> return x;
> 
>   int xExp;
>   x = frexpq(x, );
>   if (xExp & 1)
> x *= 2.0; // x in [0.5:2.0)
> 
>   __float128 r = (__float128)(1.0/sqrt((double)x)); // r=rsqrt(x) estimate
> (53 bits)
>   r *= 1.5 - r*r*x*0.5; // NR iteration improves precision of r to 105.4 bit
> 
>   __float128 y  = x*r;  // y=sqrt(x) estimate (105.4 bits)
> 
>   // extended-precision NR iteration
>   __float128 yH = (double)y;
>   __float128 yL = y - yH;
> 
>   __float128 deltaX = x - yH*yH;
>   deltaX -= yH*yL*2;
>   deltaX -= yL*yL;
>   y += deltaX*r*0.5; // improve precision of y to ~210.2 bits. Not enough
> for perfect rounding, but not too bad
> 
>   return ldexpq(y, xExp >> 1);
> }
> 
> It is very slow, even slower than what you have now, which by itself is
> quite astonishingly slow.
> It is also not sufficiently precise for correct rounding in all cases.
> But, at least, the worst error is something like (0.5+2**-98) ULP, so you are
> unlikely to be ever caught by black box type of testing.
> It's biggest advantage is extreme portability.
> Should run on all platforms where double==IEEE binary64 and __float128 ==
> IEEE binary128.
> 
> May be, few days later I'll have better variant for "good" 64-bit platforms
> i.e. for those where we have __int128.
> It would be 15-25 times faster than the variant above and rounding would be
> mathematically correct rather than just "impossible to be caught" like above.
> But it would not run everywhere.
> Also, I want to give it away under MIT or BSD license, rather than under GPL.

Here.

#include 
#include 
#include 

static __inline uint64_t umulx64(uint64_t mult1, uint64_t mult2, int rshift)
{
  return (uint64_t)(((unsigned __int128)mult1 * mult2)>>rshift);
}

static __inline uint64_t umulh64(uint64_t mult1, uint64_t mult2)
{
  return umulx64(mult1, mult2, 64);
}

static __inline __float128 ret__float128(uint64_t wordH, uint64_t wordL) {
  unsigned __int128 res_u128 = ((unsigned __int128)wordH << 64) | wordL;
  __float128 result;
  memcpy(, _u128, sizeof(result)); // hopefully __int128 and
__float128 have the endianness
  return result;
}

__float128 slow_and_clean_sqrtq(__float128 src)
{
  typedef unsigned __int128 __uint128;
  const uint64_t SIGN_BIT   = (uint64_t)1  << 63;
  const uint64_t MANT_H_MSK = (uint64_t)-1 >> 16;
  const uint64_t nNAN_MSW = (uint64_t)0x8 << 44; // -NaN

  __uint128 src_u128;
  memcpy(_u128, , sizeof(src_u128));
  uint64_t mshalf = (uint64_t)(src_u128 >> 64); // MS half
  uint64_t mantL  = (uint64_t)(src_u128);   // LS half

  // parse MS half of source
  unsigned exp   = mshalf >> 48;
  uint64_t mantH = mshalf & MANT_H_MSK;
  unsigned expx = exp + 0x3FFF;
  if (exp - 1 >= 0x7FFF-1) { // special cases: exp = 0, exp=max_exp or sign=1
if (exp > 0x7fff) {  // negative
  if (exp==0x) { // NaN or -Inf
if ((mantH | mantL)==0) // -Inf
  mshalf = nNAN_MSW;
return ret__float128(mshalf, mantL); // in case of NaN the leave number
intact
  }
  if (mshalf==SIGN_BIT && mantL==0) // -0
return ret__float128(mshalf, mantL); // in case of -0 leave the number
intact
  // normal or sub-normal
  mantL = 0;
  mshalf = nNAN_MSW;
  return ret__float128(mshalf, mantL);
}
// non-negative
if (exp == 0x7fff) // NaN or -Inf
  return ret__float128(mshalf, mantL); // in case of positive NaN or Inf
leave the number intact

// exp==0 : zero or subnormal
if ((mantH | mantL)==0) // +0
  return ret__float128(mshalf, mantL); // in case of +0 leave the number
intact

// positive subnormal
// normalize
if (mantH == 0) {
  expx -= 48;
  int lz = __builtin_clzll(mantL);
  expx -= lz;
  mantL <<= lz + 1;
  mantH = mantL >> 16;
  mantL = mantL << 48;
} else {
  int lz = __builtin_clzll(mantH)-16;
  expx -= lz;
  mantH = (mantH << (lz+1)) | mantL >> (63-lz);
  mantL = mantL << (lz + 1);
}
mantH &= MANT_H_MSK;
  }

  // Normal case
  int e = expx & 1; // e= LS bit of exponent

  const uint64_t BIT_30 = (uint64_t)1 << 30;
  static const uint8_t rsqrt_tab[64] = { // floor(1/sqrt(1+i/32)*512) - 256
   252, 248, 244, 240,237, 233, 230, 226,
   223, 220, 216, 213,210, 207, 204, 201,
   199, 196, 193, 190,188, 185, 183, 180,
   178, 175, 173, 171,168, 166, 164, 162,
   159, 157, 155, 153,151, 149, 147, 145,
   143, 141, 139, 138,136, 134, 132, 131,
   129, 127, 125, 124,122, 121, 119, 117,
   116, 114, 113, 111,110, 108, 107, 106,
 };

  // Look for approximate value of rsqrt(x)=1/sqrt(x)
  // 

[Bug libstdc++/105284] missing syncstream and spanstream forward decl. in

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-15
 Ever confirmed|0   |1
   Target Milestone|--- |12.0

[Bug libstdc++/105281] status of constexpr and for c++23

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

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

--- Comment #1 from Jonathan Wakely  ---
Those changes in  have been present since GCC 4.6, so they predate the
C++23 changes by *many* years. Nobody has yet verified how closely it conforms
to the new C++23 spec.

[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken

[esgergn at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from Esger Abbink  ---
Cherry picking
https://github.com/gcc-mirror/gcc/commit/cde87638bf5cf6aafffb590986b6a890da0ba06c
on top of releases-9.4.0 allowed me to apply the patch to get a patched gcc9.4
supporting -fprofile-prefix-map and that leads to the same (desired) behavior
as described in the previous comment for patched gcc11, plus gcovr is now able
to produce coverage reports.

However, all is still not well, because ccache does not know the
-fprofile-prefix-map option and therefore marks files compiled with it as
uncacheable.. :(

[Bug analyzer/105287] New: [12 Regression] ICE in get_region_for_local, at analyzer/region.cc:874

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 105287
   Summary: [12 Regression] ICE in get_region_for_local, at
analyzer/region.cc:874
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 52816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52816=edit
Testcase

g++ 12.0.1 20220410 snapshot (g:54c5e064cc3dc3c9b3dff12b6d48dc3efd482b07) ICEs
when compiling the attached testcase, reduced from
gcc/testsuite/g++.dg/coroutines/torture/co-await-18-if-cond.C, w/ -std=c++20
-fanalyzer:

% g++-12.0.1 -std=c++20 -fanalyzer -c refdaee6.C
during IPA pass: analyzer
refdaee6.C:35:73: internal compiler error: in get_region_for_local, at
analyzer/region.cc:874
   35 | coro1 my_coro() { co_await BoolAwaiter(true) && co_await IntAwaiter(1);
}
  |
^
0x89b2d6 ana::frame_region::get_region_for_local(ana::region_model_manager*,
tree_node*, ana::region_model_context const*) const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/region.cc:874
0x157c5e9 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*) const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/region-model.cc:2138
0x157c5e9 ana::region_model::get_lvalue(tree_node*, ana::region_model_context*)
const
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/region-model.cc:2149
0x15b8915 fully_overwrites_p
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/state-purge.cc:840
0x15b8915
ana::state_purge_per_decl::process_point_backwards(ana::function_point const&,
auto_vec*, hash_set >*, ana::state_purge_map const&,
ana::region_model const&)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/state-purge.cc:928
0x15b8fae ana::state_purge_per_decl::process_worklists(ana::state_purge_map
const&, ana::region_model_manager*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/state-purge.cc:742
0x15bb1f1 ana::state_purge_map::state_purge_map(ana::supergraph const&,
ana::region_model_manager*, ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/state-purge.cc:262
0x155f824 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/engine.cc:5728
0x156047e ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/engine.cc:5851
0x154f108 execute
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220410/work/gcc-12-20220410/gcc/analyzer/analyzer-pass.cc:87

Re: [PATCH] i386: Correct target attribute for crc32 intrinsics

[Uros Bizjak via Gcc-patches]

On Fri, Apr 15, 2022 at 10:34 AM Hongyu Wang  wrote:
>
> > This test should not be changed, it correctly reports ISA mismatch. It
> > even passes -mno-crc32.
>
> The error message changes from "needs isa option -mcrc32" to "target
> specific option mismatch" with the #pragma change.
> I see many of our intrinsic would throw such error, it has been a long
> term issue for intrinsic diagnostic.
>
> So for this test either I change the dg-error message or the call to
> builtin, otherwise it would fail.

Please update the dg-error message.

OK with the above change.

Thanks,
Uros.

>
> Uros Bizjak via Gcc-patches  于2022年4月15日周五 15:54写道：
> >
> > On Fri, Apr 15, 2022 at 6:30 AM Hongyu Wang  wrote:
> > >
> > > Hi,
> > >
> > > Complile _mm_crc32_u8/16/32/64 intrinsics with -mcrc32
> > > would meet target specific option mismatch. Correct target pragma
> > > to fix.
> > >
> > > Bootstrapped/regtest on x86_64-pc-linux-gnu{-m32,}.
> > >
> > > Ok for master and backport to GCC 11?
> > >
> > > gcc/ChangeLog:
> > >
> > > * config/i386/smmintrin.h: Correct target pragma from sse4.1
> > > and sse4.2 to crc32 for crc32 intrinsics.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * gcc.target/i386/crc32-6.c: Adjust to call builtin.
> > > * gcc.target/i386/crc32-7.c: New test.
> > > ---
> > >  gcc/config/i386/smmintrin.h | 25 +-
> > >  gcc/testsuite/gcc.target/i386/crc32-6.c |  2 +-
> > >  gcc/testsuite/gcc.target/i386/crc32-7.c | 34 +
> > >  3 files changed, 42 insertions(+), 19 deletions(-)
> > >  create mode 100644 gcc/testsuite/gcc.target/i386/crc32-7.c
> > >
> > > diff --git a/gcc/config/i386/smmintrin.h b/gcc/config/i386/smmintrin.h
> > > index b42b212300f..eb6a451c10a 100644
> > > --- a/gcc/config/i386/smmintrin.h
> > > +++ b/gcc/config/i386/smmintrin.h
> > > @@ -810,17 +810,11 @@ _mm_cmpgt_epi64 (__m128i __X, __m128i __Y)
> > >
> > >  #include 
> > >
> > > -#ifndef __SSE4_1__
> > > +#ifndef __CRC32__
> > >  #pragma GCC push_options
> > > -#pragma GCC target("sse4.1")
> > > -#define __DISABLE_SSE4_1__
> > > -#endif /* __SSE4_1__ */
> > > -
> > > -#ifndef __SSE4_2__
> > > -#pragma GCC push_options
> > > -#pragma GCC target("sse4.2")
> > > -#define __DISABLE_SSE4_2__
> > > -#endif /* __SSE4_1__ */
> > > +#pragma GCC target("crc32")
> > > +#define __DISABLE_CRC32__
> > > +#endif /* __CRC32__ */
> > >
> > >  /* Accumulate CRC32 (polynomial 0x11EDC6F41) value.  */
> > >  extern __inline unsigned int __attribute__((__gnu_inline__, 
> > > __always_inline__, __artificial__))
> > > @@ -849,14 +843,9 @@ _mm_crc32_u64 (unsigned long long __C, unsigned long 
> > > long __V)
> > >  }
> > >  #endif
> > >
> > > -#ifdef __DISABLE_SSE4_2__
> > > -#undef __DISABLE_SSE4_2__
> > > +#ifdef __DISABLE_CRC32__
> > > +#undef __DISABLE_CRC32__
> > >  #pragma GCC pop_options
> > > -#endif /* __DISABLE_SSE4_2__ */
> > > -
> > > -#ifdef __DISABLE_SSE4_1__
> > > -#undef __DISABLE_SSE4_1__
> > > -#pragma GCC pop_options
> > > -#endif /* __DISABLE_SSE4_1__ */
> > > +#endif /* __DISABLE_CRC32__ */
> > >
> > >  #endif /* _SMMINTRIN_H_INCLUDED */
> > > diff --git a/gcc/testsuite/gcc.target/i386/crc32-6.c 
> > > b/gcc/testsuite/gcc.target/i386/crc32-6.c
> > > index 464e3444069..1f306534bb8 100644
> > > --- a/gcc/testsuite/gcc.target/i386/crc32-6.c
> > > +++ b/gcc/testsuite/gcc.target/i386/crc32-6.c
> > > @@ -7,7 +7,7 @@
> > >  unsigned int
> > >  test_mm_crc32_u8 (unsigned int CRC, unsigned char V)
> > >  {
> > > -  return _mm_crc32_u8 (CRC, V);
> > > +  return __builtin_ia32_crc32qi (CRC, V);
> >
> > This test should not be changed, it correctly reports ISA mismatch. It
> > even passes -mno-crc32.
> >
> > Uros.
> >
> > >  }
> > >
> > >  /* { dg-error "needs isa option -mcrc32" "" { target *-*-* } 0  } */
> > > diff --git a/gcc/testsuite/gcc.target/i386/crc32-7.c 
> > > b/gcc/testsuite/gcc.target/i386/crc32-7.c
> > > new file mode 100644
> > > index 000..2e310e38b82
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/i386/crc32-7.c
> > > @@ -0,0 +1,34 @@
> > > +/* { dg-do compile } */
> > > +/* { dg-options "-O2 -mcrc32" } */
> > > +/* { dg-final { scan-assembler "crc32b\[^\\n\]*eax" } } */
> > > +/* { dg-final { scan-assembler "crc32w\[^\\n\]*eax" } } */
> > > +/* { dg-final { scan-assembler "crc32l\[^\\n\]*eax" } } */
> > > +/* { dg-final { scan-assembler "crc32q\[^\\n\]*rax" { target { ! ia32 } 
> > > } } } */
> > > +
> > > +#include 
> > > +
> > > +unsigned int
> > > +test_mm_crc32_u8 (unsigned int CRC, unsigned char V)
> > > +{
> > > +  return _mm_crc32_u8 (CRC, V);
> > > +}
> > > +
> > > +unsigned int
> > > +test_mm_crc32_u16 (unsigned int CRC, unsigned short V)
> > > +{
> > > +  return _mm_crc32_u16 (CRC, V);
> > > +}
> > > +
> > > +unsigned int
> > > +test_mm_crc32_u32 (unsigned int CRC, unsigned int V)
> > > +{
> > > +  return _mm_crc32_u32 (CRC, V);
> > > +}
> > > +
> > > +#ifdef __x86_64__
> > > +unsigned long long
> > > +test_mm_crc32_u64 

[Bug jit/105286] New: Struct initializers do not work with function pointers

[marc--- via Gcc-bugs]

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

Bug ID: 105286
   Summary: Struct initializers do not work with function pointers
   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: ---

Created attachment 52815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52815=edit
Sample C source demonstrating the issue

Please consider the attached C file repro.c.

$ gcc -lgccjit repro.c && ./a.out
libgccjit.so: error: gcc_jit_context_new_struct_constructor: value and field
not the same unqualified type, at index 0 (struct struct.func: void (*)
())(value type: void (*) ())
libgccjit.so: error: gcc_jit_global_set_initializer_rvalue: NULL init_rvalue
gcc_jit_result_release: NULL result

The second error is caused by the first, which is the one I am reporting here.

[PATCH] c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

[Jakub Jelinek via Gcc-patches]

Hi!

The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
run on the whole TARGET_EXPR slot.

So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-04-15  Jakub Jelinek  

PR c++/105256
* typeck2.cc (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union): Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the
containing CONSTRUCTOR.

* g++.dg/cpp0x/pr105256.C: New test.

--- gcc/cp/typeck2.cc.jj2022-04-07 09:09:54.432995137 +0200
+++ gcc/cp/typeck2.cc   2022-04-14 16:02:12.438432494 +0200
@@ -1515,6 +1515,14 @@ process_init_constructor_array (tree typ
  strip_array_types (TREE_TYPE (ce->value);
 
   picflags |= picflag_from_initializer (ce->value);
+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer
+CONSTRUCTOR.  */
+  if (TREE_CODE (ce->value) == CONSTRUCTOR
+ && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value))
+   {
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0;
+   }
 }
 
   /* No more initializers. If the array is unbounded, we are done. Otherwise,
@@ -1560,6 +1568,14 @@ process_init_constructor_array (tree typ
  }
 
picflags |= picflag_from_initializer (next);
+   /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer
+  CONSTRUCTOR.  */
+   if (TREE_CODE (next) == CONSTRUCTOR
+   && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next))
+ {
+   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0;
+ }
if (len > i+1)
  {
tree range = build2 (RANGE_EXPR, size_type_node,
@@ -1754,6 +1770,13 @@ process_init_constructor_record (tree ty
   if (fldtype != TREE_TYPE (field))
next = cp_convert_and_check (TREE_TYPE (field), next, complain);
   picflags |= picflag_from_initializer (next);
+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer CONSTRUCTOR.  */
+  if (TREE_CODE (next) == CONSTRUCTOR
+ && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next))
+   {
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0;
+   }
   CONSTRUCTOR_APPEND_ELT (v, field, next);
 }
 
@@ -1894,6 +1917,14 @@ process_init_constructor_union (tree typ
 ce->value = massage_init_elt (TREE_TYPE (ce->index), ce->value, nested,
  flags, complain);
 
+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer CONSTRUCTOR.  */
+  if (ce->value
+  && TREE_CODE (ce->value) == CONSTRUCTOR
+  && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value))
+{
+  CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+  CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0;
+}
   return picflag_from_initializer (ce->value);
 }
 
--- gcc/testsuite/g++.dg/cpp0x/pr105256.C.jj2022-04-14 16:04:30.518518875 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/pr105256.C   2022-04-14 16:03:53.264035175 
+0200
@@ -0,0 +1,18 @@
+// PR c++/105256
+// { dg-do compile { target c++11 } }
+
+int bar (int &);
+
+struct S {
+  struct T {
+struct U {
+  int i = bar (i);
+} u;
+  };
+};
+
+void
+foo (S::T *p)
+{
+  *p = {};
+};

Jakub

[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU

[lili.cui at intel dot com via Gcc-bugs]

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

--- Comment #9 from cuilili  ---
Really appreciate for your reply, I debugged SRA pass with the small testcase
and found that SRA dose not handle this situation.

SRA cannot split callee's first parameter for "Do not decompose non-BLKmode
parameters in a way that would create a BLKmode parameter. Especially for
pass-by-reference (hence, pointer type parameters), it's not worth it."

Before inline:
For caller 
store-1 :   128 bits store of struct "a" (it is an implicit store during IPA
pass, the store can only be found after a certain pass.)
For callee
load-1 :128 bits load of struct "a" for operation "c->a=(*a)"
store-2:128 bits store of struct "c->a" for operation "c->a=(*a)" 
load-2 :4 * 32 bits load for c->a.f1, c->a.f2, c->a.f3 and c->a.f4.
(because the store-2 using vector register to store, we cannot use the register
directly here.) 

After inline:
For caller
None.
For callee
store-2 :  128 bits store of struct c->a for operation "c->a=(*a)"


int callee (struct A *a, struct C *c)
{
  c->a=(*a);   
  if ((c->b + 7) & 17)
{
  c->a.f1 = c->a.f2 + c->a.f3;
  c->a.f2 = c->a.f2 - c->a.f3;
  c->a.f3 = c->a.f2 + c->a.f3;
  c->a.f4 = c->a.f2 - c->a.f3;
  c->b = c->a.f2 + c->a.f4;
  return 0;
}
  return 1;
}

int caller (int d, struct C *c)
{
  struct A a;
  a.f1 = 1 + d;
  a.f2 = 2;
  a.f3 = 12 + d;
  a.f4 = 68 + d;
  if (d > 0)
return callee (, c);
  else
return 1;
}
-
In 538.imagic_r（c_ray also has the similar code）, if we inline the hot
function, the redundant store and load structure's size is 256 bits (4 elements
of size 64 bits), which can eliminates one 256-bit store, one 256-bit load, and
four 64-bit loads.
can I do it like this? Computes the total size of all callee arguments that can
eliminate redundant loads and stores. Thanks!

[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #9 from Mikael Pettersson  ---
Can this be closed now? I cannot reproduce the abort at -O2 for the original
test case with current gcc-10/11 branch snapshots (but I can with snapshots
from March).

[Bug analyzer/105264] -Wanalyzer-use-of-uninitialized-value gets confused about var + i v.s. [i]

[avarab at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Ævar Arnfjörð Bjarmason  ---
Thanks a lot, I can confirm that this fixes the issue in builtin/merge-file.c
in git.git.

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[avarab at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ævar Arnfjörð Bjarmason  ---
This code also errors under -Werror=analyzer-too-complex, including in some
adjacent code, so perhaps the analyzer gave up?

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[avarab at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ævar Arnfjörð Bjarmason  ---
Created attachment 52814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52814=edit
A patch to git.git that works around the -fanalyzer false positive

A fix to git.git to work around the analyzer false positive, this diff on top
shows an annotated path through the program it thinks we'd take. 24 and 28
can't be true/false false/true, only false/false true/true.

diff --git a/reftable/reader.c b/reftable/reader.c
index ea66771165f..d3a4639d6ca 100644
--- a/reftable/reader.c
+++ b/reftable/reader.c
@@ -61,6 +61,9 @@ static int reader_get_block(struct reftable_block *dest,
uint32_t sz, const uint64_t off,
const uint64_t r_size)
 {
+   if (off >= r_size) /* (28) following ‘true’ branch (when ‘off >=
r_size’)... */
+   return 0;
+
if (off + sz > r_size) {
sz = r_size - off;
}
@@ -288,13 +291,14 @@ int reader_init_block_reader(struct reftable_reader *r,
struct block_reader *br,
uint32_t header_off = next_off ? 0 : header_size(r->version);
int32_t block_size = 0;

-   if (next_off >= r_size)
+   if (next_off >= r_size) /* (24) following ‘false’ branch (when
‘next_off < r_size’)... */
return 1;

err = reader_get_block(, >source, next_off, guess_block_size,
r_size);
-   if (err < 0)
+   if (err < 0) /* (31) following ‘false’ branch (when ‘err >= 0’)... */
goto done;

+   /* We'll supposedly deference NULL block.data[0] here ... */ 
block_size = extract_block_size(block.data, _typ, next_off,
r->version);
if (block_size < 0) {

[Bug analyzer/105285] New: False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[avarab at gmail dot com via Gcc-bugs]

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

Bug ID: 105285
   Summary: False positive with -Wanalyzer-null-dereference in
git.git's reftable/reader.c
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: avarab at gmail dot com
  Target Milestone: ---

Created attachment 52813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52813=edit
gcc -E of reftable/reader.c

I didn't have time to come up with a nice isolated test case this time for
$subject, sorry, but (maybe this is easier):

git clone https://github.com/git/git/
cd git
make CC=gcc CFLAGS=-fanalyzer reftable/reader.o

Or alternatively the gcc -E output that's attached, but most informative is the
patch I'll attach to git.git to work around this (as the code was pretty
nonsensical anyway).

Why do I think it's a false positive? It's code that's basically doing:

  struct x = { 0 }; /* "foo" member is NULL */
  if (x >= 0)
  return 0; /* early abort */
  [...]
  if (x >= 0)
  return 1; /* we don't init "x.foo" */
  x.foo

I.e. the analyzer thinks you can go through these two and for "x >= 0" to be
true the first time, and false the next, or the other way around.

In this case the types didn't have "const" on them, but to make sure these
*really* weren't being changed I added that in all the relevant places, but it
still complained. The warning was:

reftable/reader.c: In function ‘extract_block_size’:
reftable/reader.c:274:20: warning: dereference of NULL ‘data’ [CWE-476]
[-Wanalyzer-null-dereference]
  274 | *typ = data[0];
  |^~~

Also, for the GCC 11.2 I have locally (I tested the warning on near-trunk GCC
12.0) I got two different warnings from -fanalyzer, so this seems to be an area
that's seen active changes recently...

Re: [PING] AArch64: add R30_REGNUM into shrink-wrapping separate

[Dan Li via Gcc-patches]

On 4/12/22 06:05, Richard Sandiford wrote:

Dan Li  writes:

Gentile ping for this :), thanks.

Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590906.html


Sorry, I should have realised this at the time, but I don't think
we can do this after all.  The ABI requires us to set up the frame
chain before assigning to the frame pointer.

Sorry again for the bogus suggestion.

Thanks,
Richard



OK, thanks Richard :)

But I think I still don't quite understand it, so could the x30 be
shrinked alone when we don't need the frame chain?

Thanks,
Dan.

[Bug c++/105284] New: missing syncstream and spanstream forward decl. in

[cooky.ykooc922 at gmail dot com via Gcc-bugs]

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

Bug ID: 105284
   Summary: missing syncstream and spanstream forward decl. in

   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cooky.ykooc922 at gmail dot com
  Target Milestone: ---

according to https://wg21.link/iosfwd.syn's  sypnosis:

The followings are declared (forward declaration only) which are added in C++20
and C++23:

* class template std::basic_spanbuf
* typedef std:spanbuf
* typedef std::wspanbuf
* class template std::basic_ispanstream
* typedef std::ispanstream
* typedef std::wispanstream
* class template std::basic_ospanstream
* typedef std::ospanstream
* typedef std::wospanstream
* class template std::basic_spanstream
* typedef std::spanstream
* typedef std::wspanstream
* class template std::basic_syncbuf
* typedef std::syncbuf
* typedef std::wsyncbuf
* class template std::basic_osyncstream
* typedef std::osyncstream
* typedef std::wosyncstream

However, they are currently not added in the current header  of
libstdc++

Re: [PATCH] i386: Correct target attribute for crc32 intrinsics

[Hongyu Wang via Gcc-patches]

> This test should not be changed, it correctly reports ISA mismatch. It
> even passes -mno-crc32.

The error message changes from "needs isa option -mcrc32" to "target
specific option mismatch" with the #pragma change.
I see many of our intrinsic would throw such error, it has been a long
term issue for intrinsic diagnostic.

So for this test either I change the dg-error message or the call to
builtin, otherwise it would fail.

Uros Bizjak via Gcc-patches  于2022年4月15日周五 15:54写道：
>
> On Fri, Apr 15, 2022 at 6:30 AM Hongyu Wang  wrote:
> >
> > Hi,
> >
> > Complile _mm_crc32_u8/16/32/64 intrinsics with -mcrc32
> > would meet target specific option mismatch. Correct target pragma
> > to fix.
> >
> > Bootstrapped/regtest on x86_64-pc-linux-gnu{-m32,}.
> >
> > Ok for master and backport to GCC 11?
> >
> > gcc/ChangeLog:
> >
> > * config/i386/smmintrin.h: Correct target pragma from sse4.1
> > and sse4.2 to crc32 for crc32 intrinsics.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/i386/crc32-6.c: Adjust to call builtin.
> > * gcc.target/i386/crc32-7.c: New test.
> > ---
> >  gcc/config/i386/smmintrin.h | 25 +-
> >  gcc/testsuite/gcc.target/i386/crc32-6.c |  2 +-
> >  gcc/testsuite/gcc.target/i386/crc32-7.c | 34 +
> >  3 files changed, 42 insertions(+), 19 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/crc32-7.c
> >
> > diff --git a/gcc/config/i386/smmintrin.h b/gcc/config/i386/smmintrin.h
> > index b42b212300f..eb6a451c10a 100644
> > --- a/gcc/config/i386/smmintrin.h
> > +++ b/gcc/config/i386/smmintrin.h
> > @@ -810,17 +810,11 @@ _mm_cmpgt_epi64 (__m128i __X, __m128i __Y)
> >
> >  #include 
> >
> > -#ifndef __SSE4_1__
> > +#ifndef __CRC32__
> >  #pragma GCC push_options
> > -#pragma GCC target("sse4.1")
> > -#define __DISABLE_SSE4_1__
> > -#endif /* __SSE4_1__ */
> > -
> > -#ifndef __SSE4_2__
> > -#pragma GCC push_options
> > -#pragma GCC target("sse4.2")
> > -#define __DISABLE_SSE4_2__
> > -#endif /* __SSE4_1__ */
> > +#pragma GCC target("crc32")
> > +#define __DISABLE_CRC32__
> > +#endif /* __CRC32__ */
> >
> >  /* Accumulate CRC32 (polynomial 0x11EDC6F41) value.  */
> >  extern __inline unsigned int __attribute__((__gnu_inline__, 
> > __always_inline__, __artificial__))
> > @@ -849,14 +843,9 @@ _mm_crc32_u64 (unsigned long long __C, unsigned long 
> > long __V)
> >  }
> >  #endif
> >
> > -#ifdef __DISABLE_SSE4_2__
> > -#undef __DISABLE_SSE4_2__
> > +#ifdef __DISABLE_CRC32__
> > +#undef __DISABLE_CRC32__
> >  #pragma GCC pop_options
> > -#endif /* __DISABLE_SSE4_2__ */
> > -
> > -#ifdef __DISABLE_SSE4_1__
> > -#undef __DISABLE_SSE4_1__
> > -#pragma GCC pop_options
> > -#endif /* __DISABLE_SSE4_1__ */
> > +#endif /* __DISABLE_CRC32__ */
> >
> >  #endif /* _SMMINTRIN_H_INCLUDED */
> > diff --git a/gcc/testsuite/gcc.target/i386/crc32-6.c 
> > b/gcc/testsuite/gcc.target/i386/crc32-6.c
> > index 464e3444069..1f306534bb8 100644
> > --- a/gcc/testsuite/gcc.target/i386/crc32-6.c
> > +++ b/gcc/testsuite/gcc.target/i386/crc32-6.c
> > @@ -7,7 +7,7 @@
> >  unsigned int
> >  test_mm_crc32_u8 (unsigned int CRC, unsigned char V)
> >  {
> > -  return _mm_crc32_u8 (CRC, V);
> > +  return __builtin_ia32_crc32qi (CRC, V);
>
> This test should not be changed, it correctly reports ISA mismatch. It
> even passes -mno-crc32.
>
> Uros.
>
> >  }
> >
> >  /* { dg-error "needs isa option -mcrc32" "" { target *-*-* } 0  } */
> > diff --git a/gcc/testsuite/gcc.target/i386/crc32-7.c 
> > b/gcc/testsuite/gcc.target/i386/crc32-7.c
> > new file mode 100644
> > index 000..2e310e38b82
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/crc32-7.c
> > @@ -0,0 +1,34 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -mcrc32" } */
> > +/* { dg-final { scan-assembler "crc32b\[^\\n\]*eax" } } */
> > +/* { dg-final { scan-assembler "crc32w\[^\\n\]*eax" } } */
> > +/* { dg-final { scan-assembler "crc32l\[^\\n\]*eax" } } */
> > +/* { dg-final { scan-assembler "crc32q\[^\\n\]*rax" { target { ! ia32 } } 
> > } } */
> > +
> > +#include 
> > +
> > +unsigned int
> > +test_mm_crc32_u8 (unsigned int CRC, unsigned char V)
> > +{
> > +  return _mm_crc32_u8 (CRC, V);
> > +}
> > +
> > +unsigned int
> > +test_mm_crc32_u16 (unsigned int CRC, unsigned short V)
> > +{
> > +  return _mm_crc32_u16 (CRC, V);
> > +}
> > +
> > +unsigned int
> > +test_mm_crc32_u32 (unsigned int CRC, unsigned int V)
> > +{
> > +  return _mm_crc32_u32 (CRC, V);
> > +}
> > +
> > +#ifdef __x86_64__
> > +unsigned long long
> > +test_mm_crc32_u64 (unsigned long long CRC, unsigned long long V)
> > +{
> > +  return _mm_crc32_u64 (CRC, V);
> > +}
> > +#endif
> > --
> > 2.18.1
> >

[Bug c/105283] New: Ternary operator and precedence warning

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 105283
   Summary: Ternary operator and precedence warning
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code:

extern int g( int);

void f( int a, int b)
{
if (a & 0x03 == 3)
g( 1);

if (a + (b > 10) ? g( 1) : g( 2))
g( 10);
}

gcc finds the first problem, but not the second:

$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -Wparentheses
-Wint-in-bool-context apr15b.cc
apr15b.cc: In function ‘void f(int, int)’:
apr15b.cc:6:22: warning: suggest parentheses around comparison in operand of
‘&’ [-Wparentheses]
6 | if (a & 0x03 == 3)
  | ~^~~~
$ 

Here is recent clang on the same code:

$ /home/dcb/llvm/results/bin/clang -c -Wall   apr15b.cc
apr15b.cc:6:8: warning: & has lower precedence than ==; == will be evaluated
first [-Wparentheses]
if (a & 0x03 == 3)
  ^~~
apr15b.cc:6:8: note: place parentheses around the '==' expression to silence
this warning
if (a & 0x03 == 3)
  ^
()
apr15b.cc:6:8: note: place parentheses around the & expression to evaluate it
first
if (a & 0x03 == 3)
  ^
(   )
apr15b.cc:9:19: warning: operator '?:' has lower precedence than '+'; '+' will
be evaluated first [-Wparentheses]
if (a + (b > 10) ? g( 1) : g( 2))
 ^
apr15b.cc:9:19: note: place parentheses around the '+' expression to silence
this warning
if (a + (b > 10) ? g( 1) : g( 2))
 ^
(   )
apr15b.cc:9:19: note: place parentheses around the '?:' expression to evaluate
it first
if (a + (b > 10) ? g( 1) : g( 2))
 ^
(   )
2 warnings generated.
$ 

Please note I only had to use -Wall on clang to get the second warning
and the warning message itself is IMHO more descriptive.

[PATCH] rs6000: Move V2DI vec_neg under power8-vector [PR105271]

[Kewen.Lin via Gcc-patches]

Hi,

As PR105271 shows, __builtin_altivec_neg_v2di requires option
-mpower8-vector as its pattern expansion relies on subv2di which
has guard VECTOR_UNIT_P8_VECTOR_P (V2DImode).  This fix is to move
the related lines for __builtin_altivec_neg_v2di to the section
of stanza power8-vector.

Bootstrapped and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P9 and P10.

Is it ok for trunk?

BR,
Kewen
-
PR target/105271

gcc/ChangeLog:

* config/rs6000/rs6000-builtins.def (NEG_V2DI): Move to [power8-vector]
stanza.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr105271.c: New test.
---
 gcc/config/rs6000/rs6000-builtins.def   |  6 +++---
 gcc/testsuite/gcc.target/powerpc/pr105271.c | 14 ++
 2 files changed, 17 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr105271.c

diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index 0f527c5d78f..f4a9f24bcc5 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -1190,9 +1190,6 @@
   const vd __builtin_altivec_neg_v2df (vd);
 NEG_V2DF negv2df2 {}

-  const vsll __builtin_altivec_neg_v2di (vsll);
-NEG_V2DI negv2di2 {}
-
   void __builtin_altivec_stvx_v2df (vd, signed long, void *);
 STVX_V2DF altivec_stvx_v2df {stvec}

@@ -2136,6 +2133,9 @@
   const vus __builtin_altivec_nand_v8hi_uns (vus, vus);
 NAND_V8HI_UNS nandv8hi3 {}

+  const vsll __builtin_altivec_neg_v2di (vsll);
+NEG_V2DI negv2di2 {}
+
   const vsc __builtin_altivec_orc_v16qi (vsc, vsc);
 ORC_V16QI orcv16qi3 {}

diff --git a/gcc/testsuite/gcc.target/powerpc/pr105271.c 
b/gcc/testsuite/gcc.target/powerpc/pr105271.c
new file mode 100644
index 000..1c5f88cadcf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr105271.c
@@ -0,0 +1,14 @@
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-mdejagnu-cpu=power7" } */
+
+/* It's to verify no ICE here, ignore error messages about
+   the required options for vec_neg here.  */
+/* { dg-excess-errors "pr105271" } */
+
+#include 
+
+vector signed long long
+test (vector signed long long x)
+{
+  return vec_neg (x);
+}
--
2.27.0

Re: [PATCH] i386: Correct target attribute for crc32 intrinsics

[Uros Bizjak via Gcc-patches]

On Fri, Apr 15, 2022 at 6:30 AM Hongyu Wang  wrote:
>
> Hi,
>
> Complile _mm_crc32_u8/16/32/64 intrinsics with -mcrc32
> would meet target specific option mismatch. Correct target pragma
> to fix.
>
> Bootstrapped/regtest on x86_64-pc-linux-gnu{-m32,}.
>
> Ok for master and backport to GCC 11?
>
> gcc/ChangeLog:
>
> * config/i386/smmintrin.h: Correct target pragma from sse4.1
> and sse4.2 to crc32 for crc32 intrinsics.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/crc32-6.c: Adjust to call builtin.
> * gcc.target/i386/crc32-7.c: New test.
> ---
>  gcc/config/i386/smmintrin.h | 25 +-
>  gcc/testsuite/gcc.target/i386/crc32-6.c |  2 +-
>  gcc/testsuite/gcc.target/i386/crc32-7.c | 34 +
>  3 files changed, 42 insertions(+), 19 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/crc32-7.c
>
> diff --git a/gcc/config/i386/smmintrin.h b/gcc/config/i386/smmintrin.h
> index b42b212300f..eb6a451c10a 100644
> --- a/gcc/config/i386/smmintrin.h
> +++ b/gcc/config/i386/smmintrin.h
> @@ -810,17 +810,11 @@ _mm_cmpgt_epi64 (__m128i __X, __m128i __Y)
>
>  #include 
>
> -#ifndef __SSE4_1__
> +#ifndef __CRC32__
>  #pragma GCC push_options
> -#pragma GCC target("sse4.1")
> -#define __DISABLE_SSE4_1__
> -#endif /* __SSE4_1__ */
> -
> -#ifndef __SSE4_2__
> -#pragma GCC push_options
> -#pragma GCC target("sse4.2")
> -#define __DISABLE_SSE4_2__
> -#endif /* __SSE4_1__ */
> +#pragma GCC target("crc32")
> +#define __DISABLE_CRC32__
> +#endif /* __CRC32__ */
>
>  /* Accumulate CRC32 (polynomial 0x11EDC6F41) value.  */
>  extern __inline unsigned int __attribute__((__gnu_inline__, 
> __always_inline__, __artificial__))
> @@ -849,14 +843,9 @@ _mm_crc32_u64 (unsigned long long __C, unsigned long 
> long __V)
>  }
>  #endif
>
> -#ifdef __DISABLE_SSE4_2__
> -#undef __DISABLE_SSE4_2__
> +#ifdef __DISABLE_CRC32__
> +#undef __DISABLE_CRC32__
>  #pragma GCC pop_options
> -#endif /* __DISABLE_SSE4_2__ */
> -
> -#ifdef __DISABLE_SSE4_1__
> -#undef __DISABLE_SSE4_1__
> -#pragma GCC pop_options
> -#endif /* __DISABLE_SSE4_1__ */
> +#endif /* __DISABLE_CRC32__ */
>
>  #endif /* _SMMINTRIN_H_INCLUDED */
> diff --git a/gcc/testsuite/gcc.target/i386/crc32-6.c 
> b/gcc/testsuite/gcc.target/i386/crc32-6.c
> index 464e3444069..1f306534bb8 100644
> --- a/gcc/testsuite/gcc.target/i386/crc32-6.c
> +++ b/gcc/testsuite/gcc.target/i386/crc32-6.c
> @@ -7,7 +7,7 @@
>  unsigned int
>  test_mm_crc32_u8 (unsigned int CRC, unsigned char V)
>  {
> -  return _mm_crc32_u8 (CRC, V);
> +  return __builtin_ia32_crc32qi (CRC, V);

This test should not be changed, it correctly reports ISA mismatch. It
even passes -mno-crc32.

Uros.

>  }
>
>  /* { dg-error "needs isa option -mcrc32" "" { target *-*-* } 0  } */
> diff --git a/gcc/testsuite/gcc.target/i386/crc32-7.c 
> b/gcc/testsuite/gcc.target/i386/crc32-7.c
> new file mode 100644
> index 000..2e310e38b82
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/crc32-7.c
> @@ -0,0 +1,34 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mcrc32" } */
> +/* { dg-final { scan-assembler "crc32b\[^\\n\]*eax" } } */
> +/* { dg-final { scan-assembler "crc32w\[^\\n\]*eax" } } */
> +/* { dg-final { scan-assembler "crc32l\[^\\n\]*eax" } } */
> +/* { dg-final { scan-assembler "crc32q\[^\\n\]*rax" { target { ! ia32 } } } 
> } */
> +
> +#include 
> +
> +unsigned int
> +test_mm_crc32_u8 (unsigned int CRC, unsigned char V)
> +{
> +  return _mm_crc32_u8 (CRC, V);
> +}
> +
> +unsigned int
> +test_mm_crc32_u16 (unsigned int CRC, unsigned short V)
> +{
> +  return _mm_crc32_u16 (CRC, V);
> +}
> +
> +unsigned int
> +test_mm_crc32_u32 (unsigned int CRC, unsigned int V)
> +{
> +  return _mm_crc32_u32 (CRC, V);
> +}
> +
> +#ifdef __x86_64__
> +unsigned long long
> +test_mm_crc32_u64 (unsigned long long CRC, unsigned long long V)
> +{
> +  return _mm_crc32_u64 (CRC, V);
> +}
> +#endif
> --
> 2.18.1
>

[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 #2 from Sergei Trofimovich  ---
Proposed the fix as
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg283031.html

[PATCH] gcov-profile: Allow negavive counts of indirect calls [PR105282]

[Sergei Trofimovich via Gcc-patches]

From: Sergei Trofimovich 

TOPN metrics are histograms that contain overall count and per-bucket
count. Overall count can be nevative when two profiles merge and some
of per-bucket metrics are dropped.

Noticed as an ICE on python PGO build where gcc crashes as:

during IPA pass: modref
a.c:36:1: ICE: in stream_out_histogram_value, at value-prof.cc:340
   36 | }
  | ^
stream_out_histogram_value(output_block*, histogram_value_t*)
gcc/value-prof.cc:340

gcc/ChangeLog:

PR gcov-profile/105282
* value-prof.cc (stream_out_histogram_value): Allow negavive counts
on HIST_TYPE_INDIR_CALL.
---
 gcc/value-prof.cc | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/value-prof.cc b/gcc/value-prof.cc
index 9785c7a03ea..4927d119aa0 100644
--- a/gcc/value-prof.cc
+++ b/gcc/value-prof.cc
@@ -319,40 +319,44 @@ stream_out_histogram_value (struct output_block *ob, 
histogram_value hist)
   streamer_write_bitpack ();
   switch (hist->type)
 {
 case HIST_TYPE_INTERVAL:
   streamer_write_hwi (ob, hist->hdata.intvl.int_start);
   streamer_write_uhwi (ob, hist->hdata.intvl.steps);
   break;
 default:
   break;
 }
   for (i = 0; i < hist->n_counters; i++)
 {
   /* When user uses an unsigned type with a big value, constant converted
 to gcov_type (a signed type) can be negative.  */
   gcov_type value = hist->hvalue.counters[i];
   if (hist->type == HIST_TYPE_TOPN_VALUES
  || hist->type == HIST_TYPE_IOR)
/* Note that the IOR counter tracks pointer values and these can have
   sign bit set.  */
;
+  else if (hist->type == HIST_TYPE_INDIR_CALL && i == 0)
+   /* 'all' counter overflow is stored as a negative value. Individual
+  counters and values are expected to be non-negative.  */
+   ;
   else
gcc_assert (value >= 0);
 
   streamer_write_gcov_count (ob, value);
 }
   if (hist->hvalue.next)
 stream_out_histogram_value (ob, hist->hvalue.next);
 }
 
 /* Dump information about HIST to DUMP_FILE.  */
 
 void
 stream_in_histogram_value (class lto_input_block *ib, gimple *stmt)
 {
   enum hist_type type;
   unsigned int ncounters = 0;
   struct bitpack_d bp;
   unsigned int i;
   histogram_value new_val;
   bool next;
-- 
2.35.1

[Bug middle-end/105253] __popcountdi2 calls generated in kernel code with gcc12

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #16 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #11)
> This is a regression (as in we don't want such a call in that case for
> performance reasons and in the past we didn't emit it).

Yes, just note it regresses 531.deepsjeng_r by 2% for -O2 -march=x86-64 since
below function.

typedef unsigned long long BITBOARD;
int PopCount (BITBOARD b) {
int c = 0;

while (b) {
b &= b - 1;
c++;
}

return c;
}

popcnt is supported by x86-64_v2.

Re: [PATCH v1] LoongArch: Fix bug for tmpdir-g++.dg-struct-layout-1/t033.

[Lulu Cheng]

Hi,all: This patch has been merged into the master branch. Thanks! Lulu 
Cheng 在 2022/4/11 下午3:08, Lulu Cheng 写道:



From: chenglulu 

gcc/ChangeLog:

* config/loongarch/loongarch.cc: Fix bug for
tmpdir-g++.dg-struct-layout-1/t033.
---
  gcc/config/loongarch/loongarch.cc | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 6e24111a79d..f22150a60cc 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -473,13 +473,14 @@ loongarch_pass_aggregate_in_fpr_and_gpr_p (const_tree 
type,
  
  static rtx

  loongarch_pass_fpr_single (machine_mode type_mode, unsigned regno,
-  machine_mode value_mode)
+  machine_mode value_mode,
+  HOST_WIDE_INT offset)
  {
rtx x = gen_rtx_REG (value_mode, regno);
  
if (type_mode != value_mode)

  {
-  x = gen_rtx_EXPR_LIST (VOIDmode, x, const0_rtx);
+  x = gen_rtx_EXPR_LIST (VOIDmode, x, GEN_INT (offset));
x = gen_rtx_PARALLEL (type_mode, gen_rtvec (1, x));
  }
return x;
@@ -539,7 +540,8 @@ loongarch_get_arg_info (struct loongarch_arg_info *info,
  {
  case 1:
return loongarch_pass_fpr_single (mode, fregno,
- TYPE_MODE (fields[0].type));
+ TYPE_MODE (fields[0].type),
+ fields[0].offset);
  
  	  case 2:

return loongarch_pass_fpr_pair (mode, fregno,

[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 #1 from Sergei Trofimovich  ---
Relevant bit of counters dump for completeness (after merge):

$ gcov-dump -l a.gcda
...
a.gcda:01a9: 528:COUNTERS indirect_call 66 counts
a.gcda:   0: -50 32 1456173180 1 1792104613 1 918340114 1
a.gcda:   8: 1406444659 1 263798468 1 1664310260 1 1063174467 1
a.gcda:  16: 1596551981 1 54847898 1 533075953 1 1135316294 1
a.gcda:  24: 601636648 1 2142348703 1 450479102 1 1186224457 1
a.gcda:  32: 416313568 1 1153296983 1 617240633 1 2024260238 1
a.gcda:  40: 1680162021 1 944285266 1 1480528956 1 72519307 1
a.gcda:  48: 1631250666 1 1029141085 1 941945699 1 1682532820 1
a.gcda:  56: 71228346 1 1481851149 1 1154596710 1 414983633 1
a.gcda:  64: 2026608575 1

[Bug gcov-profile/105282] New: [11/12 Regression] V_INDIR overflow causes ICE on -O0 -flto

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

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

Bug ID: 105282
   Summary: [11/12 Regression] V_INDIR overflow causes ICE on -O0
-flto
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Initially the bug is reported by John Helmert III in
https://bugs.gentoo.org/838094 where python-3.10.4 failed to build on -flto
-O0. Here is the single-file minimal reproducer:

#include 

typedef void (*cb_t)(void);
#define F(__fn) static void __fn(void) {}

F(f00);F(f01);F(f02);F(f03);F(f04);F(f05);F(f06);F(f07);F(f08);F(f09);
F(f10);F(f11);F(f12);F(f13);F(f14);F(f15);F(f16);F(f17);F(f18);F(f19);
F(f20);F(f21);F(f22);F(f23);F(f24);F(f25);F(f26);F(f27);F(f28);F(f29);
F(f30);F(f31);F(f32);F(f33);F(f34);F(f35);F(f36);F(f37);F(f38);F(f39);
F(f40);F(f41);F(f42);F(f43);F(f44);F(f45);F(f46);F(f47);F(f48);F(f49);

static void f(int i) {
/* Needs to be bigger than gcc's GCOV_TOPN_MAXIMUM_TRACKED_VALUES == 32
 * to overflow GCOV_COUNTER_V_INDIR couter type.
 */
static const cb_t fs[] = {
,,
,,
,,
,,
,,
};
size_t sz = sizeof (fs) / sizeof (fs[0]);
fs[i % sz]();
}

int l(int argc, char * argv[]);

int main(int argc, char *argv[]) {
if (argc == 1)
  for (unsigned int i = 0; i < 25; i++)
f(i);
if (argc == 2)
  for (unsigned int i = 25; i < 50; i++)
f(i);
}

Crashing:

$ gcc -flto -O0 a.c -fprofile-generate -o a
$ ./a # populate first 25 buckets
$ ./a 1 # populate 25 more buckets, cause overflow
$ gcc -flto -O0 a.c -fprofile-use

during IPA pass: modref
a.c:36:1: internal compiler error: in stream_out_histogram_value, at
value-prof.cc:340
   36 | }
  | ^
0x8351fb stream_out_histogram_value(output_block*, histogram_value_t*)
../../gcc-12-20220410/gcc/value-prof.cc:340
0x1c848c0 output_gimple_stmt
../../gcc-12-20220410/gcc/gimple-streamer-out.cc:192
0x1c848c0 output_bb(output_block*, basic_block_def*, function*)
../../gcc-12-20220410/gcc/gimple-streamer-out.cc:227
0xdc91ad output_function
../../gcc-12-20220410/gcc/lto-streamer-out.cc:2453
0xdc91ad lto_output()
../../gcc-12-20220410/gcc/lto-streamer-out.cc:2796
0xe57b11 write_lto
../../gcc-12-20220410/gcc/passes.cc:2762
0xe57b11 ipa_write_summaries_1
../../gcc-12-20220410/gcc/passes.cc:2826
0xe57b11 ipa_write_summaries()
../../gcc-12-20220410/gcc/passes.cc:2882
0xaac060 ipa_passes
../../gcc-12-20220410/gcc/cgraphunit.cc:2209
0xaac060 symbol_table::compile()
../../gcc-12-20220410/gcc/cgraphunit.cc:2282
0xaaea77 symbol_table::compile()
../../gcc-12-20220410/gcc/cgraphunit.cc:2262
0xaaea77 symbol_table::finalize_compilation_unit()
../../gcc-12-20220410/gcc/cgraphunit.cc:2530
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.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-debug-12.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-debug-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220410 (experimental) (GCC)

I think it happens due to overly restrictive gcc_assert() in gcc/value-prof.cc:

 void
 stream_out_histogram_value (struct output_block *ob, histogram_value hist)
 {
  unsigned int i;

  ...

  for (i = 0; i < hist->n_counters; i++)
{
  /* When user uses an unsigned type with a big value, constant converted
 to gcov_type (a signed type) can be negative.  */
  gcov_type value = hist->hvalue.counters[i];
  if (hist->type == HIST_TYPE_TOPN_VALUES
  || hist->type == HIST_TYPE_IOR)
/* Note that the IOR counter tracks pointer values and these can have
   sign bit set.  */
;
  else
gcc_assert (value >= 0);

  streamer_write_gcov_count (ob, value);
}
  ...
 }


Note how it implies that all entries of HIST_TYPE_INDIR_CALL are expected to be
non-nevative values. It's not true for a case when two merged histograms
overflow at libgcc/libgcov-merge.c:

/* ...

   We use -TOTAL for situation when merging dropped some values.
   The information is used for -fprofile-reproducible flag.
   */

void
__gcov_merge_topn (gcov_type *counters, unsigned n_counters)
{

  ...
  full |= gcov_topn_add_value (counters + GCOV_TOPN_MEM_COUNTERS * i,
   value, count, 0, 0);
}

  if (full)
*total = -(*total);
}
}

[Bug target/105172] RV64: gcc generates R_RISCV_ALIGN with a non-power-of-two value

[rui314 at gmail dot com via Gcc-bugs]

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

Rui Ueyama  changed:

   What|Removed |Added

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

--- Comment #2 from Rui Ueyama  ---
I didn't understand the correct semantics of this type of relocation. Please
disregard this issue. Sorry for the noise.

[Bug libstdc++/105281] New: status of constexpr and for c++23

[cooky.ykooc922 at gmail dot com via Gcc-bugs]

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

Bug ID: 105281
   Summary: status of constexpr  and  for c++23
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cooky.ykooc922 at gmail dot com
  Target Milestone: ---

some of  functions such as std::fpclassify are declared constexpr, but i
don't know the status of whether it has been fully implemented for c++23 in
which gcc version?