[Bug target/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Waterman from comment #2)
> The RISC-V code models currently in existence place a 2 GiB limit on
> the extent of the statically linked portion of a binary.  Rather than
> a bug, I would describe this as a limitation of the existing code
> models, which we should eventually lift by introducing larger code
> models.
> 
> Note that it's possible to get similar errors on other
> architecture/code model combinations.  Here's an example from x86-64
> with the "kernel" code model:
> 
> $ g++ -mcmodel=kernel -O2 riscv_cpp_test.c
> tmp/ccEm3wfH.o: In function `main':
> test.c:(.text.startup+0x20): relocation truncated to fit: R_X86_64_32S
> against `.LC0'
> collect2: error: ld returned 1 exit status

That is definitely a bug in mcmodel=kernel in the x86backenbd which is
different from the problem here even though both have same testcase.

Anyways simplified testcase:
```
const char *f()
{
  return "1" + 2147483647;
}

int main()
{}
```

[Bug target/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

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

[Bug target/114168] [RISC-V] Compiler generates impossible addend

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

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

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

[Bug target/114168] [RISC-V] Compiler generates impossible addend

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target|riscv*-*-*  |riscv64*-*-*
 Status|UNCONFIRMED |NEW
   Keywords||link-failure
   Last reconfirmed||2024-04-01

--- Comment #1 from Andrew Pinski  ---
Confirmed, reduced testcase:
```
const char *f()
{
  return "1" + 2147483647;
}

int main()
{}
```

[Bug bootstrap/105474] GCC fails to bootstrap with --disable-libstdcxx

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Something like should provided an error while configuring so much earlier:
```
case "$enable_bootstrap:${noconfigdirs}" in
  yes:*target-libstdc++-v3*)
AC_MSG_ERROR([cannot also disable libstdcxx if bootstrapping]) ;;
;;
esac

```

Let me test that out and submit it for GCC 15.

[Bug other/44574] [meta-bug] Avoid use of atoi

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

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

--- Comment #8 from Andrew Pinski  ---
> opts.c
> lto-wrapper.c
> lto/lto.c

These 3 are all about parsing of -flto=N option; PR 114542

[Bug lto/114542] New: -flto=4294967296 is treated the same as -flto=0 and -flto=4294967297 is treated the same as -flto=1 instead of being invalid options

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

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

Bug ID: 114542
   Summary: -flto=4294967296 is treated the same as -flto=0 and
-flto=4294967297 is treated the same as -flto=1
instead of being invalid options
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 44574
  Target Milestone: ---

Due to the uses of atoi in opts.c, lto-wrapper.c and lto/lto.c,
`-flto=4294967297` is treated as `-flto=1` 

Plus `-flto=429496729b` is treated as being allowed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574
[Bug 44574] [meta-bug] Avoid use of atoi

[Bug other/44574] [meta-bug] Avoid use of atoi

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

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

--- Comment #7 from Andrew Pinski  ---
>read-rtl-function.c

Someone most likely can come up with a testcase for this one using the RTL
parser.

[Bug other/44574] [meta-bug] Avoid use of atoi

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Avoid use of atoi   |[meta-bug] Avoid use of
   ||atoi
   Keywords||meta-bug

--- Comment #6 from Andrew Pinski  ---
>c/gimple-parser.c

PR  114541 since I found a testcase .

This is turning into a meta-bug so let's turn it into a full one then.

[Bug c/114541] New: Invalid gimple __BB# accepted due to usage of atoi

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

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

Bug ID: 114541
   Summary: Invalid gimple __BB# accepted due to usage of atoi
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 44574, 101057
  Target Milestone: ---

Take:
```

/* { dg-do compile } */
/* { dg-options "-O -fgimple" } */

void __GIMPLE (ssa,startwith ("dse2")) foo ()
{
  int a;

__BB(2):
  if (a_5(D) > 4)
goto __BB4294967299;
  else
goto __BB4;

__BB(3):
  a_2 = 10;
  goto __BB5;

__BB(4):
  a_3 = 20;
  goto __BB5;

__BB(5):
  a_1 = __PHI (__BB3: a_2, __BB4: a_3);
  a_4 = a_1 + 4;

return;
}

```

This is invalid gimple but the use of atoi in c_parser_gimple_parse_bb_spec
(c/gimple-parser.cc) allows to accept it.

Note also causes ICE if you put any invalid character after the number due to
use of BB 1 at that point (I think).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574
[Bug 44574] Avoid use of atoi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057
[Bug 101057] [gimplefe] GIMPLE frontend issues

[Bug other/44574] Avoid use of atoi

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

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

--- Comment #5 from Andrew Pinski  ---
Note I filed PR 114540 for the usage in varasm.cc (decode_reg_name_and_count) 
as you can come up with a few testcases where we don't reject invalid registers
# when we should.

[Bug middle-end/114540] New: Use of atoi allows invalid registers

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

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

Bug ID: 114540
   Summary: Use of atoi allows invalid registers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 44574
  Target Milestone: ---

varasm.cc (decode_reg_name_and_count) uses atoi which means it can allow some
invalid code through testcase:
```
void f()
{
asm("":::"4294967296");
}
register int a asm("4294967296");
``` 
also Options: `-fstack-limit-register=4294967296 -ffixed-4294967296`.

Filed seperately from PR 44574 so it can be tracked seperately.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574
[Bug 44574] Avoid use of atoi

[Bug bootstrap/88321] Crosscompiled gcc does not use preinstalled as

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

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

--- Comment #3 from Andrew Pinski  ---
The place where gcc usually finds the cross assembler/linker is
aarch64-linux-gnu/bin/ rather than via the cross name unless you supply
--with-as .
Though I wonder if this should change ...

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #10 from Xi Ruoyao  ---
So fixed for all branches.

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

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

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

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

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

commit r12-10303-gbf0b32d7929f8b4b15b21658d572b89ded03d8f8
Author: Lulu Cheng 
Date:   Fri Mar 15 16:41:20 2024 +0800

LoongArch: gcc12: Implement option save/restore.

LTO option streaming and target attributes both require per-function
target configuration, which is achieved via option save/restore.

We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
context in addition to other automatically maintained option states
(via the "Save" option property in the .opt files).

PR target/113233

gcc/ChangeLog:

* config/loongarch/genopts/loongarch.opt.in: Mark options with
the "Save" property.
* config/loongarch/loongarch-opts.cc
(loongarch_update_gcc_opt_status): Update the value of the
la_target to global_options.
* config/loongarch/loongarch-opts.h
(loongarch_update_gcc_opt_status): Add a function declaration.
* config/loongarch/loongarch.cc
(loongarch_option_override_internal): Call the function
loongarch_update_gcc_opt_status.
(loongarch_option_save): New functions.
(loongarch_option_restore): Likewise.
(TARGET_OPTION_SAVE): Define macro.
(TARGET_OPTION_RESTORE): Likewise.
* config/loongarch/loongarch.opt: Regenerate.

(cherry picked from commit ea2a9c76a1dcffbbec6e53655bef9236d3a8e691)

[Bug target/113233] LoongArch: target options from LTO objects not respected during linking

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

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

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

https://gcc.gnu.org/g:4736b317047ae6b04f7609843f21cb68fef6a0c1

commit r13-8545-g4736b317047ae6b04f7609843f21cb68fef6a0c1
Author: Lulu Cheng 
Date:   Fri Mar 15 16:23:05 2024 +0800

LoongArch: gcc13: Implement option save/restore.

LTO option streaming and target attributes both require per-function
target configuration, which is achieved via option save/restore.

We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
context in addition to other automatically maintained option states
(via the "Save" option property in the .opt files).

PR target/113233

gcc/ChangeLog:

* config/loongarch/genopts/loongarch.opt.in: Mark options with
the "Save" property.
* config/loongarch/loongarch-opts.cc
(loongarch_update_gcc_opt_status): Update the value of the
la_target to global_options.
* config/loongarch/loongarch-opts.h
(loongarch_update_gcc_opt_status): Add a function declaration.
* config/loongarch/loongarch.cc
(loongarch_option_override_internal): Call the function
loongarch_update_gcc_opt_status.
(loongarch_option_save): New functions.
(loongarch_option_restore): Likewise.
(TARGET_OPTION_SAVE): Define macro.
(TARGET_OPTION_RESTORE): Likewise.
* config/loongarch/loongarch.opt: Regenerate.

(cherry picked from commit ea2a9c76a1dcffbbec6e53655bef9236d3a8e691)

[Bug tree-optimization/114538] constant fold for (v + 1 == 0) == (v + 1 < v) fails when v + 1 is stored in variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2024-04-01
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Note this can be expanded into non-CST even.
```
int unopt(unsigned v, unsigned t) {
unsigned n = v + t;
return (n < t) == (n < v);
}

int opt1(unsigned v, unsigned t) {
return (v + t < t) == (v + t < v);
}
```

Both are not optimized to 1.
In both cases, it is checking if `v+t` wraps (overflows).
Interesting is LLVM is not able to handle the non-CST form either.

That is it is able to handle:
```
int g(unsigned v, unsigned t) {
t = 555;
return (v + t < t) == (v + t < v);
}
```

Note the const form case is related to PR 114539 really which LLVM can handle
both cases.

[Bug tree-optimization/114539] `__builtin_add_overflow(unsigned, b, ); r < b` where b is a CST is not optimized to using the overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=114538
   Last reconfirmed||2024-04-01
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This is the current pattern that matches the non-CST case:
```
/* Testing for overflow is unnecessary if we already know the result.  */
/* A - B > A  */
(for cmp (gt le)
 out (ne eq)
 (simplify
  (cmp:c (realpart (IFN_SUB_OVERFLOW@2 @0 @1)) @0)
  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
   && types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
   (out (imagpart @2) { build_zero_cst (TREE_TYPE (@0)); }
/* A + B < A  */
(for cmp (lt ge)
 out (ne eq)
 (simplify
  (cmp:c (realpart (IFN_ADD_OVERFLOW:c@2 @0 @1)) @0)
  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
   && types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
   (out (imagpart @2) { build_zero_cst (TREE_TYPE (@0)); }
```

Mine for GCC 15.

[Bug tree-optimization/114539] New: `__builtin_add_overflow(unsigned, b, ); r < b` where b is a CST is not optimized to using the overflow

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

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

Bug ID: 114539
   Summary: `__builtin_add_overflow(unsigned, b, ); r  < b`
where b is a CST is not optimized to using the
overflow
   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:
```
bool f(unsigned v, unsigned tt)
{
 unsigned r;
 unsigned t = __builtin_add_overflow(v, tt, );
 return (r < tt) == t;
}


bool f1(unsigned v, unsigned tt)
{
 tt = 3;
 unsigned r;
 unsigned t = __builtin_add_overflow(v, tt, );
 return (r < tt) == t;
}
```

f is able to be optimized to 1 but f1 is not due to the `r < 3` being Canonical
form being `r <= 2` (or in the case of 1, `r == 0`).

I found this while looking into PR 114538 if we change things slightly.

[Bug c++/114455] [C++26] P2748R5 - Disallow binding a returned reference to a temporary

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug bootstrap/63684] Build failure due to "Let GDB reuse GCC's parser." (srcdir==objdir)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #18 from Andrew Pinski  ---
I just did a build with objdir==srcdir with `./configure` and `make -j24 ` and
it worked.

It builds libcc1 in `./host-x86_64-pc-linux-gnu/libcc1` just fine too.

I have no idea when it was fixed though.

[Bug tree-optimization/114538] New: constant fold for (v + 1 == 0) == (v + 1 < v) fails when v + 1 is stored in variable

[goon.pri.low at gmail dot com via Gcc-bugs]

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

Bug ID: 114538
   Summary: constant fold for (v + 1 == 0) == (v + 1 < v) fails
when v + 1 is stored in variable
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

int unopt(unsigned v) {
unsigned n = v + 1;
return (n == 0) == (n < v);
}

int opt(unsigned v) {
return (v + 1 == 0) == (v + 1 < v);
}

unopt:
xor edx, edx
add edi, 1
setcdl
xor eax, eax
testedi, edi
setne   al
xor eax, edx
ret

opt:
mov eax, 1
ret

[Bug bootstrap/63684] Build failure due to "Let GDB reuse GCC's parser." (srcdir==objdir)

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

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

--- Comment #17 from Andrew Pinski  ---
>  --disable-libstdcxx 

That also seems like a bad option to use too.

[Bug middle-end/39165] redundant simplify_cond in genattrtab.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|rtl-optimization|middle-end
   Last reconfirmed||2024-03-31
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed. This looks like it is still true. Though I am not sure how much this
will buy us in a bootstrap; less than a second for sure.

[Bug target/44002] need to #include unistd.h for pid_t on alpha-dec-vms

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---

POSIX defines pid_t in sys/types.h
(https://pubs.opengroup.org/onlinepubs/009604499/basedefs/sys/types.h.html)


But the way AC_TYPE_PID_T works, is pid_t if incldued in the standard
ac_includes don't define it. 

standard includes in the version of autoconf that is currently used are:
```
#ifdef HAVE_SYS_TYPES_H
# include 
#endif

#ifdef HAVE_UNISTD_H
# include 
#endif"
```

Looks like vms defines it in unistd.h from what I could find on the internet.

So confirmed. Though I am not 100% sure if building for VMS is still supported.

[Bug bootstrap/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #29 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #28)
> Can this be closed now?
> 
> Building with C++ works, because it's now required, not just optionally
> supported.

Plus a requirement of a C++11 compiler is needed so closing as fixed as it was
fixed a long time ago.

[Bug c++/114537] New: bit_cast does not work NSDMI of bitfields

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

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

Bug ID: 114537
   Summary: bit_cast does not work NSDMI of bitfields
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: FIXME
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
#include 

struct A {  signed char b:1 = 0; signed char b1:7 = 0; };

struct B { unsigned char b; };

static_assert( std::bit_cast(A{}).b == 0 );
```

This should work as the bitfields span all of the char space but currently we
get a sorry:
```
:9:40: error: non-constant condition for static assertion
9 | static_assert( std::bit_cast(A{}).b == 0 );
  |^~~~
In file included from :2:
:9:32:   in 'constexpr' expansion of 'std::bit_cast(A{0, 0})'
/opt/compiler-explorer/gcc-trunk-20240331/include/c++/14.0.1/bit:94:33: sorry,
unimplemented: '__builtin_bit_cast' cannot be constant evaluated because the
argument cannot be encoded
   94 |   return __builtin_bit_cast(_To, __from);
  | ^~~
```

I had been looking for a quick workaround for PR 114536 (for little-endian
only) but it looked like NSDMI for bitfields is not implemented fully.

[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Note you can't compare against clang though:
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.1/../../../../include/c++/14.0.1/bit:94:14:
note: constexpr bit_cast involving bit-field is not yet supported


But anyways with the padding bit.

With signed char instead of unsigned char, GCC gives:
```
/opt/compiler-explorer/gcc-trunk-20240331/include/c++/14.0.1/bit:94:33: error:
'__builtin_bit_cast' accessing uninitialized byte at offset 0

```

That is correct for that but in the case of unsigned char (or std::byte).

[Bug fortran/114535] [13/14 regression] ICE with elemental finalizer

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

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

--- Comment #3 from Andrew Benson  ---
Thanks Paul. The workaround is very helpful and lets me continue making
progress in the rest of my work for now. Thanks again!

[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Mikael Morin
:

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

commit r13-8543-gfc5c603da3c9b186308fb3afef7bcf3f3bf695e8
Author: Mikael Morin 
Date:   Thu Mar 21 17:27:54 2024 +0100

fortran: Ignore use statements on error [PR107426]

This fixes an access to freed memory on the testcase from the PR.
The problem comes from an invalid subroutine statement in an interface,
which is ignored and causes the following statements forming the procedure
body to be rejected.  One of them use-associates the intrinsic
ISO_C_BINDING
module, which imports new symbols in a namespace that is freed at the time
the statement is rejected.  However, this creates dangling pointers as
ISO_C_BINDING is special and its import creates a reference to the imported
C_PTR symbol in the return type of the global intrinsic symbol for C_LOC
(see the function create_intrinsic_function).

This change saves and restores the list of use statements, so that rejected
use statements are removed before they have a chance to be applied to the
current namespace and create dangling pointers.

PR fortran/107426

gcc/fortran/ChangeLog:

* gfortran.h (gfc_save_module_list, gfc_restore_old_module_list):
New declarations.
* module.cc (old_module_list_tail): New global variable.
(gfc_save_module_list, gfc_restore_old_module_list): New functions.
(gfc_use_modules): Set module_list and old_module_list_tail.
* parse.cc (next_statement): Save module_list before doing any
work.
(reject_statement): Restore module_list to its saved value.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr89943_3.f90: Update error pattern.
* gfortran.dg/pr89943_4.f90: Likewise.
* gfortran.dg/use_31.f90: New test.

(cherry picked from commit a44d7e8a52007c2d45217709ca02947c6600de87)

[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059

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

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

--- Comment #17 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

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

commit r13-8537-gbd760ac35d792683cd82f6b665516528fe11752a
Author: Iain Sandoe 
Date:   Sat Jan 6 10:52:38 2024 +

Darwin: Fix constant CFString code-gen [PR105522].

Although this only fires for one of the Darwin sub-ports, it is latent
elsewhere, it is also a regression c.f. the Darwin system compiler.

In the code we imported from an earlier branch, CFString objects (which
are constant aggregates) are constructed as CONST_DECLs.  Although our
current documentation suggests that these are reserved for enumeration
values, in fact they are used elsewhere in the compiler for constants.
This includes Objective-C where they are used to form NSString constants.

In the particular case, we take the address of the constant and that
triggers varasm.cc:decode_addr_constant, which does not currently support
CONST_DECL.

If there is a general intent to allow/encourage wider use of CONST_DECL,
then we should fix decode_addr_constant to look through these and evaluate
the initializer (a two-line patch, but I'm not suggesting it for stage-4).

We also need to update the GCC internals documentation to allow for the
additional uses.

This patch is Darwin-local and fixes the problem by making the CFString
constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan
to back-port this to the open branches once it has baked a while on trunk.

Since, for Darwin, the Objective-C default is to construct constant
NSString objects as CFStrings; this will also cover the majority of cases
there (this patch does not make any changes to Objective-C NSStrings).

PR target/105522

gcc/ChangeLog:

* config/darwin.cc (machopic_select_section): Handle C and C++
CFStrings.
(darwin_rename_builtins): Move this out of the CFString code.
(darwin_libc_has_function): Likewise.
(darwin_build_constant_cfstring): Create an anonymous var to
hold each CFString.
* config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant
CFstrings.

Signed-off-by: Iain Sandoe 
(cherry picked from commit aecc0d4ba73d0810334b351da1e67232cea450d3)

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #5 from Paul Thomas  ---
Hi Harald,

I am pinning this one on you since it needs backporting to 13-branch, at least.
It also keeps the audit trail clean.

Cheers

Paul

[Bug fortran/106999] [11/12/13/14 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
Created attachment 57838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57838=edit
Fix for this PR

Thanks for the report. The attached does what is required, I believe. It is
regtesting as I write.

Paul

[Bug fortran/114535] [13/14 regression] ICE with elemental finalizer

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

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

Paul Thomas  changed:

   What|Removed |Added

Summary|ICE with elemental  |[13/14 regression] ICE with
   |finalizer   |elemental finalizer

--- Comment #2 from Paul Thomas  ---
It seems to be OK with 12-branch.

It's not unlike some of the problems with your smart pointer work.

I have a couple more regressions to take care of and the, I promise, I will
turn to this one.

Paul

[Bug fortran/114535] ICE with elemental finalizer

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-31

--- Comment #1 from Paul Thomas  ---
Hi Andrew,

Confirmed.

A work around is:

module ni
  implicit none
contains
  subroutine iss()
use :: iv  ! Implies something is awry in module.cc
use :: d
return
  end subroutine iss
end module ni

Thanks for the report. I'll take it but it has been a while since I looked at
module.cc.

Regards

Paul

[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Fedor Chelnokov from comment #2)
> May be just fail constant evaluation then instead of evaluating it to 0?

Hmm, yes, it should fail to produce a constant expression.

[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields

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

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

--- Comment #4 from Jonathan Wakely  ---
The padding bit has an indeterminate value. Because the result type is an
unsigned char, the indeterminate bit does not produce undefined behaviour, but
it's not allowed in a constant expression.

I don't think this is a bug.

[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Fedor Chelnokov from comment #2)
> May be just fail constant evaluation then instead of evaluating it to 0?

I suspect gcc is not rejecting it because the struct is just one unsigned char
and it is getting confused between that and the unsigned char.

[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Fedor Chelnokov  ---
May be just fail constant evaluation then instead of evaluating it to 0?

[Bug c++/114536] wrong constant evaluation of std::bit_cast for bit fields

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

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

--- Comment #1 from Andrew Pinski  ---
So in the case of bitfields there is a padding bit(s) which are still
uninitialized and this might be undefined at runtime even.

[Bug c++/114536] New: wrong constant evaluation of std::bit_cast for bit fields

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 114536
   Summary: wrong constant evaluation of std::bit_cast for bit
fields
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

In this program


#include 

struct A { unsigned char a: 7; };

struct B { unsigned char b; };

// fails in GCC
static_assert( std::bit_cast(A{1}).b == 1 );

int main() {
// correctly returns 1 in GCC
return std::bit_cast(A{1}).b;
}


static_assert fails with the message:

note: the comparison reduces to '(0 == 1)'

which contradicts runtime evaluation of the same expression. Online demo:
https://gcc.godbolt.org/z/fza4zas3E

[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14

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

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

--- Comment #3 from Jonathan Wakely  ---
[dcl.array] says that for T[N] the value "N specifies the array bound, i.e.,
the
number of elements in the array; N shall be greater than zero."

So T[0] is not a valid array type. And std::is_array has never been true
for any traditional implementation based on partial specialization of class
templates, only when switching to an intrinsic __is_array that fails to
accurately give the same behaviour as the std::is_array trait.

Since the purpose of the __is_array intrinsic is to optimize the std::is_array
trait, it should have the same behaviour. For the optimization to change the
behaviour of the trait seems like the tail wagging the dog.

[Bug tree-optimization/114164] simdclone vectorization creates unsupported IL

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/111610] Cannot build cross compiler to darwin targets after r14-4108-g47346acb72b50d

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:17e5d36db43f22a696a97c24afb5fb36b00dfb0b

commit r13-8533-g17e5d36db43f22a696a97c24afb5fb36b00dfb0b
Author: Iain Sandoe 
Date:   Wed Sep 27 11:05:31 2023 +0100

Darwin, configure: Allow for an unrecognisable dsymutil [PR111610].

We had a catch-all configuration case for missing or unrecognised dsymutil
but it was setting the dsymutil source to "UNKNOWN" which is not usable in
this context (since it clashes with an existing enum).  We rename this to
DET_UNKNOWN (for Darwin External Toolchain).

PR target/111610

gcc/ChangeLog:

* configure: Regenerate.
* configure.ac: Rename the missing dsymutil case to "DET_UNKNOWN".

Signed-off-by: Iain Sandoe 
(cherry picked from commit 2ecab2f32b9e9a75bf563f80752d5b44dcd26b98)

[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org
Summary|ICE: Floating point |[11/12/13/14 Regression]
   |exception (in   |ICE: Floating point
   |is_miss_rate_acceptable),   |exception (in
   |target assigning alignent   |is_miss_rate_acceptable),
   |of 4 bits(!) to vector  |target assigning alignent
   ||of 4 bits(!) to vector
  Known to fail||9.1.0
   Target Milestone|--- |11.5
  Known to work||8.5.0

--- Comment #3 from Andrew Pinski  ---
Found it:
/* In GIMPLE the type of the MEM_REF specifies the alignment.  The
  required alignment (power) is 4 bytes regardless of data type.  */
tree align_ltype = build_aligned_type (lhs_type, 4);

That should be 4*8 instead of just 4.

There are 2 build_aligned_type in rs6000-builtins.cc which uses the wrong
alignment; thinking it was the alignment argument was bytes rather than bits.

Introduced by r9-2375-g3f7a77cd20d07c which means this is a regression.

[Bug objc/101718] Objective-C frontend emits wrong code to call methods returning scalar types returned in memory

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #9 from Iain Sandoe  ---
fixed on open branches (and gcc-10)

[Bug objc/101718] Objective-C frontend emits wrong code to call methods returning scalar types returned in memory

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:106cfc476a55c7423dca23be1eb0a5fb5da736b5

commit r11-11302-g106cfc476a55c7423dca23be1eb0a5fb5da736b5
Author: Iain Sandoe 
Date:   Mon Aug 16 21:22:13 2021 +0100

Objective-C, NeXT: Fix messenging non-aggregate return-in-memory.

When a method returns a type that the platform ABI says should be
returned in memory, and that is done by a hidden 'sret' parameter,
the message send calls must be adjusted to inform the runtime that
the sret parameter is present.  As reported in the PR, this is not
working for non-aggregate types that use this mechanism.  The fix
here is to adjust the logic such that all return values that flag
'in memory' are considered to use the mechanism *unless* they
provide a struct_value_rtx *and* the return object is an aggregate.

Signed-off-by: Iain Sandoe 

PR objc/101718 - Objective-C frontend emits wrong code to call methods
returning scalar types returned in memory

PR objc/101718

gcc/objc/ChangeLog:

* objc-next-runtime-abi-02.c (build_v2_build_objc_method_call):
Revise for cases where scalar objects use an sret parameter.
(next_runtime_abi_02_build_objc_method_call): Likwise.

(cherry picked from commit 1cef3039b880a21fbdf4153e6fc42026619fd4ad)

[Bug fortran/114535] New: ICE with elemental finalizer

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

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

Bug ID: 114535
   Summary: ICE with elemental finalizer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following code (which must be in two files to trigger the error) causes an
ICE using the latest gfortran.

$ cat ice1.F90
module iv
  type, public :: vs
   contains
 final :: destructor
  end type vs
contains
 elemental subroutine destructor(s)
type(vs), intent(inout) :: s
  end subroutine destructor
end module iv

$ cat ice2.F90 module d
contains
  function en() result(dd)
use :: iv
type(vs) :: dd
return
  end function en
end module d

module ni
contains
  subroutine iss()
use :: d
return
  end subroutine iss
end module ni

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure
--prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240330 (experimental) (GCC)

$ gfortran -c ice1.F90 -o ice1.o   
$ gfortran -c ice2.F90 -o ice2.o  
ice2.F90:16:13: 
   16 | end module ni | 1
internal compiler error: in gfc_trans_call, at fortran/trans-stmt.cc:400   
0x78ddb6 gfc_trans_call(gfc_code*, bool,
tree_node*, tree_node*, bool)
../../gcc-git/gcc/fortran/trans-stmt.cc:400 0xaa8a1b trans_code
../../gcc-git/gcc/fortran/trans.cc:2431
0xb47c14 gfc_trans_simple_do
../../gcc-git/gcc/fortran/trans-stmt.cc:2521
0xb47c14 gfc_trans_do(gfc_code*, tree_node*)
../../gcc-git/gcc/fortran/trans-stmt.cc:2653
0xaa898a trans_code
../../gcc-git/gcc/fortran/trans.cc:2463
0xb485e9 gfc_trans_integer_select  
../../gcc-git/gcc/fortran/trans-stmt.cc:3199
0xb485e9 gfc_trans_select(gfc_code*)
../../gcc-git/gcc/fortran/trans-stmt.cc:3692
0xaa8957 trans_code
../../gcc-git/gcc/fortran/trans.cc:2475
0xadd6fb gfc_generate_function_code(gfc_namespace*)
../../gcc-git/gcc/fortran/trans-decl.cc:7879
0xaadbf1 gfc_generate_module_code(gfc_namespace*)
../../gcc-git/gcc/fortran/trans.cc:2785
0xa5113d translate_all_program_units
../../gcc-git/gcc/fortran/parse.cc:7086
0xa5113d gfc_parse_file()
../../gcc-git/gcc/fortran/parse.cc:7413
0xaa546f gfc_be_parse_file
../../gcc-git/gcc/fortran/f95-lang.cc:241
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.

This only occurs if the FINAL subroutine is ELEMENTAL.