[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1

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

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

--- Comment #4 from Richard Biener  ---
I'm OK with renaming (but then some namespace prefix would be nice, at least
two underscores, but __gcc_ might be better)

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Keywords||ABI
Summary|__builtin_nested_func_ptr_c |[14 Regression]
   |reated, |__builtin_nested_func_ptr_c
   |__builtin_nested_func_ptr   |reated,
   |should be dynamically   |__builtin_nested_func_ptr
   |linked by default   |should be dynamically
   ||linked by default
   Target Milestone|--- |14.0

--- Comment #7 from Richard Biener  ---
I'm marking this as regression since it affects the ABI.

[Bug analyzer/113333] analyzer: False positives with calloc()

[buczek at molgen dot mpg.de via Gcc-bugs]

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

--- Comment #4 from Donald Buczek  ---
Great, thank you!

I wonder, if the related missed optimization opportunity should also be
reported.

#include 
int f(void) {
char **vec = calloc(1, sizeof(char *));
if (vec) {
// *vec = NULL;
if (*vec)
return 1;
}
return 0;
}

This resolves to nothing only if the commented-out line is added.

https://gcc.godbolt.org/z/WTar6zdne

Treat: clang gets it right.

[Bug c++/113407] [11/12/13/14 Regression] internal_error with const char* as non-type template parameter with index parameter pack in fold expression

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/113411] ABS*ABS can be simplified to ABS

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I think it's OK for reals with -fno-rounding-math.

It's valid for integers with or without undefined overflow, the corner
case to consider is

  abs(-INT_MAX - 1) * abs (b)

where with undefined overflow the abs() is already invoking undefined
behavior.  The problematical multiplication is (-INT_MAX-1) * -1 but
we cannot arrive at this from a defined input.  For

  abs(a*b)

the problematical input is -INT_MAX - 1 but we can't arrive at that
either (b == 1 with a == -INT_MAX-1 is undefined, b == -1 the same).

[Bug target/107201] [avr] -nodevicelib not working for devices -mmcu=avr...

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
:

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

commit r12-10100-gebdc3aae0a4705d0b72b69a37fdafa5613343d5d
Author: Georg-Johann Lay 
Date:   Mon Jan 15 13:25:59 2024 +0100

AVR: target/107201: Make -nodevicelib work for all devices.

driver-avr.cc contains a spec that discriminates between cores
and devices by means of a mmcu=avr* spec pattern.  This does not
work for new devices like AVR128* which also start with mmcu=avr
like all cores do.  The patch uses a new spec function in order to
tell apart cores from devices.

gcc/
PR target/107201
* config/avr/avr.h (EXTRA_SPEC_FUNCTIONS): Add no-devlib,
avr_no_devlib.
* config/avr/driver-avr.cc (avr_no_devlib): New function.
(avr_devicespecs_file): Use it to remove -nodevicelib from the
options for cores only.
* config/avr/avr-arch.h (avr_get_parch): New prototype.
* config/avr/avr-devices.cc (avr_get_parch): New function.

(cherry picked from commit 86fac7ee1688bdec245a43f6d2ab49fb238892e4)

[Bug target/107201] [avr] -nodevicelib not working for devices -mmcu=avr...

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |13.3
   Priority|P3  |P4
   Keywords|patch   |
 Resolution|--- |FIXED

--- Comment #5 from Georg-Johann Lay  ---
Fixed in v12.4 and v13.3+.

[Bug middle-end/113406] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -fstrub=internal and _BitInt() (and __GIMPLE wit

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

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

--- Comment #2 from Jakub Jelinek  ---
strub should be honoring aggregate_value_p, see e.g. PR112941

[Bug target/107201] [avr] -nodevicelib not working for devices -mmcu=avr...

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

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

--- Comment #6 from Georg-Johann Lay  ---
As a work around, one can use an adjusted device-specs file with the
avrlibc_devicelib removed.  The spec looks like this:

*avrlibc_devicelib:
%{!nodevicelib:-lavr128da32}

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
foundBugs $ ../results.20220116/bin/gcc -w -O2 bug998.c
foundBugs $ ./a.out
checksum = 77A231E6
foundBugs $ ../results.20220116/bin/gcc -w -O3 bug998.c
foundBugs $ ./a.out
checksum = 77A231E6
foundBugs $ ../results.20230205/bin/gcc -w -O2 bug998.c
foundBugs $ ./a.out
checksum = 77A231E6
foundBugs $ ../results.20230205/bin/gcc -w -O3 bug998.c
foundBugs $ ./a.out
checksum = 130B5204
foundBugs $ 

So it goes wrong sometime between g:90045c5df5b3c8853e7740fb72a11aead1c489bb
and g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef, a distance of 7403 commits.

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

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

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

--- Comment #8 from Florian Weimer  ---
In the current implementation, as far as I understand it, avoiding multiple
objects is just an optimization, not a correctness issue. STB_GNU_UNIQUE is for
correctness (although I don't think we'd implement it this way today).

The deallocation API does not explicitly reference the closure, which is why
stackful coroutines/fibers will have to switch the allocator state as part of
the context switch. Once we start doing this, it simplifies matters greatly if
there is just one such state to switch, and not an arbitrary count.

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

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

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

--- Comment #9 from Jakub Jelinek  ---
Note, normally libgcc.a symbols are made .hidden (and that is the case of even
these 2 functions).  So, when not using -shared-libgcc (implicitly or
explicitly), every shared library or binary uses its own copy of the registry,
rather than a shared one.
So, if we wanted to make the symbols STB_GNU_UNIQUE, we'd also need to stop
making them .hidden.

[Bug middle-end/113417] New: POINTERS_EXTEND_UNSIGNED needs to be address-space specific

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

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

Bug ID: 113417
   Summary: POINTERS_EXTEND_UNSIGNED needs to be address-space
specific
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

For pointer-to-integer conversions we need to know whether to sign- or
zero-extend.  For the default address-space using ptr_mode (or address-spaces
using ptr_mode and Pmode/word_mode) this is determined by
POINTERS_EXTEND_UNSIGNED.  For address-spaces not adhering to that constraint
we have no idea.

POINTERS_EXTEND_UNSIGNED should be remove in favor of a
TARGET_ADDR_SPACE_POINTERS_EXTEND_UNSIGNED hook specifying the
address-space.

[Bug middle-end/113417] POINTERS_EXTEND_UNSIGNED needs to be address-space specific

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-16
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
For next stage1.

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

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

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

--- Comment #10 from Iain Sandoe  ---
it is an optimisation, yes - but as Richi points out, if we change this it will
affect ABI - so it is ideal to do this before the first release that includes
it?


- IIUC Jakub's suggestion:
 - remove the functions from libgcc.a
 - add a spec to gcc/gcc.cc like 
  %{!static:%(!static-libgcc:%(ftrampoline-impl=heap: -shared-libgcc }}}

So the symbols would be public and in libgcc_s only (unless a target chooses to
do something different).

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

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

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Iain Sandoe from comment #10)
> it is an optimisation, yes - but as Richi points out, if we change this it
> will affect ABI - so it is ideal to do this before the first release that
> includes it?
> 
> 
> - IIUC Jakub's suggestion:
>  - remove the functions from libgcc.a

Not necessarily, just maybe.
We do that thing with libgcc_eh.a (unwinder is in libgcc_eh.a and libgcc_s.so.1
and not in libgcc.a).
Or put it in libgcc_eh.a and libgcc_s.so.1?
It is not unwinder, but shares the central registry property with it.

>  - add a spec to gcc/gcc.cc like 
>   %{!static:%(!static-libgcc:%(ftrampoline-impl=heap: -shared-libgcc }}}

Either that, or do something like cp/g++spec.cc does with shared_libgcc.
Whatever works.

[Bug middle-end/113395] RTL expansion of bitfield accesses drops MEM_EXPR

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

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

--- Comment #5 from Richard Biener  ---
Without fully lowering this on GIMPLE we could substitute the representative
for the bitfield member in the MEM_EXPR and adjust adjust_address_1 to
instead of using attrs.size to constrain the extent of the object designated
by MEM_EXPR re-discover it.  (I wonder if MEM_SIZE needs to be exact
in a must-def way - ao_ref_from_mem certainly treats it that way instead
of getting the size from the mode for non-BLKmode accesses)

That said, lowering on GIMPLE is the way to go.  Even iff only right before
RTL expansion ...

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
Bisect range seems to be g:e03a0a4d73a478928b26213363fa5dbb9fc8695f ..
g:4e1914625dec4aa09a5671c6294e877dbf4518f5, which is 1850 commits.

I will continue the bisection.

[Bug testsuite/113418] New: Use of vect_* targetsin tests out of vect directories

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

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

Bug ID: 113418
   Summary: Use of vect_* targetsin tests out of vect directories
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

[Bug tree-optimization/113419] New: SRA should replace some aggregate copies by load/store

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

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

Bug ID: 113419
   Summary: SRA should replace some aggregate copies by load/store
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

For example gcc.dg/tree-ssa/pr94969.c has

int a = 0, b = 0, c = 0;
struct S {
  signed m : 7;
  signed e : 2;
};
struct S f[2] = {{0, 0}, {0, 0}};
struct S g = {0, 0};

void __attribute__((noinline))
k()
{
  for (; c <= 1; c++) {
f[b] = g;
f[b].e ^= 1;
  }
}

the aggregate copy f[b] = g isn't touched by SRA because it's global
variables.  For locals we'd end up with sth like

   g$e;
   g$m;
  struct S g;
  struct S a[2];

   :
  g$m_7 = 0;
  g$e_8 = 0;
  MEM[(struct S *)&a + 4B].m = g$m_7;
  MEM[(struct S *)&a + 4B].e = g$e_8;

so bit-precision integers.  That might be good, esp. if there's field
uses around.

When the global variable variant is expaneded on RTL we see a simple
SImode load and a SImode store.  That means we should ideally treat
aggregate copies like memcpy (&dest, &src, sizeof (dest)) and then
fold it that way.

But we should let SRA have a chance at decomposing first so this
shouldn't be done as part of general folding but instead by late SRA
for aggregate copies it didn't touch.  For the gcc.dg/tree-ssa/pr94969.c
testcase this then allows GIMPLE invariant motion to hoist the load
from g, otherwise we rely on RTL PRE for this which is prone to PR113395.

[Bug tree-optimization/113419] SRA should replace some aggregate copies by load/store

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-16
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
I'll take this for next stage1, factoring out sth from
gimple_fold_builtin_memory_op

[Bug testsuite/113418] Use of vect_* target selectors in tests out of vect directories

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

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

--- Comment #1 from Xi Ruoyao  ---
[Phew, why do we allow empty reports? Just mishit "enter" and then this.]

The vect_* target selectors are evaluated with the options in
DEFAULT_VECTCFLAGS in effect, but these options are not automatically passed to
tests out of the vect directories.  This causes test failures to show up here
and there.

To me using vect_* target selectors out of vect directories is simply wrong. 
Instead of forcing the maintainers to fix these failures one by one, target by
target, we should just move the tests into vect directories, or adjust them not
to rely on vect_* target selectors.  And we should make a policy to disallow
using { target vect_* } in tests out of vect directories.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
Reduced bisect range seems to be g:2c11662391bafd74c9d19bf7626b7bcef41c1323 ..
g:9e0d5db3e04afd2d030ace4ccb5c1af5e9f05a8f, which is 462 commits.

[Bug target/112577] aarch64_class_max_nregs mishandles 64-bit structure modes

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

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

Tejas Belagod  changed:

   What|Removed |Added

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

[Bug target/112577] aarch64_class_max_nregs mishandles 64-bit structure modes

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

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

--- Comment #1 from Tejas Belagod  ---
Confirmed. Testing a fix.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
Current range seems to be g:54a5f478487a955c3ffaec3e9164a72599bc1cfb ..
g:1edfc8f2d3307a3ffa077a605f432832d7715462, which is 4 commits.

Of those 4, this one

commit 8c99e307b20c502e55c425897fb3884ba8f05882
Author: Aldy Hernandez 
Date:   Sat Jun 25 18:58:02 2022 -0400

looks a likely candidate.

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

[gaiusmod2 at gmail dot com via Gcc-bugs]

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

--- Comment #16 from gaiusmod2 at gmail dot com ---
"rguenth at gcc dot gnu.org"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
>
> --- Comment #15 from Richard Biener  ---
> (In reply to Gaius Mulley from comment #14)
>> Ah apologies, is it best that I revert:
>> 
>> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
>> h=81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032
>> 
>> happy to do this in the morning.
>
> I think it might be better to define 
> M2C_LONGREAL_FLOAT128/M2C_LONGREAL_PPC64LE
> (whatever they exactly indicate) in terms of the existing
>
> --with-long-double-128
> --with-long-double-format
>
> aka the TARGET_DEFAULT_LONG_DOUBLE_128 that's put into the config plus
> with_long_double_format (I think that causes TARGET_IEEEQUAD_DEFAULT
> to be defined to 1/0, but only for ppc, via config.gcc and
> tm_defines).

yes thanks for the hints this sounds good.  I'll pursue this line for a fix.

> I can't say whether it's better to revert or disable/fix as I can't say
> how this for example affects the M2 ABI (like if there was any 'long double'
> before this change and what effective type this used).

Prior to the patch it used the default C long double type but many of
the intrinsic functions were broken.  Currently with the patch gcc120
has no regression test failures and gcc135 (yesterday with manual
configure intervention) was at 96 failures in the m2 testsuite.

I suspect configure confusion and hence using
TARGET_DEFAULT_LONG_DOUBLE_128 and TARGET_IEEEQUAD_DEFAULT should
resolve it.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com

--- Comment #8 from David Binderman  ---
As expected:

$ git bisect good fc259b522c0f8b7bbca8e7adcd3da63330094a34
8c99e307b20c502e55c425897fb3884ba8f05882 is the first bad commit
commit 8c99e307b20c502e55c425897fb3884ba8f05882
Author: Aldy Hernandez 
Date:   Sat Jun 25 18:58:02 2022 -0400

Over to Aldy for their best opinion.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

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

https://gcc.gnu.org/g:1251d3957de04dc9b023a23c09400217e13deadb

commit r14-7274-g1251d3957de04dc9b023a23c09400217e13deadb
Author: Jakub Jelinek 
Date:   Tue Jan 16 11:49:34 2024 +0100

cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]

The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
  ivtmp.40_3 = (unsigned long) &MEM  [(void *)&bitint.6
+ 8B];
...
  uses of ivtmp.40_3
...
  bitint.6 ={v} {CLOBBER(eos)};
...
  ivtmp.28_43 = (unsigned long) &MEM  [(void
*)&bitint.6 + 8B];
...
  uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.

The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.

In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers).  The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.

2024-01-16  Jakub Jelinek  

PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.

* gcc.dg/torture/bitint-49.c: New test.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.

[Bug middle-end/90348] [11/12/13/14 Regression] Partition of char arrays is incorrect in some cases

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

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

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

https://gcc.gnu.org/g:1251d3957de04dc9b023a23c09400217e13deadb

commit r14-7274-g1251d3957de04dc9b023a23c09400217e13deadb
Author: Jakub Jelinek 
Date:   Tue Jan 16 11:49:34 2024 +0100

cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]

The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
  ivtmp.40_3 = (unsigned long) &MEM  [(void *)&bitint.6
+ 8B];
...
  uses of ivtmp.40_3
...
  bitint.6 ={v} {CLOBBER(eos)};
...
  ivtmp.28_43 = (unsigned long) &MEM  [(void
*)&bitint.6 + 8B];
...
  uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.

The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.

In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers).  The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.

2024-01-16  Jakub Jelinek  

PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.

* gcc.dg/torture/bitint-49.c: New test.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.

[Bug middle-end/111422] Wrong code at -O3 on x86_64-linux-gnu

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

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

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

https://gcc.gnu.org/g:1251d3957de04dc9b023a23c09400217e13deadb

commit r14-7274-g1251d3957de04dc9b023a23c09400217e13deadb
Author: Jakub Jelinek 
Date:   Tue Jan 16 11:49:34 2024 +0100

cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]

The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
  ivtmp.40_3 = (unsigned long) &MEM  [(void *)&bitint.6
+ 8B];
...
  uses of ivtmp.40_3
...
  bitint.6 ={v} {CLOBBER(eos)};
...
  ivtmp.28_43 = (unsigned long) &MEM  [(void
*)&bitint.6 + 8B];
...
  uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.

The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.

In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers).  The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.

2024-01-16  Jakub Jelinek  

PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.

* gcc.dg/torture/bitint-49.c: New test.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.

[Bug middle-end/110115] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu

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

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

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

https://gcc.gnu.org/g:1251d3957de04dc9b023a23c09400217e13deadb

commit r14-7274-g1251d3957de04dc9b023a23c09400217e13deadb
Author: Jakub Jelinek 
Date:   Tue Jan 16 11:49:34 2024 +0100

cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]

The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
  ivtmp.40_3 = (unsigned long) &MEM  [(void *)&bitint.6
+ 8B];
...
  uses of ivtmp.40_3
...
  bitint.6 ={v} {CLOBBER(eos)};
...
  ivtmp.28_43 = (unsigned long) &MEM  [(void
*)&bitint.6 + 8B];
...
  uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as
2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.

The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4
PRs.

In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems
besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers).  The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXX names of LTO to
make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which
iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.

2024-01-16  Jakub Jelinek  

PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.

* gcc.dg/torture/bitint-49.c: New test.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.

[Bug tree-optimization/113372] wrong code with _BitInt() arithmetics at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #20 from Jakub Jelinek  ---
Worked around for now.

[Bug middle-end/113406] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -fstrub=internal and _BitInt() (and __GIMPLE wit

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Seems ipa-strub.cc contains a copy of the expand_thunk I've fixed some weeks
ago.

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||matheus-catarino at hotmail 
dot co
   ||m

--- Comment #13 from Jonathan Wakely  ---
*** Bug 90999 has been marked as a duplicate of this bug. ***

[Bug libstdc++/90999] [MSYS2/MINGW64] std::experimental::net does not work on mingw

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
Fixed by r12-89-g0e1e7b77904f1f for PR 100180

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

[Bug target/112577] aarch64_class_max_nregs mishandles 64-bit structure modes

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

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

Tejas Belagod  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

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

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

--- Comment #12 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #11)
> Or put it in libgcc_eh.a and libgcc_s.so.1?

Yes, that's what I came up with as well (conceptually, not a patch, and I only
have a background in ELF), but Iain already dismissed it in comment 3.

[Bug ada/113397] [14 Regression] ICE: SIGSEGV in tree_check (tree.h:3611) with -fdump-ada-spec-slim on gcc.c-torture/execute/pr22061-2.c

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r14-7275-gcf420e7b98d845323fad8280aea4ede60d3d96fe
Author: Eric Botcazou 
Date:   Tue Jan 16 12:15:31 2024 +0100

Fix crash of -fdump-ada-spec in a pathological case

gcc/c-family/
PR ada/113397
* c-ada-spec.cc (check_type_name_conflict): Add guard for the
presence of DECL_NAME on a TYPE_DECL.

[Bug ada/113397] [14 Regression] ICE: SIGSEGV in tree_check (tree.h:3611) with -fdump-ada-spec-slim on gcc.c-torture/execute/pr22061-2.c

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
.

[Bug tree-optimization/113408] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt()

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

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

--- Comment #1 from Jakub Jelinek  ---
Slightly adjusted:
struct A { _BitInt(713) b; } g;
int f;

void
foo (void)
{
  struct A j = g;
  if (j.b)
f = 0;
}

The problem is that SRA decides to change:
  j = g;
  _1 = j.b;
  if (_1 != 0)
to
  j_7 = MEM[(struct A *)&g];
  _1 = VIEW_CONVERT_EXPR<_BitInt(713)>(j_7);
  if (_1 != 0)
where j_7 has _BitInt(768) type, and handle_cast doesn't seem to handle that.
So, we need to handle it there, and ideally also tweak SRA so that it keeps the
bitints as is even if they don't have precision in multiple of bytes or words
or whatever SRA rounds to.

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

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

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

--- Comment #13 from Iain Sandoe  ---
(In reply to Florian Weimer from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > Or put it in libgcc_eh.a and libgcc_s.so.1?
> 
> Yes, that's what I came up with as well (conceptually, not a patch, and I
> only have a background in ELF), but Iain already dismissed it in comment 3.

I would not do that for Darwin, experience with emuTLS gave us headaches in
doing that, especially since our users are often building projects using both
GCC and clang.

However, this is an area where individual targets can have different solutions
- so my comment should not be seen to apply to ELF targets if that seems the
best remedy there.

[Bug c/113420] New: risc-v vector: ICE when using C compiler compile C++ RVV intrinsics

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

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

Bug ID: 113420
   Summary: risc-v vector: ICE when using C compiler compile C++
RVV intrinsics
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

#include 

void matrix_transpose_intrinsics(float *dst, float *src, size_t n) 
{
for (size_t row_id = 0; row_id < n; ++row_id) { // input row-index
size_t avl = n;
// source pointer to row_id-th row
float* row_src = src + row_id * n;
// destination pointer to row_id-th column
float* row_dst = dst + row_id;
while (avl > 0) {
size_t vl = __riscv_vsetvl_e32m1(avl);
vfloat32m1_t row = __riscv_vle32_v_f32m1(row_src, vl);
__riscv_vsse32(row_dst, sizeof(float) * n, row, vl);
// updating application vector length
avl -= vl;
// updating source and destination pointers
row_src += vl;
row_dst += vl * n;
}
}
}

: In function 'matrix_transpose_intrinsics':
:14:13: internal compiler error: in resolve_overloaded_builtin, at
config/riscv/riscv-vector-builtins.cc:4614
   14 | __riscv_vsse32(row_dst, sizeof(float) * n, row, vl);
  | ^~
0x7fbb66a29e3f __libc_start_main
???: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.
Compiler returned: 1

[Bug tree-optimization/111268] [11/12/13/14 Regression] internal compiler error: in to_constant, at poly-int.h:504

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug target/112375] [14 Regression] vget_set_lane_1.c fails

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

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

Tejas Belagod  changed:

   What|Removed |Added

 CC||belagod at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-16
   Assignee|unassigned at gcc dot gnu.org  |belagod at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug target/112375] [14 Regression] vget_set_lane_1.c fails

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

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

--- Comment #3 from Tejas Belagod  ---
Confirmed.

[Bug tree-optimization/113408] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-01-16
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57100&action=edit
gcc14-pr113408.patch

Untested fix.

[Bug tree-optimization/113421] New: wrong code with -O -fno-tree-fre and _BitInt() multiplication

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113421
   Summary: wrong code with -O -fno-tree-fre and _BitInt()
multiplication
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc testcase.c -O -fno-tree-fre
$ ./a.out 
Aborted

On the asm level:
...
mov r9d, 1024   #,
lea r8, [rsp+16]#,
mov ecx, 1024   #,
mov edx, OFFSET FLAT:g  #,
mov esi, 1024   #,
mov rdi, rdx#,
call__mulbitint3#
...

rdi == rdx, overlapping the "ret" and "u" arguments of __mulbitint3

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

[Bug middle-end/113409] ICE: in omp_extract_for_data, at omp-general.cc:411 with -fopenmp-simd and _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
On e.g.
void bar (_BitInt(931));

void
foo (_BitInt(931) x)
{
  #pragma omp parallel for
  for (_BitInt(931) i = 0; i < x; ++i)
bar (i);
}

clang emits
warning: OpenMP loop iteration variable cannot have more than 64 bits size and
will be narrowed [-Wopenmp-loop-form]
warning.
On
void bar (__int128);

void
foo (__int128 x)
{
  #pragma omp parallel for // schedule(runtime)
  for (__int128 i = 0; i < x; ++i)
bar (i);
}
we actually emit something that probably works and with schedule(runtime)
silently assume it won't be more than 64-bit of iterations.
So supposedly we should treat BITINT_TYPEs the same.

[Bug tree-optimization/113371] [14 Regression] ICE: verify_ssa failed: PHI node with wrong VUSE on edge from BB 19 with -O -march=silvermont -ftree-vectorize

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I think we're doing sth unsupported - prologue peeling for
LOOP_VINFO_EARLY_BREAKS_VECT_PEELED.  The problem is that we only late
decide whether we do vect_use_loop_mask_for_alignment_p and I'm not sure
whether that variant works.

Testing a simple patch.

[Bug libstdc++/109203] sort(zip(v1, v2)) fails to compile

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

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

--- Comment #8 from Jonathan Wakely  ---
Thanks, Patrick. I have a patch for LWG 3865 too.

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

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

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

--- Comment #20 from Martin Jambor  ---
I have submitted a slightly modified patch to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6cyu1e9kw.fsf@/T/#u

[Bug ipa/112616] [11/12/13/14 Regression] wrong code at -O{s, 2, 3} on x86_64-linux-gnu since r10-3311

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

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

--- Comment #6 from Martin Jambor  ---
(In reply to Andrew Pinski from comment #1)
>   # q_11 = PHI <0B(2), removed_return.14_14(D)(4),
> removed_return.14_14(D)(3)>
>   _12 = *q_11;
> 
> 
> WTF

Well, _12 is not used anywhere, so the code expects the entire load to be DCEd.
 But it gets optimized to 

  _2 = MEM[(int *)0B]; 

before DCE sees it and then even if _2 is never used anywhere, apparently the
statement is kept there as an intended trap (I guess).

I have adjusted my patch to make DCE for removed returnd part of IPA edge
redirection so that it does not have compare-debug problems and submitted it
for review in: https://inbox.sourceware.org/gcc-patches/ri6cyu1e9kw.fsf@/T/#u

[Bug middle-end/113409] ICE: in omp_extract_for_data, at omp-general.cc:411 with -fopenmp-simd and _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2024-01-16
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57102&action=edit
gcc14-pr113409.patch

Untested fix.

[Bug tree-optimization/113422] New: Missed optimizations in the presence of pointer chains

[carnet at student dot ethz.ch via Gcc-bugs]

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

Bug ID: 113422
   Summary: Missed optimizations in the presence of pointer chains
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carnet at student dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/hdWKn4bjc

All three functions write to the same variable (b). Clang is able to optimize
this. GCC -O3 cannot always do this.
Assembly for foo is writing to **d instead to directly write 1 to b. There is
similar behavior for bar and baz. Clang optimizes the code to directly write to
b.
Baz is fully optimized only if the foo and bar are removed.

int b = 0;
static int *c = &b;
static int **d = &c;
static int ***e = &d;

void foo() {***e = 1;}
void bar() {**d = 1;}
void baz() {*c = 1;}

Assembly code:
foo:
movqd(%rip), %rax
movq(%rax), %rax
movl$1, (%rax)
ret

[Bug tree-optimization/113423] New: Missed Optimization: potential redundant load

[carnet at student dot ethz.ch via Gcc-bugs]

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

Bug ID: 113423
   Summary: Missed Optimization: potential redundant load
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carnet at student dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/jbbEPePhv

Source Code:
int a;
int *b;
int c = 0;

void foo() {
  if (b)
c = 3;
  a = c;
}


int bar(){
return c;
}

foo:
cmpq$0, b(%rip)
movlc(%rip), %eax <= eax is overwritten when the jump is
not taken, potentially redundant load
je  .L3
movl$3, c(%rip) 
movl$3, %eax
.L3:
movl%eax, a(%rip)
ret


%eax is written before the branch. If the branch is not taken, eax is
overwritten. Which makes the highlighted load potentially unnecessary.

[Bug tree-optimization/113424] New: lim fails to notice possible aliasing

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

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

Bug ID: 113424
   Summary: lim fails to notice possible aliasing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The lim pass miscompiles the following C++ program when compiled as -O3 for
x86_64 (note: it works as intended when compiled as a C program)

struct { char elt1; char bits; } *a;
char
bar (char *x, char b)
{
  if (0)
  next_bit:
return 1;
  while (1)
{
  if (b)
if (a->bits)
  goto next_bit;
  *x = b;
  if (a->elt1)
return 0;
  a = 0;
}
}

The loop lim gets as input looks as following

  
  if (b_9(D) != 0)
goto ;
  else
goto ;

  
  a.0_1 = a;
  _2 = a.0_1->bits;
  if (_2 != 0)
goto ;
  else
goto ;

  
  *x_10(D) = b_9(D);
  a.1_3 = a;
  _4 = a.1_3->elt1;
  if (_4 != 0)
goto ; [5.50%]
  else
goto ; [94.50%]

  
  a = 0B;
  goto ; [100.00%]

The lim pass changes this to load `a` before the loop and uses the same value
of `a` for both accesses in bb4 and bb5, which is not correct as the store
`*x_10(D)` may have modified `a` before the access in bb5.

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa since r14-6822

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
All good after vect_do_peeling.  It's wrecked by
vect_create_epilog_for_reduction here:

  scalar_result = scalar_results[k];
  FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, orig_name)
{
  FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
SET_USE (use_p, scalar_result);
  update_stmt (use_stmt);

we have two reduction epilogues, one for the early and one for the late
exit but we mismatch the scalar use to replace.

We're also picking up a reduction that's only live on one edge on the other
(but that doesn't seem to result in a problem here).

It also seems we're doing epilogue code generation before creating some
exit PHIs required for that - vect_do_peeling fails to do that.

We can try to hack around that a bit, but there's more issues with this
testcase, like we generate useless epilogues - it seems we should
identify the scalar exit PHI to transform when calling epilogue generation
for a specific edge and skip if there isn't one.

[Bug target/113425] New: gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6

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

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

Bug ID: 113425
   Summary: gcc.dg/fold-copysign-1.c fails on arm since
g:7cbe41d35e6
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
CC: tamar.christina at arm dot com
  Target Milestone: ---

Since g:7cbe41d35e6 (gcc-14-7115-g7cbe41d35e6), we have noticed the following
regression on arm-* targets:
FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= ABS_EXPR" 1
FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "__builtin_copysign"
1

[Bug tree-optimization/113424] lim fails to notice possible aliasing

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm, this is an infinite loop with no forward progress so that might be the
difference between c and c++.

[Bug testsuite/113425] gcc.dg/fold-copysign-1.c fails on arm since g:7cbe41d35e6

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

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

--- Comment #1 from Andrew Pinski  ---
check_effective_target_ifn_copysign needs to be updated for arm basically.

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

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

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

--- Comment #17 from Richard Biener  ---
Note that the default C long double is what is controlled by
--with-long-double-128 and --with-long-double-format, those configs do not tell
you
whether using __ieee128 with -mabi=ieeelongdouble will work.

[Bug ipa/113422] Missed optimizations in the presence of pointer chains

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |ipa
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-16
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Yes gcc static read only pass does not cycle . So it only able to remove
currently one level of indirection.

[Bug tree-optimization/113426] New: Missed optimization of loop invariant elimination

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 113426
   Summary: Missed optimization of loop invariant elimination
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that maybe there is a missed optimization for loop invariant
elimination.

Loop invariant: a+b.

https://godbolt.org/z/Ebzd3dMPW

int a, b, c;
int n;
int w;
void func(){
for(int i=0;i<100;i++){
c=n;
a+=w;
b-=w;
n=a+b;
}
}

GCC -O3:
func():
mov r9d, DWORD PTR a[rip]
mov r10d, DWORD PTR b[rip]
mov eax, 100
mov edi, DWORD PTR n[rip]
mov esi, DWORD PTR w[rip]
mov ecx, r10d
mov edx, r9d
.L2:
mov r8d, edi
lea edi, [rcx+rdx]  
sub ecx, esi
add edx, esi
sub eax, 1
jne .L2
imuledx, esi, -99
lea eax, [rsi+r9]
add r9d, r10d
mov DWORD PTR c[rip], r8d
mov DWORD PTR n[rip], r9d
sub eax, edx
mov DWORD PTR a[rip], eax
mov eax, r10d
sub eax, esi
add eax, edx
mov DWORD PTR b[rip], eax
ret

Expected code (Clang):
func():   # @func()
mov eax, dword ptr [rip + a]
mov ecx, dword ptr [rip + b]
lea edx, [rcx + rax]
imulesi, dword ptr [rip + w], 100
add eax, esi
sub ecx, esi
mov dword ptr [rip + n], edx
mov dword ptr [rip + c], edx
mov dword ptr [rip + a], eax
mov dword ptr [rip + b], ecx
ret

We analyze and find that in the optimization results of GCC, the calculation of
n is actually outside the loop (add r9d, r10d; mov DWORD PTR n[rip], r9d). 
However, because of the effect of c=n, a+b is calculated once each time through
the loop.
Hope this analysis will help with this issue.

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug middle-end/113406] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -fstrub=internal and _BitInt() (and __GIMPLE wit

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 57099 [details]
> gcc14-pr113406.patch
> 
> Seems ipa-strub.cc contains a copy of the expand_thunk I've fixed some weeks
> ago.

But the gimple testcase still fails ...

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
The code populating alternative exit virtual PHIs simply doesn't handle more
than one arg ...

  /* Now link the alternative exits.  */
  if (multiple_exits_p)  
{
...
   SET_PHI_ARG_DEF (l_phi, 0, exit_val);

we're losing the original ones doing

  for (auto exit : loop_exits)
{   
  basic_block dest = main_loop_exit_block;
  if (exit != loop_exit)
{
  if (!alt_loop_exit_block)
{ 
  edge res = redirect_edge_and_branch ( 
exit,
new_preheader);
  flush_pending_stmts (res);
  alt_loop_exit_block = split_edge (res);
  continue;
}
  dest = alt_loop_exit_block;
}
  edge e = redirect_edge_and_branch (exit, dest);
  flush_pending_stmts (e);
}

since that creates a new BB without any virtual PHI.

[Bug middle-end/113406] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -fstrub=internal and _BitInt() (and __GIMPLE wit

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Created attachment 57099 [details]
> > gcc14-pr113406.patch
> > 
> > Seems ipa-strub.cc contains a copy of the expand_thunk I've fixed some weeks
> > ago.
> 
> But the gimple testcase still fails ...

Because it is incorrect.  I think it needs to use  or something like
that.

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

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

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

Anonymous  changed:

   What|Removed |Added

 CC||iamanonymous.cs at gmail dot 
com

--- Comment #9 from Anonymous  ---
(In reply to Andrew Pinski from comment #1)
> dom3 :
> ```
> #0  0x012add4b in irange::intersect (this=, v=...) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.cc:1523
> #1  0x01c93506 in Value_Range::intersect (r=...,
> this=0x7ffe17a0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:541
> #2  gori_compute::compute_operand2_range (this=0x2f4dcd0, r=...,
> handler=..., lhs=..., name=0x779dc000, src=..., rel=) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1267
> #3  0x01c946de in gori_compute::compute_operand1_and_operand2_range
> (this=0x2f4dcd0, r=..., handler=..., lhs=..., name=0x779dc000, src=...,
> rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1296
> #4  0x01c9165b in gori_compute::compute_operand_range
> (this=0x2f4dcd0, r=..., stmt=0x776015d8, lhs=..., name=0x779dc000,
> src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:708
> #5  0x01c94028 in gori_compute::compute_operand_range (rel=0x0,
> src=..., name=0x779dc000, lhs=..., stmt=, r=...,
> this=0x2f4dcd0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
> #6  gori_compute::compute_operand1_range (this=0x2f4dcd0, r=...,
> handler=..., lhs=..., name=0x779dc000, src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1178
> #7  0x01c9159b in gori_compute::compute_operand_range
> (this=0x2f4dcd0, r=..., stmt=0x77601688, lhs=..., name=0x779dc000,
> src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:711
> #8  0x01c94028 in gori_compute::compute_operand_range (rel=0x0,
> src=..., name=0x779dc000, lhs=..., stmt=, r=...,
> this=0x2f4dcd0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
> #9  gori_compute::compute_operand1_range (this=0x2f4dcd0, r=...,
> handler=..., lhs=..., name=0x779dc000, src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1178
> #10 0x01c94757 in gori_compute::compute_operand1_and_operand2_range
> (this=0x2f4dcd0, r=..., handler=..., lhs=..., name=, src=...,
> rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1300
> #11 0x01c9165b in gori_compute::compute_operand_range
> (this=0x2f4dcd0, r=..., stmt=0x776016e0, lhs=..., name=0x779dc000,
> src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:708
> #12 0x01c94028 in gori_compute::compute_operand_range (rel=0x0,
> src=..., name=0x779dc000, lhs=..., stmt=, r=...,
> this=0x2f4dcd0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
> #13 gori_compute::compute_operand1_range (this=0x2f4dcd0, r=...,
> handler=..., lhs=..., name=0x779dc000, src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1178
> #14 0x01c9159b in gori_compute::compute_operand_range
> (this=0x2f4dcd0, r=..., stmt=0x77601790, lhs=..., name=0x779dc000,
> src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:711
> #15 0x01c94028 in gori_compute::compute_operand_range (rel=0x0,
> src=..., name=0x779dc000, lhs=..., stmt=, r=...,
> this=0x2f4dcd0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
> #16 gori_compute::compute_operand1_range (this=0x2f4dcd0, r=...,
> handler=..., lhs=..., name=0x779dc000, src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1178
> #17 0x01c94757 in gori_compute::compute_operand1_and_operand2_range
> (this=0x2f4dcd0, r=..., handler=..., lhs=..., name=, src=...,
> rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1300
> #18 0x01c9165b in gori_compute::compute_operand_range
> (this=0x2f4dcd0, r=..., stmt=0x776017e8, lhs=..., name=0x779dc000,
> src=..., rel=0x0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:708
> #19 0x01c93552 in gori_compute::compute_operand_range (rel=0x0,
> src=..., name=0x779dc000, lhs=..., stmt=, r=...,
> this=0x2f4dcd0) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:757
> #20 gori_compute::compute_operand2_range (this=0x2f4dcd0, r=...,
> handler=..., lhs=..., name=0x779dc000, src=..., rel=) at
> /home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1276
> #21 0x01c946de in gori_compute::compute_operand1_and_operand2_range
> (this=0x2f4dcd0, r=..., handler=..., lhs=..., name=0x779dc000, src=...,
> rel=0x0) at
> /home/apinski/src/

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Anonymous from comment #9)
> (In reply to Andrew Pinski from comment #1)
> > dom3 :
> > ```
> 
> Could you please explain on how you to record this trace? Is there any
> specific compilation option to enable this information? Thanks.

I used gdb to figure it out. Just stopped it a few times during the compiling
and saw the backtrace was similar/stuck.

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #11 from Andrew Macleod  ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Anonymous from comment #9)
> > (In reply to Andrew Pinski from comment #1)
> > > dom3 :
> > > ```
> > 
> > Could you please explain on how you to record this trace? Is there any
> > specific compilation option to enable this information? Thanks.
> 
> I used gdb to figure it out. Just stopped it a few times during the
> compiling and saw the backtrace was similar/stuck.

this is resolved is it not?

[Bug c++/113427] New: ICE: tree check: C++23 `this auto` lambda + multiple (ambiguous) inheritance from closure type

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 113427
   Summary: ICE: tree check: C++23 `this auto` lambda + multiple
(ambiguous) inheritance from closure type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/fd3zzfrTd
auto factory(int x) {
return [x=x](this auto self) { return x; };
}
using Lambda = decltype(factory(0));
struct LeftCat : Lambda { LeftCat() : Lambda(factory(1)) {} };
struct RightCat : Lambda { RightCat() : Lambda(factory(2)) {} };
struct SiameseCat : LeftCat, RightCat { using Lambda::operator(); };
int main() {
return SiameseCat()();
}

===

: In instantiation of 'factory(int):: [with auto:1
= SiameseCat]':
:11:24:   required from here
   11 | return SiameseCat()();
  |^~
:3:32: error: 'factory(int)::' is an ambiguous
base of 'SiameseCat'
3 | return [x=x](this auto self) { return x; };
  |^
:3:32: error: 'factory(int)::' is an ambiguous
base of 'SiameseCat'
:3:32: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_decl, at cp/pt.cc:15542
0x264113c internal_error(char const*, ...)
???:0
0x9641cf tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xa88c8c tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
???:0
0xc88d63 instantiate_decl(tree_node*, bool, bool)
???:0
0xb4de55 maybe_instantiate_decl(tree_node*)
???:0
0xb4f948 mark_used(tree_node*, int)
???:0
0xa81a04 build_op_call(tree_node*, vec**, int)
???:0
0xcce9e7 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xc521ea c_parse_file()
???:0
0xda5b99 c_common_parse_file()
???: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.

===

Found by noodling around with explicit object parameters and corner cases
related to https://eel.is/c++draft/expr.prim.lambda#closure-5 . That wording
currently demands that the explicit object parameter of a capturing lambda be
"a class type derived from the closure type," but it probably ought to say more
like "a class type _unambiguously_ derived from the closure type." At least, I
don't know what the expected behavior of the above program ought to be, if it's
_not_ supposed to be ill-formed. I think GCC's ICE happens because GCC is
trying too hard to assign a meaning to an essentially meaningless program.

[Bug middle-end/113409] ICE: in omp_extract_for_data, at omp-general.cc:411 with -fopenmp-simd and _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #57102|0   |1
is obsolete||

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

Updated patch with collapse test and some further improvements.

[Bug c++/113427] ICE: tree check: C++23 `this auto` lambda + multiple (ambiguous) inheritance from closure type

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-16
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 CC||xry111 at gcc dot gnu.org

--- Comment #7 from Xi Ruoyao  ---
The C++11 standard explicitly allows to use rand() as the random source for
random_shuffle, thus this is not a bug but an enhancement.

As random_shuffle is deprecated since C++14 and removed in C++17 (the interface
is just broken beyond any repair), I think we should just emit a deprecation
warning telling to use shuffle (it needs an uniform random bit generator to be
passed) instead.

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

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

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

--- Comment #8 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #7)
> The C++11 standard explicitly allows to use rand() as the random source for
> random_shuffle, thus this is not a bug but an enhancement.
> 
> As random_shuffle is deprecated since C++14 and removed in C++17 (the
> interface is just broken beyond any repair), I think we should just emit a
> deprecation warning telling to use shuffle (it needs an uniform random bit
> generator to be passed) instead.

The deprecation warning has been added at r14-2796.  I'm inclined to close this
as WONTFIX because people who care about the strict correctness **shall** just
use std::shuffle instead.

[Bug middle-end/112684] ICE: in main, at toplev.cc:2327 with -ftarget-help -fdiagnostics-generate-patch

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
This happens also with --help=c:

$ x86_64-pc-linux-gnu-gcc --help=c -fdiagnostics-generate-patch testcase.c 
The following options are supported by the language C:
  --all-warnings  Same as -Wall.
...
  -undef  Do not predefine system-specific and GCC-specific
macros.
  -v  Enable verbose output.
  -w  Suppress warnings.

cc1: internal compiler error: in main, at toplev.cc:2329
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

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

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

--- Comment #1 from Iain Sandoe  ---
this appears to be fixed; I get clean fortran testsuite results on (x86_64)
Darwin21 and Darwin23.  Please could you check and either close this or post
your Xcode version, configure line and OS version.

[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 12+

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

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

--- Comment #1 from Iain Sandoe  ---
which Xcode version produces this?
on Darwin23 with XC15.1 I get clean obj-c++ results
(but we should omit the duplicates anyway)

[Bug tree-optimization/113421] wrong code with -O -fno-tree-fre and _BitInt() multiplication

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-01-16
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 57104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57104&action=edit
gcc14-pr113421.patch

Untested fix.

[Bug target/112573] Suboptimal code generation with `-fdata-sections` on aarch64

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Wilco Dijkstra :

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

commit r14-7284-gdb4e496aadf1d7ab1c5af24410394d1551ddd3f0
Author: Wilco Dijkstra 
Date:   Tue Jan 16 16:27:02 2024 +

AArch64: Reassociate CONST in address expressions

GCC tends to optimistically create CONST of globals with an immediate
offset.
However it is almost always better to CSE addresses of globals and add
immediate
offsets separately (the offset could be merged later in single-use cases).
Splitting CONST expressions with an index in aarch64_legitimize_address
fixes
part of PR112573.

gcc/ChangeLog:
PR target/112573
* config/aarch64/aarch64.cc (aarch64_legitimize_address):
Reassociate
badly formed CONST expressions.

gcc/testsuite/ChangeLog:
PR target/112573
* gcc.target/aarch64/pr112573.c: Add new test.

[Bug rust/108111] Rust meets clang

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Arthur Cohen :

https://gcc.gnu.org/g:2046aec032f743023a5e353735255d951e2e54d6

commit r14-7347-g2046aec032f743023a5e353735255d951e2e54d6
Author: Marc Poulhiès 
Date:   Sat Dec 17 16:23:05 2022 +0100

gccrs: fix some clang warnings

This fixes some extra warnings reported by clang.

gcc/rust/ChangeLog:
PR rust/108111
* ast/rust-ast-full-decls.h (StructPatternElements): Declare as a
class.
* ast/rust-item.h (EnumItem): Mark several method as being
overrides.
* ast/rust-pattern.h (StructPattern::get_locus): Add override.
* lex/rust-lex.h (BufferInputSource): Use reference_wrapper
instead of bare reference.
(TokenSource::get): Add method to implement the reference_wrapper
interface.
* typecheck/rust-tyty.h (TypeBoundPredicate): Add empty dtor.
* util/rust-buffered-queue.h (peek): Source token stream is now
using a reference_wrapper, use .get()

Signed-off-by: Marc Poulhiès 

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Xi Ruoyao from comment #7)
> The C++11 standard explicitly allows to use rand() as the random source for
> random_shuffle, thus this is not a bug but an enhancement.

It doesn't just allow it, it requires it. But the standard also requires a
uniform distribution, and we fail to meet that requirement because of the range
of RAND_MAX. (We actually fail to meet it on all targets, because we use %
which is not uniformly distributed unless RAND_MAX is an exact multiple of
(last - first), so we always have a bias.)

The proposed patch still uses rand() as the source of randomness, it just uses
that source as input to another level of pseudo-randomness. That is conforming
to the C++11 standard.

Using std::shuffle isn't possible in C++98 code. Using the other overload of
std::random_shuffle is possible though, and that allows you to provide a PRNG
that returns values greater than RAND_MAX.

Please don't close this bug, that serves no purpose. It's a bug and should be
fixed.

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|enhancement |normal

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

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

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

--- Comment #10 from Xi Ruoyao  ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Xi Ruoyao from comment #7)
> > The C++11 standard explicitly allows to use rand() as the random source for
> > random_shuffle, thus this is not a bug but an enhancement.
> 
> It doesn't just allow it, it requires it. But the standard also requires a
> uniform distribution, and we fail to meet that requirement because of the
> range of RAND_MAX. (We actually fail to meet it on all targets, because we
> use % which is not uniformly distributed unless RAND_MAX is an exact
> multiple of (last - first), so we always have a bias.)

I cannot see how it is possible to guarantee an uniform distribution with
rand() because the C standard even says rand() is allowed to be very stupid:

> There are no guarantees as to the quality of the random sequence produced
> and some implementations are known to produce sequences with distressingly
> non-random low-order bits. Applications with particular requirements should
> use a generator that is known to be sufficient for their needs.

[Bug translation/108890] Translation mistakes 2023

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

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

--- Comment #7 from GCC Commits  ---
The trunk branch has been updated by Arthur Cohen :

https://gcc.gnu.org/g:747d9a92ddb74fa7ba1bb6ca0079abd5eaa38791

commit r14-7504-g747d9a92ddb74fa7ba1bb6ca0079abd5eaa38791
Author: TieWay59 
Date:   Wed Apr 19 14:07:34 2023 +0800

gccrs: Fix translation mistakes 2023 in GCC/Rust [PR108890]

In https://gcc.gnu.org/PR108890 "Translation mistakes 2023"
@rillig lists several issues with GCC/Rust diagnostics and
option help texts (but also a few non-GCC/Rust).

This commit fix mistakes only related to GCC/Rust,
specifically to the file `gcc/rust/lang.opt`.

closes https://github.com/Rust-GCC/gccrs/issues/1916

PR translation/108890
gcc/rust/
* lang.opt: Fix translation mistakes 2023 in
GCC/Rust [PR108890]
(line 67): change the inconsistent tab to spaces
(line 75): wrap bare placeholder `integer`
(line 79): remove redundant text of `Choose which`
(line 96): remove redundant text of `Choose which`
(line 112): remove redundant `Flag to`
(line 124): correct the exclusive term `When to stop`
(line 124): correct typo of `copimlation`

Signed-off-by: Tieway59 

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Macleod  ---
fixed via commit 4dfeb1cd8dfca234186216d891ec8f46235c3a14

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

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

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

--- Comment #13 from Jakub Jelinek  ---
r14-2097-g4dfeb1cd8dfca234186216d891ec8f46235c3a14
was a trunk commit, was that backported to 13 branch too (or was it fixed there
some other way)?
In any case, guess we should include the testcase into the testsuite to make
sure it doesn't reappear.

[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #14 from Andrew Macleod  ---
(In reply to Jakub Jelinek from comment #13)
> r14-2097-g4dfeb1cd8dfca234186216d891ec8f46235c3a14
> was a trunk commit, was that backported to 13 branch too (or was it fixed
> there some other way)?
> In any case, guess we should include the testcase into the testsuite to make
> sure it doesn't reappear.

hmm. no, I Missed that this was gcc 13 too.

[Bug middle-end/113410] ICE: in maybe_check_access_sizes, at gimple-ssa-warn-access.cc:3423 with _BitInt() used as array length

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57105&action=edit
gcc14-pr113410.patch

Untested fix.

[Bug other/110205] Some new warnings from clang for the range code

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Macleod  ---
fixed.

[Bug middle-end/112684] ICE: in main, at toplev.cc:2327 with -ftarget-help -fdiagnostics-generate-patch

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-01-16
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #2 from David Malcolm  ---
Thanks for filing this bug.

Happens when
   if (!exit_after_options)
is skipped, since the edit_context is created in process_options.

Working on a fix.

[Bug middle-end/112684] ICE: in main, at toplev.cc:2327 with -ftarget-help -fdiagnostics-generate-patch

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

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

--- Comment #3 from David Malcolm  ---
Reproducers for trunk and supported releases:
  Trunk:https://godbolt.org/z/fz8o3c7h6
  GCC 13.2: https://godbolt.org/z/bnd55zn7K
  GCC 12.3: https://godbolt.org/z/qdf54h6nf
  GCC 11.4: https://godbolt.org/z/fv8a4rvKs

[Bug tree-optimization/113426] Missing scalar evolution replacement sometimes

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Missed optimization of loop |Missing scalar evolution
   |invariant elimination   |replacement sometimes
   Severity|normal  |enhancement

[Bug testsuite/113428] New: [14 regression] gcc.dg/gomp/bad-array-section-c-3.c fails after r14-7158-gb5476e4c881b0d

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

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

Bug ID: 113428
   Summary: [14 regression] gcc.dg/gomp/bad-array-section-c-3.c
fails after r14-7158-gb5476e4c881b0d
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:b5476e4c881b0d2bfbbfb84ee38d791123acf8e1, r14-7158-gb5476e4c881b0d

Seeing this on big endian with -m32.  Works fine on BE with -m64.

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
gomp.exp=gcc.dg/gomp/bad-array-section-c-3.c"
FAIL: gcc.dg/gomp/bad-array-section-c-3.c  at line 14 (test for warnings, line
12)
# of expected passes4
# of unexpected failures1


spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/gomp/bad-array-section-c-3.c
-m32 -fdiagnostics-plain-output -fopenmp -S -o bad-array-section-c-3.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/gomp/bad-array-section-c-3.c:
In function 'main':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/gomp/bad-array-section-c-3.c:12:58:
error: expected ']' before ':' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/gomp/bad-array-section-c-3.c:12:23:
sorry, unimplemented: unsupported map expression '{(int *)arr[5]}'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/gomp/bad-array-section-c-3.c:19:23:
sorry, unimplemented: unsupported map expression '{&arr[5]}'
compiler exited with status 1
PASS: gcc.dg/gomp/bad-array-section-c-3.c  at line 13 (test for errors, line
12)
FAIL: gcc.dg/gomp/bad-array-section-c-3.c  at line 14 (test for warnings, line
12)
PASS: gcc.dg/gomp/bad-array-section-c-3.c  at line 15 (test for warnings, line
12)
PASS: gcc.dg/gomp/bad-array-section-c-3.c  at line 20 (test for warnings, line
19)

commit b5476e4c881b0d2bfbbfb84ee38d791123acf8e1 (HEAD)
Author: Julian Brown 
Date:   Mon Nov 15 02:23:49 2021 -0800

OpenMP: lvalue parsing for map/to/from clauses (C)

[Bug c++/113360] [13/14 Regression] Truncated constexpr error messages with -std=c++23/26

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

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

--- Comment #2 from Marek Polacek  ---
Idea: use cp_function_chain->invalid_constexpr to not to attempt to
explain_invalid_constexpr_fn.

[Bug tree-optimization/113424] lim fails to notice possible aliasing

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Andrew Pinski  ---
I am 99% sure this is because the struct is anonymous in C++ and a's address is
not taken so it is assumed not to be used outside of the TU due to that.

Once I put a name on the struct, the "miscompiling" is gone.


Where is this reduced from because I think it is undefined C++ code.

[Bug tree-optimization/113424] lim fails to notice possible aliasing

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
Without a name on the struct, a becomes a local variable.

There is no aliasing issue here.

You can see the same effect in C via using:
```
static struct b1 { char elt1; char bits; } *a;

```

Since a does not have an address taken, GCC assumes (correctly), it will only
be modified from bar and will NOT be modified from an other variable/address.

[Bug tree-optimization/91624] FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra

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

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

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

https://gcc.gnu.org/g:3867dfc3062c7216d05a4691c79edbc0bb455713

commit r14-8157-g3867dfc3062c7216d05a4691c79edbc0bb455713
Author: John David Anglin 
Date:   Tue Jan 16 19:32:56 2024 +

xfail all scan-tree-dump-times checks on hppa*64*-*-* in sra-17.c and
sra-18.c

2024-01-64  John David Anglin  

gcc/testsuite/ChangeLog:

PR tree-optimization/91624
* gcc.dg/tree-ssa/sra-17.c: xfail all scan-tree-dump-times
checks on hppa*64*-*-*.
* gcc.dg/tree-ssa/sra-18.c: Likewise.

[Bug target/113035] RISC-V: -mtune=sifive-7-series additional dump failures found with bitmanip, zicond, and vector targets

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Edwin Lu  ---
Created attachment 57106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57106&action=edit
testsuite failures for rv64 bitmanip and vector as of r14-7474-g7d8de1ca4a7

Double checked for execution failures on linux rv64gcv with
-mtune=sifive-7-series as discussed in today's meeting. No unexpected execution
failures as of r14-7474-g7d8de1ca4a7

Config:
Schedule of variations:
riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=sifive-7-series/-mcmodel=medlow

[Bug rtl-optimization/113423] Missed Optimization: potential redundant load

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Target||x86_64-linux-gnu powerpc
  Component|tree-optimization   |rtl-optimization
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
The GIMPLE level looks fine:
```

  if (b.0_1 != 0B)
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 322122544]:
  pretmp_7 = c;
  goto ; [100.00%]

   [local count: 751619280]:
  c = 3;

   [local count: 1073741824]:
  # prephitmp_8 = PHI 
```

Even on aarch64 it looks good:
```
foo:
.LFB0:
.cfi_startproc
adrpx1, .LANCHOR0
add x0, x1, :lo12:.LANCHOR0
ldr x1, [x1, #:lo12:.LANCHOR0]
cbz x1, .L5
mov w1, 3
mov w2, w1
str w1, [x0, 8]
str w2, [x0, 12]
ret
.p2align 2,,3
.L5:
ldr w2, [x0, 8]
str w2, [x0, 12]
ret
```

No extra load.

PowerPC (32bit) looks similar to x86_64 though:
```
foo:
.LFB0:
.cfi_startproc
lis 9,b@ha
lwz 9,b@l(9)
cmpwi 0,9,0
lis 9,c@ha
lwz 10,c@l(9)
beq 0,.L3
li 10,3
stw 10,c@l(9)
.L3:
lis 9,a@ha
stw 10,a@l(9)
blr
```

Post RA IFCVT is doing the change:
```
IF-CASE-1 found, start 2, then 3
rescanning insn with uid = 10.
changing bb of uid 14
  from 3 to 2
deleting insn with uid = 35.
deleting block 3
Conversion succeeded on pass 1.
```

It is doing it because of heurstics due to GCC handles `!=0`/`==0` comparisons
as being taken towards the `!=0` case.  E.g. if you change the comparison
against b to be `b == 300`, you get different behavior.