[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access

[akihiko.odaki at daynix dot com via Gcc-bugs]

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

--- Comment #6 from Akihiko Odaki  ---
(In reply to Andrew Pinski from comment #4)
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
> include/asm-generic/unaligned.h?h=v6.7
> 
> is correct except it should not expose get_unaligned/put_unaligned since the
> undefined code happens way before.
> 
> The problem is with the btrfs code in btrfs_filldir:
> ```
> static int btrfs_filldir(void *addr, int entries, struct dir_context *ctx)
> {
>   while (entries--) {
>   struct dir_entry *entry = addr; /// THIS IS BROKEN and causes 
> the
> -fsanitize=alignment error
>   char *name = (char *)(entry + 1);
> 
>   ctx->pos = get_unaligned(&entry->offset);
>   if (!dir_emit(ctx, name, get_unaligned(&entry->name_len),
>get_unaligned(&entry->ino),
>get_unaligned(&entry->type)))
>   return 1;
>   addr += sizeof(struct dir_entry) +
>   get_unaligned(&entry->name_len);
>   ctx->pos++;
>   }
>   return 0;
> }
> ```
> 
> Added comment on where the error comes from. The get_unaligned macro really
> should not be used here. What should be used here is an unaligned version of
> `struct dir_entry` instead.

With looking at this comment, I did another experiment to see if it's specific
to struct members, 
Also, note that this behavior of UBSan is specific to struct members. Think of
the following functions:

u64 f2(u64 *offset)
{
return get_unaligned(offset);
}

u64 g2(u64 *offset)
{
return *offset;
}

f2() and g2() correspond to f() and g(). The only difference is that it does
not involve struct member access. Nevertheless, GCC changes its behavior and
doesn't emit alignment checks for f2().

If casting a pointer with a strict alignment requirement to one with a relaxed
alignment requirement doesn't relax the alignment requirement, UBSan should
emit an error for f2().

[Bug lto/114218] If there is an ODR violation due to array sizes being different, it would be useful to show what the sizes were

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|-Wodr could show constant   |If there is an ODR
   |values  |violation due to array
   ||sizes being different, it
   ||would be useful to show
   ||what the sizes were
   Severity|normal  |enhancement
  Component|c++ |lto
   Keywords||diagnostic
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-03

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c++/114218] -Wdr could show constant values

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

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

--- Comment #1 from Sam James  ---
To be clear: what I'd like is if the warning included "MAGIC_NUMBER was 42 at
one instance, and 100 at another".

[Bug c++/114218] New: -Wdr could show constant values

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

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

Bug ID: 114218
   Summary: -Wdr could show constant values
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

It'd be a nice UX improvement if -Wodr showed the differing constant values
rather than just the identifier.

(This came up in the wild https://github.com/alsaplayer/alsaplayer/issues/28).

a.h:
```
#ifndef MAGIC_NUMBER
#define MAGIC_NUMBER 42
#endif

struct number_storage {
int MY_NUMBERS[MAGIC_NUMBER];
};
```

b.cxx:
```
#include "a.h"

struct number_storage collection_1;
```

c.cxx
```
#define MAGIC_NUMBER 100
#include "a.h"

struct number_storage collection_2;

int main() {

}
```

```
$ g++ b.cxx c.cxx -Wall -Wextra -flto
a.h:5:8: warning: type ‘struct number_storage’ violates the C++ One Definition
Rule [-Wodr]
5 | struct number_storage {
  |^
a.h:5:8: note: a different type is defined in another translation unit
5 | struct number_storage {
  |^
a.h:6:13: note: the first difference of corresponding definitions is field
‘MY_NUMBERS’
6 | int MY_NUMBERS[MAGIC_NUMBER];
  | ^
a.h:6:13: note: a field of same name but different type is defined in another
translation unit
6 | int MY_NUMBERS[MAGIC_NUMBER];
  | ^
a.h:5:8: note: array types have different bounds
5 | struct number_storage {
  |^
```

[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access

[akihiko.odaki at daynix dot com via Gcc-bugs]

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

--- Comment #5 from Akihiko Odaki  ---
(In reply to Andrew Pinski from comment #4)
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
> include/asm-generic/unaligned.h?h=v6.7
> 
> is correct except it should not expose get_unaligned/put_unaligned since the
> undefined code happens way before.
> 
> The problem is with the btrfs code in btrfs_filldir:
> ```
> static int btrfs_filldir(void *addr, int entries, struct dir_context *ctx)
> {
>   while (entries--) {
>   struct dir_entry *entry = addr; /// THIS IS BROKEN and causes 
> the
> -fsanitize=alignment error
>   char *name = (char *)(entry + 1);
> 
>   ctx->pos = get_unaligned(&entry->offset);
>   if (!dir_emit(ctx, name, get_unaligned(&entry->name_len),
>get_unaligned(&entry->ino),
>get_unaligned(&entry->type)))
>   return 1;
>   addr += sizeof(struct dir_entry) +
>   get_unaligned(&entry->name_len);
>   ctx->pos++;
>   }
>   return 0;
> }
> ```
> 
> Added comment on where the error comes from. The get_unaligned macro really
> should not be used here. What should be used here is an unaligned version of
> `struct dir_entry` instead.

I understand the idea. What I don't get is that GCC still emits code for
unaligned memory access in such a case. It is just a waste of performance if
GCC doesn't provide a guarantee that the unaligned access is performed in such
a case and is not optimal.

[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access

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

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

--- Comment #4 from Andrew Pinski  ---
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/unaligned.h?h=v6.7

is correct except it should not expose get_unaligned/put_unaligned since the
undefined code happens way before.

The problem is with the btrfs code in btrfs_filldir:
```
static int btrfs_filldir(void *addr, int entries, struct dir_context *ctx)
{
while (entries--) {
struct dir_entry *entry = addr; /// THIS IS BROKEN and causes
the -fsanitize=alignment error
char *name = (char *)(entry + 1);

ctx->pos = get_unaligned(&entry->offset);
if (!dir_emit(ctx, name, get_unaligned(&entry->name_len),
 get_unaligned(&entry->ino),
 get_unaligned(&entry->type)))
return 1;
addr += sizeof(struct dir_entry) +
get_unaligned(&entry->name_len);
ctx->pos++;
}
return 0;
}
```

Added comment on where the error comes from. The get_unaligned macro really
should not be used here. What should be used here is an unaligned version of
`struct dir_entry` instead.

[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access

[akihiko.odaki at daynix dot com via Gcc-bugs]

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

--- Comment #3 from Akihiko Odaki  ---
(In reply to Andrew Pinski from comment #1)
> >but also emits code to assert alignment.
> 
> 
> Yes because the code is broken still.
> 
> The alignment is not about when the access happens but rather when the
> pointer is casted to.
> 
> So in this case when passing in the argument to f, the argument entry should
> be aligned to what the `struct dir_entry` is aligned to; otherwise it is
> undefined code.


I had a similar thought when I faced the same issue before and didn't report it
then, but this time I realized GCC still emits code to perform slow unaligned
access for such a construct. Whichever is right, to assume an aligned or
unaligned access, it is not consistent.

Theoretically, it also makes sense to emit unaligned memory access for such a
construct instead of ignoring it when -fsanitize=address, but I'm worried that
such a change will break too many things.

[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access

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

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

--- Comment #2 from Andrew Pinski  ---
That is if we have:

void f(void)
{
  char t[sizeof(int)] __attribute__((aligned(1)));
  int *a = (int*)&t;
  //
}

The above code is undefined even if you have not accessed via *a at all.

[Bug sanitizer/114217] -fsanitize=alignment false positive with intended unaligned struct member access

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>but also emits code to assert alignment.


Yes because the code is broken still.

The alignment is not about when the access happens but rather when the pointer
is casted to.

So in this case when passing in the argument to f, the argument entry should be
aligned to what the `struct dir_entry` is aligned to; otherwise it is undefined
code.

[Bug sanitizer/114217] New: -fsanitize=alignment false positive with intended unaligned struct member access

[akihiko.odaki at daynix dot com via Gcc-bugs]

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

Bug ID: 114217
   Summary: -fsanitize=alignment false positive with intended
unaligned struct member access
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akihiko.odaki at daynix dot com
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
  Target Milestone: ---

-fsanitize=alignment generates a false positive error for an intended unaligned
struct member access. The intention of unaligned struct member access is
expressed with __builtin_memcpy() as done by QEMU or packed struct access as
done by Linux. GCC translates such a construct to code to access memory
unaligned for architectures like rv64gc as intended but also emits code to
enforce the alignment.

The relevant code of QEMU is at:
https://gitlab.com/qemu-project/qemu/-/blob/v8.2.1/include/qemu/bswap.h?ref_type=tags
The relevant code of Linux is at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/unaligned.h?h=v6.7

FYI, this issue is reproducible also with clang 17.0.1, and I'm going to open
an issue for it, too.

To reproduce the issue, compile the code shown below with -O2
-fsanitize=alignment for rv64gc:

#include 

typedef uint64_t u64;

/*
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler_attributes.h?h=v6.7
*/

/*
 *   gcc:
https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-packed-type-attribute
 * clang:
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-packed-variable-attribute
 */
#define __packed__attribute__((__packed__))

/*
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/unaligned.h?h=v6.7
*/

#define __get_unaligned_t(type, ptr) ({
\
const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); 
\
__pptr->x; 
\
})

#define __put_unaligned_t(type, val, ptr) do { 
\
struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr);   
\
__pptr->x = (val); 
\
} while (0)

#define get_unaligned(ptr)  __get_unaligned_t(typeof(*(ptr)), (ptr))
#define put_unaligned(val, ptr) __put_unaligned_t(typeof(*(ptr)), (val), (ptr))

/*
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/inode.c?h=v6.7
*/

struct dir_entry {
u64 ino;
u64 offset;
unsigned type;
int name_len;
};

/*
 * This function is intended to perform an unaligned access.
 * GCC emits code for an unaligned operation as intended,
 * but also emits code to assert alignment.
 */
u64 f(struct dir_entry *entry)
{
return get_unaligned(&entry->offset);
}

/*
 * This function is intended to perform an aligned access.
 * GCC emits code for an aligned operation,
 * and emits code to assert alignment.
 */
u64 g(struct dir_entry *entry)
{
return entry->offset;
}

[Bug target/111001] SH: ICE during RTL pass: sh_treg_combine2

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

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #18 from Oleg Endo  ---
Should be fixed.

[Bug target/101737] SH4 -Os causes internal compiler error when building pixman

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

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

Oleg Endo  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||olegendo at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #9 from Oleg Endo  ---
Thanks everyone for staying on this and re-testing.  It should be fixed now on
the open branches.  If you want to use a version older than GCC 11, please
apply the committed patch to your GCC source.

[Bug target/101737] SH4 -Os causes internal compiler error when building pixman

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Oleg Endo
:

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

commit r11-11267-gec65cb598cc6fa126b458cf716438cc3f2404f3c
Author: Oleg Endo 
Date:   Sun Mar 3 14:58:58 2024 +0900

SH: Fix 101737

gcc/ChangeLog:
PR target/101737
* config/sh/sh.c (sh_is_nott_insn): Handle case where the input
is not an insn, but e.g. a code label.

[Bug target/101737] SH4 -Os causes internal compiler error when building pixman

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Oleg Endo
:

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

commit r12-10192-gbbae41dc9033d6f0a9f8bc56cc6f80d90286996c
Author: Oleg Endo 
Date:   Sun Mar 3 14:58:58 2024 +0900

SH: Fix 101737

gcc/ChangeLog:
PR target/101737
* config/sh/sh.cc (sh_is_nott_insn): Handle case where the input
is not an insn, but e.g. a code label.

[Bug target/101737] SH4 -Os causes internal compiler error when building pixman

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Oleg Endo
:

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

commit r13-8402-ga38b3dfc71d6b5d07477715a3a6df7b73ebaa68d
Author: Oleg Endo 
Date:   Sun Mar 3 14:58:58 2024 +0900

SH: Fix 101737

gcc/ChangeLog:
PR target/101737
* config/sh/sh.cc (sh_is_nott_insn): Handle case where the input
is not an insn, but e.g. a code label.

[Bug target/101737] SH4 -Os causes internal compiler error when building pixman

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Oleg Endo :

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

commit r14-9278-g4ff8ffe7331cf174668cf5c729fd68ff327ab014
Author: Oleg Endo 
Date:   Sun Mar 3 14:58:58 2024 +0900

SH: Fix 101737

gcc/ChangeLog:
PR target/101737
* config/sh/sh.cc (sh_is_nott_insn): Handle case where the input
is not an insn, but e.g. a code label.

[Bug tree-optimization/114212] `MIN / CST` -> `uns >= CST`

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

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

--- Comment #2 from Andrew Pinski  ---
For mod, it is
`MIN % 64` -> `a >= 64 ? 0 : a`

`(a >= 64 ? 64 : a) % 64` -> `a >= 64 ? (64 % 64) : (a % 64)` -> `a >= 64 ? 0 :
a` as a will be `a < 64` in the false case.

[Bug tree-optimization/114214] `(x&~M)|((x&M)&~(y&M))` -> `x&~(y&M)` is not done

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-03
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
(simplify
 (bit_ior:c
  (bit_and:c @0 @c1)
  (bit_and:c
   (bit_not@n (bit_and:c @2 @1))
   (bit_and:c @0 @1)
  )
 )
 (if (gimple_bitwise_inverted_equal_p (@1, @c1, wascmp)
  && (!wascmp || element_precision (type) == 1))
  (bit_and @0 @n)))


(simplify
 (bit_ior:c
  (bit_and:c @0 @c1)
  (bit_and:c
   (bit_ior:c@n @2 @c1)
   (bit_and:c @0 @1)
  )
 )
 (if (gimple_bitwise_inverted_equal_p (@1, @c1, wascmp)
  && (!wascmp || element_precision (type) == 1))
  (bit_and @0 @n)))

[Bug libgomp/114216] gnu2x: error: too many arguments to function ‘host_fn’

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

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

--- Comment #1 from Andrew Pinski  ---
>when building gcc with CFLAGS=" -std=gnu2x "


Why are you building with this?

Also basically target.c is still written in C99.

This patch should fix the issue though:
```
diff --git a/libgomp/target.c b/libgomp/target.c
index 1367e9cce6c..945244b33de 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -3447,7 +3447,7 @@ gomp_target_rev (uint64_t fn_ptr, uint64_t mapnum,
uint64_t devaddrs_ptr,

   if (n == NULL)
 gomp_fatal ("Cannot find reverse-offload function");
-  void (*host_fn)() = (void (*)()) n->k->host_start;
+  void (*host_fn)(void*) = (void (*)(void*)) n->k->host_start;

   if ((devicep->capabilities & GOMP_OFFLOAD_CAP_SHARED_MEM) || mapnum == 0)
 {

```

> but it really does seem like something specific is broken at that point that 
> should be documented

It is documented in the C standard as being an incompatible change between
C11/C17/C90/C99 and C23. Basically `()` as the function paramaters is no longer
the same as `(...)` but rather the same as `(void)`.

[Bug libgomp/114216] New: gnu2x: error: too many arguments to function ‘host_fn’

[jeffrey.cliff at gmail dot com via Gcc-bugs]

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

Bug ID: 114216
   Summary: gnu2x: error: too many arguments to function ‘host_fn’
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeffrey.cliff at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

tl;dr : gcc fails to build, consistently failing at 

"checking for library containing gettext..." 

with error

../../../libgomp/target.c: In function ‘gomp_target_rev’:
../../../libgomp/target.c:3782:3: error: too many arguments to function
‘host_fn’
 3782 |   host_fn (devaddrs);
  |   ^~~

when building gcc with CFLAGS=" -std=gnu2x "

system installed version of gcc:

system: lfs no microsoft
https://git.freecumextremist.com/themusicgod1/LFS-no-microsoft  Linux fatima
6.7.0-gnm-c23lfs #1 SMP PREEMPT_DYNAMIC Tue Jan  9 15:37:28 CST 2024 x86_64
GNU/Linux. (ie linux-libre 6.7 with patch to allow it to work compile with
-std=gnu23 on a custom (Free) LFS system)
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --disable-multilib
--with-system-zlib --enable-default-ssp --disable-fixincludes
--enable-languages=c,c++,fortran
CFLAGS=" -Oz ";
CXXFLAGS=" -Os ";
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240220 (experimental) (GCC) 

gcc being built:

gcc version 14.0.1 20240220 (experimental) (GCC) 
CFLAGS: -std=gnu2x
CXXFLAGS: (none)
Configured with:  --prefix=/usr --disable-multilib   
--with-system-zlib--enable-default-ssp  --disable-fixincludes
--enable-languages=c,c++,fortran;

first observed in gcc 13.2 (however, i could not find anything in git bisect
history that would suggest post-2020 that this would work)

I get that gnu2x is "experimental and incomplete", but it really does seem like
something specific is broken at that point that should be
documented...somewhere, and this represents an actual
bug/not-yet-working-functionality thing

[Bug ipa/114215] -Os or -Oz inlining seems wrong for vague linkage functions

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #7 from cqwrteur  ---
 __builtin_trap() is just to crash the program.

[Bug ipa/114215] -Os or -Oz inlining seems wrong for vague linkage functions

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
(In reply to Andrew Pinski from comment #5)
> Still waiting on a full application rather then small benchmark type
> sources. The heurstic here is that if you call operator[] multiple times, it
> might be better not to inline it for size reasons.

I know. but here the function is too small to the point it is always better to
inline it. Because all it does is an efficient bounds checking. You do not want
bounds checking to be a function call.

[Bug ipa/114215] GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

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

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

--- Comment #5 from Andrew Pinski  ---
Still waiting on a full application rather then small benchmark type sources.
The heurstic here is that if you call operator[] multiple times, it might be
better not to inline it for size reasons.

[Bug ipa/114215] GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
void test_demovector(checkedvector& vec, __SIZE_TYPE__ x) noexcept
{
  for(__SIZE_TYPE__ i = 0; i < x; i++)
vec[i]=5;
}

void test_demovector_forceinline(checkedvector& vec, __SIZE_TYPE__ x) noexcept
{
  for(__SIZE_TYPE__ i = 0; i < x; i++)
vec.index_forceinline(i)=5;
}

still more instructions for the first one even with a loop.

test_demovector(checkedvector&, unsigned long):
pushq   %r12
movq%rdi, %r12
pushq   %rbp
movq%rsi, %rbp
pushq   %rbx
xorl%ebx, %ebx
.L10:
cmpq%rbp, %rbx
je  .L13
movq%rbx, %rsi
movq%r12, %rdi
incq%rbx
callcheckedvector::operator[](unsigned long)
movq$5, (%rax)
jmp .L10
.L13:
popq%rbx
popq%rbp
popq%r12
ret



test_demovector_forceinline(checkedvector&, unsigned long):
xorl%eax, %eax
.L15:
cmpq%rsi, %rax
je  .L18
movq(%rdi), %rcx
movq8(%rdi), %rdx
subq%rcx, %rdx
sarq$3, %rdx
cmpq%rdx, %rax
jb  .L16
ud2
.L16:
movq$5, (%rcx,%rax,8)
incq%rax
jmp .L15
.L18:
ret

[Bug ipa/114215] GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
test_demovector(checkedvector&):
pushq   %rbx
movq%rdi, %rbx
pushq   $4
popq%rsi
callcheckedvector::operator[](unsigned long)
movq%rbx, %rdi
movq$5, (%rax)
pushq   $6
popq%rsi
callcheckedvector::operator[](unsigned long)
movq%rbx, %rdi
movq$5, (%rax)
pushq   $10
popq%rsi
callcheckedvector::operator[](unsigned long)
movq%rbx, %rdi
movq$5, (%rax)
pushq   $5
popq%rsi
callcheckedvector::operator[](unsigned long)
movq$5, (%rax)
popq%rbx
ret
test_demovector_forceinline(checkedvector&):
movq(%rdi), %rax
movq8(%rdi), %rdx
subq%rax, %rdx
cmpq$32, %rdx
ja  .L7
.L8:
ud2
.L7:
movq$5, 32(%rax)
cmpq$48, %rdx
jbe .L8
movq$5, 48(%rax)
cmpq$80, %rdx
jbe .L8
movq$5, 80(%rax)
movq$5, 40(%rax)
ret

see? first one has more instructions than the 2nd one.

[Bug ipa/114215] GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-03-03

--- Comment #2 from Andrew Pinski  ---
checkedvector::value_type& checkedvector::operator[](size_type)/167 call is
unlikely and code size would grow
  freq:1.00 loop depth: 0 size: 4 time: 13 callee size: 6 stack: 0
   op1 is compile time invariant



If I had:
```
void test_demovector(checkedvector& vec, int x) noexcept
{
  for(int i = 0; i < y; i++)
vec[i]=5;
}
```

Then GCC will inling operator[]:
checkedvector::value_type& checkedvector::operator[](size_type)/167 inlined
  freq:8.09
  Stack frame offset 0, callee self size 0
  void __builtin_trap()/205 function body not available
freq:0.00 loop depth: 1 size: 1 time:  1

I am suspecting this is the right heurstic. Do you have real code where the
inlining does not happen at -Os/-Oz or you just looking at the code generation
with code that might be benchmarking things?

[Bug ipa/114215] GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 57597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57597&action=edit
Testcase

Please next time attach the testcase rather than just link to godbolt.

[Bug rtl-optimization/114215] New: GCC makes wrong decision for inline with -Os or -Oz to deal with trivial functions

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 114215
   Summary: GCC makes wrong decision for inline with -Os or -Oz to
deal with trivial functions
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

This is a very common example for implementing a bounds checking vecotr index.
GCC makes the wrong decision. This even increases the code size but not
decreases the size compared to -O3.

GCC with -Oz
https://godbolt.org/z/sa9YYqnYY
GCC with -Ofast
https://godbolt.org/z/b6jahvh6s

clang with -Oz
https://godbolt.org/z/GxPaxP66b

[Bug tree-optimization/114214] New: `(x&~M)|((x&M)&~(y&M))` -> `x&~(y&M)` is not done

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

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

Bug ID: 114214
   Summary: `(x&~M)|((x&M)&~(y&M))` -> `x&~(y&M)` is not done
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

GCC should be able to optimize f to f1:
```
int f(int x, int y, int M)
{
return (x&~M)|((x&M)&~(y&M));
}
int f1(int x, int y, int M)
{
return x&~(y&M);
}
```

Note it should be also done for a constant M and when M is a comparison too.

[Bug c++/107400] [c++ modules] ICE tree check: expected class 'type', have 'declaration' (template_decl) in get_originating_module_decl, at cp/module.cc:18587

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Nathaniel Shead  ---
This looks to be fixed on trunk.

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

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

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

Bug 107400 Summary: [c++ modules] ICE tree check: expected class 'type', have 
'declaration' (template_decl) in get_originating_module_decl, at 
cp/module.cc:18587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107400

   What|Removed |Added

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

[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #11 from Iain Buclaw  ---
Fix committed and backported.

[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:3e60064a03a1a6d38ceb5ca4eb7e1f4d30a8aed1

commit r11-11266-g3e60064a03a1a6d38ceb5ca4eb7e1f4d30a8aed1
Author: Iain Buclaw 
Date:   Sun Mar 3 02:26:37 2024 +0100

d: Fix gdc -O2 -mavx generates misaligned vmovdqa instruction [PR114171]

PR d/114171

gcc/d/ChangeLog:

* d-codegen.cc (lower_struct_comparison): Keep alignment of
original
type in reinterpret cast for comparison.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr114171.d: New test.

(cherry picked from commit 623f52775e677bb3d6e9e7ef97196741dd904b1e)

[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

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

commit r12-10191-gff9d13e0110b46b39cacb431926515cf4be3aa8d
Author: Iain Buclaw 
Date:   Sun Mar 3 02:26:37 2024 +0100

d: Fix gdc -O2 -mavx generates misaligned vmovdqa instruction [PR114171]

PR d/114171

gcc/d/ChangeLog:

* d-codegen.cc (lower_struct_comparison): Keep alignment of
original
type in reinterpret cast for comparison.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr114171.d: New test.

(cherry picked from commit 623f52775e677bb3d6e9e7ef97196741dd904b1e)

[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

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

commit r13-8401-gcdcbc56c3f5a04e4e7cccdc70a420bc069a0941f
Author: Iain Buclaw 
Date:   Sun Mar 3 02:26:37 2024 +0100

d: Fix gdc -O2 -mavx generates misaligned vmovdqa instruction [PR114171]

PR d/114171

gcc/d/ChangeLog:

* d-codegen.cc (lower_struct_comparison): Keep alignment of
original
type in reinterpret cast for comparison.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr114171.d: New test.

(cherry picked from commit 623f52775e677bb3d6e9e7ef97196741dd904b1e)

[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:623f52775e677bb3d6e9e7ef97196741dd904b1e

commit r14-9277-g623f52775e677bb3d6e9e7ef97196741dd904b1e
Author: Iain Buclaw 
Date:   Sun Mar 3 02:26:37 2024 +0100

d: Fix gdc -O2 -mavx generates misaligned vmovdqa instruction [PR114171]

PR d/114171

gcc/d/ChangeLog:

* d-codegen.cc (lower_struct_comparison): Keep alignment of
original
type in reinterpret cast for comparison.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr114171.d: New test.

[Bug d/113125] [D] internal compiler error: in make_import, at d/imports.cc:48

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Buclaw  ---
Fixed and backported.

[Bug d/113758] d: Callee destructor call invalidates the live object, not the temporary

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Buclaw  ---
Fixed and backported.

[Bug d/113758] d: Callee destructor call invalidates the live object, not the temporary

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:8ceb48b1f8ebb9957d896082b0b503cf7f81cace

commit r11-11264-g8ceb48b1f8ebb9957d896082b0b503cf7f81cace
Author: Iain Buclaw 
Date:   Sun Feb 4 22:04:14 2024 +0100

d: Fix callee destructor call invalidates the live object [PR113758]

When generating the argument, check the isCalleeDestroyingArgs hook, and
force a TARGET_EXPR to be created if true, so that a reference to the
live object isn't passed directly to the function that runs dtors.

When instead dealing with caller running destructors, two temporaries
were being generated, one explicit temporary generated by the D
front-end, and another implicitly by the code generator.  This has been
reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to
bind it to the implicit slot created for the TARGET_EXPR, as that has
the shorter lifetime of the two.

PR d/113758

gcc/d/ChangeLog:

* d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee
destorys its arguments.
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Set
SET_DECL_VALUE_EXPR on the temporary variable to make it a
placeholder
for the TARGET_EXPR_SLOT.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr113758.d: New test.

(cherry picked from commit 3c57b1c12a8e34d50bdf6aaf44146760db6d1b33)

[Bug d/113125] [D] internal compiler error: in make_import, at d/imports.cc:48

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:3c0c18799eff99221d2eaae3de6fca6da14269dd

commit r11-11263-g3c0c18799eff99221d2eaae3de6fca6da14269dd
Author: Iain Buclaw 
Date:   Mon Feb 12 16:59:12 2024 +0100

d: Fix internal compiler error: in make_import, at d/imports.cc:48
[PR113125]

The cause of the ICE was that TYPE_DECLs were only being generated for
structs with members, not opaque structs.

PR d/113125

gcc/d/ChangeLog:

* types.cc (TypeVisitor::visit (TypeStruct *)): Generate TYPE_DECL
and
apply UDAs to opaque struct declarations.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr113125.d: New test.
* gdc.dg/pr113125.d: New test.

(cherry picked from commit b0efb1c35724e3332ee5993976efb98200c1a154)

[Bug d/113758] d: Callee destructor call invalidates the live object, not the temporary

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

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

commit r12-10189-ge276a94c061861a09dd790d206ec73d90478925e
Author: Iain Buclaw 
Date:   Sun Feb 4 22:04:14 2024 +0100

d: Fix callee destructor call invalidates the live object [PR113758]

When generating the argument, check the isCalleeDestroyingArgs hook, and
force a TARGET_EXPR to be created if true, so that a reference to the
live object isn't passed directly to the function that runs dtors.

When instead dealing with caller running destructors, two temporaries
were being generated, one explicit temporary generated by the D
front-end, and another implicitly by the code generator.  This has been
reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to
bind it to the implicit slot created for the TARGET_EXPR, as that has
the shorter lifetime of the two.

PR d/113758

gcc/d/ChangeLog:

* d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee
destorys its arguments.
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Set
SET_DECL_VALUE_EXPR on the temporary variable to make it a
placeholder
for the TARGET_EXPR_SLOT.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr113758.d: New test.

(cherry picked from commit 3c57b1c12a8e34d50bdf6aaf44146760db6d1b33)

[Bug d/113125] [D] internal compiler error: in make_import, at d/imports.cc:48

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

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

commit r12-10188-gf3567889645ce1fed79c13d644313aa2a8ab9318
Author: Iain Buclaw 
Date:   Mon Feb 12 16:59:12 2024 +0100

d: Fix internal compiler error: in make_import, at d/imports.cc:48
[PR113125]

The cause of the ICE was that TYPE_DECLs were only being generated for
structs with members, not opaque structs.

PR d/113125

gcc/d/ChangeLog:

* types.cc (TypeVisitor::visit (TypeStruct *)): Generate TYPE_DECL
and
apply UDAs to opaque struct declarations.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr113125.d: New test.
* gdc.dg/pr113125.d: New test.

(cherry picked from commit b0efb1c35724e3332ee5993976efb98200c1a154)

[Bug d/113758] d: Callee destructor call invalidates the live object, not the temporary

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

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

--- Comment #2 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

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

commit r13-8399-ge64fbf38e0b408696a97fbceb131ed1d19cbcd03
Author: Iain Buclaw 
Date:   Sun Feb 4 22:04:14 2024 +0100

d: Fix callee destructor call invalidates the live object [PR113758]

When generating the argument, check the isCalleeDestroyingArgs hook, and
force a TARGET_EXPR to be created if true, so that a reference to the
live object isn't passed directly to the function that runs dtors.

When instead dealing with caller running destructors, two temporaries
were being generated, one explicit temporary generated by the D
front-end, and another implicitly by the code generator.  This has been
reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to
bind it to the implicit slot created for the TARGET_EXPR, as that has
the shorter lifetime of the two.

PR d/113758

gcc/d/ChangeLog:

* d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee
destorys its arguments.
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Set
SET_DECL_VALUE_EXPR on the temporary variable to make it a
placeholder
for the TARGET_EXPR_SLOT.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr113758.d: New test.

(cherry picked from commit 3c57b1c12a8e34d50bdf6aaf44146760db6d1b33)

[Bug d/113125] [D] internal compiler error: in make_import, at d/imports.cc:48

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

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

--- Comment #2 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:341fa4d2340b21c322082fb5a7cad18a48b9eda7

commit r13-8398-g341fa4d2340b21c322082fb5a7cad18a48b9eda7
Author: Iain Buclaw 
Date:   Mon Feb 12 16:59:12 2024 +0100

d: Fix internal compiler error: in make_import, at d/imports.cc:48
[PR113125]

The cause of the ICE was that TYPE_DECLs were only being generated for
structs with members, not opaque structs.

PR d/113125

gcc/d/ChangeLog:

* types.cc (TypeVisitor::visit (TypeStruct *)): Generate TYPE_DECL
and
apply UDAs to opaque struct declarations.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr113125.d: New test.
* gdc.dg/pr113125.d: New test.

(cherry picked from commit b0efb1c35724e3332ee5993976efb98200c1a154)

[Bug tree-optimization/114213] New: `MIN, CST> / CST` -> `a >= CST ? 1 : -(a <= -CST)`

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

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

Bug ID: 114213
   Summary: `MIN, CST> / CST` -> `a >= CST ? 1  : -(a
<= -CST)`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a)
{
a = a <= -64 ? -64 : a;
a = a >= 64 ? 64 : a;
return a/64;
}

int f1(int a)
{
  return a >= 64 ? 1  : -(a <= -64);
}
int f2(int a)
{
  return a <= -64 ? -1  : (a >= 64);
}
```
These all three should produce the same result.

This is basically the expanded version of PR 114212 on to the negative side.

[Bug libstdc++/113841] Can't swap two std::hash

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

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

--- Comment #12 from Jonathan Wakely  ---
There's no problem with pair, it's basic_string that fails.

[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #15 from dave.anglin at bell dot net ---
On 2024-03-01 5:42 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
>
> Jonathan Wakely  changed:
>
> What|Removed |Added
> 
>Attachment #57540|0   |1
>  is obsolete||
>
> --- Comment #14 from Jonathan Wakely  ---
> Created attachment 57591
>--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57591&action=edit
> Do not define lock-free atomic aliases if not fully lock-free
>
> Here's all of that as a single (slightly cleaned up) patch.
>
With this change, lock_free_aliases.cc fails test for excess errors:
Excess errors:
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:7:
error: #error "Feature test macro for lock-free type 
aliases is missing in "
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:19:
error: 'atomic_signed_lock_free' is not a member of 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:19:
error: template argument 1 is invalid
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:20:
error: 'atomic_unsigned_lock_free' is not a member of 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:20:
error: template argument 1 is invalid
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:25:
error: 'atomic_signed_lock_free' is not a member of 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:25:
error: template argument 1 is invalid
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:26:
error: 'atomic_unsigned_lock_free' is not a member of 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:26:
error: template argument 1 is invalid
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:29:
error: 'atomic_signed_lock_free' is not a member of 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:29:
error: template argument 1 is invalid
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:30:
error: 'atomic_unsigned_lock_free' is not a member of 'std'
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:30:
error: template argument 1 is invalid
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:33:
error: 'std::atomic_signed_lock_free' has not been declared
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc:34:
error: 'std::atomic_unsigned_lock_free' has not been 
declared

This is with my posted cmath patch.

[Bug tree-optimization/114212] `MIN / CST` -> `uns >= CST`

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

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

--- Comment #1 from Andrew Pinski  ---
Note I noticed this when looking at
https://github.com/llvm/llvm-project/issues/83676 but that is totally unrelated
since that is for mlir rather than LLVM's IR.

[Bug tree-optimization/114212] New: `MIN / CST` -> `uns >= CST`

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

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

Bug ID: 114212
   Summary: `MIN / CST` -> `uns >= CST`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
unsigned f(unsigned a)
{
a = a >= 64 ? 64 : a;
return a/64; // a >= 64
}
```

This can be simplified to just `a >= 64` as if `a >= 64`, then `MIN`
would be 64 and `64/64` is 1. Note this is actually true for all non-negative a
rather than just unsigned types.

For FP types, this can't be done as we won't just get 0,1 for the division but
the range [0.,1.].

[Bug middle-end/114209] ICE: verify_gimple failed: incorrect sharing of tree nodes at -O and above

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-02
 Ever confirmed|0   |1
 CC||pinskia at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug rtl-optimization/101523] Huge number of combine attempts

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #8 from Sam James  ---
I think Andreas meant to attach a testcase but hadn't?

[Bug target/114211] [13/14 Regression] wrong code with -O -fno-tree-coalesce-vars

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-02
   Target Milestone|--- |13.3
  Component|middle-end  |target
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
The difference with/without -fno-tree-coalesce-vars is just the expansion from
gimple to RTL does not reuse psedu-registers for variables which could have
been coalesced.

[Bug libstdc++/113841] Can't swap two std::hash

[ostash at ostash dot kiev.ua via Gcc-bugs]

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

--- Comment #11 from Viktor Ostashevskyi  ---
(In reply to Jonathan Wakely from comment #10)
> This one's much harder to fix:
> 
> #include 
> 
> template
> struct Alloc
> {
>   using value_type = T;
> 
>   Alloc(int) { }
> 
>   template Alloc(const Alloc&) { }
> 
>   T* allocate(std::size_t n) { return std::allocator().allocate(n); }
>   void deallocate(T* p, std::size_t n) { std::allocator().deallocate(p,
> n); }
> };
> 
> template struct wrap { T t; };
> 
> template void do_adl(T&) { }
> 
> void test_pr113841()
> {
>   using Tr = std::char_traits;
>   using test_type = std::basic_string>;
>   std::pair>* h = nullptr;
>   do_adl(h);
> }

Incremental approach? Fixing std::vector first, thinking about std::pair next..
:)

[Bug tree-optimization/114211] New: [13/14 Regression] wrong code with -O -fno-tree-coalesce-vars

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114211
   Summary: [13/14 Regression] wrong code with -O
-fno-tree-coalesce-vars
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57596&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-coalesce-vars testcase.c
$ ./a.out 
Aborted


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9272-20240302122604-gc8d12343a94-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9272-20240302122604-gc8d12343a94-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240302 (experimental) (GCC)

[Bug rtl-optimization/101523] Huge number of combine attempts

[sarah.kriesch at opensuse dot org via Gcc-bugs]

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

Sarah Julia Kriesch  changed:

   What|Removed |Added

 CC||sarah.kriesch at opensuse dot 
org

--- Comment #7 from Sarah Julia Kriesch  ---
That started more than some years ago.
I have initiated the debugging with this openSUSE bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1188441

IBM Bugzilla:
https://bugzilla.linux.ibm.com/show_bug.cgi?id=193674

The problem with the memory has been already available before my time at IBM.
That is reproducible on most Linux distributions for IBM Z & LinuxONE.

[Bug tree-optimization/114207] [12/13/14 Regression] modref gets confused by vecotorized code ` -O3 -fno-tree-forwprop` since r12-5439

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
Summary|[12/13/14 Regression]   |[12/13/14 Regression]
   |modref gets confused by |modref gets confused by
   |vecotorized code ` -O3  |vecotorized code ` -O3
   |-fno-tree-forwprop` |-fno-tree-forwprop` since
   ||r12-5439
   Priority|P3  |P2

--- Comment #2 from Jakub Jelinek  ---
Started with r12-5439-g0f5afb626381d19bfced30bc19cf3b03867fa6f5

[Bug c++/114210] New: Potential bug wrt __restrict on member function decl/def

[rl.alt.accnt at gmail dot com via Gcc-bugs]

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

Bug ID: 114210
   Summary: Potential bug wrt __restrict on member function
decl/def
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rl.alt.accnt at gmail dot com
  Target Milestone: ---

Clang dev here; I’m currently working on improving our support for `__restrict`
in the cv-qualifier-seq of member functions, and I have a question about the
following situation:

struct S {
void a() __restrict;
void b();
};

void S::a() { static_assert(__is_same(decltype(this), S*)); }
void S::b() __restrict { 
static_assert(__is_same(decltype(this), S* __restrict)); 
}

`decltype(this)` is `S* __restrict` in the body of `S::b`, but `S*` (no
`__restrict`) in the body of `S::a`, i.e. GCC only seems to care about
`__restrict` being present in the definition, not the declaration. 

According to the documentation
(https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Restricted-Pointers.html), ‘you
only need to specify __restrict__ in a function definition, rather than in a
function prototype as well.’ This doesn’t
really say anything about what happens if the opposite is the case (i.e. if
`__restrict` is only present in the declaration, not the definition).

My question, then: is this intended, or is it a bug?

[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function

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

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

--- Comment #14 from Paul Thomas  ---
To fix the parentheses wrinkle, this works:
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index eee569dac91..64f61c50c66 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -1963,6 +1963,20 @@ gfc_match_associate (void)
  goto assocListError;
}

+  /* If the selector expression is enclosed in parentheses and the
+expression is not a variable, throw the parentheses away.  */
+  while (newAssoc->target->expr_type == EXPR_OP
+&& newAssoc->target->value.op.op == INTRINSIC_PARENTHESES)
+   {
+ if (newAssoc->target->value.op.op1->expr_type == EXPR_VARIABLE)
+   break;
+ else
+   {
+ gfc_expr *e = gfc_copy_expr (newAssoc->target->value.op.op1);
+ gfc_replace_expr (newAssoc->target, e);
+   }
+   }
+
   /* The `variable' field is left blank for now; because the target is not

To maintain compatibility with
https://gcc.gnu.org/pipermail/fortran/2024-January/060092.html:

@@ -2220,7 +2235,8 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
bool sub_flag,
|| tgt_expr->symtree->n.sym->attr.if_source
== IFSRC_DECL);
   permissible = permissible
-   || (tgt_expr && tgt_expr->expr_type == EXPR_OP);
+   || (tgt_expr && (tgt_expr->expr_type == EXPR_OP
+   || (inquiry && tgt_expr->expr_type == EXPR_FUNCTION)));

   if (permissible)
{

[Bug libstdc++/77776] C++17 std::hypot implementation is poor

[g.peterhoff--- via Gcc-bugs]

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

--- Comment #13 from g.peterh...@t-online.de ---
Thanks for the suggestions:
template 
constexpr _Tp __hypot3(_Tp __x, _Tp __y, _Tp __z)   noexcept
{
if (std::isinf(__x) | std::isinf(__y) | std::isinf(__z))
[[__unlikely__]]
return _Tp(INFINITY);
__x = std::fabs(__x);
__y = std::fabs(__y);
__z = std::fabs(__z);
const _Tp __max = std::fmax(std::fmax(__x, __y), __z);
if (__max == _Tp{}) [[__unlikely__]]
return __max;
__x /= __max;
__y /= __max;
__z /= __max;
return std::sqrt(__x*__x + __y*__y + __z*__z) * __max;
}

The functions are then set to constexpr/noexcept.

regards
Gero

[Bug tree-optimization/114206] recursive function call vs local variable addresses

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #5 from Arsen Arsenović  ---
(In reply to Xi Ruoyao from comment #4)
> It looks like they needs to be different as they refer different objects and
> the lifetime of both object has still not ended when comparing them.
this seems the case to me also

[Bug rtl-optimization/114208] RTL DSE deletes a store that is not dead

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

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

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Andrew Pinski from comment #1)
> I wonder if this is related to r14-6674-g4759383245ac97 .

Seems unrelated: When I reverse-apply r14-6674 then the issue does not go away.

[Bug middle-end/114209] New: ICE: verify_gimple failed: incorrect sharing of tree nodes at -O and above

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114209
   Summary: ICE: verify_gimple failed: incorrect sharing of tree
nodes at -O and above
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu

Created attachment 57595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57595&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -m32 testcase.c 
testcase.c: In function 'foo':
testcase.c:7:1: error: incorrect sharing of tree nodes
7 | foo(void)
  | ^~~
MEM[(_BitInt(128) *)p.0_1]
# VUSE <.MEM_5(D)>
_8 = VIEW_CONVERT_EXPR(MEM[(_BitInt(128) *)p.0_1]);
during GIMPLE pass: bitintlower
testcase.c:7:1: internal compiler error: verify_gimple failed
0x155df5d verify_gimple_in_cfg(function*, bool, bool)
/repo/gcc-trunk/gcc/tree-cfg.cc:5663
0x13cccb4 execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2088
0x13cd20e execute_todo
/repo/gcc-trunk/gcc/passes.cc:2142
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9248-20240301110451-gd3d0fcb6527-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9248-20240301110451-gd3d0fcb6527-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240301 (experimental) (GCC)

[Bug rtl-optimization/114208] RTL DSE deletes a store that is not dead

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

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

--- Comment #2 from Georg-Johann Lay  ---
(In reply to Andrew Pinski from comment #1)
> I wonder if this is related to r14-6674-g4759383245ac97 .

Not unlikely. PR112525 tries to eliminate dead stores for arguments that are
passed.  It seems like that change misses some required conditions like
frame-pointer / arg-pointer adjustments.

[Bug tree-optimization/114206] recursive function call vs local variable addresses

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #1)
> I think both 0 and 1 are correct here.
> 
> The question becomes does the address of b need to be different between
> different calls of f. I am not 100% convinced it needs to be different.

It looks like they needs to be different as they refer different objects and
the lifetime of both object has still not ended when comparing them.

[Bug rtl-optimization/114208] RTL DSE deletes a store that is not dead

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

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

--- Comment #1 from Andrew Pinski  ---
I wonder if this is related to r14-6674-g4759383245ac97 .

[Bug rtl-optimization/114208] New: DSE deletes a store that is not dead

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

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

Bug ID: 114208
   Summary: DSE deletes a store that is not dead
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57594&action=edit
Reduced C test case

$ avr-gcc -mmcu=attiny40 bug-dse.c -S -Os -dp -mfuse-add=3 -fdse

the following C test case:

struct S { char a, b; };

__attribute__((__noinline__,__noclone__))
void test (const struct S *s)
{
if (s->a != 3 || s->b != 4)
__builtin_abort();
}

int main (void)
{
struct S s = { 3, 4 };
test (&s);

  return 0;
}

Then with DSE off (-fno-dse), main has a store of 3 into s.a:

main:
...
ldi r20,lo8(3)   ;  22  [c=4 l=1]  movqi_insn/1
ld __tmp_reg__,Y+;  24  [c=4 l=1]  *addhi3/3
st Y+,r20;  48  [c=4 l=1]  movqi_insn/2
ldi r20,lo8(4)   ;  27  [c=4 l=1]  movqi_insn/1
st Y,r20 ;  30  [c=4 l=1]  movqi_insn/2
...

but with DSE on, pass .dse2 removes the first store (insn 48, and in the wake
also insn 22) that sets s.a to 3:

main:
...
ldi r20,lo8(4)   ;  27  [c=4 l=1]  movqi_insn/1
subi r28,-2  ;  29  [c=4 l=2]  *addhi3/3
sbci r29,-1
st Y,r20 ;  30  [c=4 l=1]  movqi_insn/2
...

Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240302 (experimental) (GCC)

[Bug tree-optimization/114206] recursive function call vs local variable addresses

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

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

--- Comment #3 from congli  ---
How about this one: https://gcc.godbolt.org/z/Wvhddb7nf?

We ensured the two `b`s are different at each f() call.

[Bug tree-optimization/114207] modref gets confused by vecotorized code ` -O3 -fno-tree-forwprop`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=111613
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
Summary|Wrong code bug since GCC|modref gets confused by
   |12.1|vecotorized code ` -O3
   ||-fno-tree-forwprop`
   Target Milestone|--- |12.4
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-02

--- Comment #1 from Andrew Pinski  ---
Confirmed.

The IR is:
```
  vectp.7_7 = &s_4(D)->b;
  vectp.7_8 = vectp.7_7 + 18446744073709551612;
  vect__1.8_9 = MEM  [(int *)vectp.7_8];
  vect__2.9_10 = VEC_PERM_EXPR ;
  MEM  [(int *)s_4(D)] = vect__2.9_10;

```

modref thinks this only reads s->b somehow.

[Bug tree-optimization/114206] recursive function call vs local variable addresses

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

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

--- Comment #2 from congli  ---
That's correct. But I think it is not that reasonable if we treat the `b` like
`b` is a `static const` variable rather than a `const` variable? Any documents
telling this?

[Bug target/114194] ICE when using std::unique_ptr with xtheadvector

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||riscv
   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---

:4:28: error: unrecognizable insn:
4 | void f(S3 &) { S3 x; f(x); }
  |^
(insn 6 3 7 2 (set (reg:RVVMF8QI 134)
(unspec:RVVMF8QI [
(const_vector:RVVMF8QI [
(const_int 0 [0])
])
(reg:DI 0 zero)
(const_int 1 [0x1])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_TH_VWLDST)) "":4:19 -1
 (expr_list:REG_EQUAL (const_vector:RVVMF8QI [
(const_int 0 [0])
])
(nil)))
during RTL pass: vregs

[Bug target/114100] [avr] Inefficient indirect addressing on Reduced Tiny

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:96bad6c06d0108014a2b0e5d0921cb18066bb789

commit r14-9271-g96bad6c06d0108014a2b0e5d0921cb18066bb789
Author: Georg-Johann Lay 
Date:   Sat Mar 2 10:03:06 2024 +0100

AVR: target/114100 - Factor in -mtiny-stack in frame pointer adjustments

gcc/
PR target/114100
* config/avr/avr.cc (avr_out_plus_1) [-mtiny-stack]: Only adjust
the low part of the frame pointer with 8-bit stack pointer.

[Bug c/114207] New: Wrong code bug since GCC 12.1

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

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

Bug ID: 114207
   Summary: Wrong code bug since GCC 12.1
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: congli at smail dot nju.edu.cn
  Target Milestone: ---

The program below shows a wrong code bug, where the correct result should be
"s.a=12, s.b=6" while `-w -O3 -fno-tree-forwprop` prints "s.a=12, s.b=0" or
"s.a=12, s.b=". The bug stems from at least GCC 12.1 to our trunk.

```
#include 
#include 

struct S {
int a, b;
};

__attribute__((noinline))
void foo (struct S *s) {
struct S ss = (struct S) {
.a = s->b,
.b = s->a
};
*s = ss;
}

int main() {
  struct S s = {6, 12};
  foo(&s);
  printf("s.a=%d, s.b=%d\n", s.a, s.b);
  return 0;
}
```

Compiler Explorer: https://gcc.godbolt.org/z/8dbMWjsd8

After checking the assembly, we found that `8(%rsp)` (representing s.b) was not
initialized by the constant `6` while it is printed.

[Bug tree-optimization/114206] GCC generates wrong-code

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization

--- Comment #1 from Andrew Pinski  ---
I think both 0 and 1 are correct here.

The question becomes does the address of b need to be different between
different calls of f. I am not 100% convinced it needs to be different.

[Bug c/114206] New: GCC generates wrong-code

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

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

Bug ID: 114206
   Summary: GCC generates wrong-code
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: congli at smail dot nju.edu.cn
  Target Milestone: ---

The program shown below presents a wrong code bug, where the correct results
should be "f(0, NULL) = 0" while `-Os -fno-tree-ccp -fno-tree-copy-prop
-fno-tree-forwprop -fno-tree-fre -fno-tree-vrp` prints "f(0, NULL) = 1".

```
#include 

int f(int t, const int *a) {
  const int b[4] = {0};

  if (t == 0) {
return f(1, b);
  } else {
return b == a;
  }
}

int main(void) {
  printf("f(0, NULL) = %d\n", f(0, NULL));
}
```

Compiler Explorer: https://gcc.godbolt.org/z/W164xWMrP 

We checked the assembly, finding that it is weird that the compiler generates a
`cmove` instruction. See explanations below:

```
f:
leaq-16(%rsp), %rax -> RAX = RSP-16
testl   %edi, %edi  -> we called f(0, NULL); %edi = 0, ZF = 1
cmove   %rax, %rsi  -> condition fulfilled; RSI=RAX=RSP-16; weird
generation
cmpq%rax, %rsi  -> RSI=RAX; ZF=1
sete%al -> AL = 1
movzbl  %al, %eax   -> EAX = 1 (error)
ret
```

[Bug other/109398] libiberty/sha1.c:234:11: warning: defining a type within 'offsetof' is a Clang extension [-Wgnu-offsetof-extensions]

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

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

--- Comment #2 from Andrew Pinski  ---
So this might not be a clang extension after all. see
https://github.com/llvm/llvm-project/issues/83658 (and DE-137 discussion in the
meeting minutes: https://www.open-std.org/JTC1/sc22/wg14/www/docs/n3167.pdf ).

[Bug c/114205] Miscompilation: the use of __builtin_object_size cause asan failure.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I don't see why you think this is a bug.

-1 returning from __builtin_object_size means it does not know the size.

Without optimization, GCC cannot figure out the size of the object that is
being passed to __builtin_object_size . So at -O0 it aborts.
`-fsanitize=address` will output the error message:
```
AddressSanitizer:DEADLYSIGNAL
=
==1==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x7f7a49828898 bp
0x7f7a49a1be90 sp 0x7ffc8a097720 T0)

```

When abort is called.

There is nothing wrong here.

[Bug tree-optimization/114204] Missed optimization: -(a*!a) => 0 when a=-b-c

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

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

--- Comment #2 from Andrew Pinski  ---
```
int f(int a, int b)
{
if (a == -b)
  return a + b;
return 0;
}
int f1(int a, int b)
{
if (a == b)
  return a - b;
return 0;
}
```

Should be both handled in phiopt basically.

Another one too:
```
int f1(int a, int b)
{
if (a == b)
  return a / b;
return 1;
}
```
Should be transformed into 1 also.