[Bug target/106635] AARCH64 STUR instruction causes bus error

[xgchenshy at 126 dot com via Gcc-bugs]

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

--- Comment #9 from Xiaoguang  ---
(In reply to Andrew Pinski from comment #8)
> In ARM Armv8, for A-profile architecture (ARM DDI 0487G.b (ID072021)): 
> 
> From section B2.5.2 Alignment of data accesses:
> 
> An unaligned access to any type of Device memory causes an Alignment fault.
> 
> Unaligned accesses to Normal memory

Yeah, I also find such description, my memory type is uncachable normal memory,
but not device memory
I use mmap to get the virtual address with an O_SYNC in fd

[Bug target/106635] AARCH64 STUR instruction causes bus error

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

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

--- Comment #8 from Andrew Pinski  ---
In ARM Armv8, for A-profile architecture (ARM DDI 0487G.b (ID072021)): 

>From section B2.5.2 Alignment of data accesses:

An unaligned access to any type of Device memory causes an Alignment fault.

Unaligned accesses to Normal memory

[Bug target/106635] AARCH64 STUR instruction causes bus error

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Xiaoguang from comment #6)
> (In reply to Richard Earnshaw from comment #5)
> > Your original code contains (after stripping out the volatile):
> > u32 temp_32 = (u32)status_data_base_addr;
> > *dst++ = temp_32;
> > data_length++;
> >  
> > if(sizeof(addr_t) == 8) {
> >   *dst++ = (u32)(((u64)status_data_base_addr)>>32);
> >   data_length++;
> > }
> > 
> > Which of course on a 64-bit machine simplifies to 
> > 
> > u32 temp_32 = (u32)status_data_base_addr;
> > *dst++ = temp_32;
> > data_length++;
> >  
> > *dst++ = (u32)(((u64)status_data_base_addr)>>32);
> > data_length++;
> > 
> > And which the compiler then further simplifies to 
> > 
> >*([unaligned]u64*)dst = status_data_base_addr;
> >data_length += 2;
> >dst += 2;
> > 
> > If the location that dst points to is in normal, cachable, memory, then this
> > will be fine.  But if you're writing to non-cachable memory, then you might
> > get a trap.
> Thanks Very much for the explaination, Can you tell me why unaligned access
> only  works in normal cachable memory? where does this constraint come from? 

The architect (armv8) explains this. Basically the hardware does not know what
to do when there is a unaligned access as it has to two reads and two writes to
get the data correct.
It in the arm armv8 document.




> 
> > 
> > the correct fix is to mark dst as volatile in this case.
> > 
> > void CWLCollectReadRegData(volatile u32* dst,u16 reg_start, u32
> > reg_length,u32*
> > total_length, addr_t status_data_base_addr)

[Bug target/106635] AARCH64 STUR instruction causes bus error

[xgchenshy at 126 dot com via Gcc-bugs]

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

--- Comment #6 from Xiaoguang  ---
(In reply to Richard Earnshaw from comment #5)
> Your original code contains (after stripping out the volatile):
> u32 temp_32 = (u32)status_data_base_addr;
> *dst++ = temp_32;
> data_length++;
>  
> if(sizeof(addr_t) == 8) {
>   *dst++ = (u32)(((u64)status_data_base_addr)>>32);
>   data_length++;
> }
> 
> Which of course on a 64-bit machine simplifies to 
> 
> u32 temp_32 = (u32)status_data_base_addr;
> *dst++ = temp_32;
> data_length++;
>  
> *dst++ = (u32)(((u64)status_data_base_addr)>>32);
> data_length++;
> 
> And which the compiler then further simplifies to 
> 
>*([unaligned]u64*)dst = status_data_base_addr;
>data_length += 2;
>dst += 2;
> 
> If the location that dst points to is in normal, cachable, memory, then this
> will be fine.  But if you're writing to non-cachable memory, then you might
> get a trap.
Thanks Very much for the explaination, Can you tell me why unaligned access
only  works in normal cachable memory? where does this constraint come from? 

> 
> the correct fix is to mark dst as volatile in this case.
> 
> void CWLCollectReadRegData(volatile u32* dst,u16 reg_start, u32
> reg_length,u32*
> total_length, addr_t status_data_base_addr)

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

--- Comment #20 from HaoChen Gui  ---
(In reply to Segher Boessenkool from comment #19)
> Hi guys,
> 
> What testcases are still failing?  I'm a bit lost :-)

pr56605.c is still not fixed.

+FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine
"(compare:CC ((?:and|zero_extend):(?:DI) ((?:sub)?reg:[SD]I" 1

[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #7 from Hans-Peter Nilsson  ---
(In reply to Roger Sayle from comment #5)
> I'm sure if GCC instead canonicalized to the sign_extend form, that other
> targets would show similar asymmetries (it's only when things change that
> anyone notices the difference).  I'll see if I can come up with a fix over
> the weekend.

Maybe I'm hallucinating and I'm certainly late to the game, but perhaps a
REG_NONNEGATIVE note can be added on the insn for the target register when
doing the AND transformation and then combine can be improved to try to replace
ZERO_EXTEND with SIGN_EXTEND when seeing this note on the applicable input
operand?

[Bug middle-end/106661] New: possible uninitialized variable usage in store_bit_field_1

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

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

Bug ID: 106661
   Summary: possible uninitialized variable usage in
store_bit_field_1
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Compiling the trunk with GCC 7.5.0 for a cross to riscv32-linux-gnu produces
the following warning:
In file included from
/bajas/pinskia/src/toolchain-riscv/scripts/../src/gcc/coretypes.h:475:0,
 from
/bajas/pinskia/src/toolchain-riscv/scripts/../src/gcc/expmed.cc:26:
/bajas/pinskia/src/toolchain-riscv/scripts/../src/gcc/poly-int.h: In function
‘bool store_bit_field_1(rtx, poly_uint64, poly_uint64, poly_uint64,
poly_uint64, machine_mode, rtx, bool, bool, bool)’:
/bajas/pinskia/src/toolchain-riscv/scripts/../src/gcc/poly-int.h:1107:38:
warning: ‘regnum’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 POLY_SET_COEFF (C, r, i, NCa (a) * b.coeffs[i]);
  ^
/bajas/pinskia/src/toolchain-riscv/scripts/../src/gcc/expmed.cc:797:21: note:
‘regnum’ was declared here
   HOST_WIDE_INT regnum;
 ^~


I looked into the code I think the warning is correct, regnum could be
uninitialized if undefined_p is true but constant_multiple_p returns false.
I have not looked into if the warning happens for the trunk or why x86_64 does
not get the warning.

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

--- Comment #19 from Segher Boessenkool  ---
Hi guys,

What testcases are still failing?  I'm a bit lost :-)

[Bug target/103197] [10/11] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #18 from Segher Boessenkool  ---
Fixed everywhere.

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Segher Boessenkool
:

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

commit r10-10948-gd99d74d8b1b517784e3b05b271b977eb6603121f
Author: Segher Boessenkool 
Date:   Sun Jan 2 14:08:35 2022 +

rs6000: Disparage lfiwzx and similar

RA now chooses GEN_OR_VSX_REGS in most cases.  This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes.  We can fix that by putting a small penalty on the
instruction alternatives for those.

2022-04-21  Segher Boessenkool  

PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi2 for EXTQI):
Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi2 for EXTHI): Ditto.
(zero_extendsi2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.

(cherry picked from commit 26fa464f42622c60d6929720dd37143a21054ede)

[Bug target/103197] [10/11] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Segher Boessenkool
:

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

commit r10-10948-gd99d74d8b1b517784e3b05b271b977eb6603121f
Author: Segher Boessenkool 
Date:   Sun Jan 2 14:08:35 2022 +

rs6000: Disparage lfiwzx and similar

RA now chooses GEN_OR_VSX_REGS in most cases.  This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes.  We can fix that by putting a small penalty on the
instruction alternatives for those.

2022-04-21  Segher Boessenkool  

PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi2 for EXTQI):
Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi2 for EXTHI): Ditto.
(zero_extendsi2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.

(cherry picked from commit 26fa464f42622c60d6929720dd37143a21054ede)

[Bug go/106660] New: riscv32-linux-gnu fails to compile libgo due to having only 64bit time_t (no support for 32bit time_t)

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

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

Bug ID: 106660
   Summary: riscv32-linux-gnu fails to compile libgo due to having
only 64bit time_t (no support for 32bit time_t)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv32-linux-gnu

/bajas/pinskia/src/toolchain-riscv/scripts/../src/libgo/go/runtime/os_linux.go:30:30:
error: reference to undefined name ‘_SYS_futex’
   30 | return int32(syscall(_SYS_futex, uintptr(addr), uintptr(op),
uintptr(val), uintptr(ts), uintptr(addr2), uintptr(val3)))
  |  ^
/bajas/pinskia/src/toolchain-riscv/scripts/../src/libgo/go/runtime/os_linux.go:251:30:
error: reference to undefined name ‘_SYS_timer_settime’
  251 | return int32(syscall(_SYS_timer_settime, uintptr(timerid),
uintptr(flags), uintptr(unsafe.Pointer(new)), uintptr(unsafe.Pointer(old)), 0,
0))
  |  ^

This is due to _SYS_futex not existing for riscv32, only SYS_futex_time64
exists.

Same for _SYS_timer_settime, only _SYS_timer_settime64 .

[Bug target/106588] The constraints on most of the patterns in bitmanip.md are broken

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #2 from Hans-Peter Nilsson  ---
(In reply to Andrew Pinski from comment #0)
> Take:
> (define_insn "*bseti"
>   [(set (match_operand:X 0 "register_operand" "=r")
>   (ior:X (match_operand:X 1 "register_operand" "r")
>  (match_operand 2 "single_bit_mask_operand" "i")))]
>   "TARGET_ZBS"
>   "bseti\t%0,%1,%S2"
>   [(set_attr "type" "bitmanip")])
> 
> That is if something after reload decides to change operand 2, it will be
> accepted and then crash while emitting %S2.

And that "something" doesn't also re-validate through the
single_bit_mask_operand predicate at the time?  AFAIR, re-validation requires
predicate-matching too, not just constraint-matching.

[Bug gcov-profile/106659] [13 Regression] error: no member named 'fancy_abort' in namespace 'std'; did you mean simply 'fancy_abort'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|regression  |gcov-profile
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|error: no member named  |[13 Regression] error: no
   |'fancy_abort' in namespace  |member named 'fancy_abort'
   |'std'; did you mean simply  |in namespace 'std'; did you
   |'fancy_abort'   |mean simply 'fancy_abort'
   Target Milestone|--- |13.0
   Keywords||build
   Last reconfirmed||2022-08-16

--- Comment #1 from Andrew Pinski  ---
This should fix the issue:
diff --git a/gcc/gcov-dump.cc b/gcc/gcov-dump.cc
index 85b1be8859e..03023bfb226 100644
--- a/gcc/gcov-dump.cc
+++ b/gcc/gcov-dump.cc
@@ -17,6 +17,7 @@ along with Gcov; see the file COPYING3.  If not see
 .  */

 #include "config.h"
+#define INCLUDE_VECTOR
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
@@ -28,8 +29,6 @@ along with Gcov; see the file COPYING3.  If not see
 #include "gcov-io.h"
 #include "gcov-io.cc"

-#include 
-
 using namespace std;

 static void dump_gcov_file (const char *);

[Bug regression/106659] New: error: no member named 'fancy_abort' in namespace 'std'; did you mean simply 'fancy_abort'

[salvadore at FreeBSD dot org via Gcc-bugs]

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

Bug ID: 106659
   Summary: error: no member named 'fancy_abort' in namespace
'std'; did you mean simply 'fancy_abort'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: salvadore at FreeBSD dot org
  Target Milestone: ---

Snapshots 13-20220807 and 13-20220814 do not compile on FreeBSD (many versions,
for example 13.1-RELEASE) with its default compiler (for FreeBSD 13.1-RELEASE
it is FreeBSD clang version 13.0.0). Last successfully compiling snapshot for
gcc 13 is 13-20220731.
Error produced is

In file included from ../.././gcc/gcov-dump.cc:31: 
In file included from /usr/include/c++/v1/vector:274:  
In file included from /usr/include/c++/v1/__bit_reference:15:  
In file included from /usr/include/c++/v1/algorithm:667:   
In file included from /usr/include/c++/v1/functional:499:
In file included from /usr/include/c++/v1/__functional/bind.h:17:
In file included from /usr/include/c++/v1/tuple:172:
In file included from /usr/include/c++/v1/__functional_base:25:
/usr/include/c++/v1/typeinfo:375:5: error: no member named 'fancy_abort' in
 namespace 'std'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~
/usr/include/c++/v1/__config:826:15: note: expanded from macro '_VSTD'
#define _VSTD std
  ^
../.././gcc/system.h:785:13: note: 'fancy_abort' declared here
extern void fancy_abort (const char *, int, const char *)

And more similar errors complaining about fancy_abort follow.

The issue seems something similar to bug #102242.

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Segher Boessenkool
:

https://gcc.gnu.org/g:72cf56c7cfefaf1b074bb70e42890cf1191c46a1

commit r11-10208-g72cf56c7cfefaf1b074bb70e42890cf1191c46a1
Author: Segher Boessenkool 
Date:   Thu Apr 21 18:35:32 2022 +

rs6000/testsuite: xfail bswap-brw.c

This testcase does not generate anywhere near optimal code for 32-bit
code.  For p10 it actually now fails this testcase, after the previous
patch.  Let's xfail it.

2022-04-21  Segher Boessenkool  

gcc/testsuite/
PR target/103197
PR target/102146
* gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for
-m32.

(cherry picked from commit 748d46cd049c89a799f99f14547267ebae915af6)

[Bug target/103197] [10/11] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte

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

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Segher Boessenkool
:

https://gcc.gnu.org/g:72cf56c7cfefaf1b074bb70e42890cf1191c46a1

commit r11-10208-g72cf56c7cfefaf1b074bb70e42890cf1191c46a1
Author: Segher Boessenkool 
Date:   Thu Apr 21 18:35:32 2022 +

rs6000/testsuite: xfail bswap-brw.c

This testcase does not generate anywhere near optimal code for 32-bit
code.  For p10 it actually now fails this testcase, after the previous
patch.  Let's xfail it.

2022-04-21  Segher Boessenkool  

gcc/testsuite/
PR target/103197
PR target/102146
* gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for
-m32.

(cherry picked from commit 748d46cd049c89a799f99f14547267ebae915af6)

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Segher Boessenkool
:

https://gcc.gnu.org/g:2eb21e7349cda2885438463f045f6729a47039e8

commit r11-10207-g2eb21e7349cda2885438463f045f6729a47039e8
Author: Segher Boessenkool 
Date:   Sun Jan 2 14:08:35 2022 +

rs6000: Disparage lfiwzx and similar

RA now chooses GEN_OR_VSX_REGS in most cases.  This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes.  We can fix that by putting a small penalty on the
instruction alternatives for those.

2022-04-21  Segher Boessenkool  

PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi2 for EXTQI):
Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi2 for EXTHI): Ditto.
(zero_extendsi2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.

(cherry picked from commit 26fa464f42622c60d6929720dd37143a21054ede)

[Bug target/103197] [10/11] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Segher Boessenkool
:

https://gcc.gnu.org/g:2eb21e7349cda2885438463f045f6729a47039e8

commit r11-10207-g2eb21e7349cda2885438463f045f6729a47039e8
Author: Segher Boessenkool 
Date:   Sun Jan 2 14:08:35 2022 +

rs6000: Disparage lfiwzx and similar

RA now chooses GEN_OR_VSX_REGS in most cases.  This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes.  We can fix that by putting a small penalty on the
instruction alternatives for those.

2022-04-21  Segher Boessenkool  

PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi2 for EXTQI):
Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi2 for EXTHI): Ditto.
(zero_extendsi2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.

(cherry picked from commit 26fa464f42622c60d6929720dd37143a21054ede)

[Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0

[sebastien.michelland--- via Gcc-bugs]

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

--- Comment #5 from Sébastien Michelland  ---
> Then this is a target specific issue until provided otherwise. mach stands 
> for machine (target) specific pass.

That makes a lot of sense, thanks.

I found a much simpler example exhibiting the bug:

int f(int i, int j)
{
if(i < 0) return 1;
if(i + j) return 3;
return i;
}

Latest HEAD with -O1 (same setup as before) compiles it to

_f: cmp/pz  r4
bf  .L3
bf  .L4
rts 
mov r4,r0
.L3:rts 
mov #1,r0
.L4:rts 
mov #3,r0

incorrectly eliminating the test for (i + j) != 0. The label .L4 returning 3 is
evidently unreachable.

Comparing to 0 seems to be required. My previous example also compiles
correctly if we check values[i] != 1 instead, which invalidates the loop/CFG
theory.

Few commits changed the SH subtree since GCC 11.1.0; I should be able to bisect
it. In the meantime I've updated the title.

[Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0

[sebastien.michelland--- via Gcc-bugs]

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

Sébastien Michelland  changed:

   What|Removed |Added

Summary|[SH] miscompilation of loop |[SH] miscompilation due to
   |involving noreturn call |incorrect elimination of
   ||comparisons to 0

--- Comment #4 from Sébastien Michelland  ---
> Then this is a target specific issue until provided otherwise. mach stands 
> for machine (target) specific pass.

That makes a lot of sense, thanks.

I found a much simpler example exhibiting the bug:

int f(int i, int j)
{
if(i < 0) return 1;
if(i + j) return 3;
return i;
}

Latest HEAD with -O1 (same setup as before) compiles it to

_f: cmp/pz  r4
bf  .L3
bf  .L4
rts 
mov r4,r0
.L3:rts 
mov #1,r0
.L4:rts 
mov #3,r0

incorrectly eliminating the test for (i + j) != 0. The label .L4 returning 3 is
evidently unreachable.

Comparing to 0 seems to be required. My previous example also compiles
correctly if we check values[i] != 1 instead, which invalidates the loop/CFG
theory.

Few commits changed the SH subtree since GCC 11.1.0; I should be able to bisect
it. In the meantime I've updated the title.

[Bug target/104338] RISC-V: Subword atomics result in library calls

[aurelien at aurel32 dot net via Gcc-bugs]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #10 from Aurelien Jarno  ---
I am not subscribed to the mailing list, but I am not able to see any more
mails after the v3. Any update?

[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored

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

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

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

https://gcc.gnu.org/g:60468d6cd46a3bd3afe8ff856f82afcd4c65a217

commit r13-2081-g60468d6cd46a3bd3afe8ff856f82afcd4c65a217
Author: Tom Honermann 
Date:   Mon Aug 1 14:49:00 2022 -0400

c++: Fix pragma suppression of -Wc++20-compat diagnostics [PR106423]

Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target diagnostic option be enabled for the preprocessor
(see c_option_is_from_cpp_diagnostics).  This change modifies the
-Wc++20-compat option definition to register it as a preprocessor option
so that its associated diagnostics can be suppressed.  The changes also
implicitly disable the option in C++20 and later modes.  These changes
are consistent with the definition of the -Wc++11-compat option.

This support is motivated by the need to suppress the following diagnostic
otherwise issued in C++17 and earlier modes due to the char8_t typedef
present in the uchar.h header file in glibc 2.36.
  warning: identifier âchar8_tâ is a keyword in C++20 [-Wc++20-compat]

Tests are added to validate suppression of both -Wc++11-compat and
-Wc++20-compat related diagnostics (fixes were only needed for the C++20
case).

PR c++/106423

gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Disable -Wc++20-compat
diagnostics in C++20 and later.
* c.opt (Wc++20-compat): Enable hooks for the preprocessor.

gcc/cp/ChangeLog:
* parser.cc (cp_lexer_saving_tokens): Add comment regarding
diagnostic requirements.

gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/keywords2.C: New test.
* g++.dg/cpp2a/keywords2.C: New test.

libcpp/ChangeLog:
* include/cpplib.h (cpp_warning_reason): Add CPP_W_CXX20_COMPAT.
* init.cc (cpp_create_reader): Add cpp_warn_cxx20_compat.

[Bug c++/106658] New: [C++23] P2590 - Explicit lifetime management

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

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

Bug ID: 106658
   Summary: [C++23] P2590 - Explicit lifetime management
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106657] New: [C++23] P2460 - Relax requirements on wchar_t to match existing practices

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

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

Bug ID: 106657
   Summary: [C++23] P2460 - Relax requirements on wchar_t to match
existing practices
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106656] [C++23] P2513 - char8_t Compatibility and Portability Fixes

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Blocks||98940
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-16
 Status|UNCONFIRMED |ASSIGNED


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

[Bug c++/106656] New: [C++23] P2513 - char8_t Compatibility and Portability Fixes

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

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

Bug ID: 106656
   Summary: [C++23] P2513 - char8_t Compatibility and Portability
Fixes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106655] New: [C++23] P2295 - Support for UTF-8 as a portable source file encoding

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

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

Bug ID: 106655
   Summary: [C++23] P2295 - Support for UTF-8 as a portable source
file encoding
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106654] New: [C++23] P1774 - Portable assumptions

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

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

Bug ID: 106654
   Summary: [C++23] P1774 - Portable assumptions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106653] New: [C++23] P2582 - Class template argument deduction from inherited constructors

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

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

Bug ID: 106653
   Summary: [C++23] P2582 - Class template argument deduction from
inherited constructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106652] New: [C++23] P1467 - Extended floating-point types and standard names

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

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

Bug ID: 106652
   Summary: [C++23] P1467 - Extended floating-point types and
standard names
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106651] New: [C++23] P1169 - static operator()

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

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

Bug ID: 106651
   Summary: [C++23] P1169 - static operator()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106650] New: [C++23] P2280 - Using unknown references in constant expressions

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

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

Bug ID: 106650
   Summary: [C++23] P2280 - Using unknown references in constant
expressions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106649] New: [C++23] P2448 - Relaxing some constexpr restrictions

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

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

Bug ID: 106649
   Summary: [C++23] P2448 - Relaxing some constexpr restrictions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106648] New: [C++23] P2071 - Named universal character escapes

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

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

Bug ID: 106648
   Summary: [C++23] P2071 - Named universal character escapes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/106647] New: [C++23] P2362 - Remove non-encodable wide character literals and multicharacter wide character literals

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

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

Bug ID: 106647
   Summary: [C++23] P2362 - Remove non-encodable wide character
literals and multicharacter wide character literals
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||5.1.0

--- Comment #10 from Andrew Pinski  ---
(In reply to Vineet Gupta from comment #9)
> > > Can this be back-ported to gcc 12 please ?
> > 
> > Do you have an indication that this is a regression?
> 
> No, but this does seem like a bug, aren't those backported ?

Only regressions are backported really; especially when it comes to
optimizations.

[Bug c++/106646] New: [C++23] P2437R1 - Support for #warning

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

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

Bug ID: 106646
   Summary: [C++23] P2437R1 - Support for #warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

Yes, we already have it, but we should still double check that we implement
everything the paper talks about.

[Bug c++/106645] [C++23] P2290R3 - Delimited escape sequences

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 53467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53467=edit
gcc13-pr106645.patch

Untested implementation.

[Bug c++/106645] [C++23] P2290R3 - Delimited escape sequences

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2022-08-16
 Ever confirmed|0   |1
 Blocks||98940


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

[Bug c++/106645] New: [C++23] P2290R3 - Delimited escape sequences

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

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

Bug ID: 106645
   Summary: [C++23] P2290R3 - Delimited escape sequences
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest

[vineetg at rivosinc dot com via Gcc-bugs]

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

--- Comment #9 from Vineet Gupta  ---
> > Can this be back-ported to gcc 12 please ?
> 
> Do you have an indication that this is a regression?

No, but this does seem like a bug, aren't those backported ?

[Bug c++/106644] New: [C++23] P2468R2 - The Equality Operator You Are Looking For

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

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

Bug ID: 106644
   Summary: [C++23] P2468R2 - The Equality Operator You Are
Looking For
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug target/106637] docs: link to www.bullfreeware.com is dead

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug target/106637] docs: link to www.bullfreeware.com is dead

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:9580ab573dd59e7eaff768b1e5fc736be8c63d20

commit r13-2080-g9580ab573dd59e7eaff768b1e5fc736be8c63d20
Author: Martin Liska 
Date:   Tue Aug 16 18:15:55 2022 +0200

docs: remove link to www.bullfreeware.com from install

As mentioned at https://gcc.gnu.org/PR106637#c2, the discontinued
providing binaries.

PR target/106637

gcc/ChangeLog:

* doc/install.texi: Remove link to www.bullfreeware.com

[Bug c++/102610] [C++23] P2036R3 - Change scope of lambda trailing-return-type

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-16

--- Comment #1 from Marek Polacek  ---
https://wg21.link/p2579r0, Mitigation strategies for P2036 ”Changing scope for
lambda trailing-return-type”, was also approved.

[Bug tree-optimization/106559] [10/11/12/13 Regression] Spurious warning -Wformat-truncation (regression from 9)

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Blocks||85741

--- Comment #2 from Martin Sebor  ---
The warning triggers because it considers the size of the whole `string' array
passed as an argument to the %s directive.  It does that because the analysis
is unable to determine which array element the argument points to and it's not
"smart" enough to see that all the elements are strings of the same length. 
The output of the -fdump-tree-strlen option below helps see what's gooing on
(the numbers next  to each Result: show the minimum, maximum, likely, and
unlikely amount of output produced by the directive, with the corresponding
running totals in parentheses).

The problem can be reduced to a missed optimization opportunity in the test
following test case: the condition in each iteration of the loop is false so
the loop can be optimized away, but because of the incomplete analysis above it
is not.

void f (void)
{
  static const char string[16][3]={
  "01","02","03","04","05","06","07","08",
  "09","10","11","12","13","14","15","16"};

  for(unsigned int i=0; i<16; ++i)
  if (__builtin_strlen (string[i]) != 2)
  __builtin_abort ();
}

Short of improving the strlen optimization the warning could also be suppressed
by considering the cast in the assignment `_2 = (const char[3] *) ivtmp.11_15;'
and using the size of the array as the upper bound on the length of the string.
 (This wouldn't be safe for the optimization.)

Until this is fixed in GCC, the warning can be suppressed and the emitted code
improved by asserting in each iteration that the length of the string is (at
most) two, like so:

if (__builtin_strlen (string[i]) != 2)
  __builtin_unreachable ();

pr106559.c:11: __builtin_snprintf: objsize = 64, fmtstr = "%u (%s):   %8x"
  Directive 1 at offset 0: "%u"
Result: 1, 2, 2, 2 (1, 2, 2, 2)
  Directive 2 at offset 2: " (", length = 2
Result: 2, 2, 2, 2 (3, 4, 4, 4)
  Directive 3 at offset 4: "%s"
Result: 0, 47, 47, 9223372036854775807 (3, 51, 51, -9223372036854775805)
  Directive 4 at offset 6: "):   ", length = 5
Result: 5, 5, 5, 5 (8, 56, 56, -9223372036854775800)
  Directive 5 at offset 11: "%8x"
Result: 8, 8, 8, 8 (16, 64, 64, -9223372036854775792)
  Directive 6 at offset 14: "", length = 1
pr106559.c: In function ‘f’:
pr106559.c:11:61: warning: ‘__builtin_snprintf’ output may be truncated before
the last format character [-Wformat-truncation=]
   11 | __builtin_snprintf(buffer,sizeof(buffer),"%u (%s):   %8x",
  | ^
pr106559.c:11:5: note: ‘__builtin_snprintf’ output between 17 and 65 bytes into
a destination of size 64
   11 | __builtin_snprintf(buffer,sizeof(buffer),"%u (%s):   %8x",
  | ^~
   12 |   i,string[i],number[i]);
  |   ~~

void f ()
{
  unsigned long ivtmp.11;
  unsigned long ivtmp.5;
  unsigned int i;
  static const char string[16][3] = {"01", "02", "03", "04", "05", "06", "07",
"08", "09", "10", "11", "12", "13", "14", "15", "16"};
  unsigned int _1;
  const char[3] * _2;
  unsigned int _18;

   [local count: 63136016]:
  ivtmp.11_17 = (unsigned long) 

   [local count: 1010605809]:
  # ivtmp.5_13 = PHI 
  # ivtmp.11_15 = PHI 
  _18 = (unsigned int) ivtmp.5_13;
  _1 = MEM[(unsigned int *) + ivtmp.5_13 * 4];
  _2 = (const char[3] *) ivtmp.11_15;<<< cast
not considered
  __builtin_snprintf (, 64, "%u (%s):   %8x", _18, _2, _1);   <<<
warning here for _2


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug c++/106631] Unhelpful diagnostic on variable template specialization with unknown name

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/106588] The constraints on most of the patterns in bitmanip.md are broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Mine.
The patch to the my branch can be found at 
https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370098.html

[Bug libgomp/106643] New: [gfortran + OpenACC] Allocate in module causes refcount error

[hberre3 at gatech dot edu via Gcc-bugs]

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

Bug ID: 106643
   Summary: [gfortran + OpenACC] Allocate in module causes
refcount error
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hberre3 at gatech dot edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I built GCC 13 from the default branch with offloading support for the new AMD
MI 210 GPUs by following the documented instructions. I ran into the following
runtime error when running our offloaded code written in Fortran leveraging
OpenACC:

```
/nethome/hberre3/USERSCRATCH/build-gcc-amdgpu//gcc/libgomp/oacc-mem.c:1153:
goacc_enter_data_internal: Assertion `n->refcount != REFCOUNT_INFINITY &&
n->refcount != REFCOUNT_LINK' failed.
```

I was able to create a minimal reproducible example for it:

p_main.f90
```
program p_main

use m_macron

!
==

implicit none

call s_vars_init()
call s_vars_read()
call s_macron_init()

end program p_main
```

m_macron.f90
```
module m_macron

use m_vars

implicit none

real(kind(0d0)), allocatable, dimension(:) :: valls
!$acc declare create(valls)

contains

subroutine s_macron_init()

integer :: i

print*, "size=", size

print*, "allocate(valls(1:size))"
allocate(valls(1:size))

print*, "acc enter data create(valls(1:size))"
!$acc enter data create(valls(1:size))

print*, "!$acc update device(valls(1:size))"
valls(size) = size - 2
!$acc update device(valls(1:size))

print*, valls(1:size)

print*, "acc exit data delete(valls)"
!$acc exit data delete(valls)

end subroutine s_macron_init

end module m_macron
```

m_vars.f90
```
module m_vars

integer :: size

contains

subroutine s_vars_init()

size = -100

end subroutine s_vars_init

subroutine s_vars_read()

! Namelist of the global parameters which may be specified by user
namelist /user_inputs/ size

open (1, FILE=trim("in.inp"), FORM='formatted', ACTION='read',
STATUS='old')
read (1, NML=user_inputs); close (1)

end subroutine s_vars_read

end module m_vars
```

in.inp
```
_inputs
size = 10
/
```

In order to generate this error, I had to create and dynamically allocate the
array in another module. I initially wrote this in a single F90 file but the
executable ran as expected. The error gets produced when running:
```
!$acc enter data create(valls(1:size))
```

Here is the full output when running the executable with the `GOMP_DEBUG`
environment variable set:
```
GOACC_data_start: mapnum=3, hostaddrs=0x7fff23d2efd0, size=0x7fff23d2efb0,
kinds=0x603102
  GOACC_data_start: prepare mappings
  GOACC_data_start: mappings prepared
 size=  10
 allocate(valls(1:size))
 acc enter data create(valls(1:size))
main:
/nethome/hberre3/USERSCRATCH/build-gcc-amdgpu//gcc/libgomp/oacc-mem.c:1153:
goacc_enter_data_internal: Assertion `n->refcount != REFCOUNT_INFINITY &&
n->refcount != REFCOUNT_LINK' failed.

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7f4aa4fcdb1f in ???
#1  0x7f4aa4fcda9f in ???
#2  0x7f4aa4fa0e04 in ???
#3  0x7f4aa4fa0cd8 in ???
#4  0x7f4aa4fc63f5 in ???
#5  0x7f4aa57b79e5 in goacc_enter_data_internal
at
/nethome/hberre3/USERSCRATCH/build-gcc-amdgpu//gcc/libgomp/oacc-mem.c:1153
#6  0x7f4aa57b79e5 in goacc_enter_exit_data_internal
at
/nethome/hberre3/USERSCRATCH/build-gcc-amdgpu//gcc/libgomp/oacc-mem.c:1405
#7  0x7f4aa57b8aab in GOACC_enter_data
at
/nethome/hberre3/USERSCRATCH/build-gcc-amdgpu//gcc/libgomp/oacc-mem.c:1478
#8  0x4013b7 in __m_macron_MOD_s_macron_init
at /nethome/hberre3/bug/m_macron.f90:22
#9  0x40182a in p_main
at /nethome/hberre3/bug/p_main.f90:11
#10  0x401866 in main
at /nethome/hberre3/bug/p_main.f90:3
run.sh: line 17: 3052573 Aborted (core dumped) ./main
```

I am not sure if this error is from libgomp or another part of the GCC
codebase. I assume it is related to an issue with the scoping of the array, as
it should be available throughout the entire program, per my reading of the
OpenACC spec:
```
The associated region is the implicit region associated with the function,
subroutine, or program in which the directive appears. If the directive appears
in the declaration section of a Fortran module subprogram or in a C or C++
global scope, the associated region is the implicit region for the whole
program. 
```

Our main code currently doesn't call `!$acc enter data create` for dynamically
allocated arrays since it relies on NVIDIA (/PGI) hooking into the `allocate`
call on the CPU. I ran into the above error when 

[Bug target/106637] docs: link to www.bullfreeware.com is dead

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

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

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from David Edelsohn  ---
ATOS / Groupe Bull has discontinued its Freeware offering.  The link should be
removed from the web page.

[Bug middle-end/106548] [OpenMP] ICE in #pragma openmp parallel for simd linear with long long variables

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

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

--- Comment #3 from Tobias Burnus  ---
Submitted patch:
  https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599832.html

[Bug fortran/106566] [OpenMP] declare simd fails with with bogus "already been host associated" for module procedures

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

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

--- Comment #3 from Tobias Burnus  ---
Patch for the rejects-valid issue of module variable + a fix
for an absent linear step with OpenMP 5.2 syntax:
  https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599829.html

As mentioned, the declarative directive before IMPORT/IMPLICIT/USE issue
is a only invalid since OpenMP 5.1 - and tracked in PR106639.

[Bug target/106637] docs: link to www.bullfreeware.com is dead

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

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

--- Comment #1 from Andrew Pinski  ---
https://github.com/power-devops/bullfreeware

Looks like it was closed in May 2022.

[Bug analyzer/106634] [13 Regression] ICE in get_region_for_local, at analyzer/region.cc:874 since r13-2029-g7e3b45befdbbf1a1

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

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

David Malcolm  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106441

--- Comment #2 from David Malcolm  ---
It's failing this assertion in frame_region::get_region_for_local:
  gcc_assert (DECL_CONTEXT (expr) == m_fun->decl);

Probably relates to PR 106441, in that the analyzer doesn't yet have any
knowledge of GCC's nested functions extension to C.

[Bug c/100420] unspecified VLA bound formatted as [0] instead of [*] in -Wvla-parameter

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-08-16
  Known to fail||11.1.0, 12.1.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 11 and 12.

[Bug c/101605] bogus -Wvla-parameter in same bound expression with differently named parameters

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2021-07-23 00:00:00 |2022-08-16
  Known to fail||11.1.0, 12.1.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 11 and 12.

[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions since r13-322-g7f04b0d786e13ff5

[pivanov at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from pivanov at hotmail dot com ---
(In reply to Martin Liška from comment #9)
> Started with r13-322-g7f04b0d786e13ff5.

I do confirm that after reverting this commit there is no more hanging when
compiling (bug 106642)

[Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions since r13-322-g7f04b0d786e13ff5

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pivanov at hotmail dot com

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

[Bug middle-end/106642] cc1 compiler hangs when cross-compiling ring_buffer.c (from kernel/events) on Aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Yes it is a dup of bug 106617.

> It really looks like endless recursion as the whole memory gets exhausted if 
> I leave it running long enough.

That is because the original testcase is reduced further to figure out what is
going on. But it is the same

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

[Bug middle-end/106642] cc1 compiler hangs when cross-compiling ring_buffer.c (from kernel/events) on Aarch64

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

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

--- Comment #5 from Andrew Pinski  ---

  max_order = ( __builtin_constant_p(nr_pages) ? (
__builtin_constant_p(nr_pages) ? ( (nr_pages) < 2 ? 0 : (nr_pages) & (1ULL <<
63) ? 63 : (nr_pages) & (1ULL << 62) ? 62 : (nr_pages) & (1ULL << 61) ? 61 :
(nr_pages) & (1ULL << 60) ? 60 : (nr_pages) & (1ULL << 59) ? 59 : (nr_pages) &
(1ULL << 58) ? 58 : (nr_pages) & (1ULL << 57) ? 57 : (nr_pages) & (1ULL << 56)
? 56 : (nr_pages) & (1ULL << 55) ? 55 : (nr_pages) & (1ULL << 54) ? 54 :
(nr_pages) & (1ULL << 53) ? 53 : (nr_pages) & (1ULL << 52) ? 52 : (nr_pages) &
(1ULL << 51) ? 51 : (nr_pages) & (1ULL << 50) ? 50 : (nr_pages) & (1ULL << 49)
? 49 : (nr_pages) & (1ULL << 48) ? 48 : (nr_pages) & (1ULL << 47) ? 47 :
(nr_pages) & (1ULL << 46) ? 46 : (nr_pages) & (1ULL << 45) ? 45 : (nr_pages) &
(1ULL << 44) ? 44 : (nr_pages) & (1ULL << 43) ? 43 : (nr_pages) & (1ULL << 42)
? 42 : (nr_pages) & (1ULL << 41) ? 41 : (nr_pages) & (1ULL << 40) ? 40 :
(nr_pages) & (1ULL << 39) ? 39 : (nr_pages) & (1ULL << 38) ? 38 : (nr_pages) &
(1ULL << 37) ? 37 : (nr_pages) & (1ULL << 36) ? 36 : (nr_pages) & (1ULL << 35)
? 35 : (nr_pages) & (1ULL << 34) ? 34 : (nr_pages) & (1ULL << 33) ? 33 :
(nr_pages) & (1ULL << 32) ? 32 : (nr_pages) & (1ULL << 31) ? 31 : (nr_pages) &
(1ULL << 30) ? 30 : (nr_pages) & (1ULL << 29) ? 29 : (nr_pages) & (1ULL << 28)
? 28 : (nr_pages) & (1ULL << 27) ? 27 : (nr_pages) & (1ULL << 26) ? 26 :
(nr_pages) & (1ULL << 25) ? 25 : (nr_pages) & (1ULL << 24) ? 24 : (nr_pages) &
(1ULL << 23) ? 23 : (nr_pages) & (1ULL << 22) ? 22 : (nr_pages) & (1ULL << 21)
? 21 : (nr_pages) & (1ULL << 20) ? 20 : (nr_pages) & (1ULL << 19) ? 19 :
(nr_pages) & (1ULL << 18) ? 18 : (nr_pages) & (1ULL << 17) ? 17 : (nr_pages) &
(1ULL << 16) ? 16 : (nr_pages) & (1ULL << 15) ? 15 : (nr_pages) & (1ULL << 14)
? 14 : (nr_pages) & (1ULL << 13) ? 13 : (nr_pages) & (1ULL << 12) ? 12 :
(nr_pages) & (1ULL << 11) ? 11 : (nr_pages) & (1ULL << 10) ? 10 : (nr_pages) &
(1ULL << 9) ? 9 : (nr_pages) & (1ULL << 8) ? 8 : (nr_pages) & (1ULL << 7) ? 7 :
(nr_pages) & (1ULL << 6) ? 6 : (nr_pages) & (1ULL << 5) ? 5 : (nr_pages) &
(1ULL << 4) ? 4 : (nr_pages) & (1ULL << 3) ? 3 : (nr_pages) & (1ULL << 2) ? 2 :
1) : -1) : (sizeof(nr_pages) <= 4) ? __ilog2_u32(nr_pages) :
__ilog2_u64(nr_pages) );

[Bug middle-end/106642] cc1 compiler hangs when cross-compiling ring_buffer.c (from kernel/events) on Aarch64

[pivanov at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from pivanov at hotmail dot com ---
It really looks like endless recursion as the whole memory gets exhausted if I
leave it running long enough.

What I see in bug 106617 description
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617) is that it just works
slowly but gets the work done.

[Bug middle-end/106642] cc1 compiler hangs when cross-compiling ring_buffer.c (from kernel/events) on Aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||106617

--- Comment #3 from Andrew Pinski  ---
I am 99% sure this is a duplicate of bug 106617


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106617
[Bug 106617] [13 Regression] gcc is very slow at ternary expressions since
r13-322-g7f04b0d786e13ff5

[Bug middle-end/106642] cc1 compiler hangs when cross-compiling ring_buffer.c (from kernel/events) on Aarch64

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Richard Earnshaw  ---
Seems to be stuck in a recursive loop:

#9  0x01700472 in generic_simplify_GT_EXPR (loc=2147516709, 
type=0x7752a5e8, _p0=0x75a65900, _p1=0x772fb288, 
code=) at generic-match.cc:75812
#10 0x017ae6ee in generic_simplify (loc=loc@entry=2147516709, 
code=code@entry=GT_EXPR, type=type@entry=0x7752a5e8, 
_p0=_p0@entry=0x75a65900, _p1=_p1@entry=0x772fb288)
at generic-match.cc:93192
#11 0x00c33376 in fold_binary_loc (loc=2147516709, code=GT_EXPR, 
type=0x7752a5e8, op0=0x75a65900, op1=0x772fb288)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/fold-const.cc:10893
#12 0x00c3b8fe in fold_build2_loc (loc=loc@entry=2147516709, 
code=code@entry=GT_EXPR, type=type@entry=0x7752a5e8, 
op0=op0@entry=0x75a65900, op1=0x772fb288)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/fold-const.cc:13845
#13 0x016a0eff in generic_simplify_22 (loc=2147516709, 
type=0x7752a5e8, captures=0x7ffe8140, cmp=GT_EXPR, 
_p1=, _p0=) at generic-match.cc:2445
#14 0x01700472 in generic_simplify_GT_EXPR (loc=2147516709, 
type=0x7752a5e8, _p0=0x75a65930, _p1=0x772fb288, 
code=) at generic-match.cc:75812

[Bug c/106642] cc1 compiler hangs when cross-compiling ring_buffer.c (from kernel/events) on Aarch64

[pivanov at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from pivanov at hotmail dot com ---
Created attachment 53466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53466=edit
Preprocessed file that triggers the hang

[Bug c/106642] New: cc1 compiler hangs when cross-compiling ring_buffer.c (from kernel/events) on Aarch64

[pivanov at hotmail dot com via Gcc-bugs]

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

Bug ID: 106642
   Summary: cc1 compiler hangs when cross-compiling ring_buffer.c
(from kernel/events) on Aarch64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pivanov at hotmail dot com
  Target Milestone: ---

Compiler hangs forever and consumes all available memory when cross-compiling
android kernel tree.

The file that it hangs on is kernel/events/ring_buffer.c

You may find the preprocessed ring_buffer.i attached.

Compiler version and flags (source code checked out @ commit 1c596391e):
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1c596391e150a6b0c55960c1c1cf1da76ea78230


/storage/gcc-arm64/bin/aarch64-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/storage/gcc-arm64/bin/aarch64-elf-gcc
COLLECT_LTO_WRAPPER=/storage/gcc-arm64/bin/../libexec/gcc/aarch64-elf/13.0.0/lto-wrapper
Target: aarch64-elf
Configured with: ../gcc/configure --target=aarch64-elf CFLAGS='-flto
-flto-compression-level=10 -O3 -pipe -ffunction-sections -fdata-sections'
CXXFLAGS='-flto -flto-compression-level=10 -O3 -pipe -ffunction-sections
-fdata-sections' --prefix=/storage/gcc-arm64 --disable-decimal-float
--disable-gcov --disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-docs --enable-default-ssp --enable-languages=c,c++
--enable-threads=posix --with-pkgversion='Eva GCC' --with-newlib --with-gnu-as
--with-gnu-ld --with-linker-hash-style=gnu --with-sysroot
--with-headers=/usr/include
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220816 (Bleeding Edge) (Eva GCC)



Command line used that hangs compiler:


/storage/gcc-arm64/bin/aarch64-elf-gcc -Wp,-MD,kernel/events/.ring_buffer.o.d
-nostdinc -isystem
/ext/gcc-arm64-gcc-master/bin/../lib/gcc/aarch64-elf/13.0.0/include
-I../arch/arm64/include -I./arch/arm64/include/generated  -I../include
-I./include -I../arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi
-I../include/uapi -I./include/generated/uapi -include
../include/linux/kconfig.h  -I../kernel/events -Ikernel/events -D__KERNEL__
-mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT=3 -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar
-Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE
-fno-gcse -mgeneral-regs-only -DCONFIG_AS_LSE=1 -DCONFIG_VDSO32=1
-fno-asynchronous-unwind-tables -fno-pic -mabi=lp64
-DCONFIG_ARCH_SUPPORTS_INT128 -DKASAN_SHADOW_SCALE_SHIFT=3 -O3
-mcpu=cortex-a76.cortex-a55+crypto+crc+lse+fp16+rcpc+rdma+dotprod
-mtune=cortex-a76.cortex-a55 -fgraphite-identity -floop-nest-optimize
-fno-semantic-interposition -fdevirtualize-at-ltrans -fipa-pta -fno-plt
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation
-Wno-format-overflow -Wno-int-in-bool-context -Wno-address-of-packed-member
-Wno-attribute-alias -O3
-mcpu=cortex-a76.cortex-a55+crypto+crc+lse+fp16+rcpc+rdma+dotprod
-mtune=cortex-a76.cortex-a55 -fgraphite-identity -floop-nest-optimize
-fno-semantic-interposition -fdevirtualize-at-ltrans -fipa-pta -fno-plt
-fno-allow-store-data-races -DCC_HAVE_ASM_GOTO -fstack-protector-strong
-fno-delete-null-pointer-checks -Wno-unused-but-set-variable
-Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -ffunction-sections -fdata-sections
-Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation
-Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict
-Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants
-fmerge-constants -fno-stack-check -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -fmacro-prefix-map=../= -fgcse-sm
-Wno-packed-not-aligned-DKBUILD_BASENAME='"ring_buffer"' 
-DKBUILD_MODNAME='"ring_buffer"' -c -o kernel/events/ring_buffer.o
../kernel/events/ring_buffer.c



The same command line hangs on the attached preprocessed file (ring_buffer.i)
so the bug should be fully reproducible.

I did try to alter options from the command line above but couldn't make it to
compile no matter what options have been removed.

[Bug c++/101165] [C++23] P2266R1 - Simpler implicit move

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
This proposal has been approved by CWG.  I'll adjust our cxx-status.

[Bug target/106640] [13 Regression] during RTL pass: stv ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx ashift) in compute_convert_gain, at config/i386/i386-features.cc:1251/1285

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 CC||roger at nextmovesoftware dot 
com
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 Status|NEW |ASSIGNED

--- Comment #1 from Roger Sayle  ---
Doh!  For some reason I used "op1val = XINT (src, 1);" instead if "op1val =
INTVAL (XEXP (src, 1));".  Thanks for catching this.  I'm bootstapping and
regression testing a fix now.

[Bug driver/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16a48

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

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

--- Comment #12 from Sergei Trofimovich  ---
Should be fixed now.

[Bug driver/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16a48

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

https://gcc.gnu.org/g:2b403297b111c990c331b5bbb6165b061ad2259b

commit r13-2075-g2b403297b111c990c331b5bbb6165b061ad2259b
Author: Sergei Trofimovich 
Date:   Tue Aug 16 12:35:07 2022 +0100

driver: fix environ corruption after putenv() [PR106624]

The bug appeared afte r13-2010-g1270ccda70ca09 "Factor out
jobserver_active_p" slightly changed `putenv()` use from allocating
to non-allocating:

-xputenv (concat ("MAKEFLAGS=", dup, NULL));
+xputenv (jinfo.skipped_makeflags.c_str ());

`xputenv()` (and `putenv()`) don't copy strings and only store the
pointer in the `environ` global table. As a result `environ` got
corrupted as soon as `jinfo.skipped_makeflags` store got deallocated.

This started causing bootstrap crashes in `execv()` calls:

xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2':
execv: Bad address

The change restores memory allocation for `xputenv()` argument.

gcc/

PR driver/106624
* gcc.cc (driver::detect_jobserver): Allocate storage xputenv()
argument using xstrdup().

[Bug target/106640] [13 Regression] during RTL pass: stv ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx ashift) in compute_convert_gain, at config/i386/i386-features.cc:1251/1285

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-16
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug driver/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16a48

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

  Component|bootstrap   |driver

--- Comment #10 from Sergei Trofimovich  ---
Let's declare it a driver bug.

Proposed the patch as:

https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599799.html

[Bug d/106638] docs: bad links to DIPs

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #7 from Iain Buclaw  ---
Went through all open release branches and updated all wiki links to point at
the github repository.

[Bug d/106638] docs: bad links to DIPs

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

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

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

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

commit r10-10947-gb4ecafb9acd8a7e7eb3da92ac973cb07f0f39d40
Author: Iain Buclaw 
Date:   Tue Aug 16 12:22:10 2022 +0200

d: Update DIP links in gdc documentation to point at upstream repository

The wiki links probably worked at some point in the distant past, but
now the official location of tracking all D Improvement Proposals is on
the upstream dlang/DIPs GitHub repository.

PR d/106638

gcc/d/ChangeLog:

* gdc.texi: Update DIP links to point at upstream dlang/DIPs
repository.

(cherry picked from commit e56b695aa3aed3c0c80616bba569bbeb4a06b5e5)

[Bug d/106638] docs: bad links to DIPs

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

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

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

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

commit r11-10206-gbe0bd70649cbb3bdf998069a279d806e1e94a093
Author: Iain Buclaw 
Date:   Tue Aug 16 12:22:10 2022 +0200

d: Update DIP links in gdc documentation to point at upstream repository

The wiki links probably worked at some point in the distant past, but
now the official location of tracking all D Improvement Proposals is on
the upstream dlang/DIPs GitHub repository.

PR d/106638

gcc/d/ChangeLog:

* gdc.texi: Update DIP links to point at upstream dlang/DIPs
repository.

(cherry picked from commit e56b695aa3aed3c0c80616bba569bbeb4a06b5e5)

[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16

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

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

--- Comment #9 from Martin Liška  ---
Thanks for finding out!

To be honest, I verified that path leading to env_manager::xput, but it does
string copy only if m_can_restore.

The patch is fine, please send it to gcc-patches as obvious!

[Bug d/106638] docs: bad links to DIPs

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

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

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

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

commit r12-8691-gf6431df36461ba88f462b153fb21f6ca7497a30a
Author: Iain Buclaw 
Date:   Tue Aug 16 12:22:10 2022 +0200

d: Update DIP links in gdc documentation to point at upstream repository

The wiki links probably worked at some point in the distant past, but
now the official location of tracking all D Improvement Proposals is on
the upstream dlang/DIPs GitHub repository.

PR d/106638

gcc/d/ChangeLog:

* gdc.texi: Update DIP links to point at upstream dlang/DIPs
repository.

(cherry picked from commit e56b695aa3aed3c0c80616bba569bbeb4a06b5e5)

[Bug target/106635] AARCH64 STUR instruction causes bus error

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #5 from Richard Earnshaw  ---
Your original code contains (after stripping out the volatile):
u32 temp_32 = (u32)status_data_base_addr;
*dst++ = temp_32;
data_length++;

if(sizeof(addr_t) == 8) {
  *dst++ = (u32)(((u64)status_data_base_addr)>>32);
  data_length++;
}

Which of course on a 64-bit machine simplifies to 

u32 temp_32 = (u32)status_data_base_addr;
*dst++ = temp_32;
data_length++;

*dst++ = (u32)(((u64)status_data_base_addr)>>32);
data_length++;

And which the compiler then further simplifies to 

   *([unaligned]u64*)dst = status_data_base_addr;
   data_length += 2;
   dst += 2;

If the location that dst points to is in normal, cachable, memory, then this
will be fine.  But if you're writing to non-cachable memory, then you might get
a trap.

the correct fix is to mark dst as volatile in this case.

void CWLCollectReadRegData(volatile u32* dst,u16 reg_start, u32 reg_length,u32*
total_length, addr_t status_data_base_addr)

[Bug demangler/106641] New: Endless Looping & Abnormal Memory Occupatio

[chkunq at gmail dot com via Gcc-bugs]

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

Bug ID: 106641
   Summary: Endless Looping & Abnormal Memory Occupatio
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chkunq at gmail dot com
  Target Milestone: ---

Created attachment 53465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53465=edit
The input object file of binutils/nm that trigger an endless looping in
rust-demangler

When I executed binutils/nm-new with the command `nm-new -C [file in
attachment]`, I found that nm-new could not be executed within 24h and was
taking up an unusually large amount of memory.
Using gdb and inserting printf statements, I traced the problem to
libiberty/rust-demangle.c.

When parsing the symbol _RYOFGFF1FF_array_start, demangle_binder()
internally enters a dead loop (line 657).

When I implanted the printf statement and recompiled, I found that the number
of loops was unusually large (line 653), with a value of 9096425505278371,
which is clearly not normal for looping so many times.
And during the loop, it takes up a lot of memory (>30G), which may cause a
memory overflow.

Here is the call stack (from gdb)

#4  0x55644036 in demangle_binder (rdm=0x7fffd9b0)
at ./rust-demangle.c:662
#5  0x55644f2c in demangle_type (rdm=0x7fffd9b0)
at ./rust-demangle.c:956
#6  0x55644dc4 in demangle_type (rdm=0x7fffd9b0)
at ./rust-demangle.c:920
#7  0x556445a6 in demangle_path (
rdm=rdm@entry=0x7fffd9b0, in_value=in_value@entry=1)
at ./rust-demangle.c:759
#8  0x556456fd in demangle_path (in_value=1, 
rdm=0x7fffd9b0) at ./rust-demangle.c:1482
#9  rust_demangle_callback (mangled=, 
options=options@entry=259, 
callback=callback@entry=0x55645500 ,
opaque=opaque@entry=0x7fffda20) at ./rust-demangle.c:1482
#10 0x5564590d in rust_demangle (mangled=, 
options=options@entry=259) at ./rust-demangle.c:1593
#11 0x5563226f in cplus_demangle (
mangled=mangled@entry=0x556a7cc5 "_RYOFGFF1FF_array_start",
options=259, options@entry=3) at ./cplus-dem.c:166
#12 0x5558cfa3 in bfd_demangle (abfd=, 
name=0x556a7cc5 "_RYOFGFF1FF_array_start", options=3)
at bfd.c:2428
#13 0x555827cb in print_symname (form=0x55656c2c " %s", 
info=0x7fffdb80, 
name=0x556a7cc5 "_RYOFGFF1FF_array_start",

[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16

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

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

--- Comment #8 from Sergei Trofimovich  ---
I think I understand now why it's such a mysterious failure. gcc uses putenv()
incorrectly!

I think the real bug was introduced in: commit 1270ccda70ca09f7d4 "Factor out
jobserver_active_p.".

It's gist is the change from `xputenv (concat ("MAKEFLAGS=", dup, NULL));` to
`xputenv (jinfo.skipped_makeflags.c_str ());`.

The difference here is what happens with memory allocated to be put into
putenv().

putenv() is an odd API as it does not copy data, it just interns the pointer:


// $ cat a.c
#include 
#include 
#include 

char arr[1000] = "FOO=1234";

int main() {
putenv(arr);
printf("getenv(FOO)='%s'\n", getenv("FOO"));
sprintf(arr + strlen("FOO="), "");
printf("getenv(FOO)='%s'\n", getenv("FOO"));
}

Thus `xputenv (jinfo.skipped_makeflags.c_str ());` gets clobbered with garbage
as soon as string is freed and reallocated. I think commit 53e3b2bf16a486c
"lto: support --jobserver-style=fifo for recent GNU make" only happens to
tickle string reallocation as it does things with more std::strings.

As a hack it looks like the following is enough to build a gcc for me:

--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -9182,7 +9182,7 @@ driver::detect_jobserver () const
 {
   jobserver_info jinfo;
   if (!jinfo.is_active && !jinfo.skipped_makeflags.empty ())
-xputenv (jinfo.skipped_makeflags.c_str ());
+xputenv (xstrdup(jinfo.skipped_makeflags.c_str ()));
 }

 /* Determine what the exit code of the driver should be.  */

Not sure what should be used instead for proper memory management.

[Bug target/106640] New: [13 Regression] during RTL pass: stv ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx ashift) in compute_convert_gain, at config/i386/i386-features.cc:1251/1285

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106640
   Summary: [13 Regression] during RTL pass: stv ICE: RTL check:
expected elt 1 type 'i' or 'n', have 'e' (rtx ashift)
in compute_convert_gain, at
config/i386/i386-features.cc:1251/1285
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  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 53464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53464=edit
reduced testcase

Might need RTL checking enabled.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 testcase.c -Wno-psabi
during RTL pass: stv
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: RTL check: expected elt 1 type 'i' or
'n', have 'e' (rtx ashiftrt) in compute_convert_gain, at
config/i386/i386-features.cc:1285
9 | }
  | ^
0x77aa03 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.cc:907
0x854675 compute_convert_gain
/repo/gcc-trunk/gcc/config/i386/i386-features.cc:1285
0x183ddcf convert_scalars_to_vector
/repo/gcc-trunk/gcc/config/i386/i386-features.cc:2225
0x183ddcf execute
/repo/gcc-trunk/gcc/config/i386/i386-features.cc:2389
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> 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=/mnt/main-repo/repo/gcc-trunk/binary-trunk-r13-2065-20220816100512-g1c596391e15-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/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
--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 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-2065-20220816100512-g1c596391e15-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220816 (experimental) (GCC) 

Happens with the pr106577 patch as well.

[Bug d/106638] docs: bad links to DIPs

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r13-2073-ge56b695aa3aed3c0c80616bba569bbeb4a06b5e5
Author: Iain Buclaw 
Date:   Tue Aug 16 12:22:10 2022 +0200

d: Update DIP links in gdc documentation to point at upstream repository

The wiki links probably worked at some point in the distant past, but
now the official location of tracking all D Improvement Proposals is on
the upstream dlang/DIPs GitHub repository.

PR d/106638

gcc/d/ChangeLog:

* gdc.texi: Update DIP links to point at upstream dlang/DIPs
repository.

[Bug d/106638] docs: bad links to DIPs

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #2 from Iain Buclaw  ---
(In reply to Martin Liška from comment #1)
> Should likely lead to something like:
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md
Indeed, I'm sure the wiki links were working at one point in time, but the
github repository is the official place where they are kept now.

[Bug middle-end/106548] [OpenMP] ICE in #pragma openmp parallel for simd linear with long long variables

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

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

--- Comment #2 from Tobias Burnus  ---
The problem is the following code in omp-low.c:

do_firstprivate:
  lower_private_allocate (var, new_var, allocator, allocate_ptr,
  ilist, ctx, false, NULL_TREE);
  x = build_outer_var_ref (var, ctx);
  if (is_simd)
{
  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_LINEAR
  && gimple_omp_for_combined_into_p (ctx->stmt))
{
  tree t = OMP_CLAUSE_LINEAR_STEP (c);

where the clause ('c') is
   ( == var)
op-1: 

and 't' is
  

[Bug middle-end/106548] [OpenMP] ICE in #pragma openmp parallel for simd linear with long long variables

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

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

--- Comment #1 from Tobias Burnus  ---
The ICE is for:

expand_expr_real_1's

10721 gcc_assert (SCOPE_FILE_SCOPE_P (context)
10722 || context == current_function_decl
10723 || TREE_STATIC (exp)
10724 || DECL_EXTERNAL (exp)

where  context)  is  function_decl f3
butcurrent_function_decl  is  function_decl f3._omp_fn.0

Here, exp is a  long long int  ssa_name with 'visited var '
and the Gimple stmt is:
  _35 = _33 * k_34(D);

The dump is:
  void f3._omp_fn.0 (...)
  ...
 :
k_13 = .omp_data_i_12(D)->k;
...
_35 = _33 * k_34(D);

Thus, it seems as if some VALUE_EXPR is not taken into account?

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

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

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

Bug 106630 Summary: [13 Regression] ICE: Segmentation fault signal terminated 
program cc1plus with -O2 since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630

   What|Removed |Added

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

[Bug tree-optimization/106630] [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2 since r13-1268-g8c99e307b20c50

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug tree-optimization/106630] [13 Regression] ICE: Segmentation fault signal terminated program cc1plus with -O2 since r13-1268-g8c99e307b20c50

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:5e88fccf4be7e8ab22734d87f8e520b25d92d845

commit r13-2069-g5e88fccf4be7e8ab22734d87f8e520b25d92d845
Author: Richard Biener 
Date:   Tue Aug 16 09:43:24 2022 +0200

middle-end/106630 - avoid ping-pong between extract_muldiv and match.pd

The following avoids ping-pong between the match.pd pattern changing
(sizetype) ((a_9 + 1) * 48) to (sizetype)(a_9 + 1) * 48 and
extract_muldiv performing the reverse transform by restricting the
match.pd pattern to narrowing conversions as the comment indicates.

PR middle-end/106630
* match.pd ((T)(x * CST) -> (T)x * CST): Restrict to
narrowing conversions.

* gcc.dg/torture/pr106630.c: New testcase.

[Bug target/106635] AARCH64 STUR instruction causes bus error

[xgchenshy at 126 dot com via Gcc-bugs]

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

--- Comment #4 from Xiaoguang  ---
(In reply to Xiaoguang from comment #2)
> (In reply to Richard Biener from comment #1)
> > Can you provide preprocessed source of the whole translation unit so the
> > testcase is compilable?
> 
> Sure, please see below complete code.
> 
> void CWLCollectReadRegData(u32* dst,u16 reg_start, u32 reg_length,u32*
> total_length, addr_t status_data_base_addr)
> {
>   u32 data_length=0;
>   {
> //opcode
> *dst++ = (OPCODE_RREG<<27)|(reg_length<<16)|(reg_start*4);
> data_length++;
>  
> //data
> volatile u32 temp_32 = (u32)status_data_base_addr; // fix compiler
> optimization -O2 bug:  stur  x4, [x0, #4]
> *dst++ = temp_32;
> data_length++;
>  
> if(sizeof(addr_t) == 8) {
>   *dst++ = (u32)(((u64)status_data_base_addr)>>32);
>   data_length++;
> } else {
>   *dst++ = 0;
>   data_length++;
> }
> //alignment
> *dst = 0;
> data_length++;
>  
> *total_length = data_length;
>   }
> }

please ignore this, we added volatile to avoid such issue

[Bug target/106635] AARCH64 STUR instruction causes bus error

[xgchenshy at 126 dot com via Gcc-bugs]

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

--- Comment #3 from Xiaoguang  ---
(In reply to Richard Biener from comment #1)
> Can you provide preprocessed source of the whole translation unit so the
> testcase is compilable?

please see below code:
void CWLCollectReadRegData(u32* dst,u16 reg_start, u32 reg_length,u32*
total_length, addr_t status_data_base_addr)
{
  u32 data_length=0;
  {
//opcode
*dst++ = (OPCODE_RREG<<27)|(reg_length<<16)|(reg_start*4);
data_length++;

//data
*dst++ = (u32)status_data_base_addr;
data_length++;

if(sizeof(addr_t) == 8) {
  *dst++ = (u32)(((u64)status_data_base_addr)>>32);
  data_length++;
} else {
  *dst++ = 0;
  data_length++;
}
//alignment
*dst = 0;
data_length++;

*total_length = data_length;
  }
}

[Bug target/106635] AARCH64 STUR instruction causes bus error

[xgchenshy at 126 dot com via Gcc-bugs]

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

--- Comment #2 from Xiaoguang  ---
(In reply to Richard Biener from comment #1)
> Can you provide preprocessed source of the whole translation unit so the
> testcase is compilable?

Sure, please see below complete code.

void CWLCollectReadRegData(u32* dst,u16 reg_start, u32 reg_length,u32*
total_length, addr_t status_data_base_addr)
{
  u32 data_length=0;
  {
//opcode
*dst++ = (OPCODE_RREG<<27)|(reg_length<<16)|(reg_start*4);
data_length++;

//data
volatile u32 temp_32 = (u32)status_data_base_addr; // fix compiler
optimization -O2 bug:  stur  x4, [x0, #4]
*dst++ = temp_32;
data_length++;

if(sizeof(addr_t) == 8) {
  *dst++ = (u32)(((u64)status_data_base_addr)>>32);
  data_length++;
} else {
  *dst++ = 0;
  data_length++;
}
//alignment
*dst = 0;
data_length++;

*total_length = data_length;
  }
}

[Bug fortran/106566] [OpenMP] declare simd fails with with bogus "already been host associated" for module procedures

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

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

--- Comment #2 from Tobias Burnus  ---
The ordering part (must be after IMPORT/IMPLICIT/USE) is now tracked in
PR106639 - note that forcing it after IMPORT/IMPLICIT/USE is new since OpenMP
5.1.

[Bug fortran/106639] New: [OpenMP][5.1] Diagnose when OpenMP declarative directive appears before IMPORT/USE/IMPLICIT

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

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

Bug ID: 106639
   Summary: [OpenMP][5.1] Diagnose when OpenMP declarative
directive appears before IMPORT/USE/IMPLICIT
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Depends on: 106566
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #106566 +++

OpenMP 5.1 added to the glossary entry "declarative directive":

"For Fortran, a declarative directive must appear after any USE, IMPORT, and
IMPLICIT statements in a declarative context."

Before, it was valid everywhere in the specification part.

Example:  VALID in 5.0 but invalid since 5.1:

   subroutine add_one2(p)
 !$omp declare simd(add_one2) linear(p: ref) simdlen(8)
 implicit none  !  invalid in 5.1 because after '!$omp declare'
 integer :: p

 p = p + 1
   end subroutine


Ignoring OpenMP < 5.1 backward compatibility, the following would do, but gives
a hard error for pre-5.1 code. (Plus splitting the '#define case_omp_decl'.)

However, I think we rather want to warn (→ backward compat) instead of erroring
out → e.g. set a flag and check it in ST_... for IMPORT/IMPLICIT/USE + warn.


--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -3021,4 +3026,4 @@ verify_st_order (st_state *p, gfc_statement st, bool
silent)

-case_omp_decl:
-  /* The OpenMP/OpenACC directives have to be somewhere in the
specification
+case_oacc_decl:
+  /* The OpenACC directives have to be somewhere in the specification
 part, but there are no further requirements on their ordering.
@@ -3029,2 +3034,9 @@ verify_st_order (st_state *p, gfc_statement st, bool
silent)

+case_omp_decl:
+  if (p->state >= ORDER_EXEC)
+   goto order;
+  if (p->state < ORDER_SPEC)
+   p->state = ORDER_SPEC;
+  break;
+
 case_executable:


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106566
[Bug 106566] [OpenMP] declare simd fails with with bogus "already been host
associated" for module procedures

[Bug target/106635] AARCH64 STUR instruction causes bus error

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Keywords||wrong-code

--- Comment #1 from Richard Biener  ---
Can you provide preprocessed source of the whole translation unit so the
testcase is compilable?

[Bug d/106638] docs: bad links to DIPs

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-08-16
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Should likely lead to something like:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md

[Bug d/106638] New: docs: bad links to DIPs

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

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

Bug ID: 106638
   Summary: docs: bad links to DIPs
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

The following links are dead:

gcc/d/gdc.texi:

@table @samp
@item all
Turns on all upcoming D language features.
@item dip1000
Implements @uref{https://wiki.dlang.org/DIP1000} (Scoped pointers).
@item dip1008
Implements @uref{https://wiki.dlang.org/DIP1008} (Allow exceptions in
@code{@@nogc} code).
@item dip1021
Implements @uref{https://wiki.dlang.org/DIP1021} (Mutable function arguments).

[Bug lto/100010] [10/11/12/13 Regression] ICE in lto_output_node, at lto-cgraph.c:447 (-fdevirtualize-at-ltrans) since r6-6384-gceda2c69d5219719

[yinyuefengyi at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Xionghu Luo (luoxhu at gcc dot gnu.org)  ---
At the ICE point, node->clone_of has value, but clone_of is NULL:

(gdb) p clone_of
$114 = (cgraph_node *) 0x0
(gdb) p node->clone_of
$115 = (cgraph_node *) 0x76664bb0
(gdb) pnode node->clone_of
_ZN12ErrorHandler8decorateERK6String/0 (decorate)
  Type: function
  Visibility: semantic_interposition virtual
  next sharing asm name: 0
  References:
  Referring:
  Availability: not_available
  Function flags:
  Called by:
  Calls:
(gdb) pnode node
_ZN12ErrorHandler8decorateERK6String/0 (decorate)
  Type: function definition analyzed
  Visibility: semantic_interposition virtual
  previous sharing asm name: 0
  References:
  Referring:
  Read from file: a-pr10010.o
  Function decorate/0 is inline copy in decorate/1
  Clone of _ZN12ErrorHandler8decorateERK6String/0
  Availability: local
  Unit id: 1
  Function flags: count:1073741824 (estimated locally) local
  Called by: _ZN20LandmarkErrorHandler8decorateERK6String/1 (inlined)
(1073741824 (estimated locally),1.00 per call)
  Calls: _ZN6StringD1Ev/37 (1073741824 (estimated locally),1.00 per call)
_ZN6StringC1Ec/38 (1073741824 (estimated loca
lly),1.00 per call) (can throw external)
   Polymorphic indirect call of type struct ErrorHandler token:0(1073741824
(estimated locally),1.00 per call) (can thr
ow external) of param:0 (vptr maybe changed) num speculative call targets: 0
Outer type (dynamic):struct ErrorHandler (or a derived type) offset 0


This simple change could fix but not sure whether it is correct.

diff --git a/gcc/lto-cgraph.cc b/gcc/lto-cgraph.cc
index 6d9c36ea8b6..44a33a2af23 100644
--- a/gcc/lto-cgraph.cc
+++ b/gcc/lto-cgraph.cc
@@ -448,7 +448,7 @@ lto_output_node (struct lto_simple_output_block *ob, struct
cgraph_node *node,
   if (clone_of && !lto_symtab_encoder_encode_body_p (encoder,
ultimate_clone_of))
 clone_of = NULL;

-  if (tag == LTO_symtab_analyzed_node)
+  if (tag == LTO_symtab_analyzed_node && !flag_ltrans_devirtualize)
 gcc_assert (clone_of || !node->clone_of);
   if (!clone_of)
 streamer_write_hwi_stream (ob->main_stream, LCC_NOT_FOUND);

[Bug analyzer/106634] [13 Regression] ICE in get_region_for_local, at analyzer/region.cc:874 since r13-2029-g7e3b45befdbbf1a1

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Priority|P3  |P4

[Bug bootstrap/106624] [13 Regression] LTO plugin fails to build in parallel builds: xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address since r13-2011-g53e3b2bf16

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug target/106637] New: docs: link to www.bullfreeware.com is dead

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

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

Bug ID: 106637
   Summary: docs: link to www.bullfreeware.com is dead
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dje at gcc dot gnu.org
  Target Milestone: ---

gcc/doc/install.texi:

@itemize
@item
AIX:
@itemize
@item
@uref{http://www.bullfreeware.com,,Bull's Open Source Software Archive for
for AIX 6 and AIX 7};

Note the web is not working any longer.