[Bug target/113393] RISC-V: Full coverage test bugs for upstream 20240112

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:0627d1f5340c693699ad36fa2b741ff11d6f026a

commit r14-7238-g0627d1f5340c693699ad36fa2b741ff11d6f026a
Author: Juzhe-Zhong 
Date:   Mon Jan 15 14:57:38 2024 +0800

RISC-V: Fix attributes bug configuration of ternary instructions

This patch fixes the following FAILs:

Running target
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.c-torture/execute/pr68532.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test

Running target
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=m2/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.dg/vect/pr60196-1.c execution test
FAIL: gcc.dg/vect/pr60196-1.c -flto -ffat-lto-objects execution test

Running target
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.dg/vect/pr60196-1.c execution test
FAIL: gcc.dg/vect/pr60196-1.c -flto -ffat-lto-objects execution test

Running target
riscv-sim/-march=rv64gcv_zvl256b/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.dg/vect/pr60196-1.c execution test
FAIL: gcc.dg/vect/pr60196-1.c -flto -ffat-lto-objects execution test

The root cause is attributes of ternary intructions are incorrect which
cause AVL prop PASS and VSETVL PASS behave
incorrectly.

Tested no regression and committed.

PR target/113393

gcc/ChangeLog:

* config/riscv/vector.md: Fix ternary attributes.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr113393-1.c: New test.
* gcc.target/riscv/rvv/autovec/pr113393-2.c: New test.
* gcc.target/riscv/rvv/autovec/pr113393-3.c: New test.

[Bug modula2/111956] [14 Regression] Many powerpc platforms do _not_ have support for IEEE754 long double

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||rguenth at gcc dot gnu.org
 Target||powerpc*-*-*
Summary|Many powerpc platforms do   |[14 Regression] Many
   |_not_ have support for  |powerpc platforms do _not_
   |IEEE754 long double |have support for IEEE754
   ||long double

--- Comment #13 from Richard Biener  ---
It's a regression btw, GCC 13 was fine with this configuration.  I'm also
seeing this.

[Bug c++/113347] [12/13 Regression] ICE during gimplification building TVM since r13-8079-gd237e7b291ff52

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #6 from Richard Biener  ---
I'd like to know what fixed it on trunk still so we can decide whether
reverting or backporting sth additional.

[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #9 from Richard Biener  ---
Yes, this is basically "folding", and across multiple insns this requires
fwprop or combine.

9: r111:TI=zero_extend(r112:DI)
   10: r111:TI=r111:TI&<0,0x>|zero_extend(r113:DI)<<0x40
   74: r137:DI=r111:TI#0
   75: r138:DI=r111:TI#8

I'm not sure fwprop even tries to do 9->10->74 though.

The suggested change to drop the call to "profitable" seems to remove any
cost checking done (and is also not consistent with the other call we do
on notes?).

Would ssa-combine have catched the above?

[Bug c++/113388] Calling explicit object member function without object argument inside a function that is not an implicit object member function

[waffl3x at protonmail dot com via Gcc-bugs]

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

--- Comment #1 from waffl3x  ---
Yeah, looks like a bug. I won't be able to look at it as I am in the
process of moving but it seems like a similar one to PR113348.

Thanks for the report!

[Bug rtl-optimization/113394] New: ICE: 'verify_type' failed: type variant with 'TYPE_ALIAS_SET_KNOWN_P' with -fstrub=internal -g

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113394
   Summary: ICE: 'verify_type' failed: type variant with
'TYPE_ALIAS_SET_KNOWN_P' with -fstrub=internal -g
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

This fails on the gcc.c-torture/compile/20020210-1.c testcase.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fstrub=internal -g
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20020210-1.c
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20020210-1.c:2:15: warning:
anonymous struct declared inside parameter list will not be visible outside of
this definition or declaration
2 | void f(int a, struct {int b[a];} c) {}
  |   ^~
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20020210-1.c: In function
'f.strub.0':
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20020210-1.c:2:38: error:
type variant with 'TYPE_ALIAS_SET_KNOWN_P'
2 | void f(int a, struct {int b[a];} c) {}
...
during RTL pass: final
/repo/gcc-trunk/gcc/testsuite/gcc.c-torture/compile/20020210-1.c:2:38: internal
compiler error: 'verify_type' failed
0x1837cee verify_type(tree_node const*)
/repo/gcc-trunk/gcc/tree.cc:14386
0x1051814 gen_type_die_with_usage
/repo/gcc-trunk/gcc/dwarf2out.cc:26258
0x104e566 gen_type_die
/repo/gcc-trunk/gcc/dwarf2out.cc:26489
0x104e566 gen_decl_die
/repo/gcc-trunk/gcc/dwarf2out.cc:27226
0x104a93d gen_subprogram_die
/repo/gcc-trunk/gcc/dwarf2out.cc:24094
0x104eab9 gen_decl_die
/repo/gcc-trunk/gcc/dwarf2out.cc:27106
0x104f6eb dwarf2out_decl
/repo/gcc-trunk/gcc/dwarf2out.cc:27687
0x104fb8e dwarf2out_function_decl
/repo/gcc-trunk/gcc/dwarf2out.cc:27702
0x10dfea4 rest_of_handle_final
/repo/gcc-trunk/gcc/final.cc:4273
0x10dfea4 execute
/repo/gcc-trunk/gcc/final.cc:4317
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7237-20240115123527-g65678b2bae5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-7237-20240115123527-g65678b2bae5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240115 (experimental) (GCC)

[Bug c/113393] New: RISC-V: Full coverage test bugs for upstream 20240112

[pan2.li at intel dot com via Gcc-bugs]

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

Bug ID: 113393
   Summary: RISC-V:  Full coverage test bugs for upstream 20240112
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

For the RV64 parts

Running target
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.c-torture/execute/pr68532.c   -O0  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr68532.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test

Running target
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-lmul=m2/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.dg/vect/pr60196-1.c execution test
FAIL: gcc.dg/vect/pr60196-1.c -flto -ffat-lto-objects execution test

Running target
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.dg/vect/pr60196-1.c execution test
FAIL: gcc.dg/vect/pr60196-1.c -flto -ffat-lto-objects execution test

Running target
riscv-sim/-march=rv64gcv_zvl256b/-mabi=lp64d/-mcmodel=medlow/--param=riscv-autovec-preference=fixed-vlmax
FAIL: gcc.dg/vect/pr60196-1.c execution test
FAIL: gcc.dg/vect/pr60196-1.c -flto -ffat-lto-objects execution test

[Bug c/67819] -Wduplicated-cond should take macros into account

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
This blocks the enablement of -Wduplicated-cond with -Wall/-Wextra; see bug
87656

[Bug c/89072] -Wall -Werror should be defaults

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=87656

--- Comment #14 from Eric Gallager  ---
Now we're straying into bug 87656...

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #11 from Lukas Grätz  ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++.  I fixed it by
> keeping callee-saved registers when exception is enabled.
> 
> Backtrace with %rbp is unrelated to this.  Gcc will skip %rpb without
> -fno-omit-frame-pointer.

Great! Then I guess there is no pitfall in your patch.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

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

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

--- Comment #10 from H.J. Lu  ---
(In reply to Lukas Grätz from comment #9)

> Well it is not my testcase. But I added backtracing and observed that the
> printed backtrace is unchanged with your patch. The new
> no_return_to_caller():
> 
> void __attribute__((noreturn))
> no_return_to_caller(int a, int b, int c, int d)
> {
>LOOP_BODY;
> 
> #define BT_BUF_SIZE 100
>void *buffer[BT_BUF_SIZE];
>backtrace_symbols_fd(buffer, backtrace(buffer, BT_BUF_SIZE),
> STDOUT_FILENO);
> 
>while (1);
> }
> 
> What I observed from the assembly is that %rbp is not saved, whereas %rip
> and %rsp are still implicitly saved by the call instruction. But since
> glibc's backtrace implementation does not use %rbp, this is fine.
> 
> Some amateur speculation, just ignore it: I don't know whether %rbp is the
> source of the failed C++ test cases, which also do some stack unwinding.
> After looking in the System V Abi specification I am still unsure whether
> stack unwinding relies on %rbp or not. Perhaps there is an unnecessary
> dependency on %rbp or a missing "-fno-omit-frame-pointer" somewhere in the
> gcc internals that causes the problem.

The C++ test issue is caused by missing callee-saved registers for
exception supports in noreturn functions in libstdc++.  I fixed it by
keeping callee-saved registers when exception is enabled.

Backtrace with %rbp is unrelated to this.  Gcc will skip %rpb without
-fno-omit-frame-pointer.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #9 from Lukas Grätz  ---
(In reply to H.J. Lu from comment #8)
> (In reply to Lukas Grätz from comment #7)
> > (In reply to H.J. Lu from comment #4)
> > > When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> > > libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> > > most of C++ exception tests crashed.
> > 
> > Can you tell how you compiled it? Thanks in advance!
> 
> I have a patch to fix it. Please try users/hjl/pr113312/gcc-13 branch:
> 
> 
> For your testcase, I got

Well it is not my testcase. But I added backtracing and observed that the
printed backtrace is unchanged with your patch. The new no_return_to_caller():

void __attribute__((noreturn))
no_return_to_caller(int a, int b, int c, int d)
{
   LOOP_BODY;

#define BT_BUF_SIZE 100
   void *buffer[BT_BUF_SIZE];
   backtrace_symbols_fd(buffer, backtrace(buffer, BT_BUF_SIZE), STDOUT_FILENO);

   while (1);
}

What I observed from the assembly is that %rbp is not saved, whereas %rip and
%rsp are still implicitly saved by the call instruction. But since glibc's
backtrace implementation does not use %rbp, this is fine.

Some amateur speculation, just ignore it: I don't know whether %rbp is the
source of the failed C++ test cases, which also do some stack unwinding. After
looking in the System V Abi specification I am still unsure whether stack
unwinding relies on %rbp or not. Perhaps there is an unnecessary dependency on
%rbp or a missing "-fno-omit-frame-pointer" somewhere in the gcc internals that
causes the problem.

[Bug target/110011] -mfull-toc (-mfp-in-toc) yields incorrect _Float128 constants on power9

[LpSolit at gmail dot com via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #12 from Kewen Lin  ---
Should be fixed everywhere.

[Bug tree-optimization/95987] Another ice during GIMPLE pass: slp

[LpSolit at gmail dot com via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-30
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
  Component|c++ |tree-optimization
Version|unknown |11.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Mine.

--- Comment #2 from Richard Biener  ---
Can no longer reproduce, likely a dup of PR95916.

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

--- Comment #3 from Martin Liška  ---
(In reply to Richard Biener from comment #2)
> Can no longer reproduce, likely a dup of PR95916.
> 
> *** This bug has been marked as a duplicate of bug 95916 ***

Yes, I can confirm that it was fixed with r11-1710-g9a4a52e359ba16a2.

[Bug libstdc++/95990] New: Segmentation fault compiling with static libraries and using jthread::request_stop

[LpSolit at gmail dot com via Gcc-bugs]

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

Bug ID: 95990
   Summary: Segmentation fault compiling with static libraries and
using jthread::request_stop
   Product: gcc
   Version: 10.0
Status: RESOLVED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antal.buss at ualberta dot ca
CC: webrown.cpp at gmail dot com
  Target Milestone: ---
CC: webrown.cpp at gmail dot com
Resolution: DUPLICATE
Status: RESOLVED

A simple program creating a jthread and later calling request_stop on the
created thread produces a segmentation fault when the program is compiled
against the static libraries but works fine using dynamic libraries.

--- Comment #1 from Richard Biener  ---
.

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

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[LpSolit at gmail dot com via Gcc-bugs]

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

Jiu Fu Guo  changed:

   What|Removed |Added

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

--- Comment #12 from Jiu Fu Guo  ---
The generated code is a lot better on the trunk (both -O2 and -O3):
.cfi_startproc
dcmpuq 0,4,6
beq 0,.L4
blr
.p2align 4,,15
.L4:
fmr 5,7
fmr 4,6
fmr 3,7
fmr 2,6
blr


And the expanded RTL like below, and cse/fwprop/dse optimize it as expected. 
2: r119:TD=%2:TD
3: r120:TD=%4:TD
4: r121:TD=%6:TD
5: NOTE_INSN_FUNCTION_BEG
   10: r122:CCFP=cmp(r120:TD,r121:TD)
   11: pc={(r122:CCFP!=0)?L13:pc}
  REG_BR_PROB 708669604
   12: NOTE_INSN_BASIC_BLOCK 4
6: r120:TD=r121:TD
7: r119:TD=r121:TD
   13: L13:
   14: NOTE_INSN_BASIC_BLOCK 5
   15: r123:DI=r112:DI+0x10
   16: [r123:DI]=r120:TD
   17: [r112:DI]=r119:TD
   18: r124:TD=[r112:DI]
   19: r126:DI=r112:DI+0x10
   20: r125:TD=[r126:DI]
   21: r117:TD=r124:TD
   22: r118:TD=r125:TD
   26: %2:TD=r117:TD
   27: %4:TD=r118:TD
   28: use %2:TD
   29: use %4:TD

[Bug libstdc++/95991] New: Segmentation fault compiling with static libraries and using jthread::request_stop

[LpSolit at gmail dot com via Gcc-bugs]

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

Bug ID: 95991
   Summary: Segmentation fault compiling with static libraries and
using jthread::request_stop
   Product: gcc
   Version: 10.0
Status: RESOLVED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antal.buss at ualberta dot ca
  Target Milestone: ---
Resolution: DUPLICATE
Status: RESOLVED

A simple program creating a jthread and later calling request_stop on the
created thread produces a segmentation fault when the program is compiled
against the static libraries but works fine using dynamic libraries.

--- Comment #1 from Richard Biener  ---
.

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

[Bug preprocessor/61638] "warning: multi-line comment" unclear and has false positives

[LpSolit at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Jack Adrian Zappa  ---
Is it possible that 

  2. If a line comment end in an \ but the next line is a comment, then do
 the same thing as is done for a multi-line comment, ignore it as not an
 issue.

Could be done. I know I said or, but it would be nice not to have to add a
pragma if it is not necessary.

[Bug c++/99479] [modules] ICE Aborted signal terminated program cc1plus

[LpSolit at gmail dot com via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |12.0

--- Comment #23 from Patrick Palka  ---
Fixed since GCC 12

[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'

[LpSolit at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Maciej W. Rozycki  ---
Thanks WRT Ada clarification.

Otherwise I don't think there's anything stopping a language definition
from requiring an attempt to modify read-only data to be trapped as an
exceptional condition, leaving it up to the implementation as to whether
to use a hardware feature if available, or whether to rely purely on
software mechanisms, such as manually validating pointers to ensure they
refer to a location within the boundaries of a memory region designated
for writable data before any dereference for the purpose of a write.

For example the Linux kernel while it still supported the original 80386
processor used to manually validate kernel write accesses to user pages,
because crippled hardware would not trap on kernel writes to read-only
pages (this limitation was lifted with the CR0.WP bit from the 80486 on).
>From the Linux user ABI's point of view the solution was transparent.

[Bug tree-optimization/113392] Missed fold of loading 8 consecutive bytes leading to a missed byteswap optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
Summary|Missed fold for loading 8   |Missed fold of loading 8
   |consecutive bytes at an |consecutive bytes leading
   |offset leads to a missed|to a missed byteswap
   |byteswap optimization   |optimization

--- Comment #1 from Andrew Pinski  ---
Dup of bug 98953.

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

[Bug tree-optimization/98953] Failure to optimize two reads from adjacent addresses into one due to having an offset (index)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||llvm at rifkin dot dev

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

[Bug tree-optimization/113392] New: Missed fold of loading 8 consecutive bytes leading to a missed byteswap optimization

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 113392
   Summary: Missed fold of loading 8 consecutive bytes leading to
a missed byteswap optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The simple load function

uint64_t load64bits(const uint8_t* data) {
uint8_t d0 = data[0];
uint8_t d1 = data[1];
uint8_t d2 = data[2];
uint8_t d3 = data[3];
uint8_t d4 = data[4];
uint8_t d5 = data[5];
uint8_t d6 = data[6];
uint8_t d7 = data[7];
return (uint64_t) d0
 | (uint64_t) d1 << 8
 | (uint64_t) d2 << 16
 | (uint64_t) d3 << 24
 | (uint64_t) d4 << 32
 | (uint64_t) d5 << 40
 | (uint64_t) d6 << 48
 | (uint64_t) d7 << 56;
}

is correctly optimized to

load64bits(unsigned char const*):
mov rax, QWORD PTR [rdi]
ret

however,

uint64_t load64bits2(const uint8_t* data, size_t index) {
uint8_t d0 = data[index++];
uint8_t d1 = data[index++];
uint8_t d2 = data[index++];
uint8_t d3 = data[index++];
uint8_t d4 = data[index++];
uint8_t d5 = data[index++];
uint8_t d6 = data[index++];
uint8_t d7 = data[index++];
return (uint64_t) d0
 | (uint64_t) d1 << 8
 | (uint64_t) d2 << 16
 | (uint64_t) d3 << 24
 | (uint64_t) d4 << 32
 | (uint64_t) d5 << 40
 | (uint64_t) d6 << 48
 | (uint64_t) d7 << 56;
}

compiles to

load64bits2(unsigned char const*, unsigned long):
mov rdx, rsi
movzx   eax, BYTE PTR [rdi+1+rsi]
movzx   esi, BYTE PTR [rdi+2+rsi]
sal rax, 8
sal rsi, 16
or  rax, rsi
movzx   esi, BYTE PTR [rdi+rdx]
or  rax, rsi
movzx   esi, BYTE PTR [rdi+3+rdx]
sal rsi, 24
or  rax, rsi
movzx   esi, BYTE PTR [rdi+4+rdx]
sal rsi, 32
or  rax, rsi
movzx   esi, BYTE PTR [rdi+5+rdx]
sal rsi, 40
or  rax, rsi
movzx   esi, BYTE PTR [rdi+6+rdx]
movzx   edx, BYTE PTR [rdi+7+rdx]
sal rsi, 48
sal rdx, 56
or  rax, rsi
or  rax, rdx
ret

Clang compiles both to a single mov.

This impacts other operations, such as a simple byteswap

uint64_t bswap64(const uint8_t* data, size_t index) {
uint8_t d0 = data[index++];
uint8_t d1 = data[index++];
uint8_t d2 = data[index++];
uint8_t d3 = data[index++];
uint8_t d4 = data[index++];
uint8_t d5 = data[index++];
uint8_t d6 = data[index++];
uint8_t d7 = data[index++];
return (uint64_t) d7
 | (uint64_t) d6 << 8
 | (uint64_t) d5 << 16
 | (uint64_t) d4 << 24
 | (uint64_t) d3 << 32
 | (uint64_t) d2 << 40
 | (uint64_t) d1 << 48
 | (uint64_t) d0 << 56;
}

compiling to

bswap64(unsigned char const*, unsigned long):
mov rdx, rsi
movzx   eax, BYTE PTR [rdi+6+rsi]
movzx   esi, BYTE PTR [rdi+5+rsi]
sal rax, 8
sal rsi, 16
or  rax, rsi
movzx   esi, BYTE PTR [rdi+7+rdx]
or  rax, rsi
movzx   esi, BYTE PTR [rdi+4+rdx]
sal rsi, 24
or  rax, rsi
movzx   esi, BYTE PTR [rdi+3+rdx]
sal rsi, 32
or  rax, rsi
movzx   esi, BYTE PTR [rdi+2+rdx]
sal rsi, 40
or  rax, rsi
movzx   esi, BYTE PTR [rdi+1+rdx]
movzx   edx, BYTE PTR [rdi+rdx]
sal rsi, 48
sal rdx, 56
or  rax, rsi
or  rax, rdx
ret

instead of

bswap64(unsigned char const*, unsigned long):
movbe   rax, qword ptr [rdi + rsi]
ret


https://godbolt.org/z/bjxq1rEYY

[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #1)
> (In reply to anlauf from comment #0)
> > The dump-tree suggests that the scalarizer sees the loop invariant j,
> > unconditionally dereferences it outside the loop,
> 
> Note that the copy to the variable before the loop does NOT dereference the
> pointer.

You are right: I was mistaken as I was looking at the code generated for
PR67277, especially at testcase gfortran.dg/ishftc_optional_size_1.f90,
function ishftc4_ref_4, where the scalarization deferences the optional
argument size_,

D.4389 = *size_;

outside of the loop.

> This case is explicitly supported by the scalarizer, see
> gfc_scalar_elemental_arg_saved_as_reference (and
> gfc_walk_elemental_function_args for the initialization of the
> can_be_null_ref field).

I'll need to have a closer look here.

Note that adding a scalar call in function one:

r(1) = two (i(1), j)

generates sane code:

  *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_EXPR
) * 4)) = two (&(*i)[0], j != 0B ? *j : 0, j != 0B);

> Normally this is sufficient to support optional dummies (there is also
> additional support for class wrappers in gfc_conv_procedure_call), except if
> value comes into play.
> 
> > generates code that
> > unconditionally dereferences j in the invocation of two, and uses a
> > wrong interface:
> These are the topics to investigate.
> I suppose we need to duplicate (or factor) the code for optional, value
> dummies that was added for non-elemental procedures in
> gfc_conv_procedure_call.

Probably yes.

There is another observation: using the value attribute for j also in one,
the scalar call from above becomes a straight

  *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_EXPR
) * 4)) = two (&(*i)[0], j, .j);

while the scalarizer produces:

integer(kind=4) * D.4340;
...
D.4340 = &j;
...
  *((integer(kind=4) *) __result.0 + (sizetype) ((S.3 * D.4342 +
D.4339) * 4)) = two (&(*i)[S.3 + -1], *D.4340);

which looks more complicated (besides being wrong...)

[Bug analyzer/113150] FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c -std=c++98 (test for excess errors)

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by John David Anglin :

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

commit r14-7232-gb468821eea8df4890157e816e924244810058cb5
Author: John David Anglin 
Date:   Sun Jan 14 18:23:51 2024 +

Skip several analyzer socket tests on hppa*-*-hpux*

2024-01-14  John David Anglin  

gcc/testsuite/ChangeLog:

PR analyzer/113150
* c-c++-common/analyzer/fd-glibc-byte-stream-socket.c: Skip
on hppa*-*-hpux*.
* c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c: Likewise.
* c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c: Likewise.
* c-c++-common/analyzer/fd-symbolic-socket.c: Likewise.
* gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c:
Likewise.

[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #2 from Georg-Johann Lay  ---
Implemented in v14.

[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:48448055fb70862ff3914f8a714ff5c4128e6ced

commit r14-7231-g48448055fb70862ff3914f8a714ff5c4128e6ced
Author: Georg-Johann Lay 
Date:   Thu Jan 11 22:11:25 2024 +0100

AVR: Support .rodata in Flash for AVR64* and AVR128* Devices.

These devices see a 32 KiB block of their program memory (flash) in
the RAM address space.  This can be used to support .rodata in flash
provided Binutils support PR31124 (Add new emulations which locate
.rodata in flash).  This patch does the following:

* configure checks availability of Binutils PR31124.

* Add new command line options -mrodata-in-ram and -mflmap.
While -flmap is for internal usage (communicate hardware properties
from device-specs to the compiler proper), -mrodata-in-ram is a user
space option that allows to return to the current rodata-in-ram layout.

* Adjust gen-avr-mmcu-specs.cc so that device-specs are generated
that sanity check options, and that translate -m[no-]rodata-in-ram
to its emulation.

* Objects in .rodata don't drag __do_copy_data.

* Document new options and built-in macros.

PR target/112944

gcc/
* configure.ac [target=avr]: Check availability of emulations
avrxmega2_flmap and avrxmega4_flmap, resulting in new config vars
HAVE_LD_AVR_AVRXMEGA2_FLMAP and HAVE_LD_AVR_AVRXMEGA4_FLMAP.
* configure: Regenerate.
* config.in: Regenerate.
* doc/invoke.texi (AVR Options): Document -mflmap, -mrodata-in-ram,
__AVR_HAVE_FLMAP__, __AVR_RODATA_IN_RAM__.

* config/avr/avr.opt (-mflmap, -mrodata-in-ram): New options.
* config/avr/avr-arch.h (enum avr_device_specific_features):
Add AVR_ISA_FLMAP.
* config/avr/avr-mcus.def (AVR_MCU) [avr64*, avr128*]: Set isa flag
AVR_ISA_FLMAP.
* config/avr/avr.cc (avr_arch_index, avr_has_rodata_p): New vars.
(avr_set_core_architecture): Set avr_arch_index.
(have_avrxmega2_flmap, have_avrxmega4_flmap)
(have_avrxmega3_rodata_in_flash): Set new static const bool
according
to configure results.
(avr_rodata_in_flash_p): New function using them.
(avr_asm_init_sections): Let
readonly_data_section->unnamed.callback
track avr_need_copy_data_p only if not avr_rodata_in_flash_p().
(avr_asm_named_section): Track avr_has_rodata_p.
(avr_file_end): Emit __do_copy_data also when avr_has_rodata_p
and not avr_rodata_in_flash_p ().
* config/avr/specs.h (CC1_SPEC): Add %(cc1_rodata_in_ram).
(LINK_SPEC): Add %(link_rodata_in_ram).
(LINK_ARCH_SPEC): Remove.
* config/avr/gen-avr-mmcu-specs.cc (have_avrxmega3_rodata_in_flash)
(have_avrxmega2_flmap, have_avrxmega4_flmap): Set new static
const bool according to configure results.
(diagnose_mrodata_in_ram): New function.
(print_mcu): Generate specs with the following changes:
<*cc1_misc, *asm_misc, *link_misc>: New specs so that we don't
need to extend avr/specs.h each time we add a new bell or whistle.
<*cc1_rodata_in_ram, *link_rodata_in_ram>: New specs to diagnose
-m[no-]rodata-in-ram.
<*cpp_rodata_in_ram>: New. Does -D__AVR_RODATA_IN_RAM__=0/1.
<*cpp_mcu>: Add -D__AVR_AVR_FLMAP__ if it applies.
<*cpp>: Add %(cpp_rodata_in_ram).
<*link_arch>: Use emulation avrxmega2_flmap, avrxmega4_flmap as
requested.
<*self_spec>: Add -mflmap or %

[Bug target/113391] New: Assertion failure when MSP430 operand modifier J is used with a non-constant value

[seanga2 at gmail dot com via Gcc-bugs]

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

Bug ID: 113391
   Summary: Assertion failure when MSP430 operand modifier J is
used with a non-constant value
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seanga2 at gmail dot com
  Target Milestone: ---

The following program

unsigned char src;

int main(void)
{
unsigned int tmp = 0x1234;
unsigned int dst = 2;

src = 1;
asm(".set off, %J[off]\n\t"
"add.b off(%[base]), %[dst]\n\t"
: [dst] "+r" (dst)
: [off] "i" ((unsigned int)&src - tmp), [base] "r" (tmp), "m" (src));
return dst != 3;
}

fails to compile with the following error:

during RTL pass: final
add.c: In function 'main':
add.c:14:1: internal compiler error: in msp430_print_operand, at
config/msp430/msp430.cc:4338
   14 | }
  | ^
0x5fb114 ???
../sysdeps/x86_64/start.S:115
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.

The version of the compiler is

$ msp430-elf-gcc --version
msp430-elf-gcc (GCC) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug rtl-optimization/113390] New: [14 Regression] ICE: in model_update_limit_points_in_group, at haifa-sched.cc:1986 with -O2 --param=max-sched-region-insns=200 --param=max-sched-extend-regions-iters

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113390
   Summary: [14 Regression] ICE: in
model_update_limit_points_in_group, at
haifa-sched.cc:1986 with -O2
--param=max-sched-region-insns=200
--param=max-sched-extend-regions-iters=2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Created attachment 57079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57079&action=edit
reduced testcase

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O2 --param=max-sched-region-insns=200
--param=max-sched-extend-regions-iters=2 testcase.c 
during RTL pass: sched1
testcase.c: In function 'foo0':
testcase.c:45:1: internal compiler error: in
model_update_limit_points_in_group, at haifa-sched.cc:1986
   45 | }
  | ^
0xe95736 model_update_limit_points_in_group
/repo/gcc-trunk/gcc/haifa-sched.cc:1986
0xe95736 model_update_limit_points
/repo/gcc-trunk/gcc/haifa-sched.cc:1997
0xe95736 schedule_insn
/repo/gcc-trunk/gcc/haifa-sched.cc:4091
0x2a40c39 schedule_block(basic_block_def**, void*)
/repo/gcc-trunk/gcc/haifa-sched.cc:6915
0x1650ec4 schedule_region
/repo/gcc-trunk/gcc/sched-rgn.cc:3203
0x1650ec4 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3525
0x165130c schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3511
0x165130c rest_of_handle_sched
/repo/gcc-trunk/gcc/sched-rgn.cc:3729
0x165130c execute
/repo/gcc-trunk/gcc/sched-rgn.cc:3839
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.

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7215-20240112190107-g8b447fa89d5-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-7215-20240112190107-g8b447fa89d5-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240112 (experimental) (GCC)

[Bug c++/113389] New: ICE when explicit object parameter is not declared as the first parameter

[cooky.ykooc922 at gmail dot com via Gcc-bugs]

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

Bug ID: 113389
   Summary: ICE when explicit object parameter is not declared as
the first parameter
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cooky.ykooc922 at gmail dot com
  Target Milestone: ---

Although it is obviously an error, it causes ICE:

struct A {
void foo(A, this A);
};

compiler output:
:3:17: error: Only the first parameter of a member function can be
declared as an explicit object parameter
3 | void foo(A, this A);
  | ^~
:3:23: internal compiler error: Segmentation fault
3 | void foo(A, this A);
  |   ^
0x2640d5c internal_error(char const*, ...)
???:0
0xa78793 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
???:0
0xb18083 check_default_argument(tree_node*, tree_node*, int)
???:0
0xb1861f grokparms(tree_node*, tree_node**)
???:0
0xb2caa1 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0xb50ff3 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
???:0
0xc5214a c_parse_file()
???:0
0xda5b49 c_common_parse_file()
???:0

godbolt link with -std=c++23: https://godbolt.org/z/Mxefo3nj6

[Bug c++/113388] New: Calling explicit object member function without object argument inside a function that is not an implicit object member function

[cooky.ykooc922 at gmail dot com via Gcc-bugs]

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

Bug ID: 113388
   Summary: Calling explicit object member function without object
argument inside a function that is not an implicit
object member function
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cooky.ykooc922 at gmail dot com
  Target Milestone: ---

According to https://eel.is/c++draft/over.call.func#3:

In unqualified function calls, the function is named by a primary-expression.
The function declarations found by name lookup ([basic.lookup]) constitute the
set of candidate functions. Because of the rules for name lookup, the set of
candidate functions consists either entirely of non-member functions or
entirely of member functions of some class T. In the former case or if the
primary-expression is the address of an overload set, the argument list is the
same as the expression-list in the call. Otherwise, the argument list is the
expression-list in the call augmented by the addition of an implied object
argument as in a qualified function call. If the current class is, or is
derived from, T, and the keyword this ([expr.prim.this]) refers to it, then the
implied object argument is (*this). Otherwise, a contrived object of type T
becomes the implied object argument; if overload resolution selects a
non-static member function, the call is ill-formed.

In other words, the code snippet below must produce an error because a call to
'bar()' inside the function 'foo', 'baz', or any function which is not an
implicit object member function itself, is ill-formed without the object
argument. There is no error inside implicit object member function 'qux'
because the implied object argument is '*this' unlike other explicit object
member functions.

struct A {
void bar(this A) {}

static void foo() {
// not ok: this should be error
// because the overload resolution
// picked a non-static member function
// without an object argument
bar();

// ok [error as expected]:
// bar(A{});

// ok [converted to function pointer]:
(&A::bar)(A{});

// ok [called with an object argument]:
A{}.bar();
}

void baz(this A self) {
// ok
self.bar();

// ok [error as expected]
// self.bar(self);

// ok [error as expected]
// bar(A{});

// not ok: this should be error
// because the overload resolution
// picked a non-static function
// without an object argument
// even inside the scope of the
// explicit object member function
bar();

// ok
A{}.bar();
}

void qux() {
// ok
bar();

// ok [error as expected]
// bar(*this);
}
};

godbolt link with -std=c++23: https://godbolt.org/z/89Msa7Gfj

[Bug libstdc++/113283] missing C++26 freestanding headers.

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

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

--- Comment #11 from Arsen Arsenović  ---
could be implemented in libstdc++ when no libc impl is present

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

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

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-14
 Status|UNCONFIRMED |NEW

--- Comment #8 from H.J. Lu  ---
(In reply to Lukas Grätz from comment #7)
> (In reply to H.J. Lu from comment #4)
> > When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> > libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> > most of C++ exception tests crashed.
> 
> Can you tell how you compiled it? Thanks in advance!

I have a patch to fix it. Please try users/hjl/pr113312/gcc-13 branch:

https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13?ref_type=heads

For your testcase, I got

.globl  no_return_to_caller
.type   no_return_to_caller, @function
no_return_to_caller:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl$array+67108860, %eax
xorl%r13d, %r13d
movq%rax, 8(%rsp)
.L2:
movl$256, %ebp
movq8(%rsp), %r12
movl$256, %ebx
subl%r13d, %ebp
.p2align 4,,10
.p2align 3
.L6:
movq%r12, %r14
movl$256, %r15d
.p2align 4,,10
.p2align 3
.L3:
movl%r15d, %edx
movl%ebx, %esi
movl%ebp, %edi
subl$1, %r15d
callvalue
subq$4, %r14
movl%eax, 4(%r14)
testl   %r15d, %r15d
jne .L3
subq$1024, %r12
subl$1, %ebx
jne .L6
subq$262144, 8(%rsp)
addq$1, %r13
cmpq$256, %r13
jne .L2
.L5:
jmp .L5
.cfi_endproc
.LFE0:
.size   no_return_to_caller, .-no_return_to_caller

[Bug tree-optimization/113385] [14 regression] ICE when building opencv (dfs_enumerate_from, at cfganal.cc:1590)

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

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

--- Comment #3 from Sam James  ---
Created attachment 57078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57078&action=edit
reduced.ii

Attached something a bit smaller but it's not great (not very elegant and too
many warnings).

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

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

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

--- Comment #8 from Jonathan Wakely  ---
We will do it as a DR against all previous standards, as we do for most DRs.

But closing Bug 90203 was still correct at the time.

[Bug other/113336] libatomic (testsuite) regressions on armv6-linux-gnueabihf

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-14
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #1 from Roger Sayle  ---
As there's a patch for this regression (awaiting review), I should upgrade the
PR status to ASSIGNED.

[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com

--- Comment #8 from Roger Sayle  ---
Now we're in stage4, I'll take this.  I'm bootstrapping and regression testing
a variant of my tweak to try_fwprop_subst_pattern.  The change in comment #7
can hang loop indefinitely if the transformation results in the same cost as
the original, so the logic on when to forward-propagate needed to be tweaked a
little.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #7 from Lukas Grätz  ---
(In reply to H.J. Lu from comment #4)
> When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> most of C++ exception tests crashed.

Can you tell how you compiled it? Thanks in advance!

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz--- via Gcc-bugs]

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

Lukas Grätz  changed:

   What|Removed |Added

 CC||lukas.graetz@tu-darmstadt.d
   ||e

--- Comment #6 from Lukas Grätz  ---
(In reply to Sam James from comment #5)
> (In reply to thutt from comment #2)
> PR10837 has some discussion on this point too.

The debugging argument there was for the backtrace. For that we only need to
follow the calling conventions to save the stack and instruction pointers.
Other registers, including callee saved registers like r12,r13,r14,r15 are not
used in a backtrace.

[Bug target/106060] Inefficient constant broadcast on x86_64

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 Status|NEW |ASSIGNED

--- Comment #4 from Roger Sayle  ---
I have a patch for better materialization of vector constants (including
cmpeq+abs  and cmpeq+abs), but now that we've transitioned for stage 3 (bug
fixing) to stage 4 (regression fixing), this will have to wait for GCC 15's
stage 1.  I'm happy to post the patch here or to gcc-patches, if anyone would
like to pre-review it and/or benchmark the proposed changes.

[Bug target/112992] Inefficient vector initialization using vec_duplicate/broadcast

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |14.0

--- Comment #10 from Roger Sayle  ---
This has now been fixed on mainline (we generate identical code for all four
functions in comment #1).

[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin  ---
(In reply to anlauf from comment #0)
> The dump-tree suggests that the scalarizer sees the loop invariant j,
> unconditionally dereferences it outside the loop,

Note that the copy to the variable before the loop does NOT dereference the
pointer.
This case is explicitly supported by the scalarizer, see
gfc_scalar_elemental_arg_saved_as_reference (and
gfc_walk_elemental_function_args for the initialization of the can_be_null_ref
field).

Normally this is sufficient to support optional dummies (there is also
additional support for class wrappers in gfc_conv_procedure_call), except if
value comes into play.

> generates code that
> unconditionally dereferences j in the invocation of two, and uses a
> wrong interface:
These are the topics to investigate.
I suppose we need to duplicate (or factor) the code for optional, value dummies
that was added for non-elemental procedures in gfc_conv_procedure_call.

[Bug c/108796] Can't intermix C2x and GNU style attributes

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

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

[Bug c/113387] __attribute__ does not mix with [[gnu:]]

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 108796 .

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

[Bug c/113387] New: __attribute__ does not mix with [[gnu:]]

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

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

Bug ID: 113387
   Summary: __attribute__ does not mix with [[gnu:]]
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

The following compiles fine

[[gnu::used]] __attribute__((used)) int x;

while

__attribute__((used)) [[gnu::used]] int x;

bar.c:1:1: warning: 'used' attribute does not apply to types [-Wattributes]
1 | __attribute__((used)) [[gnu::used]] int x;
  | ^
bar.c:1:37: error: expected identifier or '(' before 'int'
1 | __attribute__((used)) [[gnu::used]] int x;
  | ^~~

IMO both should be valid.

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

[janschultke at googlemail dot com via Gcc-bugs]

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

--- Comment #7 from Jan Schultke  ---
I've noticed that too by now. What confuses me is that both libc++ and MSVC STL
implement it as if it was a DR, so transparent comparisons work even outside
C++23 mode.

Is it just a collective mistake, or what's going on with that? What would be
the right way to implement it in libstdc++ then?

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jan Schultke from comment #5)
> My bad again, it's a defect report, so cppreference is fine.

No, the status is C++23 which means it was only voted as part of C++23. as far
as I understand that.

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

[janschultke at googlemail dot com via Gcc-bugs]

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

--- Comment #5 from Jan Schultke  ---
My bad again, it's a defect report, so cppreference is fine.

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

[janschultke at googlemail dot com via Gcc-bugs]

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

--- Comment #4 from Jan Schultke  ---
My bad. https://en.cppreference.com/w/cpp/utility/pair/operator_cmp currently
shows

> template< class T1, class T2, class U1, class U2 >
> bool operator==( const std::pair& lhs, const std::pair& rhs );
> (until C++14)

I'll fix this page. Never trust cppreference blindly I guess :)

[Bug libstdc++/90203] Can't compare "const std::pair" with "std::pair"

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

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

--- Comment #5 from Andrew Pinski  ---
Note C++23 changes this via
https://cplusplus.github.io/LWG/lwg-defects.html#3865 .

[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function

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

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

Paul Thomas  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---

> 
> Both allocation with source and assignment are broken :-(

With numerical output from foo ([1,2,3,4,5]), we get:

   1   3   5  33   1
   1   2   3   4   5
   1   2   3   4   5

So allocation with source is broken here as well but assignment is OK.

[Bug libstdc++/113386] std::pair comparison operators should be transparent, but are not in libstdc++

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-14
 Status|UNCONFIRMED |NEW

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

[Bug libstdc++/113386] std::pair comparison operators should be transparent, but are not in libstdc++

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Jan Schultke from comment #0)

> Clang with -stdlib=libc++ compiles this, as does MSVC. Bug #90203 was
> incorrectly closed.

No PR 90203 was not closed incorrectly as that was what the C++ standard said
at the time (and even says still for C++20).


C++ LWG defect report 3865 added this to the standard for C++23:
https://cplusplus.github.io/LWG/lwg-defects.html#3865

GCC just does not implement that yet ...

[Bug libstdc++/113386] std::pair comparison operators should be transparent, but are not in libstdc++

[janschultke at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Jan Schultke  ---
https://godbolt.org/z/9x9n4bGKK

[Bug libstdc++/113386] New: std::pair comparison operators should be transparent, but are not in libstdc++

[janschultke at googlemail dot com via Gcc-bugs]

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

Bug ID: 113386
   Summary: std::pair comparison operators should be transparent,
but are not in libstdc++
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

## Code to reproduce

#include 

bool equals(const std::pair& a, const std::pair& b) {
return a == b;
}

## Explanation

Clang with -stdlib=libc++ compiles this, as does MSVC. Bug #90203 was
incorrectly closed.

std::pair comparison operators should be transparent, see
https://eel.is/c++draft/pairs.spec The standard requires the signature:

> template
> constexpr bool operator==(const pair& x, const pair& y);

libstdc++ incorrectly implements this with only two template parameters:

> template
>   inline _GLIBCXX_CONSTEXPR bool
>   operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
>   { return __x.first == __y.first && __x.second == __y.second; }

[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function

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

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

--- Comment #1 from Paul Thomas  ---
(In reply to anlauf from comment #0)
> While discussing a patch for PR89645/99065, the following issue with
> ASSOCIATE and unlimited polymorphic functions was found:
> 
> https://gcc.gnu.org/pipermail/fortran/2024-January/060098.html
> 
> program p
>   implicit none
>   class(*), allocatable :: x(:)
>   x = foo()
>   call prt (x)
>   deallocate (x)! up to here all is fine...
>   associate (var => foo())  ! <- crash here
> call prt (var)  ! <- or here
>   end associate
> contains
>   function foo() result(res)
> class(*), allocatable :: res(:)
> res = [42]
>   end function foo
>   subroutine prt (x)
> class(*), intent(in) :: x(:)
> select type (x)
> type is (integer)
>print *, x
> class default
>stop 99
> end select
>   end subroutine prt
> end
> 
> 
> This ICEs on current trunk for any of the indicated statements.

The associate bit is fixed with a one liner; with the patch applied:
@@ -2295,7 +2305,8 @@ trans_associate_var (gfc_symbol *sym, gfc_wrapped_block
*block)
 }

   /* Set the stringlength, when needed.  */
-  if (need_len_assign)
+  if (need_len_assign
+  && !(e->symtree->n.sym->attr.function && UNLIMITED_POLY
(e->symtree->n.sym)))
 {
   gfc_se se;
   gfc_init_se (&se, NULL);

the following gives the output in the comments:
program p
  implicit none
  class(*), allocatable :: x(:)
  allocate(x, source = foo())
  call prt (x)  ! Wrong output "6 hello e"
  deallocate (x)
  x = foo()
  call prt (x)  ! Wrong output "0  "
  deallocate (x)!
  associate (var => foo())  ! Now OK
call prt (var)  ! Now OK - outputs: "6 hello bye   "
  end associate
contains
  function foo() result(res)
class(*), allocatable :: res(:)
res = ["hello ","bye   "]
  end function foo
  subroutine prt (x)
class(*), intent(in) :: x(:)
select type (x)
type is (character(*))
   print *, len(x), x
class default
   stop 99
end select
  end subroutine prt
end

Both allocation with source and assignment are broken :-(