[Bug other/107665] g++.dg/cpp23/ext-floating1.C fails after r13-3387-g79d38dd46e6b07

2022-11-12 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107665

--- Comment #1 from Andrew Pinski  ---
r13-3387-g79d38dd46e6b07 just made the testcase actually run which it was not
doing previously.

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

2022-11-12 Thread xry111 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608

--- Comment #5 from Xi Ruoyao  ---
After r13-3924 this brings PR95115 back.  Note that Glibc has added an ugly
hack for RISC-V and old compilers, but other ports may be haunted as well.

[Bug other/107665] New: [13 regression] g++.dg/cpp23/ext-floating1.C fails after r13-3387-g79d38dd46e6b07

2022-11-12 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107665

Bug ID: 107665
   Summary: [13 regression] g++.dg/cpp23/ext-floating1.C fails
after r13-3387-g79d38dd46e6b07
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Tried g:79d38dd46e6b07e5a90ab25df1438eb0918eb475, r13-3387-g79d38dd46e6b07
make  -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/cpp23/ext-floating1.C"
FAIL: g++.dg/cpp23/ext-floating1.C  -std=gnu++23 (test for excess errors)
# of unexpected failures1

This is failing on powerpc64 when the compiler is built with 
--with-long-double-format=ieee.

Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp23/ext-floating1.C:27:54:
error: static assertion failed
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp23/ext-floating1.C:28:54:
error: static assertion failed
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp23/ext-floating1.C:29:61:
error: static assertion failed
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp23/ext-floating1.C:30:61:
error: static assertion failed


The failures are here:

#ifdef __SIZEOF_FLOAT128__
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
static_assert (is_same::value);
#endif


commit 79d38dd46e6b07e5a90ab25df1438eb0918eb475 (HEAD)
Author: Jakub Jelinek 
Date:   Wed Oct 19 18:55:46 2022 +0200

testsuite: Default make check-g++ vs. tests for newest C++ standard

[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.

2022-11-12 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167

--- Comment #1 from Jonathan Wakely  ---
Clocks are done in r13-3937-g1736bf5a61c736

Time zones and chrono I/O still missing.

[Bug libstdc++/104166] Implement C++20 std::format

2022-11-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104166

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

https://gcc.gnu.org/g:1d9454aba615eadd0d85c93713dd848227345f67

commit r13-3936-g1d9454aba615eadd0d85c93713dd848227345f67
Author: Jonathan Wakely 
Date:   Tue Oct 18 21:20:06 2022 +0100

libstdc++: Implement C++20  [PR104166]

This doesn't add the newer C++23 features like formatting ranges
and escaped string prsentation types.

However, C++23 extended floating-point types are supported, as are
128-bit integers.

It could do with more tests.

libstdc++-v3/ChangeLog:

PR libstdc++/104166
* include/Makefile.am (std_headers): Add .
* include/Makefile.in: Regenerate.
* include/precompiled/stdc++.h: Add .
* include/std/format: New file.
* python/libstdcxx/v6/printers.py (StdFormatArgsPrinter): New
printer for std::format_args.
* testsuite/std/format/arguments/args.cc: New test.
* testsuite/std/format/error.cc: New test.
* testsuite/std/format/formatter.cc: New test.
* testsuite/std/format/functions/format.cc: New test.
* testsuite/std/format/functions/format_to_n.cc: New test.
* testsuite/std/format/functions/size.cc: New test.
* testsuite/std/format/functions/vformat_to.cc: New test.
* testsuite/std/format/parse_ctx.cc: New test.
* testsuite/std/format/string.cc: New test.
* testsuite/std/format/string_neg.cc: New test.

[Bug web/107664] Vector Extensions page down

2022-11-12 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107664

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> It moved
> https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/using-
> vector-instructions-through-built-in-functions.html .

Note it might move again because the names of the pages for the trunk will be
changing.

[Bug web/107664] Vector Extensions page down

2022-11-12 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107664

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
It moved
https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/using-vector-instructions-through-built-in-functions.html
.

[Bug web/107664] New: Vector Extensions page down

2022-11-12 Thread unlvsur at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107664

Bug ID: 107664
   Summary: Vector Extensions page down
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html

[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation

2022-11-12 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661

--- Comment #4 from Sergei Trofimovich  ---
If I read a.cc.254t.optimized correctly I think there are two unrelated places
that are expected to generate `getWaitStatesSince6.constprop`:
- one is through main()
- another is through seemingly_unused_foo()

They have slightly different parameters, but gcc uses seemingly_unused_foo()'s
one in main()'s path and as a result calls code from normally unreachable
lambda.

[Bug c/107663] New: GCC does not catch -Werror=maybe-uninitialized that looks apparent

2022-11-12 Thread ercli at ucdavis dot edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107663

Bug ID: 107663
   Summary: GCC does not catch -Werror=maybe-uninitialized that
looks apparent
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ercli at ucdavis dot edu
  Target Milestone: ---

Created attachment 53890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53890=edit
a.i - the preprocessed file that triggers the bug

When compiling the following function, GCC with -Wall gives no warnings.
However, it looks clear to me that line 14 uses uninitialized variable declared
in line 13.

void func(int *p)
{
 if (f_a()) {
  int v;  /* line 13 */
  *p = v; /* line 14 */
  f_b();
 }
}

GCC does not output anything in stdout and stderr. I think this is a false
negative: GCC fails to detect uninitialized use of variable. Expected warning
message looks like:

b.c: In function 'func':
b.c:8:20: error: 'v' is used uninitialized [-Werror=uninitialized]
8 | *p = v;
  | ~~~^~~
b.c:7:21: note: 'v' declared here
7 | int v;
  | ^
cc1: all warnings being treated as errors

To reproduce this bug, use the file "a.i" attached with this bug. The compile
command is "gcc -c -Wall -Werror a.i".

My system information can be retrieved below (output of "gcc -v -save-temps
-Wall -Werror -c a.c"):

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

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 12.2.1 20220819 (Red Hat 12.2.1-2) (x86_64-redhat-linux)
compiled by GNU C version 12.2.1 20220819 (Red Hat 12.2.1-2), GMP
version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 816b60f1f61bd59efac4d324ea795f15
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Werror' '-c' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o a.o a.s
GNU assembler version 2.37 (x86_64-redhat-linux) using BFD version version
2.37-36.fc36
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/12/:/usr/libexec/gcc/x86_64-redhat-linux/12/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/12/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/12/:/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/12/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Werror' '-c' '-mtune=generic'
'-march=x86-64'

[Bug libstdc++/107636] [13 regression] r13-3761-ga239a63f868e29 breaks build on powerpc64le with __float128 support

2022-11-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107636

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-3932-gec6c2029714057b4bca344ee59be977d17361092
Author: Jakub Jelinek 
Date:   Sat Nov 12 21:56:47 2022 +0100

libstdc++: Fix up to_chars ppc64le _Float128 overloads [PR107636]

As reported, I've misplaced __extension__ keywords in these cases
(wanted not to have them on the whole inlines because _Float128 is
completely standard now while __float128 is not, but before return
it is a syntax error.
I've verified on a short testcase that both g++ and clang++ accept
__extension__ after return keyword.

2022-11-12  Jakub Jelinek  

PR libstdc++/107636
* include/std/charconv (to_chars): Fix up powerpc64le _Float128
overload __extension__ placement.

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

2022-11-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107444

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:59a63247992eb13153b82c4902aadf111460eac2

commit r13-3931-g59a63247992eb13153b82c4902aadf111460eac2
Author: Harald Anlauf 
Date:   Thu Nov 10 22:30:27 2022 +0100

Fortran: fix treatment of character, value, optional dummy arguments
[PR107444]

Fix handling of character dummy arguments that have the optional+value
attribute.  Change name of internal symbols that carry the hidden presence
status of optional arguments to distinguish them from the internal hidden
character length.  Update documentation to clarify the gfortran ABI.

gcc/fortran/ChangeLog:

PR fortran/107444
* trans-decl.cc (create_function_arglist): Extend presence status
to all intrinsic types, and change prefix of internal symbol to
'.'.
* trans-expr.cc (gfc_conv_expr_present): Align to changes in
create_function_arglist.
(gfc_conv_procedure_call): Fix generation of procedure arguments
for
the case of character dummy arguments with optional+value
attribute.
* trans-types.cc (gfc_get_function_type): Synchronize with changes
to create_function_arglist.
* doc/gfortran/naming-and-argument-passing-conventions.rst: Clarify
the gfortran argument passing conventions with regard to OPTIONAL
dummy arguments of intrinsic type.

gcc/testsuite/ChangeLog:

PR fortran/107444
* gfortran.dg/optional_absent_7.f90: Adjust regex.
* gfortran.dg/optional_absent_8.f90: New test.

[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation

2022-11-12 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661

--- Comment #3 from Sergei Trofimovich  ---
Created attachment 53889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53889=edit
a_simpler.cc

a_simpler.cc is a bit more trimmed down version of a.cc: does not need pragmas
or argument forwarding. Uses only -O1 -fipa-cp -fipa-cp-clone:

$ ./gcc-13-HEAD/bin/gcc -Wall -O1 -fipa-cp -fipa-cp-clone -DDISABLE_HACK
a_simpler.cc -o a && ./a
$ ./gcc-13-HEAD/bin/gcc -Wall -O1 -fipa-cp -fipa-cp-clone a_simpler.cc -o a &&
./a
Illegal instruction (core dumped)

/// 'function_ref' is taken from llvm-12 as is without any modifications.
/// The rest if severely maimed AMDGCN hazard verifier code.

// How to break:
// $ ./gcc-13-snap/bin/gcc -O1 -fipa-cp -fipa-cp-clone   
a_simpler.cc -o a && ./a
// Illegal instruction (core dumped)
// $ ./gcc-13-snap/bin/gcc -O1 -fipa-cp -fipa-cp-clone -DDISABLE_HACK
a_simpler.cc -o a && ./a
// 

// #define DISABLE_HACK 1

#include 

class function_ref {
  void (*callback)(void * callable) = nullptr;
  void * callable;

  template
  static void callback_fn(void * callable) {
(*reinterpret_cast(callable))();
  }

public:
  function_ref() = delete;

  template 
  function_ref(
  Callable &,
  // This is not the copy-constructor.
  std::enable_if_t<
  !std::is_same>,
function_ref>::value> * = nullptr)
  : callback(callback_fn::type>),
callable(reinterpret_cast()) {}

  void operator()(void) const {
callback(callable);
  }
};

static int get_mbb_b(int MBB) { return MBB; }
static int get_mbb_e(int MBB) {
static int n = 0;
switch (n++) {
  case 0: return MBB + 1;
  default: return MBB;
}
}

static void getWaitStatesSince6(int MBB, int I, int WaitStates, function_ref
Expired) {
  Expired();

  if (I) {
WaitStates += 1;
  }

  auto pri = get_mbb_b(MBB);
  auto pre = get_mbb_e(MBB);
  if (pri != pre) {
getWaitStatesSince6(pri, I, WaitStates, Expired);
  }
}

static void getWaitStatesSince3(int MI, function_ref Expired) {
  getWaitStatesSince6(0, MI, 42, Expired);
}

static void always_void(void) { }

int main() {
  getWaitStatesSince3(0, always_void);
}

#if defined(DISABLE_HACK)
#else
void seemingly_unused_foo(int MI) {
  struct L {
void operator()(void) const {
  __builtin_trap();
}
  };
  L IsExpiredFn;

  getWaitStatesSince3(MI, IsExpiredFn);
}
#endif

[Bug c++/107662] New: [10 concepts] ICE using concept with dependent template parameter to define variable

2022-11-12 Thread wjwray at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107662

Bug ID: 107662
   Summary: [10 concepts] ICE using concept with dependent
template parameter to define variable
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/rjMjeG7T1

template 
concept vt = true;

vt auto v = 1;
  | ^~
internal compiler error: in dependent_type_p, at cp/pt.c:26561

There were several similar ICE bugs, mostly resolved fixed.

This case is fixed in 10.4
(my non-reduced code fails on 10.4, then fixed in 11 up).

[Bug other/107620] Build errors when using sphinx

2022-11-12 Thread vvinayag at arm dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620

--- Comment #2 from vvinayag at arm dot com ---
(In reply to Martin Liška from comment #1)
> Confirmed. Btw. what revision do you build and what command do you use?

Could you please clarify what you are referring to, for the revision and
command?

[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation

2022-11-12 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661

--- Comment #2 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #0)
> Reproducing:
> 
> $ ./gcc-13-HEAD/bin/gcc -Wall -O0 a.cc -o a
> $ ./gcc-13-HEAD/bin/gcc -Wall -O3 a.cc -o a
> ./bug_HEAD.bash: line 6: 1309437 Illegal instruction (core dumped) ./a
> $ ./gcc-13-HEAD/bin/gcc -Wall -O0 -DDISABLE_HACK a.cc -o a
> $ ./gcc-13-HEAD/bin/gcc -Wall -O3 -DDISABLE_HACK a.cc -o a

Whoops. Lines miss `&& ./a` execution. The correct reproducer (it's a runtime
crash):

$ ./gcc-13-HEAD/bin/gcc -Wall -O3 a.cc -o a && ./a
Illegal instruction (core dumped)

For comparison the other modes are fine:

# remove seemingly unused code with __builtin_trap from visibility:
$ ./gcc-13-HEAD/bin/gcc -Wall -O3 a.cc -o a -DDISABLE_HACK && ./a


[Bug middle-end/107661] [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation

2022-11-12 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Severity|normal  |blocker

--- Comment #1 from Andrew Pinski  ---
IPA-CP didn't change in 13 as far as I know but lambda mangling did.

[Bug middle-end/107661] New: [13 Regression] lambdas get merged incorrectly in tempaltes, cause llvm-12 miscompilation

2022-11-12 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661

Bug ID: 107661
   Summary: [13 Regression] lambdas get merged incorrectly in
tempaltes, cause llvm-12 miscompilation
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53888
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53888=edit
a.cc

Initially observed the problem on llvm-12's test suite where 4 AMDGCN test
fail:

Failed Tests (4):
  LLVM :: CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.div.fmas.ll
  LLVM :: CodeGen/AMDGPU/atomic_optimizations_pixelshader.ll
  LLVM :: CodeGen/AMDGPU/smem-war-hazard.mir
  LLVM :: CodeGen/AMDGPU/vgpr-descriptor-waterfall-loop-idom-update.ll

Digging deeper it looks liek llvm's class

template class
function_ref ...

gets miscompiled in a very unusual way. I extracted smaller a.cc reproducer.

It looks like as if gcc picked wrong (unused) lambda to inline into actually
used code.

Reproducing:

$ ./gcc-13-HEAD/bin/gcc -Wall -O0 a.cc -o a
$ ./gcc-13-HEAD/bin/gcc -Wall -O3 a.cc -o a
./bug_HEAD.bash: line 6: 1309437 Illegal instruction (core dumped) ./a
$ ./gcc-13-HEAD/bin/gcc -Wall -O0 -DDISABLE_HACK a.cc -o a
$ ./gcc-13-HEAD/bin/gcc -Wall -O3 -DDISABLE_HACK a.cc -o a

$ ./gcc-13-HEAD/bin/gcc -v |& unnix
Using built-in specs.
COLLECT_GCC=/<>/gcc-13.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-13.0.0/libexec/gcc/x86_64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221112 (experimental) (GCC)

Full a.cc example (somewhat long, also attached):

/// 'function_ref' is taken from llvm-12 as is without any modifications.
/// The rest if severely maimed AMDGCN hasard verifier code.

// How to break:
// $ ./gcc-13-snap/bin/gcc -O3a.cc -o a && ./a
// Illegal instruction (core dumped)
// $ ./gcc-13-snap/bin/gcc -O3 -DDISABLE_HACK a.cc -o a && ./a
// 

#pragma GCC optimize "-O1"
#pragma GCC optimize "-fipa-cp"
#pragma GCC optimize "-fipa-cp-clone"

// #define DISABLE_HACK 1

#include 
#include 
#include 
#include 

/// An efficient, type-erasing, non-owning reference to a callable. This is
/// intended for use as the type of a function parameter that is not used
/// after the function in question returns.
///
/// This class does not own the callable, so it is not in general safe to store
/// a function_ref.
template class function_ref;

template
class function_ref {
  Ret (*callback)(intptr_t callable, Params ...params) = nullptr;
  intptr_t callable;

  template
  //__attribute__((noinline, noipa))
  static Ret callback_fn(intptr_t callable, Params ...params) {
return (*reinterpret_cast(callable))(
std::forward(params)...);
  }

public:
  __attribute__((noinline, noipa))
  function_ref() = default;
  __attribute__((noinline, noipa))
  function_ref(std::nullptr_t) {}

  template 
  //__attribute__((noinline, noipa))
  function_ref(
  Callable &,
  // This is not the copy-constructor.
  std::enable_if_t<
  !std::is_same>,
function_ref>::value> * = nullptr,
  // Functor must be callable and return a suitable type.
  std::enable_if_t::value ||
   std::is_convertible()(
   std::declval()...)),
   Ret>::value> * = nullptr)
  : callback(callback_fn::type>),
callable(reinterpret_cast()) {}

  //__attribute__((noinline, noipa))
  Ret operator()(Params ...params) const {
return callback(callable, std::forward(params)...);
  }

  __attribute__((noinline, noipa))
  explicit operator bool() const { return callback; }
};

typedef int OI;
typedef int OBB;

typedef function_ref IsExpiredFnT;
typedef function_ref IsHazardFnT;

__attribute__((noinline, noipa)) OI get_e(
OBB MBB,
OI I) {
static int n = 0;
switch (n++) {
  case 0: return I;
  case 1: return ++I;
  default: return I;
}
}

__attribute__((noinline, noipa))
static OBB get_mbb_b(OBB MBB) {
return MBB;
}

__attribute__((noinline, noipa))
static OBB get_mbb_e(OBB MBB) {
static int n = 0;
switch (n++) {
  case 0: return MBB + 1;
  default: return MBB;
}
}

__attribute__((noinline))
static int getWaitStatesSince6(IsHazardFnT IsHazard, OBB MBB, OI I, int
WaitStates, IsExpiredFnT IsExpired) {

  auto E = get_e(MBB, I);
  if (I != E) {
WaitStates += 2;

if (IsExpired(I, WaitStates))
  return std::numeric_limits::max();
  }

  auto pri = get_mbb_b(MBB);
  auto pre = get_mbb_e(MBB);
  if (pri != pre) {
OBB

[Bug fortran/106576] Finalization of temporaries from functions not occuring

2022-11-12 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #3 from Thomas Koenig  ---
No time to work on this at the moment.

[Bug libstdc++/107649] New std::complex specializations are never used

2022-11-12 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649

--- Comment #4 from Jonathan Wakely  ---
Yes, that looks right.

[Bug c++/107104] semantics of __builtin_constant_p within static_assert and return value

2022-11-12 Thread yann at droneaud dot fr via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104

Yann Droneaud  changed:

   What|Removed |Added

 CC||yann at droneaud dot fr

--- Comment #3 from Yann Droneaud  ---
I'm experiencing the same issue:

#include 

void a(int v)
{
static_assert(__builtin_constant_p(v) && v == -1, "failure");
}

GCC 13 and below complains:

: In function 'a':
:16:43: error: expression in static assertion is not constant
   16 | static_assert(__builtin_constant_p(v) && v == -1, "failure");
  |   ^~
Compiler returned: 1


clang current trunk, eg above 15.0, seems to finally get it right:

:16:5: error: static assertion failed due to requirement
'__builtin_constant_p(v) && v == -1': failure
static_assert(__builtin_constant_p(v) && v == -1, "failure");
^ ~~
/usr/include/assert.h:143:24: note: expanded from macro 'static_assert'
# define static_assert _Static_assert
   ^
1 error generated.
Compiler returned: 1

see https://godbolt.org/z/KKn6xTG8a

[Bug middle-end/107498] Wrong optimization leads to unaligned access when compiling OpenLDAP

2022-11-12 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107498

--- Comment #8 from John Paul Adrian Glaubitz  ---
(In reply to Eric Botcazou from comment #5)
> Can anyone print the value of mp in the debugger?

glaubitz@gcc202:~/openldap/tests$ gdb --args
/home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0 -f
/home/glaubitz/openldap/tests/testrun/slapadd.conf -l
./testdata/test-ordered.ldif
GNU gdb (Debian 12.1-4) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/glaubitz/openldap/servers/slapd/slapd...
(gdb) r
Starting program: /home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0 -f
/home/glaubitz/openldap/tests/testrun/slapadd.conf -l
./testdata/test-ordered.ldif

Program received signal SIGILL, Illegal instruction.
0xfff8000100e44320 in ?? ()
(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
0x010ceda4 in mdb_node_add (mc=0x14327b8, indx=,
key=0x7fee0a0, data=0x7fee090, pgno=0, flags=0) at
./../../../libraries/liblmdb/mdb.c:7366
7366mp->mp_lower += sizeof(indx_t);
(gdb) p mp
$1 = (MDB_page *) 0x1463caa
(gdb)

[Bug libgomp/107641] [13 Regression] libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

2022-11-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug libgomp/107641] [13 Regression] libgomp/env.c:286:20: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

2022-11-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107641

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-3927-g2a193e9df82917eaf440a20f99a3febe91dcb5fe
Author: Jakub Jelinek 
Date:   Sat Nov 12 09:47:50 2022 +0100

libgomp: Fix up build on mingw [PR107641]

Pointers should be first casted to intptr_t/uintptr_t before casting
them to another integral type to avoid warnings.
Furthermore, the function has code like
  else if (upper <= UINT_MAX)
something;
  else
something_else;
so it seems using unsigned type for upper where upper <= UINT_MAX is always
true is not intended.

2022-11-12  Jakub Jelinek  

PR libgomp/107641
* env.c (parse_unsigned_long): Cast params[2] to uintptr_t rather
than
unsigned long.  Change type of upper from unsigned to unsigned
long.

[Bug tree-optimization/107591] range-op{,-float}.cc for x * x

2022-11-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
Author: Jakub Jelinek 
Date:   Sat Nov 12 09:33:01 2022 +0100

range-op: Implement floating point multiplication fold_range [PR107569]

The following patch implements frange multiplication, including the
special case of x * x.  The callers don't tell us that it is x * x,
just that it is either z = x * x or if (x == y) z = x * y;
For irange that makes no difference, but for frange it can mean
x is -0.0 and y is 0.0 if they have the same range that includes both
signed and unsigned zeros, so we need to assume result could be -0.0.

The patch causes one regression:
+FAIL: gcc.dg/fold-overflow-1.c scan-assembler-times 2139095040 2
but that is already tracked in PR107608 and affects not just the newly
added multiplication, but addition and other floating point operations
(and doesn't seem like a ranger bug but dce or whatever else).

2022-11-12  Jakub Jelinek  

PR tree-optimization/107569
PR tree-optimization/107591
* range-op.h (range_operator_float::rv_fold): Add relation_kind
argument.
* range-op-float.cc (range_operator_float::fold_range): Name
last argument trio and pass trio.op1_op2 () as last argument to
rv_fold.
(range_operator_float::rv_fold): Add relation_kind argument.
(foperator_plus::rv_fold, foperator_minus::rv_fold): Likewise.
(foperator_mult): New class.
(floating_op_table::floating_op_table): Use foperator_mult for
MULT_EXPR.

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

2022-11-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569

--- Comment #37 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-3924-g2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb
Author: Jakub Jelinek 
Date:   Sat Nov 12 09:35:16 2022 +0100

range-op: Implement floating point division fold_range [PR107569]

Here is the floating point division fold_range implementation,
as I wrote in the last mail, we could outline some of the common parts
into static methods with descriptive names and share them between
foperator_div and foperator_mult.

Regressions are
+FAIL: gcc.dg/pr95115.c execution test
+FAIL: libphobos.phobos/std/math/hardware.d execution test
+FAIL: libphobos.phobos_shared/std/math/hardware.d execution test
The first test is we have:
  # RANGE [frange] double [] +-NAN
  _3 =  Inf /  Inf;
  if (_3 ord _3)
goto ; [INV]
  else
goto ; [INV]

   :
  abort ();

   :
before evrp, the range is correct, Inf / Inf is known NAN of unknown
sign.  evrp correctly folds _3 ord _3 into false and the
  _3 =  Inf /  Inf;
remains in the IL, but then comes dse1 and removes it as dead
statement.  So, I think yet another example of the PR107608 problems
where DCE? removes dead statements which raise floating point exceptions.
And -fno-delete-dead-exceptions doesn't help.

2022-11-12  Jakub Jelinek  

PR tree-optimization/107569
* range-op-float.cc (foperator_div): New class.
(floating_op_table::floating_op_table): Use foperator_div
for RDIV_EXPR.

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

2022-11-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569

--- Comment #38 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:5747470efa8ff0ac82bb5f53d737b29a44f18118

commit r13-3925-g5747470efa8ff0ac82bb5f53d737b29a44f18118
Author: Jakub Jelinek 
Date:   Sat Nov 12 09:36:59 2022 +0100

range-op: Cleanup floating point multiplication and division fold_range
[PR107569]

Admittedly there are many similar spots with the foperator_div case
(but also with significant differences), so perhaps if foperator_{mult,div}
inherit from some derived class from range_operator_float and that class
would define various smaller helper static? methods, like this
discussed in the PR - contains_zero_p, singleton_nan_p, zero_p,
that
+   bool must_have_signbit_zero = false;
+   bool must_have_signbit_nonzero = false;
+   if (real_isneg (_lb) == real_isneg (_ub)
+   && real_isneg (_lb) == real_isneg (_ub))
+ {
+   if (real_isneg (_lb) == real_isneg (_ub))
+ must_have_signbit_zero = true;
+   else
+ must_have_signbit_nonzero = true;
+ }
returned as -1/0/1 int, and those set result (based on the above value) to
[+INF, +INF], [-INF, -INF] or [-INF, +INF]
or
[+0, +0], [-0, -0] or [-0, +0]
or
[+0, +INF], [-INF, -0] or [-INF, +INF]
and the
+for (int i = 1; i < 4; ++i)
+  {
+   if (real_less ([i], [0])
+   || (real_iszero ([0]) && real_isnegzero ([i])))
+ std::swap (cp[i], cp[0]);
+   if (real_less ([4], [i + 4])
+   || (real_isnegzero ([4]) && real_iszero ([i + 4])))
+ std::swap (cp[i + 4], cp[4]);
+  }
block, it could be smaller and more readable.

2022-11-12  Jakub Jelinek  

PR tree-optimization/107569
* range-op-float.cc (zero_p, contains_p, singleton_inf_p,
signbit_known_p, zero_range, inf_range, zero_to_inf_range): New
functions.
(foperator_mult_div_base): New class.
(foperator_mult, foperator_div): Derive from that and use
protected static method from it as well as above new functions
to simplify the code.

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

2022-11-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569

--- Comment #36 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
Author: Jakub Jelinek 
Date:   Sat Nov 12 09:33:01 2022 +0100

range-op: Implement floating point multiplication fold_range [PR107569]

The following patch implements frange multiplication, including the
special case of x * x.  The callers don't tell us that it is x * x,
just that it is either z = x * x or if (x == y) z = x * y;
For irange that makes no difference, but for frange it can mean
x is -0.0 and y is 0.0 if they have the same range that includes both
signed and unsigned zeros, so we need to assume result could be -0.0.

The patch causes one regression:
+FAIL: gcc.dg/fold-overflow-1.c scan-assembler-times 2139095040 2
but that is already tracked in PR107608 and affects not just the newly
added multiplication, but addition and other floating point operations
(and doesn't seem like a ranger bug but dce or whatever else).

2022-11-12  Jakub Jelinek  

PR tree-optimization/107569
PR tree-optimization/107591
* range-op.h (range_operator_float::rv_fold): Add relation_kind
argument.
* range-op-float.cc (range_operator_float::fold_range): Name
last argument trio and pass trio.op1_op2 () as last argument to
rv_fold.
(range_operator_float::rv_fold): Add relation_kind argument.
(foperator_plus::rv_fold, foperator_minus::rv_fold): Likewise.
(foperator_mult): New class.
(floating_op_table::floating_op_table): Use foperator_mult for
MULT_EXPR.

[Bug libstdc++/107649] New std::complex specializations are never used

2022-11-12 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 53887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53887=edit
gcc13-pr107649.patch

So like this?  Only lightly tested so far, will check further after the
weekend.

[Bug d/107469] Build of GDC on FreeBSD 14 fails due to outdated value of __FreeBSD_version

2022-11-12 Thread developer at lorenzosalvadore dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107469

Lorenzo Salvadore  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com

--- Comment #1 from Lorenzo Salvadore  ---
I have sent the patch fixing this bug on the gcc-patches mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605685.html

[Bug other/107634] Very long filenames and URLs for sphinx-based docs

2022-11-12 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634

--- Comment #6 from Eric Botcazou  ---
> One of the biggest drawbacks of not having one file is when you need to add
> a new section, you have to add a new file/directory rather than edditing one
> file.

Right, that's clearly not manageable.  GNAT went through the same transition a
couple of years ago and ada/doc now contains 45 files, which is already quite a
bit but nowhere near the 700 now present in doc/.