[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

[i at maskray dot me via Gcc-bugs]

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

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #5 from Fangrui Song  ---
* There is a restriction on the number of instructions between the function
label and the .localentry directive.
* For -fpatchable-function-entry=N[,M], M nops must precede the function label.

On aarch64/x86/etc, these nops are consecutive. Personally I think this
condition can be lifted for PowerPC ELFv2. The runtime library will need to
check st_other or do some instruction inspection, which may be fine.


nop
nop
nop
foo:
.LCF0:
.cfi_startproc
addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry foo,.-foo
nop
nop

[Bug fortran/104382] Finalization of parent components not compliant with standard

[paul.richard.thomas at gmail dot com via Gcc-bugs]

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

--- Comment #5 from paul.richard.thomas at gmail dot com  ---
Hi Thomas,

My stepping out of gfortran activities has been for rather longer than I
expected. I had hoped to have completed the finalization work by now and to
have got on with fixing PDTs.

I will try to find the time over the summer because it is evident that a
sufficient number of colleagues are on vacation that sustaining the pace of
work might be difficult :-)

I hope that all is well with you.

Paul


On Wed, 10 Aug 2022 at 08:40, tkoenig at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382
>
> Thomas Koenig  changed:
>
>What|Removed |Added
>
> 
>  CC||tkoenig at gcc dot
> gnu.org
>
> --- Comment #4 from Thomas Koenig  ---
> To add some variety to the tests, nagfor gives
>
>  destructor4(complicated)   2.000   2.000
>  destructor5 (simple2) 5
>  destructor5 (simple2) 6
>  destructor2(simple) 1 1
>  final_count after assignment =  4
>  destructor4(complicated)   4.000   5.000
>  destructor5 (simple2) -1
>  destructor5 (simple2) -2
>  destructor2(simple) 3 4
>  final_count after deallocation =  8
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

--- Comment #6 from Kewen Lin  ---
(In reply to Fangrui Song from comment #5)
> * There is a restriction on the number of instructions between the function
> label and the .localentry directive.
> * For -fpatchable-function-entry=N[,M], M nops must precede the function
> label.
> 
> On aarch64/x86/etc, these nops are consecutive. Personally I think this
> condition can be lifted for PowerPC ELFv2. The runtime library will need to
> check st_other or do some instruction inspection, which may be fine.
>  
>  
> nop
> nop
> nop
> foo:
> .LCF0:
> .cfi_startproc
> addis 2,12,.TOC.-.LCF0@ha
> addi 2,2,.TOC.-.LCF0@l
> .localentry foo,.-foo
> nop
> nop

Thanks for the input! With your proposal, the nice thing is that we don't need
to bother the count of NOPs between GEP and LEP. But IMHO it seems confusing
since we take GEP as function entry when patching preceding NOPs while take LEP
as function entry when patching succeeding NOPs. The acceptable counts of NOPs
in the proposed patch conforms to ELFv2 ABI, I hope runtime library can survive
with it.

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
Created attachment 53433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53433=edit
a-t2.c.325r.vartrack

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free() when not optimizing

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

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

--- Comment #4 from Gökçe Aydos  ---
Just to clarify my entry:

In my opinion gcc should not fire a warning in my first example. In case
`realloc` was not successful, then `realloc` does not touch its argument. I
should be able to use its argument in this case.

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

--- Comment #3 from Francois-Xavier Coudert  ---
The module in the runtime library is compiled only once, unless the library is
multilib (one libgfortran compiled for IBM double double, one libgfortran
compiled for IEEE quad).

My goal would be to generate all IEEE intrinsics in the front-end, it should be
possible. However, there is not enough support in the middle-end support at the
current time: one would need to have GCC support type-generic built-ins for the
various IEEE fp functions. This was discussed, there was even a patch at some
point for some of them (there must be some discussion of this between myself
and, I think, Richard Biener on the gcc list a couple of months ago, but I
can't find it right now).

[Bug tree-optimization/104992] [missed optimization] x / y * y == x not optimized to x % y == 0

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

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

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

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

commit r13-2018-g8e69f2a6e91b7a01619dfd3b0788bfda4ad28941
Author: Jakub Jelinek 
Date:   Thu Aug 11 10:26:32 2022 +0200

testsuite: Fix up pr104992* tests on i686-linux [PR104992]

These 2 tests were FAILing on i686-linux or e.g. with
--target_board=unix/-m32/-mno-sse on x86_64-linux due to
-Wpsabi warnings and also because dg-options in the latter
test has been ignored due to missing space, so even -O2
wasn't passed at all.

2022-08-11  Jakub Jelinek  

PR tree-optimization/104992
* gcc.dg/pr104992.c: Add -Wno-psabi to dg-options.
* g++.dg/pr104992-1.C: Likewise.  Add space between " and } in
dg-options.

[Bug tree-optimization/106243] Failure to optimize (0 - x) & 1 on gimple level (including vector types)

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

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

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

https://gcc.gnu.org/g:621f5362253f00b910686e8221e6756457f71e81

commit r13-2019-g621f5362253f00b910686e8221e6756457f71e81
Author: Jakub Jelinek 
Date:   Thu Aug 11 10:29:06 2022 +0200

testsuite: Fix up pr106243* tests on i686-linux [PR106243]

These 2 tests were FAILing on i686-linux or e.g. with
--target_board=unix/-m32/-mno-sse on x86_64-linux due to
-Wpsabi warnings.

2022-08-11  Jakub Jelinek  

PR tree-optimization/106243
* gcc.dg/pr106243.c: Add -Wno-psabi to dg-options.
* gcc.dg/pr106243-1.c: Likewise.

[Bug c/106582] New: Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

Bug ID: 106582
   Summary: Wrong code generation resulting in HardFault
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jankowski938 at gmail dot com
  Target Milestone: ---

It makes -Ofast, -O3 unusable.


1154pQueryChunk->pSrcDriver =
pParser->pSourceDriver;
080157f4:   ldr.w   r3, [r9, #20]
080157f8:   str.w   r3, [r11, #12]
080157fc:   b.n 0x801556e 
080157fe:   movsr3, #0
08015800:   ldr.w   r2, [r9, #20]
08015804:   str r2, [r3, #12]
08015806:   udf #255; 0xff   <-- obviously wrong


if (pQueryChunk && ioIsValid(pRawChunk))
{
pQueryChunk->pSrcDriver =
pRawChunk->pSrcDriver;
}   
else if (pParser)
{
pQueryChunk->pSrcDriver =
pParser->pSourceDriver;
}


GNU C11 (GNU Tools for STM32 10.3-2021.10.20211105-1100) version 10.3.1
20210824 (release) (arm-none-eabi)
compiled by GNU C version 7.3-win32 20180312, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-mcpu=cortex-m4' '-std=gnu11' '-g3' '-D' '_GNU_SOURCE=1'
'-D' 'USE_HAL_DRIVER' '-D' '_DEBUG=1' '-D' 'DEBUG_RUN_WITHOUT_CHECKS=1' '-D'
'DEBUGFILEWRITE=0' '-D' 'DEBUG=0' '-D' 'SLOWSPIDEBUG=0' '-D' 'USE_FULL_ASSERT'
'-D' '__USE_SIMPLE_SWO=0' '-D' 'USE_SWOTRACE=1' '-D' 'AMD64' '-D'
'HSE_VALUE=1600UL' '-D' 'USE_FULL_LL_DRIVER=0' '-D' 'BOOTLOADER_VERSION=1'
'-D' 'ALLOW_SOFTWARE_BKPTS=1' '-D' 'ARM_MATH_CM4' '-D' 'FORCE_CUBE_USB' '-D'
'USE_EMBEDDED_PHY=1' '-D' 'USE_USB_OTG_FS=1' '-D' 'BITMAP_LCD_ALLOWED=0' '-D'
'LCDGUI_ALLOWED=0' '-D' 'LCD_ALLOWED=0' '-D' 'GPS_ALLOWED=0' '-D' 'STM32L4S9xx'
'-D' 'STM32L' '-D' 'INCLUDE_SLEEP_FUNCTIONS=1' '-D' 'COMPILE_FOR_EWB=1' '-D'
'COMPILE_USE_PL4S=1' '-c' '-Ofast' '-ffunction-sections' '-fdata-sections'
'-Wall' '-v' '-fstack-usage' '-MMD' '-MP' '-MF' '-MT'  '-specs=nano.specs'
'-mfpu=fpv4-sp-d16' '-mfloat-abi=hard' '-mthumb' '-o'  '-mlibarch=armv7e-m+fp'
'-march=armv7e-m+fp'
 -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 -meabi=5 -o
Libraries/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_pwr.o
C:\Users\Piotr\AppData\Local\Temp\ccHP5ygN.s
GNU assembler version 2.36.1 (arm-none-eabi) using BFD version (GNU Tools for
STM32 10.3-2021.10.20211105-1100) 2.36.1.20210621

[Bug c++/69410] [10/11/12/13 Regression] friend declarations in local classes

[creatorsmithmdt at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Zopolis0  ---
I found success in simply disabling the check at line 3754 of
gcc/cp/name-lookup.cc by setting it to 'if (1 != 1)', which then generated an
ICE at line 2484 of gcc/cp/name-lookup.cc, so I simply disabled the check
there. 

While this worked for my issue, I have not tested the change very thoroughly
and it no doubt causes issues elsewhere. 

I will look into this further.

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
However, I found another example (see attachment a-t2.c.325r.vartrack) which
does not profit from the patch:

__attribute__((noinline, noclone)) void
fn1 (int x)
{
  __asm volatile ("" : "+r" (x) : : "memory");
}

__attribute__((noinline, noclone)) int
fn2 (int x, int y)
{
  if (x)
{
  // x is copied into call-saved r11
  fn1 (x);
  // locs of x point to entry value only
  // ignoring r11
  fn1 (x);
}
  return y;
}

__attribute__((noinline, noclone)) int
fn3 (int x, int y)
{
  return fn2 (x, y);
}

int
main ()
{
  fn3 (36, 25);
  return 0;
}

For fn2 the value for parameter x is 5:5

cselib hash table:
...
(value/u:SI 5:5 @0x5fb9420/0x5f5e600)
 locs:
  from insn 1 (value/u:SI 6:263 @0x5fb9438/0x5f5e630)
  from insn 1 (entry_value:SI (reg:SI 2 %r2 [ xD.2274 ]))
  from insn 1 (reg:SI 2 %r2 [ xD.2274 ])
 no addrs

which is recorded in bb 2. In bb 4 (the true branch of the if) register r2 is
saved in r11:

bb 4 op 0 insn 36 MO_VAL_USE (concat/v:DI (value/u:DI 26:26
@0x5fb9618/0x5f5e9f0)
(reg:DI 2 %r2 [64]))
bb 4 op 1 insn 36 MO_VAL_SET (concat/u:DI (value/u:DI 26:26
@0x5fb9618/0x5f5e9f0)
(set (reg/v:DI 11 %r11 [orig:61 xD.2274+-4 ] [61])
(reg:DI 2 %r2 [64])))
(insn 36 10 11 4 (set (reg/v:DI 11 %r11 [orig:61 xD.2274+-4 ] [61])
(reg:DI 2 %r2 [64])) 1472 {*movdi_64}
 (nil))
cselib hash table:
(value/u:DI 26:26 @0x5fb9618/0x5f5e9f0)
 locs:
  from insn 36 (reg/v:DI 11 %r11 [orig:61 xD.2274+-4 ] [61])
  from insn 36 (reg:DI 2 %r2 [64])
 no addrs
cselib preserved hash table:
...
(value/u:SI 5:5 @0x5fb9420/0x5f5e600)
 locs:
  from insn 1 (value/u:SI 6:263 @0x5fb9438/0x5f5e630)
  from insn 1 (entry_value:SI (reg:SI 2 %r2 [ xD.2274 ]))
 no addrs

However at bb 4 the relation between r2 and value 5:5 is lost (except the entry
value relation). Thus I cannot record the subvalue relation between 5:5 and
26:26 at least not during creation of 26:26. Since cselib resets its table
after jumps I'm not sure how to proceed here. Any ideas?

I would be also up for the second idea and pretend that the move is not a
DImode copy but a SImode copy. However, I'm not sure how to look up the mode of
the actual type. Any pointers?

[Bug c/106582] Wrong code generation resulting in HardFault

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm-none-eabi
   Last reconfirmed||2022-08-11
Version|10.3.0  |10.3.1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Richard Biener  ---
Can you provide preprocessed source of the file where the crash occurs and the
compiler commandline?  Can you also try GCC 10.4 (or a compiler built from
the GCC 10 branch head) or possibly even GCC 12.1 to see if the issue still
reproduces there?

[Bug c/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Piotr  ---
Created attachment 53434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53434=edit
Preprocessed file

[Bug target/106577] [13 Regression] during RTL pass: subreg3 ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O -mavx since r13-2006-ga56c1641e9d25e46

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #2 from Roger Sayle  ---
I'm bootstrapping and regression testing a fix/workaround, but I'll not assign
this bug to myself (yet) as the maintainers might not like my (hacky) solution.
 The problem is that calling "force_reg" may sometimes (on some targets)
clobber recog_data.operands, so it's not universally safe to call it from
within a pre-reload splitter(!?).

[Bug target/106583] New: Suboptimal immediate generation on aarch64

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

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

Bug ID: 106583
   Summary: Suboptimal immediate generation on aarch64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

A simple codegen issue:
unsigned long long
foo (void)
{
  return 0x7efefefefefefeff;
}

generates at -O2
foo:
mov x0, 65279
movkx0, 0xfefe, lsl 16
movkx0, 0xfefe, lsl 32
movkx0, 0x7efe, lsl 48
ret

whereas LLVM can do:
foo:// @foo
mov x0, #-72340172838076674
movkx0, #65279
movkx0, #32510, lsl #48
ret

Should be a matter of just making aarch64_internal_mov_immediate in aarch64.cc
a bit smarter

[Bug debug/100960] var-tracking: parameter location in subregister not tracked

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
I really like the idea of enhancing cselib since there is a chance that other
passes might profit from it, too. The following patch fixes the initial
reported problem:

diff --git a/gcc/cselib.cc b/gcc/cselib.cc
index 6a5609786fa..64b6996a299 100644
--- a/gcc/cselib.cc
+++ b/gcc/cselib.cc
@@ -1569,6 +1569,25 @@ new_cselib_val (unsigned int hash, machine_mode mode,
rtx x)
   e->locs = 0;
   e->next_containing_mem = 0;

+  scalar_int_mode int_mode;
+  if (REG_P (x) && is_int_mode (mode, _mode) && REG_VALUES (REGNO (x)) !=
NULL
+  && (!cselib_current_insn || !DEBUG_INSN_P (cselib_current_insn)))
+{
+  rtx copy = shallow_copy_rtx (x);
+  scalar_int_mode narrow_mode;
+  FOR_EACH_MODE_UNTIL(narrow_mode, int_mode)
+   {
+ PUT_MODE_RAW (copy, narrow_mode);
+ cselib_val *v = cselib_lookup (copy, narrow_mode, 0, VOIDmode);
+ if (v)
+   {
+ rtx sub = lowpart_subreg (narrow_mode, e->val_rtx, int_mode);
+ if (sub)
+   new_elt_loc_list (v, sub);
+   }
+   }
+}
+
   if (dump_file && (dump_flags & TDF_CSELIB))
 {
   fprintf (dump_file, "cselib value %u:%u ", e->uid, hash);

So I get the subvalue relation between 5:5 and 14:14 (was initially 15:15 but
changed meanwhile due to new GCC version)

(value/u:SI 5:5 @0x4f906e0/0x4f80730)
 locs:
  from insn 17 (subreg:SI (value/u:DI 14:14 @0x4f907b8/0x4f808e0) 4)
  from insn 1 (value/u:SI 6:263 @0x4f906f8/0x4f80760)
  from insn 1 (entry_value:SI (reg:SI 2 %r2 [ xD.2274 ]))
 no addrs

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

--- Comment #4 from Jakub Jelinek  ---
Ok, I'll first implement __builtin_issignaling and then
conv_intrinsic_ieee_{value,class}.

[Bug c/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Piotr  ---
(In reply to Richard Biener from comment #1)
> Can you provide preprocessed source of the file where the crash occurs and
> the compiler commandline?  Can you also try GCC 10.4 (or a compiler built
> from
> the GCC 10 branch head) or possibly even GCC 12.1 to see if the issue still
> reproduces there?

Attached preprocessed file. 

The compiler comes with STMCubeIDE and I would not manually change it. Full
command line is in the original post (excluding include and library files and
paths)

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #5 from Francois-Xavier Coudert  ---
Previous discussion on the list:

- when I first implemented it in 2013:
https://gcc.gnu.org/legacy-ml/gcc/2013-11/msg00109.html
- more recent: https://www.mail-archive.com/gcc@gcc.gnu.org/msg97340.html

I think Joseph pointed (either in another bugzilla issue, or on the list) to a
first tentative implementation of __builtin_issignaling in the middle-end by
Sandra Loosemore, which had to be reversed because it caused trouble on some
targets. The difficulty that was cited (and why I didn't get to it myself) is
the large number of floating-point formats to be handled.

That said, having __builtin_issignaling() would be great and we could emit a
lot more of the IEEE functions in the front-end, if it were available.

[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query

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

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

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

https://gcc.gnu.org/g:16b013c9d9b4d950f89821476e791bf18c1295df

commit r13-2020-g16b013c9d9b4d950f89821476e791bf18c1295df
Author: Richard Biener 
Date:   Tue Aug 9 13:37:26 2022 +0200

tree-optimization/106514 - revisit m_import compute in backward threading

This revisits how we compute imports later used for the ranger path
query during backwards threading.  The compute_imports function
of the path solver ends up pulling the SSA def chain of regular
stmts without limit and since it starts with just the gori imports
of the path exit it misses some interesting names to translate
during path discovery.  In fact with a still empty path this
compute_imports function looks like not the correct tool.

The following instead implements what it does during the path discovery
and since we add the exit block we seed the initial imports and
interesting names from just the exit conditional.  When we then
process interesting names (aka imports we did not yet see the definition
of) we prune local defs but add their uses in a similar way as
compute_imports would have done.

compute_imports also is lacking in its walking of the def chain
compared to range_def_chain::get_def_chain which for example
handles &_1->x specially through range_op_handler and
gimple_range_operand1, so the code copies this.  A fix for
compute_imports will be done separately, also fixing the unbound
walk there.

The patch also properly unwinds m_imports during the path discovery
backtracking and from a debugging session I have verified the two
sets evolve as expected now while previously behaving slightly erratic.

Fortunately the m_imports set now also is shrunken significantly for
the PR69592 testcase (aka PR106514) so that there's overall speedup
when increasing --param max-jump-thread-duplication-stmts as
15 -> 30 -> 60 -> 120 from 1s -> 2s -> 13s -> 27s to with the patch
1s -> 2s -> 4s -> 8s.

This runs into a latent issue in X which doesn't seem to expect
any PHI nodes with a constant argument on an edge inside the path.
But we now have those as interesting, for example for the ICEing
g++.dg/torture/pr100925.C which just has sth like

  if (i)
x = 1;
  else
x = 5;
  if (x == 1)
...

where we now have the path from if (i) to if (x) and the PHI for x
in the set of imports to consider for resolving x == 1 which IMHO
looks exactly like what we want.  The path_range_query::ssa_range_in_phi
papers over the issue and drops the range to varying instead of
crashing.  I didn't want to mess with this any further in this patch
(but I couldn't resist replacing the loop over PHI args with
PHI_ARG_DEF_FROM_EDGE, so mind the re-indenting).

PR tree-optimization/106514
* tree-ssa-threadbackward.cc (back_threader::find_paths_to_names):
Compute and unwind both m_imports and interesting on the fly during
path discovery.
(back_threader::find_paths): Compute the original m_imports
from just the SSA uses of the exit conditional.  Drop
handling single_succ_to_potentially_threadable_block.
* gimple-range-path.cc (path_range_query::ssa_range_in_phi): Handle
constant PHI arguments without crashing.  Use
PHI_ARG_DEF_FROM_EDGE.

* gcc.dg/tree-ssa/ssa-thread-19.c: Un-XFAIL.
* gcc.dg/tree-ssa/ssa-thread-20.c: New testcase.

[Bug c++/53164] Undefined reference to template function instantiation

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.2

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 12.2/13

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

--- Comment #25 from David Malcolm  ---
Created attachment 53435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53435=edit
v1 of a patch to implement -Wxor-used-as-pow

This patch implements the warning, but doesn't work well; as noted in the text
it's implemented in the parser, when I think it might have to be implemented in
the lexer.

Attaching it here for reference (and as a backup for my hard drive).

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

[tetra2005 at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Yuri Gribov  ---
(In reply to Jakub Jelinek from comment #7)

I've started work on this but I'll probly only have enough time to cook a patch
on weekend.

> Perhaps either a quick check that for base ptrs that live in memory

A silly question, such cases (base_addrs living in memory) can be identified by
  gimple *g = SSA_NAME_DEF_STMT (t);
in maybe_get_single_definition having vuses?

[Bug c++/106584] New: g++ not showing correct line number in "use of deleted function" error

[accelerator0099 at gmail dot com via Gcc-bugs]

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

Bug ID: 106584
   Summary: g++ not showing correct line number in "use of deleted
function" error
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: accelerator0099 at gmail dot com
  Target Milestone: ---

Example code:

#include 
#include 

using int_map = std::map>;

void f(int_map cl);

void f2() {
int_map cl;
f(cl);
}


The actual error is that int_map is not copiable, so line 10 is ill-formed
But the compiler doesn't tell you anything about line 10, it just prints tons
of waste

This is unreasonable. You may make such a careless mistake (missing a '&') in
thousands of lines, the compiler should locate where the error is for you.

[Bug middle-end/102633] [11/12/13 Regression] warning for self-initialization despite -Wno-init-self

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:04ce2400b35225302e0d6883bb0817378180f5d7

commit r13-2022-g04ce2400b35225302e0d6883bb0817378180f5d7
Author: Marek Polacek 
Date:   Tue Jul 26 13:55:58 2022 -0400

c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
conversion by creating a NOP_EXPR.  For e.g.

  const int i = i;

that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
Consequently, we don't suppress_warning here:

711 case DECL_EXPR:
715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL
(*expr_p))
719   && !warn_init_self)
720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);

because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
doesn't disable the warning as it's supposed to.

The following patch fixes it by moving the suppress_warning call from
c_gimplify_expr to the front ends, at points where we haven't created
the NOP_EXPR yet.

PR middle-end/102633

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_gimplify_expr) : Don't call
suppress_warning here.

gcc/c/ChangeLog:

* c-parser.cc (c_parser_initializer): Add new tree parameter.  Use
it.
Call suppress_warning.
(c_parser_declaration_or_fndef): Pass d down to
c_parser_initializer.
(c_parser_omp_declare_reduction): Pass omp_priv down to
c_parser_initializer.

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Call suppress_warning.

gcc/testsuite/ChangeLog:

* c-c++-common/Winit-self1.c: New test.
* c-c++-common/Winit-self2.c: New test.

[Bug middle-end/102633] [11/12 Regression] warning for self-initialization despite -Wno-init-self

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
Summary|[11/12/13 Regression]   |[11/12 Regression] warning
   |warning for |for self-initialization
   |self-initialization despite |despite -Wno-init-self
   |-Wno-init-self  |
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Marek Polacek  ---
Fixed on trunk.  Not sure about backporting this.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 102633 Summary: [11/12 Regression] warning for self-initialization despite 
-Wno-init-self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633

   What|Removed |Added

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

[Bug c/106582] Wrong code generation resulting in HardFault

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

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

--- Comment #4 from Andrew Pinski  ---
>
080157fe:   movsr3, #0
08015800:   ldr.w   r2, [r9, #20]
08015804:   str r2, [r3, #12]

This is doing a store at the address 12 which is invalid normally.
I suspect for your code you need -fno-delete-null-pointer-checks .

Or you are missing a null pointer check.

The code does:
   if (pQueryChunk && ioIsValid(pRawChunk))
   {
pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
   }
   else
   {
if (pParser)
{
 pQueryChunk->pSrcDriver = pParser->pSourceDriver;
}
   }

But the store for "pQueryChunk->pSrcDriver" is not checked to see if
pQueryChunk was a non-null pointer before doing the store after the check that
pParser was a non-null pointer.


That is I don't think this is a bug in GCC.

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

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

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

--- Comment #9 from Jakub Jelinek  ---
If maybe_get_single_definition returns a SSA_NAME or is_gimple_min_invariant,
then it is ok as is and doesn't need anything new.
Otherwise I think we need to ask the alias oracle.

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

[accelerator0099 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Devourer Station  ---
Created attachment 53436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53436=edit
Preprocessed source file

compile with g++ example.cpp -c

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

[accelerator0099 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Devourer Station  ---
Created attachment 53437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53437=edit
compiler's output

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

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

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #5 from Kito Cheng  ---
bset generated after change X to GPR for most zbs pattern:

```
foo:
bseta1,x0,a1
andna0,a0,a1
sext.w  a0,a0
ret

```

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #6 from Andrew Pinski  ---
There is much more changes needed for ZBS support to work correctly for 32bit.
And some to get it to good state for 64bits.
I will be fixing all of them but first I need to setup a test env.

[Bug c++/101976] When constructing object, calling function and performing co_await in same statement, temporary is erroneously moved trivially

[dprokoptsev at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Dmitry Prokoptsev  ---
I believe I stumbled on this one as well -- see
https://godbolt.org/z/or31cz6eW, although it's not as trivial as the snippet
provided here.

Reproduces in 10.3 and all subsequent versions.

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[herring at lanl dot gov via Gcc-bugs]

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

--- Comment #8 from S. Davis Herring  ---
I looked at P2266R3 again; it claims that the conversion function case (in #7)
is actually covered by P1825R0.  I think that case is questionable, since it
still refers to "overload resolution to select the constructor for the copy"
and there's no constructor involved when a conversion function is used.  (In
particular, it isn't the case that the A object is converted to a Dest
temporary that is then used as the argument to Dest(Dest&&), since that would
be a second user-defined conversion.)  If we consider the intent in P1155R3,
though, it's pretty clear that that's just a wording oversight, so it's not
unreasonable that GCC and Clang (but not ICC) accept

  template Dest withMove();

in C++20 mode.  That means that we don't have to distinguish C++20 and C++23
for this discussion (at least outside of weirder cases like returning a
reference).

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #11 from joseph at codesourcery dot com  ---
On Wed, 10 Aug 2022, michael.hudson at canonical dot com via Gcc-bugs wrote:

> I just changed
> 
>   z = xx * xx;
> 
> to
> 
>   z = math_opt_barrier(xx * xx);
> 
> which perhaps isn't sufficient.

That wouldn't prevent the multiplication being moved before 
SET_RESTORE_ROUNDL, though it should suffice for the later computations as 
they all depend on z.

> But my reading of the assembly is that the issue is that some of the math code
> is being moved _after_ the restore of the fpu state implied by
> SET_RESTORE_ROUNDL (FE_TONEAREST).

To avoid code being moved after the restore, "math_force_eval (p);" just 
before the return would be appropriate.

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #53438|0   |1
is obsolete||

--- Comment #7 from Jakub Jelinek  ---
Created attachment 53440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53440=edit
gcc13-builtin-issignaling.patch

Another WIP version, the i386.md expander needs some more work but otherwise it
looks good on x86_64/i686.

[Bug middle-end/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

Piotr  changed:

   What|Removed |Added

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

--- Comment #6 from Piotr  ---
(In reply to Andrew Pinski from comment #4)
> >
> 080157fe:   movsr3, #0
> 08015800:   ldr.w   r2, [r9, #20]
> 08015804:   str r2, [r3, #12]
> 
> This is doing a store at the address 12 which is invalid normally.
> I suspect for your code you need -fno-delete-null-pointer-checks .
> 
> Or you are missing a null pointer check.
> 
> The code does:
>if (pQueryChunk && ioIsValid(pRawChunk))
>{
> pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
>}
>else
>{
> if (pParser)
> {
>  pQueryChunk->pSrcDriver = pParser->pSourceDriver;
> }
>}
> 
> But the store for "pQueryChunk->pSrcDriver" is not checked to see if
> pQueryChunk was a non-null pointer before doing the store after the check
> that pParser was a non-null pointer.
> 
> 
> That is I don't think this is a bug in GCC.

Thank you for debugging our code :) 

1. that chunk was vetted earlier in this function, so there is no need to check
it again here.
2. Offset 12 is not invalid as it is a 32bits (not 64) platform and it is
natively aligned

[Bug target/106586] New: riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

Bug ID: 106586
   Summary: riscv32 still broke with zba_zbb_zbc_zbs, ICE in
do_SUBST in C++ code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

/home/apinski/src/toolchain-riscv/riscv-build/./gcc/xgcc -shared-libgcc
-B/home/apinski/src/toolchain-riscv/riscv-build/./gcc -nostdinc++
-L/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/src
-L/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/src/.libs
-L/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/libsupc++/.libs
-nostdinc
-B/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/newlib/
-isystem
/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/newlib/targ-include
-isystem /home/apinski/src/toolchain-riscv/src/newlib/libc/include
-B/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libgloss/riscv32
-L/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libgloss/libnosys
-L/home/apinski/src/toolchain-riscv/src/libgloss/riscv32
-B/home/apinski/src/toolchain-riscv/riscv-build/../marvelldpu-tools/riscv32-marvelldpu-elf/bin/
-B/home/apinski/src/toolchain-riscv/riscv-build/../marvelldpu-tools/riscv32-marvelldpu-elf/lib/
-isystem
/home/apinski/src/toolchain-riscv/riscv-build/../marvelldpu-tools/riscv32-marvelldpu-elf/include
-isystem
/home/apinski/src/toolchain-riscv/riscv-build/../marvelldpu-tools/riscv32-marvelldpu-elf/sys-include
-L/home/apinski/src/toolchain-riscv/riscv-build/./ld
-I/home/apinski/src/toolchain-riscv/src/libstdc++-v3/../libgcc
-I/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include/riscv32-marvelldpu-elf
-I/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include
-I/home/apinski/src/toolchain-riscv/src/libstdc++-v3/libsupc++ -std=gnu++11
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cow-sstream-inst.lo -g -O2 -c
../../../../../src/libstdc++-v3/src/c++11/cow-sstream-inst.cc -o
cow-sstream-inst.o -freport-bug
during RTL pass: combine
In file included from
/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include/sstream:1218,
 from
../../../../../src/libstdc++-v3/src/c++11/sstream-inst.cc:34,
 from
../../../../../src/libstdc++-v3/src/c++11/cow-sstream-inst.cc:30:
/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include/bits/sstream.tcc:
In member function ‘void std::basic_stringbuf<_CharT, _Traits,
_Alloc>::_M_pbump(char_type*, char_type*, off_type) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]’:
/home/apinski/src/toolchain-riscv/riscv-build/riscv32-marvelldpu-elf/libstdc++-v3/include/bits/sstream.tcc:286:5:
internal compiler error: in do_SUBST, at combine.cc:701
  286 | }
  | ^
0x8e268f do_SUBST
../../src/gcc/combine.cc:700
0x1918186 subst
../../src/gcc/combine.cc:5579
0x191807a subst
../../src/gcc/combine.cc:5532
0x191807a subst
../../src/gcc/combine.cc:5532
0x191b4e7 try_combine
../../src/gcc/combine.cc:3299
0x1921c2b combine_instructions
../../src/gcc/combine.cc:1410
0x1921c2b rest_of_handle_combine
../../src/gcc/combine.cc:14978
0x1921c2b execute
../../src/gcc/combine.cc:15023
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccozqEz0.out file, please attach this to
your bugreport.

Will attach the preprocessed source in a few minutes.

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

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

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #4 from Andrew Pinski  ---
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 5a0adffb5ce..b4a08de6b93 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -426,7 +426,9 @@ riscv_build_integer_1 (struct riscv_integer_op
codes[RISCV_MAX_INTEGER_OPS],
 sign-extended (negative) representation (-1 << 31) for the
 value, if we want to build (1 << 31) in SImode.  This will
 then expand to an LUI instruction.  */
-  if (mode == SImode && value == (HOST_WIDE_INT_1U << 31))
+  if (TARGET_64BIT
+ && mode == SImode
+ && value == (HOST_WIDE_INT_1U << 31))
codes[0].value = (HOST_WIDE_INT_M1U << 31);

   return 1;


Fixes that ICE but there is still another ICE with the same reduced testcase:
0xd9898c wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../src/gcc/rtl.h:2288
0x1136bf7 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&, unsigned int)
../../src/gcc/wide-int.h:1034
0x1136bf7 generic_wide_int
>::generic_wide_int >(std::pair const&, unsigned int)
../../src/gcc/wide-int.h:790
0x1136bf7 wi::binary_traits,
std::pair, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::result_type wi::add, std::pair >(std::pair const&, std::pair const&)
../../src/gcc/wide-int.h:2442
0x1136bf7 simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
../../src/gcc/simplify-rtx.cc:5004
0x113de58 simplify_context::simplify_binary_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
../../src/gcc/simplify-rtx.cc:2569
0x10d1b75 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
../../src/gcc/rtl.h:3475
0x10d1b75 simplify_while_replacing
../../src/gcc/recog.cc:686
0x10d1b75 validate_replace_rtx_1
../../src/gcc/recog.cc:890
0x10fefb4 note_uses(rtx_def**, void (*)(rtx_def**, void*), void*)
../../src/gcc/rtlanal.cc:2065
0x10cd9b2 validate_replace_src_group(rtx_def*, rtx_def*, rtx_insn*)
../../src/gcc/recog.cc:979
0x1945e30 try_replace_reg
../../src/gcc/cprop.cc:752
0x1946509 constprop_register
../../src/gcc/cprop.cc:1023
0x194688b do_local_cprop
../../src/gcc/cprop.cc:1208
0x194688b local_cprop_pass
../../src/gcc/cprop.cc:1271
0x194688b one_cprop_pass
../../src/gcc/cprop.cc:1772
0x194688b execute_rtl_cprop
../../src/gcc/cprop.cc:1926
0x194688b execute
../../src/gcc/cprop.cc:1966
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.

Still debugging this.

[Bug analyzer/106551] [13 Regression] dup2 causes -fanalyzer ICE in valid_to_unchecked_state, at analyzer/sm-fd.cc:751

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Immad Mir :

https://gcc.gnu.org/g:837142257cbde3cc03ee0dacd1d7b2fb4fa48bae

commit r13-2023-g837142257cbde3cc03ee0dacd1d7b2fb4fa48bae
Author: Immad Mir 
Date:   Thu Aug 11 21:45:54 2022 +0530

analyzer: fix ICE casued by dup2 in sm-fd.cc[PR106551]

This patch fixes the ICE caused by valid_to_unchecked_state,
at analyzer/sm-fd.cc by handling the m_start state in
check_for_dup.

Tested lightly on x86_64.

gcc/analyzer/ChangeLog:
PR analyzer/106551
* sm-fd.cc (check_for_dup): handle the m_start
state when transitioning the state of LHS
of dup, dup2 and dup3 call.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/fd-dup-1.c: New testcases.
* gcc.dg/analyzer/fd-uninit-1.c: Remove bogus
warning.
Signed-off-by: Immad Mir 

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 53438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53438=edit
gcc13-builtin-issignaling.patch

Current WIP on the __builtin_issignaling.
Still need to look at decimal arguments (if we need/want to deal with those)
and add i386 issignalingxf2 optab so that it also handles pseudo numbers and
add test coverage.

[Bug target/106587] New: RISCV invalid jump address when compiled with -fcall-saved-reg and TCO

[michael.hale48 at gmail dot com via Gcc-bugs]

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

Bug ID: 106587
   Summary: RISCV invalid jump address when compiled with
-fcall-saved-reg and TCO
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.hale48 at gmail dot com
  Target Milestone: ---

Description of bug: When compiling with -fcall-saved on temporary registers,
program will perform a jump to a register after it has been restored from the
stack.

GCC version: gcc version 11.1.0 (GCC)

System type: 5.4.0-81-generic #91~18.04.1-Ubuntu SMP x86_64

GCC configuration: 
```
/home/mhale/github/riscv-gnu-toolchain/riscv-gcc/configure
--target=riscv32-unknown-elf --prefix=/opt/riscv --disable-shared
--disable-threads --enable-languages=c,c++ --with-system-zlib --enable-tls
--with-newlib --with-sysroot=/opt/riscv/riscv32-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libgomp --disable-nls
--disable-tm-clone-registry --src=.././riscv-gcc --disable-multilib
--with-abi=ilp32d --with-arch=rv32imfdc --with-tune=rocket
'CFLAGS_FOR_TARGET=-Os   -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os  
-mcmodel=medlow' 
```

GCC command:
```
riscv32-unknown-elf-gcc -nostartfiles -Wall -Wextra -fcall-saved-t{1..6}
clobber.c -save-temps -v -o clobber
```

Compiler output:
```
Using built-in specs.
COLLECT_GCC=/opt/riscv/bin/riscv32-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/opt/riscv/libexec/gcc/riscv32-unknown-elf/11.1.0/lto-wrapper
Target: riscv32-unknown-elf
Configured with: /home/mhale/github/riscv-gnu-toolchain/riscv-gcc/configure
--target=riscv32-unknown-elf --prefix=/opt/riscv --disable-shared
--disable-threads --enable-languages=c,c++ --with-system-zlib --enable-tls
--with-newlib --with-sysroot=/opt/riscv/riscv32-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libgomp --disable-nls
--disable-tm-clone-registry --src=.././riscv-gcc --disable-multilib
--with-abi=ilp32d --with-arch=rv32imfdc --with-tune=rocket
'CFLAGS_FOR_TARGET=-Os   -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-Os  
-mcmodel=medlow'
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-nostartfiles' '-Wall' '-Wextra' '-fcall-saved-t1'
'-fcall-saved-t2' '-fcall-saved-t3' '-fcall-saved-t4' '-fcall-saved-t5'
'-fcall-saved-t6' '-save-temps' '-v' '-o' 'clobber' '-mtune=rocket'
'-march=rv32imfdc' '-mabi=ilp32d' '-march=rv32imfdc'
 /opt/riscv/libexec/gcc/riscv32-unknown-elf/11.1.0/cc1 -E -quiet -v clobber.c
-mtune=rocket -march=rv32imfdc -mabi=ilp32d -march=rv32imfdc -Wall -Wextra
-fcall-saved-t1 -fcall-saved-t2 -fcall-saved-t3 -fcall-saved-t4 -fcall-saved-t5
-fcall-saved-t6 -fpch-preprocess -o clobber.i
ignoring nonexistent directory
"/opt/riscv/riscv32-unknown-elf/usr/local/include"
ignoring duplicate directory "/opt/riscv/riscv32-unknown-elf/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/riscv/lib/gcc/riscv32-unknown-elf/11.1.0/include
 /opt/riscv/lib/gcc/riscv32-unknown-elf/11.1.0/include-fixed

/opt/riscv/lib/gcc/riscv32-unknown-elf/11.1.0/../../../../riscv32-unknown-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-nostartfiles' '-Wall' '-Wextra' '-fcall-saved-t1'
'-fcall-saved-t2' '-fcall-saved-t3' '-fcall-saved-t4' '-fcall-saved-t5'
'-fcall-saved-t6' '-save-temps' '-v' '-o' 'clobber' '-mtune=rocket'
'-march=rv32imfdc' '-mabi=ilp32d' '-march=rv32imfdc'
 /opt/riscv/libexec/gcc/riscv32-unknown-elf/11.1.0/cc1 -fpreprocessed clobber.i
-quiet -dumpbase clobber.c -dumpbase-ext .c -mtune=rocket -march=rv32imfdc
-mabi=ilp32d -march=rv32imfdc -Wall -Wextra -version -fcall-saved-t1
-fcall-saved-t2 -fcall-saved-t3 -fcall-saved-t4 -fcall-saved-t5 -fcall-saved-t6
-o clobber.s
GNU C17 (GCC) version 11.1.0 (riscv32-unknown-elf)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 11.1.0 (riscv32-unknown-elf)
compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aecc75e33d037bca1725d62ef4fb2c89
COLLECT_GCC_OPTIONS='-nostartfiles' '-Wall' '-Wextra' '-fcall-saved-t1'
'-fcall-saved-t2' '-fcall-saved-t3' '-fcall-saved-t4' '-fcall-saved-t5'
'-fcall-saved-t6' '-save-temps' '-v' '-o' 'clobber' '-mtune=rocket'
'-march=rv32imfdc' '-mabi=ilp32d' '-march=rv32imfdc'

/opt/riscv/lib/gcc/riscv32-unknown-elf/11.1.0/../../../../riscv32-unknown-elf/bin/as
-v --traditional-format -march=rv32imfdc -march=rv32imfdc -mabi=ilp32d -o
clobber.o clobber.s
GNU 

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #12 from Michael Hudson-Doyle  
---
Ah OK, yes that fixes the failure. Does this mean all uses of
SET_RESTORE_ROUND* should be using math_opt_barrier / math_force_eval to avoid
this issue? Sounds awkward. I guess having a macro to call an always_inline
function with a given rounding mode would be less error prone but also make
code harder to read... anyway back to the glibc tracker I guess.

[Bug middle-end/106582] Wrong code generation resulting in HardFault

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

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

--- Comment #7 from Andrew Pinski  ---
It is address 12, that is offset 12 from address 0.
And yes there is a path where pQueryChunk can still be null pointer.

If pPage->dwOptions & (0x2000) is false and (pQuery is nulll or *pQuery !=
'?'), pQueryChunk can be a null pointer when pParser it true.

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #3 from Andrew Pinski  ---
Reduced testcase:
void f(int);
void g(long long __off)
{
  const int max = (1u << 31) - 1;
  while (__off > max)
{
  f(max);
}
}

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Mine. The problem here is INT_MIN is always sign extended to HWI. So there
needs to be a mask setting. Looking into how to handle INT_MIN better for
32bits.

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

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

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

Bug ID: 106588
   Summary: The constraints on most of the patterns in bitmanip.md
are broken
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, internal-improvement, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

Take:
(define_insn "*bseti"
  [(set (match_operand:X 0 "register_operand" "=r")
(ior:X (match_operand:X 1 "register_operand" "r")
   (match_operand 2 "single_bit_mask_operand" "i")))]
  "TARGET_ZBS"
  "bseti\t%0,%1,%S2"
  [(set_attr "type" "bitmanip")])

That is if something after reload decides to change operand 2, it will be
accepted and then crash while emitting %S2.

[Bug middle-end/106582] Wrong code generation resulting in HardFault

[jankowski938 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Piotr  ---
(In reply to Andrew Pinski from comment #4)
> >
> 080157fe:   movsr3, #0
> 08015800:   ldr.w   r2, [r9, #20]
> 08015804:   str r2, [r3, #12]
> 
> This is doing a store at the address 12 which is invalid normally.
> I suspect for your code you need -fno-delete-null-pointer-checks .
> 
> Or you are missing a null pointer check.
> 
> The code does:
>if (pQueryChunk && ioIsValid(pRawChunk))
>{
> pQueryChunk->pSrcDriver = pRawChunk->pSrcDriver;
>}
>else
>{
> if (pParser)
> {
>  pQueryChunk->pSrcDriver = pParser->pSourceDriver;
> }
>}
> 
> But the store for "pQueryChunk->pSrcDriver" is not checked to see if
> pQueryChunk was a non-null pointer before doing the store after the check
> that pParser was a non-null pointer.
> 
> 
> That is I don't think this is a bug in GCC.

Thank you for debugging our code :) 

1. that chunk was vetted earlier in this function, so there is no need to check
it again here.
2. Offset 12 is not invalid as it is a 32bits (not 64) platform and it is
natively aligned

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Kito Cheng from comment #5)
> bset generated after change X to GPR for most zbs pattern:

Most likely most of bitmanip.md patterns should be changed to GPR instead of X.
 Just someone will need to do the work there.
(changing *bclr pattern to GPR should improve this one to bclr too).

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|WAITING

--- Comment #26 from David Malcolm  ---
I implemented a better version of the patch; I've posted it for review here:
  https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599609.html

[Bug middle-end/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #14 from Peter Bergner  ---
Fixed everywhere.

[Bug libstdc++/106589] New: visit rejects lambdas that do not return void

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 106589
   Summary: visit rejects lambdas that do not return void
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 

int main() {
  std::visit([]{ return 0; });
}

https://godbolt.org/z/G3Penchbx

[Bug target/106590] New: x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake

[andres at anarazel dot de via Gcc-bugs]

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

Bug ID: 106590
   Summary: x86-64 miscompilation starting with "i386: Improve
ix86_expand_int_movcc" w/ mtune=skylake
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andres at anarazel dot de
  Target Milestone: ---

Hi,

The attached reproducer shows a miscompilation I found building postgres. I've
bisected postgres' failure to 1ceddd7497e, but it's of course possible it's
just surfacing a prior issue.

In my reproducer, and in postgres, the problem only occurs with -mtune=skylake
or higher, but I'm not sure how related that actually is.

$ /home/andres/build/gcc-master/install/bin/gcc --version
gcc (GCC) 12.0.1 20220423 (experimental)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-11 --version
gcc-11 (Debian 11.3.0-5) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /home/andres/build/gcc-master/install/bin/gcc -Wall -Wextra -O1
-mtune=skylake /tmp/test.i -o /tmp/test
$ /tmp/test
wrong results: procform->prorettype: 23, restype: 20

$ /home/andres/build/gcc-master/install/bin/gcc -Wall -Wextra -O1
-mtune=broadwell /tmp/test.i -o /tmp/test
$ /tmp/test
everything ok: procform->prorettype: 23, restype: 23

$ gcc-11 -Wall -Wextra -O1 -mtune=skylake /tmp/test.i -o /tmp/test
$ /tmp/test
everything ok: procform->prorettype: 23, restype: 23

I think it's pretty obvious that the code should never be able to result in
restype == 20.

Regards,

Andres

[Bug middle-end/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:6aaaf20ee4ad9c85f3099ef425720547644fb08d

commit r12-8682-g6aaaf20ee4ad9c85f3099ef425720547644fb08d
Author: Peter Bergner 
Date:   Fri Jun 17 23:43:23 2022 -0500

c: Handle initializations of opaque types [PR106016]

The initial commit that added opaque types thought that there couldn't
be any valid initializations for variables of these types, but the test
case in the bug report shows that isn't true.  The solution is to handle
OPAQUE_TYPE initializations like the other scalar types.

2022-06-17  Peter Bergner  

gcc/
PR c/106016
* expr.cc (count_type_elements): Handle OPAQUE_TYPE.

gcc/testsuite/
PR c/106016
* gcc.target/powerpc/pr106016.c: New test.

(cherry picked from commit 975658b782f36dcf6eb190966d5b705977bfd5eb)

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to jiawei from comment #7)
> I had roll back the RISC-V commit and found that this modification cause
> this building failure.
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/riscv/riscv.h;
> h=6f7f4d3fbdcfa6c8ca03604fbe5817aad6278e2e;
> hp=5083a1c24b08233810dd3b2aa4278b3ef8a75791;
> hb=4e72ccad80d69a76d149fba59603b8173fffe8fe;
> hpb=d19b4342c19e5a7fd84888aa06ebc106438d0c46
> 
> But I am not sure what's wrong with it, any suggestions?

Yes the problem is a bit complex, the problem is representation of INT_MIN is
sign extended (always) and HOST_WIDE_INT is always 64bit.
Anyways the fix is to improve the predicate to be correct and fix the
constraints too. I am working towards that but I am doing some other cleanups
along the way to the backend so the riscv backend looks more like a modern
backend.

[Bug target/106586] riscv32 still broke with zba_zbb_zbc_zbs, ICE in do_SUBST in C++ code

[jiawei at iscas dot ac.cn via Gcc-bugs]

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

jiawei  changed:

   What|Removed |Added

 CC||jiawei at iscas dot ac.cn

--- Comment #7 from jiawei  ---
I had roll back the RISC-V commit and found that this modification cause this
building failure.

https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/config/riscv/riscv.h;h=6f7f4d3fbdcfa6c8ca03604fbe5817aad6278e2e;hp=5083a1c24b08233810dd3b2aa4278b3ef8a75791;hb=4e72ccad80d69a76d149fba59603b8173fffe8fe;hpb=d19b4342c19e5a7fd84888aa06ebc106438d0c46

But I am not sure what's wrong with it, any suggestions?

[Bug libstdc++/106589] visit rejects lambdas that do not return void

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
variant#L1730:

  if constexpr (sizeof...(_Variants) == 0)
return std::forward<_Visitor>(__visitor)();

In this branch, we seem to need to detect if _Result_type is void and
explicitly cast the return type to void.

[Bug middle-end/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

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

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

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

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

commit r11-10201-gdf8567535a1f3eaa20b700be62374b2fb4f09204
Author: Peter Bergner 
Date:   Fri Jun 17 23:43:23 2022 -0500

c: Handle initializations of opaque types [PR106016]

The initial commit that added opaque types thought that there couldn't
be any valid initializations for variables of these types, but the test
case in the bug report shows that isn't true.  The solution is to handle
OPAQUE_TYPE initializations like the other scalar types.

2022-06-17  Peter Bergner  

gcc/
PR c/106016
* expr.c (count_type_elements): Handle OPAQUE_TYPE.

gcc/testsuite/
PR c/106016
* gcc.target/powerpc/pr106016.c: New test.

(cherry picked from commit 975658b782f36dcf6eb190966d5b705977bfd5eb)

[Bug target/106590] x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake

[andres at anarazel dot de via Gcc-bugs]

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

--- Comment #1 from Andres Freund  ---
Created attachment 53441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53441=edit
reproducer

[Bug middle-end/102316] Unexpected stringop-overflow Warnings on POWER CPU

[sergiodj at sergiodj dot net via Gcc-bugs]

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

Sergio Durigan Junior  changed:

   What|Removed |Added

 CC||sergiodj at sergiodj dot net

--- Comment #3 from Sergio Durigan Junior  ---
I can confirm this bug.  We're facing the problem when compiling NSS on Ubuntu
Kinetic (development version) on ppc64el, because the build uses -O3.

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 53442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53442=edit
testcase that should be ready for gcc.c-torture/execute

[Bug target/106590] [12/13 Regression] x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.2

[Bug target/106590] [12/13 Regression] x86-64 miscompilation starting with "i386: Improve ix86_expand_int_movcc" w/ mtune=skylake

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

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

--- Comment #2 from Andrew Pinski  ---
r12-8233-g1ceddd7497e15d

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Alan Modra  ---
(In reply to Segher Boessenkool from comment #7)
> '-fpatchable-function-entry=N[,M]'
>  Generate N NOPs right at the beginning of each function, with the
>  function entry point before the Mth NOP.

Bad doco.  Should be "after the Mth NOP" I think.  Or better written to avoid
the concept of a 0th nop.  Default for M is zero, placing all nops after the
function entry and before normal function prologue code.

> The nops have to be consecutive.

I hope you are making this statement based on an analysis of the purpose of
having M nops before the entry point and N-M after the entry point, because the
documentation you are quoting doesn't take into account the fact that ELFv2
functions have two entry points.  We don't have "the" entry point.

I admit I didn't analyse -fpatchable-function-entry usage in any depth before
writing the patches in PR98125.  All I did was look at the linux kernel to the
point of deciding that we want a patchable area after the local entry point to
catch all calls to the function.  That would be what
-fpatchable-function-entry=n does for ELFv2, and I think we all agree on that.

Why would someone want nops before a function entry?  Perhaps as space for a
pointer.  Or perhaps as the main patch area branched to from patched code after
the entry, to limit number of nops executed in an unpatched function.  Or
perhaps so that the function can be called by a trampoline or via function
pointer, to select either some extra code replacing those nops or the normal
function entry.  I think that means M nops go before the global entry point. 
(Note that the patch area before a function could well duplicate the normal
global entry code.)

I agree with comment #5.  nops *inside* the global entry code are a daft idea.

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Component|target  |rtl-optimization

--- Comment #3 from Andrew Pinski  ---
CE goes bad:
IF-CASE-2 found, start 6, else 8
verify found no changes in insn with uid = 35.
changing bb of uid 5
  from 8 to 6
deleting block 8
Conversion succeeded on pass 1.

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

--- Comment #4 from Andrew Pinski  ---
So the IR is slightly different entering CE1. The two BB for the sides of the
if are swapped. But that is the only difference.

This is definitely a latent bug that got exposed, it is not the first latent
bug in CE1 recently either.

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

--- Comment #7 from Segher Boessenkool  ---
'-fpatchable-function-entry=N[,M]'
 Generate N NOPs right at the beginning of each function, with the
 function entry point before the Mth NOP.

The nops have to be consecutive.

[Bug target/106585] New: RISC-V: Mis-optimized code gen for zbs

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

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

Bug ID: 106585
   Summary: RISC-V: Mis-optimized code gen for zbs
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kito at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

Command:
$ riscv64-unknown-elf-gcc foo.c -o - -S -O3 -march=rv64imafdc_zbb_zbs

```c
int foo(int rs1, int rs2) {
  return (rs1 & ~(1<

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #3 from Andrew Pinski  ---
clang prints out the similar message (even with libc++).

[Bug target/106532] riscv fails to build enabling ZBA/ZBB/ZBC/ZBS by default for 32bit

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

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #9 from Kito Cheng  ---
HI Andrew:

That's would be great if you can back port to GCC 12 branch, and thanks for
your quick fix :)

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

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

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

--- Comment #4 from Andrew Pinski  ---
Actually clang references the call:
f(cl);

When it comes to the copy constructor.

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #1 from Andrew Pinski  ---
Interesting rv32i_zbb produces:
foo:
bclra0,a0,a1
ret

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #2 from Andrew Pinski  ---
One issue is RV32i_zbb produces:
(insn 8 4 9 2 (set (reg:SI 78)
(ashift:SI (const_int 1 [0x1])
(subreg:QI (reg/v:SI 76 [ rs2 ]) 0))) "t6.c":3:20 323 {*bsetsi_1}
 (expr_list:REG_DEAD (reg/v:SI 76 [ rs2 ])
(nil)))


While RV64i_zbb does not match:
(insn 7 4 8 2 (set (reg:SI 79)
(const_int 1 [0x1])) "t6.c":3:20 140 {*movsi_internal}
 (nil))
(insn 8 7 9 2 (set (reg:SI 78)
(ashift:SI (reg:SI 79)
(subreg:QI (reg/v:DI 76 [ rs2 ]) 0))) "t6.c":3:20 154 {ashlsi3}
 (expr_list:REG_DEAD (reg:SI 79)
(expr_list:REG_DEAD (reg/v:DI 76 [ rs2 ])
(expr_list:REG_EQUAL (ashift:SI (const_int 1 [0x1])
(subreg:QI (reg/v:DI 76 [ rs2 ]) 0))
(nil)

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #3 from Andrew Pinski  ---
(define_insn "*bset"
  [(set (match_operand:X 0 "register_operand" "=r")
(ior:X (ashift:X (const_int 1)
 (match_operand:QI 2 "register_operand" "r"))
   (match_operand:X 1 "register_operand" "r")))]
  "TARGET_ZBS"
  "bset\t%0,%1,%2"
  [(set_attr "type" "bitmanip")])

It uses X iterator here instead of GPR, hmmm ...

[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization

[herring at lanl dot gov via Gcc-bugs]

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

--- Comment #7 from S. Davis Herring  ---
> In the withMove case, in C++20, we issue:
> warning: moving a local object in a return statement prevents copy elision
> for
> template Dest withMove();
> and:
> warning: redundant move in return statement
> for
> template Dest withMove();

Each of these in isolation is of course correct (which was of course never in
question).

> With my patch, we won't issue any warnings, because I'm not sure if we
> can say that in *any* instantiation of withMove the std::move is
> wrong.  Am I mistaken?

P1825R0 makes it much less likely that removing the std::move is ever a
problem.  There are cases that still need it, like

  struct A {
operator Dest() &&;
  };
  template Dest withMove();

That said, P2266R3 makes even that case work without std::move in C++23, and
GCC and Clang already accept it without std::move in C++20 mode (even though
it's not listed as a defect report).  I think that in these modes it's
impossible to need the std::move, so it's reasonable to issue the warning,
although it might make the most sense to issue a single, generic warning like
"std::move is either useless or harmful here depending on instantiation".

> Thanks for your comments and sorry if I'm still not getting your point.

Thank you for trying to work past my first unclear explanation.

[Bug target/106585] RISC-V: Mis-optimized code gen for zbs

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

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

--- Comment #4 from Kito Cheng  ---
> It uses X iterator here instead of GPR, hmmm ...

I think that because we have w-variant before, so use X rather than GPR here,
but apparently we should revise this.