[Bug libstdc++/110102] New: [13 regression] initializer_list ctors of containers skip Allocator_traits::construct, copies move-only type

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 110102
   Summary: [13 regression] initializer_list ctors of containers
skip Allocator_traits::construct, copies move-only
type
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/4Gq3TWE6M
#include 
struct A {
A(int) {}
A(const A&) = delete;
A(A&&) {}
};
int main() {
std::list v = {1,2,3};
}

This should be ill-formed, but GCC 13.1 accepts it!
GCC 12.3 and earlier correctly reject it.

This is supposed to be constructing a std::initializer_list and calling
`list::list(initializer_list)`, which should then complain because `A(const
A&)` is deleted.

My guess as to what's happening here:
- We're definitely calling list(initializer_list)
- It's calling _M_range_initialize(il.begin(), il.end())
- That's calling __uninitialized_copy_a
- That's probably somehow deciding that because `A` is trivially copyable, we
can just memcpy it. I.e. bug #89164 redux.

Even if it were copyable, we still wouldn't be allowed to bypass
`allocator_traits::construct`. The above snippet uses std::allocator, but I
originally found a more complicated case with pmr::polymorphic_allocator:

// https://godbolt.org/z/ToT6dW5dM
#include 
#include 
#include 
struct Widget {
using allocator_type = std::pmr::polymorphic_allocator;
Widget(int i) : i_(i) {}
explicit Widget(int i, allocator_type) : i_(i) {}
explicit Widget(const Widget& rhs, allocator_type) : i_(rhs.i_ + 100) {}
int i_;
};
static_assert(std::is_trivially_copyable_v);
int main() {
std::pmr::vector v = {1,2,3};
printf("%d %d %d\n", v[0].i_, v[1].i_, v[2].i_);
}

My understanding is that this should print "101 102 103", as GCC 12 does. But
GCC 13.1 prints "1 2 3" instead.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Peter Dimov  ---
Even if we assume that WFE on lock (and SEV on unlock) is the correct approach
on ARM instead of YIELD (though this seems very much domain-specific, depending
on the expected amount of contention and who knows what else), isn't the
existence of pause/yield instructions on MIPS, POWER, and apparently RISC-V (*)
enough further evidence in favor of having a portable intrinsic for emitting
such an instruction?

(*) https://doc.rust-lang.org/src/core/hint.rs.html#178-191 (implementation of
https://doc.rust-lang.org/std/hint/fn.spin_loop.html)

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

[terra at gnome dot org via Gcc-bugs]

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

M Welinder  changed:

   What|Removed |Added

 CC||terra at gnome dot org

--- Comment #10 from M Welinder  ---
mystrlen and strlen are not equivalent, so gcc is wrong in turning the former
into a call of the latter.

Specifically: mystrlen preserves errno, strlen need not do that.  (C99 section
7.5 item 3.)

(Repeating the comment from over in bug 56888.)

[Bug c/96628] Feature request: __attribute__((no_builtin("Foo")))

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||56888

--- Comment #9 from Andrew Pinski  ---
(In reply to Vincent Riviere from comment #8)
> This still happens with m68k-elf-gcc 13.1.0.

Yes because it is basically a dup of bug 56888.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
[Bug 56888] memcpy implementation optimized as a call to memcpy

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

[vincent.riviere at freesbee dot fr via Gcc-bugs]

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

--- Comment #8 from Vincent Riviere  ---
This still happens with m68k-elf-gcc 13.1.0.

[Bug tree-optimization/110035] Missed optimization for dependent assignment statements

[ptk.prasertsuk at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Pontakorn Prasertsuk  ---
For the LLVM IR code of the snippet I provided, Clang's alias analysis can
prove that `new` call has no side effect to other memory location. This is
indicated by `noalias` keyword at the return value of the `new` call (_Znwm).

According to Clang's Language Reference:
"On function return values, the noalias attribute indicates that the function
acts like a system memory allocation function, returning a pointer to allocated
storage disjoint from the storage for any other object accessible to the
caller."

Is this possible for GCC alias analysis pass?

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
Fixed.

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:57b30f0134d9b49f7707b0c2ded6fd7686a312c8

commit r14-1510-g57b30f0134d9b49f7707b0c2ded6fd7686a312c8
Author: liuhongt 
Date:   Thu Jun 1 12:11:24 2023 +0800

Don't try bswap + rotate when TYPE_PRECISION(n->type) > n->range.

For the testcase in the PR, we have

  br64 = br;
  br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull);

  n->n: 0x300200.
  n->range: 32.
  n->type: uint64.

The original code assumes n->range is same as TYPE PRECISION(n->type),
and tries to rotate the mask from 0x30200 -> 0x20300 which is
incorrect. The patch fixed this bug by not trying bswap + rotate when
TYPE_PRECISION(n->type) is not equal to n->range.

gcc/ChangeLog:

PR tree-optimization/110067
* gimple-ssa-store-merging.cc (find_bswap_or_nop): Don't try
bswap + rotate when TYPE_PRECISION(n->type) > n->range.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr110067.c: New test.

[Bug target/92658] x86 lacks vector extend / truncate

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

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:49337040865269e13cdc2ead276d12ecb2e9f606

commit r14-1509-g49337040865269e13cdc2ead276d12ecb2e9f606
Author: liuhongt 
Date:   Thu Jun 1 15:08:02 2023 +0800

i386: Add missing vector truncate patterns [PR92658].

Add missing insn patterns for v2si -> v2hi/v2qi and v2hi-> v2qi vector
truncate.

gcc/ChangeLog:

PR target/92658
* config/i386/mmx.md (truncv2hiv2qi2): New define_insn.
(truncv2si2): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr92658-avx512bw-trunc-2.c: New test.

[Bug c++/110101] New: inconsistent behavior for array-to-pointer decay in constant evaluation in template argument

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

Bug ID: 110101
   Summary: inconsistent behavior for array-to-pointer decay in
constant evaluation in template argument
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase:

template struct X {};
int arr[32];
constexpr void *id(void *p) { return p; }
void f(X) {} // #1
void f(X) {} // #2
void f(X) {} // #3

Here, the three template arguments all represent the same address, but #1 and
#3 point to the first array element whereas #2 points to the array itself.

But GCC instead says that #1 and #2 are redefinitions, and that #1/#2 and #3 do
not conflict -- and mangles #1 and #2 the same, but gives a different mangling
to #3.

It looks like the array-to-pointer conversion is not being properly handled
here.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

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

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

--- Comment #12 from Andrew Pinski  ---
Wfe normally waits a hundreds of cycles before being woken up. It also wake up
when an event happens which is exactly when a write to that address happens.
Exactly when you want.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

[andysem at mail dot ru via Gcc-bugs]

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

andysem at mail dot ru changed:

   What|Removed |Added

 CC||andysem at mail dot ru

--- Comment #11 from andysem at mail dot ru ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Peter Dimov from comment #9)
> > I don't think I want WFE here, based on what I read about it. Putting the
> > core to sleep seems like something to do in an embedded system where I have
> > full control of what cores do, not something to do on the application level,
> > in a portable C++ library.
> 
> No, WFE can be used in userspace just fine and in fact it will be
> interrupted every once in a while. yield only sleeps for a few cycles and
> then wakes up, while wfe will sleep until an event happens (also WFE is very
> hypervisor friendly too).

Spin locks are used when latency is a concern and when the protected region is
extremely small (i.e. a few instructions). Putting the core to sleep until the
next interrupt does not seem appropriate for this purpose. x86 pause and ARM
yield are better suited exactly because they wait for a time in the order of
cycles (up to about a hundred on recent x86) rather than microseconds or more.

I can add that in most spin lock implementations I have seen, either yield, nop
or nothing is used for wasting CPU cycles. A few examples:

https://www.boost.org/doc/libs/1_82_0/boost/fiber/detail/cpu_relax.hpp
https://elixir.bootlin.com/linux/latest/source/arch/arm/include/asm/vdso/processor.h#L11
https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/asm/vdso/processor.h#L12
https://chromium.googlesource.com/chromium/src/third_party/WebKit/Source/wtf/+/823d62cdecdbd5f161634177e130e5ac01eb7b48/SpinLock.cpp

The first link has instructions for a few other architectures besides ARM and
x86. I agree with Peter that an architecture-neutral intrinsic could be useful
to avoid this kind of code duplicated in various projects. Although I realize
that specifying the exact behavior of this intrinsic would be difficult, since
even the underlying instructions are defined rather vaguely. However, one thing
is certain: this intrinsic must be a full compiler fence.

[Bug target/109610] [14 regression] gcc.target/powerpc/dform-3.c fails after r14-172-g0368d169492017

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

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

--- Comment #15 from Peter Bergner  ---
Bill, the original patch went in before GCC 13 was released and I only see a
trunk/GCC 14 fix.  Is dform-3.c still broken when testing GCC 13?  Ie, do we
need a backport of the fix?

[Bug c++/110092] Missing warning that internal header is used

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #1)
> This seems more like a bug in the IDE than in GCC. If you don't include the
> header at all then GCC tells you the right header:
> 
> sp.cc: In function ‘int main()’:
> sp.cc:2:8: error: ‘shared_ptr’ is not a member of ‘std’
> 2 |   std::shared_ptr s;
>   |^~
> sp.cc:1:1: note: ‘std::shared_ptr’ is defined in header ‘’; did you
> forget to ‘#include ’?
>   +++ |+#include 
> 1 | int main() {

Right, the IDE trying to push folks to include the wrong header files is a bug
in the IDE; not just in this case either. There are other libraries which will
have a similar issue besides libstdc++ too. IDEs trying to be smart are not
always the best thing.

[Bug target/110100] __builtin_aarch64_st64b stores to the wrong address

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-02

--- Comment #1 from Andrew Pinski  ---
Confirmed, you can get the similar wrong code with just:
#include 
void do_st64b(int *a, data512_t data) {
__arm_st64b((void*)(a+512), data);
}

[Bug target/110100] New: __builtin_aarch64_st64b stores to the wrong address

[ianthompson at microsoft dot com via Gcc-bugs]

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

Bug ID: 110100
   Summary: __builtin_aarch64_st64b stores to the wrong address
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ianthompson at microsoft dot com
  Target Milestone: ---

Created attachment 55247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55247=edit
Preprocessed reproduction, compile with "aarch64-none-elf-gcc -march=armv8.7-a
-c"

On aarch64, the __arm_st64b function (which is just a thin wrapper around
__builtin_aarch64_st64b) produces incorrect code which uses an uninitialized
register as the address for an ST64B store instruction.

A full preprocessed file is attached, but this snippet is sufficient to
reproduce:

#include 
void do_st64b(data512_t data) {
__arm_st64b((void*)0x1000, data);
}

Compiling with "aarch64-none-elf-gcc -O2 -march=armv8.7-a", I get the following
assembly snippet:

do_st64b:
ldp x8, x9, [x0]
ldp x10, x11, [x0, 16]
ldp x12, x13, [x0, 32]
ldp x14, x15, [x0, 48]
st64b   x8, [x1]
ret

Notice that the st64b instruction uses the uninitialized register x1 as an
address, and the constant 0x1000 is not loaded. I turned optimizations on
to keep the assembly small, but the same issue also occurs without
optimizations.

Digging a bit into aarch64-builtins.cc, it seems like
AARCH64_LS64_BUILTIN_ST64B incorrectly declares the address register an output
instead of an input, leading to the uninitialized register seen above.

The builtins for LD64B, ST64BV, and ST64BV0 appear to be fine, it's just ST64B
which has this issue.

Initially discovered on Arm's build of the toolchain, but I can also reproduce
on trunk and an official 13.1.0 release:
aarch64-none-elf-gcc (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1
20221205

[Bug tree-optimization/110091] [12/13/14 Regression] bogus -Wdangling-pointer on non-pointer values

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|bogus -Wdangling-pointer on |[12/13/14 Regression] bogus
   |non-pointer values  |-Wdangling-pointer on
   ||non-pointer values
   Target Milestone|--- |12.4

--- Comment #2 from Andrew Pinski  ---
The split started happening in GCC 12 too.

[Bug tree-optimization/110091] bogus -Wdangling-pointer on non-pointer values

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-02
   Keywords||compile-time-hog
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Function split decides to split out the call to anotherfunc (and the clobber of
the entry struct) from bar and then the diagnostic gets confused from that.

This is a bad split in the first place.
```
Splitting function at:
Split point at BB 6
  header time: 19.904000 header size: 12
  split time: 7.26 split size: 2
  bbs: 6
  SSA names to pass: 
...

void bar.part.0 ()
{
  struct tEntry entry;

   [local count: 1073741824]:

   [local count: 1073741824]:
  anotherfunc (5);
  entry ={v} {CLOBBER(eol)};

   [local count: 1073741824]:
  return;

}
```

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

--- Comment #14 from Wilco  ---
(In reply to Wilco from comment #13)
> (In reply to Xi Ruoyao from comment #12)
> > (In reply to Wilco from comment #11)
> > 
> > > > Then the compiler (and the standard) is not what they consider.  Such
> > > > misunderstandings are everywhere and this has no difference.
> > > 
> > > Where is int128 in "the standard"?
> > 
> > Consider this:
> > 
> > const _Atomic long double x = 0.1;
> > 
> > int main()
> > {
> > double y = x;
> > return y != 0.1;
> > }
> > 
> > If CAS is used here, the program will just segfault.  Does the standard say
> > this is ill-formed or not?
> 
> I'd say this is ill formed yes. And it will crash on Atom laptops.

Correction - it crashes on all AMD cpus too. Are you going to file bugreports
for this?

[Bug rtl-optimization/110095] RISC-V: unrecognizable insn during RTL pass: vregs with -O2 -mcpu=sifive-u74

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 109760.

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

[Bug target/109760] riscv Internal compiler error in extract_insn after addition of XTheadCondMov

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||matoro_gcc_bugzilla@matoro.
   ||tk

--- Comment #2 from Andrew Pinski  ---
*** Bug 110095 has been marked as a duplicate of this bug. ***

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

--- Comment #13 from Wilco  ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to Wilco from comment #11)
> 
> > > Then the compiler (and the standard) is not what they consider.  Such
> > > misunderstandings are everywhere and this has no difference.
> > 
> > Where is int128 in "the standard"?
> 
> Consider this:
> 
> const _Atomic long double x = 0.1;
> 
> int main()
> {
>   double y = x;
>   return y != 0.1;
> }
> 
> If CAS is used here, the program will just segfault.  Does the standard say
> this is ill-formed or not?

I'd say this is ill formed yes. And it will crash on Atom laptops.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

--- Comment #12 from Xi Ruoyao  ---
(In reply to Wilco from comment #11)

> > Then the compiler (and the standard) is not what they consider.  Such
> > misunderstandings are everywhere and this has no difference.
> 
> Where is int128 in "the standard"?

Consider this:

const _Atomic long double x = 0.1;

int main()
{
double y = x;
return y != 0.1;
}

If CAS is used here, the program will just segfault.  Does the standard say
this is ill-formed or not?

[Bug sanitizer/110099] GCC's Address Sanitizer misses 'stack-use-after-scope' when accessing variable from the same scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-02
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
The order of making the variable as POSION is in the wrong order and not before
the finally.

Also can be repdoceud using the attribute cleanup:
```
void g(void *a)
{
  *(int*)a = 10;
}

int main() {
  int *t __attribute__((cleanup(g)));
  int x = 0;
  t = 
}

```

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

--- Comment #11 from Wilco  ---
(In reply to Xi Ruoyao from comment #10)
> (In reply to Wilco from comment #9)
> > (In reply to Xi Ruoyao from comment #8)
> > > (In reply to Wilco from comment #7)
> > > > I don't see the issue you have here. GCC for x86/x86_64 has been using
> > > > compare exchange for atomic load (which always does a write even if the
> > > > compare fails) for many years.
> > > 
> > > No we don't, since r7-6454.
> > 
> > Incorrect - libatomic still uses cmpxchg16b depending on the CPU.
> 
> You are incorrect.  It checks cmpxchg16b bit in CPUID but does not use the
> cmpxchg16b instruction.

No, it will use the cmpxchg16b instruction in the other ifunc when AVX is not
available. Libatomic will fallback to locking atomics if neither AVX nor
cmpxchg16b are available (first few generations of x86_64).

> The reason to check cmpxchg16b is both Intel and AMD guarantee that if both
> cmpxchg16b and AVX are available, then an aligned 16-byte load with vmovdqa
> is atomic.  So we can use vmovdqa to do a lock-free load then.  But using
> cmpxchg16b for a load is still wrong, and libatomic do NOT use it.
> 
> > > > The question is, do you believe compilers should provide users with 
> > > > fast and
> > > > efficient atomics they need? Or do you want to force every application 
> > > > to
> > > > implement their own version of 128-bit atomics?
> > > 
> > > But a compiler must generate correct code first.  They can use the 
> > > wonderful
> > > inline assembly because they know CAS is safe in their case, but the
> > > compiler does not know.
> > 
> > Many developers consider locking atomics fundamentally incorrect. If we emit
> > lock-free atomics they don't need to write inline assembler.
> 
> Then the compiler (and the standard) is not what they consider.  Such
> misunderstandings are everywhere and this has no difference.

Where is int128 in "the standard"?

[Bug middle-end/110098] [11.4 Regression] binutils bootstrap tests fail when built with 11.4

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Andrew Pinski  ---
This is a binutils testsuite issue.

```
proc default_ld_link { ld target objects } {
global host_triplet
global exec_output

set flags ""
if [is_endian_output_format $objects] then {
set flags [big_or_little_endian]
}

remote_file host delete $target
set exec_output [run_host_cmd "$ld" "$flags -o $target $objects"]
set exec_output [prune_warnings $exec_output]

# We don't care if we get a warning about a non-existent start
# symbol, since the default linker script might use ENTRY.
regsub -all "(^|\n)(\[^\n\]*: warning: cannot find entry
symbol\[^\n\]*\n?)" $exec_output "\\1" exec_output

return [string match "" $exec_output]
}
```

prune_warnings  is not pruning the warning for `warning: using serial
compilation of N LTRANS jobs`.

[Bug sanitizer/110099] New: GCC's Address Sanitizer misses 'stack-use-after-scope' when accessing variable from the same scope

[egor_suvorov at mail dot ru via Gcc-bugs]

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

Bug ID: 110099
   Summary: GCC's Address Sanitizer misses 'stack-use-after-scope'
when accessing variable from the same scope
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egor_suvorov at mail dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Consider the following code:

int main() {
struct S {
int *x;
~S() { *x = 10; }
} s;
//{
int x;
s.x = 
//}
}

I believe `s`'s destructor tries to access variable `x` when it is already
destroyed, so it should be a 'stack-use-after-scope' error.

GCC 12 and 13 do not seem to catch it when compiled with `-fsanitize=address`,
but Clang and Visual Studio 2019 do: https://godbolt.org/z/7MqGr8Y3r

If I uncomment curly brackets, `x` ends up in its own scope and now all three
compilers are able to detect the error. Maybe GCC calls destructors first and
marks variables as unavailable for ASan later?

[Bug middle-end/110098] [11.4 Regression] binutils bootstrap tests fail when built with 11.4

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

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

--- Comment #2 from Andrew Pinski  ---
I think it is failing becasuse of this output:
lto-wrapper: warning: using serial compilation of 26 LTRANS jobs
lto-wrapper: warning: using serial compilation of 26 LTRANS jobs

[Bug lto/110098] [11.4 Regression] binutils bootstrap tests fail when built with 11.4

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

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

--- Comment #1 from Matthias Klose  ---
Created attachment 55246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55246=edit
log file

log file doesn't show any hint

[Bug lto/110098] New: [11.4 Regression] binutils bootstrap tests fail when built with 11.4

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

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

Bug ID: 110098
   Summary: [11.4 Regression] binutils bootstrap tests fail when
built with 11.4
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

binutils bootstrap tests fail when built with 11.4, same configuration runs
successful tests when built with 11.3 or 12.3. seems to be limited to
x86_64-linux-gnu and i686-linux-gnu.

seen with binutils builds (2.38, 2.39, 2.40), binutils configured with 
--enable-obsolete --enable-shared --enable-plugins --enable-threads
--enable-jansson --with-system-zlib --sysconfdir=/etc
--enable-deterministic-archives --disable-compressed-debug-sections
--enable-new-dtags --disable-x86-used-note
--with-gold-ldflags=-static-libstdc++ --disable-werror --enable-pgo-build=lto
--enable-gprofng

The triggering option is --enable-pgo-build=lto, the tests pass when configured
without this option. Failing tests are:

[...]
Running
/home/packages/binutils/binutils-2.40/ld/testsuite/ld-bootstrap/bootstrap.exp
...
FAIL: bootstrap
FAIL: bootstrap with strip
FAIL: bootstrap with -Wl,--traditional-format
FAIL: bootstrap with -Wl,--no-keep-memory
FAIL: bootstrap with -Wl,--relax
FAIL: bootstrap with -Wl,--max-cache-size=-1
[...]

[Bug rtl-optimization/102733] missing fs:0 store when followed by one to gs:0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Fixed on the trunk, this was not a regression and has been an issue since
__gs/__fs support was added.

[Bug rtl-optimization/102733] missing fs:0 store when followed by one to gs:0

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

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

--- Comment #7 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:64ca6aa74b6b5a9737f3808bf4a947dd5c122d47

commit r14-1508-g64ca6aa74b6b5a9737f3808bf4a947dd5c122d47
Author: Andrew Pinski 
Date:   Thu Jun 1 21:17:56 2023 -0700

rtl-optimization: [PR102733] DSE removing address which only differ by
address space.

The problem here is DSE was not taking into account the address space
which meant if you had two addresses say `fs:0` and `gs:0` (on x86_64),
DSE would think they were the same and remove the first store.
This fixes that issue by adding a check for the address space too.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR rtl-optimization/102733

gcc/ChangeLog:

* dse.cc (store_info): Add addrspace field.
(record_store): Record the address space
and check to make sure they are the same.

gcc/testsuite/ChangeLog:

* gcc.target/i386/addr-space-6.c: New test.

[Bug tree-optimization/110087] Missing if conversion

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2) 
> there?  There's zero_one_valued_p we could use for both the
> tested value and the value or-ed into.
> 
> We already have
> 
> /* ((x & 0x1) == 0) ? y : z  y -> (-(typeof(y))(x & 0x1) & z)  y */
> 
> and
> 
> /* ((x & 0x1) == 0) ? z  y : y -> (-(typeof(y))(x & 0x1) & z)  y */

That is exactly what my patch does (I put it in PR 89263), I was going to
submit this patch a couple of days ago but got side tracked with other fixes
not to add the testcases to the patch and submit it.

[Bug rtl-optimization/110042] [14 Regression] missed cmov optimization after r14-1014-gc5df248509b489364c573e8

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Fixed.

[Bug rtl-optimization/110042] [14 Regression] missed cmov optimization after r14-1014-gc5df248509b489364c573e8

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

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

--- Comment #7 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-1507-gdf0853d72d38247aed577a4511450c91794f2f06
Author: Andrew Pinski 
Date:   Tue May 30 15:54:32 2023 -0700

Fix PR 110042: ifcvt regression due to paradoxical subregs

After r14-1014-gc5df248509b489364c573e8, GCC started to emit
directly a zero_extract for `(t1&0x8)!=0`. This introduced
a small regression where ifcvt would not do the ifconversion
as there is now a paradoxical subreg in the dest which
was being rejected. Since paradoxical subreg set the whole
register, we can treat it as the same as a reg in the two places.

OK? Bootstrapped and tested on x86_64-linux-gnu and aarch64-linux-gnu.

gcc/ChangeLog:

PR rtl-optimization/110042
* ifcvt.cc (bbs_ok_for_cmove_arith): Allow paradoxical subregs.
(bb_valid_for_noce_process_p): Strip the subreg for the SET_DEST.

gcc/testsuite/ChangeLog:

PR rtl-optimization/110042
* gcc.target/aarch64/csel_bfx_2.c: New test.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 110097 Summary: Error invalid use of non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110097

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/110097] Error invalid use of non-static member function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 103499.

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

[Bug c++/103499] C++20 modules error: invalid use of non-static member function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bmlushma at uwaterloo dot ca

--- Comment #4 from Andrew Pinski  ---
*** Bug 110097 has been marked as a duplicate of this bug. ***

[Bug c++/110097] Error invalid use of non-static member function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||103524
   Keywords||rejects-valid

--- Comment #2 from Andrew Pinski  ---
C++ modules support in GCC 11 is definitely something which is known to be
broken. It has been improved in GCC 12 and 13 but still has many known issues.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug tree-optimization/89263] Simplify bool expression to OR

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

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 55245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55245=edit
Patch where I need to add some more testcases

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Peter Dimov from comment #9)
> I don't think I want WFE here, based on what I read about it. Putting the
> core to sleep seems like something to do in an embedded system where I have
> full control of what cores do, not something to do on the application level,
> in a portable C++ library.

No, WFE can be used in userspace just fine and in fact it will be interrupted
every once in a while. yield only sleeps for a few cycles and then wakes up,
while wfe will sleep until an event happens (also WFE is very hypervisor
friendly too).

[Bug target/110044] [10/11/12/13/14 Regression] #pragma pack(push, 1) may not force packing, while __attribute__((packed, aligned(1))) works

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:84d080a29a780973bef47171ba708ae2f7b4ee47

commit r14-1506-g84d080a29a780973bef47171ba708ae2f7b4ee47
Author: Iain Sandoe 
Date:   Thu Jun 1 13:43:35 2023 +0100

Darwin, PPC: Fix struct layout with pragma pack [PR110044].

This bug was essentially that darwin_rs6000_special_round_type_align()
was ignoring externally-imposed capping of field alignment.

Signed-off-by: Iain Sandoe 

PR target/110044

gcc/ChangeLog:

* config/rs6000/rs6000.cc (darwin_rs6000_special_round_type_align):
Make sure that we do not have a cap on field alignment before
altering
the struct layout based on the type alignment of the first entry.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/darwin-abi-13-0.c: New test.
* gcc.target/powerpc/darwin-abi-13-1.c: New test.
* gcc.target/powerpc/darwin-abi-13-2.c: New test.
* gcc.target/powerpc/darwin-structs-0.h: New test.

[Bug c++/110097] Error invalid use of non-static member function

[bmlushma at uwaterloo dot ca via Gcc-bugs]

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

--- Comment #1 from bmlushma at uwaterloo dot ca  
---
Full -v output:

Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --disable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-2V7zgg/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-2V7zgg/gcc-11-11.1.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~20.04)

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Peter Dimov  ---
I don't think I want WFE here, based on what I read about it. Putting the core
to sleep seems like something to do in an embedded system where I have full
control of what cores do, not something to do on the application level, in a
portable C++ library.

[Bug fortran/100607] ICE with SELECT RANK

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #12 from Steve Kargl  ---
On Fri, Jun 02, 2023 at 06:06:59PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #11 from anlauf at gcc dot gnu.org ---
> Fixed.
> 

Thanks for taking care of the commit.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Fri, Jun 02, 2023 at 05:51:17PM +, jde...@santafe-conicet.gov.ar wrote:
> 
> --- Comment #5 from Jorge D'Elia  ---
> 
> The access restriction is a reason of the use IMPORT statements in the
> projects, since it is a very convenient and nifty way to detect any name
> collision between local entities and host-associated entities, and well as, in
> BLOCK statements, for the same purpose.

Jorge, I agree with you 100% on the usefulness of IMPORT.

The 2nd patch I attached to this PR is almost complete.
That is, 'import', 'import, none', and 'import, all'
work as defined in F2018.

Unfortunately, 'import, only :: a, b, etc' does not work
and I haven't had time to work out the details.  My first
thought is to create a list of allowed use-associated symbols.
The list would be added to the current namespace after
verifying the symbols are in a parent namespace, but that's
as far as I've gotten.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Peter Dimov from comment #7)
> These intrinsics are typically used in spinlocks as in
> ```
> while( flag_.test_and_set() )
> {
> // issue a power-saving NOP here
> }
> ```
> (where `flag_` is `std::atomic_flag`) and this use is generic and not
> target-dependent.

But yield is not the right thing for spinlocks for ARMv8. You want to use wfe
instead. yield is only for multi-threaded cores and can be used anytime.

[Bug fortran/100607] ICE with SELECT RANK

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Peter Dimov  ---
These intrinsics are typically used in spinlocks as in
```
while( flag_.test_and_set() )
{
// issue a power-saving NOP here
}
```
(where `flag_` is `std::atomic_flag`) and this use is generic and not
target-dependent.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Peter Dimov from comment #5)
> This works for the specific case of ARM, even though I don't find it
> substantially better than just using `asm("yield")`, but the benefit of
> having a portable intrinsic for this functionality is that as such
> instructions are added to targets and GCC gains support of them (as has
> happened with ARM), code would automatically take advantage of them, without
> having to acquire new ifdefs for each supported target.

There is no benifit in having an intrinsic that is generic here really. ACLE
defines the ones for ARM. Intel has a definition of their own intrinsics too
(which gcc does follow too for __pause/_mm_pause but I notice you used the
builtin directly for GCC for some reason).

[Bug fortran/100607] ICE with SELECT RANK

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

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

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

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

commit r14-1505-gfae09dfc0e6bf4cfe35d817558827aea78c6426f
Author: Steve Kargl 
Date:   Fri Jun 2 19:44:11 2023 +0200

Fortran: fix diagnostics for SELECT RANK [PR100607]

gcc/fortran/ChangeLog:

PR fortran/100607
* resolve.cc (resolve_select_rank): Remove duplicate error.
(resolve_fl_var_and_proc): Prevent NULL pointer dereference and
suppress error message for temporary.

gcc/testsuite/ChangeLog:

PR fortran/100607
* gfortran.dg/select_rank_6.f90: New test.

[Bug fortran/110033] rejects-valid: associate name corresponding to coarray selector should be considered a coarray

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/110033] rejects-valid: associate name corresponding to coarray selector should be considered a coarray

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-02

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

There is a check for F2023:C1103

C1103 (R1105) variable shall not be a coindexed object.

but that applies to something like 'associate(y => x[1])'.

gfortran needs to check that if 'x' in 'associate(y => x)'
is a coarray, that its codimension and corank are propagated to
'y'.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Peter Dimov  ---
This works for the specific case of ARM, even though I don't find it
substantially better than just using `asm("yield")`, but the benefit of having
a portable intrinsic for this functionality is that as such instructions are
added to targets and GCC gains support of them (as has happened with ARM), code
would automatically take advantage of them, without having to acquire new
ifdefs for each supported target.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

[jdelia--- via Gcc-bugs]

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

Jorge D'Elia  changed:

   What|Removed |Added

 CC||jde...@santafe-conicet.gov.
   ||ar

--- Comment #5 from Jorge D'Elia  ---
Hi,

The access restriction is a reason of the use IMPORT statements in the
projects, since it is a very convenient and nifty way to detect any name
collision between local entities and host-associated entities, and well as, in
BLOCK statements, for the same purpose. However, with the test:

$ cat import1.f90
module m_modulo
implicit none (type, external)
contains
  subroutine ss (ii)
import, all
implicit none (type, external)
integer, intent (in) :: ii
associate (i_loc => ii)
end associate
  end subroutine ss
end module m_modulo

compiled with, (i)

$ gfortran --version
GNU Fortran (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gfortran -march=native -mtune=native -m64 -fall-intrinsics -fcheck=all
-fimplicit-none -fmax-errors=4 -fno-finite-math-only -fPIC -pthread -std=f2018
-Wall -Waliasing -Warray-temporaries -Wcharacter-truncation -Werror -Wextra
-Wimplicit-interface -Wimplicit-procedure -Wintrinsic-shadow -Wline-truncation
-Wrealloc-lhs-all -Wsurprising -Wtabs -Wunused-parameter -flto -O2 -o
import1.exe import1.f90

import1.f90:5:11:

5 | import, all
   | 1
Error: IMPORT statement at (1) only permitted in an INTERFACE body
f951: all warnings being treated as errors

and next compiled with (ii):

$ nagfor ../import1.f90 -O3
rm: cannot remove '*.original': No such file or directory
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7115
Error: ../import1.f90, line 2: Syntax error
detected at NONE@(
Error: ../import1.f90, line 5: The IMPORT statement is only allowed in an
INTERFACE body
detected at IMPORT@,
Error: ../import1.f90, line 5: Syntax error
detected at IMPORT@,
Error: ../import1.f90, line 6: Syntax error
detected at NONE@(
[NAG Fortran Compiler pass 1 error termination, 4 errors]


Thus, the errors generated by gfortran and nagfor are consistent with the F2003
constraint: C1210 (R1209) "The IMPORT statement is allowed only in an
interface-body".

However, the use of IMPORT in the previus test is new in F2018, which neither
gfortran nor NAG Fortran support, that is: "The IMPORT statement can appear in
a contained subprogram or BLOCK construct, and can restrict access via host
association; diagnosis of violation of the IMPORT restrictions is required". 

Thus, this example should be valid F2018 but not F2008 or earlier.

For instance, one can have a unit testing framework that relies extensively on
BLOCK constructs, and having the guarantee that any potential conflict (between
a local block entity and an entity of the host procedure) will be flagged by
the compiler (when using an IMPORT statement in each block construct) sould be
a godsend.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Peter Dimov from comment #3)
> How does the user know when to include `arm_acle.h`?

__ARM_ARCH will be defined for both arm*-*-* and aarch64-*-* targets as defined
by the ACLE documentation.
You could also use __has_include too if needed.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

--- Comment #10 from Xi Ruoyao  ---
(In reply to Wilco from comment #9)
> (In reply to Xi Ruoyao from comment #8)
> > (In reply to Wilco from comment #7)
> > > I don't see the issue you have here. GCC for x86/x86_64 has been using
> > > compare exchange for atomic load (which always does a write even if the
> > > compare fails) for many years.
> > 
> > No we don't, since r7-6454.
> 
> Incorrect - libatomic still uses cmpxchg16b depending on the CPU.

You are incorrect.  It checks cmpxchg16b bit in CPUID but does not use the
cmpxchg16b instruction.

The reason to check cmpxchg16b is both Intel and AMD guarantee that if both
cmpxchg16b and AVX are available, then an aligned 16-byte load with vmovdqa is
atomic.  So we can use vmovdqa to do a lock-free load then.  But using
cmpxchg16b for a load is still wrong, and libatomic do NOT use it.

> > > The question is, do you believe compilers should provide users with fast 
> > > and
> > > efficient atomics they need? Or do you want to force every application to
> > > implement their own version of 128-bit atomics?
> > 
> > But a compiler must generate correct code first.  They can use the wonderful
> > inline assembly because they know CAS is safe in their case, but the
> > compiler does not know.
> 
> Many developers consider locking atomics fundamentally incorrect. If we emit
> lock-free atomics they don't need to write inline assembler.

Then the compiler (and the standard) is not what they consider.  Such
misunderstandings are everywhere and this has no difference.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Peter Dimov  ---
How does the user know when to include `arm_acle.h`?

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

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

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

--- Comment #2 from Andrew Pinski  ---
Oh and the acle defines how to detect compiling on arm targets and gcc follows
that.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://developer.arm.com/documentation/101028/latest/

Defines __yield already if you include arm_acle.h .

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

--- Comment #56 from Jakub Jelinek  ---
Created attachment 55244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55244=edit
gcc14-bitint-wip-inc.patch

Incremental patch on top of the above patch.

I've tried to make some progress and implement the simplest large _BitInt
cases,
&/|/^/~, but ran into a problem there, both BIT_FIELD_REF and BIT_INSERT_EXPR
disallow
operating on non-mode precisions, while for _BitInt I think it would be really
useful
to use them on the large/huge _BitInts (which I will force into memory during
expansion most likely).  Sure, for huge _BitInts, what is handled in the loop
will use either
ARRAY_REF on VIEW_CONVERT_EXPR for operands or TARGET_MEM_REFs on VAR_DECLs for
the results in the loop, but even for those there is the partial most
significant limb in some cases that needs to be handled separately.

So, do you think it is ok to make an exception for
BIT_FIELD_REF/BIT_INSERT_EXPR and
allow them on non-mode precision BITINT_TYPEs (the incremental patch enables
that) plus
handle it during the expansion?

Another thing, started to think about PLUS_EXPR/MINUS_EXPR, we have
__builtin_ia32_addcarryx_u64/__builtin_ia32_sbb_u64 builtins on x86-64, but
from what
I can see don't really pattern recognize even simple add + adc.

Given:
void
foo (unsigned long *p, unsigned long *q, unsigned long *r)
{
  unsigned long p0 = p[0], q0 = q[0];
  unsigned long p1 = p[1], q1 = q[1];
  unsigned long r0 = p0 + q0;
  unsigned long r1 = p1 + q1 + (r0 < p0);
  r[0] = r0;
  r[1] = r1;
}

void
bar (unsigned long *p, unsigned long *q, unsigned long *r)
{
  unsigned long p0 = p[0], q0 = q[0];
  unsigned long p1 = p[1], q1 = q[1];
  unsigned long p2 = p[2], q2 = q[2];
  unsigned long r0 = p0 + q0;
  unsigned long r1 = p1 + q1 + (r0 < p0);
  unsigned long r2 = p2 + q2 + (r1 < p1 || r1 < q1);
  r[0] = r0;
  r[1] = r1;
  r[2] = r2;
}

llvm seems to pattern recognize foo, but doesn't pattern recognize bar as add;
adc; adc
(is that actually a correct C for that though?).

So, shouldn't we implement the clang's
https://clang.llvm.org/docs/LanguageExtensions.html#multiprecision-arithmetic-builtins
builtins (add least the __builtin_{add,sub}c{,l,ll} builtins), lower them into
ifns early (similarly to .{ADD,SUB}_OVERFLOW returning complex integer with 2
returns) and add optabs so that targets can implement those efficiently?

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

--- Comment #9 from Wilco  ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to Wilco from comment #7)
> > I don't see the issue you have here. GCC for x86/x86_64 has been using
> > compare exchange for atomic load (which always does a write even if the
> > compare fails) for many years.
> 
> No we don't, since r7-6454.

Incorrect - libatomic still uses cmpxchg16b depending on the CPU.

> > The question is, do you believe compilers should provide users with fast and
> > efficient atomics they need? Or do you want to force every application to
> > implement their own version of 128-bit atomics?
> 
> But a compiler must generate correct code first.  They can use the wonderful
> inline assembly because they know CAS is safe in their case, but the
> compiler does not know.

Many developers consider locking atomics fundamentally incorrect. If we emit
lock-free atomics they don't need to write inline assembler.

[Bug c++/110097] New: Error invalid use of non-static member function

[bmlushma at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 110097
   Summary: Error invalid use of non-static member function
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmlushma at uwaterloo dot ca
  Target Milestone: ---

Created attachment 55243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55243=edit
Preprocessed *.i* files

g++-11 -std=c++20 -fmodules-ts test.cc -x c++-system-header iostream

text.cc:

import ;
int main() {
std::istream * infile;
delete infile;
}


This is going to be UB at run-time, but should not produce a compiler error,
let alone the one we got.

Compiler output:

test.cc: In function ‘int main()’:
test.cc:4:12: error: invalid use of non-static member function
‘std::basic_istream<_CharT, _Traits>::~basic_istream() [with _CharT = char;
_Traits = std::char_traits]’
4 | delete infile;
  |^~
In file included from /usr/include/c++/11/iostream:40,
of module /usr/include/c++/11/iostream, imported at test.cc:1:
/usr/include/c++/11/istream:103:7: note: declared here
  103 |   ~basic_istream()
  |   ^

[Bug target/110096] New: Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

[pdimov at gmail dot com via Gcc-bugs]

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

Bug ID: 110096
   Summary: Would be nice if __builtin_ia32_pause had a portable
equivalent as it's applicable to ARM
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

This is more of a feature request than a bug.

Currently `__builtin_ia32_pause()` only applies to Intel/AMD CPUs (hence the
`ia32` in the name), but it has a straightforward and equivalent meaning for
ARM (issue a YIELD instruction, which is the exact ARM equivalent to the PAUSE
x86 one.)

This forces us to do things like

```
#if __has_builtin(__builtin_ia32_pause)

__builtin_ia32_pause();

#elif defined(__GNUC__) && ( (defined(__ARM_ARCH) && __ARM_ARCH >= 8) ||
defined(__ARM_ARCH_8A__) || defined(__aarch64__) )

__asm__ __volatile__( "yield" : : : "memory" );

// ...
```

(E.g.
https://github.com/boostorg/core/blob/3b96d237c0e3ada30c9beca0f60062a2576dcafd/include/boost/core/detail/sp_thread_pause.hpp)

This can be solved in one of two ways; one, extend `__builtin_ia32_pause` to do
the right thing for ARM - unprincipled because of ia32 in the name, but will
automagically "fix" all code using `#if __has_builtin(__builtin_ia32_pause)`.

Or two, add a portable spelling for the intrinsic, either `__builtin_pause()`
or `__builtin_yield()`.

(Failing that, an ARM-specific `__builtin_arm_yield()` would still be an
improvement over the above because it at least will allow us to not hardcode
the ARM target detection, which we are probably getting wrong.)

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #9 from David Faust  ---
(In reply to Alex Coplan from comment #8)
> Thanks for the follow-up fix and apologies for the mid-air collision, I
> didn't see the %zu problem on the target I was testing.

No problem, thanks for the fixes :) I'm slow on the patch formatting etc.
Hopefully these are all taken care of now between the two patches.

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #8 from Alex Coplan  ---
Thanks for the follow-up fix and apologies for the mid-air collision, I didn't
see the %zu problem on the target I was testing.

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Faust :

https://gcc.gnu.org/g:934da923a7295ae97e37425e269195c7d8770ef0

commit r14-1504-g934da923a7295ae97e37425e269195c7d8770ef0
Author: David Faust 
Date:   Fri Jun 2 09:28:32 2023 -0700

btf: fix bootstrap -Wformat errors [PR110073]

Commit 7aae58b04b9 "btf: improve -dA comments for testsuite" broke
bootstrap on a number of architectures because it introduced some
new -Wformat errors.

Fix those errors by properly using PRIu64 and a small refactor to
the offending code.

Based on the suggested patch from Rainer Orth.

PR debug/110073

gcc/ChangeLog:

* btfout.cc (btf_absolute_func_id): New function.
(btf_asm_func_type): Call it here.  Change index parameter from
size_t to ctf_id_t.  Use PRIu64 formatter.

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #6 from David Faust  ---
(In reply to Iain Sandoe from comment #5)
> (In reply to David Faust from comment #4)
> > (In reply to Iain Sandoe from comment #3)
> > > (In reply to Iain Sandoe from comment #2)
> > > > there seems to be a second fail on x86_64 darwin on line 970.
> > > 
> > > I tried the alternate patch on a number of x86_64, i686 and power Darwin
> > > systems and bootstrap is restored.
> > 
> > Thanks for confirming. I'll go ahead and send it to the list.
> 
> I think with bootstrap fixes, you are allowed a bit more independence - i.e.
> can go ahead and apply - but now needs resolution with Alex's patch,

OK, thanks. And yes I just ran into the conflict. Rebasing now.

[Bug fortran/100607] ICE with SELECT RANK

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #8)
> 
> I've concluded that the bug was reported 2 years agos.
> It was fixed by a tentative patch 2 years laters.
> 
> 'case_value == -1' is for 'rank(*)'.
> 
> 'case_value == -2' appears to be for non-'rank(*)' cases,
> and those are handled in the preceding nested for-loop.

Then I can take care of the patch for you.

[Bug rtl-optimization/110095] New: RISC-V: unrecognizable insn during RTL pass: vregs with -O2 -mcpu=sifive-u74

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

Bug ID: 110095
   Summary: RISC-V: unrecognizable insn during RTL pass: vregs
with -O2 -mcpu=sifive-u74
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matoro_gcc_bugzilla at matoro dot tk
  Target Milestone: ---

Not sure if this is a regression or not.  Minimized test case produced with
cvise.

$ cat test3.i
double CastDoubleToLong_x;
long __attribute__DrawAffineImage_x;
long CastDoubleToLong() {
  if (CastDoubleToLong_x)
return 0;
  return CastDoubleToLong_x;
}
void __attribute__DrawAffineImage() {
  for (; __attribute__DrawAffineImage_x <= CastDoubleToLong();)
;
}

$ riscv64-unknown-linux-gnu-gcc -O2 -mcpu=sifive-u74 -c test3.i
test3.i: In function ‘__attribute__DrawAffineImage’:
test3.i:11:1: error: unrecognizable insn:
   11 | }
  | ^
(insn 9 8 10 2 (set (reg:DI 140)
(if_then_else:DI (eq:DF (reg:DF 136 [ CastDoubleToLong_x.0_4 ])
(reg:DF 142))
(reg:DI 141)
(const_int 0 [0]))) -1
 (nil))
during RTL pass: vregs
test3.i:11:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

Passing -fdisable-rtl-vregs does not fix the problem as the same issue appears
in sched1 pass; there is a little bit more context in the output.

$ riscv64-unknown-linux-gnu-gcc -O2 -mcpu=sifive-u74 -c test3.i
-fdisable-rtl-vregs   
cc1: note: disable pass rtl-vregs for functions in the range of [0, 4294967295]
test3.i: In function ‘__attribute__DrawAffineImage’:
test3.i:11:1: error: unrecognizable insn:
   11 | }
  | ^
(insn 9 8 12 2 (set (reg:DI 140)
(if_then_else:DI (eq:DF (reg:DF 136 [ CastDoubleToLong_x.0_4 ])
(reg:DF 142))
(reg:DI 141)
(const_int 0 [0]))) -1
 (expr_list:REG_DEAD (reg:DF 142)
(expr_list:REG_DEAD (reg:DI 141)
(expr_list:REG_DEAD (reg:DF 136 [ CastDoubleToLong_x.0_4 ])
(expr_list:REG_EQUAL (if_then_else:DI (eq:DF (reg:DF 136 [
CastDoubleToLong_x.0_4 ])
(const_double:DF 0.0 [0x0.0p+0]))
(reg:DI 141)
(const_int 0 [0]))
(nil))
during RTL pass: sched1
test3.i:11:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

Reducing optimization to -O1 removes the issue:
$ riscv64-unknown-linux-gnu-gcc -O1 -mcpu=sifive-u74 -c test3.i

Removing CPU tuning also removes the issue:
$ riscv64-unknown-linux-gnu-gcc -O2 -c test3.i

Clang has no problems (though I'm not sure if it actually supports optimization
for this CPU or if it's a no-op):
$ clang -O2 -mcpu=sifive-u74 -c test3.i


$ gcc --version --verbose
Using built-in specs.
COLLECT_AS_OPTIONS='--version'
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-unknown-linux-gnu/13/lto-wrapper
gcc (Gentoo 13.1.1_p20230527 p3) 13.1.1 20230527
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Target: riscv64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.1.1_p20230527/work/gcc-13-20230527/configure
--host=riscv64-unknown-linux-gnu --build=riscv64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/riscv64-unknown-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include
--datadir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13
--mandir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/man
--infodir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include/g++-v13
--with-python-dir=/share/gcc-data/riscv64-unknown-linux-gnu/13/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
13.1.1_p20230527 p3' --with-gcc-major-version-only --disable-esp
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --with-abi=lp64d --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --with-isl --disable-isl-version-check 

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

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

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

--- Comment #5 from Iain Sandoe  ---
(In reply to David Faust from comment #4)
> (In reply to Iain Sandoe from comment #3)
> > (In reply to Iain Sandoe from comment #2)
> > > there seems to be a second fail on x86_64 darwin on line 970.
> > 
> > I tried the alternate patch on a number of x86_64, i686 and power Darwin
> > systems and bootstrap is restored.
> 
> Thanks for confirming. I'll go ahead and send it to the list.

I think with bootstrap fixes, you are allowed a bit more independence - i.e.
can go ahead and apply - but now needs resolution with Alex's patch,

[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #12 from Peter Bergner  ---
Mike said offline we can mark this as FIXED.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #8 from Xi Ruoyao  ---
(In reply to Wilco from comment #7)
> I don't see the issue you have here. GCC for x86/x86_64 has been using
> compare exchange for atomic load (which always does a write even if the
> compare fails) for many years.

No we don't, since r7-6454.

> The question is, do you believe compilers should provide users with fast and
> efficient atomics they need? Or do you want to force every application to
> implement their own version of 128-bit atomics?

But a compiler must generate correct code first.  They can use the wonderful
inline assembly because they know CAS is safe in their case, but the compiler
does not know.

[Bug c++/109247] [13/14 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

--- Comment #17 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:9872d56661ade358c440914361c1ebdccd975bec

commit r14-1502-g9872d56661ade358c440914361c1ebdccd975bec
Author: Jason Merrill 
Date:   Fri May 26 12:28:15 2023 -0400

c++: fix explicit/copy problem [PR109247]

In the testcase, the user wants the assignment to use the operator=
declared
in the class, but because [over.match.list] says that explicit constructors
are also considered for list-initialization, as affirmed in CWG1228, we end
up choosing the implicitly-declared copy assignment operator, using the
explicit constructor template for the argument, which is ill-formed.  Other
implementations haven't implemented CWG1228, so we keep getting bug
reports.

Discussion in CWG led to the idea for this targeted relaxation: if we use
an
explicit constructor for the conversion to the argument of a copy or move
special member function, that makes the candidate worse than another.

DR 2735
PR c++/109247

gcc/cp/ChangeLog:

* call.cc (sfk_copy_or_move): New.
(joust): Add tiebreaker for explicit conv and copy ctor.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-explicit3.C: New test.

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #4 from David Faust  ---
(In reply to Iain Sandoe from comment #3)
> (In reply to Iain Sandoe from comment #2)
> > there seems to be a second fail on x86_64 darwin on line 970.
> 
> I tried the alternate patch on a number of x86_64, i686 and power Darwin
> systems and bootstrap is restored.

Thanks for confirming. I'll go ahead and send it to the list.

[Bug rtl-optimization/101188] [postreload] Uses content of a clobbered register

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

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

--- Comment #14 from Ulrich Weigand  ---
(In reply to Georg-Johann Lay from comment #13)
> Also I don't have a test case for your scenario.  I can reproduce the bug
> back to v5 on avr and maybe it is even older.  As it appears, this PR lead
> to no hickups on any other target, so for now I'd like to keep the fix
> restricted to what I can test.

I agree that your patch looks correct and unlikely to cause any new problems,
so I won't object to it being committed.  I just wanted to point out that it
might not be a complete fix.

[Bug c++/110070] Code quality regression with for (int i: {1,2,4,6})

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Last reconfirmed||2023-06-02
 Ever confirmed|0   |1

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 14 so far.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||Boyce at engineer dot com

--- Comment #4 from kargl at gcc dot gnu.org ---
*** Bug 108650 has been marked as a duplicate of this bug. ***

[Bug fortran/108650] Error: IMPORT statement only permitted in an INTERFACE body | but it should be allowed in any contained routine to control scope

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from kargl at gcc dot gnu.org ---
Dup.

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

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #53187|0   |1
is obsolete||

--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 55242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55242=edit
New diff

New diff with changes to gfortran.h

[Bug middle-end/110094] Support __builtin_mem*_inline

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

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

--- Comment #2 from Andrew Pinski  ---
Also there is no definition of what a compile time constant is.

The option supports non constant cases too.

[Bug target/106769] PPCLE: vec_extract(vector unsigned int) unnecessary rldicl after mfvsrwz

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||aagarwa at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
I wonder if Ajit's REE changes catch this unneeded zero extension?

[Bug middle-end/110094] Support __builtin_mem*_inline

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

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

--- Comment #1 from Andrew Pinski  ---
I think these builtins are a bad idea.

[Bug c++/110070] Code quality regression with for (int i: {1,2,4,6})

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

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

--- Comment #2 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-1500-g4d935f52b0d5c00fcc154461b87415ebd8791a94
Author: Jason Merrill 
Date:   Wed Dec 7 11:40:53 2022 -0500

c++: make initializer_list array static again [PR110070]

After the maybe_init_list_as_* patches, I noticed that we were putting the
array of strings into .rodata, but then memcpying it into an automatic
array, which is pointless; we should be able to use it directly.

This doesn't happen automatically because TREE_ADDRESSABLE is set (since
r12-657 for PR100464), and so gimplify_init_constructor won't promote the
variable to static.  Theoretically we could do escape analysis to recognize
that the address, though taken, never leaves the function; that would allow
promotion when we're only using the address for indexing within the
function, as in initlist-opt2.C.  But this would be a new pass.

And in initlist-opt1.C, we're passing the array address to another
function,
so it definitely escapes; it's only safe in this case because it's calling
a
standard library function that we know only uses it for indexing.  So, a
flag seems needed.  I first thought to put the flag on the TARGET_EXPR, but
the VAR_DECL seems more appropriate.

In a previous revision of the patch I called this flag DECL_NOT_OBSERVABLE,
but I think DECL_MERGEABLE is a better name, especially if we're going to
apply it to the backing array of initializer_list, which is observable.  I
then also check it in places that check for -fmerge-all-constants, so that
multiple equivalent initializer-lists can also be combined.  And then it
seemed to make sense for [[no_unique_address]] to have this meaning for
user-written variables.

I think the note in [dcl.init.list]/6 intended to allow this kind of
merging
for initializer_lists, but it didn't actually work; for an explicit array
with the same initializer, if the address escapes the program could tell
whether the same variable in two frames have the same address.  P2752 is
trying to correct this defect, so I'm going to assume that this is the
intent.

PR c++/110070
PR c++/105838

gcc/ChangeLog:

* tree.h (DECL_MERGEABLE): New.
* tree-core.h (struct tree_decl_common): Mention it.
* gimplify.cc (gimplify_init_constructor): Check it.
* cgraph.cc (symtab_node::address_can_be_compared_p): Likewise.
* varasm.cc (categorize_decl_for_section): Likewise.

gcc/cp/ChangeLog:

* call.cc (maybe_init_list_as_array): Set DECL_MERGEABLE.
(convert_like_internal) [ck_list]: Set it.
(set_up_extended_ref_temp): Copy it.
* tree.cc (handle_no_unique_addr_attribute): Set it.

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/initlist-opt1.C: Check for static array.
* g++.dg/tree-ssa/initlist-opt2.C: Likewise.
* g++.dg/tree-ssa/initlist-opt4.C: New test.
* g++.dg/opt/icf1.C: New test.
* g++.dg/opt/icf2.C: New test.
* g++.dg/opt/icf3.C: New test.
* g++.dg/tree-ssa/array-temp1.C: Revert r12-657 change.

[Bug c++/105838] [10/11/12/13/14 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings

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

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

--- Comment #22 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-1500-g4d935f52b0d5c00fcc154461b87415ebd8791a94
Author: Jason Merrill 
Date:   Wed Dec 7 11:40:53 2022 -0500

c++: make initializer_list array static again [PR110070]

After the maybe_init_list_as_* patches, I noticed that we were putting the
array of strings into .rodata, but then memcpying it into an automatic
array, which is pointless; we should be able to use it directly.

This doesn't happen automatically because TREE_ADDRESSABLE is set (since
r12-657 for PR100464), and so gimplify_init_constructor won't promote the
variable to static.  Theoretically we could do escape analysis to recognize
that the address, though taken, never leaves the function; that would allow
promotion when we're only using the address for indexing within the
function, as in initlist-opt2.C.  But this would be a new pass.

And in initlist-opt1.C, we're passing the array address to another
function,
so it definitely escapes; it's only safe in this case because it's calling
a
standard library function that we know only uses it for indexing.  So, a
flag seems needed.  I first thought to put the flag on the TARGET_EXPR, but
the VAR_DECL seems more appropriate.

In a previous revision of the patch I called this flag DECL_NOT_OBSERVABLE,
but I think DECL_MERGEABLE is a better name, especially if we're going to
apply it to the backing array of initializer_list, which is observable.  I
then also check it in places that check for -fmerge-all-constants, so that
multiple equivalent initializer-lists can also be combined.  And then it
seemed to make sense for [[no_unique_address]] to have this meaning for
user-written variables.

I think the note in [dcl.init.list]/6 intended to allow this kind of
merging
for initializer_lists, but it didn't actually work; for an explicit array
with the same initializer, if the address escapes the program could tell
whether the same variable in two frames have the same address.  P2752 is
trying to correct this defect, so I'm going to assume that this is the
intent.

PR c++/110070
PR c++/105838

gcc/ChangeLog:

* tree.h (DECL_MERGEABLE): New.
* tree-core.h (struct tree_decl_common): Mention it.
* gimplify.cc (gimplify_init_constructor): Check it.
* cgraph.cc (symtab_node::address_can_be_compared_p): Likewise.
* varasm.cc (categorize_decl_for_section): Likewise.

gcc/cp/ChangeLog:

* call.cc (maybe_init_list_as_array): Set DECL_MERGEABLE.
(convert_like_internal) [ck_list]: Set it.
(set_up_extended_ref_temp): Copy it.
* tree.cc (handle_no_unique_addr_attribute): Set it.

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/initlist-opt1.C: Check for static array.
* g++.dg/tree-ssa/initlist-opt2.C: Likewise.
* g++.dg/tree-ssa/initlist-opt4.C: New test.
* g++.dg/opt/icf1.C: New test.
* g++.dg/opt/icf2.C: New test.
* g++.dg/opt/icf3.C: New test.
* g++.dg/tree-ssa/array-temp1.C: Revert r12-657 change.

[Bug middle-end/110094] Support __builtin_mem*_inline

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Severity|normal  |enhancement

[Bug c/110094] New: Support __builtin_mem*_inline

[i at maskray dot me via Gcc-bugs]

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

Bug ID: 110094
   Summary: Support __builtin_mem*_inline
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

Clang introduced `__builtin_memcpy_inline` (https://reviews.llvm.org/D73543) in
2020 and `__builtin_memset_inline` (https://reviews.llvm.org/D126903) in 2022.
The two builtin functions expand memcpy/memset and guarantee that no external
functions are called. [1]

Past GCC discussion:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609138.html ("[RFC]
Introduce -finline-memset-loops").

[1]: There are some unhandled cases due to re-combining like
https://github.com/llvm/llvm-project/issues/56876

[Bug c++/106760] [12/13/14 Regression] ICE: tree check: expected function_decl, have template_decl in get_fndecl_argument_location, at cp/call.cc:7801

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
Summary|ICE: tree check: expected   |[12/13/14 Regression] ICE:
   |function_decl, have |tree check: expected
   |template_decl in|function_decl, have
   |get_fndecl_argument_locatio |template_decl in
   |n, at cp/call.cc:7801   |get_fndecl_argument_locatio
   ||n, at cp/call.cc:7801

[Bug c++/110092] Missing warning that internal header is used

[piotrwn1 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Piotr Nycz  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Piotr Nycz from comment #0)
> > So, probably it is doable to add warning like: "bist/shared_ptr.h is an
> > internal header file, included by other library headers. Do not attempt to
> > use it directly. Use  instead"
> 
> We could add this to :
> 
> #ifndef _GLIBCXX_MEMORY
> # error Do not include  directly, include 
> instead.
> #endif
> 
> But then you'd get an error when you include , or , or
> , or any of the other headers that use std::shared_ptr internally.
> 
> So we'd have to do:
> 
> #if !defined _GLIBCXX_MEMORY && !defined _GLIBCXX_CHRONO && !defined
> _GLIBCXX_REGEX \
> && ! defined ...
> 
> And that would be a pain to maintain.
> 
> And then it would still not give an error for this, even though it's still
> wrong:
> 
> #include 
> #include 
> std::shared_ptr p;
> 
> So I don't think this can really be solved in the compiler without a lot of
> work to hardcode special handling for each of those headers.

Well, I did not mean to make such a mess in compiler headers for sure. But if
it is somehow detectable that the compiler is compiling something in user
directories (not in std library, compiler stuff) then maybe it can be detected
by compiler that something internal is included in user file. I am just
guessing, I do not have any knowledge about how gcc compiler is working. 
I see that system headers have some pragma telling it is system header and
these internal headers have comment in `@file` section that it is internal. 

But of course - it could be done by some other tool like clang-tidy, if this is
a big problem. I just think it would be nice to have such warning - so it is
more "new feature request" than bug report.

[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.

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

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Thomas Schwinge from comment #6)
> 
> "Consider '--with-build-sysroot=[...]' for target libraries' build-tree
> testing (instead of build-time 'CC' etc.) [PR109951]".

this fixes the problem for me;  I tried both a 64b host with a 32b multilib and
vice versa. (smoke tested a couple more test suites, including Ada, with no
apparent issues)

However, my configuration does not have --with-build-sysroot= so that aspect is
untested by me.  (it is not an option used often on Darwin because of problems
elsewhere in the configuration).

[Bug tree-optimization/89263] Simplify bool expression to OR

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #8 from Andrew Pinski  ---
*** Bug 110087 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/110087] Missing if conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Andrew Pinski  ---
Really this is a dup of bug 89263.

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

[Bug c++/110092] Missing warning that internal header is used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Jonathan Wakely  ---
(In reply to Piotr Nycz from comment #0)
> So, probably it is doable to add warning like: "bist/shared_ptr.h is an
> internal header file, included by other library headers. Do not attempt to
> use it directly. Use  instead"

We could add this to :

#ifndef _GLIBCXX_MEMORY
# error Do not include  directly, include  instead.
#endif

But then you'd get an error when you include , or , or
, or any of the other headers that use std::shared_ptr internally.

So we'd have to do:

#if !defined _GLIBCXX_MEMORY && !defined _GLIBCXX_CHRONO && !defined
_GLIBCXX_REGEX \
&& ! defined ...

And that would be a pain to maintain.

And then it would still not give an error for this, even though it's still
wrong:

#include 
#include 
std::shared_ptr p;

So I don't think this can really be solved in the compiler without a lot of
work to hardcode special handling for each of those headers.

[Bug tree-optimization/110087] Missing if conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
I have a patch that converts this into the or.

[Bug c++/95226] [8 Regression] Faulty aggregate initialization of vector with struct with float

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-1498-ge7cc4d703bceb9095316c106eba0d1939c6c8044
Author: Jason Merrill 
Date:   Thu Jun 1 14:41:07 2023 -0400

varasm: check float size

In PR95226, the testcase was failing because we tried to output_constant a
NOP_EXPR to float from a double REAL_CST, and so we output a double where
the caller wanted a float.  That doesn't happen anymore, but with the
output_constant hunk we will ICE in that situation rather than emit the
wrong number of bytes.

Part of the problem was that initializer_constant_valid_p_1 returned true
for that NOP_EXPR, because it compared the sizes of integer types but not
floating-point types.  So the C++ front end assumed it didn't need to fold
the initializer.

PR c++/95226

gcc/ChangeLog:

* varasm.cc (output_constant) [REAL_TYPE]: Check that sizes match.
(initializer_constant_valid_p_1): Compare float precision.

[Bug gcov-profile/110082] Coverage analysis vs. offloading compilation

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
On Fri, 2 Jun 2023, tschwinge at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110082
> 
> --- Comment #5 from Thomas Schwinge  ---
> (In reply to Jakub Jelinek from comment #4)
> > (In reply to rguent...@suse.de from comment #3)
> > > I suppose you want to apply this generally, not only to offloaded
> > > functions and when offloading is enabled?
> > 
> > It could be done just for the functions that aren't host only, i.e.
> > the offloading kernels or declare target functions, what the offloading LTO
> > streams out.
> 
> Indeed my idea has been to apply this abstraction generally, without any
> conditionals on offloading constructs etc.  That's for reasons of
> maintainability: to not add any more diverging code paths, requiring special
> testing (now, and for future changes), and to lessen possibility of surprising
> behavior re the diverging code paths doing different things.  OK?

Yes, I think that's good.

[Bug middle-end/110089] sub-optimal code for attempting to produce JNA (jump on CF or ZF)

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Alexander Monakov from comment #4)
> If 'min' is needed anyway you can use it in subtraction:
> 
> void bar ();
> void foo (unsigned int n, unsigned s)
> {
>   do
> {
>   np = MIN (n, s);
>   bar (np);
> }
>   while (n -= np);
> }
> 
> but getting the sub-jcc trick to work should yield more efficient code.

It is needed, but using it in the subtraction creates an IV that's not
friendly to niter analysis because the step is no longer invariant.

[Bug analyzer/109015] Analyzer doesn't know about atomic builtins

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed for GCC 14 by the above patch.

[Bug analyzer/109015] Analyzer doesn't know about atomic builtins

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r14-1497-gef768035ae8090ecbe5726111a5fae4d5c86dd74
Author: David Malcolm 
Date:   Fri Jun 2 09:28:30 2023 -0400

analyzer: implement various atomic builtins [PR109015]

This patch implements many of the __atomic_* builtins from
sync-builtins.def as known_function subclasses within the analyzer.

gcc/analyzer/ChangeLog:
PR analyzer/109015
* kf.cc (class kf_atomic_exchange): New.
(class kf_atomic_exchange_n): New.
(class kf_atomic_fetch_op): New.
(class kf_atomic_op_fetch): New.
(class kf_atomic_load): New.
(class kf_atomic_load_n): New.
(class kf_atomic_store_n): New.
(register_atomic_builtins): New function.
(register_known_functions): Call register_atomic_builtins.

gcc/testsuite/ChangeLog:
PR analyzer/109015
* gcc.dg/analyzer/atomic-builtins-1.c: New test.
* gcc.dg/analyzer/atomic-builtins-haproxy-proxy.c: New test.
* gcc.dg/analyzer/atomic-builtins-qemu-sockets.c: New test.
* gcc.dg/analyzer/atomic-types-1.c: New test.

Signed-off-by: David Malcolm