[Bug tree-optimization/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
Version|unknown |13.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2022-11-11
   Keywords||diagnostic
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
We diagnose because we see

int main ()
{
  long int _2;

   [local count: 1073741824]:
  _2 = 0;
  if (_2 != 0)
goto ; [10.00%]
  else
goto ; [90.00%]

   [local count: 107374184]:
  a ();

   [local count: 1073741824]:
  return 0;

}

and the reason is that for some reason

  /* Copy propagation also copy-propagates constants, this is necessary
 to forward object-size and builtin folding results properly.  */
  NEXT_PASS (pass_copy_prop);

doesn't work:

--- a-t2.c.224t.strlen2 2022-11-11 08:44:14.044322291 +0100
+++ a-t2.c.225t.copyprop5   2022-11-11 08:44:14.044322291 +0100
...
[local count: 1073741824]:
   b_5 = __builtin_object_size (0B, 0);
-  _1 = 0;
-  _2 = (long int) _1;
+  _2 = 0;
   if (_2 != 0)
 goto ; [10.00%]
   else

I will have a look.

[Bug tree-optimization/107617] SCC-VN with len_store and big endian

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC|richard.guenther at gmail dot com  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2022-11-11
  Component|middle-end  |tree-optimization
   Priority|P4  |P3

--- Comment #2 from Richard Biener  ---
Should be also reproducible on ppc64 big-endian?  Or does that not have
len_store enabled?

Can you try reducing the fortran testcase or create a C testcase that has
the actual miscompilation separated in a function?

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-11-11
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Here is an x86_64 testcase which shows the issue at -O1 -fsignaling-nans even
before Jakub's patch:
```
typedef __bf16 __attribute__((__vector_size__ (sizeof(__bf16 V;

int
foo (__bf16 v)
{
  return v < ((V)(short)65436)[0];
}
```

I only noticed it because right now at -O1 -fno-tree-dominator-opts
-fsignaling-nans causes an ICE (PR 107628). You could do a similar thing with
float rather than bf16 but I didn't want to take the chance.

Confirmed.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #35 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #34)
> (In reply to Aldy Hernandez from comment #33)

> > what you're looking for is frange::maybe_isinf.
> 
> Again, that works on frange, which I don't have here.

Ughhh...yeah...brain fart.  Sorry.

[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[13] Regression int128_t|[13 Regression] int128_t
   |shift generates extra   |shift generates extra
   |xor/or. |xor/or.
   Keywords||missed-optimization
   Target Milestone|--- |13.0

[Bug target/107627] [13] Regression int128_t shift generates extra xor/or.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
Looks like caused by r13-1379-ge8a46e5cdab500

[Bug rtl-optimization/107628] New: ICE: SIGSEGV in commutative_operand_precedence (rtlanal.cc:3770) with -fsignaling-nans

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 107628
   Summary: ICE: SIGSEGV in commutative_operand_precedence
(rtlanal.cc:3770) with -fsignaling-nans
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fsignaling-nans testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: Segmentation fault
4 | foo (V v)
  | ^~~
0x13e3a7f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:314
0x1373710 commutative_operand_precedence(rtx_def*)
/repo/gcc-trunk/gcc/rtlanal.cc:3770
0x1373897 swap_commutative_operands_p(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/rtlanal.cc:3845
0xfdf808 emit_store_flag_1
/repo/gcc-trunk/gcc/expmed.cc:5619
0xfdfec6 emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode,
int, int)
/repo/gcc-trunk/gcc/expmed.cc:6037
0xfe15ea emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
/repo/gcc-trunk/gcc/expmed.cc:6177
0x1d3ff93 gen_cstorebf4(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/i386/i386.md:1748
0x1298f08 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8002
0xfdf05a emit_cstore(rtx_def*, insn_code, rtx_code, machine_mode, machine_mode,
int, rtx_def*, rtx_def*, int, machine_mode)
/repo/gcc-trunk/gcc/expmed.cc:5527
0xfdf932 emit_store_flag_1
/repo/gcc-trunk/gcc/expmed.cc:5722
0xfdfec6 emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode,
int, int)
/repo/gcc-trunk/gcc/expmed.cc:6037
0xfe15ea emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
/repo/gcc-trunk/gcc/expmed.cc:6177
0xfef841 do_store_flag
/repo/gcc-trunk/gcc/expr.cc:13112
0xff0545 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/repo/gcc-trunk/gcc/expr.cc:10252
0xec31e8 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3983
0xec31e8 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4044
0xec92ce expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6096
0xecaecf execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6822
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See https://gcc.gnu.org/bugs/ for instructions.

$ 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-r13-3891-2022040058-gfbad7a74aaa-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/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-r13-3891-2022040058-gfbad7a74aaa-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 2022 (experimental) (GCC)

[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-3888-gb3ac43a3c05744d62a963d656bed782fc867ad79
Author: Jonathan Wakely 
Date:   Wed Nov 9 21:44:31 2022 +

libstdc++: Avoid redundant checks in std::use_facet [PR103755]

We do not need to do bounds checks or a runtime dynamic_cast when using
std::has_facet and std::use_facet to access the default facets that are
guaranteed to be present in every std::locale object. We can just index
straight into the array and use a static_cast for the conversion.

This patch adds a new std::__try_use_facet function that is like
std::use_facet but returns a pointer, so can be used to implement both
std::has_facet and std::use_facet. We can then do the necessary
metaprogramming to skip the redundant checks in std::__try_use_facet.

To avoid having to export (or hide) instantiations of the new function
from libstdc++.so the instantiations are given hidden visibility. This
allows them to be used in the library, but user code will instantiate it
again using the definition in the header. That would happen anyway,
because there are no explicit instantiation declarations for any of
std::has_facet, std::use_facet, or the new std::__try_use_facet.

libstdc++-v3/ChangeLog:

PR libstdc++/103755
* config/abi/pre/gnu.ver: Tighten patterns for facets in the
base version. Add exports for __try_use_facet.
* include/bits/basic_ios.tcc (basic_ios::_M_cache_locale): Use
__try_use_facet instead of has_facet and use_facet.
* include/bits/fstream.tcc (basic_filebuf::basic_filebuf()):
Likewise.
(basic_filebuf::imbue): Likewise.
* include/bits/locale_classes.h (locale, locale::id)
(locale::_Impl): Declare __try_use_facet as a friend.
* include/bits/locale_classes.tcc (__try_use_facet): Define new
function template with special cases for default facets.
(has_facet, use_facet): Call __try_use_facet.
* include/bits/locale_facets.tcc (__try_use_facet): Declare
explicit instantiations.
* include/bits/locale_facets_nonio.tcc (__try_use_facet):
Likewise.
* src/c++11/locale-inst-monetary.h (INSTANTIATE_FACET_ACCESSORS):
Use new macro for facet accessor instantiations.
* src/c++11/locale-inst-numeric.h (INSTANTIATE_FACET_ACCESSORS):
Likewise.
* src/c++11/locale-inst.cc (INSTANTIATE_USE_FACET): Define new
macro for instantiating __try_use_facet and use_facet.
(INSTANTIATE_FACET_ACCESSORS): Define new macro for also
defining has_facet.
* src/c++98/compatibility-ldbl.cc (__try_use_facet):
Instantiate.
* testsuite/22_locale/ctype/is/string/89728_neg.cc: Adjust
expected errors.

[Bug target/106220] x86-64 optimizer forgets about shrd peephole optimization pattern when faced with more than one in close proximity

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
Try to add combine splitter

(define_insn_and_split "*x86_64_shrd_lshiftrtti"
  [(set (match_operand:DI 0 "nonimmediate_operand")
(subreg:DI (lshiftrt:TI (match_operand:TI 1 "nonimmediate_operand")
(subreg:QI
  (and:SI
(match_operand:SI 2 "register_operand")
(const_int 63)) 0)) 0))
   (clobber (reg:CC FLAGS_REG))]

 but failed if there's more than 2 shrd insns since there's flags clobber in
the first shrd which prevent the second shrd to be combined. By the time it's
splitted after reload, it's too later to optimize off redudant cmovne.

[Bug c++/107622] Missing optimization of switch-statement

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

--- Comment #4 from Wilhelm M  ---
In the following class the static data member is accessible via explicit
template instantiation from the outside. So the compiler cannot reason that the
value is in [0,2]. But this does not hold for the function g(): here mState2 is
definitely not accessible from outside. But here the std::unreachable() is
still neccessary. here the optimization is missing. 

struct FSM {
enum class State : uint8_t {A, B, C};
static void f() {
switch(mState) {
case State::A:
o = 10;
break;
case State::B:
o = 11;
break;
case State::C:
o = 12;
break;
default:
//std::unreachable();
break;
}
}
static void g() {
static State mState2{State::A}; // not accessible from outside
switch(mState2) {
case State::A:
o = 10;
break;
case State::B:
o = 11;
break;
case State::C:
o = 12;
break;
default:
//std::unreachable();
break;
}
}
private:
inline static State mState{State::A}; // still modifyable via explicit
template instantiation
};

[Bug c++/107622] Missing optimization of switch-statement

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

--- Comment #3 from Wilhelm M  ---
(In reply to Andrew Pinski from comment #1)
> > In the following example the default-case 
> 
> Yes it can. You can pass a 0xf to that function and still have well defined
> behavior.

Oh yes, thank you for the hint!

[Bug c/85487] Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #17 from Jonathan Wakely  ---
Implemented for GCC 13.

[Bug c/85487] Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-3887-gd3fe767c16e7c528e4fc71c8a68ac14b4573d880
Author: Jonathan Wakely 
Date:   Wed Nov 9 21:49:52 2022 +

c-family: Support #pragma region/endregion [PR85487]

These pragmas are used by some editors to mark regions of code for
grouping and folding. GCC should silently ignore them, rather than
giving -Wunknown-pragmas warnings.

PR c/85487

gcc/ChangeLog:

* doc/cpp/pragmas.rst (Pragmas): Document region pragmas.

gcc/c-family/ChangeLog:

* c-pragma.cc (handle_pragma_ignore): New function.
(init_pragma): Register region and endregion pragmas.

gcc/testsuite/ChangeLog:

* c-c++-common/pragma-region.c: New test.

[Bug target/107627] New: [13] Regression int128_t shift generates extra xor/or.

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 107627
   Summary: [13] Regression int128_t shift generates extra xor/or.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---
Target: x86_64-*-* i?86-*-*

The case is from PR106220.

#include
static __inline
unsigned __int128 mk_u128(uint64_t hi, uint64_t lo)
{
  return ((unsigned __int128)hi << 64) | lo;
}

static __inline
uint64_t shrdq(uint64_t hi, uint64_t lo, unsigned rshift)
{
  return (uint64_t)(mk_u128(hi, lo) >> (rshift % 64));
}


void foo1to1(uint64_t *dst, const uint64_t* src, unsigned rshift)
{
  uint64_t r0 = shrdq(src[0], src[1], rshift);
  dst[0] = r0;
}


GCC trunk generates 

foo1to1:
mov rax, QWORD PTR [rsi]
mov r8, QWORD PTR [rsi+8]
mov ecx, edx
xor r9d, r9d
mov rdx, rax
xor eax, eax
or  rax, r8
or  rdx, r9
shrdrax, rdx, cl
mov QWORD PTR [rdi], rax

GCC12.2 generates

foo1to1:
mov rax, QWORD PTR [rsi+8]
mov r8, rdi
mov rdi, QWORD PTR [rsi]
mov ecx, edx
shrdrax, rdi, cl
mov QWORD PTR [r8], rax
ret

[Bug c++/105195] spurious warning label defined but not used with if constexpr

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

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

--- Comment #2 from Andrew Pinski  ---
MSVC warns too:
(12): warning C4102: 'label': unreferenced label
(17): note: see reference to function template instantiation 'void
f(void)' being compiled

clang does not though.
I think GCC should not warn either.

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #12 from joseph at codesourcery dot com  ---
__builtin_isnan must not raise "invalid" for signaling NaN arguments.

__builtin_isunordered (i.e. UNORDERED / UNORDERED_EXPR; standard macro 
isunordered) must raise "invalid" for signaling NaN arguments.

The -ftrapping-math option (which is on by default) means code 
transformations that either add or remove exceptions should be avoided 
(though this isn't implemented very consistently, especially as regards 
transformations that remove exceptions).

Thus, transforming in either direction between __builtin_isnan and 
UNORDERED_EXPR is undesirable given -ftrapping-math -fsignaling-nans.  
Given -fno-trapping-math or (default) -fno-signaling-nans, the 
transformation is OK.

[Bug driver/107448] [11/12/13 Regression] GCC no longer diagnoses missing input file with -MG since r11-6855-g4804de453e7f5f90

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||accepts-invalid
Summary|GCC no longer diagnoses |[11/12/13 Regression] GCC
   |missing input file with -MG |no longer diagnoses missing
   |since   |input file with -MG since
   |r11-6855-g4804de453e7f5f90  |r11-6855-g4804de453e7f5f90
   Target Milestone|--- |11.4

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #15 from Sergey Fedorov  ---
(In reply to Andrew Pinski from comment #13)
> Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
> (lharx/sthcx.) instruction support was added (which was for Power8;
> r0-123873-g4b02c96265fb52).

There was some argument re appropriateness lwarx etc. ages ago here:
https://lists.boost.org/Archives/boost//2005/04/83865.php
Though Peter Dimov said it is likely irrelevant.

> But that was 9 years ago.
> Is powerpc-darwin really coming back in style or something?

PPC is very much alive! :)
(Primarily thanks to Iain’s efforts with GCC – without a new GCC we could not
have done much. But yes, we have fixed some forever-broken stuff for PPC
recently, and process ongoing.)

[Bug c++/80637] constraint on a member function does causes ambigious and not allowing forming a pointer to the function

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Reduced testcase from the dup bug:

Oh MSVC still rejects this reduced testcase for the same reason as GCC.
(19): error C3535: cannot deduce type for 'auto' from
'overloaded-function'

[Bug c++/80637] constraint on a member function does causes ambigious and not allowing forming a pointer to the function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
Reduced testcase from the dup bug:

extern "C" int puts(const char*);

template 
class myclass {
public:

  void func(const T&) requires true
  {
 puts("true");
  }

  void func(const T&) requires false
  {
 puts("false");
  }
};  

auto mylambda = ::func;

[Bug c++/107605] constraint on a member function does causes ambigious and not allowing forming a pointer to the function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
Summary|constraint on a member  |constraint on a member
   |function gives ambiguous|function does causes
   |error when forming a|ambigious and not allowing
   |pointer to the function |forming a pointer to the
   ||function
 Status|NEW |RESOLVED

--- Comment #5 from Andrew Pinski  ---
Dup of bug 80637.

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

[Bug c++/80637] [concepts] incorrect ambiguous overload

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jlame646 at gmail dot com

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

[Bug c++/107605] constraint on a member function does causes ambigious and not allowing forming a pointer to the function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks|101603  |
Summary|GCC rejects valid program   |constraint on a member
   |involving requires-clause   |function does causes
   ||ambigious and not allowing
   ||forming a pointer to the
   ||function

--- Comment #4 from Andrew Pinski  ---
At first I thought it was a pointer to member function issue but nope it is not
as the following happens too but we need to have have the class as a template
rather than the function:
extern "C" int puts(const char*);

template 
class myclass {
public:

  static void func(const T&) requires true
  {
 puts("true");
  }

  static void func(const T&) requires false
  {
 puts("false");
  }
};  

auto mylambda = ::func;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
[Bug 101603] [meta-bug] pointer to member functions issues

[Bug middle-end/107626] STRICT_ALIGNMENT and TARGET_SLOW_UNALIGNED_ACCESS usage

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-11-10
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #1 from Andrew Pinski  ---
I am going to try my hand at this for GCC 14.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #14 from Iain Sandoe  ---
(In reply to Andrew Pinski from comment #13)
> Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
> (lharx/sthcx.) instruction support was added (which was for Power8;
> r0-123873-g4b02c96265fb52).
> 
> But that was 9 years ago.
> Is powerpc-darwin really coming back in style or something?

hehe ... it's never actually gone out of style .. but has (very) limited time
available, so sometimes gets broken for a while ..
.. right now we have some keen folks doing some testing on a wider range of
packages.

sorry my comments are not more constructive right now - I'm fully tied up with
WG21 meeting.

[Bug analyzer/107625] RFE: analyzer support for dlopen etc

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

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

--- Comment #1 from Andrew Pinski  ---
dlmopen should be supported too (it is described in the same man page as
dlopen).

Note here is the POSIX 2018 page for dlopen:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlopen.html

[Bug middle-end/107626] New: STRICT_ALIGNMENT and TARGET_SLOW_UNALIGNED_ACCESS usage

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

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

Bug ID: 107626
   Summary: STRICT_ALIGNMENT and TARGET_SLOW_UNALIGNED_ACCESS
usage
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: documentation, internal-improvement
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

As explained in bug 107601 comment #3, these target macros/hooks usage should
be auditted in the middle-end to make sure they are used correctly and explain
better in the documentation on what their usage is.

STRICT_ALIGNMENT says all (some?) unaligned access will cause a trap and GCC
should not try to use them at all.
While TARGET_SLOW_UNALIGNED_ACCESS should tell the middle-end if a load/store
with a specific mode with a specific alignment will be much slow (where much is
usually in the order of 10x or so) than an aligned case.

An good example for usage of TARGET_SLOW_UNALIGNED_ACCESS is the powerpc*-linux
(ABI and arch) which says a floating point load/store to a 4 byte aligned (even
a 8 byte load) will not cause a trap so it will be handled in HW while
otherwise it will cause a trap (and the Linux kernel should handle the
load/store) and it will be slow. So this is techincally not a STRICT_ALIGNMENT
target as required by the ABI but  TARGET_SLOW_UNALIGNED_ACCESS should be used
there.

This should be expanded and put in the documentation here.

[Bug analyzer/107625] New: RFE: analyzer support for dlopen etc

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

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

Bug ID: 107625
   Summary: RFE: analyzer support for dlopen etc
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Perhaps the analyzer could support:
  * dlopen
  * dlclose
  * dlsym

Notes: see:
  https://man7.org/linux/man-pages/man3/dlopen.3.html (covers dlclose also)
  https://man7.org/linux/man-pages/man3/dlsym.3.html

Potentially we could track:
  - dlopen succeeding vs dlopen failing
  - dlsym after dlclose
  - double-'dlclose'
  - pointers returned from dlsym becoming invalid after dlclose (e.g.
attempting to call a function after a 'dlclose')
(potentially create a region for the "dlopen", putting code/data within it,
so that we can track the memory regions that become invalid after dlclose)

Would be great to be able to do some kind of type-checking on the result of
"dlsym", but I'm not sure how we could reliably get at the actual type of the
symbol.

[Bug middle-end/107601] Change SLOW_BYTE_ACCESS into WIDEN_MODE_ACCESS_BITFIELD target hook

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> Related is probably STRICT_ALIGNMENT vs TARGET_SLOW_UNALIGNED_ACCESS

That one comes up every once in a while though less often though
STRICT_ALIGNMENT and TARGET_SLOW_UNALIGNED_ACCESS SHOULD have a well defined
meaning some folks misunderstand them. RS6000 target has a decent usage of them
really. Definitely Something which should be expanded on in the documentation
and made use it is used correctly in the middle-end but that is for a different
bug (which I am going to file).

[Bug target/107609] ice in extract_insn, at recog.cc:2791

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-10
   Keywords||ice-on-valid-code, patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2022-Novembe
   ||r/605453.html
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Patch already submitted for this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605453.html

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #13 from Andrew Pinski  ---
Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
(lharx/sthcx.) instruction support was added (which was for Power8;
r0-123873-g4b02c96265fb52).

But that was 9 years ago.
Is powerpc-darwin really coming back in style or something?

[Bug fortran/107444] ICE on character, value, optional dummy argument

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-November/058476.html

[Bug c++/107624] [c++23] Wrong code with static operator ()

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

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

--- Comment #1 from Andrew Pinski  ---
This is interesting because clang also does not produce a call for the foo
either for "foo (0) (0);".

[Bug c++/107624] New: Wrong code with static operator ()

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

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

Bug ID: 107624
   Summary: Wrong code with static operator ()
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

In:
struct S {
  static void operator() (int);
  static void baz (int);
};
S  (int);

void
bar ()
{
  foo (0) (0);
  foo (1).baz (1);
}
we transform the latter into *foo (1), S::baz (1), but the former into just
S::operator() (0) - the side-effects on the postfix-expression are gone.
Shouldn't we add that somewhere as COMPOUND_EXPR when we select a static
operator() (ditto for static operator[])?

[Bug c++/107622] Missing optimization of switch-statement

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

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

--- Comment #2 from Andrew Pinski  ---
There is one part which GCC could optimize better that is the store.
There might be another bug about that too.

Note as I mentioned __builtin_unreachable is needed if truely the value coming
inside g is outside of [0,3] range.

[Bug other/107621] spinx generated documents has too much white space on the top

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

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

--- Comment #6 from Andrew Pinski  ---
How does this fancy stuff work on a text based browser like links or lynx?
Do we really need this fancy stuff for a manual?
Seriously this is getting out of hand.

[Bug other/107621] spinx generated documents has too much white space on the top

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
The unnecessary empty space appears due to some subresources not loading as a
result of a Content-Security-Policy issue:

https://inbox.sourceware.org/gcc-patches/5ea2ef7e-4b89-272f-c8e1-f3874c9fa...@pfeifer.com/T/#m5acd422ef000b9758206cb186fe62d6244b8cd47

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
-Winfinite-recursion was implemented as PR 88232, which complains if every path
through a function calls itself.

I have a mostly-finished implementation of a new -Wanalyzer-infinite-recursion
which complains if there is an interprocedural path through the code in which a
function is called recursively where there's no significant change to the
content of memory between calls, so it detects cases like:

void test_guarded (int flag)
{
  if (flag)
test_guarded (flag);
}

[Bug c++/107623] Using a parameter pack twice results in ambiguous overloaded function.

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

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

--- Comment #1 from Andrew Pinski  ---
On the trunk (with --enable-checking=yes) we get an ICE:
: In function 'int main()':
:10:11: internal compiler error: in comptypes, at cp/typeck.cc:1684
   10 |   test(f, 1);
  |   ^~
0x23961de internal_error(char const*, ...)
???:0
0xaaa542 fancy_abort(char const*, int, char const*)
???:0
0xce0f15 more_specialized_fn(tree_node*, tree_node*, int)
???:0
0xad8609 build_new_function_call(tree_node*, vec**, int)
???:0
0xd01048 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xc88297 c_parse_file()
???:0
0xdd1699 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 https://gcc.gnu.org/bugs/ for instructions.
ASM generation compiler returned: 1

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[samuelpmish at gmail dot com via Gcc-bugs]

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

Sam Mish  changed:

   What|Removed |Added

 CC||samuelpmish at gmail dot com

--- Comment #22 from Sam Mish  ---
I'm hitting an issue similar to this in one of my projects:

gcc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0


When linking with lto on a optimized build, gcc12 is crashing (apologies for
the long link line)

/usr/bin/g++-12 -Wall -Wextra  -pthread -save-temps -Werror  -Wshadow
-Wdouble-promotion -Wconversion -Wundef -Wnull-dereference -Wold-style-cast 
-O3 -DNDEBUG -rdynamic-fopenmp -Wl,-Bsymbolic-functions
src/serac/numerics/functional/tests/CMakeFiles/functional_qoi.dir/functional_qoi.cpp.o
-o tests/functional_qoi 
-Wl,-rpath,/home/sam/code/serac_libs_gcc12/gcc-12.1.0/lua-5.3.5-dquw3g42r65n5xisjxjm4qn77ztburb5/lib
 lib/libgtest_main.a  lib/libgtest.a  lib/libserac_state.a  lib/libserac_mesh.a
 lib/libserac_numerics.a  lib/libserac_infrastructure.a  lib/libaxom.a 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/umpire-2022.03.1-oh5f65jhr3zzxcaa52hbl5v6hokl7ukj/lib/libumpire.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/raja-2022.03.0-ssk34466yhhqwld7szsrmbc65e4c5257/lib/libRAJA.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/camp-2022.03.2-wb6wkruuotyvmioa4ngks4klpoiyxvp4/lib/libcamp.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hdf5-1.8.21-izgwwdm7ola6qvpco4g5th4ywabgnysx/lib/libhdf5.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_relay_mpi_io.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_relay.a
 -lrt 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_blueprint_mpi.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_blueprint.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_relay_mpi.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/lua-5.3.5-dquw3g42r65n5xisjxjm4qn77ztburb5/lib/liblua.so
 lib/libmfem.a  /usr/lib/gcc/x86_64-linux-gnu/12/libgomp.so 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hypre-2.18.2-qjtod2f6fq6gs27xtac52qsogpaomxg5/lib/libHYPRE.a
 /usr/lib/x86_64-linux-gnu/libopenblas.so  -lm  -ldl 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/superlu-dist-6.1.1-dzfbn5o7xmj4afrbu5bobphtc6uo2cgl/lib/libsuperlu_dist.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/parmetis-4.0.3-basm6qwardrie3ty4shbelvyadmtes3j/lib/libparmetis.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/metis-5.1.0-srkgcb2bm5fwesct5zqa3y6h74jfwcf2/lib/libmetis.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_nvecserial.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_nvecparallel.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_nvecmpiplusx.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_cvodes.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_arkode.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_kinsol.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/netcdf-c-4.7.4-ty2aqukbd6j7uuezhi7s42r7c7qqpynn/lib/libnetcdf.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hdf5-1.8.21-izgwwdm7ola6qvpco4g5th4ywabgnysx/lib/libhdf5_hl.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hdf5-1.8.21-izgwwdm7ola6qvpco4g5th4ywabgnysx/lib/libhdf5.a
 -lm  -ldl 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hdf5-1.8.21-izgwwdm7ola6qvpco4g5th4ywabgnysx/lib/libhdf5.a
 /usr/lib/x86_64-linux-gnu/libz.so  /usr/lib/x86_64-linux-gnu/libmpichcxx.so 
/usr/lib/x86_64-linux-gnu/libmpich.so && :
[build] during IPA pass: icf
[build] lto1: internal compiler error: Segmentation fault
[build] 0xb1f113 crash_signal
[build] ../../src/gcc/toplev.cc:322
[build] 0x7fe21814551f ???
[build] ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
[build] 0xdda228 varpool_node::get_constructor()
[build] ../../src/gcc/varpool.cc:300
[build] 0x17aea53 ipa_icf::sem_variable::equals(ipa_icf::sem_item*,
hash_map, ipa_icf::sem_item*>
>&)
[build] ../../src/gcc/ipa-icf.cc:1697
[build] 0x17afabe
ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool)
[build] ../../src/gcc/ipa-icf.cc:2732
[build] 0x17b7952 ipa_icf::sem_item_optimizer::execute()
[build] ../../src/gcc/ipa-icf.cc:2464
[build] 0x17b91ba ipa_icf_driver
[build] ../../src/gcc/ipa-icf.cc:3600
[build] 0x17b91ba ipa_icf::pass_ipa_icf::execute(function*)
[build] 

[Bug c++/107622] Missing optimization of switch-statement

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

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

--- Comment #1 from Andrew Pinski  ---
> In the following example the default-case 

Yes it can. You can pass a 0xf to that function and still have well defined
behavior.

[Bug c++/107623] New: Using a parameter pack twice results in ambiguous overloaded function.

[jlaros at fixedpoint dot nl via Gcc-bugs]

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

Bug ID: 107623
   Summary: Using a parameter pack twice results in ambiguous
overloaded function.
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlaros at fixedpoint dot nl
  Target Milestone: ---

The following example does not compile:

template 
void test(R (*)(Args...), Args...) {}

template 
void test(void (*)(Args...), Args...) {}

int main() {
  void (*f)(int) {};
  test(f, 1);
}

Example:

$ g++ -Wall -Wextra -pedantic x.cc
x.cc: In function ‘int main()’:
x.cc:11:7: error: call of overloaded ‘test(void (*&)(int), int)’ is
ambiguous
   11 |   test(f, 1);
  |   ^~
x.cc:2:6: note: candidate: ‘void test(R (*)(Args ...), Args ...) [with R =
void; Args = {int}]’
2 | void test(R (*)(Args...), Args...) {}
  |  ^~~~
x.cc:5:6: note: candidate: ‘void test(void (*)(Args ...), Args ...) [with
Args = {int}]’
5 | void test(void (*)(Args...), Args...) {}
  |  ^~~~

This might be a bug because the following variants on the same theme do compile
without errors or warnings:

template 
void test(R (*)(T), T) {}

template 
void test(void (*)(T), T) {}

And:

template 
void test(R (*)(FArgs...), Args...) {}

template 
void test(void (*)(FArgs...), Args...) {}

The first example does compile when using clang (version 14.0.6).

[Bug c++/107622] New: Missing optimization of switch-statement

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

Bug ID: 107622
   Summary: Missing optimization of switch-statement
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: klaus.doldinger64 at googlemail dot com
  Target Milestone: ---

In the following example the default-case could not be reached. Therefore
introducing std::unreachable() should be useless. But the compiler produces
slightly better code with std::unreachable() as it removes one (unneccessary)
comparison (tested for x86 and avr targets).

volatile uint8_t o;

enum class State : uint8_t {A, B, C};

void g(const State s) {
switch(s) {
case State::A:
o = 10;
break;
case State::B:
o = 11;
break;
case State::C:
o = 12;
break;
default:
//std::unreachable(); // __builtin_unreachable();
break;
}
}

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #34 from Jakub Jelinek  ---
(In reply to Aldy Hernandez from comment #33)
> (In reply to Jakub Jelinek from comment #31)
> > Created attachment 53873 [details]
> > gcc13-pr107569-div.patch
> > 
> > This is what I meant by complete nightmare - division.
> 
> We can take this to gcc-patches when you're done, but just a few thoughts...
> 
> +// If +-0.0 is in both ranges, it is a maybe NAN.
> +if (real_compare (LE_EXPR, _lb, )
> + && real_compare (GE_EXPR, _ub, )
> + && real_compare (LE_EXPR, _lb, )
> + && real_compare (GE_EXPR, _ub, ))
> 
> Perhaps we could provide frange::contains_zero_p ()?

Well, contains_p in irange is a method on the value range, while here we don't
have a frange, but just naked REAL_VALUE_TYPEs.
It is twice contains_zero_p...
> 
> +// +-0.0 / +-0.0 or +-INF / +-INF is a known NAN.
> +if ((real_iszero (_lb)
> +  && real_iszero (_ub)
> +  && real_iszero (_lb)
> +  && real_iszero (_ub))
> 
> This looks like frange::contains_zerp_p () as well.

No, this is twice zero_p.  Due to signed zeros it isn't a singleton +
contains_zero_p, just both boundaries are zero.

> + || (real_isinf (_lb)
> + && real_isinf (_ub, real_isneg (_lb))
> + && real_isinf (_lb)
> + && real_isinf (_ub, real_isneg (_lb
> 
> Note that, real_isinf with only one argument checks for +-INF.

I know.  I'm intentionally using one and 2 argument ones to verify
that lh is either [INF,INF] or [-INF,-INF], but not [-INF,INF].

>  But I think
> what you're looking for is frange::maybe_isinf.

Again, that works on frange, which I don't have here.
> 
> Could your patch be simplified with some of these?
> 
>   // fpclassify like API
>   bool known_isfinite () const;
>   bool known_isnan () const;
>   bool known_isinf () const;
>   bool maybe_isnan () const;
>   bool maybe_isnan (bool sign) const;
>   bool maybe_isinf () const;
>   bool signbit_p (bool ) const;
>   bool nan_signbit_p (bool ) const;
> 
> We should ultimately avoid peeking at the end points unnecessarily in order
> to prepare ourselves for next release when we (hopefully) have sub-ranges.

No, see above (at least for now).  The peeking at the end points is needed
because those end points behave weirdly.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #33 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #31)
> Created attachment 53873 [details]
> gcc13-pr107569-div.patch
> 
> This is what I meant by complete nightmare - division.

We can take this to gcc-patches when you're done, but just a few thoughts...

+// If +-0.0 is in both ranges, it is a maybe NAN.
+if (real_compare (LE_EXPR, _lb, )
+   && real_compare (GE_EXPR, _ub, )
+   && real_compare (LE_EXPR, _lb, )
+   && real_compare (GE_EXPR, _ub, ))

Perhaps we could provide frange::contains_zero_p ()?

+// +-0.0 / +-0.0 or +-INF / +-INF is a known NAN.
+if ((real_iszero (_lb)
+&& real_iszero (_ub)
+&& real_iszero (_lb)
+&& real_iszero (_ub))

This looks like frange::contains_zerp_p () as well.

+   || (real_isinf (_lb)
+   && real_isinf (_ub, real_isneg (_lb))
+   && real_isinf (_lb)
+   && real_isinf (_ub, real_isneg (_lb

Note that, real_isinf with only one argument checks for +-INF.  But I think
what you're looking for is frange::maybe_isinf.

Could your patch be simplified with some of these?

  // fpclassify like API
  bool known_isfinite () const;
  bool known_isnan () const;
  bool known_isinf () const;
  bool maybe_isnan () const;
  bool maybe_isnan (bool sign) const;
  bool maybe_isinf () const;
  bool signbit_p (bool ) const;
  bool nan_signbit_p (bool ) const;

We should ultimately avoid peeking at the end points unnecessarily in order to
prepare ourselves for next release when we (hopefully) have sub-ranges.

[Bug fortran/107595] ICE in ix86_push_argument, at config/i386/i386.cc:4335

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|13.0|---
Summary|[13 Regression] ICE in  |ICE in ix86_push_argument,
   |ix86_push_argument, at  |at config/i386/i386.cc:4335
   |config/i386/i386.cc:4335|

[Bug fortran/107595] [13 Regression] ICE in ix86_push_argument, at config/i386/i386.cc:4335

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> The initializer is
> 
> {.a=4, .b=null ()}
> 
> the frontend would need to lower such initializers to runtime initialization
> (or not use static storage).

Right.  The tree-dump for z2 has

  static struct t x = {.a=4, .b=0B};

which is what is expected, while z1 currently gives

  static struct t x = {.a=4, .b=null ()};

That looks like sth. that is fixable.

(There is at least one other compiler that supports the same extension.)

On the other hand, since I get the same ICE with all versions down to v7,
why is this marked as a regression?

[Bug middle-end/77432] warn about null check after pointer dereference

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

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

--- Comment #7 from David Malcolm  ---
(In reply to David Malcolm from comment #5)
> I hadn't seen this, and I filed PR analyzer/99671 last year to track adding
> a -fanalyzer warning for this.  I now have a mostly-working implementation
> of the latter which I'm hoping to post for stage 1.

I've now committed the above patch implementing -Wanalyzer-deref-before-check
for GCC 13 as part of -fanalyzer.

> Not sure if these are dupes or not (would we want a non-analyzer
> implementation of this warning?)

Do we want a non-analyzer implementation of this warning, or should we close
this out?

[Bug analyzer/99671] RFE: analyzer could complain about ptr derefs that occur before the ptr is checked

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
Implemented for GCC 13 by the above patch; closing this RFE.

[Bug analyzer/99671] RFE: analyzer could complain about ptr derefs that occur before the ptr is checked

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:5c6546ca7d8cab1f1c129f5b55f709e2ceee0f94

commit r13-3884-g5c6546ca7d8cab1f1c129f5b55f709e2ceee0f94
Author: David Malcolm 
Date:   Thu Nov 10 13:23:56 2022 -0500

analyzer: new warning: -Wanalyzer-deref-before-check [PR99671]

This patch implements a new -Wanalyzer-deref-before-check within
-fanalyzer.  It complains about code paths in which a pointer is checked
for NULL after it has already been dereferenced.

For example, for the testcase in PR 77432 the diagnostic emits:
deref-before-check-1.c: In function 'test_from_pr77432':
deref-before-check-1.c:6:8: warning: check of 'a' for NULL after already
dereferencing it [-Wanalyzer-deref-before-check]
6 | if (a)
  |^
  'test_from_pr77432': events 1-2
|
|5 | int b = *a;
|  | ^
|  | |
|  | (1) pointer 'a' is dereferenced here
|6 | if (a)
|  |~
|  ||
|  |(2) pointer 'a' is checked for NULL here but it was
already dereferenced at (1)
|

and in PR 77425 we had an instance of this hidden behind a
macro, which the diagnostic complains about as follows:

deref-before-check-pr77425.c: In function 'get_odr_type':
deref-before-check-pr77425.c:35:10: warning: check of 'odr_types_ptr' for
NULL after already dereferencing it [-Wanalyzer-deref-before-check]
   35 |   if (odr_types_ptr)
  |  ^
  'get_odr_type': events 1-3
|
|   27 |   if (cond)
|  |  ^
|  |  |
|  |  (1) following 'false' branch...
|..
|   31 |   else if (other_cond)
|  |   ~~~
|  |   ||
|  |   |(2) ...to here
|  |   (3) following 'true' branch...
|
  'get_odr_type': event 4
|
|   11 | #define odr_types (*odr_types_ptr)
|  |   ~^~~
|  ||
|  |(4) ...to here
deref-before-check-pr77425.c:33:7: note: in expansion of macro 'odr_types'
|   33 |   odr_types[val->id] = 0;
|  |   ^
|
  'get_odr_type': event 5
|
|   11 | #define odr_types (*odr_types_ptr)
|  |   ~^~~
|  ||
|  |(5) pointer 'odr_types_ptr' is dereferenced
here
deref-before-check-pr77425.c:33:7: note: in expansion of macro 'odr_types'
|   33 |   odr_types[val->id] = 0;
|  |   ^
|
  'get_odr_type': event 6
|
|   35 |   if (odr_types_ptr)
|  |  ^
|  |  |
|  |  (6) pointer 'odr_types_ptr' is checked for NULL here
but it was already dereferenced at (5)
|

gcc/analyzer/ChangeLog:
PR analyzer/99671
* analyzer.opt (Wanalyzer-deref-before-check): New warning.
* diagnostic-manager.cc
(null_assignment_sm_context::set_next_state): Only add state
change events for transition to "null" state.
(null_assignment_sm_context::is_transition_to_null): New.
* engine.cc (impl_region_model_context::on_pop_frame): New.
* exploded-graph.h (impl_region_model_context::on_pop_frame): New
decl.
* program-state.cc (sm_state_map::clear_any_state): New.
(sm_state_map::can_merge_with_p): New.
(program_state::can_merge_with_p): Replace requirement that
sm-states be equal in favor of an attempt to merge them.
* program-state.h (sm_state_map::clear_any_state): New decl.
(sm_state_map::can_merge_with_p): New decl.
* region-model.cc (region_model::eval_condition): Make const.
(region_model::pop_frame): Call ctxt->on_pop_frame.
* region-model.h (region_model::eval_condition): Make const.
(region_model_context::on_pop_frame): New vfunc.
(noop_region_model_context::on_pop_frame): New.
(region_model_context_decorator::on_pop_frame): New.
* sm-malloc.cc (enum resource_state): Add RS_ASSUMED_NON_NULL.
(allocation_state::dump_to_pp): Drop "final".
(struct assumed_non_null_state): New subclass.
(malloc_state_machine::m_assumed_non_null): New.
(assumed_non_null_p): New.
(class deref_before_check): New.
(assumed_non_null_state::dump_to_pp): New.
   
(malloc_state_machine::get_or_create_assumed_non_null_state_for_frame):
  

[Bug middle-end/77432] warn about null check after pointer dereference

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:5c6546ca7d8cab1f1c129f5b55f709e2ceee0f94

commit r13-3884-g5c6546ca7d8cab1f1c129f5b55f709e2ceee0f94
Author: David Malcolm 
Date:   Thu Nov 10 13:23:56 2022 -0500

analyzer: new warning: -Wanalyzer-deref-before-check [PR99671]

This patch implements a new -Wanalyzer-deref-before-check within
-fanalyzer.  It complains about code paths in which a pointer is checked
for NULL after it has already been dereferenced.

For example, for the testcase in PR 77432 the diagnostic emits:
deref-before-check-1.c: In function 'test_from_pr77432':
deref-before-check-1.c:6:8: warning: check of 'a' for NULL after already
dereferencing it [-Wanalyzer-deref-before-check]
6 | if (a)
  |^
  'test_from_pr77432': events 1-2
|
|5 | int b = *a;
|  | ^
|  | |
|  | (1) pointer 'a' is dereferenced here
|6 | if (a)
|  |~
|  ||
|  |(2) pointer 'a' is checked for NULL here but it was
already dereferenced at (1)
|

and in PR 77425 we had an instance of this hidden behind a
macro, which the diagnostic complains about as follows:

deref-before-check-pr77425.c: In function 'get_odr_type':
deref-before-check-pr77425.c:35:10: warning: check of 'odr_types_ptr' for
NULL after already dereferencing it [-Wanalyzer-deref-before-check]
   35 |   if (odr_types_ptr)
  |  ^
  'get_odr_type': events 1-3
|
|   27 |   if (cond)
|  |  ^
|  |  |
|  |  (1) following 'false' branch...
|..
|   31 |   else if (other_cond)
|  |   ~~~
|  |   ||
|  |   |(2) ...to here
|  |   (3) following 'true' branch...
|
  'get_odr_type': event 4
|
|   11 | #define odr_types (*odr_types_ptr)
|  |   ~^~~
|  ||
|  |(4) ...to here
deref-before-check-pr77425.c:33:7: note: in expansion of macro 'odr_types'
|   33 |   odr_types[val->id] = 0;
|  |   ^
|
  'get_odr_type': event 5
|
|   11 | #define odr_types (*odr_types_ptr)
|  |   ~^~~
|  ||
|  |(5) pointer 'odr_types_ptr' is dereferenced
here
deref-before-check-pr77425.c:33:7: note: in expansion of macro 'odr_types'
|   33 |   odr_types[val->id] = 0;
|  |   ^
|
  'get_odr_type': event 6
|
|   35 |   if (odr_types_ptr)
|  |  ^
|  |  |
|  |  (6) pointer 'odr_types_ptr' is checked for NULL here
but it was already dereferenced at (5)
|

gcc/analyzer/ChangeLog:
PR analyzer/99671
* analyzer.opt (Wanalyzer-deref-before-check): New warning.
* diagnostic-manager.cc
(null_assignment_sm_context::set_next_state): Only add state
change events for transition to "null" state.
(null_assignment_sm_context::is_transition_to_null): New.
* engine.cc (impl_region_model_context::on_pop_frame): New.
* exploded-graph.h (impl_region_model_context::on_pop_frame): New
decl.
* program-state.cc (sm_state_map::clear_any_state): New.
(sm_state_map::can_merge_with_p): New.
(program_state::can_merge_with_p): Replace requirement that
sm-states be equal in favor of an attempt to merge them.
* program-state.h (sm_state_map::clear_any_state): New decl.
(sm_state_map::can_merge_with_p): New decl.
* region-model.cc (region_model::eval_condition): Make const.
(region_model::pop_frame): Call ctxt->on_pop_frame.
* region-model.h (region_model::eval_condition): Make const.
(region_model_context::on_pop_frame): New vfunc.
(noop_region_model_context::on_pop_frame): New.
(region_model_context_decorator::on_pop_frame): New.
* sm-malloc.cc (enum resource_state): Add RS_ASSUMED_NON_NULL.
(allocation_state::dump_to_pp): Drop "final".
(struct assumed_non_null_state): New subclass.
(malloc_state_machine::m_assumed_non_null): New.
(assumed_non_null_p): New.
(class deref_before_check): New.
(assumed_non_null_state::dump_to_pp): New.
   
(malloc_state_machine::get_or_create_assumed_non_null_state_for_frame):
  

[Bug rtl-optimization/77425] Pointer test follows dereference in sched-int.h

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:5c6546ca7d8cab1f1c129f5b55f709e2ceee0f94

commit r13-3884-g5c6546ca7d8cab1f1c129f5b55f709e2ceee0f94
Author: David Malcolm 
Date:   Thu Nov 10 13:23:56 2022 -0500

analyzer: new warning: -Wanalyzer-deref-before-check [PR99671]

This patch implements a new -Wanalyzer-deref-before-check within
-fanalyzer.  It complains about code paths in which a pointer is checked
for NULL after it has already been dereferenced.

For example, for the testcase in PR 77432 the diagnostic emits:
deref-before-check-1.c: In function 'test_from_pr77432':
deref-before-check-1.c:6:8: warning: check of 'a' for NULL after already
dereferencing it [-Wanalyzer-deref-before-check]
6 | if (a)
  |^
  'test_from_pr77432': events 1-2
|
|5 | int b = *a;
|  | ^
|  | |
|  | (1) pointer 'a' is dereferenced here
|6 | if (a)
|  |~
|  ||
|  |(2) pointer 'a' is checked for NULL here but it was
already dereferenced at (1)
|

and in PR 77425 we had an instance of this hidden behind a
macro, which the diagnostic complains about as follows:

deref-before-check-pr77425.c: In function 'get_odr_type':
deref-before-check-pr77425.c:35:10: warning: check of 'odr_types_ptr' for
NULL after already dereferencing it [-Wanalyzer-deref-before-check]
   35 |   if (odr_types_ptr)
  |  ^
  'get_odr_type': events 1-3
|
|   27 |   if (cond)
|  |  ^
|  |  |
|  |  (1) following 'false' branch...
|..
|   31 |   else if (other_cond)
|  |   ~~~
|  |   ||
|  |   |(2) ...to here
|  |   (3) following 'true' branch...
|
  'get_odr_type': event 4
|
|   11 | #define odr_types (*odr_types_ptr)
|  |   ~^~~
|  ||
|  |(4) ...to here
deref-before-check-pr77425.c:33:7: note: in expansion of macro 'odr_types'
|   33 |   odr_types[val->id] = 0;
|  |   ^
|
  'get_odr_type': event 5
|
|   11 | #define odr_types (*odr_types_ptr)
|  |   ~^~~
|  ||
|  |(5) pointer 'odr_types_ptr' is dereferenced
here
deref-before-check-pr77425.c:33:7: note: in expansion of macro 'odr_types'
|   33 |   odr_types[val->id] = 0;
|  |   ^
|
  'get_odr_type': event 6
|
|   35 |   if (odr_types_ptr)
|  |  ^
|  |  |
|  |  (6) pointer 'odr_types_ptr' is checked for NULL here
but it was already dereferenced at (5)
|

gcc/analyzer/ChangeLog:
PR analyzer/99671
* analyzer.opt (Wanalyzer-deref-before-check): New warning.
* diagnostic-manager.cc
(null_assignment_sm_context::set_next_state): Only add state
change events for transition to "null" state.
(null_assignment_sm_context::is_transition_to_null): New.
* engine.cc (impl_region_model_context::on_pop_frame): New.
* exploded-graph.h (impl_region_model_context::on_pop_frame): New
decl.
* program-state.cc (sm_state_map::clear_any_state): New.
(sm_state_map::can_merge_with_p): New.
(program_state::can_merge_with_p): Replace requirement that
sm-states be equal in favor of an attempt to merge them.
* program-state.h (sm_state_map::clear_any_state): New decl.
(sm_state_map::can_merge_with_p): New decl.
* region-model.cc (region_model::eval_condition): Make const.
(region_model::pop_frame): Call ctxt->on_pop_frame.
* region-model.h (region_model::eval_condition): Make const.
(region_model_context::on_pop_frame): New vfunc.
(noop_region_model_context::on_pop_frame): New.
(region_model_context_decorator::on_pop_frame): New.
* sm-malloc.cc (enum resource_state): Add RS_ASSUMED_NON_NULL.
(allocation_state::dump_to_pp): Drop "final".
(struct assumed_non_null_state): New subclass.
(malloc_state_machine::m_assumed_non_null): New.
(assumed_non_null_p): New.
(class deref_before_check): New.
(assumed_non_null_state::dump_to_pp): New.
   
(malloc_state_machine::get_or_create_assumed_non_null_state_for_frame):
  

[Bug other/107621] spinx generated documents has too much white space on the top

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 53878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53878=edit
Chrome on Windows at normal zoom

So much whitespace on the top and even on the left side which is distracting.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #12 from Sergey Fedorov  ---
(In reply to Andrew Pinski from comment #2)
> >Reason: 259 at address: 0x3109
> 
> Yes that does seem like an alignment disagreement.
> 
> I suspect the code is broken for allocation and it is allocating unaligned
> structs.
> 
> Also inside gdb can you do the following:
> 
> disassemble $pc-0x10 $pc+0x10
> info registers

Here:

(gdb) run
Starting program: /Users/svacchanda/Dev/boost/a.out 
Reading symbols for shared libraries .. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 259 at address: 0x208d
0x1b38 in boost::detail::spinlock::try_lock (this=0x208d) at
spinlock_gcc_atomic.hpp:39
39  return __atomic_test_and_set( _, __ATOMIC_ACQUIRE ) == 0;
(gdb) disassemble $pc-0x10 $pc+0x10
Dump of assembler code from 0x1b28 to 0x1b48:
0x1b28 <_ZN5boost6detail8spinlock8try_lockEv+8>:mr  r30,r1
0x1b2c <_ZN5boost6detail8spinlock8try_lockEv+12>:   stw r3,72(r30)
0x1b30 <_ZN5boost6detail8spinlock8try_lockEv+16>:   lwz r2,72(r30)
0x1b34 <_ZN5boost6detail8spinlock8try_lockEv+20>:   li  r9,1
0x1b38 <_ZN5boost6detail8spinlock8try_lockEv+24>:   lwarx   r10,0,r2
0x1b3c <_ZN5boost6detail8spinlock8try_lockEv+28>:   stwcx.  r9,0,r2
0x1b40 <_ZN5boost6detail8spinlock8try_lockEv+32>:   bne-0x1b38
<_ZN5boost6detail8spinlock8try_lockEv+24>
0x1b44 <_ZN5boost6detail8spinlock8try_lockEv+36>:   isync
End of assembler dump.
(gdb) info registers
r0 0x19c4   6596
r1 0xb9f0   3221223920
r2 0x208d   8333
r3 0x208d   8333
r4 0xbb30   3221224240
r5 0xbb38   3221224248
r6 0xbb88   3221224328
r7 0xc  12
r8 0x0  0
r9 0x1  1
r100x0  0
r110x2048   8264
r120x1b20   6944
r130x0  0
r140x0  0
r150x0  0
r160x0  0
r170x0  0
r180x0  0
r190x0  0
r200x0  0
r210x0  0
r220x0  0
r230x0  0
r240x0  0
r250x0  0
r260xbb2c   3221224236
r270x8  8
r280x0  0
r290x0  0
r300xb9f0   3221223920
r310x19a8   6568
pc 0x1b38   6968
ps 0x1000f030   1152921504606908464
cr 0x2402   603979778
lr 0x1ba4   7076
ctr0x1b20   6944
xer0x0  0
mq 0x0  0
fpscr  0x0  0
vscr   0x1  65536
vrsave 0x0  0

[Bug other/107621] spinx generated documents has too much white space on the top

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 53877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53877=edit
Safari window

here is the view of Safari. That whitespace at the top makes my eye just
focuses on that alone rather than the context of the document.

This is from Safari 16.1 over VNC.

[Bug other/107621] spinx generated documents has too much white space on the top

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Earnshaw from comment #1)
> I don't see that when using Firefox, so perhaps it is a browser issue.

I see it both with Chrome and Firefox and Microsoft Edge. All on Windows.
Even on Linux with FireFox, there is big whitespace at the top for me too.
Safari too.

On Chrome, I use a zoom level of 150% because otherwise the text is unreadable
for my eyes. It gets worse at different zoom levels.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #11 from Sergey Fedorov  ---
(In reply to Andrew Pinski from comment #8)
> No preprocessed source of the code going wrong.
> Not even register state or instructions where the segfault is happening
> (this is would be very useful but not required).

I am on 10.6 PPC (10A190) now and cannot reboot into 10.5.8, so attaching .ii
file from there, but the failure happens on Leopard just as well.

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #10 from Sergey Fedorov  ---
Created attachment 53876
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53876=edit
Preprocessed spinlock_test from 10.6

36-172% /opt/local/bin/g++-mp-11 --save-temps -v spinlock_test.cpp
-I/opt/local/libexec/boost/1.79/include -L/opt/local/libexec/boost/1.79/lib -o
spinlock_test
Using built-in specs.
COLLECT_GCC=/opt/local/bin/g++-mp-11
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/ppc-apple-darwin10/11.3.0/lto-wrapper
Target: ppc-apple-darwin10
Configured with:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc11/gcc11/work/gcc-11.3.0/configure
--prefix=/opt/local --build=ppc-apple-darwin10
--enable-languages=c,c++,objc,obj-c++,lto,fortran,jit
--libdir=/opt/local/lib/gcc11 --includedir=/opt/local/include/gcc11
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-11 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-11
--with-gxx-include-dir=/opt/local/include/gcc11/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--with-zstd=/opt/local --enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-bugurl=https://trac.macports.org/newticket --enable-host-shared
--with-tune-cpu=G5 --disable-tls --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-pkgversion='MacPorts gcc11 11.3.0_1'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (MacPorts gcc11 11.3.0_1) 
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-I'
'/opt/local/libexec/boost/1.79/include' '-L/opt/local/libexec/boost/1.79/lib'
'-o' 'spinlock_test' '-mmacosx-version-min=10.6.0'
'-asm_macosx_version_min=10.6' '-nodefaultexport' '-shared-libgcc'
 /opt/local/libexec/gcc/ppc-apple-darwin10/11.3.0/cc1plus -E -quiet -v -I
/opt/local/libexec/boost/1.79/include -D__DYNAMIC__ spinlock_test.cpp -fPIC
-mmacosx-version-min=10.6.0 -fpch-preprocess -o spinlock_test.ii
ignoring nonexistent directory
"/opt/local/lib/gcc11/gcc/ppc-apple-darwin10/11.3.0/../../../../../ppc-apple-darwin10/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/boost/1.79/include
 /opt/local/include/gcc11/c++/
 /opt/local/include/gcc11/c++//ppc-apple-darwin10
 /opt/local/include/gcc11/c++//backward
 /opt/local/lib/gcc11/gcc/ppc-apple-darwin10/11.3.0/include
 /opt/local/include
 /opt/local/lib/gcc11/gcc/ppc-apple-darwin10/11.3.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-I'
'/opt/local/libexec/boost/1.79/include' '-L/opt/local/libexec/boost/1.79/lib'
'-o' 'spinlock_test' '-mmacosx-version-min=10.6.0'
'-asm_macosx_version_min=10.6' '-nodefaultexport' '-shared-libgcc'
 /opt/local/libexec/gcc/ppc-apple-darwin10/11.3.0/cc1plus -fpreprocessed
spinlock_test.ii -fPIC -quiet -dumpbase spinlock_test.cpp -dumpbase-ext .cpp
-mmacosx-version-min=10.6.0 -version -o spinlock_test.s
GNU C++17 (MacPorts gcc11 11.3.0_1) version 11.3.0 (ppc-apple-darwin10)
compiled by GNU C version 11.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (MacPorts gcc11 11.3.0_1) version 11.3.0 (ppc-apple-darwin10)
compiled by GNU C version 11.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bb9117971f7aa7e0fe2b40679b3b256c
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-I'
'/opt/local/libexec/boost/1.79/include' '-L/opt/local/libexec/boost/1.79/lib'
'-o' 'spinlock_test' '-mmacosx-version-min=10.6.0'  '-nodefaultexport'
'-shared-libgcc'
 /opt/local/bin/as -v -I /opt/local/libexec/boost/1.79/include -arch ppc -o
spinlock_test.o spinlock_test.s
Apple Inc version cctools-localbuild, GNU assembler version 1.38
COMPILER_PATH=/opt/local/libexec/gcc/ppc-apple-darwin10/11.3.0/:/opt/local/libexec/gcc/ppc-apple-darwin10/11.3.0/:/opt/local/libexec/gcc/ppc-apple-darwin10/:/opt/local/lib/gcc11/gcc/ppc-apple-darwin10/11.3.0/:/opt/local/lib/gcc11/gcc/ppc-apple-darwin10/
LIBRARY_PATH=/opt/local/lib/gcc11/gcc/ppc-apple-darwin10/11.3.0/:/opt/local/lib/gcc11/gcc/ppc-apple-darwin10/11.3.0/../../../
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-I'
'/opt/local/libexec/boost/1.79/include' '-L/opt/local/libexec/boost/1.79/lib'
'-o' 'spinlock_test' '-mmacosx-version-min=10.6.0'  '-nodefaultexport'
'-shared-libgcc' '-dumpdir' 'spinlock_test.'
 /opt/local/libexec/gcc/ppc-apple-darwin10/11.3.0/collect2 -dynamic -arch ppc
-macosx_version_min 10.6.0 -o spinlock_test -lcrt1.10.5.o
-L/opt/local/libexec/boost/1.79/lib
-L/opt/local/lib/gcc11/gcc/ppc-apple-darwin10/11.3.0

[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> With -fnon-call-exceptions we are a bit more careful (but the above is gone
> in the gimplifier still).

For -fnon-call-exceptions, you need -fno-delete-dead-exceptions (it looks like
the gimplifier is broken there).
That is for:
```
float foo(void)
{
  float t;
  t =  __FLT_MAX__ + __FLT_MAX__;
  return 1;
}
```
To keep around the addition, you need both -fnon-call-exceptions and
-fno-delete-dead-exceptions .
I know there has been issues with where we still DCE code with
-fno-delete-dead-exceptions (I fixed one last year).

[Bug other/107621] spinx generated documents has too much white space on the top

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

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

--- Comment #1 from Richard Earnshaw  ---
I don't see that when using Firefox, so perhaps it is a browser issue.

[Bug other/107621] New: spinx generated documents has too much white space on the top

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

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

Bug ID: 107621
   Summary: spinx generated documents has too much white space on
the top
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53875=edit
picture of the white space

See the attached picture.
For me there is a lot of unused white space on the top of the generated HTML. 
This white space is useless and it gets in the way.

[Bug web/65699] online docs lacks version that it documents

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
This is fixed with the move over to spinx.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #32 from Aldy Hernandez  ---
(In reply to Jakub Jelinek from comment #31)
> Created attachment 53873 [details]
> gcc13-pr107569-div.patch
> 
> This is what I meant by complete nightmare - division.

Ugh, yeah.  That's pretty bad.  (Not your code, the inevitable special casing.)

Could you abstract out functionality into short inline functions to make it
more readable?  If it's too much hassle, or doesn't improve readability then
don't... after all, it's all compartmentalized in a function in
range-ops..which is the whole points of range-ops, being able to sand box all
this knowledge.

Out of curiosity, why is it so much more complex than the integer versions
which share a lot of code?

[Bug middle-end/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"

[yann at droneaud dot fr via Gcc-bugs]

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

--- Comment #2 from Yann Droneaud  ---
I was wondering what GCC expects __builtin_object_size(0, 0) to be, and used
the following:

void a_1 (void) __attribute__((__warning__("-1")));
void a0 (void) __attribute__((__warning__("0")));
void a1 (void) __attribute__((__warning__("1")));
void a2 (void) __attribute__((__warning__("2")));
void a3 (void) __attribute__((__warning__("3")));
void a4 (void) __attribute__((__warning__("4")));

int main(void) {
  unsigned long b = __builtin_object_size(0, 0);
  if (__builtin_expect(b == (unsigned long)-1, 0))
a_1();
  if (__builtin_expect(b == 0, 0))
a0();
  if (__builtin_expect(b == 1, 0))
a1();
  if (__builtin_expect(b == 2, 0))
a2();
  if (__builtin_expect(b == 3, 0))
a3();
  if (__builtin_expect(b == 4, 0))
a4();
}

It works as expected for any level above 0, except -Og:

$ gcc -O1 -S warning.c
warning.c: In function ‘main’:
warning.c:11:5: warning: call to ‘a_1’ declared with attribute warning: -1
[-Wattribute-warning]
   11 | a_1();
  | ^

It's quite reassuring that __builtin_object_size(0, 0) returns -1, hence the
emitted call to a_1():

$ cat warning.s
.file"warning.c"
.text
.globlmain
.typemain, @function
main:
endbr64
subq$8, %rsp
calla_1@PLT
movl$0, %eax
addq$8, %rsp
ret

For -Og, there's a firework of warnings (shockingly they're the same than -O0
level):

$ gcc -Og -S warning.c
warning.c: In function ‘main’:
warning.c:11:5: warning: call to ‘a_1’ declared with attribute warning: -1
[-Wattribute-warning]
   11 | a_1();
  | ^
warning.c:13:5: warning: call to ‘a0’ declared with attribute warning: 0
[-Wattribute-warning]
   13 | a0();
  | ^~~~
warning.c:15:5: warning: call to ‘a1’ declared with attribute warning: 1
[-Wattribute-warning]
   15 | a1();
  | ^~~~
warning.c:17:5: warning: call to ‘a2’ declared with attribute warning: 2
[-Wattribute-warning]
   17 | a2();
  | ^~~~
warning.c:19:5: warning: call to ‘a3’ declared with attribute warning: 3
[-Wattribute-warning]
   19 | a3();
  | ^~~~
warning.c:21:5: warning: call to ‘a4’ declared with attribute warning: 4
[-Wattribute-warning]
   21 | a4();
  | ^~~~

Generated assembly for -Og is the same than for levels above 0: a call to a_1()
function is emitted, which mean GCC, at some point, knows
__builtin_object_size(0, 0) is -1 here. Thus most of the warnings are not very
useful.

$ cat warning.s
.file"warning.c"
.text
.globlmain
.typemain, @function
main:
endbr64
subq$8, %rsp
calla_1@PLT
movl$0, %eax
addq$8, %rsp
ret

[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars

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

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

Stam Markianos-Wright  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |stammark at gcc dot 
gnu.org
 CC||stammark at gcc dot gnu.org
   Last reconfirmed||2022-11-10
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Stam Markianos-Wright  ---
Also confirmed on trunk and assigning to myself, because I believe I've found a
fix: 
```
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index 2d213e12304..ce20a6fcd24 100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -35582,6 +35582,9 @@ enum {
short: __ARM_mve_type_int_n, \
int: __ARM_mve_type_int_n, \
long: __ARM_mve_type_int_n, \
+   _Float16: __ARM_mve_type_fp_n, \
+   __fp16: __ARM_mve_type_fp_n, \
+   float: __ARM_mve_type_fp_n, \
double: __ARM_mve_type_fp_n, \
long long: __ARM_mve_type_int_n, \
unsigned char: __ARM_mve_type_int_n, \
```

Still untested, though, and I'll likely send it to the mailing list within the
next week or two (we've got a couple more arm_mve.h changes in the pipeline, so
I'll test them all together).

[Bug target/107606] rs6000: Option not to use parameter save area in variadic function implementations

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-11-10

--- Comment #3 from Segher Boessenkool  ---
(In reply to Florian Weimer from comment #2)
> (In reply to Segher Boessenkool from comment #1)
> > Or what else is the intention?  Do you have an example of something that was
> > hard to debug, maybe?
> 
> The prctl(2) manual page documents the prctl function as:
> 
>int prctl(int option, unsigned long arg2, unsigned long arg3,
>  unsigned long arg4, unsigned long arg5);

And it also says you have to include  to use this, and that
header has a correct declaration.  Could be worse ;-)

> But if you use this prototype to call prctl

You are never supposed to do that, you always should use the header file.
But people cut corners (which then ends up as being way more wasted work) :-(

> The prototype in  matches this definition. We use to have an
> assembler implementation that did not clobber the caller stack even if
> called as a non-variadic function. But that got replaced in glibc 2.32,
> breaking some programs. We had similar portability issues with open/openat.

Ah, thanks for the background!

> Technically these things are all undefined, and the glibc headers and
> implementations are consistent.

And there is no standard that describe prctl(), which would be the last thing
justifying declaring it manually (like abort() is often declared manually
for example.  Bad practice really, but not wrong).

> Users can even declare their own matching
> (variadic) prototypes, as required by POSIX for such functions. On the other
> hand, the prctl prototype is misdocumented, so it's easy to get that wrong,
> and the variadic nature of open/openat is not that widely realized, either.

That is misdocumented as well, yes.

> Basically this is an avoidable portability trap for powerpc64le-linux-gnu,
> and maybe we can make life for programmers a bit easier.

Many PowerPC ABIs, not just 64-bit even -- and probably many other archs
will have the same problem even.  But it is more tractable to detect this
for rs6000 only, yup.

Confirmed.

Business Inquiry

[Mashhood Ali via Gcc-bugs]

Hello Admin
I hope you are doing well
I am Mashood Ali, a web developer

The domain name (*g95.org *) has expired and going to be
deleted soon. I want to buy this domain name from you so that I can make a
programming website out of it.

 If you agree with my offer, kindly reply to my mail with your price

Thanks

[Bug middle-end/107618] Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"

[yann at droneaud dot fr via Gcc-bugs]

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

Yann Droneaud  changed:

   What|Removed |Added

 CC||yann at droneaud dot fr

--- Comment #1 from Yann Droneaud  ---
A smallest reproducer (generated with some help from C-reduce):

void a(void) __attribute__((__warning__("")));
int main(void) {
  unsigned long b = __builtin_object_size(0, 0);
  if (__builtin_expect(b < 1, 0))
a();
}

Works at all level above -00, except -Og:

$ gcc -Og warning.c
warning.c: In function ‘main’:
warning.c:5:5: warning: call to ‘a’ declared with attribute warning: 
[-Wattribute-warning]
5 | a();
  | ^~~

[Bug target/107590] __atomic_test_and_set broken on PowerPC

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Peter Dimov  ---
The easiest way to reproduce the issue is with the following test:

https://github.com/boostorg/smart_ptr/blob/c577d68b0272fd0bddc88ea60a8db07219391589/test/spinlock_test.cpp

This crashes because - presumably - sp2 is on an odd address.

The definition of the spinlock class is here:

https://github.com/boostorg/smart_ptr/blob/c577d68b0272fd0bddc88ea60a8db07219391589/include/boost/smart_ptr/detail/spinlock_gcc_atomic.hpp

[Bug target/107590] __atomic_test_and_set broken on PowerPC

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Peter Dimov from comment #7) 
> I don't see an alignment requirement being mentioned here.

I think you misunderstood the alignment issue. There might be no alignment
requirement directly on __atomic_test_and_set but if there is a mismatch
understanding of alignment of what GCC thinks the alignment of the address
should be and what the address really is, then there will be an issue. now that
could be still a GCC bug or it can be a bug in the source; usually
suballocators providing wrong aligned addresses.


But there is not enough information here to figure out what exactly is going
wrong.
No preprocessed source of the code going wrong.
Not even register state or instructions where the segfault is happening (this
is would be very useful but not required).

[Bug c++/107615] Segfault on accessing to methods of optional class through member pointer

[socurahlem at yandex dot ru via Gcc-bugs]

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

--- Comment #3 from Danil Kolotushkin  ---
Oh, sorry!
Pointers to the members are a bit confusing for me. Interestingly, previous
versions of gcc and clang work fine in that case. I added more fields to the
object, and it seems that they are by default pointing to the first member
which has this type. With the first type different (for example integer) clang
works fine, but doesn't print anything and gcc exits with segfault. Quite
interesting.

Thank you very much for your answer, Andrew! :)

[Bug other/107620] New: Build errors when using sphinx

[vvinayag at arm dot com via Gcc-bugs]

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

Bug ID: 107620
   Summary: Build errors when using sphinx
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vvinayag at arm dot com
  Target Milestone: ---

I am noticing errors with use of sphinx when building:
Build machine: x86_64-none-linux-gnu
Host: x86_64-none-linux-gnu
Target: aarch64-none-elf or arm-none-eabi


SPHINXBUILD=

make[2]: Entering directory '/.../src/gcc/doc'

b "html" -d
/.../build-aarch64_be-none-elf/obj/gcc2/gcc/doc/fortran/html/doctrees  -j auto
-q  /.../src/gcc/gcc/fortran/doc/gfortran
"/.../build-aarch64_be-none-elf/obj/gcc2/gcc/doc/fortran/html/html"

/bin/sh: b: command not found

make[2]: [Makefile:96: html] Error 127 (ignored)

make[2]: Leaving directory '/.../src/gcc/doc'

test -z "/.../build-aarch64_be-none-elf/install/share/doc/" || /bin/sh
/.../src/gcc/gcc/../mkinstalldirs
"/.../build-aarch64_be-none-elf/install/share/doc/"

 /usr/bin/install -C -m 644 '/.../src/gcc/gcc/doc/fortran/html/html/index.html'
'/.../build-aarch64_be-none-elf/install/share/doc//index.html'

/usr/bin/install: cannot stat
‘/.../src/gcc/gcc/doc/fortran/html/html/index.html’: No such file or directory


Is the above error due to not installing sphinx 5.3.0?
I assumed installing sphinx 5.3.0 would help, but after installing sphinx
5.3.0, I get a different error:

Extension error:
Could not import extension gcc_sphinx (exception: No module named 'gcc_sphinx')
Makefile:84: recipe for target 'info' failed

[Bug target/107606] rs6000: Option not to use parameter save area in variadic function implementations

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

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

--- Comment #2 from Florian Weimer  ---
(In reply to Segher Boessenkool from comment #1)
> Or what else is the intention?  Do you have an example of something that was
> hard to debug, maybe?

The prctl(2) manual page documents the prctl function as:

   int prctl(int option, unsigned long arg2, unsigned long arg3,
 unsigned long arg4, unsigned long arg5);



But if you use this prototype to call prctl (potentially through a function
pointer), then the glibc implementation will corrupt the stack in the caller
because it is defined as:

int
prctl (int option, ...)
{
…
}

The prototype in  matches this definition. We use to have an
assembler implementation that did not clobber the caller stack even if called
as a non-variadic function. But that got replaced in glibc 2.32, breaking some
programs. We had similar portability issues with open/openat.

Technically these things are all undefined, and the glibc headers and
implementations are consistent. Users can even declare their own matching
(variadic) prototypes, as required by POSIX for such functions. On the other
hand, the prctl prototype is misdocumented, so it's easy to get that wrong, and
the variadic nature of open/openat is not that widely realized, either.
Basically this is an avoidable portability trap for powerpc64le-linux-gnu, and
maybe we can make life for programmers a bit easier.

[Bug c++/107615] Segfault on accessing to methods of optional class through member pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
With -W -Wall I get
: In function 'int main()':
:17:39: warning: 'aStr' is used uninitialized [-Wuninitialized]
   17 | std::cout << (aClass->*aStr).value() << std::endl;;
  |  ~^~
:14:15: note: 'aStr' was declared here
   14 | A::member aStr;
  |   ^~~~

The code is undefined because of the uninitialized variable.

Once you initialize it, the code works as expected:
A::member aStr = ::str;

[Bug c++/107615] Segfault on accessing to methods of optional class through member pointer

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 53874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53874=edit
testcase

Next time please attach the testcase instead of just linking to godbolt.

[Bug sanitizer/107619] False positive of -fsanitize=null

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
After you overflow the buffer, all bets are off.  It can but doesn't have to
overwrite unrelated variables around, and which exact depends on the
optimization flags, architecture and how exactly the compiler decides to lay
stuff out.
User -fsanitize=address to detect such buffer overflows, fix them and then
ubsan behavior will be sane.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #31 from Jakub Jelinek  ---
Created attachment 53873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53873=edit
gcc13-pr107569-div.patch

This is what I meant by complete nightmare - division.

[Bug sanitizer/107619] New: False positive of -fsanitize=null

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 107619
   Summary: False positive of -fsanitize=null
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

`gcc-tk -O0 -fsanitize=null` reports a null pointer dereference in `c[0] = *a`,
which I think should not although there is a buffer-overflow in the memcpy.

Interestingly, if you uncomment `int* e[1]`, no error will be warned and the
program exits normally.

Compiler explorer: https://godbolt.org/z/bKhnKhe7d


% gcc-tk -O0 -fsanitize=null a.c && ./a.out
a.c:11:12: runtime error: load of null pointer of type 'int'
Segmentation fault
% 
% cat a.c
int main() {
int* a;
// int* e[1];
int b[1];
int c[3];
a = b;
for (int i = 0; i < 3; i++) {
c[i] = 0;
}
__builtin_memcpy(a, c, 3 * sizeof(int));
c[0] = *a;
return 0;
}
%

[Bug target/107604] FAIL: gcc.target/aarch64/aapcs64/test_dfp_17.c execution, -O0 fails on aarch64_be

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

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

Christophe Lyon  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||clyon at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |clyon at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-11-10

--- Comment #1 from Christophe Lyon  ---
Sorry for the breakage, I'll have a look.

[Bug other/107618] New: Incorrect diagnostics when using -Og, builtin_expect(), and function attribute "warning" or "error"

[yann at droneaud dot fr via Gcc-bugs]

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

Bug ID: 107618
   Summary: Incorrect diagnostics when using -Og,
builtin_expect(), and function attribute "warning" or
"error"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at droneaud dot fr
  Target Milestone: ---

Created attachment 53872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53872=edit
reproducer for -Og, __builtin_expect(), and function
__attribute__((warning("")))

The code below compiled with -Og triggers a warning message that is not
mandated:

$ gcc -Og  warning.c
warning.c: In function ‘test_expect’:
warning.c:26:17: warning: call to ‘size_mismatch_expect’ declared with
attribute warning: size mismatch (builtin_expect) [-Wattribute-warning]
   26 | size_mismatch_expect();
  | ^~


$ cat warning.c
#include 
#include 
#include 

extern void size_mismatch_nonexpect(void)
__attribute__((__warning__("size mismatch")));

static bool
test_nonexpect(const void *addr, size_t len)
{
size_t sz = __builtin_object_size(addr, 0);
if (sz != (size_t)-1 && sz < len) {
size_mismatch_nonexpect();
return false;
}

return true;
}

extern void size_mismatch_expect(void)
__attribute__((__warning__("size mismatch (builtin_expect)")));

static bool
test_expect(const void *addr, size_t len)
{
size_t sz = __builtin_object_size(addr, 0);
if (__builtin_expect(sz != (size_t)-1 && sz < len, 0)) {
size_mismatch_expect();
return false;
}

return true;
}

int main(void)
{
int i = 0;

if (!test_nonexpect(, sizeof(i)))
return EXIT_FAILURE;

if (!test_expect(, sizeof(i)))
return EXIT_FAILURE;

return EXIT_SUCCESS;
}

The warning at -Og level is not expected because there's no call to the
size_mismatch_expect() in the generated assembler (for x86-64):

$ head warning.s
.file"warning.c"
.text
.typetest_nonexpect, @function
test_nonexpect:
movl$1, %eax
ret
.sizetest_nonexpect, .-test_nonexpect
.typetest_expect, @function
test_expect:
movl$1, %eax
ret
.sizetest_expect, .-test_expect
.globlmain
.typemain, @function
main:
endbr64
subq$24, %rsp
movq%fs:40, %rax
movq%rax, 8(%rsp)
xorl%eax, %eax
movl$0, 4(%rsp)
leaq4(%rsp), %rdi
movl$4, %esi
calltest_nonexpect
testb%al, %al
jne.L11
movl$1, %eax
.L5:
movq8(%rsp), %rdx
subq%fs:40, %rdx
jne.L12
addq$24, %rsp
ret
.L11:
leaq4(%rsp), %rdi
movl$4, %esi
calltest_expect
testb%al, %al
je.L9
movl$0, %eax
jmp.L5
.L9:
movl$1, %eax
jmp.L5


See also https://godbolt.org/z/KEsaavhvG

Compiling at optimization level s, z, 1, 2, or 3 doesn't produce that warning.
(but compiling with -O0 does produces two warnings, as expected, since calls to
the two functions are emitted).

Having the warning at debug optimization level makes using -Og in some complex
code base challenging for no good reason when __attribute__((error(""))) is
used (or -Werror=attribute-warning).

It should also be noted clang doesn't generate the warning for optimization
level above 0.

[Bug tree-optimization/107523] [13 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu since r13-3628-g6fd485d15c1a2c42

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[13 Regression] wrong code  |[13 Regression] wrong code
   |at -O2 and -O3 on   |at -O2 and -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r13-3628-g6fd485d15c1a2c42
   Last reconfirmed||2022-11-10
 CC||amacleod at redhat dot com,
   ||marxin at gcc dot gnu.org
   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r13-3628-g6fd485d15c1a2c42.

[Bug tree-optimization/107473] Unexpected warning / error with strncpy

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-10
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r10-2814-g22fca489eaf98f26.

[Bug web/107610] Broken 'onlinedocs' after "Porting the Docs to Sphinx"

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

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

--- Comment #4 from Georg-Johann Lay  ---
Also affected are other bits of the web page that are auto-generated, like

https://gcc.gnu.org/install/configure.html

And with the new URLs, "deep" links like

https://gcc.gnu.org/install/configuration.html#avr

ceased to work, too, even though the old ./gcc/doc/install.texi generated
(working) anchors like:

@html

@end html
@item --with-avrlibc

So the porting-to-sphinx dropped them, which is really sad.

[Bug target/107606] rs6000: Option not to use parameter save area in variadic function implementations

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

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

--- Comment #1 from Segher Boessenkool  ---
Hi Florian,

What do you want such an option to do?  The PSA is used only when it is needed,
do you want to have the compiler error out in such cases?  This is very
unpredictable to the user, so it should be clearly marked as just a debug aid
(in documentation and such).

Or what else is the intention?  Do you have an example of something that was
hard to debug, maybe?

[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||fxue at gcc dot gnu.org

--- Comment #11 from Richard Biener  ---
So with the last patch I have we eliminate the empty loop that's created by
threading but the result is still (or now "again") the imperfect result
mentioned in the original description - we fail to exit the outer loop.

The main thing the patches in this series did is restore the threading
that did the inner loop optimization and the required cleanup.  I don't
think that this particular thread itself can be enhanced to cover exiting
the outer loop.  In particular we ask to thread across the loop exit but
we know nothing about that apart from the code in the remaining iterations
having no side-effect.

I'm not sure which kind of pass/transform would be suited to cover this
in a more general way than jump threading does.  We do have loop splitting
which handles this as part of splitting on a "semi-invariant" condition
but that fails quite early because it's

   if (running)
 {
   if (other)
 running = 0;
 }

and we don't seem to handle the conditional "semi-invariant" condition
case.

[Bug middle-end/107617] SCC-VN with len_store and big endian

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

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

--- Comment #1 from rdapp at gcc dot gnu.org ---
For completeness, the mailing list thread is here:

https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602252.html

[Bug middle-end/107617] SCC-VN with len_store and big endian

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

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

rdapp at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c++/107616] c++tools: select not found breaks build

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

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

--- Comment #1 from John David Anglin  ---
Created attachment 53870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53870=edit
Patch

Fix build of server.cc when select is not present.

[Bug middle-end/107617] New: SCC-VN with len_store and big endian

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

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

Bug ID: 107617
   Summary: SCC-VN with len_store and big endian
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rdapp at gcc dot gnu.org
CC: richard.guenther at gmail dot com
  Target Milestone: ---
Target: s

Created attachment 53871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53871=edit
s390 patch for len_load/len_store

Hi,

Richard and I already quickly discussed this on the mailing list but I didn't
manage to progress analyzing as I was tied up with other things.  Figured I
open a bug for tracking purposes and the possibility to maybe fix it in a later
stage.

I'm evaluating len_load/len_store support on s390 via the attached patch and
seeing a FAIL in

testsuite/gfortran.dg/power_3.f90

built with -march=z16 -O3 --param vect-partial-vector-usage=1

The problem seems to be that we evaluate a vector constant
{-1, 1, -1, 1} loaded with length 11 + 1(bias) = 12 as
{1, -1, 1} instead of {-1, 1, -1}.

Richard wrote on the mailing list:
> The error is probably in vn_reference_lookup_3 which assumes that
> 'len' applies to the vector elements in element order.  See the part
> of the code where it checks for internal_store_fn_p.  If 'len' is with
> respect to the memory and thus endianess has to be taken into
> account then for the IFN_LEN_STORE
> 
> else if (fn == IFN_LEN_STORE)
>   {
> pd.rhs_off = 0;
> pd.offset = offset2i;
> pd.size = (tree_to_uhwi (len)
>+ -tree_to_shwi (bias)) * BITS_PER_UNIT;
> if (ranges_known_overlap_p (offset, maxsize,
> pd.offset, pd.size))
>   return data->push_partial_def (pd, set, set,
>  offseti, maxsizei);
> 
> likely needs to adjust rhs_off from zero for big endian?

[Bug c++/107616] New: c++tools: select not found breaks build

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

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

Bug ID: 107616
   Summary: c++tools: select not found breaks build
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

On hpux11.[0-2]*, the select declaration reside in .  configure
only checks .  As a result, select is not found:

configure:3623: checking for select
configure:3642:  /home/dave/gnu/gcc/objdir64/./gcc/xg++
-B/home/dave/gnu/gcc/objdir64/./gcc/ -nostdinc++ -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-13/hppa64-hp-hpux11.11/sys-include   -fchecking=1 -c -g -O2 
  conftest.cpp >&5
conftest.cpp:24:10: fatal error: sys/select.h: No such file or directory
   24 | #include 
  |  ^~
compilation terminated.
...
configure:3649: result: no

This exposes a problem in server.cc.  The call to FD_ISSET at line 724
is not conditional on "#if defined (HAVE_PSELECT) || defined (HAVE_SELECT)".

[Bug c++/107615] New: Segfault on accessing to methods of optional class through member pointer

[socurahlem at yandex dot ru via Gcc-bugs]

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

Bug ID: 107615
   Summary: Segfault on accessing to methods of optional class
through member pointer
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: socurahlem at yandex dot ru
  Target Milestone: ---

Example link: https://godbolt.org/z/K7bqeh9sG

If we access methods of optional class through pointer to member, the program
exited with segfault. I tried the example with previous versions of gcc and got
correct result. With clang the same

[Bug driver/107448] GCC no longer diagnoses missing input file with -MG since r11-6855-g4804de453e7f5f90

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-10
 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|GCC no longer diagnoses |GCC no longer diagnoses
   |missing input file with -MG |missing input file with -MG
   ||since
   ||r11-6855-g4804de453e7f5f90
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Likely started with r11-6855-g4804de453e7f5f90.

[Bug other/107614] build goes through but make install fails

[felix-gcc at fefe dot de via Gcc-bugs]

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

felix-gcc at fefe dot de changed:

   What|Removed |Added

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

--- Comment #1 from felix-gcc at fefe dot de ---
oops sorry my build script was at fault.

[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-3879-gf1b76811f2c3773e8cabcc07932bf13e82e264db
Author: Richard Biener 
Date:   Thu Nov 10 15:02:37 2022 +0100

better PHI copy propagation for forwprop

We can handle _1 = PHI <_1, _2> as a copy.

PR tree-optimization/84646
* tree-ssa-forwprop.cc (pass_forwprop::execute): Improve
copy propagation across PHIs.

[Bug gcov-profile/107537] gcov skips throw/fallthrough annotations for 'never executed' branches

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-10
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I'm going to take a look.

[Bug lto/107078] LTO is causing that firebird build is core dumping

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|WAITING |ASSIGNED

--- Comment #13 from Martin Liška  ---
I can take a look in this stage3 phase.

[Bug other/107614] New: build goes through but make install fails

[felix-gcc at fefe dot de via Gcc-bugs]

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

Bug ID: 107614
   Summary: build goes through but make install fails
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

I'm trying to build the current gcc git and install it to /opt/gcc so it
doesn't clash with the system gcc.

This is on x86_64 Linux. The build goes through but make install fails in
x86_64-pc-linux-gnu/libsanitizer/lsan:

 /usr/bin/mkdir -p '/tmp/fefix/usr/lib64/../lib64'
 /opt/diet/bin/install -c -m 644 liblsan_preinit.o
'/tmp/fefix/usr/lib64/../lib64'
 /usr/bin/mkdir -p '/tmp/fefix/usr/lib64/../lib64'
 /bin/sh ../libtool   --mode=install /opt/diet/bin/install -c   liblsan.la
'/tmp/fefix/usr/lib64/../lib64'
libtool: install: error: cannot install `liblsan.la' to a directory not ending
in /opt/gcc/lib64/../lib64

/tmp/fefix is my $DESTDIR for this make install.

gcc make install is trying to install liblsal to /usr/lib64 but libtool refuses
because that's not under /opt/gcc/lib64 where the rest of gcc goes.

[Bug sanitizer/107586] gcc trunk missed a stack-buffer-overflow

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-11-10
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Liška  ---
The bug can be spotted with -O0 and I noticed it's also not reported with clang
-O2. I can take a look at this later.

[Bug other/107613] sphinx-build is slow for gccint manual

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-11-10

--- Comment #2 from Martin Liška  ---
Upstream issue:
https://github.com/sphinx-doc/sphinx/issues/10966

[Bug other/107613] sphinx-build is slow for gccint manual

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

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

--- Comment #1 from Martin Liška  ---
Without cProfile, it's ~45 seconds.