[Bug ipa/111672] Inappropriate function splitting during pass_split_functions

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Add -save-temps and attach the resulting .i (or .ii) file.

This is documented at https://gcc.gnu.org/bugs/ under the section of `What we
need `.

[Bug ipa/111672] Inappropriate function splitting during pass_split_functions

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

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

--- Comment #5 from Andrew Pinski  ---
Add -save-temps and attach the resulting .i (or .ii) file.

[Bug c/111689] Unexpected comparison result of signed long long literal with zero

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

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

--- Comment #3 from Andrew Pinski  ---
Note C99 has the same table:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf


C++11 has the same table too:
https://timsong-cpp.github.io/cppwp/n3337/lex.icon

[Bug c/111689] Unexpected comparison result of signed long long literal with zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Because this is exactly what the C standard says it should be.


See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 6.4.4.1/5 .

For hex (and Octal) constants, if the value is not representable in `signed
long long` (which it is not as it is too big) but representable as `unsigned
long long` then unsigned long long is chosen for LL.
For Decimals, it is just signed.

[Bug c/111689] Unexpected comparison result of signed long long literal with zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|translation |c

--- Comment #1 from Andrew Pinski  ---
>Interestingly, the cl compiler correctly interprets ULL as unsigned and LL as 
>signed for the given literal.


clang produces the same result as GCC here.
MSVC does not though.

[Bug translation/111689] New: Unexpected comparison result of signed long long literal with zero

[guminb at ajou dot ac.kr via Gcc-bugs]

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

Bug ID: 111689
   Summary: Unexpected comparison result of signed long long
literal with zero
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guminb at ajou dot ac.kr
  Target Milestone: ---

I've come across an unexpected behavior when performing a comparison between
the value `0` and the signed long long literal `0x8F3700142F89C2A5LL`.

#include
#include

int main (int argc, char* argv[])
{   
long long zero = 0;
printf("Comparison result of zero <= signed long long 0x8F3700142F89C2A5LL:
%d\n", (zero <= 0x8F3700142F89C2A5LL));
return 0;
}

The binary representation of 0x8F3700142F89C2A5LL is:
1000001101110001011010001001111010100101

This corresponds to the decimal value -8127026915869867355, indicating that it
is unambiguously a negative number.

Considering that 0x8F3700142F89C2A5LL is meant to be interpreted as a signed
long long and represents a negative value, the expected result for (zero <=
0x8F3700142F89C2A5LL) should be 0. However, the actual result is 1 across
several compilers including gcc and clang.

Interestingly, the cl compiler correctly interprets ULL as unsigned and LL as
signed for the given literal.

It appears that the compiler is not treating the literal 0x8F3700142F89C2A5LL
as a signed long long as it should, which results in this discrepancy.

I'm seeking understanding or clarification regarding this behavior. Would it be
possible for this to be a compiler bug?

[Bug bootstrap/111688] New: [14 regression] bootstrap failure after r14-4383-g14d0c509898b03

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

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

Bug ID: 111688
   Summary: [14 regression] bootstrap failure after
r14-4383-g14d0c509898b03
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:14d0c509898b0361f78284c05556035edde6d1e0, r14-4383-g14d0c509898b03

make
. . .
Comparing stages 2 and 3
Bootstrap comparison failure!
powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/compatibility-ldbl.o
differs
powerpc64le-unknown-linux-gnu/libstdc++-v3/src/compatibility-ldbl.o differs


commit 14d0c509898b0361f78284c05556035edde6d1e0 (HEAD)
Author: Martin Jambor 
Date:   Tue Oct 3 18:44:52 2023 +0200

ipa-sra: Allow IPA-SRA in presence of returns which will be removed

[Bug ipa/111672] Inappropriate function splitting during pass_split_functions

[hkzhang455 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hanke Zhang  ---
(In reply to Andrew Pinski from comment #3)
> Oh I see the compiler you are testing with defaults with fortify turned on.
> That is the difference.
> Maybe also with pie turned on by default tlalso.
> 
> Can you provide the full output of gcc -v and also the preprocessed source?

The full output of gcc -v is shown in my description where you can check. And I
known't get what the preprocessed source means here. The origin source C file
is provided already.

[Bug ipa/111672] Inappropriate function splitting during pass_split_functions

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

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

--- Comment #3 from Andrew Pinski  ---
Oh I see the compiler you are testing with defaults with fortify turned on.
That is the difference.
Maybe also with pie turned on by default tlalso.

Can you provide the full output of gcc -v and also the preprocessed source?

[Bug ipa/111672] Inappropriate function splitting during pass_split_functions

[hkzhang455 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hanke Zhang  ---
(In reply to Andrew Pinski from comment #1)
> I cannot reproduce this on the trunk (or even in 12.3.0):
> 
> Split point at BB 3
>   header time: 1393.311190 header size: 33
>   split time: 2.226400 split size: 2
>   bbs: 3
>   SSA names to pass:
>   Refused: split size is smaller than call overhead
> found articulation at bb 7
> Split point at BB 7
>   header time: 1395.537590 header size: 35
>   split time: 0.00 split size: 0
>   bbs: 7
>   SSA names to pass:
>   Refused: split size is smaller than call overhead

It's still the same bug in my place, and I'm trying to compile on another
computer, and the same happens. Note that, my host is x86_64-linux-gnu. Here is
part of my output infomation about function splitting optimization.

  gcc -O3 -flto -fdumo-tree-fnsplit test.c
  cat a-test.c.050t.fnsplit

;; Function printf (printf, funcdef_no=15, decl_uid=964, cgraph_uid=16,
symbol_order=15)

Not splitting: disregarding inline limits.
__attribute__((artificial, gnu_inline, always_inline))
__attribute__((nonnull (1), format (printf, 1, 2)))
int printf (const char * restrict __fmt)
{
  int _4;

   [local count: 1073741824]:
  _4 = __printf_chk (1, __fmt_2(D), __builtin_va_arg_pack ());
  return _4;

}



;; Function test_split_write (test_split_write, funcdef_no=39, decl_uid=3184,
cgraph_uid=40, symbol_order=43)



Splitting function at:
Split point at BB 3
  header time: 1393.311190 header size: 33
  split time: 2.428800 split size: 3
  bbs: 3
  SSA names to pass:
;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1
Introduced new external node (puts/53).

Symbols to be put in SSA form
{ D.3222 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 5
Number of blocks to update: 4 ( 80%)


;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 4 2 3
;; 4 succs { 2 }
;; 2 succs { 3 }
;; 3 succs { 1 }
int test_split_write.part.0 ()

[Bug middle-end/111669] bogus -Wnonnull in conditionally executed code

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

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

--- Comment #2 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #1)
> The warning given for the reduced test case is correct because it does not
> make sense.  It should be just rewritten as

I mean, the code does not make sense.

And the warning is given exactly because GCC is optimizing the strcpy call to
unreachable.

[Bug middle-end/111669] bogus -Wnonnull in conditionally executed code

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
The warning given for the reduced test case is correct because it does not make
sense.  It should be just rewritten as

int GetSystemDirectory16(char *path, int count)
{
if (GetWindowsDirectoryA())
__builtin_unreachable();

return 0;
}

because in the case if GetWindowsDirectoryA() returns non-zero, the code always
invoke undefined behavior.

I'm not sure about the original file.c, but AFAIK GCC developers are keeping to
say "hey, don't use -Werror".

[Bug libstdc++/111685] Segfault while sorting on array element address

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #7 from Xi Ruoyao  ---
[alg.sorting] p3:

For algorithms other than those described in 28.7.3, comp shall
induce a strict weak ordering on the values.

Note the terminology "values".  I cannot find the definition of "value" in the
standard, but I'm pretty sure the "values" must be independent to "their
addresses" or the entire standard would become completely unreasonable (note
that rvalues has no addresses at all).

[Bug c/82967] "did you mean" suggestions are way too suggestive

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |9.0
 Status|ASSIGNED|RESOLVED
 CC||xry111 at gcc dot gnu.org

--- Comment #15 from Xi Ruoyao  ---
Closing as gcc-8 branch is closed for years.

[Bug debug/111680] DWARF information inconsistent with the generated RISC-V Binary

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to King Lok Chung from comment #8)
> It also looks like to me that the compiler is trying to be smart and save
> one register use by reusing the SP, resulting in two SP offsets. In reality,
> it could have used a6 or a7 easily.

Kinda of, the issue is `addisp,sp,` has a limit for its immediate for the
add (you can't just add -2080 to sp).
So the backend decides to 2 `addi` and that confuses the rest of the
middle-end.


Note other backends do is rather:
Create the immediate in a register and then does the add to the sp to get the
increment.
That is how MIPS, AARCH64, rs6000, etc. implement the big stack increments and
does not confuse the rest of the GCC.

Anyways this should be fixed either by changing the riscv backend or fixing the
dwarf2 pass to do the correct thing (or maybe both).

[Bug debug/111680] DWARF information inconsistent with the generated RISC-V Binary

[king.chung at manchester dot ac.uk via Gcc-bugs]

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

--- Comment #8 from King Lok Chung  ---
It also looks like to me that the compiler is trying to be smart and save one
register use by reusing the SP, resulting in two SP offsets. In reality, it
could have used a6 or a7 easily.

Or might be the SP value is similar to the pointer address, which the compiler
trying take advantage of? This is just pure guessing.

[Bug c++/111681] better error message for unknown type in catch

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|Missing fixit for exception |better error message for
   |name in catch   |unknown type in catch
   Severity|normal  |enhancement
   Last reconfirmed||2023-10-03
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
confirmed.

Even:
```
namespace tt{}
int main()
{
try
{}
catch(const tt::& e)
{}
}
```

Should give a better error message where  is an unknown type in `namespace
tt`.

[Bug tree-optimization/111389] [14 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||19373742 at buaa dot edu.cn

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

[Bug tree-optimization/111678] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 111389.

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

[Bug target/111677] arm64 build fails unrecognizable insn [REGRESSION]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
Since debian backported patches and not using the 13 branch, this is a bug in
debian sources only.

Anyways it was introduced by:
Address stack protector and stack clash protection weaknesses
   on AArch64

You need r13-7827-g4bb1ae3c13ce4fb72129229de66f5ffbcd45fe4c (PR 111411) also.

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||7.1.0
   Keywords||needs-bisection,
   ||needs-reduction
   Last reconfirmed||2023-10-03
   Target Milestone|--- |11.5
Summary|Incorrect answer when using |[11/12/13/14 Regression]
   |SSE2 intrinsics with -O3|Incorrect answer when using
   ||SSE2 intrinsics with -O3
 Status|UNCONFIRMED |NEW
  Known to work||6.1.0, 6.4.0

--- Comment #1 from Andrew Pinski  ---
Confirmed. Started between GCC 6 and GCC 7. Looks unrolling related too.

[Bug debug/111680] DWARF information inconsistent with the generated RISC-V Binary

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

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

--- Comment #7 from Andrew Pinski  ---
Note I think most other targets create the stack offset in a register and then
do the add to the sp rather than having 2 add to sp which might be the reason
why this has not been seen until now too ...

[Bug target/111680] DWARF information inconsistent with the generated RISC-V Binary

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #6 from Andrew Pinski  ---
Actually I take that back, it looks like the dwarf2 pass did do the wrong
values as I don't think it is expecting 2 increments to the sp ...

[Bug target/111680] DWARF information inconsistent with the generated RISC-V Binary

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

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

--- Comment #5 from Andrew Pinski  ---
https://sourceware.org/binutils/docs/as/CFI-directives.html#g_t_002ecfi_005fdef_005fcfa_005foffset-offset


I think you are reading the dwarf standard incorrectly.
It is the second cfi_def_cfa_offset is absolute offset and not an incremental
offset.

[Bug target/111680] DWARF information inconsistent with the generated RISC-V Binary

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

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

--- Comment #4 from Andrew Pinski  ---
MIPS64 does:
```
daddiu  $sp,$sp,-2080
.cfi_def_cfa_offset 2080
daddu   $2,$7,$6
sd  $16,2056($sp)
sd  $17,2064($sp)
sb  $0,0($2)
li  $2,1# 0x1
.cfi_offset 16, -24
.cfi_offset 17, -16

```

Oh I see, the issue riscv has more limited range for the add so it needs to
split it up.

Anyways I think the the unwind tables are valid either way really because
register 8 (s0) is not modifed until later on.

[Bug target/111680] DWARF information inconsistent with the generated RISC-V Binary

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 56044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56044=edit
Preprocessed source

[Bug target/111680] DWARF information inconsistent with the generated RISC-V Binary

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

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

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

`-g0 -O3 -Wall -Wno-unused-label   -fno-reorder-blocks -march=rv64imafd`

[Bug target/111680] DWARF information inconsistent with the generated RISC-V Binary

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||riscv64-linux-gnu
  Component|debug   |target

--- Comment #1 from Andrew Pinski  ---
.cfi_startproc
addisp,sp,-2032
.cfi_def_cfa_offset 2032
sd  s0,2024(sp)
sd  s1,2016(sp)
sd  s2,2008(sp)
add a5,a3,a2
sb  zero,0(a5)
addisp,sp,-48
.cfi_def_cfa_offset 2080
.cfi_offset 8, -8
.cfi_offset 9, -16
.cfi_offset 18, -24

[Bug libstdc++/111685] Segfault while sorting on array element address

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

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

--- Comment #6 from Andrew Pinski  ---
https://github.com/gcc-mirror/gcc/blob/d9375e490072d1aae73a93949aa158fcd2a27018/libstdc%2B%2B-v3/include/bits/stl_algo.h#L1814

is exactly where a temp copy is created. Is that valid for std::sort, I am
pretty sure it is.

[Bug libstdc++/111687] libstdc++ fails to work for clang 18 any more

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

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

--- Comment #2 from Andrew Pinski  ---
https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg361472.html

is the patch which broke clang.

Report it to them.

[Bug libstdc++/111687] libstdc++ fails to work for clang 18 any more

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

[Bug libstdc++/111687] libstdc++ fails to work for clang 18 any more

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
This is a bug in clang:
#ifdef __FLT128_DIG__
__glibcxx_float_n(128)
#endif


__FLT128_DIG__ should not be defined if _Float128 does not exist.

[Bug libstdc++/111687] New: libstdc++ fails to work for clang 18 any more

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 111687
   Summary: libstdc++ fails to work for clang 18 any more
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/limits:1995:1:
error: use of undeclared identifier '_Float128'
 1995 | __glibcxx_float_n(128)
  | ^
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/limits:1903:27:
note: expanded from macro '__glibcxx_float_n'
 1903 | struct numeric_limits<_Float##BITSIZE> 
\
  |   ^
:325:1: note: expanded from here
  325 | _Float128
  | ^
1 error generated.
[29/115] Building CXX object CMakeFiles/libWAVM.dir/Lib/IR/Validate.cpp.o
ninja: build stopped: subcommand failed.

[Bug libstdc++/111685] Segfault while sorting on array element address

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

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

--- Comment #5 from Andrew Pinski  ---
With -fsanitize=address we get this at runtime:
```
=
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fc69190003c
at pc 0x00402d20 bp 0x7ffdf89976f0 sp 0x7ffdf89976e8
READ of size 4 at 0x7fc69190003c thread T0
#0 0x402d1f in void std::__unguarded_linear_insert >(int*,
__gnu_cxx::__ops::_Val_comp_iter)
(/app/output.s+0x402d1f) (BuildId: 644c16636015edebcd5c5ddf005f8c7778b15662)
#1 0x40222f in void std::__insertion_sort >(int*,
int*, __gnu_cxx::__ops::_Iter_comp_iter)
(/app/output.s+0x40222f) (BuildId: 644c16636015edebcd5c5ddf005f8c7778b15662)
#2 0x401c23 in void std::__final_insertion_sort >(int*,
int*, __gnu_cxx::__ops::_Iter_comp_iter)
(/app/output.s+0x401c23) (BuildId: 644c16636015edebcd5c5ddf005f8c7778b15662)
#3 0x401875 in void std::__sort >(int*,
int*, __gnu_cxx::__ops::_Iter_comp_iter)
(/app/output.s+0x401875) (BuildId: 644c16636015edebcd5c5ddf005f8c7778b15662)
#4 0x401653 in void std::sort(int*, int*, main::{lambda(auto:1&&, auto:2&&)#1})
(/app/output.s+0x401653) (BuildId: 644c16636015edebcd5c5ddf005f8c7778b15662)
#5 0x401506 in main (/app/output.s+0x401506) (BuildId:
644c16636015edebcd5c5ddf005f8c7778b15662)
#6 0x7fc693b93082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#7 0x40122d in _start (/app/output.s+0x40122d) (BuildId:
644c16636015edebcd5c5ddf005f8c7778b15662)

Address 0x7fc69190003c is located in stack of thread T0 at offset 60 in frame
#0 0x4012f5 in main (/app/output.s+0x4012f5) (BuildId:
644c16636015edebcd5c5ddf005f8c7778b15662)

  This frame has 5 object(s):
[32, 33) ''
[48, 49) 'cmp' (line 13)
[64, 76) 'anums' (line 10) <== Memory access at offset 60 underflows this
variable
[96, 108) 'nums' (line 11)
[128, 152) 'vnums' (line 9)
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/app/output.s+0x402d1f)
(BuildId: 644c16636015edebcd5c5ddf005f8c7778b15662) in void
std::__unguarded_linear_insert >(int*,
__gnu_cxx::__ops::_Val_comp_iter)
Shadow bytes around the buggy address:
  0x7fc6918ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fc6918ffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fc6918ffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fc6918fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fc6918fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7fc69190: f1 f1 f1 f1 f8 f2 01[f2]00 04 f2 f2 00 04 f2 f2
  0x7fc691900080: 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x7fc691900100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fc691900180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fc691900200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fc691900280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==1==ABORTING
```

[Bug c/111684] enhancement: gcc doesn't warn about pointless tests

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I've had a quick look at the linux-6.6-rc4 kernel code 
and found about a dozen examples of this problem, so there 
would be some customers for a solution.

[Bug other/111686] New: [13 regression] excess errors in 23_containers/vector/bool/allocator/copy.cc after r13-7931-ge6d26b141bf03a

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

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

Bug ID: 111686
   Summary: [13 regression] excess errors in
23_containers/vector/bool/allocator/copy.cc after
r13-7931-ge6d26b141bf03a
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:e6d26b141bf03a0348b51e4778c79d44dc760eed, r13-7931-ge6d26b141bf03a
make  -k check
RUNTESTFLAGS="conformance.exp=23_containers/vector/bool/allocator/copy.cc"
FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
# of expected passes1
# of unexpected failures1

Excess errors:
/home/seurer/gcc/git/build/gcc-13-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437:
warning: 'void* __builtin_memmove(void*, const void*, long unsigned int)'
writing between 9 and 9223372036854775807 bytes into a region of size 8
overflows the destination [-Wstringop-overflow=]

commit e6d26b141bf03a0348b51e4778c79d44dc760eed (HEAD)
Author: Tim Song 
Date:   Wed Sep 6 19:31:55 2023 +0200

libstdc++: Force _Hash_node_value_base methods inline to fix abi (PR111050)

[Bug libstdc++/111685] Segfault while sorting on array element address

[knoepfel at fnal dot gov via Gcc-bugs]

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

Kyle Knoepfel  changed:

   What|Removed |Added

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

--- Comment #4 from Kyle Knoepfel  ---
@Andrew Pinski described what has happened, but not whether that is the
expected behavior of the standard.  See comment #3.

[Bug libstdc++/111685] Segfault while sorting on array element address

[knoepfel at fnal dot gov via Gcc-bugs]

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

--- Comment #3 from Kyle Knoepfel  ---
@Andrew Pinski, yes I surmised as much.  My difficulty, though, is in
understanding if this is the correct behavior according to the standard's
specification of std::sort, which presumably is reasonably summarized in the
type requirements listed at https://en.cppreference.com/w/cpp/algorithm/sort. 
Which formal requirements/preconditions are being violated by cmp?

[Bug libstdc++/111685] Segfault while sorting on array element address

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
And it is definitely defined incorrectly.

Adding a printf in the cmp:
__builtin_printf("%p:%p\n", , );

Gives:
0x12072b0:0x12072b0
0x12072b4:0x12072b0
0x7ffe9afcec9c:0x12072b0
0x12072b8:0x12072b0
0x7ffe9afcec9c:0x12072b4

Which means libstdc++ is calling the cmp on a temporary and you not getting the
correct thing.

[Bug libstdc++/111685] Segfault while sorting on array element address

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

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

--- Comment #1 from Andrew Pinski  ---
IIRC this happens if the cmp is defined incorrectly.

[Bug c++/111685] New: Segfault while sorting on array element address

[knoepfel at fnal dot gov via Gcc-bugs]

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

Bug ID: 111685
   Summary: Segfault while sorting on array element address
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: knoepfel at fnal dot gov
  Target Milestone: ---

The following file (`sort-bug.cpp`) results in a segmentation violation:

```
#include 
#include 
#include 
#include 

int main()
{
  std::vector vnums{1, 5, 4};
  std::array anums{1, 5, 4};
  int nums[] = {1, 5, 4};

  auto cmp = [](auto&& a, auto&& b) { return  <  };

  std::sort(vnums.begin(), vnums.end(), cmp);
  std::sort(anums.begin(), anums.end(), cmp); // segfault
  std::sort(nums, nums + 3, cmp); // segfault
}
```

*Expected result*: the `vnums`, `anums`, and `nums` variables remain unaltered
after the invocation to `std::sort`.

*Compiler info*:

- Target: x86_64-pc-linux-gnu
- Configured with:
/scratch/workspace/art-build-base/v13_02_00-e28/SLF7/build/gcc/v13_1_0/src/gcc-13.1.0/configure
--enable-__cxa_atexit --enable-checking=release
--enable-compressed-debug-sections=all
--enable-languages=c,c++,fortran,go,objc,obj-c++ --enable-libstdcxx-time=rt
--enable-plugin --enable-stage1-checking=all --enable-threads=posix
--prefix=/scratch/workspace/art-build-base/v13_02_00-e28/SLF7/build/gcc/v13_1_0/Linux64bit+3.10-2.17
--with-system-zlib --enable-lto --with-zstd --enable-link-serialization=15
- Thread model: posix
- Supported LTO compression algorithms: zlib zstd
- gcc version 13.1.0 (GCC) 

*Compiler/runtime command*: `g++ sort-bug.cpp -o sort-bug -std=c++20 -pedantic
-Werror -Wall; ./sort-bug`

[Bug c/111684] enhancement: gcc doesn't warn about pointless tests

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Blocks||87403


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c/111684] enhancement: gcc doesn't warn about pointless tests

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|enhancement: gcc doesn't|enhancement: gcc doesn't
   |detect pointless tests  |warn about pointless tests
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Note GCC does detect the pointless just does not warn about it.

[Bug fortran/111674] [13/14 regression] Failure to finalize an allocatable subobject of a non-finalizable type

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #1)
> Created attachment 56036 [details]
> Fix for this PR
> 
> I will apply this patch as 'obvious' to both affected branches.
> 
> Paul

Hi Paul,

this looks simple and pretty obvious.  Go ahead.

[Bug c/111684] New: enhancement: gcc doesn't detect pointless tests

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111684
   Summary: enhancement: gcc doesn't detect pointless tests
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Given this C++ code:

extern void g( int);

void
f( int n)
{
if (n <= 10)
g( n);
else if (n > 10)
g( 10 - n);
}

gcc doesn't have much to say:

$ ~/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra  oct3d.cc
$ 

This might be implemented as a simple extension of the Wduplicated-cond code.

Here is cppcheck finding the problem:

oct3d.cc:11:13: style: Expression is always true because 'else if' condition is
opposite to previous condition at line 9. [multiCondition]
 else if (n > 10)
^
oct3d.cc:9:8: note: first condition
 if (n <= 10)
   ^
oct3d.cc:11:13: note: else if condition is opposite to first condition
 else if (n > 10)
^
$ 

So these two problems in gcc trunk might be detected:

trunk.year/gcc/ada/sysdep.c:424:26: style: Expression is always true because
'else if' condition is opposite to previous condition at line 416.
[multiCondition]

trunk.year/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:547:27:
style: Expression is always true because 'else if' condition is opposite to
previous condition at line 538. [multiCondition]

[Bug c++/111683] New: Incorrect answer when using SSE2 intrinsics with -O3

[deodharvinit99 at gmail dot com via Gcc-bugs]

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

Bug ID: 111683
   Summary: Incorrect answer when using SSE2 intrinsics with -O3
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: deodharvinit99 at gmail dot com
  Target Milestone: ---

Created attachment 56042
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56042=edit
convn_script

g++ produces incorrect answers when SSE2 intrinsics are used with -O3. 
-O2 produces same answers compared to an equivalent code written without SSE2

A standalone repro shell script:

g++ -O2 convn_script.cpp
./a.out

g++ -O3 convn_script.cpp
./a.out


Target: x86_64-linux-gnu
gcc version 10.2.1 20210110 (Debian 10.2.1-6)


covn_script.cpp:

#include 
#include 
#include 

// Function Definitions
//
// Check properties of input in9
//
// Arguments: const double in9[10]
//const double in10[7]
//double out5[16]
// Return Type  : void
//
void convn_script(const double in9[10], const double in10[7], double out5[16])
{
  int iB;
  int iC;
  //  Check properties of input in10
  std::memset([0], 0, 16U * sizeof(double));
  iC = 0;
  iB = 0;
  for (int i{0}; i < 7; i++) {
int b_i;
int vectorUB;
if (i + 10 <= 15) {
  b_i = 9;
} else {
  b_i = 15 - i;
}
vectorUB = (((b_i + 1) / 2) << 1) - 2;
for (int r{0}; r <= vectorUB; r += 2) {
  __m128d b_r;
  b_i = iC + r;
  b_r = _mm_loadu_pd([b_i]);
  _mm_storeu_pd([b_i],
_mm_add_pd(b_r, _mm_mul_pd(_mm_set1_pd(in10[iB]),
   _mm_loadu_pd([r];
}
iC = iB + 1;
iB++;
  }
}

int main() {

double in9[10] = {0.8147, 0.9058, 0.1270, 0.9134,
0.6324,
0.0975,
0.2785,
0.5469,
0.9575,
0.9649};
double in10[7] = { 0.1576,
0.9706,
0.9572,
0.4854,
0.8003,
0.1419,
0.4218};
double out5[16];

convn_script(in9, in10, out5);

for(int i = 0; i < 16; i++) {

std::cout << "Out[" << i << "] = " << out5[i] << "\n";
}

}

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

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #17 from Martin Jambor  ---
Fixed on master (gcc14). I do not intend to backport the patch to any released
version, simply do not switch off DCE on them.

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

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:1be18ea110a2d69570dbc494588a7c73173883be

commit r14-4382-g1be18ea110a2d69570dbc494588a7c73173883be
Author: Martin Jambor 
Date:   Tue Oct 3 18:44:51 2023 +0200

ipa: Self-DCE of uses of removed call LHSs (PR 108007)

PR 108007 is another manifestation where we rely on DCE to clean-up
after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
can leave behind statements which are fed uninitialized values and
trap, even though their results are themselves never used.

I have already fixed this for unused parameters in callees, this bug
shows that almost the same thing can happen for removed returns, on
the side of callers.  This means that the issue has to be fixed
elsewhere, in call redirection.  This patch adds a function which
looks for (and through, using a work-list) uses of operations fed
specific SSA names and removes them all.

That would have been easy if it wasn't for debug statements during
tree-inline (from which call redirection is also invoked).  Debug
statements are decoupled from the rest at this point and iterating
over uses of SSAs does not bring them up.  During tree-inline they are
handled especially at the end, I assume in order to make sure that
relative ordering of UIDs are the same with and without debug info.

This means that during tree-inline we need to make a hash of killed
SSAs, that we already have in copy_body_data, available to the
function making the purging.  So the patch duly does also that, making
the interface slightly ugly.

gcc/ChangeLog:

2023-09-27  Martin Jambor  

PR ipa/108007
* cgraph.h (cgraph_edge): Add a parameter to
redirect_call_stmt_to_callee.
* ipa-param-manipulation.h (ipa_param_adjustments): Add a
parameter to modify_call.
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): New
parameter killed_ssas, pass it to padjs->modify_call.
* ipa-param-manipulation.cc (purge_transitive_uses): New function.
(ipa_param_adjustments::modify_call): New parameter killed_ssas.
Instead of substituting uses, invoke purge_transitive_uses.  If
hash of killed SSAs has not been provided, create a temporary one
and release SSAs that have been added to it.
* tree-inline.cc (redirect_all_calls): Create
id->killed_new_ssa_names earlier, pass it to edge redirection,
adjust a comment.
(copy_body): Release SSAs in id->killed_new_ssa_names.

gcc/testsuite/ChangeLog:

2023-05-11  Martin Jambor  

PR ipa/108007
* gcc.dg/ipa/pr108007.c: New test.

[Bug ipa/110378] IPA-SRA for destructors

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:14d0c509898b0361f78284c05556035edde6d1e0

commit r14-4383-g14d0c509898b0361f78284c05556035edde6d1e0
Author: Martin Jambor 
Date:   Tue Oct 3 18:44:52 2023 +0200

ipa-sra: Allow IPA-SRA in presence of returns which will be removed

Testing on 32bit arm revealed that even the simplest case of PR 110378
was still not resolved there because destructors were rturning this
pointer.  Needless to say, the return value of those destructors often
is just not used, which IPA-SRA can already detect in time.  Since
such enhancement seems generally useful, here it is.

The patch simply adds two flag to respective summaries to mark down
situations when it encounters either a simple direct use of a defaut
definition SSA_NAME of a paramter, which means that the parameter may
still be split when rturn value is removed, and when any derived use
of it is returned, allowing for complete removal in that case, instead
of discarding it as a candidate for removal or splitting like we do
now.  The IPA phase then simply checks that we indeed plan to remove
the return value before allowing any transformation to be considered
in such cases.

gcc/ChangeLog:

2023-08-18  Martin Jambor  

PR ipa/110378
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::mark_dead_statements): Verify that any
return uses of PARAM will be removed.
(ipa_param_body_adjustments::mark_clobbers_dead): Likewise.
* ipa-sra.cc (isra_param_desc): New fields
remove_only_when_retval_removed and split_only_when_retval_removed.
(struct gensum_param_desc): Likewise.  Fix comment long line.
(ipa_sra_function_summaries::duplicate): Copy the new flags.
(dump_gensum_param_descriptor): Dump the new flags.
(dump_isra_param_descriptor): Likewise.
(isra_track_scalar_value_uses): New parameter desc.  Set its flag
remove_only_when_retval_removed when encountering a simple return.
(isra_track_scalar_param_local_uses): Replace parameter call_uses_p
with desc.  Pass it to isra_track_scalar_value_uses and set its
call_uses.
(ptr_parm_has_nonarg_uses): Accept parameter descriptor as a
parameter.  If there is a direct return use, mark any..
(create_parameter_descriptors): Pass the whole parameter descriptor
to
isra_track_scalar_param_local_uses and ptr_parm_has_nonarg_uses.
(process_scan_results): Copy the new flags.
(isra_write_node_summary): Stream the new flags.
(isra_read_node_info): Likewise.
(adjust_parameter_descriptions): Check that transformations
requring return removal only happen when return value is removed.
Restructure main loop.  Adjust dump message.

gcc/testsuite/ChangeLog:

2023-08-18  Martin Jambor  

PR ipa/110378
* gcc.dg/ipa/ipa-sra-32.c: New test.
* gcc.dg/ipa/pr110378-4.c: Likewise.
* gcc.dg/ipa/ipa-sra-4.c: Use a return value.

[Bug c++/111682] New: valgrind error in tsubst_template_decl

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111682
   Summary: valgrind error in tsubst_template_decl
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Recent gcc trunk, built with valgrind, when given this C++ source code
from the clang testsuite:

template struct A {
  template struct B;
  template struct B;
};
template template struct A::B {};
template struct A;
A::B b;


template struct B {
  template static const int var1;
  template static const int var1;

  template static const int var2;
};
template template const int B::var1 = 1;
template template const int B::var2 = 1;
template struct B;
int b_test1[B::var1];
int b_test2[B::var2];


does this:

$ ~/gcc/results.20230927.valgrind/bin/gcc -c -w
./SemaTemplate/instantiate-partial-spec.cpp
==33844== Invalid read of size 2
==33844==at 0x8CCA6B: tsubst_template_decl(tree_node*, tree_node*, int,
tree_node*, tree_node*) (pt.cc:14684)
==33844==by 0x8B4469: tsubst_decl(tree_node*, tree_node*, int, bool)
(pt.cc:14933)
==33844==by 0x8CE78B: most_specialized_partial_spec(tree_node*, int, bool)
(pt.cc:26255)

[Bug ipa/111672] Inappropriate function splitting during pass_split_functions

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

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

--- Comment #1 from Andrew Pinski  ---
I cannot reproduce this on the trunk (or even in 12.3.0):

Split point at BB 3
  header time: 1393.311190 header size: 33
  split time: 2.226400 split size: 2
  bbs: 3
  SSA names to pass:
  Refused: split size is smaller than call overhead
found articulation at bb 7
Split point at BB 7
  header time: 1395.537590 header size: 35
  split time: 0.00 split size: 0
  bbs: 7
  SSA names to pass:
  Refused: split size is smaller than call overhead

[Bug c++/111681] New: Missing fixit for exception name in catch

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

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

Bug ID: 111681
   Summary: Missing fixit for exception name in catch
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Noticed with a Blender issue w/ GCC 13 (missing transitive include for
, https://bugs.gentoo.org/914740).

If I just take the example at
https://en.cppreference.com/w/cpp/error/system_error and mangle it, I get:
```
#include 

int main()
{
try
{
std::thread().detach(); // attempt to detach a non-thread
}
catch(const std::system_error& e)
{
std::cout << "Caught system_error with code "
 "[" << e.code() << "] meaning "
 "[" << e.what() << "]\n";
}
}
```

with:
```
$ g++-14 /tmp/foo.cxx -o /tmp/foo
/tmp/foo.cxx: In function ‘int main()’:
/tmp/foo.cxx:9:34: error: expected unqualified-id before ‘&’ token
9 | catch(const std::system_error& e)
  |  ^
/tmp/foo.cxx:9:34: error: expected ‘)’ before ‘&’ token
9 | catch(const std::system_error& e)
  |  ~   ^
  |  )
/tmp/foo.cxx:9:34: error: expected ‘{’ before ‘&’ token
/tmp/foo.cxx:9:36: error: ‘e’ was not declared in this scope
9 | catch(const std::system_error& e)
  |^
```

The error message here could be better, but even better would be a fixit saying
to include .

[Bug debug/111680] New: DWARF information inconstant with the generated RISC-V Binary

[king.chung at manchester dot ac.uk via Gcc-bugs]

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

Bug ID: 111680
   Summary: DWARF information inconstant with the generated RISC-V
Binary
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: king.chung at manchester dot ac.uk
  Target Milestone: ---

Created attachment 56041
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56041=edit
Screen capture of the Binary and DWARF data.

The DWARF information presented is not matching with the RISC-V binary. On the
attached picture, the left-hand side is the generated binary, and on the
right-hand side is the DWARF information. On the left, we can see the order of
operation is SP Change -> Value Store -> SP Change. However, on the right is SP
Change -> SP Change -> Value Store. If I did not understand the DWARF standard
wrong, the calculation is based on the most recent CFA value, which, in this
case, just by using the DWARF data, the saved value cannot be recovered.

Some discussions have been started on the RISC-V gnu toolchain Repo:
https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1336

[Bug tree-optimization/111679] `(~a) | (a ^ b)` is not simplified to `~(a & b)`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/111679] New: `(~a) | (a ^ b)` is not simplified to `~(a & b)`

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

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

Bug ID: 111679
   Summary: `(~a) | (a ^ b)` is not simplified to `~(a & b)`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, int b)
{
return a | ((~a) ^ b);
}

int f1(int a, int b)
{
return (~a) | (a ^ b); // ~(a & b) or (~a) | (~b)
}
```

The only difference between these 2 functions is a is bitwise inversed. f is
able to be detected and simplified but not f1.

I Noticed this while working on PR 111282.

[Bug libstdc++/108178] Filesystem::copy_file can't copy from /proc on Linux machines

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

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

commit r12-9908-gf85947338197b12b77aa5eb0eb2d1b4ea7dbdd54
Author: Jonathan Wakely 
Date:   Tue Mar 21 12:29:08 2023 +

libstdc++: Make std::filesystem::copy_file work for procfs [PR108178]

The size reported by stat is always zero for some special files such as
those under /proc, which means the current copy_file implementation
thinks there is nothing to copy. Instead of trusting the stat value, try
to read a character from a streambuf and check for EOF.

For the backport, we also need to avoid trying to use sendfile when stat
reports a zero size, so that we use streambufs to copy the file.

libstdc++-v3/ChangeLog:

PR libstdc++/108178
* src/filesystem/ops-common.h (do_copy_file): Check for empty
files by trying to read a character.
* testsuite/27_io/filesystem/operations/copy_file_108178.cc:
New test.

(cherry picked from commit 07a0e108247f23fcb919c61595adae143f1ea02a)

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

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

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

--- Comment #14 from Kito Cheng  ---
Some info for generated files:

-
File   blankcomment   code
-
insn-output.cc  3532  350291631721
insn-emit.cc   37288  402401161790
insn-recog.cc  44203 23 428130
insn-attrtab.cc 1014 30 169934
gimple-match-2.cc 77  2  49303
gimple-match-9.cc 29  2  33073
insn-extract.cc  241  8  28934
gimple-match-1.cc105  2  25578
gimple-match-8.cc114  2  24348
options.cc   325  1  24175
insn-opinit.cc12  6  20156
generic-match-9.cc55  2  19080
gimple-match-3.cc 98  2  17433
gimple-match-7.cc108  2  17105
gimple-match-10.cc   129  2  16888
gimple-match-6.cc115  2  16836
gimple-match-4.cc 97  2  16830
gimple-match-5.cc 99  2  16377
generic-match-3.cc57  2  16138
options-save.cc 1037 19  15121
generic-match-4.cc70  2  14095
gtype-desc.cc679 30  12597
insn-automata.cc  73 11  11735
generic-match-2.cc60  2  11543
generic-match-1.cc56  2  11504
generic-match-7.cc66  2  10238
generic-match-5.cc71  2  10231
generic-match-10.cc   66  2   9860
generic-match-6.cc61  2   9853
generic-match-8.cc53  2   9651
insn-modes.cc750410   7655
min-insn-modes.cc  9  2   2280
gengtype-lex.cc  398424   2126
insn-preds.cc146 32   1515
insn-dfatab.cc31  3   1230
insn-latencytab.cc26  3   1142
gcc-ranlib.cc 55 49196
insn-enums.cc  6  2173
insn-peep.cc   7  2 34
cc1-checksum.cc0  0  3
cc1plus-checksum.cc0  0  3

[Bug c/111678] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 56040
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56040=edit
The compiler output

[Bug c/111678] New: ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

Bug ID: 111678
   Summary: ICE in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 19373742 at buaa dot edu.cn
  Target Milestone: ---

Created attachment 56039
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56039=edit
The preprocessed file

***
OS and Platform:
Ubuntu 20.04.4 LTS
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/cuisk/ctc/gcc-releases/gcc-14/bin/gcc
COLLECT_LTO_WRAPPER=/home/cuisk/ctc/gcc-releases/gcc-14/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/cuisk/ctc/gcc-releases/gcc-14
--disable-multilib --enable-language=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231001 (experimental) (GCC) 
***
Command Lines:
$ gcc -I csmith/include/csmith-2.3.0 -O3 -fno-move-loop-stores -fno-tree-ccp
-fno-tree-copy-prop -fno-tree-dce -fno-tree-forwprop -fno-tree-fre
-fno-tree-loop-ivcanon -fno-tree-vrp a.c -o w 2>a.txt
during GIMPLE pass: ch_vect
a.c: In function ‘func_17’:
a.c:982:25: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
  982 | inline static uint64_t  func_17(uint32_t  p_18, int64_t  p_19, const
int32_t  p_20, uint32_t  p_21, int32_t  p_22)
  | ^~~
0x867aab check_loop_closed_ssa_def
../.././gcc/tree-ssa-loop-manip.cc:647
0x11a1a1c check_loop_closed_ssa_bb
../.././gcc/tree-ssa-loop-manip.cc:661
0x11a1fb6 verify_loop_closed_ssa(bool, loop*)
../.././gcc/tree-ssa-loop-manip.cc:697
0x11a1fb6 verify_loop_closed_ssa(bool, loop*)
../.././gcc/tree-ssa-loop-manip.cc:681
0xf0a5c9 execute_function_todo
../.././gcc/passes.cc:2106
0xf0a9ce execute_todo
../.././gcc/passes.cc:2142
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.

[Bug c/111677] New: arm64 build fails unrecognizable insn [REGRESSION]

[costamagnagianfranco at yahoo dot it via Gcc-bugs]

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

Bug ID: 111677
   Summary: arm64 build fails unrecognizable insn [REGRESSION]
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: costamagnagianfranco at yahoo dot it
  Target Milestone: ---

Created attachment 56038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56038=edit
build log and dump

Hello, according to
https://buildd.debian.org/status/fetch.php?pkg=darktable=arm64=4.4.2-1=1692542143=0

The build was fine with gcc-13 13.2.0-2 and fails with 13.2.0-4

So, the regression if this is really a gcc regression might be in the following
changes:
   * Update to git 20230902 from the gcc-13 branch.
 - Fix PR target/27 (x86), PR middle-end/111017 (x86),
   PR tree-optimization/111070, PR tree-optimization/111039,
   PR tree-optimization/111019, PR tree-optimization/110702,
   PR tree-optimization/09, PR debug/111080, PR target/111010 (x86),
   PR c++/106652, PR c++/110927, PR c++/109678, PR c++/106310,
   PR fortran/87477, PR modula2/110779, PR modula2/108119,
   PR libgcc/110956, PR middle-end/111017, PR libstdc++/110860,
   PR libstdc++/110990, PR libstdc++/110970, PR libstdc++/110974,
   PR libstdc++/110968, PR target/110484 (loong64),
   PR tree-optimization/110914, PR tree-optimization/111015,
   PR target/109725 (riscv), PR c++/109751, PR c++/92407.
 .
   [ Aurelien Jarno ]
   * Fix PR target/110066 (RISCV), taken from the trunk.
 .
   [ Matthias Klose ]
   * Remove test protocols in clean target. Addresses: #1044154.
   * Disable Ada, Go, D, Modula-2 frontends on loong64.
 .
   [ Nicolas Boulenguez ]
   * Ada: deprecate the gnatgcc symbolic link.
   * Ada: move README.gnat to debian/ada/.
   * Ada: remove the obsolete acats-killer script.
   * Ada: let gnat-BV provide a versioned virtual package.
or
   * Update to git 20230913 from the gcc-13 branch.
 - Fix PR target/96762 (PPC), PR target/111340 (x86),
   PR target/111306 (x86), PR target/111335 (x86),
   PR modula2/111330.
 - Address stack protector and stack clash protection weaknesses
   on AArch64. CVE-2023-4039.
 .
   [ Matthias Klose ]
   * Fix PR fortran/88552, taken from the trunk. LP: #1842164.
 .
   [ Aurelien Jarno ]
   * Update libasan8 symbols for riscv64.


I'm attaching the gcc dump report

[Bug target/111235] [Armv7-a]: Control-dependency between atomic accesses removed by -O1.

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

--- Comment #4 from Luke Geeson  ---
Hi there,
Apologies here you go:
https://github.com/llvm/llvm-project/issues/65106

[Bug libstdc++/111589] Use relaxed atomic increment (but not decrement!) in shared_ptr

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> > src/c++98/ios_init.cc:  __gnu_cxx::__atomic_add_dispatch(&_S_refcount, 1);
> 
> I think there's a race here, independent of the ordering used for this
> increment.

That's now PR 111676, and my fix removes the use of __atomic_add_dispatch, so
it no longer matters for this PR.

[Bug sanitizer/111620] [RISC-V]fsanitize is not working with c++

[akhilesh.k at samsung dot com via Gcc-bugs]

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

--- Comment #2 from Akhilesh Kumar  ---
with 110036 (CHECK failed) issue is fixed, but Even after patch ASAN unable to
detect corruption  like "Use_after_free(heap)","Heap buffer overflow","Stack
buffer overflow" and "Use after scope" 

some features like "Double Free" and "Memory leaks" are working after 110036

In all corruption scenarios I am getting "DEADLYSIGNAL" 
Seems program jumped to some wild address, which is unknown to AddressSanitizer 



#include
using namespace std;
int main()
{
int *p=new int;
delete p;
cout<<*p<

[Bug tree-optimization/111648] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-3243-ga7dba4a1c05

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

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

--- Comment #4 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #3)
> Created attachment 56037 [details]
> Untested fix
> 
> The issue is that when a1 is a multiple of vector length, we end up creating
> following encoding in result: { base_elem, arg[0], arg[1], ... } where arg
> is chosen input vector, which is incorrect.
> 
> For above case, vectorizer pass creates VEC_PERM_EXPR where:
> arg0: { -16, -9, -10, -11 } 
> arg1: { -12, -5, -6, -7 } 
> sel = { 3, 4, 5, 6 }
> 
> arg0, arg1 and sel are encoded with npatterns = 1 and nelts_per_pattern = 3.
> Since a1 = 4 and arg_len = 4, it ended up creating the result with
> following encoding:
> res = { arg0[3], arg1[0], arg1[1] } // npatterns = 1, nelts_per_pattern = 3
> = { -11, -12, -5 }
> 
> So for res[4], it used S = (-5) - (-12) = 7
Typo: I meant res[3], not res[4]. Sorry.
> And hence computed it as -5 + 7 = 2.
> instead of arg1[2], ie, -6.
> which is the difference we see in output at -O0 vs -O2.
> 
> The patch tweaks the constratints in valid_mask_for_fold_vec_perm_cst_p to
> punt if a1 is a multiple of vector length, so a1 ... ae only selects from
> stepped part of the input vector, which seems to fix this issue.
> I will run a proper bootstrap+test and post it upstream.

[Bug tree-optimization/111648] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-3243-ga7dba4a1c05

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

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

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 56037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56037=edit
Untested fix

The issue is that when a1 is a multiple of vector length, we end up creating
following encoding in result: { base_elem, arg[0], arg[1], ... } where arg is
chosen input vector, which is incorrect.

For above case, vectorizer pass creates VEC_PERM_EXPR where:
arg0: { -16, -9, -10, -11 } 
arg1: { -12, -5, -6, -7 } 
sel = { 3, 4, 5, 6 }

arg0, arg1 and sel are encoded with npatterns = 1 and nelts_per_pattern = 3.
Since a1 = 4 and arg_len = 4, it ended up creating the result with
following encoding:
res = { arg0[3], arg1[0], arg1[1] } // npatterns = 1, nelts_per_pattern = 3
= { -11, -12, -5 }

So for res[4], it used S = (-5) - (-12) = 7
And hence computed it as -5 + 7 = 2.
instead of arg1[2], ie, -6.
which is the difference we see in output at -O0 vs -O2.

The patch tweaks the constratints in valid_mask_for_fold_vec_perm_cst_p to punt
if a1 is a multiple of vector length, so a1 ... ae only selects from stepped
part of the input vector, which seems to fix this issue.
I will run a proper bootstrap+test and post it upstream.

[Bug libstdc++/111676] New: Race condition in std::ios::Init

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

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

Bug ID: 111676
   Summary: Race condition in std::ios::Init
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 

void f() { std::ios::Init i; }

int main()
{
  std::thread t1(f);
  std::thread t2(f);
  t1.join();
  t2.join();
}

A possible execution for this program is:

t1 runs the Init constructor which increments Init::_S_refcount to 1 and
performs the one-time initialization of the global streams.
t2 runs the Init constructor and increments the refcount to 2.
t2 runs the ~Init destructor, which decrements the refcount to 1 and so flushes
the global streams (while still under construction).
t1 finishes constructing the global streams, and increments _S_refcount to 2.
t1 runs the ~Init destructor, which decrements the refcount to 1 and so flushes
the global streams again.

Flushing twice isn't a problem, but t2 should block until t1 finishes
constructing them, so that it doesn't flush objects that haven't finished
initialization yet.

We could just use a local static so that the __cxa_guard routines are used to
make the second thread block until the initialization is complete.

[Bug modula2/111675] Incorrect parameter value passed when attempting to pass a field of a packed record as a parameter

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Confirmed this is a bug.

[Bug modula2/111675] New: Incorrect parameter value passed when attempting to pass a field of a packed record as a parameter

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

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

Bug ID: 111675
   Summary: Incorrect parameter value passed when attempting to
pass a field of a packed record as a parameter
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Summary cannot pass a packed field by value to a procedure as it results in a
garbled value.

Consider the example below, if compiled and run we get:

$ gm2 -g packedrecord3.mod
$ ./a.out
failed to pass 0 into test
$ gdb ./a.out
(gdb) break printf
(gdb) run
Breakpoint 3, __printf (format=0x402008 "failed to pass %d into test\n") 
(gdb) where
#0  __printf (format=0x402008 "failed to pass %d into test\n") at printf.c:28
#1  0x00401387 in test (s=36893488147419103232, level=0) at
packedrecord3.mod:25
#2  0x004012ce in _M2_packedrecord3_init (argc=1, argv=0x7fffe448,
envp=0x7fffe458) at packedrecord3.mod:47

oddly print sizeof s gives 16 !  


module packedrecord3 ;  (*!m2iso+gm2*)

from libc import printf, exit ;

type
   subrange = [0..63] ;

   packedrec = record
  <* bytealignment (0) *>
  bool: boolean ;
  col : (white, black) ;
  sub : subrange ;
   end ;


var
   global: subrange ;
   pr: packedrec ;


procedure test (s: subrange; level: cardinal) ;
begin
   if s # global
   then
  printf ("failed to pass %d into test\n", ord (s)) ;
  exit (1)
   end ;
   if level > 0
   then
  test (s, level-1)
   end
end test ;


begin
   if size (pr) # 1
   then
  printf ("test failed as size (pr) should be 1 not %d\n", size (pr)) ;
  exit (1)
   end ;
   for global := min (subrange) to max (subrange) do
  test (global, 2)
   end ;
   for global := min (subrange) to max (subrange) do
  pr.bool := false ;
  pr.sub := global ;
  test (pr.sub, 2)
   end
end packedrecord3.

[Bug fortran/111674] [13/14 regression] Failure to finalize an allocatable subobject of a non-finalizable type

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

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

Paul Thomas  changed:

   What|Removed |Added

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

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

I will apply this patch as 'obvious' to both affected branches.

Paul

[Bug fortran/111674] New: [13/14 regression] Failure to finalize an allocatable subobject of a non-finalizable type

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

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

Bug ID: 111674
   Summary: [13/14 regression] Failure to finalize an allocatable
subobject of a non-finalizable type
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56035=edit
Testcase demonstrating the bug

Introduced by r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee

See the attached testcase, which was developed to check F2018 compliance in the
Chivers/Sleightholme compliance tables.

gfortran correctly determines from 7.5.6.1 that y is not finalizable. However,
following the first paragraph in 7.5.6.3, the component y%aa should be
finalized before deallocation in the second assignment. 12-branch used to do
this but 13-branch and mainline currently do not.

Note, that 12-branch does not finalize x in its second assignment, as it
should.

Fortunately the fix is trivial and will be posted in the first comment.

Paul

[Bug rtl-optimization/111673] New: assign_hard_reg() routine should scale save/restore costs of callee save registers with basic block frequency

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

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

Bug ID: 111673
   Summary: assign_hard_reg() routine should scale save/restore
costs of callee save registers with basic block
frequency
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jskumari at gcc dot gnu.org
  Target Milestone: ---

In assign_hard_reg(), when computing the costs of the hard registers, the cost
of saving/restoring a callee-save hard register in epilogue/prologue is taken
into consideration. However, this cost is not scaled with the entry block
frequency. Without scaling, the cost of saving/restoring is quite small and
this can result in a callee-save register being chosen by assign_hard_reg()
even though there are free caller-save(volatile) registers available. 

Consider the following test:

int f(int);

int advance(int dz)
{
if (dz > 0)
return (dz + dz) * dz;
else
return dz * f(dz);
}


Input RTL to IRA pass:

  set r127, r3
  set r121, r127
  set r122, compare(r121, 0)
  if (r122 le 0) jump BB4 else jump BB3

BB3:
  set r123, r121*r121
  set r119, r123<<1
  jump BB5

BB4:
  set r3, call f(r3)
  set r128, r3
  set r119, r128*r121

BB5:
  set r3, r119
  return r3


When assign_hard_reg() is called for allocno r121, the cost for r31 is 0
(obtained from ALLOCNO_UPDATED_HARD_REG_COSTS). Since r31 on PowerPC is a
callee save register, we compute the cost for saving/restoring r31 in
prolog/epilog and this cost is 7. So the final cost for r31 is 7. And r31 is
assigned to allocno r121 since it has the lowest cost among the profitable
registers.
However, among profitable registers for allocno r121, there are caller save
registers (like r9) that could possibly be assigned to allocno r121. r9 has a
cost of 2040 (obtained from ALLOCNO_UPDATED_HARD_REG_COSTS). So it is not
chosen as cost of r31 is lesser.
But computation of save/restore costs for r31 is incorrect as it doesn’t take
into consideration the frequency of the basic blocks in which the save/restore
instructions will be placed. If the frequency is taken into consideration, then
cost of r31 is 7000 (frequency of entry bb is 1000). And this would result in
r9 being assigned to r121.

Since r31 is assigned to allocno r121, the above test does not get shrink
wrapped.

[Bug c/111672] New: Inappropriate function splitting during pass_split_functions

[hkzhang455 at gmail dot com via Gcc-bugs]

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

Bug ID: 111672
   Summary: Inappropriate function splitting during
pass_split_functions
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hkzhang455 at gmail dot com
  Target Milestone: ---

Created attachment 56034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56034=edit
example C file that can trigger inappropriate function splitting

When the GCC compiler performs function splitting optimization, the shorter and
closer path is split into a new function, while the remaining more complex and
expensive code is retained, resulting in the complexity of the original
function being increased after the split, and the split new function only
performs simple operations (such as 'printf()').

You can compile the source code file I put in the attachment with the following
command, and look at the gimple corresponding to the generated fnsplit to find
the phenomenon I described.

  gcc test.c -O3 -flto -fdump-tree-fnsplit -Wall -Wextra

Of course, this is only sample code, so the resulting executable does not
reflect the efficiency gap due to the problem of inline. But in more complex
code, efficiency decreases.

Hardware: 12th Gen Intel(R) Core(TM) i9-12900KF
System: Ubuntu 22.04
Output of `gcc -v`:

Using built-in specs.
COLLECT_GCC=xxx/install/bin/gcc
COLLECT_LTO_WRAPPER=xxx/install/libexec/gcc/x86_64-pc-linux-gnu/12.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=xxx/install --enable-threads=posix
--disable-checking --disable-multilib --disable-bootstrap
--enable-languages=c,c++,lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.3.0 (GCC)

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #16 from Jonathan Wakely  ---
Fixed for 14.0, 13.3, 12.4 and 11.5. Thank you both.

[Bug tree-optimization/111668] [12/13/14 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 56033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56033=edit
gcc14-pr111668.patch

Untested fix which avoids jumping through << 0 and uses the negations for the
larger precision signed boolean cases.

[Bug tree-optimization/111668] [12/13/14 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values

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

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

--- Comment #4 from Jakub Jelinek  ---
So, for the a ? -1 : 0 case (and similarly for a ? 0 : -1) we have 3 distinct
cases.
One is signed 1-bit precision type, for which we jump through the unnecessary
hops of
trying to optimize e.g. the first one as (lshift (convert:type
(convert:boolean_type_node @0) { integer_zero_node; }) and then optimizing away
the shift.  Then the signed boolean case of larger precision, where we can
choose what
exactly we want it to simplify to, one is the negation in signed integer type
of the same precision and another one would be to cast to signed boolean type
rather than unsigned.  And finally the case where both 1 and -1 are valid,
where we should use the negation.
If we go the negation route for the second subcase, that is the only case where
we need build_nonstandard_integer_type.  If we go with the casts, we don't need
it anywhere.

[Bug target/111566] RISC-V Vector Fortran: ICE in final_scan_insn_1 (final RTL pass)

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Jeremy Bennett  changed:

   What|Removed |Added

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

--- Comment #7 from Jeremy Bennett  ---
I can confirm this is resolved, and also that SPEC CPU 2017 627.cam4_s compiles
successfully.

Thanks for the patch. Marking as resolved.

[Bug middle-end/111548] RISC-V Vector: ICE in validate_change_or_fail (vsetvl pass)

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Jeremy Bennett  changed:

   What|Removed |Added

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

--- Comment #2 from Jeremy Bennett  ---
Confirmed that the test now passes, as indeed does SPEC CPU 2017 602.gcc_s.

Thanks for the fix. Marking as resolved.

[Bug tree-optimization/111671] New: ICE in get_default_value, at tree-ssa-ccp.cc:312

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

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

Bug ID: 111671
   Summary: ICE in get_default_value, at tree-ssa-ccp.cc:312
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: aldyh at redhat dot com
  Target Milestone: ---

gcc at -O2/3 crashes.

Bisected to r14-2965-gc83528d2367

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

$ cat a.c
int a, b, c, d;
int e() {
  if (a)
return 0;
  return -1;
}
static unsigned f(short);
void h() {
  int g = 59258;
  b = -50;
  g |= e() + b;
  f(g);
}
unsigned f(short i) {
  int *j[15], *k[15] = {};
  j[0] = 0;
  {
long l[4];
long m = *l, *n[] = {};
for (; c; c++)
  d = i;
int** o[] = {k, j};
  }
}
int main() {}
$
$ gcc -O2 a.c
during GIMPLE pass: ccp
a.c: In function ‘f.isra’:
a.c:14:10: internal compiler error: in get_default_value, at
tree-ssa-ccp.cc:312
   14 | unsigned f(short i) {
  |  ^
0x7ff11cd60082 __libc_start_main
../csu/libc-start.c:308
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.
$

[Bug target/111670] H8/300 SX uses incorrect code sequences

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 Target||h8300

[Bug target/111670] New: H8/300 SX uses incorrect code sequences

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

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

Bug ID: 111670
   Summary: H8/300 SX uses incorrect code sequences
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

The H8/SX port can create sequences like

(set (mem (autoinc (reg sp)) (reg_sp))

Here autoinc is PRE_DECEMENT or PRE_INCREMENT addressing modes.

Which is invalid RTL.

I believe this is the root cause of the following H8/SX failures in the
testsuite:


h8300-sim/-msx/-mint32: gcc.c-torture/execute/920501-6.c   -O1  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/920501-6.c   -Os  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/pr20466-1.c   -O1  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/pr20466-1.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/pr20466-1.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/pr39339.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/ssad-run.c   -O1  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/ssad-run.c   -Os  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/usad-run.c   -O1  execution test
h8300-sim/-msx/-mint32: gcc.c-torture/execute/usad-run.c   -Os  execution test

I suspect we need to break the "Q" constraint into two variants.  One which
allows autoinc addressing modes and the other does not.

For movsi/movhi  we would use the version which does not allow autoinc
addressing modes and instead use the Z0/ZA approach like the other H8 variants
are using.

I'm not currently working on this.