date:20240524

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368)

2024-05-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Sam James  ---
btw, note that toralf hit this on the last snapshot -> it's

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368)

2024-05-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Sam James  ---
No - do you want me to? I can, but I don't have a cache of 15 packages
available, so it might be an hour or two. Just let me know.

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368)

2024-05-24 Thread aldyh at gcc dot gnu.org via Gcc-bugs

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #5 from Aldy Hernandez  ---
Has anyone bisected this?

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Andrew Pinski  ---
```
inline int func0(int y){
return -~y;
}
int func2(int y){
return (~y)/(-(~y));
}
int func2a(int y){
return (~y)/func0(y);
}
int func1(int y){
return (~y)/(y+1);
}
```

What is interesting clang is able to handle func2 but not the rest while GCC
currently does not handle any of them (folds -~y early to `y + 1` before `y/-y`
to -y).

[Bug tree-optimization/115224] (a ^ 1) & (a ^ ~1) is not optimized to 0 at the gimplelevel

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-05-25
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
MIne. found working on the `a - b` vs `b - a` patch.

[Bug tree-optimization/115224] New: (a ^ 1) & (a ^ ~1) is not optimized to 0 at the gimplelevel

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 115224
   Summary: (a ^ 1) & (a ^ ~1) is not optimized to 0 at the
gimplelevel
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f1(int a)
{
  return (a ^ -2) & (a ^ 1);
}
int f2(int a, int b)
{
  b = 1;
  return (a ^ b) & (a ^ ~b);
}
int f3(int a, int b)
{
  b = 1;
  int t = a ^b;
  int t1 = a ^ ~b;
  return t & t1;
}
```

These all should be the same, GCC does optimize all to 0 but f1 and f3 is only
done on the RTL level.

This can be solved by improving bitwise_inverted_equal_p to see that `(a ^
CST)` and `(a ^ (~CST))` are inverse of each other.

[Bug c++/114867] [modules] name lookup issues when a function overload set is exported from GMF

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-25

--- Comment #2 from Nathaniel Shead  ---
Confirmed.  The issue is that this part of 'do_nonmember_using_decl' for the
'using std::swap' declaration in the module purview removes the template
candidate and reinserts it to "reveal" it (possibly as newly exported):

  if (new_fn == old_fn)
{
  /* The function already exists in the current
 namespace.  We will still want to insert it if
 it is revealing a not-revealed thing.  */
  found = true;
  if (!revealing_p)
;
  else if (old.using_p ())
{
  if (exporting)
/* Update in place.  'tis ok.  */
OVL_EXPORT_P (old.get_using ()) = true;
  ;
}
  else if (DECL_MODULE_EXPORT_P (new_fn))
;
  else
{
  value = old.remove_node (value);
  found = false;
}
  break;
}

  // ...

  if (!found && insert_p)
/* Unlike the decl-pushing case we don't drop anticipated
   builtins here.  They don't cause a problem, and we'd
   like to match them with a future declaration.  */
value = ovl_insert (new_fn, value, 1 + exporting);

However, within the 'shared_ptr::swap' template it's already holding a pointer
to the OVERLOAD, and the 'remove_node' call drops it from this existing
overload set but the 'ovl_insert' doesn't add it back to that set, rather
returning a new one.

I suppose a fix is possibly to ensure that we only do this update in-place but
I  don't know if that'll work with OVL_HIDDEN declarations, since they need to
always be kept at the front of the list, and reordering might still cause the
same issues.

[Bug rtl-optimization/115182] [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095

2024-05-24 Thread hp at gcc dot gnu.org via Gcc-bugs

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-25
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095

2024-05-24 Thread hp at gcc dot gnu.org via Gcc-bugs

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Keywords|testsuite-fail  |

--- Comment #11 from Hans-Peter Nilsson  ---
(In reply to Richard Biener from comment #10)
> This should be fixed now.

I applied the commit r15-815-g5b9b3bae33cae to r15-518 and built
arith-rand-ll.c with -O2 -fno-delayed-branch -fno-ivopts -march=v10 (like
above, to avoid ivopts and delayed-branch issues and the simulation numbers are
even better than with r15-517:

Basic clock cycles, total @: 13653025
Memory source stall cycles: 78259

So, verified.

Thanks!
ps. I removed the testsuite-fail keyword as that belongs to PR115182.

[Bug tree-optimization/114999] A few missing optimizations due to `a - b` and `b - a` not being detected as negatives of each other

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Andrew Pinski  ---
`~a` and `a + 1` are also negative of each other too:

```
int f(int a, int b)
{
  int t = ~a;
  int t1 = -t;
  return t1 == t;
}

int f1(int a)
{
  return (~a) == (-~a);
}


int f2(int a)
{
  return (a) == (-a);
}



int f3(int a)
{
  a = ~a;
  return (a) == (-a);
}


int f4(int a)
{
  a = ~a;
  return f2(a);
}
```

Right now I have a patch which handles `a == -a` for `(a-b)`/`b-a`.
I need one that matches `~a` with the corresponding `a + 1` too.

Note gimple_bitwise_inverted_equal_p should also be expanded to support `-a`
with `a + -1` too.

[Bug lto/115223] New: [15 regression] ICE when building KDE kontrast with LTO (error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’)

2024-05-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 115223
   Summary: [15 regression] ICE when building KDE kontrast with
LTO (error: ‘TYPE_CANONICAL’ has different
‘TYPE_CANONICAL’)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58284&action=edit
kontrast.cpp.ii.xz

This is different from the earlier bugs the other week. I hit a bunch of these
and just picked Kontrast at random.

```
# g++ -c -std=gnu++20 -flto kontrast.cpp.ii
In file included from
/var/tmp/portage/app-accessibility/kontrast-23.08.5/work/kontrast-23.08.5/src/kontrast.cpp:361:
/var/tmp/portage/app-accessibility/kontrast-23.08.5/work/kontrast-23.08.5_build/src/kontrast_autogen/include/moc_kontrast.cpp:356:27:
error: ‘TYPE_CANONICAL’ has different ‘TYPE_CANONICAL’
  356 | QT_WARNING_POP
  |   ^
 >
SI
size  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
arg-types 
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76cb8930>
chain >>
pointer_to_this >
 
SI
size  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x75afe000
arg-types 
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76cb8930>
chain >>
pointer_to_this >
during IPA pass: *free_lang_data
/var/tmp/portage/app-accessibility/kontrast-23.08.5/work/kontrast-23.08.5_build/src/kontrast_autogen/include/moc_kontrast.cpp:356:27:
internal compiler error: ‘verify_type’ failed
0xcbae3247 verify_type(tree_node const*)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree.cc:14434
0xccbd4523 free_lang_data
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-free-lang-data.cc:1134
0xccbd4523 execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-free-lang-data.cc:1176
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/15/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include
--datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15
--mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15/man
--infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/15/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
15.0. p, commit bc7d81fe2f725b4043ce8b9ffb11d80032ce3f75'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-libgomp --disable-libssp --disable-libada
--disable-standard-branch-protection --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--with-zstd --without-isl --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-build-config=bootstrap-O3
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240523 (experimental)
ed63cd2aa5b114565fe5499c3a6bf8da5e8e48ba (Gentoo Hardened 15.0. p, commit
bc7d81fe2f725b4043ce8b9ffb11d80032ce3f75)
```

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
Hmm, my reduced testcase has slightly different behavior compared to the
original one for some versions of GCC. The original testcase is partly related
to PR 114844 while my reduced testcase is just missing handling of union.

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
C++14 (and C++11) had slightly different wording here:

```
Given a member function f of some class X, where f is an inheriting constructor
(12.9) or an implicitlydeclared special member function, the set of potential
exceptions of the implicitly-declared member function f consists of all the
members from the following sets:

if f is a destructor, the sets of potential exceptions of the destructor
invocations for X’s non-variant non-static data members and for X’s virtual and
direct base classes.

```

Looks like GCC just missed the rule applies to unions too.

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-807-gfae5e6a4dfcf92

2024-05-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

   Severity|normal  |blocker

--- Comment #4 from Sam James  ---
Blocker given I can't do any more testing with this.

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-25
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
https://eel.is/c++draft/except.spec#8 is the part of the spec that matters
here.

Specifically: "is potentially-throwing if and only if any of the destructors
for any of its potentially constructed subobjects"

Confirmed.

[Bug tree-optimization/115220] [15 Regression] RISC-V: newlib targets ICE during sink pass triggered in verify_ssa

2024-05-24 Thread law at gcc dot gnu.org via Gcc-bugs

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2024-05-25
 Target|riscv   |riscv,fr30

--- Comment #5 from Jeffrey A. Law  ---
It's a generic problem.  Almost certainly caused by the recent changes to the
sinking code.

It can be triggered (for example) on the fr30-elf port with -Os on this trivial
testcase:


extern char **environ;
static char ***p_environ = &environ;
int
_setenv_r (const char *name, const char *value)
{
  register char *C;
  int offset;
  for (C = (*p_environ)[offset]; (*C = *name++) && *C != '='; ++C);
  for (*C++ = '='; (*C++ = *value++) != 0;);


  return 0;
}

[Bug c++/115222] clang does not think libstdc++'s std::optional is nothrow destructible

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
here is a much reduced testcase:
```
struct A {
  ~A() noexcept(false);
};
union _Storage {
A _M_value;
~_Storage();
};
static_assert(noexcept(_Storage{}));
```

[Bug c++/115222] New: clang does not think libstdc++'s std::optional is nothrow destructible

2024-05-24 Thread pobrn at protonmail dot com via Gcc-bugs

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

Bug ID: 115222
   Summary: clang does not think libstdc++'s std::optional is
nothrow destructible
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pobrn at protonmail dot com
  Target Milestone: ---

clang and gcc disagree whether libstdc++'s std::optional is nothrow
destructible when T is not. My reading of https://eel.is/c++draft/optional.dtor
suggests that the destructor should be `noexcept(true)` (by omission).

Consider the following piece of C++ code:

```
#include 
#include 

struct A { ~A() noexcept(false); };

static_assert(std::is_nothrow_destructible_v>);
```

the assertion passes on gcc, while it fails on clang:
https://gcc.godbolt.org/z/1ndxK1avM

Now I have tried to reduce the input, and arrived at something like this (
https://gcc.godbolt.org/z/orx5j1Eaf ):

```
template  _Tp declval() noexcept;

template 
inline constexpr bool is_nothrow_destructible_v = noexcept(declval<_Tp>());

template 
struct _Optional_payload_base {
  union _Storage {
_Tp _M_value;
  } _M_payload;
};

template 
struct _Optional_payload : _Optional_payload_base<_Tp> {
~_Optional_payload();
};

struct A {
  ~A() noexcept(false);
};

static_assert(is_nothrow_destructible_v<_Optional_payload>);
```

The assertion passes on gcc, but fails on clang (and edg).

[Bug c++/103524] [meta-bug] modules issue

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 107401, which changed state.

Bug 107401 Summary: [c++ modules] ICE in get_originating_module_decl, at 
cp/module.cc:18587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107401

   What|Removed |Added

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

[Bug c++/107401] [c++ modules] ICE in get_originating_module_decl, at cp/module.cc:18587

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Nathaniel Shead  ---
Seems fixed in GCC 14:

pr81247-a.C:5:1: error: expected ‘{’ before ‘template’
5 | template < typename T > class A
  | ^~~~
pr81247-a.C: In instantiation of ‘class A’:
pr81247-a.C:12:13:   required from here
   12 |   A < int > a1; //  { dg-message "required from here" }
  | ^~
pr81247-a.C:6:1: error: ‘template > class N’ redeclared as
different kind of entity
6 | { // { dg-error "redeclared as different" }
  | ^
pr81247-a.C:3:11: note: previous declaration ‘namespace N { }’
3 | namespace N  // { dg-message "previous declaration" }
  |   ^

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368)

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-05-25
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |15.0

--- Comment #4 from Andrew Pinski  ---
.

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368)

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
This one still ICEs and it is closer to the original source:
```
typedef unsigned uint32_t;
int cde40_t;
int offset;
void aal_test_bit();
uint32_t cde40_key_pol();
long cde40_offset_check(uint32_t pos) {
  cde40_key_pol();
  if (cde40_t)
return (offset - 2) % (((pos == 3) ? 18 : 26)) != 0;
  return 0;
}
void cde40_check_struct() {
  uint32_t i, j, to_compare;
  for (;; i++) {
cde40_offset_check(i);
if (to_compare == 0) {
  if (i && cde40_key_pol())
;
  to_compare = i;
  continue;
}
j = to_compare;
for (; j < i; j++)
  aal_test_bit();
  }
}
```

[Bug c++/103524] [meta-bug] modules issue

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 102345, which changed state.

Bug 102345 Summary: [modules] Cannot define a module interface unit for 
anything in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102345

   What|Removed |Added

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

[Bug c++/102345] [modules] Cannot define a module interface unit for anything in

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||nshead at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Nathaniel Shead  ---
The diagnostic now reads:

e.cpp:2:14: error: declaring ‘void* operator new(long unsigned int)’ in module
‘newdel’ conflicts with builtin in global module
2 | export void* operator new(__SIZE_TYPE__);
  |  ^~~~
e.cpp:1:8: warning: not writing module ‘newdel’ due to errors
1 | export module newdel;
  |^~

which should be clearer as to what the issue is.

[Bug c++/102345] [modules] Cannot define a module interface unit for anything in

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

https://gcc.gnu.org/g:28b508233a12c13295f960a2cb8a4864879acfb4

commit r15-830-g28b508233a12c13295f960a2cb8a4864879acfb4
Author: Nathaniel Shead 
Date:   Sat May 25 01:03:54 2024 +1000

c++/modules: Improve diagnostic when redeclaring builtin in module
[PR102345]

If a user mistakenly includes a standard library header within the
module purview, they currently get a confusing "declaration conflicts
with builtin" error.  This patch updates the message to include "in
module", to help guide the user towards the likely cause.

PR c++/102345

gcc/cp/ChangeLog:

* module.cc (module_may_redeclare): Update error message.

gcc/testsuite/ChangeLog:

* g++.dg/modules/enum-12.C: Test for updated error.

Signed-off-by: Nathaniel Shead

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368)

2024-05-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Sam James  ---
```
typedef unsigned uint32_t;
int cde40_t;
void aal_test_bit();
uint32_t cde40_key_pol();
long cde40_offset_check(uint32_t pos) {
  cde40_key_pol();
  if (cde40_t)
return pos ?: 0 % 0;
}
void cde40_check_struct() {
  uint32_t i, j, to_compare;
  for (;; i++) {
cde40_offset_check(i);
if (to_compare == 0) {
  if (i && cde40_key_pol())
;
  to_compare = i;
  continue;
}
j = to_compare;
for (; j < i; j++)
  aal_test_bit();
  }
}
```

but (like another recent range issue), it has the nasty division by zero again.
Let me check the original...

[Bug tree-optimization/115220] [15 Regression] RISC-V: newlib targets ICE during sink pass triggered in verify_ssa

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Edwin Lu from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > Can you provide the preprocessed source?
> 
> I attached the -freport-bug output. Please lmk if you need anything else!

that is enough.

[Bug tree-optimization/115220] [15 Regression] RISC-V: newlib targets ICE during sink pass triggered in verify_ssa

2024-05-24 Thread ewlu at rivosinc dot com via Gcc-bugs

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

--- Comment #3 from Edwin Lu  ---
(In reply to Andrew Pinski from comment #1)
> Can you provide the preprocessed source?

I attached the -freport-bug output. Please lmk if you need anything else!

[Bug tree-optimization/115220] [15 Regression] RISC-V: newlib targets ICE during sink pass triggered in verify_ssa

2024-05-24 Thread ewlu at rivosinc dot com via Gcc-bugs

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

--- Comment #2 from Edwin Lu  ---
Created attachment 58283
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58283&action=edit
-freport-bug output

[Bug tree-optimization/115221] [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368)

2024-05-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Sam James  ---
Reducing.

[Bug tree-optimization/115221] New: [15 regression] ICE when building reiser4progs (propagate_updated_value, at gimple-range-cache.cc:1368)

2024-05-24 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 115221
   Summary: [15 regression] ICE when building reiser4progs
(propagate_updated_value, at
gimple-range-cache.cc:1368)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58282
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58282&action=edit
libcde40_static_la-cde40_repair.i

toralf reported this downstream in Gentoo at https://bugs.gentoo.org/932653.

```
# gcc -c .libs/libcde40_static_la-cde40_repair.i -O2
during GIMPLE pass: vrp
cde40_repair.c: In function ‘cde40_check_struct’:
cde40_repair.c:630:9: internal compiler error: in propagate_updated_value, at
gimple-range-cache.cc:1368
  630 | errno_t cde40_check_struct(reiser4_place_t *place, repair_hint_t *hint)
{
  | ^~
0x55facfddf8a5 ranger_cache::propagate_updated_value(tree_node*,
basic_block_def*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-cache.cc:1368
0x55fad1c1816a ranger_cache::set_global_range(tree_node*, vrange const&, bool)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-cache.cc:1089
0x55fad1c0a615 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range.cc:344
0x55fad1c0e8c9 gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range.cc:112
0x55fad0852e25 iv_can_overflow_p(loop*, tree_node*, tree_node*, tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-scalar-evolution.cc:3066
0x55fad0858ac6 simple_iv_with_niters(loop*, loop*, tree_node*, affine_iv*,
tree_node**, bool)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-scalar-evolution.cc:3273
0x55fad09296a1 number_of_iterations_exit_assumptions(loop*, edge_def*,
tree_niter_desc*, gcond**, bool, basic_block_def**)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-loop-niter.cc:3198
0x55fad092d659 number_of_iterations_exit(loop*, edge_def*, tree_niter_desc*,
bool, bool, basic_block_def**)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-loop-niter.cc:3285
0x55fad092d659 estimate_numbers_of_iterations(loop*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-loop-niter.cc:4882
0x55fad0930711 loop_exits_before_overflow
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-loop-niter.cc:5286
0x55fad0931465 scev_probably_wraps_p(tree_node*, tree_node*, tree_node*,
gimple*, loop*, bool)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-loop-niter.cc:5538
0x55fad0bb3c56 get_scev_info
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/vr-values.cc:204
0x55fad0bb3c56 range_of_var_in_loop(vrange&, tree_node*, loop*, gimple*,
range_query*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/vr-values.cc:271
0x55fad1c232c8 fold_using_range::range_of_ssa_name_with_loop_info(vrange&,
tree_node*, loop*, gphi*, fur_source&)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-fold.cc:1267
0x55fad1c232c8 fold_using_range::range_of_phi(vrange&, gphi*, fur_source&)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-fold.cc:1046
0x55fad1c2b5b0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-fold.cc:670
0x55fad1c2b91e fold_range(vrange&, gimple*, range_query*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-fold.cc:317
0x55fad1c15400 ranger_cache::range_of_expr(vrange&, tree_node*, gimple*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-cache.cc:1204
0x55fad1c32b87 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, fur_source&, value_relation*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-gori.cc:1146
0x55fad1c348c6 gori_compute::compute_operand_range(vrange&, gimple*, vrange
const&, tree_node*, fur_source&, value_relation*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-range-gori.cc:648
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/po

[Bug c++/115219] [11/12/13/14/15 Regression] [c++17+] ICE on depdendent noexcept class operator delete

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Barnabás Pőcze from comment #3)
> That reduced test case compiles fine for me. On CE, too. Am I missing some
> compilation flags?

Oh I reduced it with an older version but newer versions (GCC 13+) don't ICE
there.
Anyways here is new reduced testcase:
```
using t = decltype(sizeof(0));

template 
  constexpr bool is_nothrow_destructible_v =
false;

template
struct B {
static void * operator new(t s, t);
static void
operator delete(void *)
noexcept(is_nothrow_destructible_v)
   ;
};

void test() {
new (42) B();
}
```

The only difference between this one and the previous one is that noexcept is
is_nothrow_destructible_v vs is_nothrow_destructible_v. Meaning it is
dependent in the new version while in the old one is not; it seems like GCC 13+
can handle non-dependent values there.

[Bug tree-optimization/115220] [15] RISC-V: newlib targets ICE during sink pass triggered in verify_ssa

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code
  Component|target  |tree-optimization

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source?

[Bug c++/115219] [11/12/13/14/15 Regression] [c++17+] ICE on depdendent noexcept class operator delete

2024-05-24 Thread pobrn at protonmail dot com via Gcc-bugs

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

--- Comment #3 from Barnabás Pőcze  ---
That reduced test case compiles fine for me. On CE, too. Am I missing some
compilation flags?

[Bug target/115220] New: [15] RISC-V: newlib targets ICE during sink pass triggered in verify_ssa

2024-05-24 Thread ewlu at rivosinc dot com via Gcc-bugs

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

Bug ID: 115220
   Summary: [15] RISC-V: newlib targets ICE during sink pass
triggered in verify_ssa
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

Our gcc postcommit is encountering build failures for all newlib targets
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/981 with the
potential commits which caused the ice shown here
https://github.com/gcc-mirror/gcc/compare/c71886f2ca2e46ce1449c7064d6f1b447d02fcba...6d6f324bda1ccb51cd43ff9d4d017eb71bb2d690

during GIMPLE pass: sink
/home/runner/work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/newlib/newlib/libc/include/stdlib.h:212:9:
internal compiler error: verify_ssa failed
0x16ce85e verify_ssa(bool, bool)
../../../gcc/gcc/tree-ssa.cc:1203
0x12ef125 execute_function_todo
../../../gcc/gcc/passes.cc:2096
0x12ef98e execute_todo
../../../gcc/gcc/passes.cc:2143
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Potentially related:
Also getting this error in the build logs. 
/home/runner/work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/newlib/newlib/libc/include/stdlib.h:212:9:
error: stmt with wrong VUSE
  212 | int _setenv_r (struct _reent *, const char *__string, const char
*__value, int __overwrite);
  | ^
# .MEM_109 = VDEF <.MEM_67>
*C_59 = 61;
expected .MEM_106

[Bug c++/115219] [11/12/13/14/15 Regression] [c++17+] ICE on depdendent noexcept class operator delete

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
Summary|[c++17+] ICE on depdendent  |[11/12/13/14/15 Regression]
   |noexcept class operator |[c++17+] ICE on depdendent
   |delete  |noexcept class operator
   ||delete
  Known to work||6.5.0

[Bug c++/115219] [c++17+] ICE on depdendent noexcept class operator delete

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-05-24

--- Comment #2 from Andrew Pinski  ---
.

[Bug c++/115219] [c++17+] ICE on depdendent noexcept class operator delete

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE on conditionally|[c++17+] ICE on depdendent
   |noexcept class operator |noexcept class operator
   |delete  |delete
  Known to fail||7.1.0, 8.5.0
   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
Confirmed reduced testcase:
```
using t = decltype(sizeof(0));

template 
  constexpr bool is_nothrow_destructible_v =
false;

template
struct B {
static void * operator new(t s, t);
static void
operator delete(void *)
noexcept(is_nothrow_destructible_v)
   ;
};

void test() {
new (42) B();
}
```

[Bug c++/115219] New: ICE on conditionally noexcept class operator delete

2024-05-24 Thread pobrn at protonmail dot com via Gcc-bugs

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

Bug ID: 115219
   Summary: ICE on conditionally noexcept class operator delete
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pobrn at protonmail dot com
  Target Milestone: ---

Consider the following piece of C++ code:

```
#include 
#include 

template
struct B {
static void *
operator new(std::size_t s, std::size_t)
{ return ::operator new(s); }

static void
operator delete(void *)
noexcept(std::is_nothrow_destructible_v)
{ }
};

struct A : B { };

void test() {
new (42) A();
}
```

gcc 14.1.1 and trunk (on CE) trigger the following ICE (
https://gcc.godbolt.org/z/z7av1Mf3Y ):

```
: In function 'void test()':
:19:16: internal compiler error: in type_throw_all_p, at
cp/except.cc:1234
   19 | new (42) A();
  |^
0x268e9ac internal_error(char const*, ...)
???:0
0xa5b247 fancy_abort(char const*, int, char const*)
???:0
0xb08bb3 fnptr_conv_p(tree_node*, tree_node*)
???:0
0xaa0ae6 instantiate_type(tree_node*, tree_node*, int)
???:0
0xa75b7e build_op_delete_call(tree_code, tree_node*, tree_node*, bool,
tree_node*, tree_node*, int)
???:0
0xb82ab0 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
???:0
0xc63d8a c_parse_file()
???:0
0xdb95b9 c_common_parse_file()
???:0
```

Removing the conditional noexcept specification makes the ICE go away.

Here is a more detailed stack trace from the arch linux build of gcc (about
14.1.1):

```
Breakpoint 1, internal_error (gmsgid=gmsgid@entry=0x2b4b860 "in %s, at %s:%d")
at /usr/src/debug/gcc/gcc/gcc/diagnostic.cc:2227
2227{
(gdb) bt
#0  internal_error (gmsgid=gmsgid@entry=0x2b4b860 "in %s, at %s:%d") at
/usr/src/debug/gcc/gcc/gcc/diagnostic.cc:2227
#1  0x00703e88 in fancy_abort (file=0x2b5c798
"/usr/src/debug/gcc/gcc/gcc/cp/except.cc", line=1234, function=0x2aa87dc
"type_throw_all_p") at /usr/src/debug/gcc/gcc/gcc/diagnostic.cc:2353
#2  0x006b97f2 in type_throw_all_p (type=) at
/usr/src/debug/gcc/gcc/gcc/cp/except.cc:1231
#3  type_throw_all_p (type=) at
/usr/src/debug/gcc/gcc/gcc/cp/except.cc:1231
#4  noexcept_conv_p (to=0x76c24498, from=0x76a15930) at
/usr/src/debug/gcc/gcc/gcc/cp/cvt.cc:2130
#5  fnptr_conv_p (to=, from=) at
/usr/src/debug/gcc/gcc/gcc/cp/cvt.cc:2157
#6  0x0072a772 in instantiate_type (lhstype=0x76c24498,
rhs=0x76a10690, complain=0) at /usr/src/debug/gcc/gcc/gcc/cp/class.cc:9085
#7  0x0072cede in build_op_delete_call (code=DELETE_EXPR,
addr=0x76a1e1e0, size=0x76e212d0, global_p=,
placement=0x76a1b340, alloc_fn=0x76de9700, complain=3)
at /usr/src/debug/gcc/gcc/gcc/cp/call.cc:7893
#8  0x00804299 in build_new_1
(placement=placement@entry=0x7fffcd78, type=,
nelts=, nelts@entry=0x0, init=init@entry=0x7fffcd70, 
globally_qualified_p=globally_qualified_p@entry=false,
complain=complain@entry=3) at /usr/src/debug/gcc/gcc/gcc/cp/init.cc:3784
#9  0x008055ca in build_new (loc=64384747, placement=0x7fffcd78,
type=, nelts=0x0, init=0x7fffcd70, use_global_new=0,
complain=3) at /usr/src/debug/gcc/gcc/gcc/cp/init.cc:4054
#10 0x00867ab7 in cp_parser_new_expression
(parser=parser@entry=0x76fb4dc8) at
/usr/src/debug/gcc/gcc/gcc/cp/parser.cc:9659
#11 0x0086258b in cp_parser_unary_expression (parser=0x76fb4dc8,
pidk=, address_p=, cast_p=,
decltype_p=)
at /usr/src/debug/gcc/gcc/gcc/cp/parser.cc:9245
#12 0x00864664 in cp_parser_binary_expression
(parser=parser@entry=0x76fb4dc8, cast_p=cast_p@entry=false,
no_toplevel_fold_p=no_toplevel_fold_p@entry=false,
decltype_p=decltype_p@entry=false, 
prec=prec@entry=PREC_NOT_OPERATOR, pidk=pidk@entry=0x0) at
/usr/src/debug/gcc/gcc/gcc/cp/parser.cc:10393
#13 0x008653bd in cp_parser_assignment_expression
(parser=parser@entry=0x76fb4dc8, pidk=pidk@entry=0x0,
cast_p=cast_p@entry=false, decltype_p=decltype_p@entry=false)
at /usr/src/debug/gcc/gcc/gcc/cp/parser.cc:10737
#14 0x00865994 in cp_parser_expression
(parser=parser@entry=0x76fb4dc8, pidk=pidk@entry=0x0,
cast_p=cast_p@entry=false, decltype_p=decltype_p@entry=false,
warn_comma_p=warn_comma_p@entry=false)
at /usr/src/debug/gcc/gcc/gcc/cp/parser.cc:10903
#15 0x0086622e in cp_parser_expression_statement
(parser=0x76fb4dc8, in_statement_expr=0x0) at
/usr/src/debug/gcc/gcc/gcc/cp/parser.cc:13166
#16 0x00876d31 in cp_parser_statement
(parser=parser@entry=0x76fb4dc8,
in_statement_expr=in_statement_expr@entry=0x0,
in_compound=in_compound@entry=true, if_p=if_p@entry=0x0, chain=chain@entry=0x0, 
loc_after_labels=loc_after_labels@entry=0x0) at
/usr/src/debug/gcc/gcc/gcc/cp/parser.cc:12947
#17 0x00

[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics

2024-05-24 Thread slyfox at gcc dot gnu.org via Gcc-bugs

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

--- Comment #22 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #21)

gcc generates the following code for this C code:

> int main() {
>   const __m128i su = _mm_set1_epi32(0x4f80);
>   const __m128  sf = _mm_castsi128_ps(su);
> 
>   const __m128  overflow_mask_f32 = _mm_cmpge_ps(sf,
> _mm_set1_ps(2147483648.0f));
>   const __m128i overflow_mask = _mm_castps_si128(overflow_mask_f32);
> 
>   const __m128i conv = _mm_cvttps_epi32(sf); // overflows
>   const __m128i yes = _mm_set1_epi32(INT32_MAX);
> 
>   const __m128i a = _mm_and_si128(overflow_mask, yes);
>   const __m128i na = _mm_andnot_si128(overflow_mask, conv);
> 
>   const __m128i conv_masked = _mm_or_si128(a, na);

Dump of assembler code for function main:
   0x00401020 <+0>: sub$0x8,%rsp
   0x00401024 <+4>: movss  0xfdc(%rip),%xmm2# 0x402008
   0x0040102c <+12>:movss  0xfd0(%rip),%xmm0# 0x402004
   0x00401034 <+20>:movss  0xfd0(%rip),%xmm3# 0x40200c
   0x0040103c <+28>:shufps $0x0,%xmm2,%xmm2
   0x00401040 <+32>:shufps $0x0,%xmm0,%xmm0
   0x00401044 <+36>:cmpleps %xmm2,%xmm0
   0x00401048 <+40>:cvttps2dq %xmm2,%xmm2
   0x0040104c <+44>:shufps $0x0,%xmm3,%xmm3
   0x00401050 <+48>:movdqa %xmm0,%xmm1
   0x00401054 <+52>:andps  %xmm3,%xmm0
   0x00401057 <+55>:pandn  %xmm2,%xmm1
   0x0040105b <+59>:por%xmm0,%xmm1

All of this all looks fine.

>   const __m128i actual = _mm_cmpeq_epi32(conv_masked,
> _mm_set1_epi32(INT32_MAX));
>   const __m128i expected = _mm_set1_epi32(-1);

   0x0040105f <+63>:pcmpeqd %xmm0,%xmm0
   0x00401063 <+67>:pcmpeqd %xmm2,%xmm1
   0x00401067 <+71>:call   0x401160 <_ZL9assert_eqDv2_xS_>

Here `pcmpeqd %xmm2,%xmm1` is a problematic instruction. Why does `gcc` use
`%xmm2` (result of `cvttps2dq`) instead of, say `%xmm0` which contains
`0x` pattern?

>   assert_eq(expected, actual);
> }
> ```

[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47

2024-05-24 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #8)
> I simply copied all the associated functions in trans-expr.cc from mainline
> and plonked them in 13-branch. That's why I said that I hadn't done any
> weeding. There is also a commit from Jakub in there as well. I'll check to
> see if the associated PRs are fixed.
> 
> I got into regression fixing before the 14.1 release and this was one of
> the low hanging fruit. To be honest, I am not especially bothered about
> fixing it or not. Up until the ICE of the PR it was giving an error on
> valid code. I would prefer though that the ICE went away!

Well, if the ICE is resolved and there is no regression, go ahead.
The commits I mentioned on 14-branch address some more, so it may be
a waste of time to see if any issue was fixed along the way.

[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:9561cf550a66a89e7c8d31202a03c4fddf82a3f2

commit r15-828-g9561cf550a66a89e7c8d31202a03c4fddf82a3f2
Author: Harald Anlauf 
Date:   Thu May 23 21:13:00 2024 +0200

Fortran: improve attribute conflict checking [PR93635]

gcc/fortran/ChangeLog:

PR fortran/93635
* symbol.cc (conflict_std): Helper function for reporting attribute
conflicts depending on the Fortran standard version.
(conf_std): Helper macro for checking standard-dependent conflicts.
(gfc_check_conflict): Use it.

gcc/testsuite/ChangeLog:

PR fortran/93635
* gfortran.dg/c-interop/c1255-2.f90: Adjust pattern.
* gfortran.dg/pr87907.f90: Likewise.
* gfortran.dg/pr93635.f90: New test.

Co-authored-by: Steven G. Kargl

[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:93765736815a049e14d985b758a213cfe60c1e1c

commit r15-827-g93765736815a049e14d985b758a213cfe60c1e1c
Author: Harald Anlauf 
Date:   Mon May 13 22:06:33 2024 +0200

Fortran: fix bounds check for assignment, class component [PR86100]

gcc/fortran/ChangeLog:

PR fortran/86100
* trans-array.cc (gfc_conv_ss_startstride): Use abridged_ref_name
to generate a more user-friendly name for bounds-check messages.
* trans-expr.cc (gfc_copy_class_to_class): Fix bounds check for
rank>1 by looping over the dimensions.

gcc/testsuite/ChangeLog:

PR fortran/86100
* gfortran.dg/bounds_check_25.f90: New test.

[Bug c++/114841] [P0522R0] partial ordering of template template parameters

2024-05-24 Thread mizvekov at gmail dot com via Gcc-bugs

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

--- Comment #2 from Matheus Izvekov  ---
I published
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3310r0.html
to address this problem, it has the most up-to-date wording.

FYI the inconsistent deduction examples from problem #1 crash GCC.

[Bug c++/111529] [11/12/13 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

2024-05-24 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed for 11.5/12.4/13.4/14.

[Bug c++/101603] [meta-bug] pointer to member functions issues

2024-05-24 Thread jason at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
Bug 101603 depends on bug 113598, which changed state.

Bug 113598 Summary: [11/12/13 Regression] GCC internal compiler error since 
r0-124275
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598

   What|Removed |Added

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

[Bug c++/113598] [11/12/13 Regression] GCC internal compiler error since r0-124275

2024-05-24 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 11.5/12.4/13.4/14.

[Bug c++/111529] [11/12/13 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-11448-ga644775c363979bc25951532819ffa0f244b82f4
Author: Jason Merrill 
Date:   Fri Sep 22 12:10:11 2023 +0100

c++: unroll pragma in templates [PR111529]

We were failing to handle ANNOTATE_EXPR in tsubst_copy_and_build, leading
to
problems with substitution of any wrapped expressions.

Let's also not tell users that lambda templates are available in C++14.

PR c++/111529

gcc/cp/ChangeLog:

* parser.c (cp_parser_lambda_declarator_opt): Don't suggest
-std=c++14 for lambda templates.
* pt.c (tsubst_expr): Move ANNOTATE_EXPR handling...
(tsubst_copy_and_build): ...here.

gcc/testsuite/ChangeLog:

* g++.dg/ext/unroll-4.C: New test.

(cherry picked from commit 9c62af101e11e1cce573c2b3d2e18b403412dbc8)

[Bug c++/113598] [11/12/13 Regression] GCC internal compiler error since r0-124275

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:38de942670ad39c60ba4feae893d11843e0aebe8

commit r11-11449-g38de942670ad39c60ba4feae893d11843e0aebe8
Author: Jason Merrill 
Date:   Thu Jan 25 12:02:07 2024 -0500

c++: array of PMF [PR113598]

Here AGGREGATE_TYPE_P includes pointers to member functions, which is not
what we want.  Instead we should use class||array, as elsewhere in the
function.

PR c++/113598

gcc/cp/ChangeLog:

* init.c (build_vec_init): Don't use {} for PMF.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-pmf2.C: New test.

(cherry picked from commit 136a828754ff65079a83482b49d54bd5bc64)

[Bug libstdc++/100667] [11/12 Regression] std::tuple cannot be constructed from A&&, if A not defined (only forward declared)

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:16046a075cb54c90609825e30b2ab45a03395ca1

commit r11-11447-g16046a075cb54c90609825e30b2ab45a03395ca1
Author: Jason Merrill 
Date:   Wed Mar 27 16:14:01 2024 -0400

c++: __is_constructible ref binding [PR100667]

The requirement that a type argument be complete is excessive in the case
of
direct reference binding to the same type, which does not rely on any
properties of the type.  This is LWG 2939.

PR c++/100667

gcc/cp/ChangeLog:

* semantics.c (same_type_ref_bind_p): New.
(finish_trait_expr): Use it.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_constructible8.C: New test.

(cherry picked from commit 8bb3ef3f6e335e8794590fb712a2661d11d21973)

[Bug libstdc++/115218] New: The conversion constructor of concat_view::iterator always default-constructs variant

2024-05-24 Thread hewillk at gmail dot com via Gcc-bugs

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

Bug ID: 115218
   Summary: The conversion constructor of concat_view::iterator
always default-constructs variant
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

constexpr
iterator(iterator __it)
  requires _Const && (convertible_to, iterator_t> && ...)
: _M_parent(__it._M_parent)
{
  _M_invoke_with_runtime_index([this, &__it]() {
_M_it.template emplace<_Idx>(std::get<_Idx>(std::move(__it._M_it)));
  });
}

This constructor always default-constructs variant which may not be
well-formed:

https://godbolt.org/z/YndEKGhz5

#include 

struct I {
  I() = delete;
  I(int*);
  using value_type = int;
  using difference_type = int;
  value_type& operator*() const;
  I& operator++();
  void operator++(int);
};

struct R {
  int* begin();
  I begin() const;
  std::unreachable_sentinel_t end() const;
};

int main() {
  auto c = std::ranges::concat_view{R{}};
  const auto& cr = c;
  decltype(cr.begin()) it = c.begin(); // hard error
}

[Bug target/115217] Register pairs can't be encoded in RISC-V inline asm blocks

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
Note aarch64's TImode is always allocated in starting in even number registers
(starting in GCC 9:
https://inbox.sourceware.org/gcc-patches/20181002161915.18843-10-richard.hender...@linaro.org/
) .

[Bug libstdc++/100667] [11/12 Regression] std::tuple cannot be constructed from A&&, if A not defined (only forward declared)

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-10470-gba57a52dbf6a64ba66f72c20064c5c0e8cc9dbbb
Author: Jason Merrill 
Date:   Wed Mar 27 16:14:01 2024 -0400

c++: __is_constructible ref binding [PR100667]

The requirement that a type argument be complete is excessive in the case
of
direct reference binding to the same type, which does not rely on any
properties of the type.  This is LWG 2939.

PR c++/100667

gcc/cp/ChangeLog:

* semantics.cc (same_type_ref_bind_p): New.
(finish_trait_expr): Use it.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_constructible8.C: New test.

(cherry picked from commit 8bb3ef3f6e335e8794590fb712a2661d11d21973)

[Bug target/115217] New: Register pairs can't be encoded in RISC-V inline asm blocks

2024-05-24 Thread palmer at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 115217
   Summary: Register pairs can't be encoded in RISC-V inline asm
blocks
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palmer at gcc dot gnu.org
  Target Milestone: ---

Alex is trying to do the amocas.q support in Linux, which operates on paired X
registers by providing only the even register in the instruction encoding.  As
far as I can tell we don't have a way to encode this in inline assembly
constraints: we can just force a pair of registers via the asm/register
variable type tricks, but we don't have a constraint for allocating them.

IIUC just doing something like the following isn't sufficient, as we'd need to
also read/clobber the paired register and I'm not sure how to plumb that into
inline assembly.

It's not super clear if that's a real performance problem as there's not going
to be a ton of 128-bit CAS instances in code, but I figured it's worth filing a
bug just in case anyone's looking or there's some inline asm trick I don't know
about.  Both x86_64 and aarch64 look like they're using explicit register
numbers in their 128-bit cmpxchg code in Linux, so maybe that's a sign this
isn't worth doing?

diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index a9ee346af6f..c372c5f8853 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -141,6 +141,10 @@ (define_constraint "T"
   (and (match_operand 0 "move_operand")
(match_test "CONSTANT_P (op)")))

+(define_constraint "re"
+  "The even part of an X register pair, not including the x0-x0 pair"
+  (match_test "even_x_register_pair (op)"))
+
 ;; Zfa constraints.

 (define_constraint "zfli"
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index 0fb5729fdcf..70ba741ab54 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -201,6 +201,11 @@ (define_predicate "zcmp_mv_sreg_operand"
 : IN_RANGE (REGNO (op), S0_REGNUM, S1_REGNUM)
 || IN_RANGE (REGNO (op), S2_REGNUM, S7_REGNUM)")))

+;; Some operations (like amocas.q) operate on X register pairs.
+(define_predicate "even_x_register_pair"
+  (and (match_code "reg")
+   (match_test "GP_REG_P (REGNO (op)) && (REGNO (op) % 2 == 0)")))
+
 ;; Only use branch-on-bit sequences when the mask is not an ANDI immediate.
 (define_predicate "branch_on_bit_operand"
   (and (match_code "const_int")

[Bug c++/115187] [14 Regression] ICE when deleting temporary array

2024-05-24 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 14.2/15.

[Bug c++/104318] [modules] ICE tsubst_copy, at cp/pt.c:16621

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Nathaniel Shead  ---
I can no longer reproduce (either reproducer) since GCC 14.

[Bug c++/103524] [meta-bug] modules issue

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 104318, which changed state.

Bug 104318 Summary: [modules] ICE tsubst_copy, at cp/pt.c:16621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104318

   What|Removed |Added

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

[Bug c++/115187] [14 Regression] ICE when deleting temporary array

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:9031c027827bff44e1b55c366fc7034c43501b4c

commit r14-10242-g9031c027827bff44e1b55c366fc7034c43501b4c
Author: Jason Merrill 
Date:   Wed May 22 18:41:27 2024 -0400

c++: deleting array temporary [PR115187]

Decaying the array temporary to a pointer and then deleting that crashes in
verify_gimple_stmt, because the TARGET_EXPR is first evaluated inside the
TRY_FINALLY_EXPR, but the cleanup point is outside.  Fixed by using
get_target_expr instead of save_expr.

I also adjust the stabilize_expr comment to prevent me from again thinking
it's a suitable replacement.

PR c++/115187

gcc/cp/ChangeLog:

* init.cc (build_delete): Use get_target_expr instead of save_expr.
* tree.cc (stabilize_expr): Update comment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/array-prvalue3.C: New test.

[Bug c/114831] typeof doesn't evaluate expression when it has variably modified type in some cases

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:9f1798c1a93257526196a3c19828e40fb28ac551

commit r15-825-g9f1798c1a93257526196a3c19828e40fb28ac551
Author: Martin Uecker 
Date:   Sat May 18 14:40:02 2024 +0200

c: Fix for some variably modified types not being recognized [PR114831]

We did not evaluate expressions with variably modified types correctly
in typeof and did not produce warnings when jumping over declarations
using typeof.  After addressof or array-to-pointer decay we construct
new pointer types that have to be marked variably modified if the pointer
target is variably modified.

2024-05-18 Martin Uecker  

PR c/114831
gcc/c/
* c-typeck.cc (array_to_pointer_conversion, build_unary_op):
Propagate flag to pointer target.

gcc/testsuite/
* gcc.dg/pr114831-1.c: New test.
* gcc.dg/pr114831-2.c: New test.
* gcc.dg/gnu23-varmod-1.c: New test.
* gcc.dg/gnu23-varmod-2.c: New test.

[Bug c++/111106] [11/12/13/14/15 Regression] missing ; causes internal compiler error: in dependent_type_p, at cp/pt.cc:27901

2024-05-24 Thread simartin at gcc dot gnu.org via Gcc-bugs

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

Simon Martin  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |simartin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-05-24

--- Comment #3 from Simon Martin  ---
Working on it

[Bug c++/114683] [modules] name declared in GMF in inline namespace and exported via using-decl from parent namespace is not visible to importer

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

   Last reconfirmed||2024-05-24
 CC||nshead at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Nathaniel Shead  ---
Confirmed.  Another related testcase with a different kind of using-declaration
from PR114868:

  // using_enum_a.cpp
  module;
  namespace foo {
enum class a { x, y, z };
  }
  export module M:a;
  namespace bar {
export using enum foo::a;
  }

  // using_enum_b.cpp
  export module M;
  export import :a;

  // using_enum_c.cpp
  import M;
  int main() {
auto x = bar::x;
  }

[Bug c++/103524] [meta-bug] modules issue

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 114868, which changed state.

Bug 114868 Summary: [modules] func declared in GMF and exported via using-decl 
in module partition is not actually exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114868

   What|Removed |Added

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

[Bug c++/114868] [modules] func declared in GMF and exported via using-decl in module partition is not actually exported

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #4 from Nathaniel Shead  ---
And fixed for GCC 14.2.

[Bug c++/114868] [modules] func declared in GMF and exported via using-decl in module partition is not actually exported

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Nathaniel Shead
:

https://gcc.gnu.org/g:782ad2033ea0709a25ef3e899cbb9491406146d5

commit r14-10241-g782ad2033ea0709a25ef3e899cbb9491406146d5
Author: Nathaniel Shead 
Date:   Tue Apr 9 21:49:58 2024 +1000

c++: Propagate using decls from partitions [PR114868]

The modules code currently neglects to set OVL_USING_P on the dependency
created for a using-decl, which causes it not to remember that the
OVL_EXPORT_P flag had been set on it when emitted from the primary
interface unit. This patch ensures that it occurs.

PR c++/114868

gcc/cp/ChangeLog:

* module.cc (depset::hash::add_binding_entity): Propagate
OVL_USING_P for using-declarations.

gcc/testsuite/ChangeLog:

* g++.dg/modules/using-15_a.C: New test.
* g++.dg/modules/using-15_b.C: New test.
* g++.dg/modules/using-15_c.C: New test.

Signed-off-by: Nathaniel Shead 
(cherry picked from commit 0d0215b10dbbe39d655ceda4af283f288ec7680c)

[Bug c++/115216] operator auto() gets instantiatied too eagerly

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
MSVC and ICC (EDG in GCC compat mode) also rejects the code for the same reason
as GCC. Are you sure this is not a clang issue?

[Bug c++/115216] operator auto() gets instantiatied too eagerly

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

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

Next time please attach the testcase or place it inline rather than just a link
to godbolt.

[Bug c++/115216] New: operator auto() gets instantiatied too eagerly

2024-05-24 Thread olaf.krzikalla at dlr dot de via Gcc-bugs

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

Bug ID: 115216
   Summary: operator auto() gets instantiatied too eagerly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olaf.krzikalla at dlr dot de
  Target Milestone: ---

Full example in:

https://godbolt.org/z/3hG5fh1PW

The example can be compiled either by commenting out line 24 or by swapping in
line 8 for line 9. In any case line 25 works. Thus there is a difference
between
the terms "xx[1]" and "xx.operator[](1)".

The error occurs with all recent gcc versions. It doesn't occur with any clang
version.

[Bug c++/103524] [meta-bug] modules issue

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 114275, which changed state.

Bug 114275 Summary: using std::thread within a templated function in a module 
fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275

   What|Removed |Added

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

[Bug c++/105320] Use of shared_ptr within a type exported from a module results in spurious compiler error

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #7 from Nathaniel Shead  ---
And now fixed for GCC 14.2 as well.

[Bug c++/103524] [meta-bug] modules issue

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 105320, which changed state.

Bug 105320 Summary: Use of shared_ptr within a type exported from a module 
results in spurious compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105320

   What|Removed |Added

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

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #12 from Nathaniel Shead  ---
And now fixed for GCC 14.2.

[Bug c++/105320] Use of shared_ptr within a type exported from a module results in spurious compiler error

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r14-10240-gfd6fd88b1a93f4fb38f095688255ab5c00122810
Author: Nathaniel Shead 
Date:   Mon Apr 29 17:00:13 2024 +1000

c++: Fix instantiation of imported temploid friends [PR114275]

This patch fixes a number of issues with the handling of temploid friend
declarations.

The primary issue is that instantiations of friend declarations should
attach the declaration to the same module as the befriending class, by
[module.unit] p7.1 and [temp.friend] p2; this could be a different
module from the current TU, and so needs special handling.

The other main issue here is that we can't assume that just because name
lookup didn't find a definition for a hidden class template, that it
doesn't exist at all: it could be a non-exported entity that we've
nevertheless streamed in from an imported module.  We need to ensure
that when instantiating template friend classes that we return the same
TEMPLATE_DECL that we got from our imports, otherwise we will get later
issues with 'duplicate_decls' (rightfully) complaining that they're
different when trying to merge.

This doesn't appear necessary for function templates due to the existing
name lookup handling already finding these hidden declarations.

(cherry-picked from commits b5f6a56940e70838a07e885de03a92e2bd64674a and
ec2365e07537e8b17745d75c28a2b45bf33be119)

PR c++/105320
PR c++/114275

gcc/cp/ChangeLog:

* cp-tree.h (propagate_defining_module): Declare.
(remove_defining_module): Declare.
(lookup_imported_hidden_friend): Declare.
* decl.cc (duplicate_decls): Also check if hidden decls can be
redeclared in this module. Call remove_defining_module on
to-be-freed newdecl.
* module.cc (imported_temploid_friends): New.
(init_modules): Initialize it.
(trees_out::decl_value): Write it; don't consider imported
temploid friends as attached to a module.
(trees_in::decl_value): Read it for non-discarded decls.
(get_originating_module_decl): Follow the owning decl for an
imported temploid friend.
(propagate_defining_module): New.
(remove_defining_module): New.
* name-lookup.cc (get_mergeable_namespace_binding): New.
(lookup_imported_hidden_friend): New.
* pt.cc (tsubst_friend_function): Propagate defining module for
new friend functions.
(tsubst_friend_class): Lookup imported hidden friends.  Check
for valid module attachment of existing names.  Propagate
defining module for new classes.

gcc/testsuite/ChangeLog:

* g++.dg/modules/tpl-friend-10_a.C: New test.
* g++.dg/modules/tpl-friend-10_b.C: New test.
* g++.dg/modules/tpl-friend-10_c.C: New test.
* g++.dg/modules/tpl-friend-10_d.C: New test.
* g++.dg/modules/tpl-friend-11_a.C: New test.
* g++.dg/modules/tpl-friend-11_b.C: New test.
* g++.dg/modules/tpl-friend-12_a.C: New test.
* g++.dg/modules/tpl-friend-12_b.C: New test.
* g++.dg/modules/tpl-friend-12_c.C: New test.
* g++.dg/modules/tpl-friend-12_d.C: New test.
* g++.dg/modules/tpl-friend-12_e.C: New test.
* g++.dg/modules/tpl-friend-12_f.C: New test.
* g++.dg/modules/tpl-friend-13_a.C: New test.
* g++.dg/modules/tpl-friend-13_b.C: New test.
* g++.dg/modules/tpl-friend-13_c.C: New test.
* g++.dg/modules/tpl-friend-13_d.C: New test.
* g++.dg/modules/tpl-friend-13_e.C: New test.
* g++.dg/modules/tpl-friend-13_f.C: New test.
* g++.dg/modules/tpl-friend-13_g.C: New test.
* g++.dg/modules/tpl-friend-14_a.C: New test.
* g++.dg/modules/tpl-friend-14_b.C: New test.
* g++.dg/modules/tpl-friend-14_c.C: New test.
* g++.dg/modules/tpl-friend-14_d.C: New test.
* g++.dg/modules/tpl-friend-9.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill 
Reviewed-by: Patrick Palka

[Bug c++/114275] using std::thread within a templated function in a module fails to compile

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Nathaniel Shead
:

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

commit r14-10240-gfd6fd88b1a93f4fb38f095688255ab5c00122810
Author: Nathaniel Shead 
Date:   Mon Apr 29 17:00:13 2024 +1000

c++: Fix instantiation of imported temploid friends [PR114275]

This patch fixes a number of issues with the handling of temploid friend
declarations.

The primary issue is that instantiations of friend declarations should
attach the declaration to the same module as the befriending class, by
[module.unit] p7.1 and [temp.friend] p2; this could be a different
module from the current TU, and so needs special handling.

The other main issue here is that we can't assume that just because name
lookup didn't find a definition for a hidden class template, that it
doesn't exist at all: it could be a non-exported entity that we've
nevertheless streamed in from an imported module.  We need to ensure
that when instantiating template friend classes that we return the same
TEMPLATE_DECL that we got from our imports, otherwise we will get later
issues with 'duplicate_decls' (rightfully) complaining that they're
different when trying to merge.

This doesn't appear necessary for function templates due to the existing
name lookup handling already finding these hidden declarations.

(cherry-picked from commits b5f6a56940e70838a07e885de03a92e2bd64674a and
ec2365e07537e8b17745d75c28a2b45bf33be119)

PR c++/105320
PR c++/114275

gcc/cp/ChangeLog:

* cp-tree.h (propagate_defining_module): Declare.
(remove_defining_module): Declare.
(lookup_imported_hidden_friend): Declare.
* decl.cc (duplicate_decls): Also check if hidden decls can be
redeclared in this module. Call remove_defining_module on
to-be-freed newdecl.
* module.cc (imported_temploid_friends): New.
(init_modules): Initialize it.
(trees_out::decl_value): Write it; don't consider imported
temploid friends as attached to a module.
(trees_in::decl_value): Read it for non-discarded decls.
(get_originating_module_decl): Follow the owning decl for an
imported temploid friend.
(propagate_defining_module): New.
(remove_defining_module): New.
* name-lookup.cc (get_mergeable_namespace_binding): New.
(lookup_imported_hidden_friend): New.
* pt.cc (tsubst_friend_function): Propagate defining module for
new friend functions.
(tsubst_friend_class): Lookup imported hidden friends.  Check
for valid module attachment of existing names.  Propagate
defining module for new classes.

gcc/testsuite/ChangeLog:

* g++.dg/modules/tpl-friend-10_a.C: New test.
* g++.dg/modules/tpl-friend-10_b.C: New test.
* g++.dg/modules/tpl-friend-10_c.C: New test.
* g++.dg/modules/tpl-friend-10_d.C: New test.
* g++.dg/modules/tpl-friend-11_a.C: New test.
* g++.dg/modules/tpl-friend-11_b.C: New test.
* g++.dg/modules/tpl-friend-12_a.C: New test.
* g++.dg/modules/tpl-friend-12_b.C: New test.
* g++.dg/modules/tpl-friend-12_c.C: New test.
* g++.dg/modules/tpl-friend-12_d.C: New test.
* g++.dg/modules/tpl-friend-12_e.C: New test.
* g++.dg/modules/tpl-friend-12_f.C: New test.
* g++.dg/modules/tpl-friend-13_a.C: New test.
* g++.dg/modules/tpl-friend-13_b.C: New test.
* g++.dg/modules/tpl-friend-13_c.C: New test.
* g++.dg/modules/tpl-friend-13_d.C: New test.
* g++.dg/modules/tpl-friend-13_e.C: New test.
* g++.dg/modules/tpl-friend-13_f.C: New test.
* g++.dg/modules/tpl-friend-13_g.C: New test.
* g++.dg/modules/tpl-friend-14_a.C: New test.
* g++.dg/modules/tpl-friend-14_b.C: New test.
* g++.dg/modules/tpl-friend-14_c.C: New test.
* g++.dg/modules/tpl-friend-14_d.C: New test.
* g++.dg/modules/tpl-friend-9.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill 
Reviewed-by: Patrick Palka

[Bug c++/103524] [meta-bug] modules issue

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 115200, which changed state.

Bug 115200 Summary: [modules] ICE in declare_module() with unclosed namespace 
scope before module perview
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115200

   What|Removed |Added

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

[Bug c++/115200] [modules] ICE in declare_module() with unclosed namespace scope before module perview

2024-05-24 Thread nshead at gcc dot gnu.org via Gcc-bugs

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

Nathaniel Shead  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||nshead at gcc dot gnu.org
   Target Milestone|--- |15.0
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org

--- Comment #2 from Nathaniel Shead  ---
Fixed for GCC 15.

[Bug c++/115200] [modules] ICE in declare_module() with unclosed namespace scope before module perview

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Nathaniel Shead :

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

commit r15-824-gdae606a11eb99814e452b49241fa76f7678f53b8
Author: Nathaniel Shead 
Date:   Fri May 24 00:08:57 2024 +1000

c++/modules: Improve errors for bad module-directives [PR115200]

This fixes an ICE when a module directive is not given at global scope.
Although not explicitly mentioned, it seems implied from [basic.link] p1
and [module.global.frag] that a module-declaration must appear at the
global scope after preprocessing.  Apart from this the patch also
slightly improves the errors given when accidentally using a module
control-line in other situations where it is not expected.

PR c++/115200

gcc/cp/ChangeLog:

* parser.cc (cp_parser_error_1): Special-case unexpected module
directives for better diagnostics.
(cp_parser_module_declaration): Check that the module
declaration is at global scope.
(cp_parser_import_declaration): Sync error message with that in
cp_parser_error_1.

gcc/testsuite/ChangeLog:

* g++.dg/modules/mod-decl-1.C: Update error messages.
* g++.dg/modules/mod-decl-6.C: New test.
* g++.dg/modules/mod-decl-7.C: New test.
* g++.dg/modules/mod-decl-8.C: New test.

Signed-off-by: Nathaniel Shead 
Reviewed-by: Jason Merrill

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-809

2024-05-24 Thread ro at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Rainer Orth  ---
An i686-pc-linux-gnu reghunt just completed, looking for the rust OOM failures
reported in PR bootstrap/115213. This patch is the culprit:

commit fae5e6a4dfcf9270cd09c2240480860b09c2c627
Author: Andrew MacLeod 
Date:   Tue May 21 14:20:52 2024 -0400

Make gori_map a shared component.

[Bug tree-optimization/115210] Missed optimization opportunity in redundant copies for large structure

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||user202729 at protonmail dot 
com

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

[Bug tree-optimization/115210] Missed optimization opportunity in redundant copies for large structure

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/114561] [11/12 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410

2024-05-24 Thread Liam.Jackson--- via Gcc-bugs

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

--- Comment #11 from Liam Jackson  ---
Thank-you all for narrowing down and fixing this issue, and back-porting the
fix to older compilers. It is much appreciated.

[Bug c++/114562] [11/12 Regression] ICE when trying to bind rvalue reference to lvalue with comma operator and forwarding reference to pointer since r10-7410

2024-05-24 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed in 11.5/12.4/13.3/14.

[Bug c++/114561] [11/12 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410

2024-05-24 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #10 from Jason Merrill  ---
Fixed in 11.5/12.4/13.3/14.

[Bug c++/114561] [11/12 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-11446-gb35afe75674ff9f79cf9685d099bc80f10442216
Author: Jason Merrill 
Date:   Tue Apr 2 10:52:28 2024 -0400

c++: binding reference to comma expr [PR114561]

We represent a reference binding where the referent type is more qualified
by a ck_ref_bind around a ck_qual.  We performed the ck_qual and then tried
to undo it with STRIP_NOPS, but that doesn't work if the conversion is
buried in COMPOUND_EXPR.  So instead let's avoid performing that fake
conversion in the first place.

PR c++/114561
PR c++/114562

gcc/cp/ChangeLog:

* call.c (convert_like_internal): Avoid adding qualification
conversion in direct reference binding.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref10.C: New test.
* g++.dg/conversion/ref11.C: New test.

(cherry picked from commit 5d7e9a35024f065b25f61747859c7cb7a770c92b)

[Bug c++/114562] [11/12 Regression] ICE when trying to bind rvalue reference to lvalue with comma operator and forwarding reference to pointer since r10-7410

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-11446-gb35afe75674ff9f79cf9685d099bc80f10442216
Author: Jason Merrill 
Date:   Tue Apr 2 10:52:28 2024 -0400

c++: binding reference to comma expr [PR114561]

We represent a reference binding where the referent type is more qualified
by a ck_ref_bind around a ck_qual.  We performed the ck_qual and then tried
to undo it with STRIP_NOPS, but that doesn't work if the conversion is
buried in COMPOUND_EXPR.  So instead let's avoid performing that fake
conversion in the first place.

PR c++/114561
PR c++/114562

gcc/cp/ChangeLog:

* call.c (convert_like_internal): Avoid adding qualification
conversion in direct reference binding.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref10.C: New test.
* g++.dg/conversion/ref11.C: New test.

(cherry picked from commit 5d7e9a35024f065b25f61747859c7cb7a770c92b)

[Bug c++/111529] [11/12/13 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:19827831516023f2dff449af0b228b2d60190a28

commit r12-10468-g19827831516023f2dff449af0b228b2d60190a28
Author: Jason Merrill 
Date:   Fri Sep 22 12:10:11 2023 +0100

c++: unroll pragma in templates [PR111529]

We were failing to handle ANNOTATE_EXPR in tsubst_copy_and_build, leading
to
problems with substitution of any wrapped expressions.

Let's also not tell users that lambda templates are available in C++14.

PR c++/111529

gcc/cp/ChangeLog:

* parser.cc (cp_parser_lambda_declarator_opt): Don't suggest
-std=c++14 for lambda templates.
* pt.cc (tsubst_expr): Move ANNOTATE_EXPR handling...
(tsubst_copy_and_build): ...here.

gcc/testsuite/ChangeLog:

* g++.dg/ext/unroll-4.C: New test.

(cherry picked from commit 9c62af101e11e1cce573c2b3d2e18b403412dbc8)

[Bug c++/113598] [11/12/13 Regression] GCC internal compiler error since r0-124275

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:419b5e17eace9b6b985b9853db0dc1a5478375b6

commit r12-10467-g419b5e17eace9b6b985b9853db0dc1a5478375b6
Author: Jason Merrill 
Date:   Thu Jan 25 12:02:07 2024 -0500

c++: array of PMF [PR113598]

Here AGGREGATE_TYPE_P includes pointers to member functions, which is not
what we want.  Instead we should use class||array, as elsewhere in the
function.

PR c++/113598

gcc/cp/ChangeLog:

* init.cc (build_vec_init): Don't use {} for PMF.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-pmf2.C: New test.

(cherry picked from commit 136a828754ff65079a83482b49d54bd5bc64)

[Bug c++/114562] [11/12 Regression] ICE when trying to bind rvalue reference to lvalue with comma operator and forwarding reference to pointer since r10-7410

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:7076c565e22281e193aeafafbf40676426a64b75

commit r12-10466-g7076c565e22281e193aeafafbf40676426a64b75
Author: Jason Merrill 
Date:   Tue Apr 2 10:52:28 2024 -0400

c++: binding reference to comma expr [PR114561]

We represent a reference binding where the referent type is more qualified
by a ck_ref_bind around a ck_qual.  We performed the ck_qual and then tried
to undo it with STRIP_NOPS, but that doesn't work if the conversion is
buried in COMPOUND_EXPR.  So instead let's avoid performing that fake
conversion in the first place.

PR c++/114561
PR c++/114562

gcc/cp/ChangeLog:

* call.cc (convert_like_internal): Avoid adding qualification
conversion in direct reference binding.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref10.C: New test.
* g++.dg/conversion/ref11.C: New test.

(cherry picked from commit 5d7e9a35024f065b25f61747859c7cb7a770c92b)

[Bug c++/114561] [11/12 Regression] Comma operator with forwarding reference to pointer raises invalid lvalue required error since r10-7410

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:7076c565e22281e193aeafafbf40676426a64b75

commit r12-10466-g7076c565e22281e193aeafafbf40676426a64b75
Author: Jason Merrill 
Date:   Tue Apr 2 10:52:28 2024 -0400

c++: binding reference to comma expr [PR114561]

We represent a reference binding where the referent type is more qualified
by a ck_ref_bind around a ck_qual.  We performed the ck_qual and then tried
to undo it with STRIP_NOPS, but that doesn't work if the conversion is
buried in COMPOUND_EXPR.  So instead let's avoid performing that fake
conversion in the first place.

PR c++/114561
PR c++/114562

gcc/cp/ChangeLog:

* call.cc (convert_like_internal): Avoid adding qualification
conversion in direct reference binding.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/ref10.C: New test.
* g++.dg/conversion/ref11.C: New test.

(cherry picked from commit 5d7e9a35024f065b25f61747859c7cb7a770c92b)

[Bug c++/111529] [11/12/13 Regression] ICE on bool conversion in an unrolled loop condition inside template lambda nested in another template scope

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:53cdaa755de57e57ba9e787f232adc3cfde88209

commit r13-8799-g53cdaa755de57e57ba9e787f232adc3cfde88209
Author: Jason Merrill 
Date:   Fri Sep 22 12:10:11 2023 +0100

c++: unroll pragma in templates [PR111529]

We were failing to handle ANNOTATE_EXPR in tsubst_copy_and_build, leading
to
problems with substitution of any wrapped expressions.

Let's also not tell users that lambda templates are available in C++14.

PR c++/111529

gcc/cp/ChangeLog:

* parser.cc (cp_parser_lambda_declarator_opt): Don't suggest
-std=c++14 for lambda templates.
* pt.cc (tsubst_expr): Move ANNOTATE_EXPR handling...
(tsubst_copy_and_build): ...here.

gcc/testsuite/ChangeLog:

* g++.dg/ext/unroll-4.C: New test.

(cherry picked from commit 9c62af101e11e1cce573c2b3d2e18b403412dbc8)

[Bug c++/113598] [11/12/13 Regression] GCC internal compiler error since r0-124275

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

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

commit r13-8798-g5f1457841abc2fd8657a52d1371c983ac010f1cc
Author: Jason Merrill 
Date:   Thu Jan 25 12:02:07 2024 -0500

c++: array of PMF [PR113598]

Here AGGREGATE_TYPE_P includes pointers to member functions, which is not
what we want.  Instead we should use class||array, as elsewhere in the
function.

PR c++/113598

gcc/cp/ChangeLog:

* init.cc (build_vec_init): Don't use {} for PMF.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-pmf2.C: New test.

(cherry picked from commit 136a828754ff65079a83482b49d54bd5bc64)

[Bug tree-optimization/115208] [15 Regression] Memory consumption get extremely high after r15-809

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

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

[Bug bootstrap/115213] [15 regression] Excessive memory use compiling rust with 32-bit gcc

2024-05-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I am going to say this is a dup for now.

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

[Bug c++/115190] -fmodule-mapper does not accept CRLF files

2024-05-24 Thread peter0x44 at disroot dot org via Gcc-bugs

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

--- Comment #8 from Peter Damianov  ---
I have been totally unable to reproduce this outside of MSYS2, with any
compilers I built myself. The "MSYS2 MSYS" shell also doesn't have this
problem.

I can't explain why. I tried investigating, but didn't have success.

Peter@DESKTOP-1SHN9FA UCRT64 ~
$  g++ -std=c++20 -fmodules-ts -fmodule-mapper=a.modmap -E -o /dev/null -x c++
/dev/null
nul: error: failed reading mapper 'a.modmap'

Peter@DESKTOP-1SHN9FA UCRT64 ~
$ /c/Users/Peter/3D\ Objects/mydevkit/bin/g++ -B /c/Users/Peter/3D\
Objects/mydevkit/bin/  -std=c++20 -fmodules-ts -fmodule-mapper=a.modmap -E -o
/dev/null -x c++ /dev/null

Peter@DESKTOP-1SHN9FA UCRT64 ~
$ g++ -B /c/Users/Peter/3D\ Objects/mydevkit/bin/  -std=c++20 -fmodules-ts
-fmodule-mapper=a.modmap -E -o /dev/null -x c++ /dev/null
nul: error: failed reading mapper 'a.modmap'

[Bug libstdc++/115215] New: views::concat rejects non-movable references

2024-05-24 Thread hewillk at gmail dot com via Gcc-bugs

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

Bug ID: 115215
   Summary: views::concat rejects non-movable references
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

libstdc++'s views::concat always requires concat_view(rs...) to be well-formed
which does not fully conform with the wording as R does not need to satisfy
concatable when there only one pack:


#include 
#include 

int main() {
  auto r = std::views::iota(0, 5)
 | std::views::transform([](int) { return
std::format_parse_context{""}; });
  auto c = std::views::concat(r); // should be well-formed
}

https://godbolt.org/z/WG5TdsEce

[Bug c/115214] New: tree-ssa-pre.c(ICE in find_or_generate_expression, at tree-ssa-pre.c:2780)

2024-05-24 Thread jiawei at iscas dot ac.cn via Gcc-bugs

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

Bug ID: 115214
   Summary: tree-ssa-pre.c(ICE in find_or_generate_expression, at
tree-ssa-pre.c:2780)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiawei at iscas dot ac.cn
  Target Milestone: ---

We got an ICE when compile this C code use gcc-14 on RISC-V target,see
https://godbolt.org/z/WE9aGYvoo


```
#include 

static inline __attribute__(()) int vaddq_f32();
static inline __attribute__(()) int vload_tillz_f32(int nlane) {
  vint32m1_t __trans_tmp_9;
  {
int __trans_tmp_0 = nlane;
{
  vint64m1_t __trans_tmp_1;
  vint64m1_t __trans_tmp_2;
  vint64m1_t __trans_tmp_3;
  vint64m1_t __trans_tmp_4;
  if (__trans_tmp_0 == 1) {
{
  __trans_tmp_3 =
  __riscv_vslideup_vx_i64m1(__trans_tmp_1, __trans_tmp_2, 1, 2);
}
__trans_tmp_4 = __trans_tmp_2;
  }
  __trans_tmp_4 = __trans_tmp_3;
  __trans_tmp_9 = __riscv_vreinterpret_v_i64m1_i32m1(__trans_tmp_3);
}
  }
  return vaddq_f32(__trans_tmp_9);
}

char CFLOAT_add_args[3];
const int *CFLOAT_add_steps;
const int CFLOAT_steps;

__attribute__(()) void CFLOAT_add() {
  char *b_src0 = &CFLOAT_add_args[0], *b_src1 = &CFLOAT_add_args[1],
   *b_dst = &CFLOAT_add_args[2];
  const float *src1 = (float *)b_src1;
  float *dst = (float *)b_dst;
  const int ssrc1 = CFLOAT_add_steps[1] / sizeof(float);
  const int sdst = CFLOAT_add_steps[2] / sizeof(float);
  const int hstep = 4 / 2;
  vfloat32m1x2_t a;
  int len = 255;
  for (; len > 0; len -= hstep, src1 += 4, dst += 4) {
int b = vload_tillz_f32(len);
int r = vaddq_f32(a.__val[0], b);
  }
  for (; len > 0; --len, b_src0 += CFLOAT_steps,
  b_src1 += CFLOAT_add_steps[1], b_dst += CFLOAT_add_steps[2])
;
}
```

Reports as a bug following Richard Biener's suggestion
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652641.html

[Bug c++/115192] [11/12/13/14 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

2024-05-24 Thread rsandifo at gcc dot gnu.org via Gcc-bugs

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

Richard Sandiford  changed:

   What|Removed |Added

Summary|[11/12/13/14/15 regression] |[11/12/13/14 regression]
   |-O3 miscompilation on   |-O3 miscompilation on
   |x86-64 (loops with vectors  |x86-64 (loops with vectors
   |and scalars) since r11-6380 |and scalars) since r11-6380

--- Comment #11 from Richard Sandiford  ---
Fixed on trunk, will backport if there is no reported fallout.

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

2024-05-24 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r15-820-ga0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba
Author: Richard Sandiford 
Date:   Fri May 24 13:47:21 2024 +0100

vect: Fix access size alignment assumption [PR115192]

create_intersect_range_checks checks whether two access ranges
a and b are alias-free using something equivalent to:

  end_a <= start_b || end_b <= start_a

It has two ways of doing this: a "vanilla" way that calculates
the exact exclusive end pointers, and another way that uses the
last inclusive aligned pointers (and changes the comparisons
accordingly).  The comment for the latter is:

  /* Calculate the minimum alignment shared by all four pointers,
 then arrange for this alignment to be subtracted from the
 exclusive maximum values to get inclusive maximum values.
 This "- min_align" is cumulative with a "+ access_size"
 in the calculation of the maximum values.  In the best
 (and common) case, the two cancel each other out, leaving
 us with an inclusive bound based only on seg_len.  In the
 worst case we're simply adding a smaller number than before.

The problem is that the associated code implicitly assumed that the
access size was a multiple of the pointer alignment, and so the
alignment could be carried over to the exclusive end pointer.

The testcase started failing after g:9fa5b473b5b8e289b6542
because that commit improved the alignment information for
the accesses.

gcc/
PR tree-optimization/115192
* tree-data-ref.cc (create_intersect_range_checks): Take the
alignment of the access sizes into account.

gcc/testsuite/
PR tree-optimization/115192
* gcc.dg/vect/pr115192.c: New test.

[Bug other/115211] [11/12/13/14/15 regression] -frecord-gcc-switches refactoring lost list of enabled options

2024-05-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
[..]
> Ah!  Use -Q --help=optimizers (how intuititve...)

Or when invoking cc1 omit -quiet.  remember to put --help=optimziers after
optimization options.

[Bug other/115211] [11/12/13/14/15 regression] -frecord-gcc-switches refactoring lost list of enabled options

2024-05-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Richard Biener  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Richard Biener  ---
> > This was done on purpose, you can use -help=optimizers now I think.
> 
> The thread I cited rather suggested is was removed because Martin argued
> the info wasn't fully complete.  However, I don't see how something that
> is only 95% complete is worse than having nothing.

ISTR it was awkward to keep it without duplicating code and that was the
main reason citing the info is available with -[gf]record-gcc-switches ...

> --help=optimizers just documents optimization options, with no
> indication which are enabled for a given compilation.  Don't see how
> this helps.

... and also by another means that I don't remember that shows the list
of options but tells whether they are enabled or not.  Seems like
--help=optimizers indeed isn't it (or maybe it was it but it as well was
imprecise and removed ...?).

Ah!  Use -Q --help=optimizers (how intuititve...)

1 2 >

1 - 100 of 121 matches

Mail list logo