[Bug c/108019] [ARM] D16 float register was used but not saved in integer-dominated code

[zhangyuan21 at xiaomi dot com via Gcc-bugs]

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

--- Comment #3 from zyfeier  ---
Created attachment 54046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54046=edit
preprocessed file for calling function

[Bug c/108019] [ARM] D16 float register was used but not saved in integer-dominated code

[zhangyuan21 at xiaomi dot com via Gcc-bugs]

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

--- Comment #2 from zyfeier  ---
C code:

int weak_function up_alarm_tick_start(clock_t ticks)
{
  int ret = -EAGAIN;

  if (g_oneshot_lower != NULL)
{
  clock_t now = 0;
  clock_t delta;

  ONESHOT_TICK_CURRENT(g_oneshot_lower, );
  delta = ticks - now;
  if ((sclock_t)delta < 0)
{
  delta = 0;
}

  ret = ONESHOT_TICK_START(g_oneshot_lower, oneshot_callback,
   NULL, delta);
}

  return ret;
}

Part of assembly code:
38020444 :
380204b8:   e592ldr r0, [r2]
380204bc:   e5932000ldr r2, [r3]
380204c0:   e154cmp r4, r0
380204c4:   e5931004ldr r1, [r3, #4]
380204c8:   21a04000movcs   r4, r0
380204cc:   e0940002addsr0, r4, r2
380204d0:   e2a11000adc r1, r1, #0
380204d4:   eb0038dabl  3802e844 

3802e844 :
3802e844:   e92d49f0push{r4, r5, r6, r7, r8, fp, lr}
3802e848:   e30e66f8movwr6, #59128  ; 0xe6f8
3802e84c:   e343689cmovtr6, #14492  ; 0x389c
3802e850:   e28db018add fp, sp, #24
3802e854:   e24dd024sub sp, sp, #36 ; 0x24
3802e858:   e5965000ldr r5, [r6]
3802e85c:   e59f31c0ldr r3, [pc, #448]  ; 3802ea24

3802e860:   e355cmp r5, #0
3802e864:   e5933000ldr r3, [r3]
3802e868:   e50b3020str r3, [fp, #-32]  ; 0xffe0
3802e86c:   e3a03000mov r3, #0
3802e870:   0a5ebeq 3802e9f0 
3802e874:   f2c00010vmov.i32d16, #0 ; 0x
3802e878:   e1a07000mov r7, r0
3802e87c:   e1a5mov r0, r5
3802e880:   e1a04001mov r4, r1
3802e884:   ed4b0b0dvstrd16, [fp, #-52] ; 0xffcc
3802e888:   eb004c98bl  38041af0 <__asan_load4_noabort>
3802e88c:   e5958000ldr r8, [r5]
3802e890:   e288001cadd r0, r8, #28
3802e894:   eb004c95bl  38041af0 <__asan_load4_noabort>
3802e898:   e598301cldr r3, [r8, #28]
3802e89c:   e353cmp r3, #0
3802e8a0:   0a21beq 3802e92c 
3802e8a4:   e24b1034sub r1, fp, #52 ; 0x34
3802e8a8:   e1a5mov r0, r5
3802e8ac:   e12fff33blx r3

Problem:
At 0x3802e874 d16 was cleared, but the calling function does not save this
register.

[Bug c/108019] [ARM] D16 float register was used but not saved in integer-dominated code

[zhangyuan21 at xiaomi dot com via Gcc-bugs]

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

--- Comment #1 from zyfeier  ---
Created attachment 54045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54045=edit
preprocessed file

[Bug c/108019] New: [ARM] D16 float register was used but not saved in integer-dominated code

[zhangyuan21 at xiaomi dot com via Gcc-bugs]

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

Bug ID: 108019
   Summary: [ARM] D16 float register was used but not saved in
integer-dominated code
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhangyuan21 at xiaomi dot com
  Target Milestone: ---

Created attachment 54044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54044=edit
gcc version information

[Bug tree-optimization/108017] ptr+v >= ptr + d should converted into (long)v >= CST(/sizeof(*ptr))

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
We do this for  + C {!=,==} ' + C' - I think we're afraid of relational
compares here though, even with TYPE_OVERFLOW_UNDEFINED.

/* (+b) !=/== ([1] + c) ->  sizeof(a[0]) + b !=/== c */
(for neeq (ne eq)
 (simplify 
  (neeq (pointer_plus ADDR_EXPR@0 @1) (pointer_plus ADDR_EXPR@2 @3))
   (with { poly_int64 diff; tree inner_type = TREE_TYPE (@1);}
(if (ptr_difference_const (@0, @2, ))
 (neeq (plus { build_int_cst_type (inner_type, diff); } @1) @3)

that could be relaxed to general @0/@2 (at some cost) and to
relational compares with TYPE_OVERFLOW_UNDEFINED.

[Bug c/108018] New: Wide immediate sequences not scheduled for POWER10 fusion

[npiggin at gmail dot com via Gcc-bugs]

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

Bug ID: 108018
   Summary: Wide immediate sequences not scheduled for POWER10
fusion
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npiggin at gmail dot com
  Target Milestone: ---

POWER10 has "wideimmediate" fusion sequences that include addi rx,ra,si ; addis
rx,rx,SI and addis rx,ra,si ; addi rx,rx,SI

--- test.c ---
static int foo, bar;

unsigned long test(void)
{
return (unsigned long) + (unsigned long)
}
---

This test case when compiled with -O2 -mcpu=power10 -mno-pcrel results in

addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
addis 3,2,.LANCHOR0@toc@ha
addis 9,2,.LANCHOR0+4@toc@ha
addi 3,3,.LANCHOR0@toc@l
addi 9,9,.LANCHOR0+4@toc@l
add 3,3,9
blr

The TOC pointer generation is scheduled properly because it is the global entry
prologue, but the variable address generation is scheduled to favour
dependencies rather than the static fusion sequences that P10 has, which should
be preferable.

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

[andrew at sifive dot com via Gcc-bugs]

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

--- Comment #9 from Andrew Waterman  ---
On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
>
> palmer at gcc dot gnu.org changed:
>
>What|Removed |Added
> 
>  CC||palmer at gcc dot gnu.org
>
> --- Comment #8 from palmer at gcc dot gnu.org ---
> (In reply to Jeffrey A. Law from comment #7)
> > Raphael and I are poking at this a bit.  I can't convince myself that it's
> > actually safe to use GPR for the bit manipulation patterns.
> >
> > For rv64 I'm pretty sure the b* instructions are operating on 64bit
> > quantities only.  Meaning they might twiddle the SI sign bit without
> > extending.  If we were to change these patterns to use GPR and the result
> > then fed an addw (for example) then we would have inconsistent register
> > state as operand twiddled by the prior b* pattern wouldn't have been sign
> > extended.
> >
> > To be clear, I think this is a limitation imposed by the ISA docs, not GCC
> > where this will be reasonably well defined.
>
> So you're worried about addw (and the various other OP-32 instructions) 
> needing
> signed extended high parts in registers in order to function as expected?  
> I've
> never gotten that from the ISA manual, there might be some vestigial MIPS-isms
> floating around the RISC-V port that indicate that though (as we've got 
> similar
> constraints for the comparisons).
>
> That said, I'v gone and actually read the ISA manual here and it's not at all
> specific.  I'm seeing
>
> ADDW and SUBW are RV64I-only instructions that are defined analogously
> to ADD and SUB but operate on 32-bit values and produce signed 32-bit
> results.  Overflows are ignored, and the low 32-bits of the result is
> sign-extended to 64-bits and written to the destination register.
>
> which doesn't explicitly say the high 32-bits of the inputs are ignored.  As
> far as I can tell "32-bit values" isn't defined anywhere, so that's not so
> useful.
>
> Do you know if there's any hardware that needs extended values for addw and
> friends?  That'd almost certainly break a lot of binaries, but I could
> certainly buy an argument saying it's to the spec (and the actual words in the
> spec, not just this "anything goes" compatibility stuff).

The spec explicitly says that the upper 32 bits of the inputs are
ignored; you just need to read a few paragraphs up.
https://github.com/riscv/riscv-isa-manual/blob/b7080e0d18765730ff4f3d07b866b4884a8be401/src/rv64.tex#L18-L21

>
> > With that in mind I think the only path forward is new patterns that (sadly)
> > use explicit subregs for sources, but still set a DImode destination.
> >
> > I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly,
> > don't hesitate to let me know.
>
> Kind of just a related FYI: the comparison instructions and various bits of 
> the
> ABI do require values in canonical forms (the ABI stuff isn't exactly sign
> extended, but there's a rule).  That's all a big fragile.

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

[Andrew Waterman]

On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
>
> palmer at gcc dot gnu.org changed:
>
>What|Removed |Added
> 
>  CC||palmer at gcc dot gnu.org
>
> --- Comment #8 from palmer at gcc dot gnu.org ---
> (In reply to Jeffrey A. Law from comment #7)
> > Raphael and I are poking at this a bit.  I can't convince myself that it's
> > actually safe to use GPR for the bit manipulation patterns.
> >
> > For rv64 I'm pretty sure the b* instructions are operating on 64bit
> > quantities only.  Meaning they might twiddle the SI sign bit without
> > extending.  If we were to change these patterns to use GPR and the result
> > then fed an addw (for example) then we would have inconsistent register
> > state as operand twiddled by the prior b* pattern wouldn't have been sign
> > extended.
> >
> > To be clear, I think this is a limitation imposed by the ISA docs, not GCC
> > where this will be reasonably well defined.
>
> So you're worried about addw (and the various other OP-32 instructions) 
> needing
> signed extended high parts in registers in order to function as expected?  
> I've
> never gotten that from the ISA manual, there might be some vestigial MIPS-isms
> floating around the RISC-V port that indicate that though (as we've got 
> similar
> constraints for the comparisons).
>
> That said, I'v gone and actually read the ISA manual here and it's not at all
> specific.  I'm seeing
>
> ADDW and SUBW are RV64I-only instructions that are defined analogously
> to ADD and SUB but operate on 32-bit values and produce signed 32-bit
> results.  Overflows are ignored, and the low 32-bits of the result is
> sign-extended to 64-bits and written to the destination register.
>
> which doesn't explicitly say the high 32-bits of the inputs are ignored.  As
> far as I can tell "32-bit values" isn't defined anywhere, so that's not so
> useful.
>
> Do you know if there's any hardware that needs extended values for addw and
> friends?  That'd almost certainly break a lot of binaries, but I could
> certainly buy an argument saying it's to the spec (and the actual words in the
> spec, not just this "anything goes" compatibility stuff).

The spec explicitly says that the upper 32 bits of the inputs are
ignored; you just need to read a few paragraphs up.
https://github.com/riscv/riscv-isa-manual/blob/b7080e0d18765730ff4f3d07b866b4884a8be401/src/rv64.tex#L18-L21

>
> > With that in mind I think the only path forward is new patterns that (sadly)
> > use explicit subregs for sources, but still set a DImode destination.
> >
> > I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly,
> > don't hesitate to let me know.
>
> Kind of just a related FYI: the comparison instructions and various bits of 
> the
> ABI do require values in canonical forms (the ABI stuff isn't exactly sign
> extended, but there's a rule).  That's all a big fragile.

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

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #8 from palmer at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #7)
> Raphael and I are poking at this a bit.  I can't convince myself that it's
> actually safe to use GPR for the bit manipulation patterns.
> 
> For rv64 I'm pretty sure the b* instructions are operating on 64bit
> quantities only.  Meaning they might twiddle the SI sign bit without
> extending.  If we were to change these patterns to use GPR and the result
> then fed an addw (for example) then we would have inconsistent register
> state as operand twiddled by the prior b* pattern wouldn't have been sign
> extended.
> 
> To be clear, I think this is a limitation imposed by the ISA docs, not GCC
> where this will be reasonably well defined.

So you're worried about addw (and the various other OP-32 instructions) needing
signed extended high parts in registers in order to function as expected?  I've
never gotten that from the ISA manual, there might be some vestigial MIPS-isms
floating around the RISC-V port that indicate that though (as we've got similar
constraints for the comparisons).

That said, I'v gone and actually read the ISA manual here and it's not at all
specific.  I'm seeing

ADDW and SUBW are RV64I-only instructions that are defined analogously
to ADD and SUB but operate on 32-bit values and produce signed 32-bit
results.  Overflows are ignored, and the low 32-bits of the result is
sign-extended to 64-bits and written to the destination register.

which doesn't explicitly say the high 32-bits of the inputs are ignored.  As
far as I can tell "32-bit values" isn't defined anywhere, so that's not so
useful.

Do you know if there's any hardware that needs extended values for addw and
friends?  That'd almost certainly break a lot of binaries, but I could
certainly buy an argument saying it's to the spec (and the actual words in the
spec, not just this "anything goes" compatibility stuff).

> With that in mind I think the only path forward is new patterns that (sadly)
> use explicit subregs for sources, but still set a DImode destination.
> 
> I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly,
> don't hesitate to let me know.

Kind of just a related FYI: the comparison instructions and various bits of the
ABI do require values in canonical forms (the ABI stuff isn't exactly sign
extended, but there's a rule).  That's all a big fragile.

[Bug tree-optimization/108017] New: ptr+v >= ptr + d should converted into (long)v >= CST(/sizeof(*ptr))

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

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

Bug ID: 108017
   Summary: ptr+v >= ptr + d should converted into (long)v >=
CST(/sizeof(*ptr))
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
_Bool f(int *a, __SIZE_TYPE__ t, __SIZE_TYPE__ t1)
{
int *b = a + t;
int *c = a + t1;
return c >= b;
}

_Bool f1(int *a, __SIZE_TYPE__ t, __SIZE_TYPE__ t1)
{
long tt = t;
long tt1 = t1;
return tt1 >= tt;
}
```
These two should give the same code.

LLVM does this optimization.

I noticed this while looking into the code from the blog at
https://lemire.me/blog/2022/12/06/optimizing-compilers-reload-vector-constants-needlessly/
(but not vector constant issue though).

[Bug preprocessor/105005] Misleading error message at #line directive with no arguments

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Patches should be sent to over email to gcc-patc...@gcc.gnu.org after reading
https://gcc.gnu.org/contribute.html .

Confirmed.

[Bug middle-end/108016] RISC-V：Bad codegen in scalar code comparing to LLVM

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

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

--- Comment #1 from Andrew Pinski  ---
99% it is a dup of those other bugs.

[Bug c++/108016] New: RISC-V：Bad codegen in scalar code comparing to LLVM

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 108016
   Summary: RISC-V：Bad codegen in scalar code comparing to LLVM
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

This is the simple code example:
https://godbolt.org/z/jKGavbx7o

Post it here and let me not forget about it. 
If someone can fix it, I will really appreciate.

If not, I will fix it if I have time (Currently busy with working on RVV
support).

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #3 from Eugene Rozenfeld  ---
Repro steps:

gcc -O2 -g -o ./pr108000 ./pr108000.c

perf record -e cpu/event=0xC4,umask=0x20/puk -b -m8 -o perf.data ./pr108000

create_gcov --binary ./pr108000 --profile=./perf.data -gcov_version=2
--gcov=./pr108000.gcda

gcc ./pr108000.c -O2 -fauto-profile=./pr108000.gcda -O2 -o ./pr108000.afdo

[Bug testsuite/108005] FAIL: c-c++-common/asan/null-deref-1.c /pointer-compare-1.c output pattern test

[zhangkefan at ultrarisc dot com via Gcc-bugs]

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

zhangkefan at ultrarisc dot com  changed:

   What|Removed |Added

   Host||riscv64-unknown-linux-gnu
 Target||riscv64-unknown-linux-gnu
  Build||x86_64-pc-linux-gnu

--- Comment #3 from zhangkefan at ultrarisc dot com  ---
(In reply to Richard Biener from comment #2)
> Really for GCC 11.1.0?  Which architecture/OS?

riscv64/ubuntu22.04qemu7.0.0 and fpga also have this problem

riscv-gcc/build/gcc/xgcc  version 11.1.0 (GCC)

[Bug c/105177] GCC should warn if pragma redefine_extname fails due to missing declaration

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

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

--- Comment #1 from Andrew Pinski  ---
Here is the Solaris compiler documentation about this feature since GCC is
supposed to be implementing them:
https://docs.oracle.com/cd/E37069_01/html/E37074/bjacu.html

[Bug libstdc++/108015] [13 Regression] 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc failure on i686-linux

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

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

--- Comment #1 from Andrew Pinski  ---
Funny I was just looking at the preprocessor PR about tokenizing even inside
`#if 0` yesterday too.

[Bug libstdc++/108015] [13 Regression] 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc failure on i686-linux

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |13.0

[Bug libstdc++/108015] New: [13 Regression] 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc failure on i686-linux

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

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

Bug ID: 108015
   Summary: [13 Regression]
17_intro/headers/c++2011/stdc++_multiple_inclusion.cc
failure on i686-linux
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I'm seeing
FAIL: 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc (test for excess
errors)
Excess errors:
/home/jakub/src/gcc/obj45/i686-pc-linux-gnu/libstdc++-v3/include/chrono:2436:
warning: missing terminating ' character

This is about
&& (ratio_greater_equal_v<_Period, ratio<1, 4'000'000'000>>
line, which is surely in a section guarded with
#if __cplusplus >= 202002L
...
#endif
This boils down to:
#if __cplusplus >= 202002L
int a = 4'000'000'000;
#endif
int b = 42;
which also warns when preprocessed or compiled with -std=c++11, the
preprocessor
tokenizes even skipped tokens.

[Bug tree-optimization/108008] [12 Regression] Compiler mis-optimization with posix_memalign

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to dhsbz from comment #2)
> > (using gcc as of the prior commit shows the behavior as in the bug
> > description). I can't judge if the above commit had fixed an underlying
> > problem that the example was triggering, or if it changed the behavior in an
> > indirect way.
> 
> I think it just changes the IR just ever so slightly which makes the problem
> go latent. As shown sometimes adding and removing vectorization.

Even my example does not show the issue with GCC 11 but does show it with GCC
12.

[Bug tree-optimization/108008] [12 Regression] Compiler mis-optimization with posix_memalign

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-07
Summary|Compiler mis-optimization   |[12 Regression] Compiler
   |with posix_memalign |mis-optimization with
   ||posix_memalign
   Target Milestone|--- |12.3
 Ever confirmed|0   |1
  Known to work||8.1.0

--- Comment #7 from Andrew Pinski  ---
(In reply to dhsbz from comment #2)
> (using gcc as of the prior commit shows the behavior as in the bug
> description). I can't judge if the above commit had fixed an underlying
> problem that the example was triggering, or if it changed the behavior in an
> indirect way.

I think it just changes the IR just ever so slightly which makes the problem go
latent. As shown sometimes adding and removing vectorization.

[Bug tree-optimization/108008] Compiler mis-optimization with posix_memalign

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #54042|0   |1
is obsolete||

--- Comment #6 from Andrew Pinski  ---
Created attachment 54043
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54043=edit
Reduced further but needs -O3 -fno-tree-vectorize to hit the bug

[Bug tree-optimization/108008] Compiler mis-optimization with posix_memalign

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #54041|0   |1
is obsolete||

--- Comment #5 from Andrew Pinski  ---
Created attachment 54042
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54042=edit
Removed headers and removed difference from -std=c++17/-std=gnu++17

-std=c++17 was causing posix_memalign not to be known as a allocator and such.
Hide it using the gnu::noipa attribute instead.

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

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

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

--- Comment #7 from Jeffrey A. Law  ---
Raphael and I are poking at this a bit.  I can't convince myself that it's
actually safe to use GPR for the bit manipulation patterns.

For rv64 I'm pretty sure the b* instructions are operating on 64bit quantities
only.  Meaning they might twiddle the SI sign bit without extending.  If we
were to change these patterns to use GPR and the result then fed an addw (for
example) then we would have inconsistent register state as operand twiddled by
the prior b* pattern wouldn't have been sign extended.

To be clear, I think this is a limitation imposed by the ISA docs, not GCC
where this will be reasonably well defined.

With that in mind I think the only path forward is new patterns that (sadly)
use explicit subregs for sources, but still set a DImode destination.

I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly, don't
hesitate to let me know.

[Bug tree-optimization/108008] Compiler mis-optimization with posix_memalign

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 54041
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54041=edit
Slightly more reduced testcase

Slightly more reduced and self contained testcase.
I was able to remove the exit from Init as it just caused the function not to
be inlined.
There is more to be done to reduce it further though.

[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)

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

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #14)
> Comment #10 contains a simple timing measurement in from my Intel Core2 Duo
> based system.  gfortran with its current method (ie., -fcx-fortran-rules)
> takes 44.5 clock ticks for a complex division.
[...]
> ticks.  I haven't looked at what algorithm C uses, but I suspect its along
> the lines you suggest.

I may have misread the library implementation of complex division (libgcc2),
but it likely does really much more that we need for Fortran.  And some
of the overhead seems to come from doing many more divisions in the
library version than in the current gfortran variant.

> The question is likely do we break backwards
> compatibility and remove -fcx-fortran-rules or change when/how
> -fcx-fortran-rules applies (e.g., add it to -ffast-math?)

I would certainly not be happy breaking backwards compatibility,
but is there a precise definition of what the "cx-fortran-rules" are?

I had the silent hope that manipulating exponents of IEEE floats could be a
cheap operation, allowing for a cheaper solution than the expensive method
that gets really borderline cases better, although an unreasonable cost.

[Bug tree-optimization/108008] Compiler mis-optimization with posix_memalign

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to dhsbz from comment #2)
> I tried the example with gcc master, and it seems to behave as expected
> (i.e. sameZ=1 for i=1). Tracking back it seems the commit which restored
> this was:

r13-1728-gce92603fbe3b48

[Bug tree-optimization/108008] Compiler mis-optimization with posix_memalign

[dhsbz at chaw dot com via Gcc-bugs]

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

dhsbz at chaw dot com changed:

   What|Removed |Added

 CC||dhsbz at chaw dot com

--- Comment #2 from dhsbz at chaw dot com ---
I tried the example with gcc master, and it seems to behave as expected (i.e.
sameZ=1 for i=1). Tracking back it seems the commit which restored this was:

commit ce92603fbe3b4870e0a38efee1ee766d62942065 (HEAD)
Author: Richard Biener
Date:   Mon Jul 18 12:06:00 2022 +0200

Improve common reduction vs builtin code generation in loop distribution
[...]

(using gcc as of the prior commit shows the behavior as in the bug
description). I can't judge if the above commit had fixed an underlying problem
that the example was triggering, or if it changed the behavior in an indirect
way.

[Bug fortran/108010] ICE in reduce_unary, at fortran/arith.cc:1345

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.  Closing.

Thanks for the report!

[Bug fortran/108010] ICE in reduce_unary, at fortran/arith.cc:1345

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:7d6512d102a5a4fb3939de95bce38d154512a19f

commit r13-4545-g7d6512d102a5a4fb3939de95bce38d154512a19f
Author: Harald Anlauf 
Date:   Wed Dec 7 21:50:23 2022 +0100

Fortran: handle zero-sized arrays in ctors with typespec [PR108010]

gcc/fortran/ChangeLog:

PR fortran/108010
* arith.cc (reduce_unary): Handle zero-sized arrays.
(reduce_binary_aa): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/108010
* gfortran.dg/pr108010.f90: New test.

[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)

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

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

--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #13)
> (In reply to Steve Kargl from comment #12)
> > The optimization level is irrelevant.  gfortran unilaterally
> > uses -fcx-fortran-rules, and there is no way to disable this
> > option to user the slower, but stricter, evaluation.  One
> > will always get complex division computed by
> > 
> > a+ib   a + b(d/c) b - a(d/c) 
> >  = -- + i   |c| > |d|
> > c+id   c + d(d/c) c + d(d/c)
> > 
> > and similar for |d| > |c|.
> > 
> > There are a few problems with this. d/c can trigger an invalid underflow
> > exception.  If d == c, you then have numerators of a + b and b - a, you
> > can get a invalid overflow for a = huge() and b > 1e291_8.
> 
> I am wondering how slow an algorithm would be that scales numerator
> and denominator by respective factors that are powers of 2, e.g.
> 
> e_num = 2. ** -max (exponent (a), exponent (b))
> e_den = 2. ** -max (exponent (c), exponent (d))
> 
> The modulus of scaled values would be <= 1, even for any of a,... being
> huge().
> Of course this does not address underflows that could occur during scaling,
> or denormalized numbers, which are numerically irrelevant for the result.
> 
> Is there anything else wrong with this approach?

Comment #10 contains a simple timing measurement in from my Intel Core2 Duo
based system.  gfortran with its current method (ie., -fcx-fortran-rules) takes
44.5 clock ticks for a complex division.  If I sidestep the option and force it
to use the C language method of evaluation, it takes 62 clock ticks.  I haven't
looked at what algorithm C uses, but I suspect its along the lines you suggest.
 The question is likely do we break backwards compatibility and remove
-fcx-fortran-rules or change when/how -fcx-fortran-rules applies (e.g., add it
to -ffast-math?)

[Bug sanitizer/108014] Incorrect line number in UBSAN's report

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

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

--- Comment #2 from Andrew Pinski  ---
I don't know if this is a bug really.
The statement on line 9 (`e = b + 1;`) gets removed and therefor there was no
undefined behavior that happens at all.


Either DSE or CDDCE does the removal (depending on if you use -Og or -O1):

  Deleted trivially dead stmt: [/app/example.cpp:9:7] e_9 = (long int) _2;

  Deleted trivially dead stmt: [/app/example.cpp:9:11] _2 = .UBSAN_CHECK_ADD
(2147483647, 1);

[Bug sanitizer/108014] Incorrect line number in UBSAN's report

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

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

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

[Bug sanitizer/108014] New: Incorrect line number in UBSAN's report

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108014
   Summary: Incorrect line number in UBSAN's report
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, GCC's UBsan at -O1 and above produces incorrect line
number in the final report.

Compiler explorer: https://godbolt.org/z/jvvdrfPdo

% cat -n a.c
 1  int a, b;
 2  char c[5];
 3  int d[1];
 4  static int g() {
 5long e;
 6b = __INT_MAX__;
 7for (int f = 0; f < sizeof(c); f++)
 8  e = b + 1;
 9return 0;
10  }
11  int main() {
12for (b = 0;b<1; b++) {
13  d[a];
14  g();
15}
16  }
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
a.c:8:11: runtime error: signed integer overflow: 2147483647 + 1 cannot be
represented in type 'int'
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
a.c:12:20: runtime error: signed integer overflow: 2147483647 + 1 cannot be
represented in type 'int'
%

[Bug fortran/107874] merge not using all its arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #24 from anlauf at gcc dot gnu.org ---
I didn't see any testsuite failures left.  Closing again.  (Fingers crossed.)

[Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)

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

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

--- Comment #13 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #12)
> The optimization level is irrelevant.  gfortran unilaterally
> uses -fcx-fortran-rules, and there is no way to disable this
> option to user the slower, but stricter, evaluation.  One
> will always get complex division computed by
> 
> a+ib   a + b(d/c) b - a(d/c) 
>  = -- + i   |c| > |d|
> c+id   c + d(d/c) c + d(d/c)
> 
> and similar for |d| > |c|.
> 
> There are a few problems with this. d/c can trigger an invalid underflow
> exception.  If d == c, you then have numerators of a + b and b - a, you
> can get a invalid overflow for a = huge() and b > 1e291_8.

I am wondering how slow an algorithm would be that scales numerator
and denominator by respective factors that are powers of 2, e.g.

e_num = 2. ** -max (exponent (a), exponent (b))
e_den = 2. ** -max (exponent (c), exponent (d))

The modulus of scaled values would be <= 1, even for any of a,... being huge().
Of course this does not address underflows that could occur during scaling,
or denormalized numbers, which are numerically irrelevant for the result.

Is there anything else wrong with this approach?

[Bug fortran/108010] ICE in reduce_unary, at fortran/arith.cc:1345

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058586.html

[Bug debug/106719] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/108013] `extern "C" int t = 1;` warns about being declared as extern and initialized

[manx-bugzilla at problemloesungsmaschine dot de via Gcc-bugs]

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

--- Comment #1 from Jörn Heusipp  ---
Thanks for the work-around with using a extern "C" {} block. That's actually
way better than the extra .c file that I did use.

[Bug fortran/108010] ICE in reduce_unary, at fortran/arith.cc:1345

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-12-07
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from anlauf at gcc dot gnu.org ---
Taking.

[Bug fortran/108010] ICE in reduce_unary, at fortran/arith.cc:1345

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 54038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54038=edit
Tentative patch

We need to catch zero-sized array ctors.

[Bug c/45977] "warning: 'i' initialized and declared 'extern'" could use a separate warning flag controlling it

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Jörn Heusipp from comment #8)
> I am seeing the same warning, however in C++, when trying to set DJGPP's CRT
> startup flags (see ):

I filed PR 108013 for that case since it is a different issue all together
really.

[Bug c++/108013] New: `extern "C" int t = 1;` warns about being declared as extern and initialized

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

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

Bug ID: 108013
   Summary: `extern "C" int t = 1;` warns about being declared as
extern and initialized
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

I don't think we should warn about this case:
```
extern "C" int h = 1; 
```

We should warn for:
```
extern int h = 1; 
```
Though.

We already don't warn for:
```
extern "C" { int h = 1; }
```
Which is a small workaround but I don't think it is needed though.

Forwarded from bug 45977 comment #8 .

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #17 from joseph at codesourcery dot com  ---
The details of not expanding in cases where it matters whether and how 
many times something is expanded - such as arguments expanding to have 
unbalanced parentheses - may be a non-obvious consequence that wasn't 
considered in WG14.  The basic definition of ignoring the pp-tokens 
without converting them to tokens (and thus not requiring them to parse as 
any particular kind of C language construct) was clear enough from the 
paper (whether or not anyone felt the need to comment on that aspect of 
the definition).

[Bug c++/108001] unamed struct extension is documented for C++

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #1 from joseph at codesourcery dot com  ---
At least some cases of this are a standard C++ feature - which ones are 
still an extension for C++ and so need documenting as such?

[Bug c++/108012] Add fix-it hint for smartptr.foo which should be smartptr->foo

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> For bonus points, check whether the result of smartptr->i would actually
> compile. Maybe the user meant to access a real member of the smart pointer
> type, like a Ptr::get() or Ptr::reset() member, in which case changing it ->
> would not make it any more correct.

Related to PR 91138, where we make an incorrect fix-it suggestion for the raw
pointer case.

[Bug c++/108012] Add fix-it hint for smartptr.foo which should be smartptr->foo

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
There's PR 84898 which is related but not the same (it's not about smart
pointers).

[Bug c++/108012] Add fix-it hint for smartptr.foo which should be smartptr->foo

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, I thought I had saw a bug like this before but I can't seem to find
it.

[Bug c++/100460] [11/12/13 Regression][modules] mingw build broken due to use of unsupported open() flags

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

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

--- Comment #6 from Andrew Pinski  ---
The way libgfortran fixed this two ways.
First way is to use umask (disabled for mingw though). Second way is doing
#ifndef/#define 0

See:
r6-2699-g18a2180daa88bc
r0-63059-g41724e6a1387d9

[Bug c++/108012] New: Add fix-it hint for smartptr.foo which should be smartptr->foo

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

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

Bug ID: 108012
   Summary: Add fix-it hint for smartptr.foo which should be
smartptr->foo
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Given:

struct S { int i; };

struct Ptr
{
  S* operator->() const;
};

void func(S* rawptr, Ptr smartptr)
{
  int i = rawptr.i;
  int j = smartptr.i;
}


G++ helpfully points out your mistake in the first case, but not the second:

sp.cc: In function 'void func(S*, Ptr)':
sp.cc:10:18: error: request for member 'i' in 'rawptr', which is of pointer
type 'S*' (maybe you meant to use '->' ?)
   10 |   int i = rawptr.i;
  |  ^
sp.cc:11:20: error: 'struct Ptr' has no member named 'i'
   11 |   int j = smartptr.i;
  |^



Maybe the compiler could chek whether Ptr::operator->() exists, and if so, add
a similar "(maybe you meant to use '->' ?)" hint.

For bonus points, check whether the result of smartptr->i would actually
compile. Maybe the user meant to access a real member of the smart pointer
type, like a Ptr::get() or Ptr::reset() member, in which case changing it ->
would not make it any more correct.

Also, it looks like the "maybe you mean to use '->' ?" is not a real fix-it
hint, i.e. not affected by -fdiagnostics-parseable-fixits. Should it be a real
fix-it?

[Bug testsuite/108005] FAIL: c-c++-common/asan/null-deref-1.c /pointer-compare-1.c output pattern test

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Keywords||testsuite-fail
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-07

--- Comment #2 from Richard Biener  ---
Really for GCC 11.1.0?  Which architecture/OS?

[Bug c++/100460] [11/12/13 Regression][modules] mingw build broken due to use of unsupported open() flags

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

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

--- Comment #5 from Andrew Pinski  ---
https://osdn.net/projects/mingw/lists/archive/notify/2020-January/000438.html

[Bug target/108011] [13 Regression] gcc-13-20221204 failure to build on Cygwin: ‘uc_mcontext’ has incomplete type

[mckelvey at maskull dot com via Gcc-bugs]

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

James McKelvey  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #6 from James McKelvey  ---
OK, but it has been building for a long time without --disable-multilib.
I guess Cygwin changed something. I don't need 32 bit so it's OK.

[Bug target/108011] [13 Regression] gcc-13-20221204 failure to build on Cygwin: ‘uc_mcontext’ has incomplete type

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
The header file you have does:
#ifdef __x86_64__
...
#else
#error unimplemented for this target
#endif

Maybe multilib was never working before.

This cannot be a GCC bug.

Use --disable-multilib if the header files you have installed don't support
32bit.

[Bug tree-optimization/107986] [12/13 Regression] Bogus -Warray-bounds diagnostic with std::sort

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
(In reply to Richard Biener from comment #3)
> Note the old VRP was able to at least tell that qa was [0, +INF] by means of
> iterating and saturating to +INF after too many iterations.  SCEV isn't of
> help here.  Since we've lost the last lattice-based (iterating) VRP pass now
> what's the plan for cases like this?



When we first process a statement we set the LHS to varying first. Then we
resolve all the inputs, and then do the final calculation of the LHS and save
that. 

This is done to prevent resolving inputs along back edges from entering a
cycle. If the back edge ever returns to this def, it will pick up the saved
varying value and stop looking..

This is conservatively correct, but it does mean in the case of PHI nodes, we
are not optimistic about the outcome if there is a cyclic dependency. 

I intend to experiment with pre-walking any back edges to look for bounds if
there is a cycle.. ie, the range increases or decreases providing an
upper/lower limit.  I just haven't gotten to it yet.SO no iterations as
such, but a quick pattern check which may provide a bound.

in another PR (107972) I mentioned al alternative VRP which discovers things
from the bottom to the top.. Theres some possibility that pass might expose
this sort of thing too when I get to it.

[Bug target/108011] [13 Regression] gcc-13-20221204 failure to build on Cygwin: ‘uc_mcontext’ has incomplete type

[mckelvey at maskull dot com via Gcc-bugs]

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

--- Comment #4 from James McKelvey  ---
Created attachment 54037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54037=edit
signal.h

[Bug target/108011] [13 Regression] gcc-13-20221204 failure to build on Cygwin: ‘uc_mcontext’ has incomplete type

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

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

--- Comment #3 from Andrew Pinski  ---
Can you attach /usr/include/cygwin/signal.h ?

[Bug target/108011] [13 Regression] gcc-13-20221204 failure to build on Cygwin: ‘uc_mcontext’ has incomplete type

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-pc-cygwin
  Component|bootstrap   |target
   Keywords||build

--- Comment #2 from Andrew Pinski  ---
Hmm:
/usr/include/cygwin/signal.h:102:2: error: #error unimplemented for this target
  102 | #error unimplemented for this target
  |  ^

[Bug bootstrap/108011] [13 Regression] gcc-13-20221204 failure to build on Cygwin: ‘uc_mcontext’ has incomplete type

[mckelvey at maskull dot com via Gcc-bugs]

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

--- Comment #1 from James McKelvey  ---
Created attachment 54036
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54036=edit
Config log

[Bug bootstrap/108011] New: [13 Regression] gcc-13-20221204 failure to build on Cygwin: ‘uc_mcontext’ has incomplete type

[mckelvey at maskull dot com via Gcc-bugs]

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

Bug ID: 108011
   Summary: [13 Regression] gcc-13-20221204 failure to build on
Cygwin: ‘uc_mcontext’ has incomplete type
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mckelvey at maskull dot com
  Target Milestone: ---

Created attachment 54035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54035=edit
Build log with failure

This worked two snapshots ago.

/home/McKelvey/gcc-13-20221204/host-x86_64-pc-cygwin/gcc/xgcc
-B/home/McKelvey/gcc-13-20221204/host-x86_64-pc-cygwin/gcc/
-B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem
/usr/local/x86_64-pc-cygwin/include -isystem
/usr/local/x86_64-pc-cygwin/sys-include   -fno-checking -g -O2 -m32 -O2
-I../../.././libgcc/../winsup/w32api/include
-I../../.././libgcc/../winsup/include
-I../../.././libgcc/../winsup/cygwin/include -g -O2 -DIN_GCC-W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -I. -I.
-I../../../host-x86_64-pc-cygwin/gcc -I../../.././libgcc -I../../.././libgcc/.
-I../../.././libgcc/../gcc -I../../.././libgcc/../include
-I../../.././libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS
-DUSE_EMUTLS  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../.././libgcc/libgcc2.c
In file included from /usr/include/sys/signal.h:23,
 from /usr/include/signal.h:6,
 from /usr/include/time.h:158,
 from ../../.././libgcc/../gcc/tsystem.h:108,
 from ../../.././libgcc/libgcc2.c:27:
/usr/include/cygwin/signal.h:102:2: error: #error unimplemented for this target
  102 | #error unimplemented for this target
  |  ^
In file included from /usr/include/sys/signal.h:379:
/usr/include/sys/ucontext.h:17:25: error: field ‘uc_mcontext’ has incomplete
type
   17 | mcontext_t  uc_mcontext;
  | ^~~
make[5]: *** [Makefile:501: _muldi3.o] Error 1

$ uname
CYGWIN_NT-10.0-19044

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/13.0.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: ./configure --enable-languages=c,c++ --enable-threads=posix
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221118 (experimental) (GCC)

./configure --enable-languages=c,c++ --enable-threads=posix

[Bug target/108006] [13 Regression] ICE in aarch64_move_imm building 502.gcc_r

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

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

Wilco  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wilco at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 CC||wilco at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Wilco  ---
Fixed now.

[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #4 from Andrew Pinski  ---
Most likely due to r10-3311-gff6686d2e5f797 (the new IPA-SRA).

[Bug target/108006] [13 Regression] ICE in aarch64_move_imm building 502.gcc_r

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Wilco Dijkstra :

https://gcc.gnu.org/g:952c8a1dc6235dc49ab207a7f18f63d2bc97fbc9

commit r13-4538-g952c8a1dc6235dc49ab207a7f18f63d2bc97fbc9
Author: Wilco Dijkstra 
Date:   Wed Dec 7 14:16:24 2022 +

AArch64: Fix assert in aarch64_move_imm [PR108006]

Ensure we only pass SI/DImode which fixes the assert.

gcc/
PR target/108006
* config/aarch64/aarch64.cc (aarch64_expand_sve_const_vector):
Fix call to aarch64_move_imm to use SI/DI.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #11 from Andrew Macleod  ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
> > 
> > Note, I've just committed the PR107879 fix, but that one is for the reverse
> > operations.
> > And, we have still unresolved the PR107608 which on the other side could
> > very well be related or the cause of this.
> > BTW, Aldy, is there a way to disable all range related optimizations through
> > some command line option?  In the past, -fno-tree-vrp would do the trick,
> > but now that the ranger is used in lots of passes, I don't know what else to
> > use.
> 
> Not really, as ranger clients are spread around various passes.  
> 
> I think you could return false from irange::supports_p() and
> frange::supports_p() and that would block everyone using ranger.  It would
> certainly stop range_of_expr and range_of_edge, which are the main
> workhorses.



yes, we could add some form of disable.. wmaybe add something like

--param=ranger-disable=[all|float|int|gori]
all - disables all ranger queries (ie, they return false)
float - removes support for folating point
int - removes support for integrals
gori - removes support for op1/op2 backwiding

I think we could do something like that if it was useful?  It would apply
across the board to any and all uses of ranger in all passes

We could also add a ranger dbgcnt counter too,which would we could trigger in
one or more of the routines...?

[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-07
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|wrong code at -Os and above |[10/11/12/13 Regression]
   |with "-fno-dce  |wrong code at -Os and above
   |-fno-tree-dce" on   |with "-fno-dce
   |x86_64-linux-gnu|-fno-tree-dce" on
   ||x86_64-linux-gnu
  Known to fail||10.1.0, 11.1.0, 12.2.0
   Target Milestone|--- |10.5
 CC||marxin at gcc dot gnu.org
Version|unknown |13.0
  Component|tree-optimization   |ipa
  Known to work||9.1.0

--- Comment #2 from Andrew Pinski  ---
== IPA-SRA decisions ==

Evaluating analysis results for i/8
  Will remove return value.
  Created new node i.isra/12

[Bug tree-optimization/108007] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---
#(insn:TI 36 66 40 8 (set (reg:CCGC 17 flags)
#(compare:CCGC (mem:SI (const_int 0 [0]) [1 *removed_return.17_12(D)+0
S4 A32])
#(reg:SI 1 dx [orig:83 b.0_5 ] [83]))) "/app/example.cpp":20:13 11
{*cmpsi_1}
# (expr_list:REG_UNUSED (reg:CCGC 17 flags)
#(nil)))
cmpl%edx, 0 # 36  [c=8 l=7]  *cmpsi_1/0

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #16 from Aaron Ballman  ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Aaron Ballman from comment #14)
> > Also, it was a potentially silently breaking change (if you don't mind
> > horribly contrived examples of breakage): https://godbolt.org/z/T4bG6179f
> 
> But __COUNTER__ is not part of the standard 

The code changed meaning regardless and WG14 usually goes out of our way to
avoid changing the meaning of existing, conforming code. (FWIW, I'll freely
admit this example is not compelling; it's just intended as a demonstration
that I don't think WG14 fully thought through the ramifications of what
prohibiting token expansion does in practice.)

[Bug fortran/108010] New: ICE in reduce_unary, at fortran/arith.cc:1345

[gscfq--- via Gcc-bugs]

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

Bug ID: 108010
   Summary: ICE in reduce_unary, at fortran/arith.cc:1345
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   print *, -[real :: [real ::], 2]
end


$ cat z2.f90
program p
   print *, +[integer :: [real ::], 2]
   print *, -[integer :: [real ::], 2]
   print *, 1 + [integer :: [real ::], 2]
   print *, 1 - [integer :: [real ::], 2]
   print *, 2 * [integer :: [real ::], 2]
   print *, +[integer :: [real ::]]
   print *, -[integer :: [real ::]]
   print *, 1 + [integer :: [real ::]]
   print *, 1 - [integer :: [real ::]]
   print *, 2 * [integer :: [real ::]]
end


$ cat z3.f90
program p
   print *, [integer :: [real ::]] + [integer :: [real ::]]
   print *, [integer :: [real ::]] - [integer :: [real ::]]
   print *, [integer :: [real ::]] * [integer :: [real ::]]
   print *, [integer :: [real ::], 2] + [real :: [real ::], 3]
   print *, [integer :: [real ::], 2] - [real :: [real ::], 3]
   print *, [integer :: [real ::], 2] * [real :: [real ::], 3]
end


$ cat z0.f90
program p
   print *, [integer :: [integer ::], 2]
   print *, [real :: [real ::], 2]
end


$ gfortran-13-20221204 z0.f90 && ./a.out
   2
   2.


$ gfortran-13-20221204 -c z1.f90
f951: internal compiler error: Segmentation fault
0xf488bf crash_signal
../../gcc/toplev.cc:314
0x7d7ebd reduce_unary
../../gcc/fortran/arith.cc:1345
0x7d7e91 reduce_unary
../../gcc/fortran/arith.cc:1332
0x7d8638 eval_intrinsic
../../gcc/fortran/arith.cc:1706
0x84baa4 match_level_2
../../gcc/fortran/matchexp.cc:490
0x84bac2 match_level_3
../../gcc/fortran/matchexp.cc:551
0x84bbb4 match_level_4
../../gcc/fortran/matchexp.cc:599
0x84bbb4 match_and_operand
../../gcc/fortran/matchexp.cc:693
0x84bda2 match_or_operand
../../gcc/fortran/matchexp.cc:722
0x84be72 match_equiv_operand
../../gcc/fortran/matchexp.cc:765
0x84bf44 match_level_5
../../gcc/fortran/matchexp.cc:811
0x84b311 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.cc:870
0x832a09 match_io_element
../../gcc/fortran/io.cc:3668
0x83533a match_io_list
../../gcc/fortran/io.cc:3716
0x83573e match_io
../../gcc/fortran/io.cc:4394
0x83923a gfc_match_print()
../../gcc/fortran/io.cc:4450
0x86b501 match_word
../../gcc/fortran/parse.cc:67
0x871163 decode_statement
../../gcc/fortran/parse.cc:539
0x87159a next_free
../../gcc/fortran/parse.cc:1403
0x87159a next_statement
../../gcc/fortran/parse.cc:1635

[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[mckelvey at maskull dot com via Gcc-bugs]

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

--- Comment #5 from James McKelvey  ---
This works:

$ diff gcc/config/i386/t-cygwin-w64~ gcc/config/i386/t-cygwin-w64
2c2
< MULTILIB_DIRNAMES = 64
---
> MULTILIB_DIRNAMES = 64 32

[Bug c++/101098] [11/12 Regression] ICE with explicit specialization of constrained function template

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||StevenSun2021 at hotmail dot 
com

--- Comment #6 from Patrick Palka  ---
*** Bug 99686 has been marked as a duplicate of this bug. ***

[Bug c++/99686] ICE when using concepts on function template before c++20 (Reason already found)

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
 CC||ppalka at gcc dot gnu.org

--- Comment #9 from Patrick Palka  ---
Fixed by r12-2230

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

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Aaron Ballman from comment #14)
> Also, it was a potentially silently breaking change (if you don't mind
> horribly contrived examples of breakage): https://godbolt.org/z/T4bG6179f

But __COUNTER__ is not part of the standard 

[Bug tree-optimization/107972] backward propagation of finite property not performed

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
Its because we don't go back and re-propagate into previous basic block.  Take
an integral vexample:

unsigned 
foo (unsigned a, unsigned b)
{
  unsigned res = a + b;
  if (res > 100)
return 42
  if (a > 30 || b > 30)
__builtin_unreachable ();
  if (res > 100)
return 42
  return res;

The branch which restricts the range of a and b to [0,30] causes GORI to
recompute "res = a + b" on each edge, so those values are pushed along any
outgoing edges, and when we see res > 100 the second time we fold that away.

Thats all handled buy GORI which is basic-block oriented only.  At no point
(yet anyway) do we attempt to push these values back further in the CFG, so
therefore we don't touch the conditions that were encountered earlier, and
cannot eliminate the earlier compare and return.  

I have contemplated a new kind of VRP analysis pass which leverages what we did
with 'assume', propagates known values backwards and looks for opportunities
earlier in the CFG that are exposed by information determined later in the IL. 
 This sort of thing would probably require such a pass.

[Bug target/87832] AMD pipeline models are very costly size-wise

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

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

--- Comment #11 from Alexander Monakov  ---
Factoring out Lujiazui divider shrinks its tables by almost 20x:

3 r lujiazui_decoder_min_issue_delay
20 r lujiazui_decoder_transitions
32 r lujiazui_agu_min_issue_delay
126 r lujiazui_agu_transitions
304 r lujiazui_div_base
352 r lujiazui_div_check
352 r lujiazui_div_transitions
1152 r lujiazui_core_min_issue_delay
1592 r lujiazui_agu_translate
1592 r lujiazui_core_translate
1592 r lujiazui_decoder_translate
1592 r lujiazui_div_translate
3952 r lujiazui_div_min_issue_delay
9216 r lujiazui_core_transitions

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #14 from Aaron Ballman  ---
(In reply to jos...@codesourcery.com from comment #12)
> The standard rule about not using extra arguments means that any warnings 
> would need to avoid even converting those arguments from pp-tokens to 
> tokens; it's OK for them to contain pp-tokens that cannot be converted to 
> tokens.

Agreed, that's why I filed an NB comment to remove the restriction that the
arguments can't be expanded. Hopefully WG14 will relax that so we can give good
diagnostic behavior.

> I think the accepted change to the standard was entirely clear about 
> ignoring the extra arguments; it wasn't some obscure non-obvious 
> consequence that such code would become valid.

It was not discussed in the paper, or the meeting minutes, or my personal
notes. I may have missed something, but I have no reason to believe WG14
explicitly considered the ramifications of this. Also, I cannot find another
instance where a function-like macro accepts arguments that it is not allowed
to *expand*; that's a novel WG14 invention.

Also, it was a potentially silently breaking change (if you don't mind horribly
contrived examples of breakage): https://godbolt.org/z/T4bG6179f

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

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

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

--- Comment #13 from Jakub Jelinek  ---
Warning for 3 or more arguments using preprocessor stuff only could look like:
#define __va_start_2()
#define __va_start_23(...) __builtin_warning ("too many va_arg arguments");
#define __va_start_1()
#define __va_start_12(v, ...) __va_start_2##__VA_OPT__(3) (__VA_ARGS__)
#define va_start(v, ...) __va_start_1##__VA_OPT__(2) (__VA_ARGS__)
__builtin_va_start (v, 0)
We are C2X here, so we can rely on __VA_OPT__.
As for warning when there are 2 arguments and second argument is not identifier
for the last argument, in the light of #c12 that would be fairly difficult.  In
the preprocessor it is going to be pretty hard to find out whether in the 2
arguments case the second one is a single identifier token, and on the compiler
side __builtin_va_start or __builtin_va_start_c23 would need to be a keyword
with its own parsing which would parse
normally as expression the first argument, but for the rest just warn if it is
more than 2 arguments or second argument is present and is not identifier of
the last argument, but otherwise ignore the tokens.  Still, isn't say:
#define A (
#define B )
va_start (ap, A B B );
va_start (ap, A A A );
valid in C2X?  That ruins both the argument counting and especially any
attempts to decide something after preprocessing.

[Bug c++/108008] Compiler mis-optimization with posix_memalign

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
-fno-split-loops "cures" it (of course it might just be an enabling transform
for an incorrect optimization later on)

Bisecting trunk for which commit fixes/hides it may be useful.

[Bug target/108009] New: GCC does not produce Pack Halfword instructions

[chris.sidebottom at arm dot com via Gcc-bugs]

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

Bug ID: 108009
   Summary: GCC does not produce Pack Halfword instructions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chris.sidebottom at arm dot com
  Target Milestone: ---

I've been trying to remove a dependency on CMSIS intrinsics
(https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/cmsis_gcc.h),
following https://arm-software.github.io/acle/main/acle.html, I should be able
to generate a halfword packing instructions
(https://developer.arm.com/documentation/dui0489/h/arm-and-thumb-instructions/pkhbt-and-pkhtb)
using C, such as:

  int pack(int x, int y) {
  return ((x & 0xu) << 16) | (y & 0xu);
  }

However, `gcc -mcpu=cortex-m4 -O3` results in two instructions rather than the
single halfword packing instruction.

[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.

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

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 54034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54034=edit
gcc13-pr107627-imm.patch

Untested patch to improve the case where one of the concat operand is constant.

[Bug c++/108008] New: Compiler mis-optimization with posix_memalign

[hahnjo at hahnjo dot de via Gcc-bugs]

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

Bug ID: 108008
   Summary: Compiler mis-optimization with posix_memalign
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hahnjo at hahnjo dot de
  Target Milestone: ---

Created attachment 54033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54033=edit
init.cpp

Consider the attached example, reduced from some real code, and also available
on Compiler Explorer: https://godbolt.org/z/x4Gsjo7rT

The expectation is that sameZ[i] = true if zPlanes[i] == zPlanes[i + 1] which
should be the case for i = 1. However, when compiling the code with GCC 11.2.0
or 12.2.0 and -std=c++17 -O3, the output is sameZ = 0 for all three iterations
of the second loop. The problem disappears when changing anything in the
slightest manner: compiling with -O2, using -std=gnu++17, using a different
allocation function, commenting out one of the other two statements in the
first loop, using the unconditional assignment to sameZ[i], or removing the
exit(1).

Could this be a bug in the optimizer?

[Bug tree-optimization/106904] [12/13 Regression] Incorrect -Wstringop-overflow with partial memcpy() into a nested structure

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-12-07
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #5 from Richard Biener  ---
Note we diagnose

MEM  [(char * {ref-all})vectp.4_10] = MEM 
[(char * {ref-all})];

where vectp.4_10 == _5(D)->mp.hwnd;

that happens because SLP vectorization produces

  vectp.4_10 = _5(D)->wp.hwnd;
  vect__1.5_11 = MEM[(int *)vectp.4_10];
  vectp.4_12 = vectp.4_10 + 4;
  vectp.4_14 = vectp.4_10 + 8;
  vect__1.7_15 = MEM[(int *)vectp.4_14];

and we then CSE the memcpy address in the following code to vectp.4_10:

  _3 = _5(D)->wp;
  __builtin_memcpy (_3, , 8);

the access diagnostics have the issue that they mis-interpret addresses
as more than just pointer arithmetic.  Eventually part of this could be
avoided by not introducing any non-invariant ADDR_EXPRs at least but
use POINTER_PLUS_EXPR where possible (like in the above case).  Alternatively
we could strip zero-offset components at these points.

[Bug tree-optimization/108007] New: wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108007
   Summary: wrong code at -Os and above with "-fno-dce
-fno-tree-dce" on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/51r5Kqr9q

It appears to be a regression from 9.*, and affects 10.* till trunk. 

[599] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221207 (experimental) [master r13-4532-gda7fb32d403] (GCC) 
[600] % 
[600] % gcctk -Os -fno-dce -fno-tree-dce small.c
[601] % ./a.out
Segmentation fault
[602] % 
[602] % cat small.c
int a, b, d, e, f = 1000, h;
short c, g;
static int *i() {
  g = f;
 L:
  h = e = ~g;
  g = ~f % g & e;
  if (!g)
goto L;
  c++;
  while (g < 1)
;
  return 
}
static void k() {
  int *l, m = 2;
  l = i();
  for (; d < 1; d++)
m |= *l >= b;
}
int main() {
  k();
  return 0;
}

[Bug d/104749] [12/13 regression] stage1 d21 fails to link with GDC 9.1

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

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

Thomas Schwinge  changed:

   What|Removed |Added

Summary|[12/13 regression] stage1   |[12/13 regression] stage1
   |d21 fails to link on|d21 fails to link with GDC
   |Solaris/x86 |9.1

--- Comment #12 from Thomas Schwinge  ---
(In reply to Iain Buclaw from comment #6)
> Just having a look around, I couldn't see anywhere that `___s` would be
> created now.
> 
> Then I came across r9-8460, which was fixed for 10.1.0, and backported
> before 9.4.0 was released.  Linked bug report is pr d/94240.
> 
> In that case then, earlier versions of version 9 might not work correctly.

I have, by the way, confirmed that cherry-picking commit
r9-8460-ge926d076f28a91f3ea30bd0bcfa1f25958fdb59e "d: Fix ICE in
add_symbol_to_partition_1, at lto/lto-partition.c:215" on top of GCC 9.1 does
resolve the issue discussed here (for x86_64-pc-linux-gnu).

... but for 'gcc/doc/install.texi' we'd rather state "GDC compiler (GCC version
9.4 or later)", I suppose.

[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #8 from 康桓瑋  ---
(In reply to Jonathan Wakely from comment #4)
> Maybe you could legally do:
> 
> using difference_type = iterator_t>;
> 
> but maybe just don't do that. If things break when you do dumb things, don't
> do those things.

A more uncontrived example would be:

  std::vector v(10);
  auto r = std::views::iota((unsigned __int128)0) | 
std::views::transform([&](auto i) -> auto& { return v[i]; });
  auto s = std::format_to_n(r.begin(), 5, "{}", "");

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

Richard Biener  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2022-Decembe
   ||r/608077.html

--- Comment #24 from Richard Biener  ---
Here's a patch doing that (ADDR_NONZERO) which fixes the issue.

[Bug ipa/105676] [12 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))` since r12-5437-g09a4ffb72aa2f513

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13 Regression] Bogus|[12 Regression] Bogus
   |`-Wsuggest-attribute=pure`  |`-Wsuggest-attribute=pure`
   |on function marked  |on function marked
   |`__attribute__((const))`|`__attribute__((const))`
   |since   |since
   |r12-5437-g09a4ffb72aa2f513  |r12-5437-g09a4ffb72aa2f513
  Known to work||13.0
  Known to fail|12.1.0  |12.2.0

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.

[Bug ipa/105676] [12/13 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))` since r12-5437-g09a4ffb72aa2f513

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

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

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

https://gcc.gnu.org/g:45e09c2eb9c2bdd34ef777e06ddc9908dd0664f9

commit r13-4535-g45e09c2eb9c2bdd34ef777e06ddc9908dd0664f9
Author: Richard Biener 
Date:   Wed Dec 7 10:26:01 2022 +0100

ipa/105676 - pure attribute suggestion for const function

When a function is declared const (even though it technically
accesses memory), ipa-modref discovering pureness shouldn't end
up suggesting that attribute.  The following thus exempts
'const' functions from ipa_make_function_pure handling.

PR ipa/105676
* ipa-pure-const.cc (ipa_make_function_pure): Skip also
for functions already being const.

* gcc.dg/pr105676.c: New testcase.

[Bug target/108006] [13 Regression] ICE in aarch64_move_imm building 502.gcc_r

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Wilco, is this something you've touched recently?

[Bug target/108006] New: [13 Regression] ICE in aarch64_move_imm building 502.gcc_r

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

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

Bug ID: 108006
   Summary: [13 Regression] ICE in aarch64_move_imm building
502.gcc_r
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

Building 502.gcc_r from SPEC2017 with -O2 -mcpu=neoverse-v1 ICEs with trunk.
Reduced testcase:

void c();

short *foo;
short *bar;
void
a() {
  for (bar; bar < foo; bar++)
*bar = 999;
  c();
}

backtrace is:
during RTL pass: expand
ice.c: In function a:
ice.c:8:10: internal compiler error: in aarch64_move_imm, at
config/aarch64/aarch64.cc:5692
8 | *bar = 999;
  | ~^
0x129db4c aarch64_move_imm(unsigned long, machine_mode)
$SRC/gcc/config/aarch64/aarch64.cc:5692
0x12c01cd aarch64_expand_sve_const_vector
$SRC/gcc/config/aarch64/aarch64.cc:6516
0x12c63cb aarch64_expand_mov_immediate(rtx_def*, rtx_def*)
$SRC/gcc/config/aarch64/aarch64.cc:6996
0x18c3248 gen_movvnx8hi(rtx_def*, rtx_def*)
$SRC/gcc/config/aarch64/aarch64-sve.md:662
0xa09062 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
$SRC/gcc/recog.h:407
0xa09062 emit_move_insn_1(rtx_def*, rtx_def*)
$SRC/gcc/expr.cc:4172
0xa095bb emit_move_insn(rtx_def*, rtx_def*)
$SRC/gcc/expr.cc:4342
0x9db8aa copy_to_mode_reg(machine_mode, rtx_def*)
$SRC/gcc/explow.cc:654
0xd0607d maybe_legitimize_operand
$SRC/gcc/optabs.cc:7809
0xd0607d maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
$SRC/gcc/optabs.cc:7941
0xd06366 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
$SRC/gcc/optabs.cc:7960
0xd06592 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
$SRC/gcc/optabs.cc:8005
0xd05b17 expand_insn(insn_code, unsigned int, expand_operand*)
$SRC/gcc/optabs.cc:8036
0xb53fb7 expand_partial_store_optab_fn
$SRC/gcc/internal-fn.cc:2878
0xb54307 expand_MASK_STORE
$SRC/gcc/internal-fn.def:141
0xb59960 expand_internal_call(internal_fn, gcall*)
$SRC/gcc/internal-fn.cc:4436
0xb5997a expand_internal_call(gcall*)
$SRC/gcc/internal-fn.cc:
0x8b6161 expand_call_stmt
$SRC/gcc/cfgexpand.cc:2737
0x8b6161 expand_gimple_stmt_1

[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression

[alvinhochun at gmail dot com via Gcc-bugs]

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

Alvin Wong  changed:

   What|Removed |Added

 CC||alvinhochun at gmail dot com

--- Comment #6 from Alvin Wong  ---
Still a problem with 12.2 / trunk using GNU attributes:


$ <: In lambda function:
:2:47: error: expected '{' before 'noexcept'
: In function 'auto a()':
:2:46: error: expected ';' before 'noexcept'
:2:56: error: expected '(' before '{' token
:2:56: error: expected primary-expression before '{' token
:2:55: error: expected ')' before '{' token


https://godbolt.org/z/xMrb4Pqsj

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

--- Comment #23 from Richard Biener  ---
Interestingly doing

void QFutureInterfaceBase::setThrottled(bool enable)
{   
if (>m_mutex == nullptr)
  __builtin_unreachable ();
QMutexLocker lock(>m_mutex);

will avoid the diagnostic but instead complains

qfutureinterface.cpp:67:21:warning: the address of
'QFutureInterfaceBasePrivate::m_mutex' will never be NULL [-Waddress]

(that's without the re-ordering).  So the C++ frontend already knows this
but doesn't transfer it to the middle-end.  Maybe we want something
like ADDR_EXPR_NONZERO on the built ADDR_EXPR?

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

--- Comment #22 from Richard Biener  ---
Re-ordering m_mutex and continuationMutex avoids the bogus diagnostic.

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

--- Comment #21 from Richard Biener  ---
When the C++ frontend sees

QMutexLocker lock(>m_mutex);

it could hint the middle-end via emitting

[[assume (>m_mutex != nullptr)]]
QMutexLocker lock(>m_mutex);

instead.

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #20 from Richard Biener  ---
(In reply to Thiago Macieira from comment #19)
> (In reply to Richard Biener from comment #15)
> > Thanks, it's still the same reason - we isolate a nullptr case and end up
> > with
> > 
> > __atomic_or_fetch_4 (184B, 64, 0); [tail call]
> > 
> > The path we isolate is d->m_mutex == nullptr && !enable in
> > 
> > void QFutureInterfaceBase::setThrottled(bool enable)
> > {
> > QMutexLocker lock(>m_mutex);
> 
> Thank you for the analysis, Richard. But do note that it's >m_mutex, not
> d->m_mutex that is passed to the locker. C++ says that if you do d-> then d
> != nullptr, so >m_mutex can't be nullptr either.

Hmm, I see

 [local count: 1073741824]:
_1 = this_10(D)->d;
_2 = &_1->m_mutex;
MEM[(struct __as_base  &)] ={v} {CLOBBER};
if (_2 != 0B)

so we load the pointer 'this_10(D)->d' and then indeed check >m_mutex
for being NULL.

The middle-end long allowed >x for the sake of legacy code
implementing offsetof by pointer arithmetic on an object at NULL.

Given

struct X { int a; int b ; };
int foo (struct X *x)
{
  return >a != (int *)0;
}

we do indeed not simplify this.  Doing >b != (int *)0 shows even that
is only simplified by recent code in Ranger (via DOM at -O1 or VRP at -O2).
That's also true for the

struct X { int a; int b ; };
int foo (struct X *x)
{
  int *p = (int *)x + 1;
  return p != (int *)0;
}

variant.  Special-casing this in the language frontends probably won't
fix the testcase since the use in a nullptr comparison is hidden
via a function call of the CTOR:

QMutexLocker lock(>m_mutex);

and as you say m_mutex is at offset zero.

Since consider pointer overflow undefined we should be able to optimize
>b != nullptr in the middle-end earlier and more consistently.  The
offset zero case is harder since we consider >b as just pointer
arithmetic and x + 0 != nullptr cannot be optimized I think.

[Bug ipa/105676] [12/13 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))` since r12-5437-g09a4ffb72aa2f513

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
It's ipa-modref detecting getval as pure and calling ipa_make_function_pure
which emits the diagnostic.  I have a patch excluding functions already const
from this.

[Bug testsuite/108005] FAIL: c-c++-common/asan/null-deref-1.c /pointer-compare-1.c output pattern test

[zhangkefan at ultrarisc dot com via Gcc-bugs]

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

--- Comment #1 from zhangkefan at ultrarisc dot com  ---
my execution test  all  pass

[Bug testsuite/108005] New: FAIL: c-c++-common/asan/null-deref-1.c /pointer-compare-1.c output pattern test

[zhangkefan at ultrarisc dot com via Gcc-bugs]

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

Bug ID: 108005
   Summary: FAIL: c-c++-common/asan/null-deref-1.c
/pointer-compare-1.c  output pattern test
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhangkefan at ultrarisc dot com
  Target Milestone: ---

##When I make  check-gcc RUNTESTFLAGS=asan.exp 
FAIL: c-c++-common/asan/null-deref-1.c   -O0  output pattern test
FAIL: c-c++-common/asan/null-deref-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/null-deref-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/null-deref-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/null-deref-1.c   -Os  output pattern test
FAIL: c-c++-common/asan/null-deref-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/null-deref-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/asan/pointer-compare-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/pointer-compare-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/pointer-compare-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/pointer-compare-1.c   -Os  output pattern test 
 ##all of them are output pattern error and I run this on riscv

Output was:
AddressSanitizer:DEADLYSIGNAL
=
==3347640==ERROR: AddressSanitizer: SEGV on unknown address 0x0028 (pc
0x00010764 bp 0x003fffeff610 sp 0x003fffeff5f0 T0)
==3347640==The signal is caused by a READ memory access.
==3347640==Hint: address points to the zero page.
#0 0x10764 in NullDeref c-c++-common/asan/null-deref-1.c:10

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV c-c++-common/asan/null-deref-1.c:10 in
NullDeref
==3347640==ABORTING

Should match:
ERROR: AddressSanitizer:? SEGV on unknown address[^
^M]*0x[0-9a-f]+ [^
^M]*pc 0x[0-9a-f]+.*(
|^M
|^M)#0 0x[0-9a-f]+ +(in [^
^M]*NullDeref[^
^M]* ([^
^M]*null-deref-1.c:10|[^
^M]*:0|[^
^M]*\+0x[0-9a-z]*)|[(])[^
^M]*(
|^M
|^M)#1 0x[0-9a-f]+ +(in _*main ([^
^M]*null-deref-1.c:15|[^
^M]*:0|[^
^M]*\+0x[0-9a-z]*)|[(])
`

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

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

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

--- Comment #55 from CVS Commits  ---
The master branch has been updated by Hongyu Wang :

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

commit r13-4534-g3a1a141f79c83ad38f7db3a21d8a4dcfe625c176
Author: Hongyu Wang 
Date:   Tue Dec 6 09:53:35 2022 +0800

i386: Avoid fma_chain for -march=alderlake and sapphirerapids.

For Alderlake there is similar issue like PR 81616, enable
avoid_fma256_chain will also benefit on Intel latest platforms
Alderlake and Sapphire Rapids.

gcc/ChangeLog:

* config/i386/x86-tune.def (X86_TUNE_AVOID_256FMA_CHAINS): Add
m_SAPPHIRERAPIDS, m_ALDERLAKE and m_CORE_ATOM.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

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

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

--- Comment #4 from HaoChen Gui  ---
$cat asm_test.c
#include 

unsigned long foo() {
  unsigned long res;
  __asm__ ("li 3,0x\n\t"
   "li 4,0xfff1\n\t"
   "and. 3,3,4\n\t"
   "mfcr %0"
   : "=r" (res));
  return res;
}

void
main()
{
  printf ("%lx\n", foo());
}
$ gcc -O1 -o asm_test asm_test.c && ./asm_test
82000482

Use the assembly to test the "and.". The bit32 (cr0 LT bit) is set when the
result is less than 0.