[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

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

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

Sam James  changed:

   What|Removed |Added

 CC||eschwartz93 at gmail dot com,
   ||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
If meson is getting it wrong rather than gegl using it wrong, please report it
over there and one of us can handle it.

[Bug c++/19501] Redundant "template" keyword rejected

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Yeah, seems fixed by r12-6754-g30f2c22def7392

commit 30f2c22def7392119f1ffaca30ef998b3b43f336
Author: Jason Merrill 
Date:   Tue Jan 18 18:28:22 2022 -0500

c++: template-id with current inst qualifier [PR102300]

[Bug tree-optimization/85605] Potentially missing optimization under x64 and ARM: seemingly unnecessary branch in codegen

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Fixed for GCC 15.

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Sergey Fedorov  ---
(In reply to Eli Schwartz from comment #5)
> Not a meson bug, but gegl should probably test whether -ObjC is accepted as
> a valid flag before unconditionally adding it to their build.

I have opened an issue there: https://gitlab.gnome.org/GNOME/gegl/-/issues/393

[Bug c++/117479] ICE on x86_64-linux-gnu: in cxx_eval_constant_expression, at cp/constexpr.cc:8448 with vector_size

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #2 from Andrew Pinski  ---
I think this code is valid though.

Slightly better/easier testcase:
```
typedef __attribute__((vector_size(sizeof(int int v1si;

struct s1 {
  int a;
  v1si c { a };
};
s1 b1;
constexpr s1 b{1};
```

I think we don't treat vector constructors as possible constexpr.

[Bug c++/117479] ICE on x86_64-linux-gnu: in cxx_eval_constant_expression, at cp/constexpr.cc:8448 with vector_size

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Also doing:
```
v1si c { 1 };
```
Works.

[Bug target/117477] Register allocator chooses a slot location instead a new callee saved register and not taking inot account pair allocation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||ra
 Target||aarch64

[Bug tree-optimization/85605] Potentially missing optimization under x64 and ARM: seemingly unnecessary branch in codegen

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

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

--- Comment #9 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:2a2e6784074e1f7b679bc09b1a66982bf60645a5

commit r15-5024-g2a2e6784074e1f7b679bc09b1a66982bf60645a5
Author: Andrew Pinski 
Date:   Mon Oct 28 16:40:34 2024 -0700

ifcombine: For short circuit case, allow 2 convert defining statements
[PR85605]

r0-126134-g5d2a9da9a7f7c1 added support for circuiting and combing the ifs
into using either AND or OR. But it only allowed the inner condition
basic block having the conditional only. This changes to allow up to 2
defining
statements as long as they are just integer to integer conversions for
either the lhs or rhs of the conditional.

This should allow to use ccmp on aarch64 and x86_64 (APX) slightly more
than before.

Boootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/85605

gcc/ChangeLog:

* tree-ssa-ifcombine.cc (can_combine_bbs_with_short_circuit): New
function.
(ifcombine_ifandif): Use can_combine_bbs_with_short_circuit
instead of checking if iterator is one before the last statement.

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/ifcombine-ccmp-1.C: New test.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-7.c: New test.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-8.c: New test.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-9.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/117414] missing predicated VN due to combining if statements

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

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

--- Comment #3 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:578002846620ed04192a4832e9f20b5c32816153

commit r15-5021-g578002846620ed04192a4832e9f20b5c32816153
Author: Andrew Pinski 
Date:   Fri Nov 1 20:06:30 2024 -0700

VN: Handle `(a | b) !=/== 0` for predicates [PR117414]

For `(a | b) == 0`, we can "assert" on the true edge that
both `a == 0` and `b == 0` but nothing on the false edge.
For `(a | b) != 0`, we can "assert" on the false edge that
both `a == 0` and `b == 0` but nothing on the true edge.
This adds that predicate and allows us to optimize f0, f1,
and f2 in fre-predicated-[12].c.

Changes since v1:
* v2: Use vn_valueize. Also canonicalize the comparison
  at the begining of insert_predicates_for_cond for
  constants to be on the rhs. Return early for
  non-ssa names on the lhs (after canonicalization).

Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/117414

gcc/ChangeLog:

* tree-ssa-sccvn.cc (insert_predicates_for_cond): Canonicalize the
comparison.
Don't insert anything if lhs is not a SSA_NAME. Handle `(a | b)
!=/== 0`.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/fre-predicated-1.c: New test.
* gcc.dg/tree-ssa/fre-predicated-2.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/117414] missing predicated VN due to combining if statements

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r15-5022-gadd4bb94459d6cecae11de279b49f9c1acb14394
Author: Andrew Pinski 
Date:   Fri Nov 1 23:12:52 2024 -0700

VN: Handle `(A CMP B) !=/== 0` for predicates [PR117414]

After the last patch, we also want to record `(A CMP B) != 0`
as `(A CMP B)` and `(A CMP B) == 0` as `(A CMP B)` with the
true/false edges swapped.

This shows up more due to the new handling of
`(A | B) ==/!= 0` in insert_predicates_for_cond
as now we can notice these comparisons which were not seen before.

This is enough to fix the original issue in `gcc.dg/tree-ssa/pr111456-1.c`
and make sure we don't regress it when enhancing ifcombine.

This adds that predicate and allows us to optimize f
in fre-predicated-3.c.

Changes since v1:
* v2:  Use vn_valueize.

Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/117414

gcc/ChangeLog:

* tree-ssa-sccvn.cc (insert_predicates_for_cond): Handle `(A CMP B)
!=/== 0`.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/fre-predicated-3.c: New test.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/117414] missing predicated VN due to combining if statements

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:684e5ae90b64c3481f8a5cb7b9517daf79c78ab4

commit r15-5023-g684e5ae90b64c3481f8a5cb7b9517daf79c78ab4
Author: Andrew Pinski 
Date:   Fri Nov 1 23:20:22 2024 -0700

VN: Lookup `val != 0` if we got back val when looking up the predicate for
GIMPLE_COND [PR117414]

Sometimes we get back a full ssa name when looking up the comparison of the
GIMPLE_COND
rather than a predicate. We then want to lookup the `val != 0` for the
predicate.

Note this might happen with other boolean assignments and COND_EXPR but I
am not sure
if it is as important; I have not found a testcase yet.

Bootstrapped and tested on x86_64-linux-gnu.

PR tree-optimization/117414

gcc/ChangeLog:

* tree-ssa-sccvn.cc (process_bb): Lookup
`val != 0` if got back a ssa name when looking the comparison.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/fre-predicated-4.c: New test.

Signed-off-by: Andrew Pinski 

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #12 from David Binderman  ---
(In reply to Alexey Merzlyakov from comment #11)
> To verify the "outside mode N" part, we need to change
> 
>  & ~GET_MODE_MASK (mode)) == 0)
> 
> to the:
> 
>  & ~GET_MODE_MASK(GET_MODE (op))) == 0)
> 
> as "op" is in "N" mode, not in "mode" (M) itself.

A couple of minor points:

1. gcc source code is packed full of random macros ;-|

A more stylish solution might be using some sort of an accessor function.

That might make generalising this solution across the whole
source code file of the bugfix easier.

2.

> If this turns out to be true, I will elaborate a patch to fix this issue in
> the coming days.

For bugfixes of this nature, I can strongly recommend that thousands
of runs of csmith are very useful for testing. 

That's how I found this one. Every gcc build gets 3,000 runs of csmith
before going onto more serious testing.

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Sergey Fedorov  ---
(In reply to Jakub Jelinek from comment #10)
> -xobjective-c should work fine with both gcc and clang and is much better
> designed, it isn't about two almost dead languages, but allows specifying
> any language the compiler supports.

-xobjective-c worked, gegl builds now. Thank you.

[Bug target/117477] Register allocator chooses a slot location instead a new callee saved register and not taking inot account pair allocation

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

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

--- Comment #2 from Andrew Pinski  ---
Here is a testcase which shows that GCC spilling but spilling is better than
using a callee saved register by removing extra moves:
```
int test (int x), test2 (int x);

int test3(int,int,int);
int foo (int x, int y) {
test (x);
int lhs = test2 (y);
int lhs1 = test2 (y);
return test3(lhs,lhs1,x);
} 
```

So it is a wash I think.

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #13 from Alex Coplan  ---
FWIW h264ref from SPEC CPU 2006 also seems to start getting miscompiled with
the above commit (r15-4991-g69bd93c167fefb) on aarch64.

[Bug c++/117256] When initializing an object, padding bits are not set to zero

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 59554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59554&action=edit
gcc15-pr117256.patch

Untested fix on top of the above mentioned patch.
This is just the start, I think for full support we need to decide where
exactly
the flag should be copied especially during constant evaluation and where
should be cleared (essentially, object copying doesn't preserve it, only memcpy
does but then memcpy on objects isn't kosher in constant evaluation; but e.g.
bit_cast should be).

[Bug target/117447] ICE in BPF GCC-trunk segmentation fault

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by David Faust :

https://gcc.gnu.org/g:0e1382034246a594f1da8dbaee97c4a06743f31a

commit r15-5026-g0e1382034246a594f1da8dbaee97c4a06743f31a
Author: David Faust 
Date:   Thu Nov 7 09:27:07 2024 -0800

bpf: avoid possible null deref in btf_ext_output [PR target/117447]

The BPF-specific .BTF.ext section is always generated for BPF programs
if -gbtf is specified, and generating it requires BTF information and
assumes that the BTF info has already been generated.

Compiling non-C languages to BPF is not supported, nor is generating
CTF/BTF for non-C.  But, compiling another language like C++ to BPF
with -gbtf specified meant that we would try to generate the .BTF.ext
section anyway, and then ICE because no BTF information was available.

Add a check to bail out of btf_ext_output if the TU CTFC does not exist,
meaning no BTF info is available.

gcc/
PR target/117447
* config/bpf/btfext-out.cc (btf_ext_output): Bail if TU CTFC is
null.

[Bug tree-optimization/117482] [12/13/14/15 Regression] Bogus -Wstringop-overflow warning in intrusive list implementation

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.4.0
  Known to fail||12.1.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.5
   Last reconfirmed||2024-11-07
Summary|Bogus -Wstringop-overflow   |[12/13/14/15 Regression]
   |warning in intrusive list   |Bogus -Wstringop-overflow
   |implementation  |warning in intrusive list
   ||implementation
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I was thinking there was a missed optimization due to an character type but int
gives the same IR too.

Anyways confirmed.

Note another workaround is to add:
   if (!entry) __builtin_unreachable();

After the pop. To say the pop will always work.

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Priority|P3  |P1
   Keywords||testsuite-fail

--- Comment #14 from Andrew Pinski  ---
I think:

FAIL: image
FAIL: image/color
FAIL: image/draw
FAIL: image/jpeg

These failures in libgo is also caused by this. Happens on x86_64 and aarch64.

[Bug libstdc++/115285] [12/13/14 Regression] std::unordered_set can have duplicate value

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:90c578654a2c96032aa6621449859243df5f641b

commit r15-5032-g90c578654a2c96032aa6621449859243df5f641b
Author: Jonathan Wakely 
Date:   Tue Nov 5 17:19:06 2024 +

libstdc++: Fix conversions to key/value types for hash table insertion
[PR115285]

The conversions to key_type and value_type that are performed when
inserting into _Hashtable need to be fixed to do any required
conversions explicitly. The current code assumes that conversions from
the parameter to the key_type or value_type can be done implicitly,
which isn't necessarily true.

Remove the _S_forward_key function which doesn't handle all cases and
either forward the parameter if it already has type cv key_type, or
explicitly construct a temporary of type key_type.

Similarly, the _ConvertToValueType specialization for maps doesn't
handle all cases either, for std::pair arguments only some value
categories are handled. Remove _ConvertToValueType and for the _M_insert
function for unique keys, either forward the argument unchanged or
explicitly construct a temporary of type value_type.

For the _M_insert overload for non-unique keys we don't need any
conversion at all, we can just forward the argument directly to where we
construct a node.

libstdc++-v3/ChangeLog:

PR libstdc++/115285
* include/bits/hashtable.h (_Hashtable::_S_forward_key): Remove.
(_Hashtable::_M_insert_unique_aux): Replace _S_forward_key with
a static_cast to a type defined using conditional_t.
(_Hashtable::_M_insert): Replace _ConvertToValueType with a
static_cast to a type defined using conditional_t.
* include/bits/hashtable_policy.h (_ConvertToValueType): Remove.
* testsuite/23_containers/unordered_map/insert/115285.cc: New test.
* testsuite/23_containers/unordered_set/insert/115285.cc: New test.
* testsuite/23_containers/unordered_set/96088.cc: Adjust
expected number of allocations.

[Bug tree-optimization/117484] New: [15 Regression] ICE: segfault during GIMPLE pass: vect

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 117484
   Summary: [15 Regression] ICE: segfault during GIMPLE pass: vect
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
extern int a;
extern short b[];
extern signed char c[], d[];
int main() {
  for (long j = 3; j; j += 3)
if (c[j] ? b[j] : 0) {
  b[j] = d[j - 2];
  a = d[j];
}
}

Command/backtrace:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -fsigned-char -fno-strict-aliasing -fwrapv -march=rv64gcv -fwhole-program 
> -O3 red.c -o rv64gcv.out
during GIMPLE pass: vect
red.c: In function 'main':
red.c:4:5: internal compiler error: Segmentation fault
4 | int main() {
  | ^~~~
0x2f0de35 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:518
0x13b0163 crash_signal
../../../gcc/gcc/toplev.cc:323
0x7c71c764251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xf8bf81 location_wrapper_p(tree_node const*)
../../../gcc/gcc/tree.h:4410
0xf8bf81 tree_strip_any_location_wrapper(tree_node*)
../../../gcc/gcc/tree.h:4422
0xf8bf81 operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
../../../gcc/gcc/fold-const.cc:3177
0xf8f640 operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
../../../gcc/gcc/fold-const.cc:4244
0xf8f640 operand_compare::verify_hash_value(tree_node const*, tree_node const*,
unsigned int, bool*)
../../../gcc/gcc/fold-const.cc:4233
0xf8f640 operand_compare::verify_hash_value(tree_node const*, tree_node const*,
unsigned int, bool*)
../../../gcc/gcc/fold-const.cc:4225
0xf901ec operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
../../../gcc/gcc/fold-const.cc:3173
0xf901ec operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../../gcc/gcc/fold-const.cc:4264
0x16e22d0 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2678
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16dff17 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2743
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16dff17 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2743
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16e0be8 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2077
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16dff17 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2743
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Godbolt: https://godbolt.org/z/nfovE9jr1

[Bug ada/117485] New: aspect "type_invariant" only allowed for private type or corresponding full view, but RM doesn't mention that

[00120260a at gmail dot com via Gcc-bugs]

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

Bug ID: 117485
   Summary: aspect "type_invariant" only allowed for private type
or corresponding full view, but RM doesn't mention
that
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 00120260a at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

The release version is gnat_native_14.2.1_06bb3def. this code below fails with
all the people that tried it:

procedure main is
type ArrayInput is array (Positive range <>) of Integer with Type_Invariant
=> (for all I in ArrayInput(1..ArrayInput'Last-1) => ArrayInput(I).K <
ArrayInput(I+1).K); 
begin
  null;
end main;

The error raised is "main.adb:4:10: error: aspect "type_invariant" only allowed
for private type or corresponding full view". The problem is that such
limitation is mentioned nowhere in the reference manual. In doubt, I'd tend to
think the RM is right and the developers wrong.

[Bug target/117483] New: [15 Regression] ICE: in merge, at config/riscv/riscv-vsetvl.cc:2106

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 117483
   Summary: [15 Regression] ICE: in merge, at
config/riscv/riscv-vsetvl.cc:2106
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
char a, b, f;
short c, h;
int d[5];
int e;
long *g;
short (*i)[4];
int main() {
  e = 906784;
  char *j = &f;
  short *k = &h;
  for (short l = 0; l < 23; l += 740314495218734 - 29738)
for (unsigned char m = ~!g[l] - 255; m < 24; m += 3) {
  a = k[m];
  b += j[1] ?: d[6];
  c ^= i[010][l];
}
}

Command/backtrace:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -fsigned-char -fno-strict-aliasing -fwrapv -march=rv64gcv_zvl256b -O3 red.c 
> -o rv64gcv.out
during RTL pass: vsetvl
red.c: In function 'main':
red.c:17:1: internal compiler error: in merge, at
config/riscv/riscv-vsetvl.cc:2106
   17 | }
  | ^
0x2f0de35 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:518
0xc69f90 fancy_abort(char const*, int, char const*)
../../../gcc/gcc/diagnostic.cc:1696
0xb9e239 demand_system::merge(vsetvl_info&, vsetvl_info const&)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2106
0xb9e239 pre_vsetvl::earliest_fuse_vsetvl_info(int)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2983
0x18ba5f4 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3558
0x18ba96a pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3605
0x18ba96a pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3588
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Godbolt: https://godbolt.org/z/q9PsvhMxP

[Bug ada/117485] aspect "type_invariant" only allowed for private type or corresponding full view

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
Summary|aspect "type_invariant" |aspect "type_invariant"
   |only allowed for private|only allowed for private
   |type or corresponding full  |type or corresponding full
   |view, but RM doesn't|view
   |mention that|
 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  ---
RM 2022 7.3.2(2/3):

"Type_Invariant

This aspect shall be specified by an expression, called an invariant
expression. Type_Invariant may be specified on a private_type_declaration, on a
private_extension_declaration, or on a full_type_declaration that declares the
completion of a private type or private extension."

[Bug tree-optimization/117484] [15 Regression] ICE: segfault during GIMPLE pass: vect

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug tree-optimization/117484] [15 Regression] ICE: segfault during GIMPLE pass: vect

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 59557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59557&action=edit
testcase that also fails with -march=armv9-a on aarch64

[Bug tree-optimization/117486] New: [15 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.cc:2027

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 117486
   Summary: [15 Regression] ICE: in vect_build_slp_tree_2, at
tree-vect-slp.cc:2027
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a;
extern int d[];
extern int b[];
extern _Bool c[];
extern char h[];
int main() {
  for (int i = 0; i < -18446744073709551493ULL; i += 4)
if (h[i] || c[i]) {
  a = d[i];
  b[i] = d[i - 3];
}
}


Command/backtrace:
> /scratch/tc-testing/tc-compiler-fuzz-trunk/build-gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -I/scratch/tc-testing/compiler-fuzz-ci/csmith-build/include -fsigned-char 
> -fno-strict-aliasing -fwrapv -march=rv64gcv_zvl256b -O3 red.c -o rv64gcv.out
during GIMPLE pass: vect
red.c: In function 'main':
red.c:6:5: internal compiler error: in vect_build_slp_tree_2, at
tree-vect-slp.cc:2027
6 | int main() {
  | ^~~~
0x2f0de35 internal_error(char const*, ...)
../../../gcc/gcc/diagnostic-global-context.cc:518
0xc69f90 fancy_abort(char const*, int, char const*)
../../../gcc/gcc/diagnostic.cc:1696
0xb71971 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2027
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16dff17 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2743
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16dff17 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2743
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16dff17 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2743
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16e0be8 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2077
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16dff17 vect_build_slp_tree_2
../../../gcc/gcc/tree-vect-slp.cc:2743
0x16e55eb vect_build_slp_tree
../../../gcc/gcc/tree-vect-slp.cc:1806
0x16e6afb vect_build_slp_instance
../../../gcc/gcc/tree-vect-slp.cc:3851
0x16ec51c vect_analyze_slp(vec_info*, unsigned int, bool)
../../../gcc/gcc/tree-vect-slp.cc:4731
0x16b662a vect_analyze_loop_2
../../../gcc/gcc/tree-vect-loop.cc:2885
0x16b7ca3 vect_analyze_loop_1
../../../gcc/gcc/tree-vect-loop.cc:3454
0x16b8411 vect_analyze_loop(loop*, gimple*, vec_info_shared*)
../../../gcc/gcc/tree-vect-loop.cc:3614
0x1706b97 try_vectorize_loop_1
../../../gcc/gcc/tree-vectorizer.cc:1072
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Found via fuzzer

Tested using g4473cf8409f

Assertion triggered:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/tree-vect-slp.cc;h=97c362d24f8d3f483c455876edc280097385f70a;hb=HEAD#l2027

Godbolt: https://godbolt.org/z/qGKsTYP31

[Bug tree-optimization/117486] [15 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.cc:2027

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 59558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59558&action=edit
testcase that ICEs the same way on aarch64

[Bug tree-optimization/117486] [15 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.cc:2027

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #3 from Patrick O'Neill  ---
(In reply to Andrew Pinski from comment #2)
> I think you reduced the testcase case a little too much. Anyways confirmed,
> see the attached testcase for one that fails on aarch64 with -march=armv9-a.

Thanks for the better testcase :)
I had forgotten how aggressive my reduction flow was for ICEs.

[Bug tree-optimization/117484] [15 Regression] ICE: segfault during GIMPLE pass: vect

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|riscv*-*-*  |riscv*-*-* aarch64*-*-*
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-07

--- Comment #2 from Andrew Pinski  ---
Confirmed via the aarch64 testcase.

Note I do think you reduced the testcase slightly too much. See mine which adds
a simple check for < 1024 instead of checking for the induction variables turns
to 0.

[Bug tree-optimization/117486] [15 Regression] ICE: in vect_build_slp_tree_2, at tree-vect-slp.cc:2027

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |15.0
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-07
 Target|riscv*-*-*  |riscv*-*-* aarch64

--- Comment #2 from Andrew Pinski  ---
I think you reduced the testcase case a little too much. Anyways confirmed, see
the attached testcase for one that fails on aarch64 with -march=armv9-a.

[Bug target/117353] [15 regression] RISC-V: ICE when building libcrypt since r15-3228-g771256bcb9ddc4

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

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

--- Comment #7 from Vineet Gupta  ---
(In reply to Jeffrey A. Law from comment #6)
> So my approach would be to note the insn number, then set a conditional
> breakpoint  in make_insn_raw (after it initializes INSN_UID in the new
> insn).  The condition would be insn->u2.insn_uid ==  or
> something close to that.

Nice: I've been using the uid conditional breakpoints forever but bt out of
make_insn_raw () is a nice trick to know.

> That gives us a handle on precisely where it's created, then walk up the
> frames into the RISC-V code.  As Robin noted, could easily be a missed
> can_create_pseudos_p test.

Yeah, as Robin said it is the const vect and reload move 

 lra_constraints
   curr_insn_transform
  lra_emit_move
 emit_move_insn
gen_movv8qi
   riscv_vector::legitimize_move (rtx dest, rtx *srcp)
   if (CONST_VECTOR_P(src))
   riscv_vector::expand_const_vector<---
  expand_simple_binop
 expand_binop
expand_binop_directly
   emit_insn
 make_insn_raw


In expand_const_vector() it seems we need to explicitly handle lra_in_progress
for this case, which seems non trivial to me personally.

However I have a different question about these vector shifts lacking a vsetvl
veneer due to being post/during reload. For the ones pre-existing before
reload, the splitter in autovec.md does the trick.

;; -
;;  [INT] Binary shifts by scalar.
;; -
;; Includes:
;; - vsll.vx/vsra.vx/vsrl.vx
;; - vsll.vi/vsra.vi/vsrl.vi
;; -

(define_insn_and_split "3"
  [(set (match_operand:V_VLSI 0 "register_operand""=vr")
(any_shift:V_VLSI
 (match_operand:V_VLSI 1 "register_operand"   " vr")
 (match_operand: 2 "vector_scalar_shift_operand" " rK")))]
  "TARGET_VECTOR && can_create_pseudo_p ()"
  "#"
  "&& 1"
  [(const_int 0)]
{
  operands[2] = gen_lowpart (Pmode, operands[2]);
  riscv_vector::emit_vlmax_insn (code_for_pred_scalar (, mode),
 riscv_vector::BINARY_OP, operands);
  DONE;
}

I wonder if we can instead enhance it to use emit_vlmax_insn_lra() type
constructs if lra_in_progress ?

[Bug target/117353] [15 regression] RISC-V: ICE when building libcrypt since r15-3228-g771256bcb9ddc4

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

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

--- Comment #8 from Vineet Gupta  ---
We could potentially use a scratch in splitter.

   (clobber (match_scratch:DI 3 "=&r"))]

[Bug ada/117485] aspect "type_invariant" only allowed for private type or corresponding full view

[00120260a at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Saada Mehdi <00120260a at gmail dot com> ---
mm, ok, we're wrong, I remember we didn't find it, weird.
In that case I'll take it up with ARG, because it doesn't make sense to stop
public types from using this.

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

[eschwartz93 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Eli Schwartz  ---
https://github.com/GNOME/gegl/blob/626c202550c4536c2e411821fb34e91d138c1548/meson.build#L246-L254

```
if os_osx
  add_languages('objc')
  osx_ldflags = ['-Wl,-framework,Foundation', '-Wl,-framework,AppKit', '-ObjC']
  add_project_link_arguments(osx_ldflags, language : ['objc', 'c'])
endif

if os_osx
  add_project_arguments('-ObjC', language : 'c')
endif
```

Not a meson bug, but gegl should probably test whether -ObjC is accepted as a
valid flag before unconditionally adding it to their build.

[Bug target/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-07
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
  Component|objc|target
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |15.0

--- Comment #14 from Iain Sandoe  ---
making this a target bug, because it is only relevant to Darwin (even if it's
technically a driver issue).

I have a patch which is pretty much trivial .. so will apply after testing.

[Bug c/117482] New: Bogus -Wstringop-overflow warning in intrusive list implementation

[adam at adamrosenfield dot com via Gcc-bugs]

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

Bug ID: 117482
   Summary: Bogus -Wstringop-overflow warning in intrusive list
implementation
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at adamrosenfield dot com
  Target Milestone: ---

Created attachment 59555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59555&action=edit
Test file exhibiting the bogus -Wstringop-overflow warning

In the attached code, we have an intrusive linked list implementation that
generates bogus -Wstringop-overflow warning.

Compile as:

```
$ gcc -c bug.c  -Wall -O3
bug.c: In function ‘foo’:
bug.c:55:10: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   55 | x->a = 0;
  | ~^~~
```

This occurs in every GCC version since 12.1.  This occurs at -O2 and -O3, but
not at -O1 or -Os.

It's fairly sensitive to local code changes.  If the `x->a` member is read from
instead of written into, it doesn't trigger.  If there's another access of
`x->a` prior to the write, it doesn't trigger.  If the type of `a` is changed
to a type with any other size (short/int/long long/etc.), it doesn't trigger. 
If other fields are added or removed, or if the type of the `head` field as
changed, it doesn't trigger.

I've found a number of other -Wstringop-overflow bugs related to from the
metabug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=Wstringop-overflow, and
I looked through some of them, but I haven't exhaustively checked them all
since there are so many.  If this is a duplicate of an existing issue, please
feel free to link this & resolve as a duplicate if needed.

[Bug tree-optimization/117414] missing predicated VN due to combining if statements

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed. A followup patch for the "partial" canonicalization will posted later
today; it is in testing.

[Bug fortran/117473] Issue with OpenMP workshare and -fsanitize=thread

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #59547|0   |1
is obsolete||
  Attachment #59548|0   |1
is obsolete||

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 59556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59556&action=edit
Ensure schedule(static), sharing of work arrays

[Bug tree-optimization/117480] New: wrong code at -O1 and above on x86_64-linux-gnu

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

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

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

This appears to be a recent regression as it doesn't reproduce with 14.2 and
earlier. 

Compiler Explorer: https://godbolt.org/z/91fxrzE49

[607] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241107 (experimental) (GCC) 
[608] % 
[608] % gcctk -O0 small.c; ./a.out
[609] % 
[609] % gcctk -O1 small.c
[610] % ./a.out
Aborted
[611] % 
[611] % cat small.c
int c = 0x1FF;
int main() {
  if (((c ^ 0xFF) & 0xFF) != 0)
__builtin_abort();
  return 0;
}

[Bug target/117353] [15 regression] RISC-V: ICE when building libcrypt since r15-3228-g771256bcb9ddc4

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

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

--- Comment #9 from Vineet Gupta  ---
Or the other option is to prevent these patterns from kicking in during reload 
by adjust the costs (there's a TODO there already)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 3ac40234345a..0933fc2d6099 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2352,6 +2352,9 @@ riscv_const_insns (rtx x, bool allow_new_pseudos)

if (CONST_VECTOR_STEPPED_P (x))
  {
+   if (lra_in_progress || reload_completed)
+ return 0;
+

[Bug ada/117485] aspect "type_invariant" only allowed for private type or corresponding full view

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

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

--- Comment #3 from Eric Botcazou  ---
> In that case I'll take it up with ARG, because it doesn't make sense to stop
> public types from using this.

You might want to read the AI that discussed it 15 years ago, that's clearly
explained in there.  You might also want to use Dynamic_Predicate instead.

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #15 from Sergei Trofimovich  ---
Also noticed test failures on grep-3.11 (FAIL: word-delim-multibyte) and on
libgcrypt-1.10.3 (FAIL: basic FAIL: basic-disable-all-hwf) for x86_64-linux
target. python interpreter SIGSEGVs frequently. Bisect landed on the same
commit.

[Bug target/117487] New: Power8 optimizations for math library aren't done in power9 or power10 (PR target/71977)

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

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

Bug ID: 117487
   Summary: Power8 optimizations for math library aren't done in
power9 or power10 (PR target/71977)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

I was answering an email about something else, and I wanted to look up code
that I added in January 4th, 2017 (PR target/71977, PR target/70568, PR
target/78823).  I noticed while this code is optimized on power8, it is not
optimized on power9 or power10.

The code (gcc.target/pr71977-1.c) is:

#include 

typedef union
{
  float value;
  uint32_t word;
} ieee_float_shape_type;

float
mask_and_float_var (float f, uint32_t mask)
{ 
  ieee_float_shape_type u;

  u.value = f;
  u.word &= mask;

  return u.value;
}

The initial code generated before the January 4th, 2017 changes was:

xscvdpspn 0,1
mfvsrwz 9,0
and 9,9,4
sldi 9,9,32
mtvsrd 1,9
xscvspdpn 1,1
blr

Note, there is a direct move from the FPR/vector registers, the logical
operation is done in the GPR registers and then a direct move back to the
FPR/vector registers.

After the changes, the code for power8 is:

xscvdpspn 0,1
sldi 9,4,32
mtvsrd 32,9
xxland 1,0,32
xscvspdpn 1,1
blr

In this case, we avoid a direct register move from the FPR/vector registers to
the GPR registers, and we do the logical operation in the vector registers.

If we look at the power10/power9 code, it is:

xscvdpspn 0,1
mfvsrwz 2,0
and 2,2,4
mtvsrws 1,2
xscvspdpn 1,1
blr

I.e. we do 2 direct moves between the GPR registers and the FPR/vector
registers and do the logical operation in the GPR registers.

The reason for this is we have the MTVSRWS instruction in power9/power10 (splat
bottom 32-bits of a GPR register into a FPR register).  In the power8 case, we
don't have MTVSRWS, so instead we need to do a shift left 32-bits (SLDI) and
then direct move to the FPR/vector registers before we can do XSCVSPDPN.

The XSCVSPDPN instruction wants the value in the upper 32-bits.  We do this
either by a left shift or by a splat operation.

To fix this, we would need a similar define_peephole2 to the one around line
6318 of vsx.md that matches using the splat operation instead of a shift and
64-bit move.

[Bug bootstrap/117488] New: Building a gcc cross-compiler for hppa fails

[bart.vanassche at gmail dot com via Gcc-bugs]

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

Bug ID: 117488
   Summary: Building a gcc cross-compiler for hppa fails
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bart.vanassche at gmail dot com
  Target Milestone: ---

Created attachment 59559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59559&action=edit
build-gcc-hppa

The attached script builds a hppa cross-compiler from the gcc source code. This
script worked fine with previous versions of gcc but fails as follows with the
gcc git commit (e97179bacd06 ("libstdc++: Improve comment for
_Hashtable::_M_insert_unique_node")):
~~~
In file included from ../include/atomic.h:49,
 from dl-find_object.c:20:
In function '_dlfo_update_init_seg',
inlined from '_dl_find_object_update_1' at dl-find_object.c:689:30,
inlined from '_dl_find_object_update' at dl-find_object.c:805:13:
../sysdeps/unix/sysv/linux/hppa/atomic-machine.h:44:4: error:
'__atomic_store_4' writing 4 bytes into a region of size 0 overflows the
destination [-Werror=stringop-overflow=]
   44 |__atomic_store_n ((mem), (val), __ATOMIC_RELAXED);  
 \
  |^
dl-find_object.c:644:3: note: in expansion of macro 'atomic_store_relaxed'
  644 |   atomic_store_relaxed (&seg->size, new_seg_size);
  |   ^~~~
In function '_dl_find_object_update':
cc1: note: destination object is likely at address zero
cc1: all warnings being treated as errors
make[2]: *** [../o-iterator.mk:9:
/home/bart/software/glibc-build/elf/dl-find_object.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [Makefile:484: elf/subdir_lib] Error 2
make: *** [Makefile:9: all] Error 2
~~~
Version of the kernel source tree: commit 906bd684e4b1 ("Merge tag
'spi-fix-v6.12-rc6' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi"; )

[Bug bootstrap/117488] Building a gcc cross-compiler for hppa fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to Andreas Schwab from comment #13)
> > Note again the only reason clang 17 from opensuse works is because it is
> > using GCC's libstdc++ from GCC 7
> 
> This is not true.

It seems to be true for Sebastian, because if clang was using the gcc-13
headers then the example would not compile.

Maybe it's using gcc-9 headers, or something else, but I don't think it's using
the gcc-13 ones.

Adding -v to the clang invocation would tell us.

[Bug c/117476] [15 regression] bad generated code from -finline-small-functions

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
(In reply to David Binderman from comment #2)
> Partially reduced code:
> 
:59:20: warning: iteration 6 invokes undefined behavior
[-Waggressive-loop-optimizations]
   59 |   crc32_tab[i] = crc;
  |   ~^
:48:16: note: within this loop
   48 |  for (i; i < 256; i++) {
  |  ~~^

Please reduce with something like: -Werror=uninitialized
-Werror=aggressive-loop-optimizations -Werror=sequence-point.

[Bug tree-optimization/117467] [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

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

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

commit r15-5008-g7a07de2c60b3c513b6aef206e9b55b3ffefe8b39
Author: Richard Biener 
Date:   Thu Nov 7 09:23:03 2024 +0100

rtl-optimization/117467 - 33% compile-time in rest of compilation

ext-dce uses TV_NONE, that's not OK for a pass taking 33% compile-time.
The following adds a timevar to it for proper blaming.

PR rtl-optimization/117467
* timevar.def (TV_EXT_DCE): New.
* ext-dce.cc (pass_data_ext_dce): Use TV_EXT_DCE.

[Bug rtl-optimization/117477] New: aarch64: Unnecessary stack spill generated around function call

[dhruvc at nvidia dot com via Gcc-bugs]

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

Bug ID: 117477
   Summary: aarch64: Unnecessary stack spill generated around
function call
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhruvc at nvidia dot com
  Target Milestone: ---

Given the following input:

int test (int x), test2 (int x);

int foo (int x, int y) {
test (x);
int lhs = test2 (y);
return x + lhs;
}

GCC 15.0 generates the following assembly at -O2:

foo:
stp x29, x30, [sp, -48]!
mov x29, sp
str x19, [sp, 16]
mov w19, w0
str w1, [sp, 44]
bl  test
ldr w0, [sp, 44]
bl  test2
add w0, w19, w0
ldr x19, [sp, 16]
ldp x29, x30, [sp], 48
ret

The stack spill around the call to `test` is unnecessary, and LLVM does not
generate it:

foo:
stp x29, x30, [sp, #-32]!
stp x20, x19, [sp, #16]
mov x29, sp
mov w19, w1
mov w20, w0
bl  test
mov w0, w19
bl  test2
add w0, w0, w20
ldp x20, x19, [sp, #16]
ldp x29, x30, [sp], #32
ret

clang commit: bbc3af0577a05bf5c06f5c39d51b7d48bd63d65f

This issue seems to intermittently occur in older versions, and is not present
in 14.2.0 or 13.3.0.

CE: https://godbolt.org/z/rK7P4jffh

[Bug tree-optimization/116578] vectorizer SLP transition issues / dependences

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

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

--- Comment #3 from Richard Biener  ---
The linaro CI reports 184 regressions on aarch64:
https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/8871/artifact/artifacts/artifacts.precommit/notify/mail-body.txt

4 regressions on arm:
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/9998/artifact/artifacts/artifacts.precommit/notify/mail-body.txt

and the risc-v CI around 1634/61 (I always forget what N/M is here)
https://github.com/ewlu/gcc-precommit-ci/issues/2535#issuecomment-2459996217

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #2)
> This was p0883r2 :
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0883r2.pdf
> 
> Which was the change in C++20.

Which was implemented in r10-5914-ge4379a931d140a

[Bug c/117476] [15 regression] bad generated code from -finline-small-functions

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||wrong-code
Summary|bad generated code from |[15 regression] bad
   |-finline-small-functions|generated code from
   ||-finline-small-functions

--- Comment #1 from Sam James  ---
r15-4967-gc7518891483e2a doesn't have this behaviour indeed, so presumably the
ifcombine changes from oliva, but not verified yet.

[Bug c/117476] [15 regression] bad generated code from -finline-small-functions

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Partially reduced code:

void  printf ();
void
platform_main_end(int crc)
{
 printf ("checksum = %X\n", crc);
}
int crc32_tab[6];
int crc32_context = 4294967295;

void
crc32_byte (char b) {
 crc32_context =
  crc32_context >> 8 & 16777215 ^
  crc32_tab[(crc32_context ^ b) & 255];
}
static void
transparent_crc (long val)

 {
 long __trans_tmp_1 = val;

  {char b = val;

   crc32_context =
crc32_context >> 8 & 16777215 ^
crc32_tab[(crc32_context ^ val) & 255];
  }

  ;
  crc32_byte (val>>8) ;
  crc32_byte (val>>16) ;
  crc32_byte (val>>24) ;
  crc32_byte (val>>32) ;
  crc32_byte (val>>40) ;
  crc32_byte (val>>48) ;
  crc32_byte (val>>56) ;
 }
int g_2 ;
void  main ()
{
{

 int i, j;

 i = 0;

 for (i; i < 256; i++) {
  unsigned crc = i;
  j = 8;

  for (j; j ; j--)
   if (crc & 1)
crc = crc >> 1 ^ 3988292384;
else
crc >>= 1;


  crc32_tab[i] = crc;
 }
   }

;

g_2 = -3;

transparent_crc(g_2);
platform_main_end(crc32_context ^ 4294967295);
}

[Bug c++/117294] Concept swallow diagnostics when they're defined in terms of type traits

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org

--- Comment #4 from Nathaniel Shead  ---
At least for type traits defined directly in terms of compiler builtins I feel
it should be possible to provide better errors here.

I've posted a patch here
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667976.html for comment
that would open the road to improving this, though I'm not sure that this is
the best way to go about it.

[Bug target/98189] [SH] ICE and segmentation fault with -O2 and without -fno-guess-branch-probability when building gdal

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #6 from John Paul Adrian Glaubitz  ---
This is still reproducible with GCC 14:

(unstable-sh4-sbuild)glaubitz@adams:~/gdal/gdal-3.9.3+dfsg/build-py3.12/frmts/pcraster$
/usr/bin/g++-14 -DDONT_DEPRECATE_SPRINTF -DGDAL_COMPILATION -DUSE_IN_GDAL
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/apps
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/alg
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/gcore
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/build-py3.12/gcore
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/port
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/build-py3.12/port
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/ogr
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/ogr/ogrsf_frmts
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/libcsf -g -O2
-ffile-prefix-map=/home/glaubitz/gdal/gdal-3.9.3+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
-fvisibility=hidden -fPIC -Wall -Wextra -Winit-self -Wunused-parameter
-Wmissing-declarations -Wlogical-op -Wshadow -Wmissing-include-dirs -Wformat
-Werror=format-security -Wno-format-nonliteral -Werror=vla -Wno-clobbered
-Wdate-time -Wnull-dereference -Wextra-semi -Wfloat-conversion
-Wnon-virtual-dtor -Woverloaded-virtual -Wsuggest-override -fno-operator-names
-Wzero-as-null-pointer-constant -std=gnu++17 -MD -MT
frmts/pcraster/CMakeFiles/gdal_PCRaster.dir/pcrasterutil.cpp.o -MF
CMakeFiles/gdal_PCRaster.dir/pcrasterutil.cpp.o.d -o
CMakeFiles/gdal_PCRaster.dir/pcrasterutil.cpp.o -c
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp
during RTL pass: mach
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp: In
function 'void castValuesToBooleanRange(void*, size_t, CSF_CR)':
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp:785:1:
internal compiler error: Segmentation fault
  785 | }
  | ^
0x15af0a5 internal_error(char const*, ...)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
(unstable-sh4-sbuild)glaubitz@adams:~/gdal/gdal-3.9.3+dfsg/build-py3.12/frmts/pcraster$

With an LRA-enabled GCC 15 (20241004) based on Oleg Endo's tree with the
additional patches 59432 and 59550 from PR target/55212, I'm getting a
different ICE:

(unstable-sh4-sbuild)glaubitz@adams:~/gdal/gdal-3.9.3+dfsg/build-py3.12/frmts/pcraster$
/usr/lib/gcc-snapshot/bin/c++ -DDONT_DEPRECATE_SPRINTF -DGDAL_COMPILATION
-DUSE_IN_GDAL -I/home/glaubitz/gdal/gdal-3.9.3+dfsg/apps
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/alg
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/gcore
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/build-py3.12/gcore
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/port
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/build-py3.12/port
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/ogr
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/ogr/ogrsf_frmts
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts
-I/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/libcsf -g -O2
-ffile-prefix-map=/home/glaubitz/gdal/gdal-3.9.3+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
-fvisibility=hidden -fPIC -Wall -Wextra -Winit-self -Wunused-parameter
-Wmissing-declarations -Wlogical-op -Wshadow -Wmissing-include-dirs -Wformat
-Werror=format-security -Wno-format-nonliteral -Werror=vla -Wno-clobbered
-Wdate-time -Wnull-dereference -Wextra-semi -Wfloat-conversion
-Wnon-virtual-dtor -Woverloaded-virtual -Wsuggest-override -fno-operator-names
-Wzero-as-null-pointer-constant -std=gnu++17 -MD -MT
frmts/pcraster/CMakeFiles/gdal_PCRaster.dir/pcrasterutil.cpp.o -MF
CMakeFiles/gdal_PCRaster.dir/pcrasterutil.cpp.o.d -o
CMakeFiles/gdal_PCRaster.dir/pcrasterutil.cpp.o -c
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp: In
function 'std::string valueScale2String(CSF_VS)':
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp:149:13:
note: non-delegitimized UNSPEC UNSPEC_GOTOFF (6) found in variable location
  149 | std::string valueScale2String(CSF_VS valueScale)
  | ^
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp:149:13:
note: non-delegitimized UNSPEC UNSPEC_GOTOFF (6) found in variable location
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp: In
function 'std::string cellRepresentation2String(CSF_CR)':
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp:213:13:
note: non-delegitimized UNSPEC UNSPEC_GOTOFF (6) found in variable location
  213 | std::string cellRepresentation2String(CSF_CR cellRepresentation)
  | ^
/home/glaubitz/gdal/gdal-3.9.3+dfsg/frmts/pcraster/pcrasterutil.cpp:213:13:
note: non-delegitimized UNSPEC UNSPEC_GOTOFF

[Bug c++/117479] ICE on x86_64-linux-gnu: in cxx_eval_constant_expression, at cp/constexpr.cc:8448 with vector_size

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed||2024-11-07
   Priority|P3  |P5
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Even GCC 5 ICEs.

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I must say whomever invented those -ObjC etc. flags had very bad taste for
naming options...

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

[eschwartz93 at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Eli Schwartz  ---
(In reply to Sergey Fedorov from comment #11)
> Do you mean that even with the correct flag passed, the code won’t compile
> with gcc14? While I have gcc15 locally (not updating it weekly though), few
> people will until it is officially released and adopted by downstream
> distributions.


No, I'm saying that projects that pass -ObjC won't ever compile with GCC 14
because GCC 14 won't gain support for -ObjC even if GCC 15 does.

The solution is therefore to check whether it is possible to pass -ObjC before
doing so (or use -x).

Again, it's still an interesting idea to add -ObjC support to GCC 15.

[Bug c++/115560] ICE: in type_dependent_expression_p, at cp/pt.cc:28576

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Got fixed by r15-3532:

commit 7cebc6384a0ad63d444029472a8ed1afe965bbbc
Author: Jason Merrill 
Date:   Fri Sep 6 15:28:53 2024 -0400

c++: exception spec and stdlib specialization

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

[sebastian.huber--- via Gcc-bugs]

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

--- Comment #17 from Sebastian Huber  ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Andreas Schwab from comment #13)
> > > Note again the only reason clang 17 from opensuse works is because it is
> > > using GCC's libstdc++ from GCC 7
> > 
> > This is not true.
> 
> It seems to be true for Sebastian, because if clang was using the gcc-13
> headers then the example would not compile.
> 
> Maybe it's using gcc-9 headers, or something else, but I don't think it's
> using the gcc-13 ones.
> 
> Adding -v to the clang invocation would tell us.

The clang 17.0.6 on my machine seems to use the GCC 7 libstdc++. Sorry for the
false positive.

clang -Wall -Wextra -std=c++20 -pedantic -xc++ -v -S test.cc -o -
clang version 17.0.6
Target: x86_64-suse-linux
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/7
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/7
Candidate multilib: .;@m64
Selected multilib: .;@m64
 (in-process)
 "/usr/bin/clang-17" -cc1 -triple x86_64-suse-linux -S -disable-free
-clear-ast-before-backend -disable-llvm-verifier -discard-value-names
-main-file-name test.cc -mrelocation-model pic -pic-level 2 -pic-is-pie
-mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math
-mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic
-debugger-tuning=gdb -v
-fcoverage-compilation-dir=/home/EB/sebastian_h/src/bug-cxx20-atomics
-resource-dir /usr/lib64/clang/17 -internal-isystem
/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../../include/c++/7
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../../include/c++/7/x86_64-suse-linux
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../../include/c++/7/backward
-internal-isystem /usr/lib64/clang/17/include -internal-isystem
/usr/local/include -internal-isystem
/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include -Wall
-Wextra -pedantic -std=c++20 -fdeprecated-macro
-fdebug-compilation-dir=/home/EB/sebastian_h/src/bug-cxx20-atomics
-ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fcxx-exceptions
-fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o -
-x c++ test.cc
clang -cc1 version 17.0.6 based upon LLVM 17.0.6 default target
x86_64-suse-linux
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../../include/c++/7

/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../../include/c++/7/x86_64-suse-linux
 /usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../../include/c++/7/backward
 /usr/lib64/clang/17/include
 /usr/local/include

/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.
.text
.file   "test.cc"
.type   obj,@object # @obj
.bss
.globl  obj
.p2align2, 0x0
obj:
.zero   4
.size   obj, 4

.section".linker-options","e",@llvm_linker_options
.ident  "clang version 17.0.6"
.section".note.GNU-stack","",@progbits
.addrsig

[Bug target/117468] [12/13/14/15 Regression] arm thumb1 high reg restoration trashes register reserved with -ffixed-reg

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.1.0
  Known to work||9.5.0
Summary|arm thumb1 high reg |[12/13/14/15 Regression]
   |restoration trashes |arm thumb1 high reg
   |register reserved with  |restoration trashes
   |-ffixed-reg |register reserved with
   ||-ffixed-reg
   Target Milestone|--- |12.5

[Bug target/117366] [12/13/14/15 regression] arm thumb1 epilogue size optimizer violates -ffixed

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

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

Sam James  changed:

   What|Removed |Added

  Known to work||4.5.4
   Target Milestone|--- |12.5
  Known to fail||15.0, 4.6.0
Summary|arm thumb1 epilogue size|[12/13/14/15 regression]
   |optimizer violates -ffixed  |arm thumb1 epilogue size
   ||optimizer violates -ffixed

[Bug c/117476] New: bad generated code from -finline-small-functions

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 117476
   Summary: bad generated code from -finline-small-functions
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 59552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59552&action=edit
C source code

For the attached C code:

foundBugs $ ~/gcc/results/bin/gcc -v 2>&1 | grep exp
gcc version 15.0.0 20241107 (experimental) (4473cf8409f4db19) 
foundBugs $ ~/gcc/results/bin/gcc -g -O1  bug1062.c
foundBugs $ ./a.out
checksum = 6361D861
foundBugs $ ~/gcc/results/bin/gcc -g -O1 -finline-small-functions bug1062.c
foundBugs $ ./a.out
Segmentation fault (core dumped)
foundBugs $ 

And yet a couple of days ago:

foundBugs $ ~/gcc/results.20241105.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 15.0.0 20241105 (experimental) (e152a734337a06ed) 
foundBugs $ ~/gcc/results.20241105.asan.ubsan/bin/gcc -g -O1  bug1062.c &&
./a.out
checksum = 6361D861
foundBugs $ ~/gcc/results.20241105.asan.ubsan/bin/gcc -g -O1
-finline-small-functions  bug1062.c && ./a.out
checksum = 6361D861
foundBugs $

[Bug target/117481] New: ICE: maximum number of generated reload insns per insn achieved (90) with -O -mrvv-vector-bits=zvl -march=rv64gcv -mabi=lp64e

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 117481
   Summary: ICE: maximum number of generated reload insns per insn
achieved (90) with -O -mrvv-vector-bits=zvl
-march=rv64gcv -mabi=lp64e
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

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

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O -mrvv-vector-bits=zvl -march=rv64gcv
-mabi=lp64e testcase.c 
cc1: warning: LP64E ABI is marked for deprecation in GCC [-Wdeprecated]
cc1: note: if you need LP64E please notify the GCC project via PR116152
during RTL pass: reload
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
   11 | }
  | ^
0x33b1bee internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:518
0x15d066d lra_constraints(bool)
/repo/gcc-trunk/gcc/lra-constraints.cc:5405
0x15b6254 lra(_IO_FILE*, int)
/repo/gcc-trunk/gcc/lra.cc:2445
0x1561ddf do_reload
/repo/gcc-trunk/gcc/ira.cc:5977
0x1561ddf execute
/repo/gcc-trunk/gcc/ira.cc:6165
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

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

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

[vital.had at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Sergey Fedorov  ---
(In reply to Eli Schwartz from comment #9)
> It's not a bad idea to "fix" it from both ends.
> 
> Projects such as gegl cannot compile on macOS using GCC 13 or 14, and that's
> not going to change. They can't really know what versions their users have
> installed, so the only real choice to support this case is to do a configure
> probe.
> 
> Not all projects will fix that, so the best that GCC can do is make those
> projects work with GCC 15.

Do you mean that even with the correct flag passed, the code won’t compile with
gcc14? While I have gcc15 locally (not updating it weekly though), few people
will until it is officially released and adopted by downstream distributions.

Gegl 0.4.48 built fine with gcc14 (but that was before -ObjC addition).

[Bug c++/78620] C++11, Padding bytes not zero-intialized when POD is initialized with compiler generated default constructor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
>From what I can see, on the given testcase with struct tm this was on aarch64
"fixed" with the r11-4973-g54bbde550ec55 changes.
But PR117256 shows something that still reproduces on the trunk.

[Bug c++/117462] internal compiler error: comptypes(tree_node*, tree_node*, int)

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
The ICE started with r9-3836-g4be5c72cf3ea3e:

commit 4be5c72cf3ea3ee98a97ac2e53d21122ad224b10
Author: Jason Merrill 
Date:   Mon Nov 5 02:47:02 2018 -0500

Implement P0732R2, class types in non-type template parameters.

[Bug rtl-optimization/117476] [15 regression] bad generated code from -finline-small-functions since r15-4991-g69bd93c167fefb

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

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

Sam James  changed:

   What|Removed |Added

  Known to fail||15.0
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-07
 Status|UNCONFIRMED |NEW
  Known to work||14.2.1

--- Comment #6 from Sam James  ---
Thanks.

```
int tab[1024];
int ctx = 0x00FF;

int main() {
  ctx = tab[(ctx ^ -1) & 0xFF];
  if (ctx != 0) {
__builtin_abort();
  }
}
```

[Bug target/98189] [SH] ICE and segmentation fault with -O2 and without -fno-guess-branch-probability when building gdal

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
Passing -fno-guess-branch-probability still helps, even with the LRA-enabled
GCC 15.

[Bug target/116725] operand size mismatch for vfpclasssd and vfpclassss when using -masm=intel for AVX512 builtins

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:0dadf022de293c202ab21b0aeed7c9a4511f57d5

commit r15-5011-g0dadf022de293c202ab21b0aeed7c9a4511f57d5
Author: Jakub Jelinek 
Date:   Thu Nov 7 13:20:20 2024 +0100

testsuite: Fix up pr116725.c test [PR116725]

On Fri, Oct 18, 2024 at 02:05:59PM -0400, Antoni Boucher wrote:
> PR target/116725
> * gcc.target/i386/pr116725.c: Add test using those AVX
builtins.

This test FAILs for me, as I don't have the latest gas around and the test
is dg-do assemble, so doesn't need just fixed compiler, but also assembler
which supports those instructions.

The following patch adds effective target directives to ensure assembler
supports those too.

2024-11-07  Jakub Jelinek  

PR target/116725
* gcc.target/i386/pr116725.c: Add dg-require-effective-target
avx512{dq,fp16,vl}.

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

[eschwartz93 at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Eli Schwartz  ---
It's not a bad idea to "fix" it from both ends.

Projects such as gegl cannot compile on macOS using GCC 13 or 14, and that's
not going to change. They can't really know what versions their users have
installed, so the only real choice to support this case is to do a configure
probe.

Not all projects will fix that, so the best that GCC can do is make those
projects work with GCC 15.

Also yes, that is such a lame flag naming convention...

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

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

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

--- Comment #10 from Jakub Jelinek  ---
-xobjective-c should work fine with both gcc and clang and is much better
designed, it isn't about two almost dead languages, but allows specifying any
language the compiler supports.

[Bug rtl-optimization/117476] [15 regression] bad generated code from -finline-small-functions since r15-4991-g69bd93c167fefb

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

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

Sam James  changed:

   What|Removed |Added

  Component|c   |rtl-optimization
Summary|[15 regression] bad |[15 regression] bad
   |generated code from |generated code from
   |-finline-small-functions|-finline-small-functions
   ||since
   ||r15-4991-g69bd93c167fefb
 CC||alexey.merzlyakov at samsung 
dot c
   ||om, law at gcc dot gnu.org

--- Comment #4 from Sam James  ---
Looks like r15-4991-g69bd93c167fefb.

(Also, can we please avoid using "[RISC-V]" in non-riscv specific commits in
future? The CI can handle it if you CC it instead.)

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

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

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > testcase which works with clang but fails with GCC:
> 
> But that was fixed in GCC 13. Let me see if I can find the bug report ...

r13-1783:

c++: defaulted ctor with DMI in union [PR94823]

CWG2084 clarifies that a variant member with a non-trivial constructor does
not make the union's defaulted default constructor deleted if another
variant member has a default member initializer.

[Bug c++/117475] C++20: Union object with atomic integer cannot be statically initialized

[schwab--- via Gcc-bugs]

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

--- Comment #13 from Andreas Schwab  ---
> Note again the only reason clang 17 from opensuse works is because it is
> using GCC's libstdc++ from GCC 7

This is not true.

$ clang -Wall -Wextra -std=c++20 -pedantic -S atomic.cc -v
clang version 17.0.6
Target: x86_64-suse-linux
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/11
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/12
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/13
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/7
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/8
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/9
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/13
Candidate multilib: .;@m64
Selected multilib: .;@m64
 (in-process)
 "/usr/bin/clang-17" -cc1 -triple x86_64-suse-linux -S -disable-free
-clear-ast-before-backend -disable-llvm-verifier -discard-value-names
-main-file-name atomic.cc -mrelocation-model pic -pic-level 2 -pic-is-pie
-mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math
-mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic
-debugger-tuning=gdb -v -fcoverage-compilation-dir=/suse/schwab/src/test
-resource-dir /usr/lib64/clang/17 -internal-isystem
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/x86_64-suse-linux
-internal-isystem
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/backward
-internal-isystem /usr/lib64/clang/17/include -internal-isystem
/usr/local/include -internal-isystem
/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include -Wall
-Wextra -pedantic -std=c++20 -fdeprecated-macro
-fdebug-compilation-dir=/suse/schwab/src/test -ferror-limit 19
-fgnuc-version=4.2.1 -fno-implicit-modules -fcxx-exceptions -fexceptions
-fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o atomic.s -x c++
atomic.cc
clang -cc1 version 17.0.6 based upon LLVM 17.0.6 default target
x86_64-suse-linux
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13

/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/x86_64-suse-linux
 /usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/backward
 /usr/lib64/clang/17/include
 /usr/local/include

/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.

[Bug rtl-optimization/117476] [15 regression] bad generated code from -finline-small-functions since r15-4991-g69bd93c167fefb

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to Sam James from comment #3)
> Please reduce with something like: -Werror=uninitialized
> -Werror=aggressive-loop-optimizations -Werror=sequence-point.

Thanks. Second try:

void  printf ();
void
platform_main_end(int crc)
{
 printf ("checksum = %X\n", crc);
}
int crc32_tab[256];
int crc32_context = 0xUL;

void
crc32_gentab ()
{

 int i, j;

 for (i = 0; i < 256; i++) {
  unsigned crc = i;
  for (j = 8; j ; j--)
   if (crc & 1)
crc = (crc >> 1) ^ 0xEDB88320UL;
else
crc >>= 1;


  crc32_tab[i] = crc;
 }
}
void
crc32_byte (char b) {
 crc32_context =
  ((crc32_context >> 8) & 0x00FF) ^
  crc32_tab[(crc32_context ^ b) & 0xFF];
}
static void
transparent_crc (long val)
{
 {
 long __trans_tmp_1 = val;
 {
  crc32_byte ((__trans_tmp_1) );
  crc32_byte ((__trans_tmp_1>>8) );
  crc32_byte ((__trans_tmp_1>>16) );
  crc32_byte ((__trans_tmp_1>>24) );
  crc32_byte ((__trans_tmp_1>>32) );
  crc32_byte ((__trans_tmp_1>>40) );
  crc32_byte ((__trans_tmp_1>>48) );
  crc32_byte ((__trans_tmp_1>>56) );
 }}
}
int g_2 ;
void  main ()
{
crc32_gentab();
{
g_2 = (-3);
}
transparent_crc(g_2);
platform_main_end(crc32_context ^ 0xUL);
}

[Bug c++/117479] New: ICE on x86_64-linux-gnu: in cxx_eval_constant_expression, at cp/constexpr.cc:8448 with vector_size

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 117479
   Summary: ICE on x86_64-linux-gnu: in
cxx_eval_constant_expression, at cp/constexpr.cc:8448
with vector_size
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/W8v9x3bde

***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap --enable-checking=yes
--prefix=/home/software/gcc-trunk --enable-sanitizers --enable-languages=c,c++
--disable-werror --enable-multilib --enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241107 (experimental) (GCC)

***
Program:
$ cat mutant.C
struct {
  int a;
  __attribute__((vector_size(4))) int c { a };
} constexpr b {
};

***
Command Lines:
$ gcc mutant.C
mutant.C:5:1: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.cc:8448
5 | }
  | ^
0x5cdf4f4 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:518
0x5c807b6 fancy_abort(char const*, int, char const*)
../../gcc/gcc/diagnostic.cc:1696
0xf7d3b4 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8448
0xf6a9c4 cxx_eval_indirect_ref
../../gcc/gcc/cp/constexpr.cc:5995
0xf78f14 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:7874
0xf60932 cxx_eval_component_reference
../../gcc/gcc/cp/constexpr.cc:4598
0xf79a0a cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8047
0xf65f51 cxx_eval_bare_aggregate
../../gcc/gcc/cp/constexpr.cc:5369
0xf79f46 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8107
0xf65f51 cxx_eval_bare_aggregate
../../gcc/gcc/cp/constexpr.cc:5369
0xf79f46 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.cc:8107
0xf8102a cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.cc:8880
0xf84107 maybe_constant_init_1
../../gcc/gcc/cp/constexpr.cc:9391
0xf84244 cxx_constant_init(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.cc:9417
0x169a16b store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/gcc/cp/typeck2.cc:910
0x109512a check_initializer
../../gcc/gcc/cp/decl.cc:7880
0x10a122f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
../../gcc/gcc/cp/decl.cc:8933
0x1383414 cp_parser_init_declarator
../../gcc/gcc/cp/parser.cc:23919
0x1364c5a cp_parser_simple_declaration
../../gcc/gcc/cp/parser.cc:16165
0x1364376 cp_parser_block_declaration
../../gcc/gcc/cp/parser.cc:15984
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug objc/117478] New: -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

[vital.had at gmail dot com via Gcc-bugs]

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

Bug ID: 117478
   Summary: -ObjC is not accepted: error: argument to '-O' should
be a non-negative integer, 'g', 's', 'z' or 'fast'
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vital.had at gmail dot com
CC: iains at gcc dot gnu.org
  Target Milestone: ---
Target: *-apple-darwin

This is not the first time building something fails because clang-specific flag
is passed unconditionally. Now it is gegl:

FAILED: libs/npd/libgegl-npd-0.4.dylib.p/graphics.c.o 
ccache /opt/local/bin/gcc-mp-14 -Ilibs/npd/libgegl-npd-0.4.dylib.p -Ilibs/npd
-I../gegl-0.4.50/libs/npd -Igegl -I../gegl-0.4.50/gegl -Igegl/buffer
-I../gegl-0.4.50/gegl/buffer -Igegl/graph -I../gegl-0.4.50/gegl/graph
-Igegl/module -I../gegl-0.4.50/gegl/module -Igegl/opencl
-I../gegl-0.4.50/gegl/opencl -Igegl/operation -I../gegl-0.4.50/gegl/operation
-Igegl/process -I../gegl-0.4.50/gegl/process -Igegl/property-types
-I../gegl-0.4.50/gegl/property-types -I/opt/local/include/glib-2.0
-I/opt/local/lib/glib-2.0/include -I/opt/local/include/babl-0.1
-I/opt/local/include -fdiagnostics-color=always -Wall -Winvalid-pch -std=gnu11
-O2 -g -DHAVE_CONFIG_H -DGEGL_ENABLE_DEBUG -Winit-self -Wmissing-declarations
-Wpointer-arith -Wno-unused-parameter -Wno-cast-function-type -ftree-vectorize
-Wmissing-prototypes -Wold-style-definition -ObjC -pipe -Os -arch ppc -MD -MQ
libs/npd/libgegl-npd-0.4.dylib.p/graphics.c.o -MF
libs/npd/libgegl-npd-0.4.dylib.p/graphics.c.o.d -o
libs/npd/libgegl-npd-0.4.dylib.p/graphics.c.o -c
../gegl-0.4.50/libs/npd/graphics.c
cc1: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or
'fast'

While this is of course an upstream bug, there are quite a number of such
instances, and not every upstream will bother fixing their build system for
what they may consider a minority case (using GCC on macOS).
AFAICT, this flag is redundant with GCC, and just dropping it works fine.
Perhaps if it cannot be supported in a meaningful way, at least ignore it
instead of failing?

[Bug rtl-optimization/117476] [15 regression] bad generated code from -finline-small-functions since r15-4991-g69bd93c167fefb

[alexey.merzlyakov at samsung dot com via Gcc-bugs]

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

--- Comment #7 from Alexey Merzlyakov  ---
Thank you for the issue simplification the repro-case. Confirming: the problem
exists on trunk since r15-4991-g69bd93c167fefb. Working on it.

[Bug c/117065] [15 regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_padding_at_level_p, at gimple-fold.cc:4820

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #4 from Marek Polacek  ---
Started with r15-3328:

commit 673a448aa24efedd5ac140ebf7bfe652d7a6a846
Author: Alexandre Oliva 
Date:   Sat Aug 31 06:03:12 2024 -0300

Optimize initialization of small padded objects

[Bug rtl-optimization/117476] [15 regression] bad generated code from -finline-small-functions since r15-4991-g69bd93c167fefb

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

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

Sam James  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |alexey.merzlyakov at 
samsung dot c
   ||om
 Status|NEW |ASSIGNED

--- Comment #8 from Sam James  ---
Thanks for looking so quickly!

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

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

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

--- Comment #4 from Iain Sandoe  ---
-ObjC is not exactly clang-specific - AFAIR it was supported by Apple gcc-4.x
as well,

Perhaps we can support it as a driver flag (which is used as shorthand for -x
objective-c)

I'm short of time at the moment to try this, but will do so at some point (or
I'd be happy to review a patch to do so).

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

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

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

--- Comment #1 from Andrew Pinski  ---
> AFAICT, this flag is redundant with GCC

No the correct flag is -xobjc

[Bug rtl-optimization/117477] aarch64: Unnecessary stack spill generated around function call

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

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

--- Comment #1 from Andrew Pinski  ---
Both are the same.

Gcc choices a stack location rather than a calee save register which is also
saved/restored from the stackq.

The cost of knowing that using another callee saved register is not known to be
almost free with the stp/ldp instructions might not be taken into account.  I
suspect you could make a case where gcc does the right thing and llvms register
allocator still goes for the callee saved register

[Bug rtl-optimization/117476] [15 regression] bad generated code from -finline-small-functions since r15-4991-g69bd93c167fefb

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

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

Sam James  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #9 from Sam James  ---
*** Bug 117480 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/117480] wrong code at -O1 and above on x86_64-linux-gnu

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #1 from Sam James  ---
Dupe of PR117476 (thank you!)

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

[Bug rtl-optimization/117476] [15 regression] bad generated code from -finline-small-functions since r15-4991-g69bd93c167fefb

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

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

--- Comment #10 from Sam James  ---
The dupe PR117480 has a nicer testcase.

[Bug objc/117478] -ObjC is not accepted: error: argument to '-O' should be a non-negative integer, 'g', 's', 'z' or 'fast'

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

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

--- Comment #6 from Iain Sandoe  ---
fine with fixing it upstream - but also OK with trying to be compatible (esp.
with facilities that were present for ≈ 20 years, if those are not to intrusive
to arrange).

[Bug rtl-optimization/117476] [15 regression] bad generated code at -O1 since r15-4991-g69bd93c167fefb

[alexey.merzlyakov at samsung dot com via Gcc-bugs]

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

--- Comment #11 from Alexey Merzlyakov  
---
Analysis shown that the problem seem is related to incorrect check in the
optimization, introduced by the aforementioned patch:

(zero_extend:M (subreg:N (not:M (X:M -> (xor:M (X:M, mask))

In this patch the condition

(nonzero_bits (XEXP (XEXP (op, 0), 0), mode)
 & ~GET_MODE_MASK (mode)) == 0)

should verify that X:M doesn't have any non-zero bits outside of mode N.
However, it seems that the in the last part of this check I've made a mistake.
To verify the "outside mode N" part, we need to change

 & ~GET_MODE_MASK (mode)) == 0)

to the:

 & ~GET_MODE_MASK(GET_MODE (op))) == 0)

as "op" is in "N" mode, not in "mode" (M) itself.

If this turns out to be true, I will elaborate a patch to fix this issue in the
coming days.

[Bug tree-optimization/117467] [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

--- Comment #1 from Richard Biener  ---
Samples: 2M of event 'cycles:Pu', Event count (approx.): 2183019518772  
Overhead   Samples  Command  Shared Object Symbol   
  29.34%627170  f951 f951  [.]
bitmap_bit_p(bitmap_head const*, int)   
  10.68%231516  f951 f951  [.]
bitmap_set_bit(bitmap_head*, int)   
   5.62%122003  f951 f951  [.]
bitmap_set_range(bitmap_head*, unsigned int, unsigned int) [
   5.23%113260  f951 f951  [.]
bitmap_list_insert_element_after(bitmap_head*, bitmap_elemen
   4.23% 90654  f951 f951  [.] df_count_refs(bool,
bool, bool) 
   4.03% 87072  f951 f951  [.]
bitmap_ior_into(bitmap_head*, bitmap_head const*)   
   3.53% 77003  f951 f951  [.]
bitmap_copy(bitmap_head*, bitmap_head const*)   
   2.78% 59162  f951 f951  [.]
bitmap_and_compl_into(bitmap_head*, bitmap_head const*) 
   1.60% 34193  f951 f951  [.] lra_remat()  

yay.

  + 32.11% (anonymous namespace)::pass_ext_dce::execute(function*)  

is the "rest of compilation", fixing that.

[Bug tree-optimization/117467] [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
  - 32.11% (anonymous namespace)::pass_ext_dce::execute(function*) 
  ▒
 - ext_dce_execute()   
  ▒
- 32.10% df_worklist_dataflow(dataflow*, bitmap_head*, int*, int)  
  ▒
   - 32.08% ext_dce_rd_transfer_n(int) 
  ▒
  + 14.75% ext_dce_process_uses(rtx_insn*, rtx_def*,
bitmap_head*, bool)  ▒
  + 8.18% bitmap_ior_into(bitmap_head*, bitmap_head const*)
  ▒
  + 4.49% ext_dce_process_sets(rtx_insn*, rtx_def*,
bitmap_head*) ▒
3.34% bitmap_copy(bitmap_head*, bitmap_head const*)
  ▒
1.31% bitmap_equal_p(bitmap_head const*, bitmap_head
const*)

likely (unverified) also the source of 25GB memory use.

The DF problem seems seriously unoptimized - it lacks a separate "local"
compute
step (the ext_dce_process_sets part that populates live_tmp _per insn_!).

[Bug tree-optimization/117467] [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
>   - 32.11% (anonymous namespace)::pass_ext_dce::execute(function*)  
> ▒
>  - ext_dce_execute()
> ▒
> - 32.10% df_worklist_dataflow(dataflow*, bitmap_head*, int*,
> int) ▒
>- 32.08% ext_dce_rd_transfer_n(int)  
> ▒
>   + 14.75% ext_dce_process_uses(rtx_insn*, rtx_def*,
> bitmap_head*, bool)  ▒
>   + 8.18% bitmap_ior_into(bitmap_head*, bitmap_head const*) 
> ▒
>   + 4.49% ext_dce_process_sets(rtx_insn*, rtx_def*,
> bitmap_head*) ▒
> 3.34% bitmap_copy(bitmap_head*, bitmap_head const*) 
> ▒
> 1.31% bitmap_equal_p(bitmap_head const*, bitmap_head
> const*)
> 
> likely (unverified) also the source of 25GB memory use.
> 
> The DF problem seems seriously unoptimized - it lacks a separate "local"
> compute
> step (the ext_dce_process_sets part that populates live_tmp _per insn_!).

That is, usually the transfer function is the IOR of input and appropriate
IOR/whatever of the (cached!) local compute result.

[Bug libstdc++/108645] Change in behavior, std::accumulate doesn't always work as expected in C++20 builds

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Evan Teran from comment #1)
> Which results in the same behavior, so it appears to be that the:
> 
> ```
> basic_string operator+(basic_string &&, basic_string &&)
> ```
> 
> Overload doesn't steal the guts of the rhs at all?


Because it steals the guts of the LHS instead, which is fine because they're
both rvalues, and it's simpler to append to the LHS than to insert at the
beginning of the RHS.


> 
> But the 
> 
> ```
> basic_string operator+(const basic_string &, basic_string &&)
> ```
> 
> overload does?


Because it can't steal the guts from the const lvalue on the left.

Closing as not a bug because the current behaviour is conforming and I don't
see a compelling reason to change anything.

[Bug tree-optimization/117467] [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #4 from Richard Biener  ---
-   28.13%28.04%590285  f951 f951  [.]
bitmap_bit_p(bitmap_head const*, int)  ▒
   + 8.28% _start  
  ▒
   - 2.79% gimple_simplify_PLUS_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, ▒
  - 2.78% gimple_resimplify2(gimple**, gimple_match_op*, tree_node*
(*)(tree_node*))  ▒
 - gimple_simplify_MULT_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, ▒
- 2.26% pta_valueize(tree_node*)   
  ▒
 range_query::value_of_expr(tree_node*, gimple*)   
  ▒
   + gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
  ▒
   + 2.36% gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)  
  ▒
   + 2.23% gimple_simplify_POINTER_PLUS_EXPR(gimple_match_op*, gimple**,
tree_node* (*)(tree_node*), code_helper, tree▒
   + 2.07% fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*) ▒
   + 2.03% execute_ranger_vrp(function*, bool)  

this seems in the end all related to prange and pta_valueize?

[Bug tree-optimization/116578] vectorizer SLP transition issues / dependences

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

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

--- Comment #2 from Richard Biener  ---
On x86-64, apart from PR116973, there is only

FAIL: gcc.dg/vect/vect-early-break_20.c scan-tree-dump vect "LOOP VECTORIZED"

remaining with --param vect-force-slp=1

[Bug libstdc++/104222] std::basic_string::resize_and_overwrite passes an unexpected value to user's callable

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed by:
r14-3253-g4a2b262597e4a6  gcc-14.1.0
r13-8030-gf749564ca5e3d1  gcc-13.3.0
r12-10236-gb9d09c7cfcaeb7 gcc-12.4.0

[Bug tree-optimization/117467] [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-07
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
So confirmed the 25GB memory use is ext-dce, with -fno-ext-dce memory use is
donw to 3GB.  The time report then shows VRP as offender:

 tree VRP   :  76.20 ( 23%)   125M (  4%)
 dominator optimization :  28.30 (  8%)84M (  3%)

given 25GB memory use is going to trash most machines this is P1.

The testcase is quite small but has lots of calls with lots of arguments
that might or might not invoke fortran array copying, it's probably
difficult to reduce sensibly (it has lots of module USEs).  Jeff and Andrew
should have access to SPEC, so I won't spend time trying at this point.

[Bug tree-optimization/117467] [15 Regression] 521.wrf_r again explodes memory/compile-time wise

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Richard Biener from comment #5)
> So confirmed the 25GB memory use is ext-dce, with -fno-ext-dce memory use is
> donw to 3GB.  The time report then shows VRP as offender:
> 
>  tree VRP   :  76.20 ( 23%)   125M (  4%)
>  dominator optimization :  28.30 (  8%)84M (  3%)
> 
> given 25GB memory use is going to trash most machines this is P1.
> 
> The testcase is quite small but has lots of calls with lots of arguments
> that might or might not invoke fortran array copying, it's probably
> difficult to reduce sensibly (it has lots of module USEs).  Jeff and Andrew
> should have access to SPEC, so I won't spend time trying at this point.

Note I think PR 116758 is the recording the ranger/DOM/VRP side of things too.

[Bug c/117492] ICE: in decompose, at wide-int.h:1049 with __builtin_stdc_rotate_left/right()

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Sam James from comment #1)
> I don't think we have any folding for patterns into these yet so can't make
> it a regression.

We do fold sometimes into LROTATE_EXPR and RROTATE_EXPR but this is all
undefined code but only if is well defined.  This is undefined in this case.