[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

--- Comment #11 from Andrew Pinski  ---
I can confirm it is also fixed on aarch64.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-18 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #10 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #9)
> I'm going to reclose this if
> I can find support for it being fixed on one more target.

So, https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805640.html
says it's fixed for power8 too, compared to the previous report, for r14-8195.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-18 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

--- Comment #9 from Hans-Peter Nilsson  ---
For cris-elf, a change in the range (known to fail, known to pass]
(r14-8193-g3340878009acfc, r14-8200-g9a5e8f9d112adb] seems to have fixed the
remaining hello-1 execution failure, so fixed by r14-8196-g3471a61ed0ddef
(being a change to the c++ modules code and the only code change outside
riscv).

Being the person that reopened the PR, I think I'm going to reclose this if I
can find support for it being fixed on one more target.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-13 Thread danglin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #8 from John David Anglin  ---
> Only partially: the "g++.dg/modules/hello-1 -std=c++2b execute"
> is still there, and was part of the regression; at least introduced at the
> same time.

Same failure is observed on hppa64-hp-hpux11.11.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-12 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #7 from Hans-Peter Nilsson  ---
(In reply to Jason Merrill from comment #6)
> But the regression is fixed.

Only partially: the "g++.dg/modules/hello-1 -std=c++2b execute"
is still there, and was part of the regression; at least introduced at the same
time.  This both for cris-elf@r14-7217-g444a31f3b354 and
powerpc64le-unknown-linux-gnu@r14-7215-g8b447fa89d
(https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805221.html).

Thus reopening.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-12 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
But the regression is fixed.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-12 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

--- Comment #5 from Jason Merrill  ---
Created attachment 57053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57053=edit
second piece

and an accompanying patch to allow P1811 redefinition of classes.  I think we
need to extend this to all redefinitions, especially with -fno-module-lazy

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-12 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

--- Comment #4 from Jason Merrill  ---
Created attachment 57052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57052=edit
more general approach WIP for GCC 15

this is the beginning of a more general approach to this issue that also
handles P1811 include-after-import.  More work will be needed.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

--- Comment #3 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:27521a2f4f7b859d5656e5bdd69d3f759ea4c23a

commit r14-7213-g27521a2f4f7b859d5656e5bdd69d3f759ea4c23a
Author: Jason Merrill 
Date:   Mon Dec 18 15:47:10 2023 -0500

c++: __class_type_info and modules [PR113038]

Doing a dynamic_cast in both TUs broke because we were declaring a new
__class_type_info in _b that conflicted with the one imported in the global
module from _a.  It seems clear to me that any new class declaration in
the global module should merge with an imported definition, but for GCC 14
let's just fix this for the specific case of __class_type_info.

PR c++/113038

gcc/cp/ChangeLog:

* name-lookup.cc (lookup_elaborated_type): Look for bindings
in the global namespace in the ABI namespace.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr106304_b.C: Add dynamic_cast.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2024-01-11 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2023-12-18 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |14.0

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2023-12-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

--- Comment #2 from Jonathan Wakely  ---
jason: seems like a simple matter of forcing the builtin declaration into the
global module

ppalka: fwiw it also works if we get rid of the implicit declaration of
__class_type_info when declaring the builtin and just use const void*
throughout the parameter list

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

2023-12-16 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-16
 Target|powerpc64le-linux-gnu   |
 Status|UNCONFIRMED |NEW
   Host|powerpc64le-linux-gnu   |
 Ever confirmed|0   |1
  Build|powerpc64le-linux-gnu   |

--- Comment #1 from Jonathan Wakely  ---
It's seen on other targets too. Patrick came up with this reduced reproducer
for it:

--- a/gcc/testsuite/g++.dg/modules/pr106304_b.C
+++ b/gcc/testsuite/g++.dg/modules/pr106304_b.C
@@ -5,4 +5,5 @@ module pr106304;

 void f(A& a) {
   as_b(a);
+  dynamic_cast();
 }

Just another latent front-end modules bug, that gets triggered by my new
library code.