[Bug libstdc++/108118] New: std::weak_ptr lacks a self-usurp check on move

[b.stanimirov at abv dot bg via Gcc-bugs]

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

Bug ID: 108118
   Summary: std::weak_ptr lacks a self-usurp check on move
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.stanimirov at abv dot bg
  Target Milestone: ---

If one somehow move-assigns a weak pointer to itself, it gets destroyed.

Demo: https://godbolt.org/z/eWdhYMhYe

[Bug modula2/108119] New: m2rte Seems like it should not be there at all

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

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

Bug ID: 108119
   Summary: m2rte Seems like it should not be there at all
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

The plugin usage in the gm2 driver is going to break if someone tries to
compile C or fortran code with it. I suspect it will also break using -flto
too.

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||iains at gcc dot gnu.org
   Last reconfirmed||2022-12-15
 Status|UNCONFIRMED |NEW

--- Comment #3 from Iain Sandoe  ---
(In reply to Rainer Orth from comment #1)
> Besides, the m2rte plugin is incorrectly named on Darwin, thus unusable:
> 
> cc1gm2: fatal error: inaccessible plugin file
> /var/gcc/modula-2/10.7-gcc/./gcc/plugin/m2rte.dylib expanded from short
> plugin name m2rte: No such file or directory
> compilation terminated.
> 
> There's code in gcc/jit/Make-lang.in handling the same situation.
> 
> To get further along, I've just manually added a symlink for now.


Hi Rainer, you are ahead of me in testing this (I got bogged down in fixing
libffi for i686 rust use)

Just to note that the values used in gcc/jit/Make-lang.in are still not
completely correct (and that causes problems with cross-compilers where the
target and host linkers are different)

 * because LD_VERSION_SCRIPT_OPTION and LD_SONAME_OPTION are for $target, not
$host.
 * (maybe not relevant to gm2) the .map file is not in a format usable by
Darwin's linker and unfortunately the existing conversion scripts in the tree
do not handle that specific map.

So much of the content is useful for Darwin and mingw but those points need to
be taken into account (rather than copying verbatim).

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

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

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Rainer Orth from comment #1)
> Besides, the m2rte plugin is incorrectly named on Darwin, thus unusable:
> 
> cc1gm2: fatal error: inaccessible plugin file
> /var/gcc/modula-2/10.7-gcc/./gcc/plugin/m2rte.dylib expanded from short
> plugin name m2rte: No such file or directory
> compilation terminated.
> 
> There's code in gcc/jit/Make-lang.in handling the same situation.
> 
> To get further along, I've just manually added a symlink for now.


Hi Rainer, you are ahead of me in testing this (I got bogged down in fixing
libffi for i686 rust use)

Just to note that the values used in gcc/jit/Make-lang.in are still not
completely correct (and that causes problems with cross-compilers where the
target and host linkers are different)

 * because LD_VERSION_SCRIPT_OPTION and LD_SONAME_OPTION are for $target, not
$host.
 * (maybe not relevant to gm2) the .map file is not in a format usable by
Darwin's linker and unfortunately the existing conversion scripts in the tree
do not handle that specific map.

So much of the content is useful for Darwin and mingw but those points need to
be taken into account (rather than copying verbatim).

[Bug c/108120] New: ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)

[m.olbrich at pengutronix dot de via Gcc-bugs]

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

Bug ID: 108120
   Summary: ICE: in extract_insn, at recog.cc:2791 (on ARM with
-mfpu=neon -freciprocal-math -O3)
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.olbrich at pengutronix dot de
  Target Milestone: ---

Created attachment 54100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54100&action=edit
test-case to reproduce the ICE

When building the attached test-case with:

arm-linux-gnueabihf-gcc-12 -mfpu=neon -freciprocal-math -O3  -c w.c  -o
/dev/null

It fails with:

w.c: In function ‘b’:
w.c:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 63 62 64 7 (set (reg:V4SF 209)
(mult:V4SF (reg:V4SF 209)
(reg:V4SF 210))) "w.c":6:21 -1
 (nil))
during RTL pass: vregs
w.c:7:1: internal compiler error: in extract_insn, at recog.cc:2791
0x7f33afb67189 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f33afb67244 __libc_start_main_impl
../csu/libc-start.c:381

This is with arm-linux-gnueabihf-gcc-12 12.2.0-9 from Debian but I've seen it
with the 12-20221022 snapshot and going back to at least gcc 9.2.

-mfpu=neon -freciprocal-math -O3 are all needed to reproduce this. It does not
happen with a different optimization level or -mfpu option.

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

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

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

--- Comment #5 from Iain Sandoe  ---
sorry about the duplicate comment - not quite sure what BZ did there.

Note: dynamic lookups might become an issue for Darwin2* (I expect that there
is a move towards requiring that symbols are resolved to a specific DSO at link
time).

[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-4713-gbf3ce6f84a7a994a0fc87419b383b9ce4efed442
Author: Jakub Jelinek 
Date:   Thu Dec 15 09:26:44 2022 +0100

into-ssa: Fix emitting debug stmts after asm goto [PR108095]

The following testcase ICEs, because ccp1 replaced
  s.0_1 = &s;
  __asm__ goto("" : "=r" MEM[(T *)s.0_1] :  :  : "lab" lab);
with
  __asm__ goto("" : "=r" s :  :  : "lab" lab);
and because s is no longer addressable, we are rewriting it into
ssa and want
  __asm__ goto("" : "=r" s_7 :  :  : "lab" lab);
plus debug stmt
  # DEBUG s => s_7
The code assumes that there is at most one non-EH edge in that
case, but with the addition of outputs to asm goto that is no longer the
case, we can have many outgoing edges.

The patch keeps the checking assertion that there is at most one such
edge for everything but asm goto, but moves the addition of the debug
stmt into the loop, so that it can be added on all edges where it is
possible, not just one of them.

Furthermore, looking at gsi_insert_on_edge_immediate
-> gimple_find_edge_insert_loc, the conditions to insert stmt there
to the destination block are
  if (single_pred_p (dest)
  && gimple_seq_empty_p (phi_nodes (dest))
  && dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
(plus there is code to insert it in the previous block but that is
never true when the pred is known to be stmt_ends_bb_p), while
mayube_register_def was just checking
 if (ef && single_pred_p (ef->dest)
 && ef->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
so if for whatever reason ef->dest had any PHIs, we'd split the
edge for -g and not for -g0, something we must avoid for -fcompare-debug
stability.  So, I've added the no phi_nodes check too.

2022-12-15  Jakub Jelinek  

PR tree-optimization/108095
* tree-into-ssa.cc (maybe_register_def): Insert debug stmt
on all non-EH edges from asm goto if they have a single
predecessor rather than asserting there is at most one such edge.
Test whether there are no PHI nodes next to the single predecessor
test.

* gcc.dg/pr108095.c: New test.

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

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

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #5 from Alexander Monakov  ---
On further thought, this is really an invalid transform, because the value
becomes "clobbered" only if it was changed between setjmp and longjmp:

(C11 7.13.2.1 "The longjmp function")
>  All accessible objects have values, and all other components of the abstract
> machine have state, as of the time the longjmp function was called, except 
> that
> the values of objects of automatic storage duration that are local to the
> function containing the invocation of the corresponding setjmp macro that
> do not have volatile-qualified type and have been changed between the setjmp
> invocation and longjmp call are indeterminate.

In the testcase, the assignment 'vb = 1' did not happen in the abstract
machine.

Moving back to UNCONFIRMED, both because the transform is invalid, and because
lifting assignments to pseudos across calls in sched1 seems useless if not
harmful to performance and code size.

(that said, the -Wclobbered diagnostic still points to a potential issue, so it
shouldn't be ignored)

[Bug target/108120] [11/12/13 Regression] ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.3.0, 13.0, 9.1.0
   Target Milestone|--- |11.4
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-15
Summary|ICE: in extract_insn, at|[11/12/13 Regression] ICE:
   |recog.cc:2791 (on ARM with  |in extract_insn, at
   |-mfpu=neon  |recog.cc:2791 (on ARM with
   |-freciprocal-math -O3)  |-mfpu=neon
   ||-freciprocal-math -O3)

--- Comment #1 from Andrew Pinski  ---
Confirmed. there is a mismatch between div3 and ARM_HAVE_NEON_V2SF_ARITH
(ARM_HAVE_NEON_V4SF_ARITH )

/* SF operations always flush to zero, regardless of FPSCR.FZ, so we can
   only use them for general arithmetic when -funsafe-math-optimizations
   is in effect.  */
#define ARM_HAVE_NEON_V2SF_ARITH \
  (TARGET_NEON && flag_unsafe_math_optimizations)
#define ARM_HAVE_NEON_V4SF_ARITH ARM_HAVE_NEON_V2SF_ARITH

(define_expand "div3"
  [(set (match_operand:VCVTF 0 "s_register_operand")
(div:VCVTF (match_operand:VCVTF 1 "s_register_operand")
  (match_operand:VCVTF 2 "s_register_operand")))]
  "TARGET_NEON && !optimize_size
   && flag_reciprocal_math"


This mismatch was introduced with r9-3954-g536ecfc44b1fd2 which introduced the
div3 (note ARM_HAVE_NEON_V4SF_ARITH was done differently but still have
the check on flag_unsafe_math_optimizations).

I suspect div3 here should become:
(define_expand "div3"
  [(set (match_operand:VCVTF 0 "s_register_operand")
(div:VCVTF (match_operand:VCVTF 1 "s_register_operand")
  (match_operand:VCVTF 2 "s_register_operand")))]
  "ARM_HAVE_NEON__ARITH && !optimize_size
   && flag_reciprocal_math"

Note the iterator here maybe should be VF too but I am not 100% sure the HF
modes support all the instructions that this generates.

[Bug target/108120] [10/11/12/13 Regression] ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||8.1.0
   Target Milestone|11.4|10.5
Summary|[11/12/13 Regression] ICE:  |[10/11/12/13 Regression]
   |in extract_insn, at |ICE: in extract_insn, at
   |recog.cc:2791 (on ARM with  |recog.cc:2791 (on ARM with
   |-mfpu=neon  |-mfpu=neon
   |-freciprocal-math -O3)  |-freciprocal-math -O3)

[Bug modula2/107607] tools-src/calcpath uses unportable realpath(1)

[arsen at aarsen dot me via Gcc-bugs]

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at aarsen dot me

--- Comment #1 from Arsen Arsenović  ---
Created attachment 54101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54101&action=edit
m2: Remove bdepend on realpath, cut and echo

I've already written a patch that removes the realpath invocation.

[Bug modula2/108119] m2rte Seems like it should not be there at all

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

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

--- Comment #1 from Richard Biener  ---
It looks to me the plugin isn't needed to compile m2 programs, it's merely an
additional tool to diagnose invalid code (that is maybe never be reached at
runtime).  So I'd suggest to put this plugin use behind some driver option.

Alternatively the functionality could be lifted to the middle-end for example
by introducing an __attribute__((diagnose_if_invoked_on_function_entry))
that could then emit

warning: 'error' is always invoked when executing 'foo'

for

void __attribute__((diagnose_if_invoked_on_function_entry)) error ();

void foo ()
{
  error ();
}

but I understand the plugin does some whole-program analysis?  That won't
work with LTO at the point the plugin runs.

That said, the immediate thing to do would be to make the plugin build/run
dependent on plugin support.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
803a91330bf20174 seems bad, so trying 095a13eda2caf684.

[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move

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

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

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

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

[Bug modula2/107607] tools-src/calcpath uses unportable realpath(1)

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-15
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||iains at gcc dot gnu.org
   Host||*-*-darwin*

[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move

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

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

--- Comment #2 from Andrew Pinski  ---
Basically you have:
w = std::move(w);

I think that is just undefined code at this point ... But I am not 100% sure.

[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move

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

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

--- Comment #3 from Andrew Pinski  ---
Unless https://cplusplus.github.io/LWG/issue2315 is not implemented ...

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #6 from Feng Xue  ---
(In reply to Andrew Pinski from comment #2)
> https://en.cppreference.com/w/c/program/setjmp

I think that most programmers are not aware of this, neither I for sure. Usage
of volatile here is not that intuitive as for purpose of multi-execution
synchronization, it just tells compiler to keep variable in memory, instead of
register. With current SSA representation in GCC, probably, this could be
automatically identified without explicit source level specifier. That is, any
SSA name occurring in abnormal phi should go to memory during expansion to rtl.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
(In reply to David Binderman from comment #8)
> 803a91330bf20174 seems bad, so trying 095a13eda2caf684.

That seems bad, so trying 4834e9360f7bf42f.

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Feng Xue from comment #6)
> (In reply to Andrew Pinski from comment #2)
> > https://en.cppreference.com/w/c/program/setjmp
> 
> I think that most programmers are not aware of this, neither I for sure.
> Usage of volatile here is not that intuitive as for purpose of
> multi-execution synchronization

You should read up on https://en.cppreference.com/w/cpp/utility/program/signal
too.

[Bug libgomp/108098] OpenMP/nvptx reverse offload execution test FAILs

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

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

--- Comment #1 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #0)
> $ nvidia-smi
> [...]
> | NVIDIA-SMI 440.33.01Driver Version: 440.33.01CUDA Version: 10.2
> [...]
> |   0  Tesla K80  [...]
> [...]
> |   1  Tesla K80  [...]
> 

I'm not sure if it matters for triggering this problem, but if I look at this
board at nvidia drivers download and select cuda 10.2 and production branch, I
get :
...
version:440.118.02
Release Date:   2020.9.30
...

Then using the "Beta and Older Drivers" I find the version you're using is:
...
version: 440.33.01
Release date:  November 19, 2019
...

Please always use the latest drivers when reporting a problem.

[Bug modula2/108121] New: Failing tests on x86_64-linux-gnu

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

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

Bug ID: 108121
   Summary: Failing tests on x86_64-linux-gnu
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu

I noticed the following 2 tests fail:

gm2.log: FAIL: gm2/pim/pass/TestLong4.mod,  -g  
gm2.log: FAIL: gm2/pim/pass/TestLong4.mod,  -O  
gm2.log: FAIL: gm2/pim/pass/TestLong4.mod,  -O -g  
gm2.log: FAIL: gm2/pim/pass/TestLong4.mod,  -Os  
gm2.log: FAIL: gm2/pim/pass/TestLong4.mod,  -O3 -fomit-frame-pointer  
gm2.log: FAIL: gm2/pim/pass/TestLong4.mod,  -O3 -fomit-frame-pointer
-finline-functions  
gm2.log: FAIL: gm2/pim/pass/arraybool.mod,  -g   (internal compiler error:
Aborted)
gm2.log: FAIL: gm2/pim/pass/arraybool.mod,  -O   (internal compiler error:
Aborted)
gm2.log: FAIL: gm2/pim/pass/arraybool.mod,  -O -g   (internal compiler error:
Aborted)
gm2.log: FAIL: gm2/pim/pass/arraybool.mod,  -Os   (internal compiler error:
Aborted)
gm2.log: FAIL: gm2/pim/pass/arraybool.mod,  -O3 -fomit-frame-pointer  
(internal compiler error: Aborted)
gm2.log: FAIL: gm2/pim/pass/arraybool.mod,  -O3 -fomit-frame-pointer
-finline-functions   (internal compiler error: Aborted)


/dev/shm/objdir/gcc/gm2 -B/dev/shm/objdir/gcc
-I/dev/shm/objdir/x86_64-pc-linux-gnu/./libgm2/libm2log:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-libs-pim
-I/dev/shm/objdir/x86_64-pc-linux-gnu/./libgm2/libm2pim:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-libs
-I/dev/shm/objdir/x86_64-pc-linux-gnu/./libgm2/libm2iso:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-libs-iso
-I/home/marxin/Programming/gcc/gcc/testsuite/gm2/pim/pass:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-compiler:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-gcc
-fpim -L/dev/shm/objdir/x86_64-pc-linux-gnu/./libgm2/libm2log/.libs
-L/dev/shm/objdir/x86_64-pc-linux-gnu/./libgm2/libm2pim/.libs
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-plain-output -O3 -fomit-frame-pointer
-finline-functions -c -o /dev/shm/objdir/gcc/testsuite/gm211/arraybool.o
/home/marxin/Programming/gcc/gcc/testsuite/gm2/pim/pass/arraybool.mod
terminate called after throwing an instance of 'unsigned int'
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH| m2rte
cc1gm2: internal compiler error: Aborted
0x214082f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:314
0x27b7e1d __gnu_cxx::__verbose_terminate_handler()
../../../../libstdc++-v3/libsupc++/vterminate.cc:95
0x27b70fb __cxxabiv1::__terminate(void (*)())
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
0x27b7166 std::terminate()
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58
0x27b72c7 __cxa_throw
../../../../libstdc++-v3/libsupc++/eh_throw.cc:98
0x1011deb InvokeHandler
m2/gm2-libs-boot/RTExceptions.c:483
0x1011deb RTExceptions_Raise
m2/gm2-libs-boot/RTExceptions.c:943
0xf89fcf M2LexBuf_MakeVirtualTok
m2/gm2-compiler-boot/M2LexBuf.c:1357
0xf9daba BuildStaticArray
m2/gm2-compiler-boot/M2Quads.c:13084
0xf9daba M2Quads_BuildDesignatorArray
m2/gm2-compiler-boot/M2Quads.c:18617
0xfe017a ArrayExpList
m2/gm2-compiler-boot/P3Build.c:6533
0xfe017a SubDesignator
m2/gm2-compiler-boot/P3Build.c:6496
0xfde222 SimpleDes
m2/gm2-compiler-boot/P3Build.c:6867
0xfde222 SetOrDesignatorOrFunction
m2/gm2-compiler-boot/P3Build.c:6824
0xfde222 Factor
m2/gm2-compiler-boot/P3Build.c:6739
0xfde2b3 Term
m2/gm2-compiler-boot/P3Build.c:6702
0xfde39c UnaryOrTerm
m2/gm2-compiler-boot/P3Build.c:6680
0xfde39c SimpleExpression
m2/gm2-compiler-boot/P3Build.c:6633
0xfde59d Expression
m2/gm2-compiler-boot/P3Build.c:6608
0xfe08f5 IfStatement
m2/gm2-compiler-boot/P3Build.c:7200
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.

spawn -ignore SIGHUP /dev/shm/objdir/gcc/gm2 -B/dev/shm/objdir/gcc
-I/dev/shm/objdir/x86_64-pc-linux-gnu/./libgm2/libm2log:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-libs-pim
-I/dev/shm/objdir/x86_64-pc-linux-gnu/./libgm2/libm2pim:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-libs
-I/dev/shm/objdir/x86_64-pc-linux-gnu/./libgm2/libm2iso:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-libs-iso
-I/home/marxin/Programming/gcc/gcc/testsuite/gm2/pim/pass:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2-compiler:/home/marxin/Programming/gcc/gcc/testsuite/../m2/gm2

[Bug modula2/108121] Failing tests on x86_64-linux-gnu

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

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

--- Comment #1 from Martin Liška  ---
The first fails due to the following valgrind issue:

==2990== Conditional jump or move depends on uninitialised value(s)
==2990==at 0xF94BF4: GenQuadO(unsigned int, M2Quads_QuadOperator, unsigned
int, unsigned int, unsigned int, unsigned int) [clone .part.0]
(M2Quads.c:13971)
==2990==by 0xF99E15: GenQuadO (M2Quads.c:13960)
==2990==by 0xF99E15: doBuildAssignment(unsigned int, unsigned int, unsigned
int) (M2Quads.c:6859)
==2990==by 0xF9EA3D: BuildAssignmentWithoutBounds (M2Quads.c:6671)
==2990==by 0xF9EA3D: ConvertBooleanToVariable(unsigned int, unsigned int)
(M2Quads.c:13684)
==2990==by 0xFE0175: ArrayExpList (P3Build.c:6532)
==2990==by 0xFE0175: SubDesignator(unsigned int, unsigned int, unsigned
int) (P3Build.c:6496)
==2990==by 0xFDE222: SimpleDes (P3Build.c:6867)
==2990==by 0xFDE222: SetOrDesignatorOrFunction (P3Build.c:6824)
==2990==by 0xFDE222: Factor(unsigned int, unsigned int, unsigned int)
(P3Build.c:6739)
==2990==by 0xFDE2B3: Term(unsigned int, unsigned int, unsigned int)
(P3Build.c:6702)
==2990==by 0xFDE39C: UnaryOrTerm (P3Build.c:6680)
==2990==by 0xFDE39C: SimpleExpression(unsigned int, unsigned int, unsigned
int) (P3Build.c:6633)
==2990==by 0xFDE59D: Expression(unsigned int, unsigned int, unsigned int)
(P3Build.c:6608)
==2990==by 0xFE08F5: IfStatement (P3Build.c:7200)
==2990==by 0xFE08F5: Statement(unsigned int, unsigned int, unsigned int)
(P3Build.c:6989)
==2990==by 0xFE142D: StatementSequence(unsigned int, unsigned int, unsigned
int) (P3Build.c:7158)
==2990==by 0xFE166F: NormalPart (P3Build.c:8018)
==2990==by 0xFE166F: InitialBlockBody (P3Build.c:7947)
==2990==by 0xFE166F: InitialBlock (P3Build.c:7907)
==2990==by 0xFE166F: Block(unsigned int, unsigned int, unsigned int)
(P3Build.c:7882)
==2990==by 0xFE2C5D: ProgramModule (P3Build.c:3936)
==2990==by 0xFE2C5D: ImplementationOrProgramModule (P3Build.c:4048)
==2990==by 0xFE2C5D: FileUnit (P3Build.c:3863)
==2990==by 0xFE2C5D: P3Build_CompilationUnit (P3Build.c:9362)

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from David Binderman  ---
That's the bad revision.

  ipa: Better way of applying both IPA-CP and IPA-SRA (PR 103227)

[Bug modula2/108121] Failing tests on x86_64-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-15
   Target Milestone|--- |13.0

[Bug modula2/108122] New: gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod runs too long

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

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

Bug ID: 108122
   Summary: gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod
runs too long
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Running make check-m2 -j32 should finish pretty fast on a modern machine,
however, the mentioned test-case spends a lot of time in sleep calls :)

Please shorten the time periods in it.

[Bug modula2/108122] gcc/testsuite/gm2/pimcoroutines/run/pass/testtime.mod runs too long

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-15
   Target Milestone|--- |13.0

[Bug modula2/108121] Failing tests on x86_64-linux-gnu

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

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

--- Comment #2 from Martin Liška  ---
> gm2.log: FAIL: gm2/pim/pass/TestLong4.mod,  -g  

And this one fails due to UBSAN (signed integer overflow):

/dev/shm/objdir/gcc/gm2 -B/dev/shm/objdir2/gcc
/home/marxin/Programming/gcc/gcc/testsuite/gm2/pim/pass/TestLong4.mod -c
/home/marxin/Programming/gcc/gcc/m2/gm2-gcc/m2expr.cc:4037:13: runtime error:
signed integer overflow: 1717986918 + 429496730 cannot be represented in type
'int'
#0 0x4db49f6 in append_m2_digit
/home/marxin/Programming/gcc/gcc/m2/gm2-gcc/m2expr.cc:4037
#1 0x4db52c0 in m2expr_interpret_m2_integer
/home/marxin/Programming/gcc/gcc/m2/gm2-gcc/m2expr.cc:4106
#2 0x4da403c in m2decl_DetermineSizeOfConstant
/home/marxin/Programming/gcc/gcc/m2/gm2-gcc/m2decl.cc:296
#3 0x4f8879e in GetConstLitType(unsigned int, unsigned int)
(/dev/shm/objdir2/gcc/cc1gm2+0x4f8879e)
#4 0x4f9d0e3 in SymbolTable_MakeConstLit
(/dev/shm/objdir2/gcc/cc1gm2+0x4f9d0e3)
#5 0x4f633a8 in P2SymBuild_BuildNumber
(/dev/shm/objdir2/gcc/cc1gm2+0x4f633a8)
#6 0x4fe4572 in Integer(unsigned int, unsigned int, unsigned int)
(/dev/shm/objdir2/gcc/cc1gm2+0x4fe4572)
#7 0x4fe5076 in Number(unsigned int, unsigned int, unsigned int)
(/dev/shm/objdir2/gcc/cc1gm2+0x4fe5076)
#8 0x4feea69 in Factor(unsigned int, unsigned int, unsigned int)
(/dev/shm/objdir2/gcc/cc1gm2+0x4feea69)

[Bug modula2/108123] New: gcc/m2/gm2config.h.in is out of date

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

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

Bug ID: 108123
   Summary: gcc/m2/gm2config.h.in is out of date
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

When I run autoheader-2.69 in gcc/m2 I get modified gcc/m2/gm2config.h.in:

Can you please re-generate that?

diff --git a/gcc/m2/gm2config.h.in b/gcc/m2/gm2config.h.in
index ced7f4586dc..fe2f81400ed 100644
--- a/gcc/m2/gm2config.h.in
+++ b/gcc/m2/gm2config.h.in
@@ -1,56 +1,70 @@
-/* gm2config.h.in template file for values required by gm2spec.c.
+/* gm2config.h.in.  Generated from configure.ac by autoheader.  */

-Copyright (C) 2006-2022 Free Software Foundation, Inc.
-Contributed by Gaius Mulley .
+/* Define to 1 if you have the  header file, and it defines `DIR'.
+   */
+#undef HAVE_DIRENT_H
+
+/* Define to 1 if you have the  header file. */
+#undef HAVE_INTTYPES_H
+
+/* Define to 1 if you have the  header file. */
+#undef HAVE_MEMORY_H
+
+/* Define to 1 if you have the  header file, and it defines `DIR'. */
+#undef HAVE_NDIR_H
+
+/* found opendir */
+#undef HAVE_OPENDIR

-This file is part of GNU Modula-2.
+/* Define to 1 if you have the  header file. */
+#undef HAVE_STDINT_H

-GNU Modula-2 is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
+/* Define to 1 if you have the  header file. */
+#undef HAVE_STDLIB_H

-GNU Modula-2 is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-General Public License for more details.
+/* Define to 1 if you have the `stpcpy' function. */
+#undef HAVE_STPCPY
+
+/* Define to 1 if you have the  header file. */
+#undef HAVE_STRINGS_H
+
+/* Define to 1 if you have the  header file. */
+#undef HAVE_STRING_H
+
+/* Define to 1 if you have the  header file, and it defines `DIR'.
+   */
+#undef HAVE_SYS_DIR_H
+
+/* Define to 1 if you have the  header file, and it defines `DIR'.
+   */
+#undef HAVE_SYS_NDIR_H

-You should have received a copy of the GNU General Public License
-along with GNU Modula-2; see the file COPYING3.  If not see
-.  */
+/* Define to 1 if you have the  header file. */
+#undef HAVE_SYS_STAT_H
+
+/* Define to 1 if you have the  header file. */
+#undef HAVE_SYS_TYPES_H
+
+/* Define to 1 if you have the  header file. */
+#undef HAVE_UNISTD_H

-#ifndef PACKAGE_BUGREPORT
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
-#endif

-#ifndef PACKAGE_NAME
 /* Define to the full name of this package. */
 #undef PACKAGE_NAME
-#endif

-#ifndef PACKAGE_STRING
 /* Define to the full name and version of this package. */
 #undef PACKAGE_STRING
-#endif
-
-/* Define to 1 if you have the `stpcmp' function. */
-#undef HAVE_STPCMP
-
-/* Define to 1 if you have the dirent.h header. */
-#undef HAVE_DIRENT_H

-/* Define to 1 if you have the sys/ndir.h header. */
-#undef HAVE_SYS_NDIR_H
-
-/* Define to 1 if you have the sys/dir.h header. */
-#undef HAVE_SYS_DIR_H
+/* Define to the one symbol short name of this package. */
+#undef PACKAGE_TARNAME

-/* Define to 1 if you have the ndir.h header. */
-#undef HAVE_NDIR_H
+/* Define to the home page for this package. */
+#undef PACKAGE_URL

-/* Define to 1 if you have the sys/types.h header. */
-#undef HAVE_SYS_TYPES_H
+/* Define to the version of this package. */
+#undef PACKAGE_VERSION

-/* Define to 1 if you have the opendir function.  */
-#undef HAVE_OPENDIR
+/* Define to 1 if you have the ANSI C header files. */
+#undef STDC_HEADERS

[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #2)
> Basically you have:
> w = std::move(w);
> 
> I think that is just undefined code at this point ... But I am not 100% sure.

Nope, it's allowed. But it's not required to be a no-op.

(In reply to Andrew Pinski from comment #3)
> Unless https://cplusplus.github.io/LWG/issue2315 is not implemented ...

That was done years ago: r5-4842-gf871d7f9f458d8

[Bug libstdc++/108118] std::weak_ptr lacks a self-usurp check on move

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-15
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
Actually for this type the standard does require it to be effectively a no-op:

weak_ptr& operator=(weak_ptr&& r) noexcept;

Effects: Equivalent to weak_ptr(std::move(r)).swap(*this).

[Bug rust/108124] New: UBSAN issues when tests are run

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

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

Bug ID: 108124
   Summary: UBSAN issues when tests are run
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

I built GCC compiler with ASAN & UBSAN enabled:
F="-fsanitize=address,undefined -g -O2" ; make -j32 all-host -k CFLAGS="$F"
CXXFLAGS="$F"  LDFLAGS="$F"

and I see a couple of issues:

./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/rust/compile/torture/must_use2.rs -c
/usr/include/c++/12/bits/stl_iterator.h:1096:17: runtime error: reference
binding to null pointer of type 'struct SubstitutionParamMapping'
#0 0x3be00ae in
__gnu_cxx::__normal_iterator > >::operator*() const
/usr/include/c++/12/bits/stl_iterator.h:1096
#1 0x3be00ae in std::vector >::front()
/usr/include/c++/12/bits/stl_vector.h:1207
#2 0x3be00ae in
Rust::TyTy::TypeBoundPredicate::TypeBoundPredicate(Rust::DefId,
std::vector >, Location)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-bounds.cc:129
#3 0x3be0ea3 in Rust::TyTy::TypeBoundPredicate::error()
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-bounds.cc:207
#4 0x3cc9cb8 in Rust::Resolver::TypeCheckItem::visit(Rust::HIR::ImplBlock&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:74
#5 0x3cc72e7 in Rust::Resolver::TypeCheckItem::Resolve(Rust::HIR::Item&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:39
#6 0x39c3724 in Rust::Resolver::TypeResolution::Resolve(Rust::HIR::Crate&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check.cc:48
#7 0x2aff5ff in Rust::Session::compile_crate(char const*)
/home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:565
#8 0x2b0420e in Rust::Session::handle_input_files(int, char const**)
/home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:362
#9 0x212ce46 in grs_langhook_parse_file
/home/marxin/Programming/gcc/gcc/rust/rust-lang.cc:184
#10 0xcf3b22e in compile_file
/home/marxin/Programming/gcc/gcc/toplev.cc:444
#11 0xcf4f14d in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125
#12 0xcf4f14d in toplev::main(int, char**)
/home/marxin/Programming/gcc/gcc/toplev.cc:2277
#13 0x10409e86 in main /home/marxin/Programming/gcc/gcc/main.cc:39
#14 0x76a2c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af)
#15 0x76a2c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678)
#16 0x212cbd4 in _start ../sysdeps/x86_64/start.S:115

/usr/include/c++/12/bits/stl_vector.h:1207:16: runtime error: reference binding
to null pointer of type 'struct value_type'
#0 0x3be00e8 in std::vector >::front()
/usr/include/c++/12/bits/stl_vector.h:1207
#1 0x3be00e8 in
Rust::TyTy::TypeBoundPredicate::TypeBoundPredicate(Rust::DefId,
std::vector >, Location)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-bounds.cc:129
#2 0x3be0ea3 in Rust::TyTy::TypeBoundPredicate::error()
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-bounds.cc:207
#3 0x3cc9cb8 in Rust::Resolver::TypeCheckItem::visit(Rust::HIR::ImplBlock&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:74
#4 0x3cc72e7 in Rust::Resolver::TypeCheckItem::Resolve(Rust::HIR::Item&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:39
#5 0x39c3724 in Rust::Resolver::TypeResolution::Resolve(Rust::HIR::Crate&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check.cc:48
#6 0x2aff5ff in Rust::Session::compile_crate(char const*)
/home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:565
#7 0x2b0420e in Rust::Session::handle_input_files(int, char const**)
/home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:362
#8 0x212ce46 in grs_langhook_parse_file
/home/marxin/Programming/gcc/gcc/rust/rust-lang.cc:184
#9 0xcf3b22e in compile_file /home/marxin/Programming/gcc/gcc/toplev.cc:444
#10 0xcf4f14d in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125
#11 0xcf4f14d in toplev::main(int, char**)
/home/marxin/Programming/gcc/gcc/toplev.cc:2277
#12 0x10409e86 in main /home/marxin/Programming/gcc/gcc/main.cc:39
#13 0x76a2c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af)
#14 0x76a2c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678)
#15 0x212cbd4 in _start ../sysdeps/x86_64/start.S:115

/home/marxin/Programming/gcc/gcc/rust/util/fnv-hash.h:73:15: runtime error:
shift exponent 6685089673273576526 is too large for 64-bit type 'long unsigned
int'
#0 0x2b84979 in Rust::Hash::FNV128::write(unsigned char const*, unsigned
long) /home/marxin/Programming/gcc/gcc/rust/util/fnv-hash.h:73
#1 0x2b84979 in l

[Bug rust/108124] Rust: UBSAN issues when tests are run

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Last reconfirmed||2022-12-15
 Ever confirmed|0   |1
Summary|UBSAN issues when tests are |Rust: UBSAN issues when
   |run |tests are run
 CC||cohenarthur at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug rust/108124] Rust: UBSAN issues when tests are run

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

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

--- Comment #1 from Martin Liška  ---
./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/rust/compile/macro19.rs
-w
/home/marxin/Programming/gcc/gcc/rust/ast/rust-stmt.h:342:48: runtime error:
load of value 190, which is not a valid value for type 'bool'
#0 0x3546c7e in Rust::AST::ExprStmtWithBlock::is_semicolon_followed() const
/home/marxin/Programming/gcc/gcc/rust/ast/rust-stmt.h:342
#1 0x3546c7e in
Rust::HIR::ASTLoweringStmt::visit(Rust::AST::ExprStmtWithBlock&)
/home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-stmt.h:78
#2 0x35510cd in Rust::HIR::ASTLoweringStmt::translate(Rust::AST::Stmt*,
bool*) /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-stmt.h:42
#3 0x3521208 in Rust::HIR::ASTLoweringBlock::visit(Rust::AST::BlockExpr&)
/home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower.cc:113
#4 0x354de9e in
Rust::HIR::ASTLoweringBlock::translate(Rust::AST::BlockExpr*, bool*)
/home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-block.h:36
#5 0x36ef7fa in Rust::HIR::ASTLoweringItem::visit(Rust::AST::Function&)
/home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-item.cc:428
#6 0x36b8646 in Rust::HIR::ASTLoweringItem::translate(Rust::AST::Item*)
/home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-item.cc:28
#7 0x351caeb in Rust::HIR::ASTLowering::go()
/home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower.cc:75
#8 0x351f7d9 in Rust::HIR::ASTLowering::Resolve(Rust::AST::Crate&)
/home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower.cc:65
#9 0x2afebf5 in Rust::Session::compile_crate(char const*)
/home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:549
#10 0x2b0420e in Rust::Session::handle_input_files(int, char const**)
/home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:362
#11 0x212ce46 in grs_langhook_parse_file
/home/marxin/Programming/gcc/gcc/rust/rust-lang.cc:184
#12 0xcf3b22e in compile_file
/home/marxin/Programming/gcc/gcc/toplev.cc:444
#13 0xcf4f14d in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125
#14 0xcf4f14d in toplev::main(int, char**)
/home/marxin/Programming/gcc/gcc/toplev.cc:2277
#15 0x10409e86 in main /home/marxin/Programming/gcc/gcc/main.cc:39
#16 0x76a2c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af)
#17 0x76a2c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678)
#18 0x212cbd4 in _start ../sysdeps/x86_64/start.S:115

[Bug rust/108124] Rust: ASAN&UBSAN issues when tests are run

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Rust: UBSAN issues when |Rust: ASAN&UBSAN issues
   |tests are run   |when tests are run

--- Comment #2 from Martin Liška  ---
One more example of ASAN issue:

/dev/shm/objdir2/gcc/testsuite/rust10/../../gccrs
-B/dev/shm/objdir2/gcc/testsuite/rust10/../../
/home/marxin/Programming/gcc/gcc/testsuite/rust/compile/torture/generics16.rs
-fdiagnostics-plain-output
-frust-incomplete-and-experimental-compiler-do-not-use -O0 -S -o generics16.s
/usr/include/c++/12/bits/stl_iterator.h:1096:17: runtime error: reference
binding to null pointer of type 'struct SubstitutionParamMapping'
/usr/include/c++/12/bits/stl_vector.h:1207:16: runtime error: reference binding
to null pointer of type 'struct value_type'
=
==13693==ERROR: AddressSanitizer: heap-use-after-free on address 0x60e05700
at pc 0x03b57bfe bp 0x7fff9a10 sp 0x7fff9a08
READ of size 4 at 0x60e05700 thread T0
#0 0x3b57bfd in Rust::TyTy::BaseType::get_kind() const
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty.h:206
#1 0x3b57bfd in Rust::TyTy::BaseRules::unify(Rust::TyTy::BaseType*)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-rules.h:113
#2 0x3a87ea1 in Rust::TyTy::IntType::unify(Rust::TyTy::BaseType*)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty.cc:1880
#3 0x3b77be0 in Rust::TyTy::ADTRules::visit(Rust::TyTy::ADTType&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-rules.h:1125
#4 0x3b54d25 in Rust::TyTy::BaseRules::unify(Rust::TyTy::BaseType*)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-rules.h:81
#5 0x3a87121 in Rust::TyTy::ADTType::unify(Rust::TyTy::BaseType*)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty.cc:980
#6 0x3ece21f in
Rust::Resolver::TypeCheckImplItem::visit(Rust::HIR::Function&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-implitem.cc:369
#7 0x3ed2071 in
Rust::Resolver::TypeCheckImplItem::Resolve(Rust::HIR::ImplBlock*,
Rust::HIR::ImplItem*, Rust::TyTy::BaseType*)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-implitem.cc:338
#8 0x3ccdd4b in Rust::Resolver::TypeCheckItem::visit(Rust::HIR::ImplBlock&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:118
#9 0x3cc72e7 in Rust::Resolver::TypeCheckItem::Resolve(Rust::HIR::Item&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:39
#10 0x39c3724 in Rust::Resolver::TypeResolution::Resolve(Rust::HIR::Crate&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check.cc:48
#11 0x2aff5ff in Rust::Session::compile_crate(char const*)
/home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:565
#12 0x2b0420e in Rust::Session::handle_input_files(int, char const**)
/home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:362
#13 0x212ce46 in grs_langhook_parse_file
/home/marxin/Programming/gcc/gcc/rust/rust-lang.cc:184
#14 0xcf3b22e in compile_file
/home/marxin/Programming/gcc/gcc/toplev.cc:444
#15 0xcf4f14d in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125
#16 0xcf4f14d in toplev::main(int, char**)
/home/marxin/Programming/gcc/gcc/toplev.cc:2277
#17 0x10409e86 in main /home/marxin/Programming/gcc/gcc/main.cc:39
#18 0x76a2c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af)
#19 0x76a2c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678)
#20 0x212cbd4 in _start ../sysdeps/x86_64/start.S:115

0x60e05700 is located 32 bytes inside of 152-byte region
[0x60e056e0,0x60e05778)
freed by thread T0 here:
#0 0x778bb0e8  (/lib64/libasan.so.8+0xbb0e8)
#1 0x3b8f222 in Rust::TyTy::TypeCheckCallExpr::visit(Rust::TyTy::ADTType&)
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-call.cc:69

previously allocated by thread T0 here:
#0 0x778bc40f in __interceptor_malloc (/lib64/libasan.so.8+0xbc40f)
#1 0x109248eb in operator new(unsigned long)
../../../../libstdc++-v3/libsupc++/new_op.cc:50

SUMMARY: AddressSanitizer: heap-use-after-free
/home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty.h:206 in
Rust::TyTy::BaseType::get_kind() const
Shadow bytes around the buggy address:
  0x0c1c7fff8a90: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
  0x0c1c7fff8aa0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8ab0: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa
  0x0c1c7fff8ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1c7fff8ad0: 00 00 00 fa fa fa fa fa fa fa fa fa fd fd fd fd
=>0x0c1c7fff8ae0:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
  0x0c1c7fff8af0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c1c7fff8b00: 00 0

[Bug rust/108102] rust bootstrap comparison failure on s390x-linux-gnu

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-15
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

[Bug rtl-optimization/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

--- Comment #7 from Richard Biener  ---
Samples: 877K of event 'cycles:u', Event count (approx.): 779618998855  
Overhead   Samples  Command  Shared Object Symbol   
  52.64%461458  cc1plus  cc1plus   [.] ggc_internal_alloc
   3.18% 27836  cc1plus  cc1plus   [.] bitmap_set_bit
   2.66% 23374  cc1plus  cc1plus   [.]
hash_table::_transpose(input, transVecs);
  bar (transVecs);
}

Reducing 64 to 32 (also in the templates) makes it compile almost instantly
but still

 callgraph ipa passes   :  11.74 ( 84%)   3.00 ( 91%)  14.74 ( 85%)
 1617M ( 92%)
 integration:   6.88 ( 49%)   1.75 ( 53%)   8.63 ( 50%)
 1460M ( 83%)
 tree operand scan  :   3.04 ( 22%)   1.17 ( 35%)   4.31 ( 25%)
  113M (  7%)

I can halve the operand scan time.

[Bug rtl-optimization/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

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

https://gcc.gnu.org/g:930b3d6948f2cddc6a7fc4b35bafda1deabcd0c9

commit r13-4714-g930b3d6948f2cddc6a7fc4b35bafda1deabcd0c9
Author: Richard Biener 
Date:   Thu Dec 15 11:30:21 2022 +0100

middle-end/108086 - reduce operand scanner use from inliner

The following avoids a redundant second operand scan on all stmts
during inlining which shows with PR108086.

PR middle-end/108086
* tree-inline.cc (copy_edges_for_bb): Do not update all
stmts again.

[Bug libstdc++/108105] std::is_sorted(std::execution::par, ...) giving incorrect result

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
   Last reconfirmed||2022-12-15

--- Comment #1 from Martin Liška  ---
Hm, confirmed.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-15
 Status|UNCONFIRMED |ASSIGNED
Summary|[13 Regression] ice in  |[13 Regression] ice in
   |modify_call, at |modify_call, at
   |ipa-param-manipulation.cc:7 |ipa-param-manipulation.cc:7
   |00 with -std=c++14 -O3  |00 with -std=c++14 -O3
   |-march=native   |-march=znver3 since
   ||r13-4685-g4834e9360f7bf4
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

[Bug rust/108111] Rust meets clang

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-12-15
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=znver3 since r13-4685-g4834e9360f7bf4

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

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

--- Comment #11 from Martin Liška  ---
A bit more reduced test-case:

namespace std {
template  struct integral_constant {
  static constexpr int value = __v;
};
template  using decay_t = _Tp;
template  using enable_if_t = _Tp;
template  _Tp &&forward(_Tp &);
long max(long __b) {
  if (__b)
return __b;
}
} // namespace std
enum layout_type { row_major };
struct svector {
  long operator[](long) const;
  long *m_begin;
};
auto svector::operator[](long idx) const -> long { return m_begin[idx]; }
template  struct xcontainer_inner_types;
template  class xarray_container;
template 
using xarray = xarray_container;
struct xrange {
  xrange() noexcept;
  int m_size;
};
template  struct xrange_adaptor {
  xrange_adaptor(int, int, int) : m_start() {}
  std::enable_if_t::value, xrange> get(long size) {
if (m_start)
  std::max(size);
if (m_stop)
  std::max(size);
return xrange();
  }
  int m_start;
  int m_stop;
};
template  auto range(A, B stop_val) {
  return xrange_adaptor(0, stop_val, int());
}
template  struct slice_implementation_getter {
  template  auto operator()(E e, SL slice, long index) {
return get_slice(e, slice, index, std::integral_constant<1>());
  }
  template 
  auto get_slice(E, SL slice, long, std::integral_constant) {
return slice < std::decay_t() ?: slice;
  }
};
template 
struct slice_implementation_getter> {
  template  auto operator()(E e, SL adaptor, long index) {
const svector __trans_tmp_6 = e.shape();
long __trans_tmp_2 = __trans_tmp_6[index];
return adaptor.get(__trans_tmp_2);
  }
};
long get_slice_implementation_index;
template  auto get_slice_implementation(E e, SL &&slice) {
  slice_implementation_getter> getter;
  return getter(e, slice, get_slice_implementation_index);
}
xrange::xrange() noexcept {}
template  struct xcontainer {
  using derived_type = D;
  using inner_shape_type = typename
xcontainer_inner_types::inner_shape_type;
  constexpr const inner_shape_type &shape() const noexcept;
  const derived_type &derived_cast() const &noexcept;
};
template  struct xstrided_container : xcontainer {
  using typename xcontainer::inner_shape_type;
  const inner_shape_type &shape_impl() const noexcept;
  inner_shape_type m_shape;
};
template 
constexpr auto xcontainer::shape() const noexcept
-> const inner_shape_type & {
  return derived_cast().shape_impl();
}
template 
auto xcontainer::derived_cast() const &noexcept -> const derived_type & {
  return *static_cast(this);
}
template 
auto xstrided_container::shape_impl() const noexcept
-> const inner_shape_type & {
  return m_shape;
}
template 
struct xcontainer_inner_types> {
  using inner_shape_type = SC;
};
template 
struct xarray_container
: xstrided_container> {};
struct xview {
  template  xview(CTA, FSL);
};
template  void make_view_impl(E e, S &&...slices) {
  xview(get_slice_implementation(e, std::forward(slices))...);
}
template  void view(E e, S... slices) {
  make_view_impl(e, slices...);
}
void TestBody() {
  xarray a, arr;
  xrange_adaptor __trans_tmp_3 = range(1, 4), __trans_tmp_4 = range(1, 3);
  view(a, 1, __trans_tmp_3);
  view(arr, 1, __trans_tmp_4);
}

[Bug c++/108116] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1074 since r12-6897-gdec8d0e5fa00ceb2

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|internal compiler error: in |[12/13 Regression] ICE in
   |check_noexcept_r, at|check_noexcept_r, at
   |cp/except.cc:1074   |cp/except.cc:1074 since
   ||r12-6897-gdec8d0e5fa00ceb2
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-15

--- Comment #2 from Martin Liška  ---
Started with r12-6897-gdec8d0e5fa00ceb2.

[Bug c++/108116] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1074 since r12-6897-gdec8d0e5fa00ceb2

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

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

--- Comment #3 from Martin Liška  ---
Reduced test-case:

namespace std {
template  struct initializer_list {
  int *_M_array;
  unsigned long _M_len;
};
struct c {
  c(int);
  ~c();
};
struct d {
  d(initializer_list);
};
struct e {
  d f{0};
};
template  void h() {
  e {};
};
}

[Bug gcov-profile/107537] gcov skips throw/fallthrough annotations for 'never executed' branches

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

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

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

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

commit r13-4715-gc263c3eba8953c341cd8ac2d0a5f2b8f38623016
Author: Spacetown 
Date:   Sun Dec 4 21:03:34 2022 +0100

gcov: annotate uncovered branches [PR107537]

PR gcov-profile/107537

gcc/ChangeLog:
* gcov.cc (output_branch_count): Add annotation '(fallthrough)'
or '(throw)' also to uncovered branches.

Signed-off-by: Michael Förderer 

[Bug gcov-profile/107537] gcov skips throw/fallthrough annotations for 'never executed' branches

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed on master.

[Bug ada/108125] New: Suggestion for improving bug-box / reporting on ICE

[jesper.quorning at gmail dot com via Gcc-bugs]

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

Bug ID: 108125
   Summary: Suggestion for improving bug-box / reporting on ICE
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jesper.quorning at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Barry Houser @barryhouser:matrix.org 2022-12-15 10:36 [1];

> It would be a lot easier for both parties if the compiler offered to collect 
> the 
> necessary data and logs for submitting the bug. If it can detect a bug, then 
> why 
> stop there? This is exactly why Apple's products are so successful. It's 
> small 
> seemingly insignificant things they get right that makes all the difference. 
> It's 
> paid off handsomely. Just their iPhone division  > alone is bigger than 
> Microsoft. 
> It's hard to believe Apple was on life support 20 years ago.

it would be nice to have more information available in case of ICE;
Like -

* (Symbolic) Stack traceback
* Source code location
* Data structures

[1]: https://gitter.im/ada-lang/Alire.

[Bug libfortran/108056] [12/13 Regression] backward compatibility issue between 11 and 12

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r13-4716-ge205ec03f0794aeac3e8a89e947c12624d5a274e
Author: Tobias Burnus 
Date:   Thu Dec 15 12:25:07 2022 +0100

libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only
code [PR108056]

Since GCC 12, the conversion between the array descriptors formats - the
internal (GFC) and the C binding one (CFI) - moved to the compiler itself
such that the cfi_desc_to_gfc_desc/gfc_desc_to_cfi_desc functions are only
used with older code (GCC 9 to 11).  The newly added checks caused asserts
as older code did not pass the proper values (e.g. real(4) as effective
argument arrived as BT_ASSUME type as the effective type got lost
inbetween).

As proposed in the PR, revert to the GCC 11 version - known bugs is better
than some fixes and new issues. Still, GCC 12 is much better in terms of
TS29113 support and should really be used.

This patch uses the current libgomp version of the GCC 11 branch, except
it fixes the GFC version number (which is 0), uses calloc instead of
malloc,
and sets the lower bound to 1 instead of keeping it as is for
CFI_attribute_other.

libgfortran/ChangeLog:

PR libfortran/108056
* runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc,
gfc_desc_to_cfi_desc): Mostly revert to GCC 11 version for
those backward-compatiblity-only functions.

[Bug rust/108126] New: rust meets cppcheck

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108126
   Summary: rust meets cppcheck
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

I just ran the C/C++ static analyser over the new source code of rust.

First the errors:

trunk.d1/gcc/rust/ast/rust-cond-compilation.h:228:65: error: Member variable
'cfg_attrs' is initialized by itself. [selfInitialization]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:1635:46: error: Reference to local
variable returned. [returnReference]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:1636:58: error: Reference to local
variable returned. [returnReference]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:558:58: error: Reference to local
variable returned. [returnReference]
trunk.d1/gcc/rust/util/rust-optional.h:157:12: error: Reference to local
variable returned. [returnReference]

Next, the warnings:

trunk.d1/gcc/rust/parse/rust-parse-impl.h:12423:21: warning: Access of moved
variable 'outer_attrs'. [accessMoved]
trunk.d1/gcc/rust/typecheck/rust-tyty-rules.h:394:7: warning: Class 'BaseRules'
does not have a copy constructor which is recommended since it has dynamic
memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-tyty-rules.h:394:7: warning: Class 'BaseRules'
does not have a operator= which is recommended since it has dynamic
memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:146:7: warning: Class
'SubstMapper' does not have a copy constructor which is recommended since it
has dynamic memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:146:7: warning: Class
'SubstMapper' does not have a operator= which is recommended since it has
dynamic memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:261:7: warning: Class
'SubstMapperInternal' does not have a copy constructor which is recommended
since it has dynamic memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:261:7: warning: Class
'SubstMapperInternal' does not have a operator= which is recommended since it
has dynamic memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:75:7: warning: Class
'TypeCheckCallExpr' does not have a copy constructor which is recommended since
it has dynamic memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:75:7: warning: Class
'TypeCheckCallExpr' does not have a operator= which is recommended since it has
dynamic memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-hir-type-check-struct.cc:29:5: warning: Class
'TypeCheckStructExpr' does not have a copy constructor which is recommended
since it has dynamic memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-hir-type-check-struct.cc:29:5: warning: Class
'TypeCheckStructExpr' does not have a operator= which is recommended since it
has dynamic memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:664:9: warning: Either the condition
'argument!=nullptr' is redundant or there is possible null pointer dereference:
argument. [nullPointerRedundantCheck]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:740:29: warning: Either the condition
'index>mappings.size()' is redundant or 'index' can have the value
mappings.size(). Expression 'mappings.at(index)' cause access out of bounds.
[containerOutOfBounds]
trunk.d1/gcc/rust/expand/rust-macro-substitute-ctx.cc:77:25: warning: Either
the condition 'it==fragments.end()' is redundant or there is possible
dereference of an invalid iterator: it. [derefInvalidIteratorRedundantCheck]
trunk.d1/gcc/rust/backend/rust-tree.cc:155:5: warning: Label 'CASE_CONVERT' is
not used. Should this be a 'case' of the enclosing switch()?
[unusedLabelSwitch]
trunk.d1/gcc/rust/backend/rust-tree.cc:45:5: warning: Label 'CASE_CONVERT' is
not used. Should this be a 'case' of the enclosing switch()?
[unusedLabelSwitch]
trunk.d1/gcc/rust/ast/rust-expr.h:1853:3: warning: Member variable
'CallExpr::fndeclRef' is not initialized in the constructor. [uninitMemberVar]
trunk.d1/gcc/rust/ast/rust-expr.h:1862:3: warning: Member variable
'CallExpr::fndeclRef' is not initialized in the copy constructor.
[uninitMemberVar]
trunk.d1/gcc/rust/util/rust-canonical-path.h:51:18: warning: Member variable
'CanonicalPath::crate_num' is not assigned a value in
'CanonicalPath::operator='. [operatorEqVarError]
trunk.d1/gcc/rust/util/rust-canonical-path.h:49:3: warning: Member variable
'CanonicalPath::crate_num' is not initialized in the copy constructor.

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

--- Comment #8 from Feng Xue  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Feng Xue from comment #6)
> > (In reply to Andrew Pinski from comment #2)
> > > https://en.cppreference.com/w/c/program/setjmp
> > 
> > I think that most programmers are not aware of this, neither I for sure.
> > Usage of volatile here is not that intuitive as for purpose of
> > multi-execution synchronization
> 
> You should read up on
> https://en.cppreference.com/w/cpp/utility/program/signal too.

>From viewpoint of programmer, setjmp/longjmp is somewhat similar to C++
exception handling, which happens in one logical execution context, while
signal implies two  unrelated contexts.

In another angle, because gcc already model control flow and SSA web for
setjmp/longjmp, explicit volatile specification is not really needed. But
signal mechanism is kind of asynchronous exception, for which it is impractical
for compiler to do that, so volatile is must.

[Bug ada/108125] Suggestion for improving bug-box / reporting on ICE

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

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

--- Comment #1 from Andrew Pinski  ---
The ice for Ada front end already provides this information. Even saying what
to attachments are required.


The c/c++ frontend ice says to rerun with -freport-bug and attach that .out
file.

What more improvements are needed to compared to what clang does?
Outputting internal state is hard to do really and confuse everyone.

[Bug modula2/108123] gcc/m2/gm2config.h.in is out of date

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

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

--- Comment #1 from Gaius Mulley  ---
done thanks for the bug report.

[Bug rust/108126] rust meets cppcheck

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-15
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug modula2/108123] gcc/m2/gm2config.h.in is out of date

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #2 from Gaius Mulley  ---
closing.

[Bug c/108127] New: FP due to combination of -Warray-bounds and UBSAN

[frolov.da at phystech dot edu via Gcc-bugs]

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

Bug ID: 108127
   Summary: FP due to combination of -Warray-bounds and UBSAN
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frolov.da at phystech dot edu
  Target Milestone: ---

I've tried to build the next example (which is a reduced example of one of the
functions from firefox):

static const unsigned DECPOWERS[10] = { 1, 10, 100, 1000, 1, 10,
100, 1000, 1, 10};

unsigned foo(int discard, unsigned char *lsu, unsigned char *up) {
  int count;
  unsigned cut, quot;

  count = discard;

  cut = discard - (count - 1) - 1;

  if (cut == 1 - 1) {
return 8;
  } else {
quot = *up >> cut;
cut++;
return DECPOWERS[1 - cut];
  }
}

$ gcc -O2 -fsanitize-undefined-trap-on-error  -Werror=array-bounds 
-fsanitize=shift,signed-integer-overflow

and got an error:

: In function 'foo':
:16:21: error: array subscript 4294967265 is above array bounds of
'const unsigned int[10]' [-Werror=array-bounds=]
   16 | return DECPOWERS[1 - cut];
  |~^
:1:23: note: while referencing 'DECPOWERS'
1 | static const unsigned DECPOWERS[10] = { 1, 10, 100, 1000, 1,
10, 100, 1000, 1, 10}

Looks like the builtin functions of the ubsan (such as UBSAN_CHECK_SUB) does
not allow optimizations and cause these false positives. If I remove the
sanitizer flags then there will be no warning.

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

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

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

--- Comment #6 from Iain Sandoe  ---
hmm .. some odd things.

With Rainer's patch actually the plugin build succeeded on x86_64-darwin19
(Catalina) 

so then the plugin fails to load because it is missing the libstdc++ version
needed (since that is not yet installed).

so if I then install libstdc++ and resume the build.

.. then the target library build fails with a lot of missing symbols.

(I am also trying on rosetta-2 x86_64 on macOS12).

A weird thing that I can't explain (and could be unrelated, it just happens to
appear at the same time) is that when I try to restart a parallel build (after
fixing things up) I end up with a make instance spinning at 100% .. yet if I
resume the build as a single process... it proceeds.

unfortunately, I have no time for analysis - I have some CPU cycles, but no
spare engineering ones...

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

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

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

--- Comment #9 from Alexander Monakov  ---
(In reply to Feng Xue from comment #8)

> In another angle, because gcc already model control flow and SSA web for
> setjmp/longjmp, explicit volatile specification is not really needed.

That covers GIMPLE, but after transitioning to RTL, setjmp is not properly
modeled anymore (like in old versions of GCC before Tree-SSA). Many RTL passes
simply refuse touching the function if it has a setjmp call, but as your
example demonstrated, scheduling still can make a surprising transform.

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

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

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

--- Comment #7 from Iain Sandoe  ---
same result on x86_64 darwin21 - under rosetta 2.

BTW: this seems a bit odd to me I see the plugin specified like this:

plugin/m2rte$(exeext)$(soext) (.so without Rainer's patch).

Why $(exeext)?
Won't you end up with something like
plugin\m2rte.exe.dll
on Windows?

[Bug rtl-optimization/106751] [10/11/12/13 Regression] internal compiler error: in purge_dead_edges with inline-asm goto

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org
Summary|internal compiler error: in |[10/11/12/13 Regression]
   |purge_dead_edges with   |internal compiler error: in
   |inline-asm goto |purge_dead_edges with
   ||inline-asm goto
   Target Milestone|--- |10.5

--- Comment #8 from Jakub Jelinek  ---
Reduced testcase that ICEs on x86_64-linux too (-O2):
int *foo (void);

void
bar (void)
{
  asm goto ("" : : : : lab);
  __builtin_unreachable ();
lab:
  while (1)
{
  int o;
  asm ("" : "=r" (o) : "g" (1));
  *foo () = o;
}
}
Started with r0-128630-ga3afdbb80906a5553a64f9ba7686a57d2f43f536

[Bug c/108128] New: missing -Wshift-overflow warning

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Bug ID: 108128
   Summary: missing -Wshift-overflow warning
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider the following C program:

#include 
enum { A = 1 << 31 };
int main (void)
{
  printf ("%d\n", A);
  printf ("%d\n", 1 << 31);
  printf ("%d\n", 2 << 31);
  return 0;
}

In C, the 3 shifts have undefined behavior.

The GCC 12 man page says

-Wshift-overflow=n
These options control warnings about left shift overflows.

-Wshift-overflow=1
This is the warning level of -Wshift-overflow and is enabled by
default in C99 and C++11 modes (and newer).  This warning level
does not warn about left-shifting 1 into the sign bit.
(However, in C, such an overflow is still rejected in contexts
where an integer constant expression is required.)  No warning
is emitted in C++20 mode (and newer), as signed left shifts
always wrap.

-Wshift-overflow=2
This warning level also warns about left-shifting 1 into the
sign bit, unless C++14 mode (or newer) is active.

Nothing is said about the default, but I assume that this should be
-Wshift-overflow=2 in C because undefined behavior should be warned.

But with gcc-12 (Debian 12.2.0-10) 12.2.0, I get a warning only for 2 << 31.

cventin:~> /usr/bin/gcc-12 -std=c99 tst.c -o tst
tst.c: In function ‘main’:
tst.c:7:21: warning: result of ‘2 << 31’ requires 34 bits to represent, but
‘in’ only has 32 bits [-Wshift-overflow=]
7 |   printf ("%d\n", 2 << 31);
  | ^~

BTW, according to the man page, gcc should warn on "enum { A = 1 << 31 };" even
with -Wshift-overflow=1, but it doesn't. This is actually required by the
standard as constraint 6.6#4 is violated (as the evaluation is not defined).

With the UB sanitizer (-fsanitize=undefined), running the program gives as
expected:

-2147483648
tst.c:6:21: runtime error: left shift of 1 by 31 places cannot be represented
in type 'int'
-2147483648
tst.c:7:21: runtime error: left shift of 2 by 31 places cannot be represented
in type 'int'
0

Note that the sanitizer does not emit an error for "enum { A = 1 << 31 };"
since the issue occurs only at compilation (thus a warning is particularly
important).

[Bug c/108128] missing -Wshift-overflow warning

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #1 from Vincent Lefèvre  ---
Well, with -pedantic, GCC also warns on "enum { A = 1 << 31 };".

[Bug modula2/107607] tools-src/calcpath uses unportable realpath(1)

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #2 from Gaius Mulley  ---
LGTG

I've tested it on amd64 both in tree and out of tree with and absolute and
relative paths to configure.  No extra failures.

Thanks for the patch!

[Bug tree-optimization/108129] New: nop_atomic_bit_test_and_p is too bloated

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

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

Bug ID: 108129
   Summary: nop_atomic_bit_test_and_p is too bloated
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

match.pd has multi-pattern matcher 'nop_atomic_bit_test_and_p'.

It expands to ~38 KLOC in gimple-match.cc and ~350 KB in the compiled binary.

There has to be a better way than repeatedly emitting the match pattern for
each member of {ATOMIC,SYNC}_FETCH_{AND,OR_XOR}_N :)

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Sebastian Pop
:

https://gcc.gnu.org/g:59bba6f9dc6dcfefe96e6fad677614f39928564e

commit r10-11122-g59bba6f9dc6dcfefe96e6fad677614f39928564e
Author: Sebastian Pop 
Date:   Wed Nov 30 19:45:24 2022 +

AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

Currently patchable area is at the wrong place on AArch64.  It is placed
immediately after function label, before .cfi_startproc.  This patch
adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
modifies aarch64_print_patchable_function_entry to avoid placing
patchable area before .cfi_startproc.

gcc/
PR target/98776
* config/aarch64/aarch64-protos.h (aarch64_output_patchable_area):
Declared.
* config/aarch64/aarch64.c
(aarch64_print_patchable_function_entry):
Emit an UNSPECV_PATCHABLE_AREA pseudo instruction.
(aarch64_output_patchable_area): New.
* config/aarch64/aarch64.md (UNSPECV_PATCHABLE_AREA): New.
(patchable_area): Define.

gcc/testsuite/
PR target/98776
* gcc.target/aarch64/pr98776.c: New.
* gcc.target/aarch64/pr92424-2.c: Adjust pattern.
* gcc.target/aarch64/pr92424-3.c: Adjust pattern.

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Sebastian Pop
:

https://gcc.gnu.org/g:50f7161448a19c4fa355c7c652e26b47ceb36cc4

commit r11-10422-g50f7161448a19c4fa355c7c652e26b47ceb36cc4
Author: Sebastian Pop 
Date:   Wed Nov 30 19:45:24 2022 +

AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

Currently patchable area is at the wrong place on AArch64.  It is placed
immediately after function label, before .cfi_startproc.  This patch
adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
modifies aarch64_print_patchable_function_entry to avoid placing
patchable area before .cfi_startproc.

gcc/
PR target/98776
* config/aarch64/aarch64-protos.h (aarch64_output_patchable_area):
Declared.
* config/aarch64/aarch64.c
(aarch64_print_patchable_function_entry):
Emit an UNSPECV_PATCHABLE_AREA pseudo instruction.
(aarch64_output_patchable_area): New.
* config/aarch64/aarch64.md (UNSPECV_PATCHABLE_AREA): New.
(patchable_area): Define.

gcc/testsuite/
PR target/98776
* gcc.target/aarch64/pr98776.c: New.
* gcc.target/aarch64/pr92424-2.c: Adjust pattern.
* gcc.target/aarch64/pr92424-3.c: Adjust pattern.

[Bug tree-optimization/108129] nop_atomic_bit_test_and_p is too bloated

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-15
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Yep, I also noticed that some time ago :)

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Sebastian Pop
:

https://gcc.gnu.org/g:7525c9d7e72ac3818e08fe7aa98396bd41e4ec8c

commit r12-8987-g7525c9d7e72ac3818e08fe7aa98396bd41e4ec8c
Author: Sebastian Pop 
Date:   Wed Nov 30 19:45:24 2022 +

AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

Currently patchable area is at the wrong place on AArch64.  It is placed
immediately after function label, before .cfi_startproc.  This patch
adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
modifies aarch64_print_patchable_function_entry to avoid placing
patchable area before .cfi_startproc.

gcc/
PR target/98776
* config/aarch64/aarch64-protos.h (aarch64_output_patchable_area):
Declared.
* config/aarch64/aarch64.cc
(aarch64_print_patchable_function_entry):
Emit an UNSPECV_PATCHABLE_AREA pseudo instruction.
(aarch64_output_patchable_area): New.
* config/aarch64/aarch64.md (UNSPECV_PATCHABLE_AREA): New.
(patchable_area): Define.

gcc/testsuite/
PR target/98776
* gcc.target/aarch64/pr98776.c: New.
* gcc.target/aarch64/pr92424-2.c: Adjust pattern.
* gcc.target/aarch64/pr92424-3.c: Adjust pattern.

[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry

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

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #15 from Sebastian Pop  ---
Fixed for arm64 as well on master, and backported to active branches gcc-12,
11, and 10.

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Tomas Kalibera  ---
Another instance of this problem is %z (to print size_t). It is supported by
UCRT, but the GCC's Microsoft format warns, because it wasn't supported with
MSVCRT (seen with GCC 12.2).

[Bug ipa/108130] New: [13 Regression] LTO compile time hog seen on bootstrap-lto config since r13-4684-g7450b25566b7a7

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

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

Bug ID: 108130
   Summary: [13 Regression] LTO compile time hog seen on
bootstrap-lto config since r13-4684-g7450b25566b7a7
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

I noticed linking of e.g. cc1plus gets much slower in stage2 with a WPA hog in:

58.15%  lto1[.] lto_symtab_encoder_lookup
19.95%  lto1[.] may_need_named_section_p
18.77%  lto1[.] rename_statics
 0.50%  lto1[.] lto_symtab_encoder_lookup
 0.09%  lto1[.] lto_symtab_encoder_encode_body_p

The WPA phase takes >5 minutes, while it used to take ~30 seconds on my
machine.

[Bug ipa/108130] [13 Regression] LTO compile time hog seen on bootstrap-lto config since r13-4684-g7450b25566b7a7

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-12-15
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.0

[Bug rtl-optimization/106751] [10/11/12/13 Regression] internal compiler error: in purge_dead_edges with inline-asm goto

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
I'm afraid I don't know much about the RTL lim, but
1840  reorder_insns (inv->insn, inv->insn, BB_END (preheader));
with no check whether it is actually ok to append the statement at the end of
the preheader bb (at least no check that I can find) sounds wrong to me and I'm
just confused why it doesn't break stuff much more often.
>From what I can see, loop-invariant.cc pass happens in between loop2_init and
loop2_done passes where the former calls loop_optimizer_init (LOOPS_NORMAL |
LOOPS_HAVE_RECORDED_EXITS);
which should ensure that loops have preheaders, but doesn't actually ask for
LOOPS_HAVE_FALLTHRU_PREHEADERS.
If the latter was on, then create_preheader would force splitting of the edge:
  /* If we want fallthru preheaders, also create forwarder block when
 preheader ends with a jump or has predecessors from loop.  */
  else if ((flags & CP_FALLTHRU_PREHEADERS)
   && (JUMP_P (BB_END (single_entry->src))
   || has_preds_from_loop (single_entry->src, loop)))
need_forwarder_block = true;
So, should loop-invariant.cc split_edge the preheader edge if preheader block
ends with JUMP_P, or shall we somehow arrange for
LOOPS_HAVE_FALLTHRU_PREHEADERS?

[Bug libstdc++/108075] Undefined typeinfo for _Float16 (_ZTIDF16_)

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-4722-g3f101e32e2fb616633722fb552779f537e9a9891
Author: Jakub Jelinek 
Date:   Thu Dec 15 17:02:55 2022 +0100

c++, libstdc++: Add typeinfo for _Float{16,32,64,128,32x,64x} and __bf16
types [PR108075]

The following patch adds typeinfos for the extended floating point
types and _Float{32,64}x.

2022-12-15  Jakub Jelinek  

PR libstdc++/108075
gcc/cp/
* rtti.cc (emit_support_tinfos): Add pointers to
{bfloat16,float{16,32,64,128,32x,64x,128x}}_type_node to
fundamentals
array.
gcc/testsuite/
* g++.dg/cpp23/ext-floating13.C: New test.
libstdc++-v3/
* config/abi/pre/gnu.ver (CXXABI_1.3.14): Export
_ZTIDF[0-9]*[_bx], _ZTIPDF[0-9]*[_bx] and _ZTIPKDF[0-9]*[_bx].
* testsuite/util/testsuite_abi.cc (check_version): Handle
CXXABI_1.3.14.

[Bug libstdc++/108075] Undefined typeinfo for _Float16 (_ZTIDF16_)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk.  As I said, there is nothing that can be done for older
versions.

[Bug c++/78147] The -Wshadow warning is too aggressive with constructor parameters

[psmith at gnu dot org via Gcc-bugs]

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

--- Comment #7 from Paul Smith  ---
I don't really think this change is related to -Wunused-private-field: at least
I don't see any relationship.

My personal preference would be to not even bother to create an option for
this; I think that GCC should _never_ warn about this usage.  I really can't
fathom a reason that anyone would want to enable shadow warnings in this
situation, such that creating a separate option to control it worth the effort.

[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-12-15
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
We need to add a check to disable hwasan for older linkers.

[Bug rtl-optimization/106751] [10/11/12/13 Regression] internal compiler error: in purge_dead_edges with inline-asm goto

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 54103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54103&action=edit
gcc13-pr106751.patch

This seems to work on the testcase.

[Bug fortran/108131] New: Incorrect bound calculation when bound intrinsic used in size expression

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

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

Bug ID: 108131
   Summary: Incorrect bound calculation when bound intrinsic used
in size expression
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

This is from
https://stackoverflow.com/questions/74814027/where-to-report-possible-gfortran-compiler-bug
. Consider

program test
  integer, parameter :: mg(0:10) = 0
  integer, parameter :: u = ubound(mg, dim=1)
  integer, parameter :: cx(-1:ubound(mg, dim=1)) = 1
  integer, parameter :: cy(-1:10) = 2
  integer, parameter :: cz(-1:u) = 3

  write(*,*) lbound(mg, dim=1), ubound(mg, dim=1)
  write(*,*) lbound(cx, dim=1), ubound(cx, dim=1)
  write(*,*) lbound(cy, dim=1), ubound(cy, dim=1)
  write(*,*) lbound(cz, dim=1), ubound(cz, dim=1)
end program test

Obviously the ubounds of all the 4 arrays should be 10. However running the
program results in:

$ ./a.out
   0  10
  -1  11
  -1  10
  -1  10

This affects master as of today, an earlier 12.x snapshot I had lying around,
and 11.3.0 as shipped with Ubuntu 22.04. Based on a comment on the
stackoverflow question, versions 7, 8, 9, and 10 are ok. Looking at
-fdump-tree-original output, the error occurs already in the gfortran frontend.

[Bug tree-optimization/108129] nop_atomic_bit_test_and_p is too bloated

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

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

--- Comment #2 from Andrew Pinski  ---
This might improve the build time of GCC ...

[Bug fortran/108131] [10/11/12/13 Regression] Incorrect bound calculation when bound intrinsic used in size expression

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|Incorrect bound calculation |[10/11/12/13 Regression]
   |when bound intrinsic used   |Incorrect bound calculation
   |in size expression  |when bound intrinsic used
   ||in size expression
   Last reconfirmed||2022-12-15
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||anlauf at gcc dot gnu.org
  Known to work||7.5.0, 8.5.0, 9.5.0
  Known to fail||10.4.1, 11.3.1, 12.2.1,
   ||13.0

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug rtl-optimization/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

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

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

commit r13-4723-gd49b2a3a1dbbe3ac9ae134bc5742be7fdb417d32
Author: Richard Biener 
Date:   Thu Dec 15 13:42:16 2022 +0100

middle-end/108086 - avoid quadraticness in copy_edges_for_bb

For the testcase in PR108086 it's visible that we split blocks
multiple times when inlining and that causes us to adjust the
block tail stmt BBs multiple times, once for each split.  The
fix is to walk backwards and split from the tail instead.

For a reduced testcase this improves compile-time at -O by 4%.

PR middle-end/108086
* tree-inline.cc (copy_edges_for_bb): Walk stmts backwards for
splitting the block to avoid quadratic behavior with setting
stmts BB on multliple splits.

[Bug fortran/108131] [10/11/12/13 Regression] Incorrect bound calculation when bound intrinsic used in size expression

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
   Priority|P3  |P4

[Bug middle-end/108127] FP due to combination of -Warray-bounds and UBSAN

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

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

--- Comment #1 from Andrew Pinski  ---
>From the new documentation:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsanitize_003dundefined

"Note that sanitizers tend to increase the rate of false positive warnings,
most notably those around -Wmaybe-uninitialized. We recommend against combining
-Werror and [the use of] sanitizers.

"

[Bug rtl-optimization/108132] New: Wrong instruction scheduling around function call with longjmp on aarch64 at O2

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

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

Bug ID: 108132
   Summary: Wrong instruction scheduling around function call with
longjmp on aarch64 at O2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

The error only happens on aarch64 (fine on X86). 

The following testing case:
[opc@qinzhao-aarch64-ol8]$ cat t.c
#include  
#include  
#include  

jmp_buf ex_buf__; 

int f(int x) 
{ 
  int arr[] = {1,2,6,8,9,10}; 
  int lo=0; 
  int hi=5; 

  while(lo<=hi) { 
int mid=(lo+hi)/2; 

if(arr[mid]==x) { 
  longjmp(ex_buf__, 1); 
} else if(arr[mid]x) { 
  hi=mid-1; 
} 
  } 

  return -1; 
} 

int 
main(int argc, char** argv) 
{ 
  int a=2; 
  bool b=false; 

  do {
if( !setjmp(ex_buf__) ){
a=f(a); 
b=true; 
} else { 
  printf("a : %d\n",a); 
  printf("Got Exception!\n"); 
} 
  } while(0);

  if(b) { 
printf("b is true!\n"); 
  } 
  return 0; 
}

when compiled with the latest upstream gcc13 on aarch64 with -O2, the variable
"b" was set to true, which is wrong. 
when disable insn scheduling by adding -fno-schedule-insns, the issue gone:
[opc@qinzhao-aarch64-ol8]$ /home/opc/Install/latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/opc/Install/latest/bin/gcc
COLLECT_LTO_WRAPPER=/home/opc/Install/latest/libexec/gcc/aarch64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../latest_gcc/configure --prefix=/home/opc/Install/latest
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221215 (experimental) (GCC) 
[opc@qinzhao-aarch64-ol8]$ /home/opc/Install/latest/bin/gcc -O2 t.c
[opc@qinzhao-aarch64-ol8]$ ./a.out
a : 2
Got Exception!
b is true!
[opc@qinzhao-aarch64-ol8]$ /home/opc/Install/latest/bin/gcc -O2
-fno-schedule-insns t.c
[opc@qinzhao-aarch64-ol8]$ ./a.out
a : 2
Got Exception!
[opc@qinzhao-aarch64-ol8]$

[Bug middle-end/70090] add non-constant variant of __builtin_object_size for _FORTIFY_SOURCE and -fsanitize=object-size

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Siddhesh Poyarekar
:

https://gcc.gnu.org/g:7283380a5829150cc820ab3b25c4d91cad372eec

commit r13-4724-g7283380a5829150cc820ab3b25c4d91cad372eec
Author: Siddhesh Poyarekar 
Date:   Thu Dec 15 11:29:23 2022 -0500

middle-end/70090: Document that -fsanitize=object-size uses dynamic size

Fix the documentation to say that object sizes are deduced using
__builtin_dynamic_object_size.

gcc/ChangeLog:

PR middle-end/70090
* doc/invoke.texi (-fsanitize=object-size): Use
__builtin_dynamic_object_size instead of
__builtin_object_size.

Signed-off-by: Siddhesh Poyarekar 

[Bug rtl-optimization/108132] Wrong instruction scheduling around function call with longjmp on aarch64 at O2

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
As we checked the assembly and the IR, the wrong transformation is something
like the following at source code level: (inside function "main")

from : 
a=f(a); 
b=true; 
to: 
b=true; 
a=f(a) 

since there is a "longjmp" inside the function "f", I think that it's not 
correct  to move b=true before the function call. 

I think that the function "f" which has a "longjmp" should be treated as a
memory barrier, any insn movement should not across it. 

This problem exists back to gcc8.

[Bug rtl-optimization/108132] Wrong instruction scheduling around function call with longjmp on aarch64 at O2

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #2 from qinzhao at gcc dot gnu.org ---
I am changing the priority of this one to P2 since we have a lot of instances
in our important application on aarch64.

[Bug tree-optimization/108129] nop_atomic_bit_test_and_p is too bloated

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Alexander Monakov from comment #0)
> match.pd has multi-pattern matcher 'nop_atomic_bit_test_and_p'.
> 
> It expands to ~38 KLOC in gimple-match.cc and ~350 KB in the compiled binary.
> 
> There has to be a better way than repeatedly emitting the match pattern for
> each member of {ATOMIC,SYNC}_FETCH_{AND,OR_XOR}_N :)

It's the way the matcher works - if you can think of a better way of
code-generating it within the constraints:
 - earlier patterns in match.pd should match first in case there are multiple
matches
 - matching time should ideally be O(size of the pattern) rather than O(size of
match.pd)

The 2nd constraint isn't currently fulfilled because of the first constraint
(or how that is implemented).  The 2nd constraint was the original design
goal to make frequent "re-folding" cheap.  The first constraint was implemented
to allow pattern ordering to disambiguate "overlapping" matches.

Writing a different code generation in genmatch should be possible, the
(lowered) AST is available.

[Bug rtl-optimization/108132] Wrong instruction scheduling around function call with longjmp on aarch64 at O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug rtl-optimization/57067] Missing control flow edges for setjmp/longjmp

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

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

[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 54104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54104&action=edit
A patch

Please try this.

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Dup of bug 57067.

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

[Bug rtl-optimization/57067] Missing control flow edges for setjmp/longjmp

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||fxue at os dot 
amperecomputing.com

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

[Bug rtl-optimization/106751] [10/11/12/13 Regression] internal compiler error: in purge_dead_edges with inline-asm goto

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

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

--- Comment #11 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 54103 [details]
> gcc13-pr106751.patch
> 
> This seems to work on the testcase.

looks reasonable.

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

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

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

--- Comment #11 from Andrew Pinski  ---
>From the duplicated bug: "In this case the RTL scheduler pass generates broken
code due to the missing control flow info."

[Bug rtl-optimization/108132] Wrong instruction scheduling around function call with longjmp on aarch64 at O2

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

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

--- Comment #4 from Andrew Pinski  ---
>From the duplicated bug: "In this case the RTL scheduler pass generates broken
code due to the missing control flow info."

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

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

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

--- Comment #12 from Alexander Monakov  ---
Shouldn't there be another bug for the sched1 issue specifically? In absence of
abnormal control flow, extending lifetimes of pseudos across calls is still
likely to be a pessimization.

[Bug c++/107065] GCC treats rvalue as an lvalue

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-4726-g8b775b4c48a3cc4ef5c50e56144aea02da2e9cc6
Author: Jakub Jelinek 
Date:   Thu Dec 15 19:17:45 2022 +0100

c++: Ensure !!var is not an lvalue [PR107065]

The TRUTH_NOT_EXPR case in cp_build_unary_op is one of the spots where
we somewhat fold immediately using invert_truthvalue_loc.
I've tried using
  return build1_loc (location, TRUTH_NOT_EXPR, boolean_type_node, arg);
in there instead, but unfortunately that regressed
Wlogical-not-parentheses-*.c pr49706.c pr62199.c pr65120.c sequence-pt-1.C
tests, so at least for backporting that doesn't seem to be a way to go.

So, this patch instead wraps it into NON_LVALUE_EXPR if needed (which also
need a tweak for some tests in the pr47906.c test, but nothing major),
with the intent to make it backportable, and later I'll try to do further
steps to avoid folding here prematurely.  Most of the problems with
build1 TRUTH_NOT_EXPR are that it doesn't even invert comparisons as most
common case and lots of warning code isn't able to deal with ! around
comparisons; so perhaps one way to do this would be fold by hand only
invertable comparisons and for the rest create TRUTH_NOT_EXPR.

2022-12-15  Jakub Jelinek  

PR c++/107065
gcc/cp/
* typeck.cc (cp_build_unary_op) : If
invert_truthvalue_loc returns obvalue_p, wrap it into
NON_LVALUE_EXPR.
* parser.cc (cp_parser_binary_expression): Don't call
warn_logical_not_parentheses if current.lhs is a NON_LVALUE_EXPR
of a decl with boolean type.
gcc/testsuite/
* g++.dg/cpp0x/pr107065.C: New test.