[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(>offset);
>   if (!dir_emit(ctx, name, get_unaligned(>name_len),
>get_unaligned(>ino),
>get_unaligned(>type)))
>   return 1;
>   addr += sizeof(struct dir_entry) +
>   get_unaligned(>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(>offset);
>   if (!dir_emit(ctx, name, get_unaligned(>name_len),
>get_unaligned(>ino),
>get_unaligned(>type)))
>   return 1;
>   addr += sizeof(struct dir_entry) +
>   get_unaligned(>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(>offset);
if (!dir_emit(ctx, name, get_unaligned(>name_len),
 get_unaligned(>ino),
 get_unaligned(>type)))
return 1;
addr += sizeof(struct dir_entry) +
get_unaligned(>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*)
  //
}

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(>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;
}

[committed][SH] Fix 101737

[Oleg Endo]

Hi,

The attached patch should fix PR 101737.  It's a rather obvious oversight. 
Sanity tested with 'make all-gcc'.  Committed to master, gcc-13, gcc-12,
gcc-11.

Cheers,
Oleg


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.
From 4ff8ffe7331cf174668cf5c729fd68ff327ab014 Mon Sep 17 00:00:00 2001
From: Oleg Endo 
Date: Sun, 3 Mar 2024 14:58:58 +0900
Subject: [PATCH] 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.
---
 gcc/config/sh/sh.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index 2c4..ef3c2e6 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -11766,9 +11766,10 @@ sh_insn_operands_modified_between_p (rtx_insn* operands_insn,
negates the T bit and stores the result in the T bit.  */
 bool
 sh_is_nott_insn (const rtx_insn* i)
 {
-  return i != NULL && GET_CODE (PATTERN (i)) == SET
+  return i != NULL_RTX && PATTERN (i) != NULL_RTX
+	 && GET_CODE (PATTERN (i)) == SET
 	 && t_reg_operand (XEXP (PATTERN (i), 0), VOIDmode)
 	 && negt_reg_operand (XEXP (PATTERN (i), 1), VOIDmode);
 }
 
--
libgit2 1.6.4

[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)&~(y))` -> `x&~(y)` 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=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)&~(y))` -> `x&~(y)` 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)&~(y))` -> `x&~(y)` 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)&~(y));
}
int f1(int x, int y, int M)
{
return x&~(y);
}
```

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

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

[Iain Buclaw]

Hi,

This patch fixes a wrong code issue in the D front-end where lowered
struct comparisons would reinterpret fields with a different (usually
bigger) alignment than the original.  Use `build_aligned_type' to
preserve the alignment when casting away for such comparisons.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline, and backported to releases/gcc-13, releases/gcc-12, and
releases/gcc-11.

Regards,
Iain.
---
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.
---
 gcc/d/d-codegen.cc  |  1 +
 gcc/testsuite/gdc.dg/torture/pr114171.d | 29 +
 2 files changed, 30 insertions(+)
 create mode 100644 gcc/testsuite/gdc.dg/torture/pr114171.d

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 5bc233928aa..43d7739f8fc 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -1006,6 +1006,7 @@ lower_struct_comparison (tree_code code, 
StructDeclaration *sd,
  if (tmode == NULL_TREE)
tmode = make_unsigned_type (GET_MODE_BITSIZE (mode.require ()));
 
+ tmode = build_aligned_type (tmode, TYPE_ALIGN (stype));
  t1ref = build_vconvert (tmode, t1ref);
  t2ref = build_vconvert (tmode, t2ref);
 
diff --git a/gcc/testsuite/gdc.dg/torture/pr114171.d 
b/gcc/testsuite/gdc.dg/torture/pr114171.d
new file mode 100644
index 000..0f9ffcab916
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/torture/pr114171.d
@@ -0,0 +1,29 @@
+// { dg-do run }
+// { dg-additional-options "-mavx" { target avx_runtime } }
+// { dg-skip-if "needs gcc/config.d" { ! d_runtime } }
+import gcc.builtins;
+
+struct S1
+{
+string label;
+}
+
+struct S2
+{
+ulong pad;
+S1 label;
+}
+
+pragma(inline, false)
+auto newitem()
+{
+void *p = __builtin_malloc(S2.sizeof);
+__builtin_memset(p, 0, S2.sizeof);
+return cast(S2*) p;
+}
+
+int main()
+{
+auto bn = newitem();
+return bn.label is S1.init ? 0 : 1;
+}
-- 
2.40.1

[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.

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

[Iain Buclaw]

Hi,

This patch backports a fix to code generation when passing objects by
invisible reference that have a defined cpctor or dtor.

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.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, backported
to releases/gcc-13, releases/gcc-12, and releases/gcc-11.

Regards,
Iain.

---
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)
---
 gcc/d/d-codegen.cc  | 15 +++
 gcc/d/decl.cc   | 22 --
 gcc/testsuite/gdc.dg/torture/pr113758.d | 19 +++
 3 files changed, 50 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/torture/pr113758.d

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 8fe659ad527..b8e4b83d2de 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -2213,10 +2213,17 @@ d_build_call (TypeFunction *tf, tree callable, tree 
object,
  Type *t = arg->type->toBasetype ();
  StructDeclaration *sd = t->baseElemOf ()->isTypeStruct ()->sym;
 
- /* Nested structs also have ADDRESSABLE set, but if the type has
-neither a copy constructor nor a destructor available, then we
-need to take care of copying its value before passing it.  */
- if (arg->op == EXP::structLiteral || (!sd->postblit && !sd->dtor))
+ /* Need to take care of copying its value before passing the
+argument in the following scenarios:
+- The argument is a literal expression; a CONSTRUCTOR can't
+have its address taken.
+- The type has neither a copy constructor nor a destructor
+available; nested structs also have ADDRESSABLE set.
+- The ABI of the function expects the callee to destroy its
+arguments; when the caller is handles destruction, then `targ'
+has already been made into a temporary. */
+ if (arg->op == EXP::structLiteral || (!sd->postblit && !sd->dtor)
+ || target.isCalleeDestroyingArgs (tf))
targ = force_target_expr (targ);
 
  targ = convert (build_reference_type (TREE_TYPE (targ)),
diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 0375ede082b..2a135b516aa 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -860,10 +860,28 @@ public:
/* Maybe put variable on list of things needing destruction.  */
if (d->needsScopeDtor ())
  {
+   /* Rewrite: `decl = exp' => TARGET_EXPR(decl, exp, dtor).  */
vec_safe_push (d_function_chain->vars_in_scope, decl);
+
/* Force a TARGET_EXPR to add the corresponding cleanup.  */
-   exp = force_target_expr (compound_expr (exp, decl));
-   TARGET_EXPR_CLEANUP (exp) = build_expr (d->edtor);
+   if (TREE_CODE (exp) != TARGET_EXPR)
+ {
+   if (VOID_TYPE_P (TREE_TYPE (exp)))
+ exp = compound_expr (exp, decl);
+
+   exp = force_target_expr (exp);
+ }
+
+   TARGET_EXPR_CLEANUP (exp)
+ = compound_expr (TARGET_EXPR_CLEANUP (exp),
+  build_expr (d->edtor));
+
+   /* The decl is really an alias for the TARGET_EXPR slot.  */
+   SET_DECL_VALUE_EXPR (decl, TARGET_EXPR_SLOT (exp));
+   DECL_HAS_VALUE_EXPR_P (decl) = 1;
+   /* This tells the gimplifier not to emit a clobber for the decl
+  as its lifetime ends when the slot gets cleaned up.  */
+   TREE_ADDRESSABLE (decl) = 0;
  }
 
add_stmt (exp);
diff --git a/gcc/testsuite/gdc.dg/torture/pr113758.d 
b/gcc/testsuite/gdc.dg/torture/pr113758.d
new file mode 100644
index 000..dc53883a8de
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/torture/pr113758.d
@@ -0,0 +1,19 @@
+// { dg-do run }
+// { dg-skip-if "needs gcc/config.d" { ! d_runtime 

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

[Iain Buclaw]

Hi,

This patch backports an ICE triggered in the D front-end.

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

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, backported
to releases/gcc-13, releases/gcc-12, and releases/gcc-11.

Regards,
Iain.

---
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)
---
 gcc/d/types.cc  | 5 +
 gcc/testsuite/gdc.dg/imports/pr113125.d | 2 ++
 gcc/testsuite/gdc.dg/pr113125.d | 4 
 3 files changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/gdc.dg/imports/pr113125.d
 create mode 100644 gcc/testsuite/gdc.dg/pr113125.d

diff --git a/gcc/d/types.cc b/gcc/d/types.cc
index f19779fec7d..05050f9edd0 100644
--- a/gcc/d/types.cc
+++ b/gcc/d/types.cc
@@ -1230,6 +1230,11 @@ public:
apply_user_attributes (t->sym, t->ctype);
finish_aggregate_type (structsize, alignsize, t->ctype);
   }
+else
+  {
+   build_type_decl (t->ctype, t->sym);
+   apply_user_attributes (t->sym, t->ctype);
+  }
 
 /* For structs with a user defined postblit, copy constructor, or a
destructor, also set TREE_ADDRESSABLE on the type and all variants.
diff --git a/gcc/testsuite/gdc.dg/imports/pr113125.d 
b/gcc/testsuite/gdc.dg/imports/pr113125.d
new file mode 100644
index 000..761e613b055
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/imports/pr113125.d
@@ -0,0 +1,2 @@
+module imports.pr113125;
+struct S113125;
diff --git a/gcc/testsuite/gdc.dg/pr113125.d b/gcc/testsuite/gdc.dg/pr113125.d
new file mode 100644
index 000..cb7300baa1a
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr113125.d
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options "-I $srcdir/gdc.dg" }
+module pr113125;
+import imports.pr113125: S113125;
-- 
2.40.1

[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=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.

gcc-13-20240302 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-13 revision 96e6576a1ba0080e70fef4a6f9cc3129fcf6f008

You'll find:

 gcc-13-20240302.tar.xz   Complete GCC

  SHA256=58699cc427a25fd8c702f515b7786c969cb8732dd64b1bdcc5960cce3c81cca1
  SHA1=f10fb89da1bf094be934014dec04584b8138a8b1

Diffs from 13-20240224 are available in the diffs/ subdirectory.

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

[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.

libbacktrace patch committed: Link test programs with -no-install

[Ian Lance Taylor]

Some of the libbacktrace tests link a program and then modify the
debug info in some way.  When configured with --enable-shared the
linking, using libtool, generates a shell script.  That causes the
tests to fail because they can't modify the debug info of a shell
script.  This patch, originally by Jan Tojnar, pass the -no-install
flag to libtool to avoid generating a shell script.  Bootstrapped and
ran libbacktrace tests on x86_64-pc-linux-gnu.  Committed to mainline.

Ian

* Makefile.am (libbacktrace_testing_ldflags): Define.
(*_LDFLAGS): Add $(libbacktrace_testing_ldflags) for test
programs.
* Makefile.in: Regenerate
9b0d218544cd1b12bf63792c70052d2970acc69b
diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 750ed80ed05..5677ecd8865 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -106,6 +106,10 @@ check_DATA =
 # Flags to use when compiling test programs.
 libbacktrace_TEST_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) -g
 
+# Flags to use when linking test programs.
+# This avoids generating a shell script when configured with --enable-shared.
+libbacktrace_testing_ldflags = -no-install
+
 if USE_DSYMUTIL
 
 %.dSYM: %
@@ -170,54 +174,63 @@ xcoff_%.c: xcoff.c
 
 test_elf_32_SOURCES = test_format.c testlib.c
 test_elf_32_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+test_elf_32_LDFLAGS = $(libbacktrace_testing_ldflags)
 test_elf_32_LDADD = libbacktrace_noformat.la elf_32.lo
 
 BUILDTESTS += test_elf_32
 
 test_elf_64_SOURCES = test_format.c testlib.c
 test_elf_64_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+test_elf_64_LDFLAGS = $(libbacktrace_testing_ldflags)
 test_elf_64_LDADD = libbacktrace_noformat.la elf_64.lo
 
 BUILDTESTS += test_elf_64
 
 test_macho_SOURCES = test_format.c testlib.c
 test_macho_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+test_macho_LDFLAGS = $(libbacktrace_testing_ldflags)
 test_macho_LDADD = libbacktrace_noformat.la macho.lo
 
 BUILDTESTS += test_macho
 
 test_xcoff_32_SOURCES = test_format.c testlib.c
 test_xcoff_32_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+test_xcoff_32_LDFLAGS = $(libbacktrace_testing_ldflags)
 test_xcoff_32_LDADD = libbacktrace_noformat.la xcoff_32.lo
 
 BUILDTESTS += test_xcoff_32
 
 test_xcoff_64_SOURCES = test_format.c testlib.c
 test_xcoff_64_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+test_xcoff_64_LDFLAGS = $(libbacktrace_testing_ldflags)
 test_xcoff_64_LDADD = libbacktrace_noformat.la xcoff_64.lo
 
 BUILDTESTS += test_xcoff_64
 
 test_pecoff_SOURCES = test_format.c testlib.c
 test_pecoff_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+test_pecoff_LDFLAGS = $(libbacktrace_testing_ldflags)
 test_pecoff_LDADD = libbacktrace_noformat.la pecoff.lo
 
 BUILDTESTS += test_pecoff
 
 test_unknown_SOURCES = test_format.c testlib.c
 test_unknown_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+test_unknown_LDFLAGS = $(libbacktrace_testing_ldflags)
 test_unknown_LDADD = libbacktrace_noformat.la unknown.lo
 
 BUILDTESTS += test_unknown
 
 unittest_SOURCES = unittest.c testlib.c
 unittest_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+unittest_LDFLAGS = $(libbacktrace_testing_ldflags)
 unittest_LDADD = libbacktrace.la
 
 BUILDTESTS += unittest
 
 unittest_alloc_SOURCES = $(unittest_SOURCES)
 unittest_alloc_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+unittest_alloc_LDFLAGS = $(libbacktrace_testing_ldflags)
 unittest_alloc_LDADD = libbacktrace_alloc.la
 
 BUILDTESTS += unittest_alloc
@@ -253,7 +266,7 @@ if HAVE_OBJCOPY_DEBUGLINK
 
 b2test_SOURCES = $(btest_SOURCES)
 b2test_CFLAGS = $(libbacktrace_TEST_CFLAGS)
-b2test_LDFLAGS = -Wl,--build-id
+b2test_LDFLAGS = -Wl,--build-id $(libbacktrace_testing_ldflags)
 b2test_LDADD = libbacktrace_elf_for_test.la
 
 check_PROGRAMS += b2test
@@ -263,7 +276,7 @@ if HAVE_DWZ
 
 b3test_SOURCES = $(btest_SOURCES)
 b3test_CFLAGS = $(libbacktrace_TEST_CFLAGS)
-b3test_LDFLAGS = -Wl,--build-id
+b3test_LDFLAGS = -Wl,--build-id $(libbacktrace_testing_ldflags)
 b3test_LDADD = libbacktrace_elf_for_test.la
 
 check_PROGRAMS += b3test
@@ -277,6 +290,7 @@ endif HAVE_ELF
 
 btest_SOURCES = btest.c testlib.c
 btest_CFLAGS = $(libbacktrace_TEST_CFLAGS) -O
+btest_LDFLAGS = $(libbacktrace_testing_ldflags)
 btest_LDADD = libbacktrace.la
 
 BUILDTESTS += btest
@@ -289,6 +303,7 @@ if HAVE_ELF
 
 btest_lto_SOURCES = btest.c testlib.c
 btest_lto_CFLAGS = $(libbacktrace_TEST_CFLAGS) -O -flto
+btest_lto_LDFLAGS = $(libbacktrace_testing_ldflags)
 btest_lto_LDADD = libbacktrace.la
 
 BUILDTESTS += btest_lto
@@ -297,6 +312,7 @@ endif HAVE_ELF
 
 btest_alloc_SOURCES = $(btest_SOURCES)
 btest_alloc_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+btest_alloc_LDFLAGS = $(libbacktrace_testing_ldflags)
 btest_alloc_LDADD = libbacktrace_alloc.la
 
 BUILDTESTS += btest_alloc
@@ -331,6 +347,7 @@ endif HAVE_DWZ
 
 stest_SOURCES = stest.c
 stest_CFLAGS = $(libbacktrace_TEST_CFLAGS)
+stest_LDFLAGS = $(libbacktrace_testing_ldflags)
 stest_LDADD = libbacktrace.la
 
 BUILDTESTS += stest
@@ -341,6 +358,7 @@ endif USE_DSYMUTIL
 
 stest_alloc_SOURCES = $(stest_SOURCES)
 stest_alloc_CFLAGS = $(libbacktrace_TEST_CFLAGS)

[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.

libbacktrace patch committed: Skip all LZMA block header padding bytes

[Ian Lance Taylor]

This patch to libbacktrace corrects the LZMA block header parsing to
skip all the padding bytes, verifying that they are zero.  This fixes
https://github.com/ianlancetaylor/libbacktrace/issues/118.
Bootstrapped and ran libbacktrace tests on x86_64-pc-linux-gnu.  I was
able to verify that the problem occurred when setting the environment
variable XZ_OPT="--threads=2", and that this patch fixes the bug.
Committed to mainline.

Ian

* elf.c (elf_uncompress_lzma_block): Skip all header padding bytes
and verify that they are zero.
23f9fbed3c97ed70d2615d7d3fa7c249cc862553
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index f4527e2477d..7841c86cd9c 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -5568,6 +5568,7 @@ elf_uncompress_lzma_block (const unsigned char 
*compressed,
   uint64_t header_compressed_size;
   uint64_t header_uncompressed_size;
   unsigned char lzma2_properties;
+  size_t crc_offset;
   uint32_t computed_crc;
   uint32_t stream_crc;
   size_t uncompressed_offset;
@@ -5671,19 +5672,20 @@ elf_uncompress_lzma_block (const unsigned char 
*compressed,
   /* The properties describe the dictionary size, but we don't care
  what that is.  */
 
-  /* Block header padding.  */
-  if (unlikely (off + 4 > compressed_size))
+  /* Skip to just before CRC, verifying zero bytes in between.  */
+  crc_offset = block_header_offset + block_header_size - 4;
+  if (unlikely (crc_offset + 4 > compressed_size))
 {
   elf_uncompress_failed ();
   return 0;
 }
-
-  off = (off + 3) &~ (size_t) 3;
-
-  if (unlikely (off + 4 > compressed_size))
+  for (; off < crc_offset; off++)
 {
-  elf_uncompress_failed ();
-  return 0;
+  if (compressed[off] != 0)
+   {
+ elf_uncompress_failed ();
+ return 0;
+   }
 }
 
   /* Block header CRC.  */

Re: ☠ Buildbot (Sourceware): gccrust - failed compile (failure) (master)

[Mark Wielaard]

Hi,

On Fri, Mar 01, 2024 at 11:24:00AM +0100, Arthur Cohen wrote:
> On 2/29/24 21:22, Mark Wielaard wrote:
> >I think what needs to happen is have a config check for the minimum
> >versions of cargo and rustc that are now needed for when configuring
> >for --enable-languages=rust.
> 
> Yes - sorry about that. I will spend some time trying to make it
> nice for the builders and users overall but I am currently trying to
> finish the implementation of format_args!() in time for 14.1. So
> this will take me a little bit of time.

So when you use --enable-languages=ada it says:
configure: error: GNAT is required to build ada

And with --enable-languages=d:
configure: error: GDC is required to build d

That comes from this bit in the top-level configure.ac:

# Disable Ada if no preexisting GNAT is available.
case ${add_this_lang}:${language}:${have_gnat} in
  yes:ada:no)
# Specifically requested language; tell them.
AC_MSG_ERROR([GNAT is required to build $language])
;;
  all:ada:no)
AC_MSG_WARN([GNAT is required to build $language])
add_this_lang=unsupported
;;
  *:ada:no)
# Silently disable.
add_this_lang=unsupported
;;
esac

# Disable D if no preexisting GDC is available.
case ${add_this_lang}:${language}:${have_gdc} in
  yes:d:no)
# Specifically requested language; tell them.
AC_MSG_ERROR([GDC is required to build $language])
   ;;
  all:d:no)
AC_MSG_WARN([GDC is required to build $language])
add_this_lang=unsupported
;;
  *:d:no)
# Silently disable.
add_this_lang=unsupported
;;
esac

have_gnat and have_gdc are set by ACX_PROG_GNAT and ACX_PROG_GDC
defined in config/acx.m4 and called earlier in configure.ac.

Cheers,

Mark

[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=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)
{

Re: [PATCH 01/11] gcc/doc/extend.texi: Sort built-in traits alphabetically

[Ken Matsui]

Hi Dr. Brown,

Sorry for forgetting to CC you.  Could you please review my patch
series when you get a chance?  This patch series adds documentation
only for built-ins I implemented.  To minimize git conflicts, I will
add documentation updates to my existing patches after this patch
series gets merged.  After that, I will try to add documentation to
missing built-ins that I did not implement.

Thank you!

Sincerely,
Ken Matsui

On Fri, Mar 1, 2024 at 4:23 PM Ken Matsui  wrote:
>
> This patch sorts built-in traits alphabetically for better codebase
> consistency and easier future integration of changes.
>
> gcc/ChangeLog:
>
> * doc/extend.texi (Type Traits): Sort built-in traits
> alphabetically.
>
> Signed-off-by: Ken Matsui 
> ---
>  gcc/doc/extend.texi | 62 ++---
>  1 file changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index f679c81acf2..b13f9d6f934 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -29499,15 +29499,6 @@ Requires: @var{type} shall be a complete type, 
> (possibly cv-qualified)
>  @code{void}, or an array of unknown bound.
>  @enddefbuiltin
>
> -@defbuiltin{bool __has_nothrow_copy (@var{type})}
> -If @code{__has_trivial_copy (type)} is @code{true} then the trait is
> -@code{true}, else if @var{type} is a cv-qualified class or union type
> -with copy constructors that are known not to throw an exception then
> -the trait is @code{true}, else it is @code{false}.
> -Requires: @var{type} shall be a complete type, (possibly cv-qualified)
> -@code{void}, or an array of unknown bound.
> -@enddefbuiltin
> -
>  @defbuiltin{bool __has_nothrow_constructor (@var{type})}
>  If @code{__has_trivial_constructor (type)} is @code{true} then the trait
>  is @code{true}, else if @var{type} is a cv class or union type (or array
> @@ -29517,6 +29508,15 @@ Requires: @var{type} shall be a complete type, 
> (possibly cv-qualified)
>  @code{void}, or an array of unknown bound.
>  @enddefbuiltin
>
> +@defbuiltin{bool __has_nothrow_copy (@var{type})}
> +If @code{__has_trivial_copy (type)} is @code{true} then the trait is
> +@code{true}, else if @var{type} is a cv-qualified class or union type
> +with copy constructors that are known not to throw an exception then
> +the trait is @code{true}, else it is @code{false}.
> +Requires: @var{type} shall be a complete type, (possibly cv-qualified)
> +@code{void}, or an array of unknown bound.
> +@enddefbuiltin
> +
>  @defbuiltin{bool __has_trivial_assign (@var{type})}
>  If @var{type} is @code{const}- qualified or is a reference type then
>  the trait is @code{false}.  Otherwise if @code{__is_trivial (type)} is
> @@ -29527,15 +29527,6 @@ Requires: @var{type} shall be a complete type, 
> (possibly cv-qualified)
>  @code{void}, or an array of unknown bound.
>  @enddefbuiltin
>
> -@defbuiltin{bool __has_trivial_copy (@var{type})}
> -If @code{__is_trivial (type)} is @code{true} or @var{type} is a reference
> -type then the trait is @code{true}, else if @var{type} is a cv class
> -or union type with a trivial copy constructor ([class.copy]) then the trait
> -is @code{true}, else it is @code{false}.  Requires: @var{type} shall be
> -a complete type, (possibly cv-qualified) @code{void}, or an array of unknown
> -bound.
> -@enddefbuiltin
> -
>  @defbuiltin{bool __has_trivial_constructor (@var{type})}
>  If @code{__is_trivial (type)} is @code{true} then the trait is @code{true},
>  else if @var{type} is a cv-qualified class or union type (or array thereof)
> @@ -29545,6 +29536,15 @@ Requires: @var{type} shall be a complete type, 
> (possibly cv-qualified)
>  @code{void}, or an array of unknown bound.
>  @enddefbuiltin
>
> +@defbuiltin{bool __has_trivial_copy (@var{type})}
> +If @code{__is_trivial (type)} is @code{true} or @var{type} is a reference
> +type then the trait is @code{true}, else if @var{type} is a cv class
> +or union type with a trivial copy constructor ([class.copy]) then the trait
> +is @code{true}, else it is @code{false}.  Requires: @var{type} shall be
> +a complete type, (possibly cv-qualified) @code{void}, or an array of unknown
> +bound.
> +@enddefbuiltin
> +
>  @defbuiltin{bool __has_trivial_destructor (@var{type})}
>  If @code{__is_trivial (type)} is @code{true} or @var{type} is a reference 
> type
>  then the trait is @code{true}, else if @var{type} is a cv class or union
> @@ -29560,6 +29560,13 @@ If @var{type} is a class type with a virtual 
> destructor
>  Requires: If @var{type} is a non-union class type, it shall be a complete 
> type.
>  @enddefbuiltin
>
> +@defbuiltin{bool __integer_pack (@var{length})}
> +When used as the pattern of a pack expansion within a template
> +definition, expands to a template argument pack containing integers
> +from @code{0} to @code{@var{length}-1}.  This is provided for
> +efficient implementation of @code{std::make_integer_sequence}.
> +@enddefbuiltin
> +
>  @defbuiltin{bool __is_abstract 

[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.

Play with your friends or sleep

[Tricia Rowland via Gcc]

Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64

[Jonathan Yong]

On 2/15/24 14:08, Jonathan Yong wrote:

Attached patch OK?

Copy/pasted for review convenience.

Ping.

[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=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)

[PATCH v2] gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]

[Ken Matsui]

This patch adds a warning switch for "#pragma once in main file".  The
warning option name is Wpragma-once-outside-header, which is the same
as Clang.

PR preprocessor/89808

gcc/c-family/ChangeLog:

* c-opts.cc (c_common_handle_option): Handle
OPT_Wpragma_once_outside_header.
* c.opt (Wpragma_once_outside_header): Define new option.

gcc/ChangeLog:

* doc/invoke.texi (Warning Options): Document
-Wno-pragma-once-outside-header.

libcpp/ChangeLog:

* include/cpplib.h (struct cpp_options): Define
cpp_warn_pragma_once_outside_header.
* directives.cc (do_pragma_once): Use
cpp_warn_pragma_once_outside_header.
* init.cc (cpp_create_reader): Handle
cpp_warn_pragma_once_outside_header.

gcc/testsuite/ChangeLog:

* g++.dg/Wpragma-once-outside-header.C: New test.
* g++.dg/warn/Wno-pragma-once-outside-header.C: New test.
* g++.dg/warn/Wpragma-once-outside-header.C: New test.

Signed-off-by: Ken Matsui 
---
 gcc/c-family/c-opts.cc |  9 +
 gcc/c-family/c.opt |  4 
 gcc/doc/invoke.texi| 10 --
 gcc/testsuite/g++.dg/Wpragma-once-outside-header.C |  5 +
 .../g++.dg/warn/Wno-pragma-once-outside-header.C   |  5 +
 .../g++.dg/warn/Wpragma-once-outside-header.C  |  5 +
 libcpp/directives.cc   |  8 ++--
 libcpp/include/cpplib.h|  4 
 libcpp/init.cc |  1 +
 9 files changed, 47 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/Wpragma-once-outside-header.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wno-pragma-once-outside-header.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wpragma-once-outside-header.C

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index be3058dca63..4edd8c6c515 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -430,6 +430,15 @@ c_common_handle_option (size_t scode, const char *arg, 
HOST_WIDE_INT value,
   cpp_opts->warn_num_sign_change = value;
   break;
 
+case OPT_Wpragma_once_outside_header:
+  if (value == 0)
+   cpp_opts->cpp_warn_pragma_once_outside_header = 0;
+  else if (kind == DK_ERROR)
+   cpp_opts->cpp_warn_pragma_once_outside_header = 2;
+  else
+   cpp_opts->cpp_warn_pragma_once_outside_header = 1;
+  break;
+
 case OPT_Wunknown_pragmas:
   /* Set to greater than 1, so that even unknown pragmas in
 system headers will be warned about.  */
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index b7a4a1a68e3..6841a5a5e81 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1180,6 +1180,10 @@ Wpragmas
 C ObjC C++ ObjC++ Var(warn_pragmas) Init(1) Warning
 Warn about misuses of pragmas.
 
+Wpragma-once-outside-header
+C ObjC C++ ObjC++ Var(warn_pragma_once_outside_header) Init(1) Warning
+Warn about #pragma once outside of a header.
+
 Wprio-ctor-dtor
 C ObjC C++ ObjC++ Var(warn_prio_ctor_dtor) Init(1) Warning
 Warn if constructor or destructors with priorities from 0 to 100 are used.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index bdf05be387d..eeb8954bcdf 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -391,8 +391,8 @@ Objective-C and Objective-C++ Dialects}.
 -Wpacked  -Wno-packed-bitfield-compat  -Wpacked-not-aligned  -Wpadded
 -Wparentheses  -Wno-pedantic-ms-format
 -Wpointer-arith  -Wno-pointer-compare  -Wno-pointer-to-int-cast
--Wno-pragmas  -Wno-prio-ctor-dtor  -Wredundant-decls
--Wrestrict  -Wno-return-local-addr  -Wreturn-type
+-Wno-pragmas  -Wno-pragma-once-outside-header  -Wno-prio-ctor-dtor
+-Wredundant-decls  -Wrestrict  -Wno-return-local-addr  -Wreturn-type
 -Wno-scalar-storage-order  -Wsequence-point
 -Wshadow  -Wshadow=global  -Wshadow=local  -Wshadow=compatible-local
 -Wno-shadow-ivar
@@ -7955,6 +7955,12 @@ Do not warn about misuses of pragmas, such as incorrect 
parameters,
 invalid syntax, or conflicts between pragmas.  See also
 @option{-Wunknown-pragmas}.
 
+@opindex Wno-pragma-once-outside-header
+@opindex Wpragma-once-outside-header
+@item -Wno-pragma-once-outside-header
+Do not warn when @code{#pragma once} is used in a file that is not a header
+file, such as a main file.
+
 @opindex Wno-prio-ctor-dtor
 @opindex Wprio-ctor-dtor
 @item -Wno-prio-ctor-dtor
diff --git a/gcc/testsuite/g++.dg/Wpragma-once-outside-header.C 
b/gcc/testsuite/g++.dg/Wpragma-once-outside-header.C
new file mode 100644
index 000..678bd4e7626
--- /dev/null
+++ b/gcc/testsuite/g++.dg/Wpragma-once-outside-header.C
@@ -0,0 +1,5 @@
+/* { dg-do assemble  } */
+/* { dg-options "-Werror=pragma-once-outside-header" } */
+
+#pragma once  // { dg-error "#pragma once in main file" }
+int main() {}
diff --git a/gcc/testsuite/g++.dg/warn/Wno-pragma-once-outside-header.C 

[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.

[patch,avr,applied] Avoid magic numbers for register numbers.

[Georg-Johann Lay]

There are some places where avr.cc uses magic numbers like 17 that
are actually register numbers.  This patch defines constants like
REG_17 and uses them instead of the magic numbers when a register
number is meant.

Johann

--

AVR: Use REG_ constants instead of magic numbers .

There are some places where avr.cc uses magic numbers like 17 that
are actually register numbers.  This patch defines constants like
REG_17 and uses them instead of the magic numbers when a register
number is meant.

gcc/
* config/avr/avr.md (REG_0, ... REG_36): New define_constants.
* config/avr/avr.cc: Use them instead of magic numbers when it
means a register number.
diff --git a/gcc/config/avr/avr.cc b/gcc/config/avr/avr.cc
index e312ddfbff4..5c71c7f8c0d 100644
--- a/gcc/config/avr/avr.cc
+++ b/gcc/config/avr/avr.cc
@@ -171,10 +171,10 @@ static bool avr_rtx_costs (rtx, machine_mode, int, int, int *, bool);
 
 
 /* Allocate registers from r25 to r8 for parameters for function calls.  */
-#define FIRST_CUM_REG 26
+#define FIRST_CUM_REG REG_26
 
 /* Last call saved register */
-#define LAST_CALLEE_SAVED_REG (AVR_TINY ? 19 : 17)
+#define LAST_CALLEE_SAVED_REG (AVR_TINY ? REG_19 : REG_17)
 
 /* Implicit target register of LPM instruction (R0) */
 extern GTY(()) rtx lpm_reg_rtx;
@@ -197,8 +197,8 @@ extern GTY(()) rtx cc_reg_rtx;
 rtx cc_reg_rtx;
 
 /* RTXs for all general purpose registers as QImode */
-extern GTY(()) rtx all_regs_rtx[32];
-rtx all_regs_rtx[32];
+extern GTY(()) rtx all_regs_rtx[REG_32];
+rtx all_regs_rtx[REG_32];
 
 /* SREG, the processor status */
 extern GTY(()) rtx sreg_rtx;
@@ -542,7 +542,7 @@ avr_casei_sequence_check_operands (rtx *xop)
 
   if (AVR_HAVE_EIJMP_EICALL
   // The last clobber op of the tablejump.
-  && xop[8] == all_regs_rtx[24])
+  && xop[8] == all_regs_rtx[REG_24])
 {
   // $6 is: (subreg:SI ($5) 0)
   sub_5 = xop[6];
@@ -1171,7 +1171,7 @@ avr_init_machine_status (void)
 void
 avr_init_expanders (void)
 {
-  for (int regno = 0; regno < 32; regno ++)
+  for (int regno = REG_0; regno < REG_32; regno ++)
 all_regs_rtx[regno] = gen_rtx_REG (QImode, regno);
 
   lpm_reg_rtx  = all_regs_rtx[LPM_REGNO];
@@ -1549,7 +1549,7 @@ avr_regs_to_save (HARD_REG_SET *set)
   || cfun->machine->is_OS_main)
 return 0;
 
-  for (int reg = 0; reg < 32; reg++)
+  for (int reg = REG_0; reg < REG_32; reg++)
 {
   /* Do not push/pop __tmp_reg__, __zero_reg__, as well as
 	 any global register variables.  */
@@ -2300,9 +2300,9 @@ avr_pass_fuse_add::execute (function *func)
 
   FOR_EACH_BB_FN (bb, func)
 {
-  Ldi_Insn prev_ldi_insns[32];
-  Add_Insn prev_add_insns[32];
-  Mem_Insn prev_mem_insns[32];
+  Ldi_Insn prev_ldi_insns[REG_32];
+  Add_Insn prev_add_insns[REG_32];
+  Mem_Insn prev_mem_insns[REG_32];
   rtx_insn *insn, *curr;
 
   avr_dump ("\n;; basic block %d\n\n", bb->index);
@@ -2484,7 +2484,7 @@ avr_incoming_return_addr_rtx (void)
 static int
 avr_hregs_split_reg (HARD_REG_SET *set)
 {
-  for (int regno = 0; regno < 32; regno++)
+  for (int regno = REG_0; regno < REG_32; regno++)
 if (TEST_HARD_REG_BIT (*set, regno))
   {
 	// Don't remove a register from *SET which might indicate that
@@ -2620,9 +2620,9 @@ avr_prologue_setup_frame (HOST_WIDE_INT size, HARD_REG_SET set)
 
   first_reg = (LAST_CALLEE_SAVED_REG + 1) - (live_seq - 2);
 
-  for (reg = 29, offset = -live_seq + 1;
+  for (reg = REG_29, offset = -live_seq + 1;
 	   reg >= first_reg;
-	   reg = (reg == 28 ? LAST_CALLEE_SAVED_REG : reg - 1), ++offset)
+	   reg = (reg == REG_28 ? LAST_CALLEE_SAVED_REG : reg - 1), ++offset)
 	{
 	  rtx m, r;
 
@@ -2636,7 +2636,7 @@ avr_prologue_setup_frame (HOST_WIDE_INT size, HARD_REG_SET set)
 }
   else /* !minimize */
 {
-  for (int reg = 0; reg < 32; ++reg)
+  for (int reg = REG_0; reg < REG_32; ++reg)
 	if (TEST_HARD_REG_BIT (set, reg))
 	  emit_push_byte (reg, true);
 
@@ -3795,7 +3795,7 @@ avr_print_operand (FILE *file, rtx x, int code)
 {
   if (x == zero_reg_rtx)
 	fprintf (file, "__zero_reg__");
-  else if (code == 'r' && REGNO (x) < 32)
+  else if (code == 'r' && REGNO (x) < REG_32)
 	fprintf (file, "%d", (int) REGNO (x));
   else
 	fprintf (file, "%s", reg_names[REGNO (x) + abcd]);
@@ -4136,7 +4136,9 @@ avr_asm_final_postscan_insn (FILE *stream, rtx_insn *insn, rtx *, int)
 int
 avr_function_arg_regno_p (int r)
 {
-  return AVR_TINY ? IN_RANGE (r, 20, 25) : IN_RANGE (r, 8, 25);
+  return AVR_TINY
+? IN_RANGE (r, REG_20, REG_25)
+: IN_RANGE (r, REG_8, REG_25);
 }
 
 
@@ -4148,7 +4150,7 @@ void
 avr_init_cumulative_args (CUMULATIVE_ARGS *cum, tree fntype, rtx libname,
 			  tree fndecl ATTRIBUTE_UNUSED)
 {
-  cum->nregs = AVR_TINY ? 6 : 18;
+  cum->nregs = 1 + AVR_TINY ? REG_25 - REG_20 : REG_25 - REG_8;
   cum->regno = FIRST_CUM_REG;
   cum->has_stack_args = 0;
   if (!libname && stdarg_p (fntype))
@@ -4216,7 +4218,7 @@ avr_function_arg_advance 

[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=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 ();

  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 = _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();
  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.

[patch,avr,applied] Take into account -mtiny-stack in frame pointer adjustments

[Georg-Johann Lay]

Applied this addendum to avr PR114100:

When the frame pointer is adjusted and -mtiny-stack is set,
then it is enough to adjust the low part of the frame pointer.

Johann

--

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.


diff --git a/gcc/config/avr/avr.cc b/gcc/config/avr/avr.cc
index 94ef7c591a9..d39d6707c97 100644
--- a/gcc/config/avr/avr.cc
+++ b/gcc/config/avr/avr.cc
@@ -8983,14 +8983,17 @@ avr_out_plus_1 (rtx *xop, int *plen, enum 
rtx_code code, int *pcc,

  && frame_pointer_needed
  && REGNO (xop[0]) == FRAME_POINTER_REGNUM)
{
- rtx xval16 = simplify_gen_subreg (HImode, xval, imode, i);
- if (xval16 == const1_rtx || xval16 == constm1_rtx)
+ if (AVR_HAVE_8BIT_SP)
+   {
+ avr_asm_len ("subi %A0,%n2", xop, plen, 1);
+ return;
+   }
+ else if (xop[2] == const1_rtx || xop[2] == constm1_rtx)
{
- avr_asm_len ((code == PLUS) == (xval16 == const1_rtx)
+ avr_asm_len (xop[2] == const1_rtx
   ? "ld __tmp_reg__,%a0+"
   : "ld __tmp_reg__,-%a0", xop, plen, 1);
- i++;
- continue;
+ return;
}
}

[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.