[Bug c++/116640] Inconsistent compiler rules when using private types as default template parameters

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-09-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c/116642] miscompilation involving vfork child.

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

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

--- Comment #22 from Jonathan Wakely  ---
(In reply to Joshua from comment #16)
> I took out -fpie and the output assembly was different and the binary
> started working. That is contrary to the documentation which says you need
> -fpie for position independent executables.


Which documentation? The official manual on gcc.gnu.org documents the behaviour
of hostel GCC, not the Debian build your using, which has been configured
differently. Presumably Debian (or Ubuntu) documents the default behaviour of
their build. If not, that's a big in their docs, not a big in upstream GCC.

[Bug c/116642] miscompilation involving vfork child.

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

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

--- Comment #23 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #22)
> Which documentation? The official manual on gcc.gnu.org documents the
> behaviour of hostel GCC,


Gah, phone autocorrect.

s/hostel/upstream/ !!

[Bug c/116642] miscompilation involving vfork child.

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

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

--- Comment #24 from Jonathan Wakely  ---
And s/big/bug/g

I'll stop fighting my phone now since I'm probably not helping here

[Bug c/116631] [gcc] c23 - 'auto' struggles with comma expression type inference.

[ping at zero dot ms via Gcc-bugs]

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

Sofian Touhami  changed:

   What|Removed |Added

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

--- Comment #5 from Sofian Touhami  ---
Either align on clang behavior (which authorizes the construct) by removing the
error, making it closer to __auto_type too, or maybe explain what is the point
of such restraint.

Anyway this is not a bug anymore, it's an official "feature" even though it
lacks an explanation and purpose. An arbitrary decision taken at some point
that nobody knows the why (and contradict its initial goal of being a direct
__auto_type standardization).

So I gotta mark it as resolved.

Thank you guys for the answers.

[Bug c++/116645] New: Huge performance loss after 13.2.0 compiler upgrade

[joern274 at googlemail dot com via Gcc-bugs]

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

Bug ID: 116645
   Summary: Huge performance loss after 13.2.0 compiler upgrade
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joern274 at googlemail dot com
  Target Milestone: ---

After upgrading g++ compiler from version 11.4.0 (Ubuntu 22.04 LTS) to version
13.2.0 (Ubuntu 24.04 LTS) the compile time for auto-generated verilator code
increased by a factor of *five*.

According to -ftime-report this is mostly due to "reload CSE regs" but I don't
know what this means.

Using this line to compile:
g++ -Os  -I.  -MMD -I/usr/local/share/verilator/include
-I/usr/local/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0
-DVM_TIMING=0 -DVM_TRACE=1 -DVM_TRACE_FST=0 -DVM_TRACE_VCD=1 -faligned-new
-fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare
-Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter
-Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable-O3
-I/usr/include   -c -o Vanalytic_filter_h_a4__ALL.o
Vanalytic_filter_h_a4__ALL.cpp

[Bug c++/116645] Huge performance loss after 13.2.0 compiler upgrade

[joern274 at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Jörn Langheinrich  ---
Created attachment 59077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59077&action=edit
ii-file created by -save-temps

[Bug c/116642] miscompilation involving vfork child.

[joshudson at gmail dot com via Gcc-bugs]

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

--- Comment #25 from Joshua  ---
Guys, I goofed and don't know what I actually did.

I failed to reset one of the other hypotheses after finding the problem in the
disassembly. On re-unpacking the archive containing the reproduction I
uploaded, taking out -pie doesn't fix the problem anymore.

[Bug rtl-optimization/116645] [13/14/15 regression] Huge performance loss after 13.2.0 compiler upgrade

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

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

Sam James  changed:

   What|Removed |Added

Summary|Huge performance loss after |[13/14/15 regression] Huge
   |13.2.0 compiler upgrade |performance loss after
   ||13.2.0 compiler upgrade
  Component|c++ |rtl-optimization

--- Comment #2 from Sam James  ---
Please share the full -ftime-report output too.

[Bug rtl-optimization/116645] [13/14/15 regression] Huge performance loss after 13.2.0 compiler upgrade

[joern274 at googlemail dot com via Gcc-bugs]

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

--- Comment #3 from Jörn Langheinrich  ---
Created attachment 59078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59078&action=edit
Output from -ftime-report

[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Mital Ashok  changed:

   What|Removed |Added

 CC||mital at mitalashok dot co.uk

--- Comment #11 from Mital Ashok  ---
Looks like the original alignas(...) bug is fixed, but the
__attribute__((vector_size(...))) one remains even in GCC15 (should a new bug
for that be opened?)

You don't even need dependent expressions:

char vec __attribute__((vector_size(__builtin_is_constant_evaluated() ? 2 :
2)));
// error: 'vector_size' attribute argument value
'(__builtin_is_constant_evaluated() ? 2 : 2)' is not an integer constant

`if consteval` also triggers this

[Bug other/116635] new test case cc.dg/opt-ordered-and-nonequal-1.c from r15-3463-g91421e21e8f0f0 fails

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-09-08

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #237 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #236)
> (In reply to John Paul Adrian Glaubitz from comment #235)
> > Not sure though whether this is related at all. Will go back to the known
> > working version and retry with all patches.
> 
> OK, the stack overflow issue is reproducible. Will try with LRA disabled now
> to see if it's a side-effect or LRA or the patches 59061 and 59062.

Turns out the stack overflow is unrelated to 59061 and 59062, and indeed, the
two patches fix the problem with previous problem with Ada. So the two patches
are fine.

Let me try to bisect the stack overflow bug. Will report back once I know more.

[Bug c++/116646] New: Compilation of code inside if constexpr with failed condition.

[cas43 at cs dot stanford.edu via Gcc-bugs]

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

Bug ID: 116646
   Summary: Compilation of code inside if constexpr with failed
condition.
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cas43 at cs dot stanford.edu
  Target Milestone: ---

When compiling the following code (g++ -std=c++20 file.cpp):

static const int y=0;
void f() {if constexpr(y<0){static_assert(y<0);}}

I expect no errors, but I get the following diagnostic with gcc version 12.3.0
(Ubuntu 12.3.0-1ubuntu1~22.04):

a.cpp: In function ‘void f()’:
a.cpp:2:44: error: static assertion failed
2 | void f() {if constexpr(y<0){static_assert(y<0);}}
  |   ~^~
a.cpp:2:44: note: the comparison reduces to ‘(0 < 0)’

I get similar diagnostics with every compiler I have ready access to:

gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 
gcc version 10.5.0 (Ubuntu 10.5.0-1ubuntu1~22.04) 
Ubuntu clang version 15.0.7
Ubuntu clang version 14.0.0-1ubuntu1.1
Ubuntu clang version 13.0.1-2ubuntu2.2
Ubuntu clang version 12.0.1-19ubuntu3
Ubuntu clang version 11.1.0-6

This suggests a mistake in my own code, but I don't see it.  My understanding
is that the "if constexpr" should fail and prevent compilation within its body.
 Declaring y as "static constexpr" still fails.  The static_assert can be
replaced with other types of errors, such as a call to a function call that
fails to match.

[Bug c++/116646] Compilation of code inside if constexpr with failed condition.

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

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

--- Comment #1 from Andrew Pinski  ---
It works when y is dependent though:
```
template
void f() {
if constexpr(y<0)
{
static_assert(y<0);
}
}

auto t = &f<0>;
```

I think since it is not dependent, it gets resolved right away.

[Bug c++/116646] Compilation of code inside if constexpr with failed condition.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
https://developercommunity.visualstudio.com/t/non-dependent-static-assertfalse-in-constexpr-if-s/1267343

[Bug rtl-optimization/116645] [13/14/15 regression] Huge performance loss after 13.2.0 compiler upgrade

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.4
   Keywords||needs-bisection,
   ||needs-reduction

[Bug bootstrap/113174] gcc fails to bootstrap on ppc64le with clang-based host environment (internal compiler error)

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #10 from Segher Boessenkool  ---
(In reply to q66 from comment #7)
> I just tested this on big-endian ppc64 targeting power4/ppc970; I was able
> to successfully bootstrap the compiler. It seems this is really specific to
> LE after all (which makes sense I suppose, considering the affected code
> appears to be related to VSX?)

LE and VSX have nothing whatsoever to do with each other.

Other than maybe that the default target for powerpc64le-linux by default
supports VSX.  But you can do ELFv2 BE, you can do ELFv2 on older CPUs, and
you can do "ELFv1" on newer CPUs.

[Bug c/116642] miscompilation involving vfork child.

[joshudson at gmail dot com via Gcc-bugs]

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

--- Comment #26 from Joshua  ---
I've been wondering how to fix this item. Having found the faulting assembly
code; vfork is incidental to the problem. Removing vfork simply preterbs it
away not actually fixing.

I actually hit this once before with execve but without vfork; failed to find
the actual problem, and use memcpy to build up the array in a buffer rather
than the inline initializer to get rid of it.

What this code *is* is the root component of a 20,000 line web management
interface. It's still growing; the final target looks like it's going to be
50,000 lines with 1,200 lines of root code.

Everything it doesn't need has been stripped away. libc is gone, replaced with
three hundred lines of assembly mostly declaring system calls. The dynamic
linker is gone; one less piece of code to audit.

So the root failing construct is:

.LC16:
.quad   .LC7

You can't *do* that in this environment. No relocations allowed.

The sse code that is using it is a pessimization not an optimization anyway. To
avoid a register stall it wants a relocation and a memory access. That
relocation costs more than the register stall.

So ultimately the best way to fix it is to stop generating that construct and
similar constructs; as though this were the the ELF relocation processor
itself. If -mno-sse is what it takes, that's fine. But I need to know exactly
how it's intended to be done. Adding more compiler options costs me nothing.
Adding more compiler options blindly hoping I've got the right ones costs too
much.

So far I haven't gotten a new upstream gcc; I could if it fixed the problem.
It's just a build management problem that I'm not going to tackle unless I need
to.

[Bug target/116621] [12/13/14/15 Regression] x86_64: Crash when fetching va_arg of type union

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r15-3537-gfa7bbb065c63aa802e0bbb04d605407dad58cf94
Author: H.J. Lu 
Date:   Fri Sep 6 05:24:07 2024 -0700

x86-64: Don't use temp for argument in a TImode register

Don't use temp for a PARALLEL BLKmode argument of an EXPR_LIST expression
in a TImode register.  Otherwise, the TImode variable will be put in
the GPR save area which guarantees only 8-byte alignment.

gcc/

PR target/116621
* config/i386/i386.cc (ix86_gimplify_va_arg): Don't use temp for
a PARALLEL BLKmode container of an EXPR_LIST expression in a
TImode register.

gcc/testsuite/

PR target/116621
* gcc.target/i386/pr116621.c: New test.

Signed-off-by: H.J. Lu 

[Bug c++/116276] [14/15 regression] multiple inheritance CTAD regression with -std=c++23

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

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

commit r14-10655-gb5ed381d05e0ed9edf2f320b71f8775ea96a4866
Author: Patrick Palka 
Date:   Fri Aug 9 21:15:25 2024 -0400

c++: inherited CTAD fixes [PR116276]

This implements the overlooked inherited vs non-inherited guide
tiebreaker from P2582R1.  This requires tracking inherited-ness of a
guide, for which it seems natural to reuse the lang_decl_fn::context
field which for a constructor tracks its inherited-ness.

This patch also works around CLASSTYPE_CONSTRUCTORS not reliably
returning all inherited constructors (due to some using-decl handling
quirks in in push_class_level_binding) by iterating over TYPE_FIELDS
instead.

This patch also makes us recognize another written form of inherited
constructor, 'using Base::Base::Base' whose USING_DECL_SCOPE is a
TYPENAME_TYPE.

PR c++/116276

gcc/cp/ChangeLog:

* call.cc (joust): Implement P2582R1 inherited vs non-inherited
guide tiebreaker.
* cp-tree.h (lang_decl_fn::context): Document usage in
deduction_guide_p FUNCTION_DECLs.
(inherited_guide_p): Declare.
* pt.cc (inherited_guide_p): Define.
(set_inherited_guide_context): Define.
(alias_ctad_tweaks): Use set_inherited_guide_context.
(inherited_ctad_tweaks): Recognize some inherited constructors
whose scope is a TYPENAME_TYPE.
(ctor_deduction_guides_for): For C++23 inherited CTAD, iterate
over TYPE_FIELDS instead of CLASSTYPE_CONSTRUCTORS to recognize
all inherited constructors.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/class-deduction-inherited4.C: Remove an xfail.
* g++.dg/cpp23/class-deduction-inherited5.C: New test.
* g++.dg/cpp23/class-deduction-inherited6.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 8cc67b520968ca9a13fd96896522aa66e39a99e2)

[Bug c++/116320] [12/13/14 Regression] ICE: Segmentation fault (perform_or_defer_access_check) since r11-1350

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:149d87fbe661da29d8a0aa671b42bd532206a8b8

commit r14-10656-g149d87fbe661da29d8a0aa671b42bd532206a8b8
Author: Patrick Palka 
Date:   Thu Aug 15 10:23:54 2024 -0400

c++: c->B::m access resolved through current inst [PR116320]

Here when checking the access of (the injected-class-name) B in c->B::m
at parse time, we notice its context B (now the type) is a base of the
object type C, so we proceed to use C as the effective qualifying
type.  But this C is the dependent specialization not the primary
template type, so it has empty TYPE_BINFO, which leads to a segfault later
from perform_or_defer_access_check.

The reason the DERIVED_FROM_P (B, C) test guarding this code path works
despite C having empty TYPE_BINFO is because of its currently_open_class
logic (added in r9-713-gd9338471b91bbe) which replaces a dependent
specialization with the primary template type if we're inside it.  So the
safest fix seems to be to call currently_open_class in the caller as well.

PR c++/116320

gcc/cp/ChangeLog:

* semantics.cc (check_accessibility_of_qualified_id): Try
currently_open_class when using the object type as the
effective qualifying type.

gcc/testsuite/ChangeLog:

* g++.dg/template/access42.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 484f139ccd3b631a777802e810a632678b42ffab)

[Bug c++/116276] [14/15 regression] multiple inheritance CTAD regression with -std=c++23

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Keywords||rejects-valid
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 14.3 / 15.

[Bug c++/116320] [12/13 Regression] ICE: Segmentation fault (perform_or_defer_access_check) since r11-1350

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] ICE:  |[12/13 Regression] ICE:
   |Segmentation fault  |Segmentation fault
   |(perform_or_defer_access_ch |(perform_or_defer_access_ch
   |eck) since r11-1350 |eck) since r11-1350

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 14.3 / 15 so far.

[Bug other/116635] new test case cc.dg/opt-ordered-and-nonequal-1.c from r15-3463-g91421e21e8f0f0 fails

[lin1.hu at intel dot com via Gcc-bugs]

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

--- Comment #1 from Hu Lin  ---
According to the results from https://godbolt.org/z/eKnvraP8T and
https://godbolt.org/z/G6MTWKf4P, certain options such as -march=armv8-m.base
and -mtune=cortex-m23 influence the structure of the code in the ccp1 pass,
rendering the optimization invalid in the forwprop1 pass.

Since the patch is intended for general optimization, I would prefer not to
impose an architecture-specific restriction for this test.

Do you have any ideas for resolving this issue, or could you include this test
case in the list of stable failures?

[Bug c/116647] New: Internal compiler error in operator[], at vec.h:910

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

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

Bug ID: 116647
   Summary: Internal compiler error in operator[], at vec.h:910
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yunboni at smail dot nju.edu.cn
  Target Milestone: ---

Created attachment 59079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59079&action=edit
The preprocessed file when using -O3

When I run the following code with -O3 flag, it went crash:

```c
int a;
char b;
long c, d, e;
unsigned long f;
long g() {
  if (a <= 0)
return 1;
  for (; d; d++) {
e = 0;
for (; e < a; e++) {
  unsigned long h = 0;
  switch (b)
  case 2:
if (e)
  h = 5;
  c += h;
}
  }
  c /= f;
}
```

The full backtrace is:

0x24c4b25 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x24d80c5 internal_error(char const*, ...)
???:0
0x99f670 fancy_abort(char const*, int, char const*)
???:0
0x13bd81c vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*, _slp_tree*,
_slp_instance*, vec*)
???:0
0x139c223 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
???:0
0x13fc15d vect_slp_analyze_operations(vec_info*)
???:0
0x13ca29b vect_analyze_loop(loop*, vec_info_shared*)
???:0

The gcc version I used is:

Using built-in specs.
COLLECT_GCC=/home/yunbo/eval/compilers/gcc_latest/bin/gcc
COLLECT_LTO_WRAPPER=/home/yunbo/eval/compilers/gcc_latest/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/yunbo/eval/compilers/gcc_latest
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240909 (experimental) (GCC)

The details can be found here: https://godbolt.org/z/W8azvcW6d

[Bug tree-optimization/116647] [15 Regression] Internal compiler error in operator[], at vec.h:910

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-09-09
 Target||x86_64 aarch64
   Target Milestone|--- |15.0
Summary|Internal compiler error in  |[15 Regression] Internal
   |operator[], at vec.h:910|compiler error in
   ||operator[], at vec.h:910

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

There is a missing unswitch too. Let me file that seperately.

[Bug tree-optimization/116648] New: unswitch does not handle `if (a & b)` where a is invariant

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

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

Bug ID: 116648
   Summary: unswitch does not handle `if (a & b)` where a is
invariant
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int ff(void);
int g(int a, int *tt, _Bool t1) {
  int c = 0;
  for (int e = 0; e < a; e++)
{
  int h = 1;
  _Bool t2 = tt[e] != 0;
  if (t1 & t2)
h = ff();
  c += h;
}
  return c;
}
```


This could be unswitched as t1 is invariant but currently unswitch does not
handle it.

[Bug c/116642] miscompilation involving vfork child.

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

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

--- Comment #27 from Xi Ruoyao  ---
Build your program as a static PIE and use assembly (or a very limited C
subset) to relocate itself on startup.  In a static PIE there are only relative
relocs, and it's fairly easy to handle relative relocs even in assembly.

[Bug tree-optimization/116648] unswitch does not handle `if (a & b)` where a is invariant

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

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

--- Comment #1 from Andrew Pinski  ---
I should say I noticed this while looking into PR 116647.  Fixing this will
almost definitely make PR 116647 latent though.

[Bug c/116642] miscompilation involving vfork child.

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

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

--- Comment #28 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #27)
> Build your program as a static PIE and use assembly (or a very limited C
> subset) to relocate itself on startup.  In a static PIE there are only
> relative relocs, and it's fairly easy to handle relative relocs even in
> assembly.

All other implementations (Glibc, Musl, and Linux kernel with KASLR enabled on
modern architectures like RISC-V) do this, instead of urging the compiler to
add some feature to disable all relocs.  And sorry, your implementation is not
more important than them so it's a no-go to add burdens to the compiler just
for your case.

[Bug c/116642] miscompilation involving vfork child.

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

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

--- Comment #29 from Andrew Pinski  ---
That is: `-static -pie` which should remove the requirement of
`-Wl,--no-dynamic-linker` too.

Basically a (non-static) PIE binary requires using the dynamic loader to do the
relocations while a static PIE does not.

[Bug c/116642] miscompilation involving vfork child.

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

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

--- Comment #30 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #29)
> That is: `-static -pie` which should remove the requirement of
> `-Wl,--no-dynamic-linker` too.
> 
> Basically a (non-static) PIE binary requires using the dynamic loader to do
> the relocations while a static PIE does not.

Actually -static-pie.  -static-pie is different from -static -pie (with a
space):

$ cc -static-pie hw.c
$ file a.out
a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), static-pie
linked, for GNU/Linux 6.10.0, with debug_info, not stripped
$ cc -static -pie hw.c
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically
linked, for GNU/Linux 6.10.0, with debug_info, not stripped

>From a "normal programmer" perspective, ASLR is performed for the former, but
not the latter.

In the former the load address of the executable is unknown, so some relocs are
turned to R_X86_64_RELATIVE by ld, and Glibc rcrt1.o is linked in to resolve
R_X86_64_RELATIVE at program startup.  

In the latter the load address is fixed, so all relocs are just resolved by ld,
nothing is turned to R_X86_64_RELATIVE.

[Bug ada/115917] GNAT fails to bootstrap with LTO and -Werror=lto-type-mismatch

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Summary|GNAT fails to bootstrap |GNAT fails to bootstrap
   |with LTO and|with LTO and
   |-Werror=lto-type-mismatch   |-Werror=lto-type-mismatch
   |due to C_Version_String and |
   |gnat_version_string on  |
   |x86_64-pc-linux-gnu |
   Target Milestone|--- |15.0
 Resolution|--- |FIXED
 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou  ---
Fixed on mainline.

[Bug c++/103833] Overloaded static member function cannot be resolved unlike overloaded global function

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Fedor Chelnokov  ---
Same issue in Clang has been fixed:
https://github.com/llvm/llvm-project/issues/52883

Another observation is that `(&(A::m))(0)` was always supported by Clang and
MSVC. Demo: https://gcc.godbolt.org/z/q16837dax

[Bug testsuite/116635] new test case cc.dg/opt-ordered-and-nonequal-1.c from r15-3463-g91421e21e8f0f0 fails

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|other   |testsuite
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
   Keywords||patch, testsuite-fail

--- Comment #2 from Thomas Schwinge  ---
 "Match:
Fix ordered and nonequal: Fix 'gcc.dg/opt-ordered-and-nonequal-1.c' re
'LOGICAL_OP_NON_SHORT_CIRCUIT' [PR116635]"

[Bug target/116617] x86_64: arch lunarlake not documented

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Haochen Jiang :

https://gcc.gnu.org/g:91bc2ad28c58ca3f4c2f96601d8af51f570e08c4

commit r15-3539-g91bc2ad28c58ca3f4c2f96601d8af51f570e08c4
Author: Haochen Jiang 
Date:   Fri Sep 6 11:19:26 2024 +0800

doc: Enhance Intel CPU documentation

This patch will add those recent aliased CPU names into documentation
for clearness.

gcc/ChangeLog:

PR target/116617
* doc/invoke.texi: Add meteorlake, raptorlake and lunarlake.

[Bug target/116617] x86_64: arch lunarlake not documented

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Haochen Jiang
:

https://gcc.gnu.org/g:3951efed1cce970a5c61eacbad7e5f5314a9fc17

commit r14-10658-g3951efed1cce970a5c61eacbad7e5f5314a9fc17
Author: Haochen Jiang 
Date:   Fri Sep 6 11:19:26 2024 +0800

doc: Enhance Intel CPU documentation

This patch will add those recent aliased CPU names into documentation
for clearness.

gcc/ChangeLog:

PR target/116617
* doc/invoke.texi: Add meteorlake, raptorlake and lunarlake.

[Bug tree-optimization/116588] [14 Regression] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|15.0|
Summary|wrong code with -O2 |[14 Regression] wrong code
   |-fno-vect-cost-model|with -O2
   |-fno-tree-dominator-opts|-fno-vect-cost-model
   |-fno-tree-fre   |-fno-tree-dominator-opts
   |--param=vrp-block-limit=0   |-fno-tree-fre
   ||--param=vrp-block-limit=0
   Target Milestone|--- |14.3
  Known to work||15.0

--- Comment #5 from Richard Biener  ---
latent on the branch, the pass exists there as well.

[Bug target/116617] x86_64: arch lunarlake not documented

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Haochen Jiang
:

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

commit r13-9011-g0a16b1b97c112e41a0d37235e83678a67abd9454
Author: Haochen Jiang 
Date:   Fri Sep 6 11:19:26 2024 +0800

doc: Enhance Intel CPU documentation

This patch will add those recent aliased CPU names into documentation
for clearness, partly backported from GCC15 trunk patch.

gcc/ChangeLog:

PR target/116617
* doc/invoke.texi: Add meteorlake, raptorlake and lunarlake.