[Bug preprocessor/117968] New: running "cpp" with malformed arguments can cause input file deletion

[dev--- via Gcc-bugs]

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

Bug ID: 117968
   Summary: running "cpp" with malformed arguments can cause input
file deletion
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d...@remi-marsal.com
  Target Milestone: ---

When running the "cpp" command, if the command's arguments contain two values
that cannot be associated with a flag (eg "cpp arg1 arg2"), it will result in:

- case 1, if file "arg1" exists in your file system, then a file named "arg2"
will be overwritten with the output of the "cpp" command.

- case 2, if file "arg1" does not exist in your file system, then if file
"arg2" exists in the file system, it will be deleted.

Example:

Given a source file "main.c".

Let's run "cpp" on the source file while setting up a macro: 
> "cpp -DMACRO=1 main.c"

The command is correct, nothing will happen.

However, if I make a typo in the command and forget to use the equal sign ('=')
to affect a value to my macro:
> "cpp -DMACRO 1 main.c"

The file "main.c" will be deleted.

If the file "1" exists, then running:
> "cpp -DMACRO 1 main.c"

Will overwrite the file "main.c" with the output of the "cpp" command.

Reproduction case 1:
> touch main.c
> cpp -DMACRO 1 main.c
...
> cat main.c
cat: main.c: No such file or directory

Reproduction case 2:
> touch 1
> touch main.c
> cpp -DMACRO 1 main.c
> cat main.c
# 0 "1"
# 0 ""
...

Comment:

I could not find explanation for this behavior on the internet and after a talk
with chatgpt.

I don't know if this behavior is correct and apologize if there is a mechanism
under the hood that I don't understand.

What would make sense to me would be if I explicitly redirected the output of
my cpp command (eg "cpp ... >") or if I used an output flag (eg "cpp ... -o
...")

[Bug driver/117968] running "cpp" with malformed arguments can cause input file deletion

[dev--- via Gcc-bugs]

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

--- Comment #4 from Rémi MARSAL  ---
Thanks for pointing out the man page Jakub. This makes sense now.

Apologies about this report.

However, I don't understand why cpp doesn't raise an error because the input
file doesn't exist.

I recursively run a malformed cpp command on a "mock" project folder, and it
disappeared.

[Bug c++/100252] New: Internal compiler error during template instantiation

[sand at rifkin dot dev via Gcc-bugs]

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

Bug ID: 100252
   Summary: Internal compiler error during template instantiation
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sand at rifkin dot dev
  Target Milestone: ---

An internal compiler error occurs while compiling this template code:
https://godbolt.org/z/rP9Wf97vP.

Error message:
: In member function 'typename example::Ac::gt::k& tcc::gr()
[with int I = 1; A = {float, int}]':
:97:62: internal compiler error: in replace_placeholders_r, at
cp/tree.c:3332
   97 | return typename example::Ac::template gt{k}.K;
  | ~^
0x1cff079 internal_error(char const*, ...)
???:0
0x6bac69 fancy_abort(char const*, int, char const*)
???:0
0x13971f3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0

[Bug c++/100252] Internal compiler error during template instantiation

[sand at rifkin dot dev via Gcc-bugs]

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

--- Comment #1 from Jeremy R.  ---
A more minimal case: https://godbolt.org/z/jxP9e35bz

[Bug c++/97946] New: passing templated function without template argument

[niklas at nolte dot dev via Gcc-bugs]

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

Bug ID: 97946
   Summary: passing templated function without template argument
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niklas at nolte dot dev
  Target Milestone: ---

The compiler accepts the following code.
`fun` without template arguments should not be accepted, should it?
```
template
void fun() {}

template
void higher_order_fun( const F & f) {
f();
}

int main () {
//higher_order_fun(fun<>); //works
higher_order_fun(fun);
}
```

The related stackoverflow question:

https://stackoverflow.com/questions/64872397/passing-function-template-prototype-as-argument

[Bug c++/100252] Internal compiler error during template instantiation

[sand at rifkin dot dev via Gcc-bugs]

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

--- Comment #2 from Jeremy R.  ---
Even more minimal case: https://godbolt.org/z/M3Tv9oqcn

[Bug c++/100482] namespaces as int in decltype expression

[sand at rifkin dot dev via Gcc-bugs]

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

--- Comment #1 from Jeremy R.  ---
This appears to be valid for function return types as well but the compiler
does error when decltype is used in a function parameter

namespace std{}
int A(int a) { // fine
decltype(std) b = a;
return b;
}
decltype(std) B(int a) {  // fine
decltype(std) b = a;
return b;
}
auto C(int a) -> decltype(std) {  // fine
decltype(std) b = a;
return b;
}
int D(decltype(std) a) { // error: expected initializer before 'a'
decltype(std) b = a;
return b;
}

[Bug jit/100207] -Werror=format-security error in AUR build of libgccjit

[jonathon at m2x dot dev via Gcc-bugs]

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

Jonathon  changed:

   What|Removed |Added

 CC||jonathon at m2x dot dev

--- Comment #16 from Jonathon  ---
> Kernel: 5.11.15-arch1-2

> the guys at Manjaro

If you are running Manjaro please don't refer to Arch. They are not the same
distribution and it causes huge amounts of confusion given the large number of
patches and changes that Manjaro apply.

[Bug jit/100207] -Werror=format-security error in AUR build of libgccjit

[jonathon at m2x dot dev via Gcc-bugs]

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

--- Comment #18 from Jonathon  ---
Thanks for clearing that up. You gave the impression that you reinstalled
Manjaro in a VM to ensure it wasn't a local change, and it wasn't otherwise
clear what Manjaro had to do with anything (i.e. why would Manjaro's settings
indicate what was "safe" in Arch?).

As it is, have a look at the Arch bug report and see if there's anything you
can add: https://bugs.archlinux.org/task/70701

[Bug c++/100507] New: ICE on invalid: tree check expects tree that contains 'decl common'

[sand at rifkin dot dev via Gcc-bugs]

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

Bug ID: 100507
   Summary: ICE on invalid: tree check expects tree that contains
'decl common'
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sand at rifkin dot dev
  Target Milestone: ---

template
void f(auto r){}

Causes an ICE on gcc trunk (11.1 errors correctly):
https://godbolt.org/z/fYe7E9ocM

[Bug lto/100692] New: [11 Regression] ICE in fld_incomplete_type_of, at tree.c:5452

[luke at street dot dev via Gcc-bugs]

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

Bug ID: 100692
   Summary: [11 Regression] ICE in fld_incomplete_type_of, at
tree.c:5452
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luke at street dot dev
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

ICE triggered with 

g++ -std=c++2a -msse4.1 -fext-numeric-literals -flto

during IPA pass: *free_lang_data
../extern/athena/src/athena/DNAYaml.cpp:1105:1: internal compiler error: in
fld_incomplete_type_of, at tree.c:5452
0x1797368 internal_error(char const*, ...)
???:0
0x67f8f9 fancy_abort(char const*, int, char const*)
???:0

Preprocessed source attached.

[Bug lto/100692] [11 Regression] ICE in fld_incomplete_type_of, at tree.c:5452

[luke at street dot dev via Gcc-bugs]

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

--- Comment #1 from Luke Street  ---
Preprocessed source was too large to attach, so here's a GitHub gist:

https://gist.githubusercontent.com/encounter/03ecf9a70a225970f8485d3e89dff432/raw/bac21e49cb0f6be88cb7cf5fa80664a0f62b7748/ice_fld_incomplete_type_of.cpp

[Bug c++/100829] New: ICE with type that can't be determined

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 100829
   Summary: ICE with type that can't be determined
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

Following code causes an ICE:

template
auto e = e;
template
auto e = 0;

auto r = e;


This goes back to GCC 10.

[Bug c++/92105] [8/9/10 Regression] decltype(decltype(decltype)) prints exponential number of repeated errors

[llvm at rifkin dot dev via Gcc-bugs]

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

Jeremy R.  changed:

   What|Removed |Added

 CC||llvm at rifkin dot dev

--- Comment #6 from Jeremy R.  ---
Hey Jonathan, this is one of the most exciting bugs I've seen in gcc. This is a
little off-topic and I know the post is years old but:

Some folks and I have been doing a golf challenge to create the shortest
program which emits >1000 lines of error messages on gcc (version 8 or greater,
-fmessage-length not allowed). The previous best was a recursive template:
templateF(){F}k(){F<1>}, 43 characters, but this bug allows
us to beat that with just:
#define d decltype
d(d(d(d(d

[Bug c++/101213] New: Improve support for decltype(std)

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 101213
   Summary: Improve support for decltype(std)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

Gcc treats decltype(std) as an integer. It only works in some situations
though:

// OK
decltype(std) a;
static_assert(std::is_same::value);

// Not OK
static_assert(std::is_same::value);

// OK
decltype(std) a;
using b = decltype(a);
using c = b;

// Not OK
using a = decltype(std);
using b = a;

decltype(std) foo(int a) {} // OK
auto foo() -> decltype(std) {} // OK
void foo(decltype(std) a) {} // Not OK

// Not OK
std::vector v;

This bug is hilarious please improve support for it and make it a feature :)
It's invaluable for code bowling and nerd sniping.

[Bug c++/101213] Improve support for decltype(std)

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #2 from Jeremy R.  ---
(In reply to Jonathan Wakely from comment #1)
> This is just how GCC recovers from a bad parse, so that it can attempt to
> continue and give diagnostics for the rest of the code. An invalid type in
> certain declaration contexts is replaced with 'int'. Often it does more harm
> than good, because you get errors about int::foo being invalid because it's
> not a class type (which is true, but then it wasn't int in the original
> code!)
> 
> I've sometimes wondered whether it would be better to use an invented,
> incomplete class type as the default instead of int. On balance, most
> un-parseable types are probably classes, not fundamental types.

That's super cool, thanks for the insight into why decltype(std) is replaced
with int in the first place. Is the substitution but lack of diagnostic
intentional in a case like this https://godbolt.org/z/K91j35rTs? The lack of
diagnostic is of course appreciated for code bowling :)

What's the reason why this substitution is only made in certain contexts?

[Bug target/101215] New: Using non-standard custom linker with -fuse-ld

[freesoftware at logarithmus dot dev via Gcc-bugs]

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

Bug ID: 101215
   Summary: Using non-standard custom linker with -fuse-ld
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freesoftware at logarithmus dot dev
  Target Milestone: ---

Hello. I'd like to have an ability to use custom linkers with gcc.
Unfortunately gcc's `-fuse-ld` option only supports fixed set of linkers: ld,
gold & lld. On the other hand, clang supports passing path to linker's binary
with `-fuse-ld`.

My specific use case is novell `mold` linker: https://github.com/rui314/mold
I know that I can use mold like this: `mold -run gcc `. But it
works by intercepting system calls and changing all calls to `ld` with `mold`.
It looks kinda hacky to be honest. So I think the best solution would be to
implement custom linkers support into gcc.

I've never worked with gcc codebase before, so I'll appreciate any guidance
about implementing this feature.

[Bug driver/93645] Support Clang 12 --ld-path=

[freesoftware at logarithmus dot dev via Gcc-bugs]

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

--- Comment #9 from Artur Sinila  ---
What's a blocker for this bug? What should be improved in the patch in order
for it to be accepted?

[Bug fortran/108621] New: [12 regression]: bind(c) pointer array spurious maybe-uninitialized warning

[michael at scivision dot dev via Gcc-bugs]

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

Bug ID: 108621
   Summary: [12 regression]: bind(c) pointer array spurious
maybe-uninitialized warning
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael at scivision dot dev
  Target Milestone: ---

GCC 12 introduced a new regression--spurious Wmaybe-initialized warnings from
example code compiled with:

gfortran -Wall -c main.f90

```
program demo
use, intrinsic :: iso_c_binding, only : c_int
implicit none

interface
subroutine fun(f_p) bind(c)
import c_int
integer(c_int), pointer, intent(out) :: f_p(:)
end subroutine
end interface

integer(c_int), pointer :: f(:)

nullify(f)
call fun(f)

end program
```

emits spurious warnings not seen in GCC < 12:

```
   18 | call fcpoint(f)
  | ^
Warning: 'f.dim[idx.1_32].lbound' may be used uninitialized
[-Wmaybe-uninitialized]

   14 | integer(c_int), pointer :: f(:)
  | ^
note: 'f' declared here

   18 | call fcpoint(f)
  | ^
Warning: 'f.dim[idx.1_32].ubound' may be used uninitialized
[-Wmaybe-uninitialized]

   14 | integer(c_int), pointer :: f(:)
  | ^
note: 'f' declared here

   18 | call fcpoint(f)
  | ^
Warning: 'f.dim[idx.1_32].lbound' may be used uninitialized
[-Wmaybe-uninitialized]

   14 | integer(c_int), pointer :: f(:)
  | ^
note: 'f' declared here

   18 | call fcpoint(f)
  | ^
Warning: 'f.dim[idx.1_32].stride' may be used uninitialized
[-Wmaybe-uninitialized]

   14 | integer(c_int), pointer :: f(:)
  | ^
note: 'f' declared her
```

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

[john at drouhard dot dev via Gcc-bugs]

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

--- Comment #5 from John Drouhard  ---
Has there been any progress toward resolution for this? We've been trying to
use coroutines in our project but we require LTO for performance reasons, so
this is holding us back.

[Bug tree-optimization/109044] New: Missed fold for (n - 1) / 2 when n is odd

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 109044
   Summary: Missed fold for (n - 1) / 2 when n is odd
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

int foo(unsigned n) {
if(n % 2 == 0) __builtin_unreachable();
return (n - 1) / 2;
}

int bar(unsigned n) {
return n >> 1;
}



foo(unsigned int):
lea eax, [rdi-1]
shr eax
ret
bar(unsigned int):
mov eax, edi
shr eax
ret


https://godbolt.org/z/3G7enYdnM

https://alive2.llvm.org/ce/z/m3qbdN

[Bug c++/109096] New: __has_unique_object_representations does not account for unnamed bitfield

[gcc at jonathanmueller dot dev via Gcc-bugs]

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

Bug ID: 109096
   Summary: __has_unique_object_representations does not account
for unnamed bitfield
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at jonathanmueller dot dev
  Target Milestone: ---

__has_unique_object_representations should return false for types that contain
an unnamed bit field of non-zero bit-width, since that introduces padding bits;
yet it doesn't:

```
#include 
#include 

struct foo
{
int member : 8;
// We explitly introduce 24 padding bits here.
int : 24;

bool operator==(const foo&) const = default;
};

// Yet this assertion passes?!
static_assert(__has_unique_object_representations(foo));

// But we clearly don't have unique object representations:
int main()
{
// Create two objects with different object representations.
foo a, b;
std::memset(&a, 0xFF, sizeof(foo));
std::memset(&b, 0x99, sizeof(foo));

// Make all members identical to give them the same value representation.
a.member = 0;
b.member = 0;
// This passes; they have the same value representation.
assert(a == b);

// But this fails; they don't have unique object representations!
assert(std::memcmp(&a, &b, sizeof(foo)) == 0);
}
```

https://godbolt.org/z/Y4GzqYE8s

[Bug c++/109096] __has_unique_object_representations does not account for unnamed bitfield

[gcc at jonathanmueller dot dev via Gcc-bugs]

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

--- Comment #1 from Jonathan Müller  ---
Sorry, wrong godbolt link: https://godbolt.org/z/f1fGExsr7

[Bug libstdc++/109111] Definition of repeat_view::_Iterator has wrong template-head

[john at drouhard dot dev via Gcc-bugs]

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

--- Comment #1 from John Drouhard  ---
https://godbolt.org/z/csozden6e

example of gcc not diagnosing mismatched requires clauses (and clang correctly
doing so).

[Bug c++/104702] New: [12 Regression] False positive -Wunused-value warning with -fno-exceptions

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 104702
   Summary: [12 Regression] False positive -Wunused-value warning
with -fno-exceptions
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

I'm getting a false positive "value computed is not used" warning on trunk iff
I specify -fno-exceptions.

Godbolt link: https://godbolt.org/z/h7ssrza8Y

$ cat unused.cpp
struct FlyString {
  FlyString(char const*);
  ~FlyString();
};

struct Array { FlyString __data[1]; };

void frobnicate(Array&);

int main() {
Array s_reserved_words { "" };
frobnicate(s_reserved_words);
}

$ g++ -fno-exceptions -Wunused-value unused.cpp
unused.cpp: In function 'int main()':
unused.cpp:11:33: warning: value computed is not used [-Wunused-value]
   11 | Array s_reserved_words { "" };
  | ^

[Bug c++/105130] New: gcc does not warn about unused return value of last expression of statement expr

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 105130
   Summary: gcc does not warn about unused return value of last
expression of statement expr
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

Created attachment 52739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52739&action=edit
Proposed patch

The following code does not cause a warning about the return value of the foo()
function being ignored:

$ cat unused.cc
[[nodiscard]] int foo();

int main() {
({ foo(); });
}

$ g++ -Wunused-value -std=c++20 unused.cc
[no warnings]

The issue seems to be that CLEANUP_POINT_EXPR and STATEMENT_LIST -- which are
what statement expressions are turned into -- are not handled in
convert_to_void() (cp/cvt.cc).

The attached patch resolves the issue, but as a newbie to hacking on gcc, I
can't evaluate if it has any unintended consequences.

[Bug c++/105130] gcc does not warn about unused return value of last expression of statement expr

[dani at danielbertalan dot dev via Gcc-bugs]

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

--- Comment #1 from Daniel Bertalan  ---
Created attachment 52740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52740&action=edit
Proposed patch #2

Actually, my proposed patch was definitely incorrect. It didn't allow me to
circumvent the warning by explicitly casting to void. This new version fixes
that issue.

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #8 from Vineet Gupta  ---
Created attachment 53332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53332&action=edit
Full reload output

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #9 from Vineet Gupta  ---
The redundant Insn 2660 is reload inserted for Insn 1717

 1717: r1871:DI=frame:DI+r2813:DI
Inserting insn reload before:
 2660: r2814:DI=0x1000
 2661: r2813:DI=r2814:DI-0x7e8
  REG_EQUAL 0x818


Insn 1717 in turn is reload inserted for Insn 82

   82: r1870:DI=r1871:DI+r222:DI
  REG_DEAD r222:DI
Inserting insn reload before:
 1717: r1871:DI=frame:DI+0x28
Inserting insn reload after:
 1716: r223:DI=r1870:DI


Insn 82 comes from 253r.expand

(insn 80 79 81 5 (set (reg:DI 222 [ _282 ])
(ashift:DI (reg:DI 74 [ g.1_3 ])
(const_int 7 [0x7]))) "rhs-cred.cc":44:29 -1
 (nil))
(insn 81 80 82 5 (set (reg:DI 884)
(plus:DI (reg/f:DI 67 virtual-stack-vars)
(const_int -8 [0xfff8]))) "rhs-cred.cc":44:29 -1
 (nil))
(insn 82 81 83 5 (set (reg/f:DI 223 [ _283 ])
(plus:DI (reg:DI 884)
(reg:DI 222 [ _282 ]))) "rhs-cred.cc":44:29 -1
 (nil))


Stepping thru lra-constraints.cc, curr_insn_transform () is called twice for
Insn 1717 and in the 2nd call (lra_constraints_iter == 4), operand is required
to have a reload (goal_alt_win[2]==false) which leads to lra_emit_move () ->
riscv_move_integer ()

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #10 from Vineet Gupta  ---
Created a small test case which emulates generation of 2 split consts. 

void foo(void)
{
bar(2072, 2096);
}

253r.expand has 4 instructions: Pair of LI 4096 + ADDI for each const.
260r.fwprop1 prunes out the redundant insn 7. However it runs before
300r.reload. The original issue is reload inserting the insns so no way to
prune these out.

---253r.expand
(insn 5 2 6 2 (set (reg:DI 72)
(const_int 4096 [0x1000])) "const-load.c":5:2 -1
 (nil))
(insn 6 5 7 2 (set (reg:DI 11 a1)
(plus:DI (reg:DI 72)
(const_int -2000 [0xf830]))) "const-load.c":5:2 -1
 (expr_list:REG_EQUAL (const_int 2096 [0x830])
(nil)))
(insn 7 6 8 2 (set (reg:DI 73)
(const_int 4096 [0x1000])) "const-load.c":5:2 -1
 (nil))
(insn 8 7 9 2 (set (reg:DI 10 a0)
(plus:DI (reg:DI 73)
(const_int -2024 [0xf818]))) "const-load.c":5:2 -1
 (expr_list:REG_EQUAL (const_int 2072 [0x818])
(nil)))

---300r.reload
(insn 5 2 6 2 (set (reg:DI 10 a0 [72])
(const_int 4096 [0x1000])) "const-load.c":5:2 139 {*movdi_64bit}
 (expr_list:REG_EQUIV (const_int 4096 [0x1000])
(nil)))
(insn 6 5 8 2 (set (reg:DI 11 a1)
(plus:DI (reg:DI 10 a0 [72])
(const_int -2000 [0xf830]))) "const-load.c":5:2 4
{adddi3}
 (expr_list:REG_EQUAL (const_int 2096 [0x830])
(nil)))
(insn 8 6 9 2 (set (reg:DI 10 a0)
(plus:DI (reg:DI 10 a0 [72])
(const_int -2024 [0xf818]))) "const-load.c":5:2 4
{adddi3}
 (expr_list:REG_EQUAL (const_int 2072 [0x818])
(nil)))

[Bug c/106439] New: RISC-V suboptimal codegen for large constants

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Bug ID: 106439
   Summary: RISC-V suboptimal codegen for large constants
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineet.gupta at linux dot dev
CC: cmuellner at linux dot com, kito at gcc dot gnu.org,
wilson at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

As part of experiments to create smaller tests for 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265, ran into a slightly
different issue involving large constants (> S12) and stack access.

RISC-V codegen for stack accesses with offsets > S12 is terrible. 

long foo(void)
{
long a[512];
return a[500];
}

output for rv64 -O2 : gcc trunk as of June 14 (commit 6abe341558ab)

foo:
li  t0,-4096
li  a5,4096
add sp,sp,t0
addia5,a5,-96
add a5,a5,sp
li  t0,4096
ld  a0,0(a5)
add sp,sp,t0
jr  ra

Compare the same code to aarch64:

foo:
sub sp, sp, #4096
ldr x0, [sp, 4000]
add sp, sp, 4096

Of course part of the problem is limited S12 offset encoding in RV LD, but the
compiler can definitely do much better.

[Bug tree-optimization/106727] New: Missed fold / canonicalization for checking if a number is a power of 2

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 106727
   Summary: Missed fold / canonicalization for checking if a
number is a power of 2
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

These two are equivalent but generate different code:

bool foo(unsigned n) {
return std::popcount(n) <= 1;
}
bool bar(unsigned n) {
return (n & (n - 1)) == 0;
}

https://godbolt.org/z/crrxnfWo7

For systems that don't have popcount instructions it would be very beneficial
to transform foo -> bar. For systems that do have popcount instructions it
still would be beneficial to canonicalize the two.

[Bug c++/107178] New: Diagnosis for colon vs semi-colon in a member function declaration

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 107178
   Summary: Diagnosis for colon vs semi-colon in a member function
declaration
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The following code emits a poor diagnosis:

struct T {};

struct S {
T foo():
};

:4:7: error: bit-field 'T S::foo()' has non-integral type 'T (S::)()'
4 | T foo():
  |   ^~~

https://godbolt.org/z/39ME3K6TE

At least for the case of a member function declaration, a better diagnosis
would probably be ideal.


For T foo():, clang emits:

:5:1: error: expected '(' or '{'
};
^


For T foo:, clang emits:

:5:1: error: expected expression
};
^
:5:3: error: expected '}'
};
  ^
:3:10: note: to match this '{'
struct S {
 ^
:5:3: error: expected ';' after struct
};
  ^
  ;

[Bug c++/107178] Diagnosis for colon vs semi-colon in a member function declaration

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #2 from Jeremy R.  ---
The easy solution is to mention both the bitfield and "hey maybe you meant to
use a ;"

[Bug ipa/103819] New: [12 Regression] ICE in redirect_callee, at cgraph.c:1389 with __attribute__((flatten)) and -O2

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 103819
   Summary: [12 Regression] ICE in redirect_callee, at
cgraph.c:1389 with __attribute__((flatten)) and -O2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52052&action=edit
Test case

Link to Compiler Explorer: https://godbolt.org/z/5bE9zsvfh

The following code fails to compile with gcc 12 (commit
61e53698a08dc1d9a54d785218af687a6751c1b3):

===
template  struct Optional {
  ~Optional() {
if (m_has_value)
  value();
  }
  T value();
  void release_value() { m_has_value = false; }
  bool m_has_value;
};
struct Completion {
  Optional m_target;
};
struct ThrowCompletionOr {
  void release_error() { m_throw_completion.release_value(); }
  Optional m_throw_completion;
} __trans_tmp_1;

__attribute__((flatten)) void value_to_numeric() {
  auto _temporary_result(__trans_tmp_1);
  _temporary_result.release_error();
}
===

The issue is both present in Compiler Explorer's trunk compiler, and in my
local build that has SerenityOS-specific patches applied. The error, as
reported by the latter, is:

$ g++ -O2 -v -save-temps -c repro.ii:
Using built-in specs.
COLLECT_GCC=../../Toolchain/Local/gcc-12/i686/bin/i686-pc-serenity-g++
Target: i686-pc-serenity
Configured with: ../../Tarballs/gcc/configure
--prefix=/home/dani/Projects/contributions/serenity/Toolchain/Local/gcc-12/i686
--target=i686-pc-serenity
--with-sysroot=/home/dani/Projects/contributions/serenity/Build/i686/Root
--disable-nls --with-newlib --enable-shared --enable-languages=c,c++
--enable-default-pie --enable-lto --enable-threads=posix
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211223 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-v' '-save-temps' '-c' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'

/home/dani/Projects/contributions/serenity/Toolchain/Local/gcc-12/i686/libexec/gcc/i686-pc-serenity/12.0.0/cc1plus
-fpreprocessed repro.ii -ftls-model=initial-exec -fPIC
-fno-semantic-interposition -quiet -dumpbase repro.ii -dumpbase-ext .ii
-mtune=generic -march=pentiumpro -O2 -version -ftls-model=initial-exec -o
repro.s
GNU C++17 (GCC) version 12.0.0 20211223 (experimental) (i686-pc-serenity)
compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++17 (GCC) version 12.0.0 20211223 (experimental) (i686-pc-serenity)
compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 42faffcdcc480dea6a6ccc95e1bcf344
during IPA pass: inline
repro.ii:21:1: internal compiler error: in redirect_callee, at cgraph.c:1389
   21 | }
  | ^
0x761a99 cgraph_edge::redirect_callee(cgraph_node*)
../../../Tarballs/gcc/gcc/cgraph.c:1389
0xf0a8af redirect_to_unreachable
../../../Tarballs/gcc/gcc/ipa-fnsummary.c:260
0xf0a8af edge_set_predicate
../../../Tarballs/gcc/gcc/ipa-fnsummary.c:284
0xf0ad3d remap_edge_summaries
../../../Tarballs/gcc/gcc/ipa-fnsummary.c:4037
0xf0e246 ipa_merge_fn_summary_after_inlining(cgraph_edge*)
../../../Tarballs/gcc/gcc/ipa-fnsummary.c:4200
0xf23cd5 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
../../../Tarballs/gcc/gcc/ipa-inline-transform.c:504
0x1eb2477 flatten_function
../../../Tarballs/gcc/gcc/ipa-inline.c:2413
0x1eb69eb ipa_inline
../../../Tarballs/gcc/gcc/ipa-inline.c:2736
0x1eb69eb execute
../../../Tarballs/gcc/gcc/ipa-inline.c:3148

[Bug tree-optimization/103858] New: [12 Regression] strlen() implementation is optimized into a call to strlen() at -O2, causing infinite recursion

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 103858
   Summary: [12 Regression] strlen() implementation is optimized
into a call to strlen() at -O2, causing infinite
recursion
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

Compiler Explorer link: https://godbolt.org/z/h419G55P4

The following function is folded into a call to strlen() by gcc 12 (commit
61e53698a08dc1d9a54d785218af687a6751c1b3) at -O2, unless -fno-builtin-strlen is
specified. This function is taken from a (naive) libc implementation, where
this is the only definition of strlen(), so it ends up calling itself
recursively, overflowing the stack.

#include 

size_t strlen(const char* str)
{
size_t len = 0;
while (*(str++))
++len;
return len;
}

x86_64 assembly output:
strlen:
cmp BYTE PTR [rdi], 0
je  .L3
lea rax, [rdi+1]
sub rsp, 8
mov rdi, rax
callstrlen
add rsp, 8
add rax, 1
ret
.L3:
xor eax, eax
ret

My workaround is to compile our libc with -ffreestanding/-fno-builtin, but I'd
like to avoid that, as it might prevent other (valid) optimizations from being
performed on our code.

[Bug ipa/103819] [10/11/12 Regression] ICE in redirect_callee, at cgraph.c:1389 with __attribute__((flatten)) and -O2 since r11-7940-ge7fd3b783238d034

[dani at danielbertalan dot dev via Gcc-bugs]

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

--- Comment #3 from Daniel Bertalan  ---
Here's an even smaller test case (https://gcc.godbolt.org/z/ee9GceMx3):

===
template  struct Optional {
~Optional() {
if (m_has_value)
value();
}
T value();
bool m_has_value{};
};
__attribute__((flatten)) int main(){
Optional> _temporary_result{};
return 0;
}
===

during IPA pass: inline
:12:1: internal compiler error: in redirect_callee, at cgraph.cc:1389
   12 | }
  | ^
0x215b739 internal_error(char const*, ...)
???:0
0x73b7e7 fancy_abort(char const*, int, char const*)
???:0
0xbe2bbe cgraph_edge::redirect_callee(cgraph_node*)
???:0
0xe6b781 ipa_merge_fn_summary_after_inlining(cgraph_edge*)
???:0
0xe85396 inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
???:0

[Bug c++/104284] New: [9/10/11/12 Regression] ICE: unexpected expression '' of kind implicit_conv_expr

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 104284
   Summary: [9/10/11/12 Regression] ICE: unexpected expression
'' of kind implicit_conv_expr
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

Godbolt link: https://godbolt.org/z/8bTPra5jK

The following code snippet causes an ICE on trunk (commit
3d41939c8799a51b1cd7f4610c06771bf6d52f15), and as far back as on 9.1 with
-fchecking=2:

---
struct EstablishedTiming {
char m_dmt_id{};
};

auto x = [](auto) { constexpr EstablishedTiming
established_timings3_bytes[]{{}}; };
---

ice1.ii: In lambda function:
ice1.ii:5:80: internal compiler error: unexpected expression '' of
kind implicit_conv_expr
5 | x = [](auto) { constexpr EstablishedTiming
established_timings3_bytes[]{{}}; };
  |
  ^

0x98a181 cxx_eval_constant_expression
gcc/cp/constexpr.cc:7493
0x99109b cxx_eval_store_expression
gcc/cp/constexpr.cc:5619
0x9860b4 cxx_eval_constant_expression
gcc/cp/constexpr.cc:6763
0x98a626 cxx_eval_outermost_constant_expr
gcc/cp/constexpr.cc:7707
0x98f770 fold_non_dependent_expr_template
gcc/cp/constexpr.cc:8066
0xb0de7f build_non_dependent_expr(tree_node*)
gcc/cp/pt.cc:28412
0xb6c547 finish_expr_stmt(tree_node*)
gcc/cp/semantics.cc:870
0xa2d933 get_temp_regvar(tree_node*, tree_node*)
gcc/cp/init.cc:4254
0xa2d933 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int,
vec**)
gcc/cp/init.cc:4477
0xa2f503 build_aggr_init(tree_node*, tree_node*, int, int)
gcc/cp/init.cc:2009
0x9d83ec build_aggr_init_full_exprs
gcc/cp/decl.cc:7053
0x9d83ec check_initializer
gcc/cp/decl.cc:7214
0x9fdc7f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
gcc/cp/decl.cc:8108
0xaf15df cp_parser_init_declarator
gcc/cp/parser.cc:22823
0xacb5e3 cp_parser_simple_declaration
gcc/cp/parser.cc:15286
0xacd2fd cp_parser_declaration_statement
gcc/cp/parser.cc:14367
0xacdaeb cp_parser_statement
gcc/cp/parser.cc:12452
0xace9bd cp_parser_statement_seq_opt
gcc/cp/parser.cc:12856
0xacea98 cp_parser_compound_statement
gcc/cp/parser.cc:12808
0xacf797 cp_parser_function_body
gcc/cp/parser.cc:25062

[Bug fortran/104391] New: Gfortran 9 regression with bind(C) and allocatable or pointer attribute

[michael at scivision dot dev via Gcc-bugs]

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

Bug ID: 104391
   Summary: Gfortran 9 regression with bind(C) and allocatable or
pointer attribute
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael at scivision dot dev
  Target Milestone: ---

The `bind(C)` on a procedure appears to break `pointer` and `allocatable`
attributes of a variable with regard to index start. Specifically, on exiting a
procedure with `bind(c)`, the variable(s) have their indices shifted to
zero-based.

example that works with GCC <= 8.5 and GCC 12 (broken for GCC 9, 10, 11).

```
program test_bounds
use iso_fortran_env, only : error_unit
implicit none

real, allocatable :: a(:)
integer :: L1,L2, U1,U2
allocate(a(1:2))

L1 = lbound(a,1)
U1 = ubound(a,1)
call c_bounder(a)
L2 = lbound(a,1)
U2 = ubound(a,1)

if (L1 /= L2 .or. U1 /= U2) then
  write(error_unit, '(a,2i2,a,2i2)') 'FAIL: bounds changed before/after
lower:', L1,L2, " upper: ", U1,U2
  error stop
endif

print '(a)', "bounds check OK"

contains

subroutine c_bounder(a) bind(c)
real,  intent(inout) :: a(:)
end subroutine c_bounder

end program
```

[Bug tree-optimization/103072] New: Folding common switch code

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 103072
   Summary: Folding common switch code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

In the following code, GCC can optimize foo but not bar:

void foo(int x) {
switch(x) {
case 1: func1(); break;
case 2: func1(); break;
case 3: func1(); break;
case 4: func1(); break;
case 5: func1(); break;
default: __builtin_unreachable();
}
}

void bar(int x) {
switch(x) {
case 1: func2(x); break;
case 2: func2(x); break;
case 3: func2(x); break;
case 4: func2(x); break;
case 5: func2(x); break;
default: __builtin_unreachable();
}
}

https://godbolt.org/z/3eqnG71f5 (LLVM optimizes both)

[Bug tree-optimization/103072] Folding common switch code

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #3 from Jeremy R.  ---
(In reply to Jakub Jelinek from comment #1)
> So maybe the switchconv pass could be
> improved not to do just the linear etc. expression handling, but also
> consider code sequences that are the same except for the linear expression
> somewhere in it and turn it back into use of a temporary.

I think this is how LLVM approaches it. It might be nice to be able to fold
switches where it's not a linear sequence too, such as:

void bar(int x) {
switch(x) {
case 1: func(x); break;
case 4: func(x); break;
case 7: func(x); break;
case 3: func(x); break;
case 9: func(x); break;
default: __builtin_unreachable();
}
}

LLVM is able to fold this out of a switch though it also struggles due to the
early constant propagation and doesn't fold this perfectly.

[Bug tree-optimization/103559] New: Can't optimize away < 0 check on sqrt

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 103559
   Summary: Can't optimize away < 0 check on sqrt
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

For a simple invocation of sqrt, gcc inserts a < 0 check to set math errno if
needed. E.g.

float f(float x) {
return sqrt(x);
}

Is generated as

f(float):
vxorps  xmm1, xmm1, xmm1
vucomissxmm1, xmm0
ja  .L10
vsqrtss xmm0, xmm0, xmm0
ret
.L10:
jmp sqrtf


Unfortunately, this check is still present when the GCC is able to prove that x
is non-negative:

float f(float x) {
if(x < 0) [[unlikely]] {
__builtin_unreachable();
} else {
return sqrt(x);
}
}

LLVM suffers from the same problem, even with __builtin_assume().
https://godbolt.org/z/ddcoMj3oz

This is a very common pattern, and I'd imagine the argument for sqrt is often
able to be shown to be positive. This would be a helpful enhancement.

[Bug c/103738] New: No warning when setting deprecated fields using designated initializers

[gcc at haasn dot dev via Gcc-bugs]

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

Bug ID: 103738
   Summary: No warning when setting deprecated fields using
designated initializers
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at haasn dot dev
  Target Milestone: ---

Created attachment 52009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52009&action=edit
No deprecation warning produced

Deprecated attributes on struct members are ignored when setting those fields
using designated initializers. The attached example should produce a warning,
but it does not.

Contrast the following alternative code:

struct foo foo;
foo.bar = 5;

This does produce a deprecation warning as expected:

no_warning.c: In function ‘main’:
no_warning.c:8:5: warning: ‘bar’ is deprecated [-Wdeprecated-declarations]
8 | foo.bar = 5;
  | ^~~
no_warning.c:2:9: note: declared here
2 | int bar __attribute((deprecated));
  | ^~~

[Bug c/103738] No warning when setting deprecated fields using designated initializers

[gcc at haasn dot dev via Gcc-bugs]

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

Niklas Haas  changed:

   What|Removed |Added

  Attachment #52009|no_warning.c|warning.c
   filename||
  Attachment #52009|No deprecation warning  |Deprecation warning
description|produced|produced

--- Comment #1 from Niklas Haas  ---
Comment on attachment 52009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52009
Deprecation warning produced

Accidentally attached the wrong version of the file, fixing.

[Bug c/103738] No warning when setting deprecated fields using designated initializers

[gcc at haasn dot dev via Gcc-bugs]

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

--- Comment #2 from Niklas Haas  ---
Created attachment 52010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52010&action=edit
No deprecation warning produced

[Bug tree-optimization/103765] New: Missed arithmetic simplification for multiplication + division

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 103765
   Summary: Missed arithmetic simplification for multiplication +
division
   Product: gcc
   Version: 12.0
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 following code is optimized strangely:

int foo(int x) {
return (x * 72) / 3;
}
int bar(int x) {
x *= 72;
x /= 3;
return x;
}

foo(int):
lea eax, [rdi+rdi*2]
sal eax, 3
ret
bar(int):
lea edx, [rdi+rdi*8]
sal edx, 3
movsx   rax, edx
imulrax, rax, 1431655766
sar edx, 31
shr rax, 32
sub eax, edx
ret

https://godbolt.org/z/13PxxsM8G

For some foo is simplified to return x * 24; but bar is not. It appears the
transformation is done before transformation to gimple.

Another case:

int foo(int x) {
return (x * 64) / 8;
}
int bar(int x) {
x *= 64;
x /= 8;
return x;
}

foo(int):
lea eax, [0+rdi*8]
ret
bar(int):
sal edi, 6
lea eax, [rdi+7]
cmovns  eax, edi
sar eax, 3
ret

https://godbolt.org/z/vfG1TP7oG

Even with powers of 2 (and thus shift operations down the line), it is not
transformed.

This would be a good enhancement, and I'd also be interested to learn why this
strange behavior is occurring.

[Bug tree-optimization/102232] New: Missed arithmetic fold

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 102232
   Summary: Missed arithmetic fold
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

LLVM optimizes bar into tgt here but not foo.

https://godbolt.org/z/nhEjaoanx

int foo(int a, int b) {
return b * (1 + a / b) - a;
}
int bar(int a, int b) {
return b * (a / b) + b - a;
}
int tgt(int a, int b) {
return b - a % b;
}

LLVM appears to miss this too.

[Bug tree-optimization/102232] Missed arithmetic fold

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #1 from Jeremy R.  ---
Correction on first line: *GCC optimizes bar into tgt here but not foo.
Pardon my sloppy copy-paste from my bug report over on LLVM's bugzilla!

[Bug c++/107363] New: Wrong caret location for "redundant move in return statement"

[dani at danielbertalan dot dev via Gcc-bugs]

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

Bug ID: 107363
   Summary: Wrong caret location for "redundant move in return
statement"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

The caret in the following "redundant move in return statement" warning does
not point to a return statement (https://godbolt.org/z/4v7Y9G9e3):

```
#include 

template 
struct Optional {
  T &value();
  T release_value() {
T released_value = std::move(value());
return released_value;
  }
};

struct Foo {};
void test(Optional o) { o.release_value(); }
```

:7:7: warning: redundant move in return statement [-Wredundant-move]
7 | T released_value = std::move(value());
  |   ^~
:7:7: note: remove 'std::move' call

As an aside, it's a bit annoying to have this warning when the moved type
depends on a template parameter in library code. We are forced to either
silence this warning with a #pragma, or use concepts to have a variant of the
release_value method that does not call std::move for const-qualified T.

[Bug target/105666] New: RISC-V 507.cactuBSSN_r build has costly FMV instructions

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Bug ID: 105666
   Summary: RISC-V 507.cactuBSSN_r build has costly FMV
instructions
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineet.gupta at linux dot dev
  Target Milestone: ---

Created attachment 53001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53001&action=edit
Test case to generate FMV.d.x instructions

SPEC2017 FP benchmark 507.cactu: ML_BSSN_Advect.cc:ML_BSSN_Advect_Body() has
really ugly code causing high register pressure and ensuing spills of both FP
and int register. Current riscv TARGET_REGISTER_MOVE_COST lacking any cost
considerations, resorts to fp <--> int mov as opposed to spilling to stack.

|   fmv.d.x fa5,s9  # PDupwindNthSymm2Xt1, PDupwindNthSymm2Xt1
| .LVL325:
|   ld  s9,184(sp)  # _12469, %sfp
| ...
| .LVL339:
|   fmv.x.d s4,fa5  # PDupwindNthSymm2Xt1, PDupwindNthSymm2Xt1

The FMV.d.x / FMV.x.d instructions could be costly on certain
micro-architectures and thus needs to be made tunable.

Test case attached: ripped off of existing
gcc/testsuite/gcc.c-torture/execute/pr28982a.c

[Bug target/105666] RISC-V 507.cactuBSSN_r build has costly FMV instructions

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||vineet.gupta at linux dot dev

--- Comment #1 from Vineet Gupta  ---
Created attachment 53002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53002&action=edit
proposed fix

[Bug target/105666] RISC-V 507.cactuBSSN_r build has costly FMV instructions

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #3 from Vineet Gupta  ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595428.html

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org,
   ||palmer at gcc dot gnu.org,
   ||vineet.gupta at linux dot dev

--- Comment #7 from Vineet Gupta  ---
Failing for riscv as well !

[Bug target/105666] RISC-V 507.cactuBSSN_r build has costly FMV instructions

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Vineet Gupta  changed:

   What|Removed |Added

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

--- Comment #4 from Vineet Gupta  ---
Commited by Kito.

commit b646d7d279ae0c0d35564542d09866bf3e8afac0
Author: Vineet Gupta 
Date:   Mon May 23 11:12:09 2022 -0700

RISC-V: Inhibit FP <--> int register moves via tune param

Under extreme register pressure, compiler can use FP <--> int
moves as a cheap alternate to spilling to memory.
This was seen with SPEC2017 FP benchmark 507.cactu:
ML_BSSN_Advect.cc:ML_BSSN_Advect_Body()

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Bug 105666 Summary: RISC-V 507.cactuBSSN_r build has costly FMV instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666

   What|Removed |Added

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

[Bug c++/105734] New: Regression: Incorrect "error: invalid use of 'auto'"

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 105734
   Summary: Regression: Incorrect "error: invalid use of 'auto'"
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The following code errors erroneously: https://godbolt.org/z/68vYYj8cc

A more minimal reproducible example is here: https://godbolt.org/z/f75Yx7K57.
Interestingly the error only manifests in conjunction with the explicit
destructor call.

This came up in conjunction with a library doing a lot of TMP shenanigans, I
will try to make a more minimal standalone reproducible example.

[Bug c++/105734] Regression: Incorrect "error: invalid use of 'auto'"

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #1 from Jeremy R.  ---
More minimal: https://godbolt.org/z/WcGab4W8T

[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #9 from Jeremy R.  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Jeremy R. from comment #1)
> > More minimal: https://godbolt.org/z/WcGab4W8T
> 
> The https://gcc.gnu.org/bugs very clearly says to provide the testcase
> *here* not only as a URL.

Thanks for letting me know

[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #10 from Jeremy R.  ---
One workaround in the general case is
decltype(ns::expression_decomposer(ns::expression_decomposer{} << expr)) =
libassert_decomposer = ns::expression_decomposer(ns::expression_decomposer{} <<
expr);

But this doesn't work if expr is a lambda.

A more general workaround is deferring the destructor to another function:

template void destruct(T& t) {
t.~T();
}
template 
void bar() {
auto m = hh::s(hh::s{}.h());
destruct(m);
}

[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #14 from Jeremy R.  ---
Thank you for the quick patch :)

[Bug c++/105811] New: Diagnostics for template class member call with missing template parameters can be improved

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 105811
   Summary: Diagnostics for template class member call with
missing template parameters can be improved
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The following code:

namespace ns {
template
struct S {
void foo() {}
};
}

void foo(ns::S<1>& s) {
s.ns::S::foo();
s.ns::S::~S();
}


Produces the following diagnostics:

: In function 'void foo(ns::S<1>&)':
:9:11: error: 'template > struct ns::S' used without
template arguments
9 | s.ns::S::foo();
  |   ^
:10:7: error: 'ns::S' is not a class member
   10 | s.ns::S::~S();
  |   ^~
Compiler returned: 1


https://godbolt.org/z/89fbbWhhh


I'm not sure why the destructor call is being treated differently, it would be
great if it would also specify the issue is missing template arguments.

[Bug target/106265] New: RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Bug ID: 106265
   Summary: RISC-V SPEC2017 507.cactu code bloat due to address
generation
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineet.gupta at linux dot dev
  Target Milestone: ---

SPEC2017 FP benchmark 507.cactu: ML_BSSN_RHS.cc:ML_BSSN_RHS_Body() has terrible
codegen. A recurring pattern which shows up in hotspot analysis is

  380a1a:   lui a6,0x1 # LI 4096 before linker relaxation
  380a1c:   addit2,sp,32
  380a20:   addia6,a6,-1192 # b58
  380a24:   add a6,a6,t2
  380a26:   sd  t4,0(a6)

The first 4 instructions help calculate the destination of the last SD
instruction. There were 27 such distinct instances in the hottest top block.

Part of this is the ISA not having a single instruction to do set a reg with
32-bit const and/or the limited addressing modes. However the compiler is not
helping either. All those 27 instances have the first instruction to set
register with 4096, sometimes with the register still being live with the exact
same value.

Using creduce I was able to create a small'ish (not ideal small) test case
which shows 14 instances of li ,4096

Built as riscv64-unknown-linux-gnu-g++ -O3 -static -ffast-math -funroll-loops
-march=rv64gc_zba_zbb_zbc_zbs -c  -std=c++03 

This is with trunk as of June 14 (commit 6abe341558ab)

--->8-
void *a();
int b, c, d, l, o, q;
double *e, *f, *p, *r, *s = 0;
long g, h, k;
double m, n, aa;
void y() {
  double ag, ai, aj, ap, ar, at, aw(01.0 / 0);
  double *am((double *)a);
  double *an;
  double *ao((double *)a());
  long av = sizeof(double) * g;
  for (; l; ++l)
for (int j = d; j < q; ++j)
  for (int i = 1; i < o; i++) {
long az = i * j + l;
double ba, bb, bc, bd, be, bf, bg, bh, bi, bj, bk, bl, bm, bn, bo, bp,
bq, br, bs, bv(-ar);
switch (b)
case 4: {
  *(double *)((char *)0)[2] = ((char *)0)[2];
  ba = ((char *)0)[k + av] + ((char *)0)[2] + ((char *)0)[k] +
   *(double *)((char *)0)[av] +
   ((char *)0)[av * 2] * ((char *)0)[k * av];
  bb = (&am[az])[h] + ((char *)0)[k * h] +
   ((char *)&am[az])[1] *
   (((char *)&am[az])[h] + *(&am)[h] + (&am[az])[k]) +
   (&am[az])[2] - ((char *)0)[h] + (&am[az])[k * av];
  bc = 4 * 8 + *(double *)&((char *)0)[2];
  bd = 4 * ((char *)0)[k + 1] +
   (&an[az])[k * h] * (((char *)0)[-1] + (&an[az])[k + h]) +
   8 * ((&an[az])[k * 2] + (&an[az])[av + h * -2] + (&an[az])[av] +
(&an[az])[av * 2 + h]) -
   8 * ((&an[az])[av * 2] + (&an[az])[k] + (&an[az])[av * 21] +
(&an[az])[av + h]) +
   *(&an)[h] - (&an[az])[av * 22] * (&an[az])[h] +
   (&an[az])[av * 2 * 2];
  bf = (&az)[0] * (((char *)&ao[az])[0] + ao[av] + (&ao[az])[av * 2] +
   *(double *)((char *)ao)[k]);
  bg = (&ao[az])[0] * *(&ao)[av] + *(&ao)[2];
  bh = *((char **)0)[av] * (&ao[az])[av - h] +
   ((char *)0)[1] * *(double *)((char *)0)[1] *
   (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
((char *)&ao[az])[av]) +
   *(&ao)[av * 2] - *(&ao)[k] - (&ao[az])[2] +
   (&ao[az])[k * av * 2];
  bi = *(&ao)[av * h] *
   (ao[h] + ((char *)0)[k * 2] + (&ao[az])[k * av] +
((char *)0)[21]) *
   (((char *)0)[h] + *(double *)((char *)0)[h * 2] +
*(double *)((char *)&ao[az])[k] + *(&ao)[h]) +
   *(&ao)[av * 22] - (&ao[az])[2 * h * 2] + ((char *)0)[22];
  bj = 4 * ((&ao[az])[av] + (&ao[az])[k * av * h] * (&ao[az])[av * -1]
+
(&ao[az])[av * h]) +
   ((&ao[az])[av * 12] + (&ao[az])[k] + ((char *)&ao)[h] +
(&ao[az])[av * 2 + h * 0]) *
   (((char *)0)[2] + *(double *)((char *)&ao[az])[av * 2] +
(&ao[az])[h] + (&ao[az])[av + h]) +
   (&ao[az])[av * 22] - ((char *)&ao[az])[h] - (&ao[az])[av * -2] +
   (&ao[az])[av + h * 2];
  bk = 8 * (&ap)[1];
  bm = ((char *)0)[1] * (&e[az])[2];
  bn = -(&az)[0];
  bo = (&e[az])[h] - (&e[az])[h * 2] * aw;
  bq = (&at)[h];
  br = 8 * 8 * ((&az)[1] + (&f[az])[-2] - (&f[az])[2]);
  bs = (&f[az])[h * -2] - (&f[az])[h * 2];
  n = ((char *)&s)[h * 2];
}
  double bt(e[az] * f[az] - at * at);
double bu(p[az] * at * az);
double bw(f[az] - p[az]);
double bx = 01.0 / 0;
double by = 01.0 / 0 * 0;
double ca;
double cb = -

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #1 from Vineet Gupta  ---
Analyzed a section of -dP dump where reg a2 is setup with exact same value
while being live.

rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2662 1711 76 (set (reg:DI 12 a2 [2816])
#(const_int 4096 [0x1000])) "rhs-cred.cc":42:47 139 {*movdi_64bit}
# (nil))
li  a2,4096 # tmp2816,  # 2662  [c=4 l=4] 
*movdi_64bit/1


rhs-cred.cc:39: bg = (&ao[az])[0] * *(&ao)[av] + *(&ao)[2];
#(insn 76 2662 2663 (set (reg/f:DI 20 s4 [orig:193 _239 ] [193])
#(plus:DI (reg:DI 13 a3 [1865])
#(reg:DI 20 s4 [orig:181 _224 ] [181]))) "rhs-cred.cc":39:40 4
{adddi3}
# (expr_list:REG_DEAD (reg:DI 13 a3 [1865])
#(nil)))
add s4,a3,s4# _224, _239, tmp1865   # 76[c=4 l=4] 
adddi3/0


rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2663 76 2660 (set (reg:DI 13 a3 [2815])
#(plus:DI (reg:DI 12 a2 [2816])
#(const_int -2024 [0xf818]))) "rhs-cred.cc":42:47 4
{adddi3}
# (expr_list:REG_DEAD (reg:DI 12 a2 [2816])
#(expr_list:REG_EQUAL (const_int 2072 [0x818])
#(nil
addia3,a2,-2024 #, tmp2815, tmp2816 # 2663  [c=4 l=4] 
adddi3/1

rhs-cred.cc:44: *(&ao)[av * 2] - *(&ao)[k] - (&ao[az])[2] +
#(insn 2660 2663 1710 (set (reg:DI 12 a2 [2814])
#(const_int 4096 [0x1000])) "rhs-cred.cc":44:29 139 {*movdi_64bit}
# (nil))
li  a2,4096 # tmp2814,  # 2660  [c=4 l=4] 
*movdi_64bit/1

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #2 from Vineet Gupta  ---
I've experimented with riscv_rtx_costs() setting cost of const to 1 as
discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596. This does
reduce the number of li 4096 instances to 10 (from 14), but the fragment pasted
above generates the same code.

# rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2660 1703 76 (set (reg:DI 28 t3 [2817])
#(const_int 4096 [0x1000])) "rhs-cred.cc":42:47 139 {*movdi_64bit}
# (nil))
li  t3,4096 # tmp2817,  # 2660  [c=1 l=4] 
*movdi_64bit/1


# rhs-cred.cc:39: bg = (&ao[az])[0] * *(&ao)[av] + *(&ao)[2];
#(insn 76 2660 2661 (set (reg/f:DI 16 a6 [orig:193 _239 ] [193])
#(plus:DI (reg:DI 12 a2 [1860])
#(reg:DI 16 a6 [orig:181 _224 ] [181]))) "rhs-cred.cc":39:40 4
{adddi3}
# (expr_list:REG_DEAD (reg:DI 12 a2 [1860])
#(nil)))
add a6,a2,a6# _224, _239, tmp1860   # 76[c=4 l=4] 
adddi3/0


# rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2661 76 2658 (set (reg:DI 12 a2 [2816])
#(plus:DI (reg:DI 28 t3 [2817])
#(const_int -2040 [0xf808]))) "rhs-cred.cc":42:47 4
{adddi3}
# (expr_list:REG_DEAD (reg:DI 28 t3 [2817])
#(expr_list:REG_EQUAL (const_int 2056 [0x808])
#(nil
addia2,t3,-2040 #, tmp2816, tmp2817 # 2661  [c=4 l=4] 
adddi3/1

# rhs-cred.cc:44: *(&ao)[av * 2] - *(&ao)[k] - (&ao[az])[2] +
#(insn 2658 2661 1702 (set (reg:DI 28 t3 [2815])
#(const_int 4096 [0x1000])) "rhs-cred.cc":44:29 139 {*movdi_64bit}
# (nil))

li  t3,4096 # tmp2815,  # 2658  [c=1 l=4] 
*movdi_64bit/1

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #3 from Vineet Gupta  ---
Digging into RTL dumps, the li instructions are introduced by 300r reload.

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #4 from Vineet Gupta  ---
Going back to first dump (upstream 6abe341558a w/o riscv_rtx_costs() adj): the
3rd instruction addi is marking a2 REG_DEAD at 315 cprop.hardreg

--->8 314r.rnreg

(insn 2663 2662 1714 3 (set (reg:DI 13 a3 [2815])
(plus:DI (reg:DI 12 a2 [2816])
(const_int -2024 [0xf818]))) "rhs-cred.cc":42:47 4
{adddi3}
 (expr_list:REG_EQUAL (const_int 2072 [0x818])
(nil)))


--->8 315r.cprop_hardreg

(insn 2663 2662 1714 3 (set (reg:DI 13 a3 [2815])
(plus:DI (reg:DI 12 a2 [2816])
(const_int -2024 [0xf818]))) "rhs-cred.cc":42:47 4
{adddi3}
 (expr_list:REG_DEAD (reg:DI 12 a2 [2816])
(expr_list:REG_EQUAL (const_int 2072 [0x818])
(nil

Not sure if that is the issue or the compiler just deducing that a2 is dead
given that the next instruction sets it up again was introduced much earlier in
300r.reload

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #7 from Vineet Gupta  ---
(In reply to Richard Biener from comment #5)
> So why do we even emit unsupported 'li 4096' and leave it to the linker to
> "optimize(?)"? 

li 4096 is really a pseudo-op - LUI is used to build 32-bit constants. For this
problem whether LI or LUI is used is just a detail.

> OTOH LRA rematerialization also could be the culprit, thinking rematerializing
> the constant is cheaper than spilling a register holding it.

Thx for the pointer. I tried disabling it -fno-lra-remat and it generates
exactly same code.

[Bug sanitizer/101300] New: -fsanitize=undefined suppresses -Wuninitialized

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 101300
   Summary: -fsanitize=undefined suppresses -Wuninitialized
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

The following code should produce a Wuninitialized warning.

int foo() {
int n = 4;
char b[n];
return b[2];
}

The compiler identifies the uninitialized access when compiled -Wall however it
does not when compiled with -Wall -fsanitize=undefined.

It does warn properly when compiled with -Wall -fsanitize=undefined -O1 (or any
optimization flag other than -O0).

https://godbolt.org/z/4rrKK5MYj

[Bug c++/101701] New: GCC optimization and code generation for if-else chains vs ternary chains vs a switch

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 101701
   Summary: GCC optimization and code generation for if-else
chains vs ternary chains vs a switch
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

I'm looking at an example of three equivalent functions implemented with
if-else chains, ternary chains, and a switch. Gcc is not compiling them
equivalently: https://godbolt.org/z/8cjGr7M7W.

For the if-else chain, gcc does not optimize away the jumps.
For the ternary chain, gcc does its codegen well.
For the switch, gcc also does its codegen well but there is an extra mov
instruction compared to the ternary chain.

I don't think it's idealistic to say these should compile equivalently - if
someone told me to prefer one over the other for performance reasons I'd
dismiss it as a micro-optimization.

Clang does not do this perfectly either at the moment.




This bug is probably miscategorized. I am not sure the correct category for it.

[Bug tree-optimization/101701] GCC optimization and code generation for if-else chains vs ternary chains vs a switch

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #4 from Jeremy R.  ---
I see with gcc x86_64 it does get the fold correct if another term (val == 5)
is added to the if-else chain: https://godbolt.org/z/TE15Wf1bo.

[Bug tree-optimization/101754] New: Missed fold for a/b*b

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 101754
   Summary: Missed fold for a/b*b
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

GCC is not optimizing the following (contrived) divisibility check
https://godbolt.org/z/1rEhYa8Ts.

bool foo(int a, int b) {
return a/b*b == a;
}
bool bar(int a, int b) {
return a%b == 0;
}

If GCC can fold a/b*b into a-a%b, it will be able to optimize properly the rest
of the way.

[Bug c++/101790] New: ICE on invalid regression in trunk: tree check: expected class 'type', have 'exceptional' (error_mark)

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 101790
   Summary: ICE on invalid regression in trunk: tree check:
expected class 'type', have 'exceptional' (error_mark)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

https://godbolt.org/z/9ozxbY5nh


template
concept a=;
int b=a<>;


:2:11: error: expected primary-expression before ';' token
2 | concept a=;
  |   ^
: In function 'void __static_initialization_and_destruction_0(int,
int)':
:3:7: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87
3 | int b=a<>;
  |   ^~~
0x1db4d89 internal_error(char const*, ...)
???:0
0x6a23c3 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xd76e33 useless_type_conversion_p(tree_node*, tree_node*)
???:0
0x136bdf6 tree_ssa_strip_useless_type_conversions(tree_node*)
???:0
0xdbe63f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc14ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdc0d3e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdbfe83 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdc12b0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdc12b0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdc43a8 gimplify_stmt(tree_node**, gimple**)
???:0
0xdc600e gimplify_body(tree_node*, bool)
???:0
0xdc6627 gimplify_function_tree(tree_node*)
???:0
0xbe2ad7 cgraph_node::analyze()
???:0
0xbe6f0d symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/101821] New: Redundant xor eax eax

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 101821
   Summary: Redundant xor eax eax
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

Gcc is generating an unnecessary and redundant xor eax eax in the following
code

#include 
#include 
uint32_t pop(uint32_t n) {
return std::popcount(n);
}


pop(unsigned int):
xor eax, eax
popcnt  eax, edi
ret

https://godbolt.org/z/81o1Y6T5x

[Bug tree-optimization/101821] Redundant xor eax eax

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #1 from Jeremy R.  ---
This happens with __builtin_popcount as well, not just std::popcount. This
appears to have started in GCC 4.9.2. https://godbolt.org/z/4dGWvT5zr

[Bug tree-optimization/101821] Redundant xor eax eax related to popcount intrinsic

[llvm at rifkin dot dev via Gcc-bugs]

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

Jeremy R.  changed:

   What|Removed |Added

Summary|Redundant xor eax eax   |Redundant xor eax eax
   |related to  |related to popcount
   |__builtin_popcount  |intrinsic

--- Comment #2 from Jeremy R.  ---
Seems to effect all

[Bug tree-optimization/101822] New: Codegen bug for popcount

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 101822
   Summary: Codegen bug for popcount
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

GCC cleverly optimizes the following loop into a popcount intrinsic:

uint32_t foo(uint32_t n) {
uint32_t count = 0;
while(n) {
n &= n - 1;
count++;
}
return count;
}

But the generated assembly is highly redundant https://godbolt.org/z/nbGb13G5W:

foo(unsigned int):
xor eax, eax
xor edx, edx
popcnt  eax, edi
testedi, edi
cmove   eax, edx
ret

if(n == 0) __builtin_unreachable(); does seem to help the compiler's analysis.

It seems here the compiler is not realizing both the loop and popcnt intrinsic
are well-defined for n == 0. This is closely related to another bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101821.

[Bug target/101821] Redundant xor eax eax

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #6 from Jeremy R.  ---
Ah thank you @Andrew Pinski @Jakub Jelinek

[Bug target/101821] Redundant xor eax eax

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #7 from Jeremy R.  ---
Does the false dependency still apply to modern CPUs?

[Bug tree-optimization/101822] Codegen bug for popcount

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #1 from Jeremy R.  ---
Never mind, 101821 was invalid and the initial xor eax eax is by design (still
wondering whether this applies to new CPUs though). There is still a
discrepancy between this code and the __builtin_popcount code though.

[Bug target/101821] Redundant xor eax eax

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #9 from Jeremy R.  ---
Thank you for the resources and for your insight, it's much appreciated.
Is there interest in updating the intentional false-dependency logic to not
fire for architectures newer than cannonlake?

[Bug tree-optimization/101822] Codegen bug for popcount

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #3 from Jeremy R.  ---
Interestingly it's optimized correctly on -Os

[Bug target/114160] New: ICE in dwarf2out_frame_debug_cfa_offset RISCV thead-c906

[nop at unearthly dot dev via Gcc-bugs]

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

Bug ID: 114160
   Summary: ICE in dwarf2out_frame_debug_cfa_offset RISCV
thead-c906
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nop at unearthly dot dev
  Target Milestone: ---

Created attachment 57573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57573&action=edit
cvise produced reproduction case

Taking out -O2, -mcpu, or -fPIC out resolves the issue. Additionally, this
doesn't happen on -mtune=thead-c906

This does not happen on gcc 14

mu-loong ~ # gcc -v -O2 -mcpu=thead-c906 -fPIC GBZ.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-unknown-linux-gnu/13/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/configure
--host=riscv64-unknown-linux-gnu --build=riscv64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/riscv64-unknown-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include
--datadir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13
--mandir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/man
--infodir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include/g++-v13
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/riscv64-unknown-linux-gnu/13/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
13.2.1_p20240210 p13' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --with-abi=lp64d --disable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--with-zstd --without-isl --enable-default-pie --enable-default-ssp
--disable-fixincludes
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20240210 (Gentoo 13.2.1_p20240210 p13)
COLLECT_GCC_OPTIONS='-v' '-O2' '-mcpu=thead-c906' '-fPIC'
'-march=rv64imafdc_zicsr_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync'
'-mabi=lp64d' '-misa-spec=20191213'
'-march=rv64imafdc_zicsr_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync'
'-dumpdir' 'a-'
 /usr/libexec/gcc/riscv64-unknown-linux-gnu/13/cc1 -quiet -v -imultilib . GBZ.c
-quiet -dumpdir a- -dumpbase GBZ.c -dumpbase-ext .c -mcpu=thead-c906
-march=rv64imafdc_zicsr_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync
-mabi=lp64d -misa-spec=20191213
-march=rv64imafdc_zicsr_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync
-O2 -version -fPIC -o /tmp/cczMFA4n.s
GNU C17 (Gentoo 13.2.1_p20240210 p13) version 13.2.1 20240210
(riscv64-unknown-linux-gnu)
   compiled by GNU C version 13.2.1 20240210, GMP version
6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/riscv64-unknown-linux-gnu/13/../../../../riscv64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/riscv64-unknown-linux-gnu/13/include
 /usr/include
End of search list.
Compiler executable checksum: e5bb685f082cf8fc728c5e3c357fe251
GBZ.c:9:1: warning: no semicolon at end of struct or union 
 9
| } __libc_message(char *fmt, ...) {
  | ^
during RTL pass: dwarf2
GBZ.c: In function ‘__libc_message’:
GBZ.c:19:1: internal compiler error: in dwarf2out_frame_debug_cfa_offset, at
dwarf2cfi.cc:1376 
19 | }
  | ^
0x40c4e9 dwarf2out_frame_debug_cfa_offset
   
/usr/src/debug/sys-devel/gcc-13.2.1_p20240210/gcc-13-20240210/gcc/dwarf2cfi.cc:1376
0x40c4e9 dwarf2out_frame_debug 
   

/usr/src/debug/sys-devel/gcc-13.2.1_p202

[Bug c++/110804] New: [13 regression] eliminate_stmt ICE on aarch64

[alice at ayaya dot dev via Gcc-bugs]

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

Bug ID: 110804
   Summary: [13 regression] eliminate_stmt ICE on aarch64
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alice at ayaya dot dev
  Target Milestone: ---

Created attachment 55629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55629&action=edit
minimised repro, crashes with -O2

using the latest of the gcc13 snapshots (presently 13-20230722, but this is
present since 13 i think), i noticed that the swizzle_test.cc of the google
highway library fails to compile on version 1.0.5.

for reference, the test file is
https://github.com/google/highway/blob/1.0.5/hwy/tests/swizzle_test.cc

the compiler failure looks like

[127/130] Linking CXX executable tests/arithmetic_test
ninja: job failed: /usr/lib/ccache/bin/g++ -DGTEST_LINKED_AS_SHARED_LIBRARY=1
-DHWY_SHARED_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H
-I/home/demon/src/aports/community/highway/src/highway-1.0.5 -Os
-fstack-clash-protection -Wformat -Werror=format-security
-D_GLIBCXX_ASSERTIONS=1 -flto=auto -O2 -DNDEBUG -fPIE -fvisibility=hidden
-fvisibility-inlines-hidden -Wno-builtin-macro-redefined
-D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla
-Wnon-virtual-dtor -fmath-errno -fno-exceptions -DHWY_IS_TEST=1 -MD -MT
CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o -MF
CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o.d -o
CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o -c
/home/demon/src/aports/community/highway/src/highway-1.0.5/hwy/tests/swizzle_test.cc
during GIMPLE pass: fre
/home/demon/src/aports/community/highway/src/highway-1.0.5/hwy/tests/swizzle_test.cc:
In function
'hwy::N_SVE::TestPer4LaneBlockShuffle::TestTblLookupPer4LaneBlkShuf >(hwy::N_SVE::Simd, unsigned long,
hwy::N_SVE::Simd::T const*, hwy::N_SVE::Simd::T*)void':
/home/demon/src/aports/community/highway/src/highway-1.0.5/hwy/tests/swizzle_test.cc:393:1:
internal compiler error: in const_unop, at fold-const.cc:1884
  393 | }  // namespace hwy
  | ^

then i went to minimise it using cvise. i forgot to correctly check that i got
the same ICE error, so i ended up with one in eliminate_stmt. minimised repro
attached. it only crashes with -O2 (not with -O1).

i'm not sure if this is the same crash as the original const_unop, it might be
a separate case.

[Bug c++/110804] [13 regression] eliminate_stmt ICE on aarch64

[alice at ayaya dot dev via Gcc-bugs]

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

--- Comment #1 from psykose  ---
forgot to mention, but this is on alpine linux.

i can't seem to reproduce this with g++13 '13.1.0' on debian sid

[Bug c++/110804] [13 regression] eliminate_stmt ICE on aarch64

[alice at ayaya dot dev via Gcc-bugs]

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

--- Comment #3 from psykose  ---
oh wow, completely identical! i didn't find that somehow, thanks

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[alice at ayaya dot dev via Gcc-bugs]

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

psykose  changed:

   What|Removed |Added

 CC||alice at ayaya dot dev

--- Comment #10 from psykose  ---
with 13-20230722 i can reproduce the exact same failures

[Bug c++/111242] New: Out of bounds pointer arithmetic not caught in constexpr

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 111242
   Summary: Out of bounds pointer arithmetic not caught in
constexpr
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The following UB is not caught by gcc:

#include 

constexpr auto tester() {
  std::vector v = {1, 2, 3};
  auto p = &v[v.size() + 1];
  return &v[0] == p;
}

static_assert(!tester());


https://godbolt.org/z/Y3ofcb1b1

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

[john at drouhard dot dev via Gcc-bugs]

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

John Drouhard  changed:

   What|Removed |Added

 CC||john at drouhard dot dev

--- Comment #10 from John Drouhard  ---
(In reply to frs.dumont from comment #9)
> To be honest before that report I thought that preserving abi was just a 
> matter of preserving memory layout of types. I had no idea that member 
> methods mattered !

(I was the original reporter of this to TC)

I think the specific issue here is that the member function `_M_valptr()`
returns the address of the storage data member, and that _function_ is used in
a construct call elsewhere to point to the address where a new object should be
placed. It returns the address based on the offset from the beginning of the
object which changed when the base class (which had its own data members) was
removed.

So, if the function isn't inlined, the symbol that's actually loaded by the
dynamic linker during runtime will return a potentially bogus address for that
data member if the definition of that function came from a library compiled
with the other version.

[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)

[alice at ayaya dot dev via Gcc-bugs]

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

--- Comment #18 from psykose  ---
> Could you please run a regression to identify which commit along GCC-13 
> branch introduce the change at least to get the ball rolling ?  

note that it might not actually be a regression; it's possible the cvise
minimisation (above) results in "easy to spot UB in testcase" because the
original (non-minimised) program was actually broken because of UB somewhere
(with newer gcc then breaking it via new optimisations), just with it being
harder to find. knowing which commit causes the final bad output may or may not
help find that, if it's the case. the investigation hasn't concluded quite yet.

[Bug libstdc++/111729] New: Design considerations for operator<<(basic_ostream&, const charT*)

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 111729
   Summary: Design considerations for operator<<(basic_ostream&,
const charT*)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

The following program violates a precondition specified in the standard and is
UB however it leads to some surprising behavior

#include 
int main() {
std::cout<<(const char*)nullptr;
std::cout<<"test";
}

There is no segfault, no abort, no non-zero exit status, and no exception.
Instead the program silently continues with the output stream's badbit set.
This can silently ruin the behavior of the rest of the program leaving the
programmer to pull their hair out over what on earth is happening.

Yes, it's UB and the programmer can't expect anything, however it's a very easy
mistake to make and the current behavior makes tracking down that mistake
exceedingly difficult.

I would like to humbly suggest that any of the following behaviors would be
better: Segfaulting, throwing an exception, aborting, an assertion failure in
debug, or printing "(null)" (which is the %s behavior). Libc++ and msvc's stl
both segfault here.

[Bug libstdc++/111729] Design considerations for operator<<(basic_ostream&, const charT*)

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #2 from Jeremy R.  ---
Thank you for the quick response

[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #20 from Jeremy R.  ---
Silently ruining the behavior of the rest of a program and leaving the
programmer to pull their hair out over what on earth is happening seems very
un-ideal behavior.

This is a very easy mistake to make and the current behavior makes tracking
down that mistake exceedingly difficult.

I do recognize the concerns here about existing programs and crashing being
arguably less friendly, but something should be done here. 

Libc++ and msvc's stl both segfault and there's some value in making the
behavior here consistent.

(In reply to Jonathan Wakely from comment #13)
> I'm not suggesting we should print "(null)", that would be crazy
Maybe, but it's also a nice middle ground between silently corrupting the
stream and crashing the program.

Throwing an exception, even only in debug, also seems reasonable as existing
programs may be able to recover from the exception without crashing.

[Bug libstdc++/86130] Expect SIGSEGV but program just silently exits

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #21 from Jeremy R.  ---
Another option might be just do nothing and don't set the badbit, just pretend
it's an empty string. This shouldn't break existing programs and would at least
be something a programmer could more easily track down.

[Bug c/116274] New: x86: poor code generation with 16 byte function arguments

[ripatel at wii dot dev via Gcc-bugs]

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

Bug ID: 116274
   Summary: x86: poor code generation with 16 byte function
arguments
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ripatel at wii dot dev
  Target Milestone: ---

The following program:

struct a { long x,y; };
long test(struct a a) { return a.x+a.y; }

compiled with

$ gcc -c -o test.o -march=x86-64-v2 -O3 test.c

Results in 15 x86_64 instructions using xmm registers when using the System V
calling convention, when it should be two (lea, ret).

$ objdump -d test.o

test.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   0f 29 4c 24 e8  movaps %xmm1,-0x18(%rsp)
   5:   48 8b 54 24 f0  mov-0x10(%rsp),%rdx
   a:   66 48 0f 6e cf  movq   %rdi,%xmm1
   f:   66 48 0f 6e de  movq   %rsi,%xmm3
  14:   66 48 0f 3a 22 ca 01pinsrq $0x1,%rdx,%xmm1
  1b:   66 0f 6c cb punpcklqdq %xmm3,%xmm1
  1f:   0f 29 4c 24 e8  movaps %xmm1,-0x18(%rsp)
  24:   48 8b 44 24 f0  mov-0x10(%rsp),%rax
  29:   66 0f 6f d1 movdqa %xmm1,%xmm2
  2d:   66 48 0f 3a 22 d0 01pinsrq $0x1,%rax,%xmm2
  34:   66 0f 6f c2 movdqa %xmm2,%xmm0
  38:   66 0f 73 d8 08  psrldq $0x8,%xmm0
  3d:   66 0f d4 c1 paddq  %xmm1,%xmm0
  41:   66 48 0f 7e c0  movq   %xmm0,%rax
  46:   c3 

Debug information:

$ gcc -v -save-temps -c -o test.o -march=x86-64-v2 -O3 test.c
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-14.2.1-20240801/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20240801 (Red Hat 14.2.1-1) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'test.o' '-march=x86-64-v2'
'-O3'
 /usr/libexec/gcc/x86_64-redhat-linux/14/cc1 -E -quiet -v test.c
-march=x86-64-v2 -O3 -fpch-preprocess -o test.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/14/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/14/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/14/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'test.o' '-march=x86-64-v2'
'-O3'
 /usr/libexec/gcc/x86_64-redhat-linux/14/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -dumpbase-ext .c -march=x86-64-v2 -O3 -version -o test.s
GNU C17 (GCC) version 14.2.1 20240801 (Red Hat 14.2.1-1) (x86_64-redhat-linux)
compiled by GNU C version 14.2.1 20240801 (Red Hat 14.2.1-1), GMP
version 6.2.1, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7983ab47815232989bed61515b77d1c7
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'test.o' '-march=x86-64-v2'
'-O3'
 as -v --64 -o test.o test.s
GNU assembler version 2.41 (x86_64-redhat-linux) using BFD version version
2.41-37.fc40
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/14/:/usr/libexec/gcc/x86_64-redhat-linux/14/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/14/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/14/:/usr/lib/gcc/x86_64-redhat-linux/14/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/14/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'test.o' '-march=x86-64-v2'
'-O3' '-dumpdir' 'test.'

[Bug c++/116534] New: [14 regression] internal compiler error with comparison of pointers calculated with array offset

[john at drouhard dot dev via Gcc-bugs]

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

Bug ID: 116534
   Summary: [14 regression] internal compiler error with
comparison of pointers calculated with array offset
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john at drouhard dot dev
  Target Milestone: ---

The following produces an internal compiler when compiled with -Wall starting
with gcc 14:


$ cat test.cpp
template 
class Test {
void foo(unsigned x, unsigned y) {
bool test = &a[x] == &b[y];
}
unsigned *a;
unsigned *b;
};



$ g++ -Wall ./test.cpp
./test.cpp: In member function 'void Test::foo(unsigned int, unsigned int)':
./test.cpp:4:34: internal compiler error: Segmentation fault
4 | bool test = &a[x] == &b[y];
  |  ^
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

[Bug target/110634] Incorrect RISC-V assembly with -fno-omit-frame-pointer

[andrew.jones at linux dot dev via Gcc-bugs]

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

Andrew Jones  changed:

   What|Removed |Added

 CC||andrew.jones at linux dot dev

--- Comment #6 from Andrew Jones  ---
I also stumbled onto this issue, but it appears to be fixed with gcc-14 (tested
with gcc version 14.2.1 20240904 (g0562522e1290)).

[Bug target/109279] New: [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Bug ID: 109279
   Summary: [13 Regression] RISC-V: complex constants synthesized
vs. fetching from constant pool
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineet.gupta at linux dot dev
  Target Milestone: ---

This is code bloat regression since gcc 12.1, seen yet again in SPEC2017
deepsjeng. After 2e886eef7f2b5a ("RISC-V: Produce better code with complex
constants [PR95632] [PR106602]").

unsigned long long FileAttacks(unsigned long long occ, const unsigned int sq) {
unsigned int o;
unsigned int f = sq & 7;

occ   =   0x0101010101010101ULL & (occ   >> f);
o = ( 0x0080402010080400ULL *  occ ) >> 58;
return  ( aFileAttacks[o][sq>>3]) << f;
}

cc1 -O2 -march=rv64gc_zba_zbb_zbc_zbs -mabi=lp64d   # stage1 is enough

Before above commit
---
lui a4,%hi(.LC0)
ld  a4,%lo(.LC0)(a4)
andia3,a1,7
srl a5,a0,a3
and a5,a5,a4
lui a4,%hi(.LC1)
ld  a4,%lo(.LC1)(a4)
srliw   a1,a1,3
mul a5,a5,a4
lui a4,%hi(aFileAttacks)
addia4,a4,%lo(aFileAttacks)
srlia5,a5,58
sh3add  a5,a5,a1
sh3add  a5,a5,a4
ld  a0,0(a5)
sll a0,a0,a3
ret

.section.srodata.cst8,"aM",@progbits,8
.align  3
.LC0:
.dword  0x0101010101010101
.align  3
.LC1:
.dword  0x0080402010080400


With commit
---

   li  a5,16842752
addia5,a5,257
sllia5,a5,16
addia5,a5,257
andia3,a1,7
sllia5,a5,16
srl a4,a0,a3
addia5,a5,257
and a4,a4,a5
sllia5,a4,9
add a5,a5,a4
sllia5,a5,9
add a5,a5,a4
sllia4,a5,27
add a5,a5,a4
srlia5,a5,45
srliw   a1,a1,3
andia5,a5,504
lui a4,%hi(aFileAttacks)
add a5,a5,a1
addia4,a4,%lo(aFileAttacks)
sh3add  a5,a5,a4
ld  a0,0(a5)
sll a0,a0,a3
ret

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #3 from Vineet Gupta  ---
We start off with following:

  (insn 18 17 19 2 (set (reg:DI 154)
 (mem/u/c:DI (reg/f:DI 155) [0  S8 A64])) "...":9:8 179 {*movdi_64bit}
 (expr_list:REG_DEAD (reg/f:DI 155)
(expr_list:REG_EQUAL (const_int [0x101010101010101])

cse1 matches the new pattern and converts mem to const_int.

   (insn 18 17 19 2 (set (reg:DI 154)
(const_int [0x101010101010101])) "...":9:8 177 {*mvconst_internal}
 (expr_list:REG_DEAD (reg/f:DI 155)
(expr_list:REG_EQUAL (const_int [0x101010101010101])

split1 then does its job, again using the introduced define_insn_and_split
"*mvconst_internal"

Splitting with gen_split_15 (riscv.md:1677)
deleting insn with uid = 18.

   (insn 47 15 48 2 (set (reg:DI 154)
(const_int 16842752 [0x101])) "...":9:8 -1

   (insn 48 47 49 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1

   (insn 49 48 50 2 (set (reg:DI 154)
(ashift:DI (reg:DI 154)
(const_int 16 [0x10]))) "...":9:8 -1

   (insn 50 49 51 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1

   (insn 51 50 52 2 (set (reg:DI 154)
(ashift:DI (reg:DI 154)
(const_int 16 [0x10]))) "...":9:8 -1

   (insn 52 51 19 2 (set (reg:DI 154)
(plus:DI (reg:DI 154)
(const_int 257 [0x101]))) "...":9:8 -1
 (expr_list:REG_EQUAL (const_int [0x101010101010101])

[Bug target/109279] [13 Regression] RISC-V: complex constants synthesized vs. fetching from constant pool

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #4 from Vineet Gupta  ---
(In reply to Andrew Pinski from comment #2)
> If this was about -Os, then I would say yes this is a big code bloat but
> this is about -O2.

But this is not so much about code bloat, we see 3.5% additional dynamic icount
on qemu which will affect perf even if we didn't care about code size at all.

[Bug target/109279] RISC-V: complex constants synthesized should be improved

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #10 from Vineet Gupta  ---
I tried removing the in_splitter  check (in 2 places), but no change in
results.

@@ -1313,7 +1313,7 @@ riscv_force_temporary (rtx dest, rtx value, bool
in_splitter)

-  if (can_create_pseudo_p () && !in_splitter)
+  if (can_create_pseudo_p ())


@@ -1669,7 +1669,7 @@ riscv_move_integer (rtx temp, rtx dest, HOST_WIDE_INT
value,

-  bool can_create_pseudo = can_create_pseudo_p () && ! in_splitter;
+  bool can_create_pseudo = can_create_pseudo_p ();