[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Jason Liam  ---
(In reply to Andrew Pinski from comment #8)
Does that imply that following program is also invalid? GCC rejects the below
program but msvc accepts.

```
struct A
{
  explicit A(int = 10);
  A()= default;
};

A a = {}; //gcc rejects this but msvc accepts
```

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen5 CPU with znver5 scheduler Model

[Richard Biener]

On Sat, Feb 10, 2024 at 1:55 PM Anbazhagan, Karthiban
 wrote:
>
> [Public]
>
>
> Hi all,
>
>
>
> PFA, the patch that enables support for the next generation AMD Zen5 CPU via 
> -march=znver5 with basic znver5 scheduler Model.
>
> We may update the scheduler model going forward.
>
>
>
> Good for trunk?

I'll note that gmail flagged this as spam, in case there's no response
from maintainers
I suggest to re-send.

The patch itself looks straight forward, I'll leave review to Honza/Uros though.

I'll note we have around eight processor_type left before eventually overflowing
the m_PROCESSOR mask ...

Thanks,
Richard.

> Thanks and Regards
>
> Karthiban
>
>
>
>
>
> Resending the patch, as unable to inline the patch here.
>
> reason : awaits moderator approval
>
> Message body is too big: 601858 bytes with a limit of 400 KB
>
>

[Bug target/113537] ext should be used more for __builtin_shufflevector

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101846

--- Comment #4 from Andrew Pinski  ---
Actually part of this is the "don't care" part, which is referenced in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101846#c10 (and maybe others).
That is something I can't fix ...

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

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

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

--- Comment #9 from Florian Weimer  ---
(In reply to H.J. Lu from comment #7)
> > The __tls_get_addr call with the default approach potentially needs to solve
> > the same problem, doesn't it?
> 
> Isn't __tls_get_addr called via the PLT entry?

I'm not sure if that matters? Even if the lazy binding trampoline is active, it
won't protect the actual call.

[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Jason Liam from comment #7)
> (In reply to Andrew Pinski from comment #5)
> > std::vector 's constructor which takes std::size_t is marked as explicit.
> 
> But you're missing that the initializer list ctor is preferred/choosen over
> the size_t arg ctor. 

That is different from your original example.
This is closer to your original example:
```
#include 

struct B
{
  B(std::initializer_list);
};

struct C
{
  explicit C(int);
};


void func(B);
void func(C);

int main() {
func({ 4.2 });
}
```

here we have two calls to func, one which takes B and the other which takes C.
In the case case of copy-list-initialization, it is ambigous which is to be
constructed as copy-list-initialization for overload resolution; explicit
constructors are looked at but only an error if it was chosen. Note narrowing
is not taken into account for overload resolution too; maybe that is what you
are missing.

Again read https://wg21.link/cwg1228 which talks about this not being a defect
in the C++ standard; this is how the standard is written.

Anyways clang's bug report is https://github.com/llvm/llvm-project/issues/28016
.

>implying the the second overload is not even viable so how can it make the 
>call ambiguous.

I should note that is not have overload resolution works either.

[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Jason Liam  ---
(In reply to Andrew Pinski from comment #5)
> std::vector 's constructor which takes std::size_t is marked as explicit.

But you're missing that the initializer list ctor is preferred/choosen over the
size_t arg ctor. 

See
https://stackoverflow.com/questions/27144054/why-is-the-stdinitializer-list-constructor-preferred-when-using-a-braced-initi

I've created the following demo to show this:

```

class Foo
{
//  val_;
public:
Foo(std::initializer_list il)
{
std::cout << "initializer_list ctor" << std::endl;
}
 explicit  Foo(std::size_t val)
{
std::cout << "ctor" << std::endl;
};
};

int main()
{
Foo f = {1.1}; //all compiler use initializer list
}
```

[Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7

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

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

Sam James  changed:

   What|Removed |Added

  Attachment #57384|0   |1
is obsolete||

--- Comment #14 from Sam James  ---
Created attachment 57390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57390=edit
test.c

I'll try reducing it preprocessed now (couldn't do it before as checking w/
clang as well in the reduction script to avoid introducing UB).

[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

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

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

--- Comment #6 from Andrew Pinski  ---
I know cppreference is not the standard but it is a decent reference to start
with.

https://en.cppreference.com/w/cpp/container/vector/vector


Without the explicit, clang will also reject it as being ambiguous. As I
mentioned this is not a bug in gcc but rather a bug in clang.

[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jason Liam from comment #4)
> But which constructor is explicit here? I don't see any explicit ctor here.

std::vector 's constructor which takes std::size_t is marked as explicit.

[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

[jlame646 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Jason Liam  ---
But which constructor is explicit here? I don't see any explicit ctor here.

[Bug c++/60027] [DR1228] Problem with braced-init-lists and explicit ctors

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jlame646 at gmail dot com

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

[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Since explicit is needed, then this is a dup of bug 60027 which means GCC is
correct at rejecting this as being ambigous.  Clang does not implement
https://wg21.link/cwg1228 resolution.

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

[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Reduced to:
> ```
> struct B
> {
>   B(double);
> };
> 
> struct C
> {
>   C(int);
> };
> 
> 
> void func(B);
> void func(C);
> 
> int main() {
> func({ 4.2 });
> }
> ```

Actually C constructor should be:
  explicit  C(int);

[Bug c++/113884] GCC rejects valid program saying ambiguous call when using std::vector

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

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

--- Comment #1 from Andrew Pinski  ---
Reduced to:
```
struct B
{
  B(double);
};

struct C
{
  C(int);
};


void func(B);
void func(C);

int main() {
func({ 4.2 });
}
```

[Bug c++/113884] New: GCC rejects valid program saying ambiguous call when using std::vector

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 113884
   Summary: GCC rejects valid program saying ambiguous call when
using std::vector
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following valid program is rejected by gcc
```
#include 
#include 

struct A {
A();
};


void func(std::vector values);
void func(std::vector as);

int main() {
func({ 4.2 }); //gcc rejects this
}
```

One way to see that gcc is incorrect here is by just removing the first
overload and then gcc also starts rejecting this, implying the the second
overload is not even viable so how can it make the call ambiguous.

```
#include 
#include 

struct A {
A();
};


void func(std::vector as);

int main() {
func({ 4.2 });//now gcc also starts correctly rejecting this implying that
this is not even viable so how can it possibly make the call ambiguous 
}
```

[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #17 from Lukas Grätz  ---
(In reply to Xi Ruoyao from comment #16)
> (In reply to gooncreeper from comment #15)
> > May I suggest we just add something like __attribute__((trace)) for the
> > special abort case? Noreturn was added for code optimization after all, not
> > for backtracing.
> 
> It will break any attempts to debug an abort until the libc headers are
> updated to use __attribute__((trace)).

"any attempts"? We could simply use the gdb debugger and ignore the backtrace.
In comparison, the backtrace is a rather restricted debugging instrument.

If there are applications that really depend on GCC's backtrace, this should be
the reason to keep the current behaviour.

> 
> Note that in GCC noreturn has been added far before the WG14 _Noreturn paper
> (even this ticket predates the WG14 paper), so the rationale in the paper
> may not apply.

Backtracing functionality is highly platform dependent, so there is no surprise
that the C standard cannot guarantee anything about it.

> 
> In practice most _Noreturn functions are abort, exit, ..., i.e. they are
> only executed one time so optimizing against a cold path does not help much.
> I don't think it's a good idea to encourage people to construct some fancy
> code by a recursive _Noreturn function (why not just use a loop?!)

... and why not just if and goto? Because it is considered good programming
practice to structure source code into functions (not to long) and loops. If a
function gets too big, GCC might not optimize it well.

>  And if
> you must write such fancy code anyway IMO musttail attribute (PR83324) will
> be a better solution.

I agree.

[Bug fortran/113883] allocatable length parameter used but is undefined

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-02-12
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4

[Bug fortran/113883] allocatable length parameter used but is undefined

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

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Created attachment 57389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57389=edit
patch to fix bug

This is the patch and testcase.  I have successfully bootstrapped
and run the Fortran regression tests without issues.

[Bug fortran/113883] New: allocatable length parameter used but is undefined

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

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

Bug ID: 113883
   Summary: allocatable length parameter used but is undefined
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

All,

I stumbled across the following issue with my code.  Consider, 

! { dg-do compile }
! { dg-options "-Werror -Wall" }
module foo
   contains
  subroutine bar 
 character(len=:), allocatable :: s(:)
 call bah(s)
  end subroutine bar
end module foo

Currently, if this compiled with '-Werror -Wall' the result is

% gfcx -Wall -Werror -c gcc/testsuite/gfortran.dg/allocatable_length.f90
gcc/testsuite/gfortran.dg/allocatable_length.f90:6:46:

6 |  character(len=:), allocatable :: s(:)
  |  ^
Error: '.s' is used uninitialized [-Werror=uninitialized]
gcc/testsuite/gfortran.dg/allocatable_length.f90:5:20:

5 |   subroutine bar
  |^
note: '.s' was declared here
f951: all warnings being treated as errors

I tracked down the location where the issue occurs and Mikael suggested
the patch that ultimately fixes the issue.  I'll attach it in a follow-up.

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #35 from nightstrike  ---
(In reply to anlauf from comment #34)
> Are you sure that it finds the right new libgfortran?

Good call.  I did a make install first and re-ran it, and they all pass now. 
Sorry for the noise, this is an unfortunate aspect of the testsuite where in
many cases it will not use the just-built libraries, but instead picks up the
libraries in the install path.

[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83324
 CC||xry111 at gcc dot gnu.org

--- Comment #16 from Xi Ruoyao  ---
(In reply to gooncreeper from comment #15)
> May I suggest we just add something like __attribute__((trace)) for the
> special abort case? Noreturn was added for code optimization after all, not
> for backtracing.

It will break any attempts to debug an abort until the libc headers are updated
to use __attribute__((trace)).

Note that in GCC noreturn has been added far before the WG14 _Noreturn paper
(even this ticket predates the WG14 paper), so the rationale in the paper may
not apply.

In practice most _Noreturn functions are abort, exit, ..., i.e. they are only
executed one time so optimizing against a cold path does not help much.  I
don't think it's a good idea to encourage people to construct some fancy code
by a recursive _Noreturn function (why not just use a loop?!)  And if you must
write such fancy code anyway IMO musttail attribute (PR83324) will be a better
solution.

[PATCH] c++: Fix error recovery when redeclaring enum in different module [PR99573]

[Nathaniel Shead]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

-- >8 --

This ensures that with modules enabled, redeclaring an enum in the wrong
module or with the wrong underlying type no longer ICEs.

The patch also rearranges the order of the checks a little because I
think it's probably more important to note that you can't redeclare the
enum all before complaining about mismatched underlying types etc.

As a drive by this patch also adds some missing diagnostic groups, and
rewords the module redeclaration error message to more closely match the
wording used in other places this check is done.

PR c++/99573

gcc/cp/ChangeLog:

* decl.cc (start_enum): Reorder check for redeclaring in module.
Add missing auto_diagnostic_groups.

gcc/testsuite/ChangeLog:

* g++.dg/modules/enum-12.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/decl.cc | 31 +++---
 gcc/testsuite/g++.dg/modules/enum-12.C | 10 +
 2 files changed, 28 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/enum-12.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 3e41fd4fa31..f982b5f88de 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -16951,12 +16951,28 @@ start_enum (tree name, tree enumtype, tree 
underlying_type,
 /*tag_scope=*/TAG_how::CURRENT_ONLY,
 /*template_header_p=*/false);
 
+  /* Attempt to set the declaring module.  */
+  if (modules_p () && enumtype && TREE_CODE (enumtype) == ENUMERAL_TYPE)
+{
+  tree decl = TYPE_NAME (enumtype);
+  if (!module_may_redeclare (decl))
+   {
+ auto_diagnostic_group d;
+ error ("cannot declare %qD in different module", decl);
+ inform (DECL_SOURCE_LOCATION (decl), "previously declared here");
+ enumtype = error_mark_node;
+   }
+  else
+   set_instantiating_module (decl);
+}
+
   /* In case of a template_decl, the only check that should be deferred
  to instantiation time is the comparison of underlying types.  */
   if (enumtype && TREE_CODE (enumtype) == ENUMERAL_TYPE)
 {
   if (scoped_enum_p != SCOPED_ENUM_P (enumtype))
{
+ auto_diagnostic_group d;
  error_at (input_location, "scoped/unscoped mismatch "
"in enum %q#T", enumtype);
  inform (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (enumtype)),
@@ -16965,6 +16981,7 @@ start_enum (tree name, tree enumtype, tree 
underlying_type,
}
   else if (ENUM_FIXED_UNDERLYING_TYPE_P (enumtype) != !! underlying_type)
{
+ auto_diagnostic_group d;
  error_at (input_location, "underlying type mismatch "
"in enum %q#T", enumtype);
  inform (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (enumtype)),
@@ -16975,25 +16992,13 @@ start_enum (tree name, tree enumtype, tree 
underlying_type,
   && !same_type_p (underlying_type,
ENUM_UNDERLYING_TYPE (enumtype)))
{
+ auto_diagnostic_group d;
  error_at (input_location, "different underlying type "
"in enum %q#T", enumtype);
  inform (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (enumtype)),
  "previous definition here");
  underlying_type = NULL_TREE;
}
-
-  if (modules_p ())
-   {
- if (!module_may_redeclare (TYPE_NAME (enumtype)))
-   {
- error ("cannot define %qD in different module",
-TYPE_NAME (enumtype));
- inform (DECL_SOURCE_LOCATION (TYPE_NAME (enumtype)),
- "declared here");
- enumtype = error_mark_node;
-   }
- set_instantiating_module (TYPE_NAME (enumtype));
-   }
 }
 
   if (!enumtype || TREE_CODE (enumtype) != ENUMERAL_TYPE
diff --git a/gcc/testsuite/g++.dg/modules/enum-12.C 
b/gcc/testsuite/g++.dg/modules/enum-12.C
new file mode 100644
index 000..57eeb85d92a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/enum-12.C
@@ -0,0 +1,10 @@
+// PR c++/99573
+// { dg-additional-options "-fmodules-ts" }
+// { dg-module-cmi !foo }
+
+export module foo;
+namespace std {
+  enum class align_val_t : decltype(sizeof(int)) {};  // { dg-error "different 
module" }
+}
+
+// { dg-prune-output "not writing module" }
-- 
2.43.0

[Bug target/113882] New: V4SF->V4HI could be implemented using V4SF->V4SI and then truncation to V4HI

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

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

Bug ID: 113882
   Summary: V4SF->V4HI could be implemented using V4SF->V4SI and
then truncation to V4HI
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
void f(short *a, float *b)
{
a[0] = b[0];
a[1] = b[1];
a[2] = b[2];
a[3] = b[3];
}

void f1(float *a, short *b)
{
a[0] = b[0];
a[1] = b[1];
a[2] = b[2];
a[3] = b[3];
}
```
GCC can SLP f1 (which does V4SF->V4HI) but not f1.
LLVM can though:
```
f:
ldr q0, [x1]
fcvtzs  v0.4s, v0.4s
xtn v0.4h, v0.4s
str d0, [x0]
ret
```

[Bug sanitizer/113881] New: Multiple testsuite failures with gfortran on FreeBSD

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

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

Bug ID: 113881
   Summary: Multiple testsuite failures with gfortran on FreeBSD
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

% gmake bootstrap
% cd gcc
% gmake check-fortran
...

Inspection of testsuite/gfortran/gfortran.sum on x86_64-*-freebsd shows

PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O0  (test for
excess errors)
FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O0  execution
test
PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O1  (test for
excess errors)
FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O1  execution
test
PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O2  (test for
excess errors)
FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O2  execution
test
PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
execution test
PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O3 -g  (test
for excess errors)
FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -O3 -g 
execution test
PASS: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -Os  (test for
excess errors)
FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address  -Os  execution
test
PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O0  (test for excess
errors)
FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O0  execution test
PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O1  (test for excess
errors)
FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O1  execution test
PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O2  (test for excess
errors)
FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O2  execution test
PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
execution test
PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O3 -g  (test for
excess errors)
FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -O3 -g  execution
test
PASS: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -Os  (test for excess
errors)
FAIL: gfortran.dg/asan/pr110415-2.f90 -fsanitize=address  -Os  execution test
PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O0  (test for excess
errors)
FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O0  execution test
PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O1  (test for excess
errors)
FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O1  execution test
PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O2  (test for excess
errors)
FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O2  execution test
PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
execution test
PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O3 -g  (test for
excess errors)
FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -O3 -g  execution
test
PASS: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -Os  (test for excess
errors)
FAIL: gfortran.dg/asan/pr110415-3.f90 -fsanitize=address  -Os  execution test

Digging into testsuite/gfortran/gfortran.log the failure are all of the form

spawn -ignore SIGHUP
/usr/home/kargl/gcc/obj/gcc/testsuite/gfortran/../../gfortran
-B/usr/home/kargl/gcc/obj/gcc/testsuite/gfortran/../../
-B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libgfortran/
/home/kargl/gcc/gcc/gcc/testsuite/gfortran.dg/asan/pointer_assign_16.f90
-fdiagnostics-plain-output
-B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libsanitizer/
-B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libsanitizer/asan/
-B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libsanitizer/asan/.libs
-B/usr/home/kargl/gcc/obj/x86_64-unknown-freebsd15.0/./libstdc++-v3/src/.libs
-fsanitize=address -g

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

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

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

--- Comment #34 from anlauf at gcc dot gnu.org ---
(In reply to nightstrike from comment #33)
> I modified the test further to just print which ones would have called stop.
> Almost, but not all, do:
> 
>  stop 2
>  stop 3
>  stop 4
>  stop 7
>  stop 8
>  stop 9
>  stop 10
>  stop 11
>  stop 12
>  stop 13
>  stop 15
>  stop 20
>  stop 21
>  stop 22
>  stop 23
>  stop 24
>  stop 25
>  stop 26
>  stop 27
>  stop 28
>  stop 29
>  stop 30
>  stop 31
>  stop 32

Are you sure that it finds the right new libgfortran?

[Bug target/113880] New: V2SF->V2DF conversion pattern seems to be missing

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

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

Bug ID: 113880
   Summary: V2SF->V2DF conversion pattern seems to be missing
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

Take:
```
void f(float *a, double *b)
{
b[0] = a[0];
b[1] = a[1];
}
```

This should be optimized to:
```
ldr d31, [x0]
fcvtv31.2d, v31.2s
stp q31, [x1]
ret
```

But V2SF->V2DF conversion does not exist.

This is in a similar way V4HF->V4SF is missing (PR 113869).

gcc-14-20240211 is now available

[GCC Administrator via Gcc]

Snapshot gcc-14-20240211 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/14-20240211/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 19a647bd72632dd5829eddd0d29b04be4fcb864f

You'll find:

 gcc-14-20240211.tar.xz   Complete GCC

  SHA256=701928f114f807130e512aa5a1536fbe3b060e75f2891cbb4de2d760dc50dcd1
  SHA1=741c0a2b50146e54647b1dd3fb8dcbbfe07ac849

Diffs from 14-20240204 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-14
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #33 from nightstrike  ---
I modified the test further to just print which ones would have called stop. 
Almost, but not all, do:

 stop 2
 stop 3
 stop 4
 stop 7
 stop 8
 stop 9
 stop 10
 stop 11
 stop 12
 stop 13
 stop 15
 stop 20
 stop 21
 stop 22
 stop 23
 stop 24
 stop 25
 stop 26
 stop 27
 stop 28
 stop 29
 stop 30
 stop 31
 stop 32

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #32 from nightstrike  ---
(In reply to anlauf from comment #31)
> (In reply to nightstrike from comment #30)
> > (In reply to GCC Commits from comment #29)
> > > * gfortran.dg/pr111022.f90: New test.
> > 
> > This new test fails of x64 mingw.
> 
> Can you be more specific?

Sure, it exits with STOP 2, which is the following:

  write(buffer,"(EN0.3E0)") 6.660_4
  if (buffer.ne."6.660E+0") stop 2

I modified that as:

  write(buffer,"(EN0.3E0)") 6.660_4
  if (buffer.ne."6.660E+0") then 
print *, buffer
stop 2
  end if

And now it prints:

 6.660   
STOP 2


So I guess it's losing the E+0 from the string?

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

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

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

--- Comment #31 from anlauf at gcc dot gnu.org ---
(In reply to nightstrike from comment #30)
> (In reply to GCC Commits from comment #29)
> > * gfortran.dg/pr111022.f90: New test.
> 
> This new test fails of x64 mingw.

Can you be more specific?

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #30 from nightstrike  ---
(In reply to GCC Commits from comment #29)
> * gfortran.dg/pr111022.f90: New test.

This new test fails of x64 mingw.

[Bug target/113872] PERM<{0},a,{3,4,5,6}> is not producing SHL (for little-endian) and USHR for big-endian

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-Februar
   ||y/645379.html

--- Comment #2 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645379.html

[PATCH] aarch64: Improve PERM<{0}, a, ...> (64bit) by adding whole vector shift right [PR113872]

[Andrew Pinski]

The backend currently defines a whole vector shift left for 64bit vectors, 
adding the
shift right can also improve code for some PERMs too. So this adds that pattern.

I added a testcase for the shift left also. I also fixed the instruction 
template
there which was using a space instead of a tab after the instruction.

Built and tested on aarch64-linux-gnu.

PR target/113872

gcc/ChangeLog:

* config/aarch64/aarch64-simd.md (vec_shr_): Use 
tab instead of space after
the instruction in the template.
(vec_shl_): New pattern
* config/aarch64/iterators.md (unspec): Add UNSPEC_VEC_SHL

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/perm_zero-1.c: New test.
* gcc.target/aarch64/perm_zero-2.c: New test.

Signed-off-by: Andrew Pinski 
---
 gcc/config/aarch64/aarch64-simd.md | 18 --
 gcc/config/aarch64/iterators.md|  1 +
 gcc/testsuite/gcc.target/aarch64/perm_zero-1.c | 15 +++
 gcc/testsuite/gcc.target/aarch64/perm_zero-2.c | 15 +++
 4 files changed, 47 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/perm_zero-1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/perm_zero-2.c

diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index f8bb973a278..0d2f1ea3902 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -1592,9 +1592,23 @@ (define_insn "vec_shr_"
   "TARGET_SIMD"
   {
 if (BYTES_BIG_ENDIAN)
-  return "shl %d0, %d1, %2";
+  return "shl\t%d0, %d1, %2";
 else
-  return "ushr %d0, %d1, %2";
+  return "ushr\t%d0, %d1, %2";
+  }
+  [(set_attr "type" "neon_shift_imm")]
+)
+(define_insn "vec_shl_"
+  [(set (match_operand:VD 0 "register_operand" "=w")
+(unspec:VD [(match_operand:VD 1 "register_operand" "w")
+   (match_operand:SI 2 "immediate_operand" "i")]
+  UNSPEC_VEC_SHL))]
+  "TARGET_SIMD"
+  {
+if (BYTES_BIG_ENDIAN)
+  return "ushr\t%d0, %d1, %2";
+else
+  return "shl\t%d0, %d1, %2";
   }
   [(set_attr "type" "neon_shift_imm")]
 )
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 99cde46f1ba..3aebe9cf18a 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -758,6 +758,7 @@ (define_c_enum "unspec"
 UNSPEC_PMULL; Used in aarch64-simd.md.
 UNSPEC_PMULL2   ; Used in aarch64-simd.md.
 UNSPEC_REV_REGLIST  ; Used in aarch64-simd.md.
+UNSPEC_VEC_SHL  ; Used in aarch64-simd.md.
 UNSPEC_VEC_SHR  ; Used in aarch64-simd.md.
 UNSPEC_SQRDMLAH ; Used in aarch64-simd.md.
 UNSPEC_SQRDMLSH ; Used in aarch64-simd.md.
diff --git a/gcc/testsuite/gcc.target/aarch64/perm_zero-1.c 
b/gcc/testsuite/gcc.target/aarch64/perm_zero-1.c
new file mode 100644
index 000..3c8f0591a2f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/perm_zero-1.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2"  } */
+/* PR target/113872 */
+/* For 64bit vectors, PERM with a constant 0 should produce a shift instead of 
the ext instruction. */
+
+#define vect64 __attribute__((vector_size(8)))
+
+void f(vect64  unsigned short *a)
+{
+  *a = __builtin_shufflevector((vect64 unsigned short){0},*a, 3,4,5,6);
+}
+
+/* { dg-final { scan-assembler-times "ushr\t" 1 { target aarch64_big_endian } 
} } */
+/* { dg-final { scan-assembler-times "shl\t" 1 { target aarch64_little_endian 
} } } */
+/* { dg-final { scan-assembler-not "ext\t"  } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/perm_zero-2.c 
b/gcc/testsuite/gcc.target/aarch64/perm_zero-2.c
new file mode 100644
index 000..970e428f832
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/perm_zero-2.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2"  } */
+/* PR target/113872 */
+/* For 64bit vectors, PERM with a constant 0 should produce a shift instead of 
the ext instruction. */
+
+#define vect64 __attribute__((vector_size(8)))
+
+void f(vect64  unsigned short *a)
+{
+  *a = __builtin_shufflevector(*a, (vect64 unsigned short){0},3,4,5,6);
+}
+
+/* { dg-final { scan-assembler-times "shl\t" 1 { target aarch64_big_endian } } 
} */
+/* { dg-final { scan-assembler-times "ushr\t" 1 { target aarch64_little_endian 
} } } */
+/* { dg-final { scan-assembler-not "ext\t"  } } */
-- 
2.43.0

[Bug c++/113854] the expression 'is_invocable_v ... evaluated to 'false'

[f.heckenbach--- via Gcc-bugs]

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

--- Comment #4 from Frank Heckenbach  ---
(In reply to Jonathan Wakely from comment #1 and #2)

> [...] than to get errors deep inside an instantiation stack.

But they are deep in the stack; maybe not an instantiation stack, but a
requires stack or whatever you call it. Anyway, the text is much longer than
that for plain std::find_if.

> And those are not library internals, they're the public concepts defined in
> the standard.

is:invocable_v is standard, the rest seems to be full of __library _Internals.
Perhaps I wasn't clear, that's what I'm referring to. Apart from the last line
and a few others, most of the messages are not meaningful to a mere user.

> You can look them up to see what they mean, but the problem
> boils down to what's shown at the end: your predicate can't be used with
> that argument type.
> 
> I think that's actually a more accurate description of the problem than
> telling you that a deleted copy constructor can't be used. We've just been
> conditioned by years of bad errors to know what it means. But really what
> you're trying to do is call a function, not copy a unique_ptr.

Those messages may not be optimal, and perhaps we've actually been conditioned
in a way, but at least I've learned to understand what they mean. Deleted
copy-constructor, sure, it's about non-copyable types, I have something to go
on. Whereas the concepts message basically tells me I can't call it because I
can't invoke it.

In a simple case like this, it's clear why, but if i is not just a unique_ptr,
but a struct containing one among several other members (as was the case in my
actual code), it will be less obvious. And if the function takes more than one
argument, there will be no indication which one is the problem, whereas the
std::find_if message at least says "argument 1".

Also, the message "the expression 'is_invocable_v<_Fn, _Args ...> [with _Fn =
main::._anon_116&; _Args = {std::unique_ptr
>&}]'" IMHO reads more like a text puzzle. (This is a more general issue,
should I file another bug or two for it?)

a) It introduces 3 new identifiers, resolves 2 of them right after and the last
one not at all.

b) It lists default parameters the user doesn't really care about. I get that
gcc at this point probably doesn't know whether the parameters were defaulted
or specified (and happened to match the default, which seems unlikely). It
would be a big improvement if gcc could simplify that message to something like
this:

is_invocable_v<[] (auto), std::unique_ptr> is required, but false

Please note: I'm not trying to be difficult here. I'm actually having trouble
understanding these kinds of messages. Finding the actual (see above) relevant
messages and puzzling them together now often takes more time than ignoring
them altogether and analyzing the code myself. That's why I said "something's
wrong here" would be as good a message. :(

[committed] Fix gcc.c-torture/execute/ieee/cdivchkf.c on hpux

[John David Anglin]

Tested on hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu.
Committed to trunk.

Dave
---

Fix gcc.c-torture/execute/ieee/cdivchkf.c on hpux

2024-02-11  John David Anglin  

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/ieee/cdivchkf.c: Use ilogb and
__builtin_fmax instead of ilogbf and __builtin_fmaxf.

diff --git a/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkf.c 
b/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkf.c
index adf1ed91dc7..86ef69f8771 100644
--- a/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkf.c
@@ -8,7 +8,7 @@
 extern void abort (void);
 extern void exit (int);
 
-extern int ilogbf (float);
+extern int ilogb (double);
 int match (float _Complex, float _Complex);
 
 #define SMALL FLT_MIN
@@ -22,7 +22,8 @@ int match (float _Complex, float _Complex);
 int match (float _Complex c, float _Complex z)
 {
   float rz, iz, rc, ic;
-  float rerr, ierr, rmax;
+  float rerr, ierr;
+  double rmax;
   int biterr;
   rz = __real__ z;
   iz = __imag__ z;
@@ -54,11 +55,11 @@ int match (float _Complex c, float _Complex z)
 {
   ierr = __builtin_fabsf (iz - ic) / SMALL;
 }
-  rmax = __builtin_fmaxf(rerr, ierr);
+  rmax = __builtin_fmax (rerr, ierr);
   biterr = 0;
   if ( rmax != 0.0)  
 {
-  biterr = ilogbf (rmax) + MAXBIT + 1;
+  biterr = ilogb (rmax) + MAXBIT + 1;
 }
 
   if (biterr >= ERRLIM)


signature.asc
Description: PGP signature

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

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

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

--- Comment #8 from Jakub Jelinek  ---
E.g.
https://sourceware.org/legacy-ml/binutils/2005-09/msg00184.html
says
The functions defined above use custom calling conventions that
require them to preserve any registers they modify.  This penalizes
the case that requires dynamic TLS, since it must preserve all
call-clobbered registers before calling __tls_get_addr(), but it is
optimized for the most common case of static TLS, and also for the
case in which the code generated by the compiler can be relaxed by the
linker to a more efficient access model: being able to assume no
registers are clobbered by the call tends to improve register
allocation.  Also, the function that handles the dynamic TLS case will
most often be able to avoid calling __tls_get_addr(), thus potentially
avoiding the need for preserving registers.

[Bug libgomp/113843] FAIL: libgomp.c/alloc-pinned-1.c execution test

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
Fixed on trunk.

[committed] libgomp: Define config_path for hppa*-*-linux*

[John David Anglin]

Tested on hppa-unknown-linux-gnu.  Committed to trunk.

Dave
---

libgomp: Define config_path for hppa*-*-linux*

2024-02-11  John David Anglin  

libgomp/ChangeLog:

PR libgomp/113843
* configure.tgt (hppa*-*-linux*): Define config_path.

diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
index 2cd7272fcd8..46af75f978f 100644
--- a/libgomp/configure.tgt
+++ b/libgomp/configure.tgt
@@ -52,6 +52,10 @@ if test x$enable_linux_futex = xyes; then
config_path="linux posix"
;;
 
+hppa*-*-linux*)
+   config_path="linux posix"
+   ;;
+
 ia64*-*-linux*)
config_path="linux/ia64 linux posix"
;;


signature.asc
Description: PGP signature

[Bug libgomp/113843] FAIL: libgomp.c/alloc-pinned-1.c execution test

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:167798a4d29a4e6d2d304c8b13256f3d431fdeaf

commit r14-8921-g167798a4d29a4e6d2d304c8b13256f3d431fdeaf
Author: John David Anglin 
Date:   Sun Feb 11 20:23:14 2024 +

libgomp: Define config_path for hppa*-*-linux*

2024-02-11  John David Anglin  

libgomp/ChangeLog:

PR libgomp/113843
* configure.tgt (hppa*-*-linux*): Define config_path.

Re: [PATCH] Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268]

[Harald Anlauf]

Hi Alex,

I've been unable to apply your patch to my local trunk, likely due to
whitespace issues my newsreader handles differently from your site.
I see it inline instead of attached.

A few general remarks:

Please follow the general recommendation regarding style if possible,
see https://www.gnu.org/prep/standards/standards.html#Formatting
regarding formatting/whitespace use (5.1) and comments (5.2)

Also, when an error message text spans multiple lines, please place the
whitespace at the end of a line, not at the beginning of the new one:


+  if ( resolve_bindings_derived->attr.pdt_template &&
+   !gfc_pdt_is_instance_of(resolve_bindings_derived,
+   CLASS_DATA(me_arg)->ts.u.derived))
+{
+  gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
+" the parametric derived-type %qs", me_arg->name, proc->name,


  gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of "
 "the parametric derived-type %qs", me_arg->name,
proc->name,


+me_arg->name, , resolve_bindings_derived->name);
+  goto error;
+}


The following change is almost unreadable: the lnegthy comment is split
over three parts and almost hides the code.  Couldn't this be combined
into one comment before the function?


diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index fddf68f8398..11f4bac0415 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -5172,6 +5172,35 @@ gfc_type_is_extension_of (gfc_symbol *t1, gfc_symbol
*t2)
return gfc_compare_derived_types (t1, t2);
  }

+/* Check if a parameterized derived type t2 is an instance of a PDT
template t1 */
+
+bool
+gfc_pdt_is_instance_of(gfc_symbol *t1, gfc_symbol *t2)
+{
+  if ( !t1->attr.pdt_template || !t2->attr.pdt_type )
+return false;
+
+  /*
+in decl.cc, gfc_get_pdt_instance, a pdt instance is given a 3
character prefix "Pdt", followed
+by an underscore list of the kind parameters, up to a maximum of 8.
+
+So to check if a PDT Type corresponds to the template, extract the
core derive_type name,
+and then see if it is type compatible by name...
+
+For example:
+
+Pdtf_2_2 -> extract out the 'f' -> see if the derived type 'f' is
compatible with symbol t1
+  */
+
+  // Starting at index 3 of the string in order to skip past the 'Pdt'
prefix
+  // Also, here the length of the template name is used in order to avoid
the
+  // kind parameter suffixes that are placed at the end of PDT instance
names.
+  if ( !(strncmp(&(t2->name[3]), t1->name, strlen(t1->name)) == 0) )
+return false;
+
+  return true;
+}
+

  /* Check if two typespecs are type compatible (F03:5.1.1.2):
 If ts1 is nonpolymorphic, ts2 must be the same type.


The following testcase tests for errors.  I tried Intel and NAG on it
after commenting the 'contains' section of the type desclaration.
Both complained about subroutine deferred_len_param, e.g.

Intel:
A colon may only be used as a type parameter value in the declaration of
an object that has the POINTER or ALLOCATABLE attribute.   [THIS]
class(param_deriv_type(:)), intent(inout) :: this

NAG:
Entity THIS of type PARAM_DERIV_TYPE(A=:) has a deferred length type
parameter but is not a data pointer or allocatable

Do we detect this after your patch?  If the answer is yes,
can we add another subroutine where we check for this error?
(the dg-error suggests we only expect assumed len type parameters.)
If no, maybe add a comment in the testcase that this subroutine
may need updating later.


diff --git a/gcc/testsuite/gfortran.dg/pdt_37.f03
b/gcc/testsuite/gfortran.dg/pdt_37.f03
new file mode 100644
index 000..68d376fad25
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pdt_37.f03
@@ -0,0 +1,34 @@
+! { dg-do compile }
+!
+! Tests the fixes for PR82943.
+!
+! This test focuses on the errors produced by incorrect LEN parameters for
dummy
+! arguments of PDT Typebound Procedures.
+!
+! Contributed by Alexander Westbrooks  
+!
+module test_len_param
+
+   type :: param_deriv_type(a)
+   integer, len :: a
+   contains
+   procedure :: assumed_len_param   ! Good. No error expected.
+   procedure :: deferred_len_param  ! { dg-error "All LEN type
parameters of the passed dummy argument" }
+   procedure :: fixed_len_param ! { dg-error "All LEN type
parameters of the passed dummy argument" }
+   end type
+
+contains
+subroutine assumed_len_param(this)
+   class(param_deriv_type(*)), intent(inout) :: this
+end subroutine
+
+subroutine deferred_len_param(this)
+class(param_deriv_type(:)), intent(inout) :: this
+end subroutine
+
+subroutine fixed_len_param(this)
+class(param_deriv_type(10)), intent(inout) :: this
+end subroutine
+
+end module
+

[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow

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

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

--- Comment #8 from uecker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to uecker from comment #6)
> > My idea would be to explicitly add either traps or __builtin_unreachable
> > whenever there is UB that can be checked for in the C FE, and not add
> > sanitizer calls (that may return). Just a lightweight tool for safety that
> > needs no run-time and and be activated in production because it is optimized
> > well.
> 
> Something that traps is -fsanitize=undefined -fsanitize-trap=undefined (or
> selected sanitizers), that doesn't need any runtime.  And it is still very
> costly, it isn't lightweight, and it severely prevents optimizations.
> Something that would add conditional __builtin_unreachable would be useless,
> that is already implied from the operations.

Sure, but -fsanitize=undefined -fsanitize-trap=undefined does optimize much
worse than directly adding the overflow checks (as this and other examples
show) and also sometimes does not have quite the ideal semantics because of
upstream sanitizer library dependency. I wouldn't mind if it could be fixed but
its complexity seems to make it unnecessary hard.

[Bug tree-optimization/113879] New: missed optimization - not exploiting known range of integers

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 113879
   Summary: missed optimization - not exploiting known range of
integers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

This is similar to PR105855 but without sanitizer.

In the following example the loop is not vectorized because  the overflow check
(which is not needed) is not removed.  It works when adding the first check
before the loop.  But the information about j < INT_MAX can be derived directly
from j < i + 4. 

void f(int i, float * restrict a, float * restrict b) 
{   
#if 0
if (INT_MAX - 4 < i)
__builtin_unreachable();
#endif
for (int j = i; j < i + 4; ) {
a[j] = b[j] + 1.;
#if 1
if (INT_MAX - 1 < j)
__builtin_trap();
#endif 
j++;
}
}

https://godbolt.org/z/xnEbh5zfv

Re: [PATCH] testsuite: Update test case to comply with GCC14 changes

[Torbjorn SVENSSON]

On 2024-02-11 20:01, Mike Stump wrote:

On Feb 10, 2024, at 7:21 AM, Torbjörn SVENSSON  
wrote:


I have confirmed that this updated pr97969.c file still hangs with
gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969.

Ok for trunk?


Ok.


Pushed as f85450819414700a7883a7de128b03f655f43d44.

[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization

[goon.pri.low at gmail dot com via Gcc-bugs]

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

gooncreeper  changed:

   What|Removed |Added

 CC||goon.pri.low at gmail dot com

--- Comment #15 from gooncreeper  ---
May I suggest we just add something like __attribute__((trace)) for the special
abort case? Noreturn was added for code optimization after all, not for
backtracing.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Florian Weimer from comment #6)
> > (In reply to H.J. Lu from comment #4)
> > > (In reply to H.J. Lu from comment #3)
> > > > Created attachment 57385 [details]
> > > > A patch
> > > > 
> > > > Try this.
> > > 
> > > This doesn't work properly.  To work around in ld.so, _dl_tlsdesc_dynamic
> > > needs to save and restore ALL registers, which can be expensive.
> 
> Why doesn't this work properly? Is it possible to make it work with a
> different approach?

Clobber must be attached to TLS descriptor call insn.

> The __tls_get_addr call with the default approach potentially needs to solve
> the same problem, doesn't it?

Isn't __tls_get_addr called via the PLT entry?

> (In reply to Jakub Jelinek from comment #5)
> > Or it could be compiled with options to make sure it doesn't use vector
> > registers etc., and only save/restore if it needs to call into some code
> > where libc can't afford that (say allocate memory).
> 
> We currently call into malloc, which could be a replacement malloc. If GCC
> cannot be fixed, full context switch or elimination of the slow path are our
> best options for a glibc-side fix.

We should open a glibc bug.  I am working on the glibc fix.

[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow

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

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to uecker from comment #6)
> My idea would be to explicitly add either traps or __builtin_unreachable
> whenever there is UB that can be checked for in the C FE, and not add
> sanitizer calls (that may return). Just a lightweight tool for safety that
> needs no run-time and and be activated in production because it is optimized
> well.

Something that traps is -fsanitize=undefined -fsanitize-trap=undefined (or
selected sanitizers), that doesn't need any runtime.  And it is still very
costly, it isn't lightweight, and it severely prevents optimizations.
Something that would add conditional __builtin_unreachable would be useless,
that is already implied from the operations.

[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow

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

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

--- Comment #6 from uecker at gcc dot gnu.org ---

My idea would be to explicitly add either traps or __builtin_unreachable
whenever there is UB that can be checked for in the C FE, and not add sanitizer
calls (that may return). Just a lightweight tool for safety that needs no
run-time and and be activated in production because it is optimized well.

[Bug target/113625] Interesting behavior with and without -mcpu=generic

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

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

--- Comment #3 from Andrew Pinski  ---
I should note that gcc.target/aarch64 tests are explicitly tested with
-mtune=generic ...

Re: [PATCH] i386, testsuite: adjust asm patterns

[Mike Stump]

On Feb 10, 2024, at 10:07 AM, FX Coudert  wrote:
> 
> The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is 
> partly because symbols are prefixed with underscore, and also because the 
> order of operands in the addition is reversed (but I think it’s valid still). 
> The code generated is this:
> 
> _func:
> LFB0:
>pushq   %rbp
> LCFI0:
>movq%rsp, %rbp
> LCFI1:
> # 8 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" 1
>@ _func
> # 0 "" 2
> # 9 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" 1
>@ 4+_var
> # 0 "" 2
>nop
>popq%rbp
> LCFI2:
>ret
> 
> 
> 
> I’m adjusting the pattern accordingly.
> OK to push?

Ok.

Re: [PATCH] testsuite: Update test case to comply with GCC14 changes

[Mike Stump]

On Feb 10, 2024, at 7:21 AM, Torbjörn SVENSSON  
wrote:
> 
> I have confirmed that this updated pr97969.c file still hangs with
> gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969.
> 
> Ok for trunk?

Ok.

[Bug fortran/113866] ice in generic_simplify_COND_EXPR

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Argument passing and the handling of optional arguments differs for bind(c)
procedures from regular ones.  For character, the length is not passed as
a hidden argument but in the CFI descriptor.

Tentative partial fix for comment#1:

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 67abca9f6ba..42ef1cd271d 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7270,7 +7271,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 an intrinsic subroutine, however, fsym is NULL, but we might still
 have an optional argument, so we proceed to the substitution
 just in case.  */
-  if (e && (fsym == NULL || fsym->attr.optional))
+  if (e && (fsym == NULL || fsym->attr.optional)
+ && !sym->attr.is_bind_c)
{
  /* If an optional argument is itself an optional dummy argument,
 check its presence and substitute a null if absent.  This is

Likely incomplete; needs checking using variations of dummy and actual args.

[Bug c++/98531] [modules] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

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

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

--- Comment #24 from John David Anglin  ---
Maybe there are multiple problems:

FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++17 (test for excess errors)
Excess errors:
/usr/include/oneapi/tbb/task_group.h:465:11: error: 'template
tbb::detail::d1::task*
tbb::detail::d1::function_task::execute(tbb::detail::d1::execution_data&)'
references internal linkage entity 'template tbb::detail::d1::task*
tbb::detail::d2::{anonymous}::task_ptr_or_nullptr(F&&)'
/usr/include/oneapi/tbb/task_group.h:494:11: error: 'template
tbb::detail::d1::task*
tbb::detail::d1::function_stack_task::execute(tbb::detail::d1::execution_data&)'
references internal linkage entity 'template tbb::detail::d1::task*
tbb::detail::d2::{anonymous}::task_ptr_or_nullptr(F&&)'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to write compiled module: Bad file data

FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)

FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++17 (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to read compiled module: No such file or directory
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.

FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++17 (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to read compiled module: No such file or directory
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.

FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2a (test for excess errors)
Excess errors:
/usr/include/oneapi/tbb/task_group.h:465:11: error: 'template
tbb::detail::d1::task*
tbb::detail::d1::function_task::execute(tbb::detail::d1::execution_data&)'
references internal linkage entity 'template tbb::detail::d1::task*
tbb::detail::d2::{anonymous}::task_ptr_or_nullptr(F&&)'
/usr/include/oneapi/tbb/task_group.h:494:11: error: 'template
tbb::detail::d1::task*
tbb::detail::d1::function_stack_task::execute(tbb::detail::d1::execution_data&)'
references internal linkage entity 'template tbb::detail::d1::task*
tbb::detail::d2::{anonymous}::task_ptr_or_nullptr(F&&)'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to write compiled module: Bad file data

FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)

FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to read compiled module: No such file or directory
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.

FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2a (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to read compiled module: No such file or directory
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.

FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2b (test for excess errors)
Excess errors:
/usr/include/oneapi/tbb/task_group.h:465:11: error: 'template
tbb::detail::d1::task*
tbb::detail::d1::function_task::execute(tbb::detail::d1::execution_data&)'
references internal linkage entity 'template tbb::detail::d1::task*
tbb::detail::d2::{anonymous}::task_ptr_or_nullptr(F&&)'
/usr/include/oneapi/tbb/task_group.h:494:11: error: 'template
tbb::detail::d1::task*
tbb::detail::d1::function_stack_task::execute(tbb::detail::d1::execution_data&)'
references internal linkage entity 'template tbb::detail::d1::task*
tbb::detail::d2::{anonymous}::task_ptr_or_nullptr(F&&)'
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to write compiled module: Bad file data

FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)

FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to read compiled module: No such file or directory
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: fatal
error: returning to the gate for a mechanical issue
compilation terminated.

FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error:
failed to read compiled module: No such 

[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow

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

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

--- Comment #5 from Jakub Jelinek  ---
Different instrumentations are done at different times.
Some ubsan instrumentations are already done in the FEs (e.g. shifts, division,
...), others are added in the ubsan pass (the idea is that catching up all the
spots where the FE emits e.g. undefined overflow additions etc. is really hard,
unlike the shifts or divisions there are hundreds of spots and we want to catch
even what is added e.g. during gimplification).  Still, the ubsan pass is
fairly early.
asan is far later, ditto tsan.
The warning case wouldn't get better by instrumenting
additions/subtractions/multiplications already in the FEs, it would be exactly
the same.

[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow

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

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

--- Comment #4 from uecker at gcc dot gnu.org ---


Would it make sense to add the instrumentation earlier? Then it could be
optimized as usual which may give better results. 

Just adding a test explicitly shows that this works:
https://godbolt.org/z/av15nheTG

Anyway, I am generally not super convinced about how the sanitizers (bloated
library, unfortunate interaction with warnings, missing cases, poor
optimization...) 

I am somewhat tempted to try putting a light-weight instrumentation directly
into the C FE. That does not seem to hard and would avoid all those problems.
But I am probably missing something  And I have no idea whether something
like this would be acceptable to GCC.

[Bug c++/111224] modules: xtreme-header-1_a.H etc. ICE (in core_vals, at cp/module.cc:6108) on AArch64 with SVE types

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

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

--- Comment #6 from Andrew Pinski  ---
case POLY_INT_CST:
  gcc_unreachable (); /* Not supported in C++.  */


That is definitely not true. POLY_INT_CST can be created via target builtins
even.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

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

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

--- Comment #6 from Florian Weimer  ---
> (In reply to H.J. Lu from comment #4)
> > (In reply to H.J. Lu from comment #3)
> > > Created attachment 57385 [details]
> > > A patch
> > > 
> > > Try this.
> > 
> > This doesn't work properly.  To work around in ld.so, _dl_tlsdesc_dynamic
> > needs to save and restore ALL registers, which can be expensive.

Why doesn't this work properly? Is it possible to make it work with a different
approach?

The __tls_get_addr call with the default approach potentially needs to solve
the same problem, doesn't it?

(In reply to Jakub Jelinek from comment #5)
> Or it could be compiled with options to make sure it doesn't use vector
> registers etc., and only save/restore if it needs to call into some code
> where libc can't afford that (say allocate memory).

We currently call into malloc, which could be a replacement malloc. If GCC
cannot be fixed, full context switch or elimination of the slow path are our
best options for a glibc-side fix.

[Bug c++/111224] modules: xtreme-header-1_a.H etc. ICE (in core_vals, at cp/module.cc:6108) on AArch64 with SVE types

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||pinskia at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-11

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

[Bug c++/98531] [modules] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #23 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #22)
> (In reply to John David Anglin from comment #21)
> > With revision r14-8899-gc9bdcb0c343, I stll have the following fails:
> 
> Likewise on aarch64-linux-gnu.
> FAIL: g++.dg/modules/xtreme-header-1_a.H -std=c++17 (internal compiler
> error: in core_vals, at cp/module.cc:6116)

Oh that might be PR 111224 though.

[Bug c++/98531] [modules] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

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

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

--- Comment #22 from Andrew Pinski  ---
(In reply to John David Anglin from comment #21)
> With revision r14-8899-gc9bdcb0c343, I stll have the following fails:

Likewise on aarch64-linux-gnu.
FAIL: g++.dg/modules/xtreme-header-1_a.H -std=c++17 (internal compiler error:
in core_vals, at cp/module.cc:6116)

[Bug c++/98531] [modules] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

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

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed|2023-04-02 00:00:00 |2024-2-11

--- Comment #21 from John David Anglin  ---
With revision r14-8899-gc9bdcb0c343, I stll have the following fails:
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi 
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi 
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi 
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-4_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-6_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H module-cmi 
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header_a.H module-cmi 
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header_a.H module-cmi 
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)

[Bug target/113872] PERM<{0},a,{3,4,5,6}> is not producing SHL (for little-endian) and USHR for big-endian

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Mine, I have a patch.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

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

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to H.J. Lu from comment #4)
> (In reply to H.J. Lu from comment #3)
> > Created attachment 57385 [details]
> > A patch
> > 
> > Try this.
> 
> This doesn't work properly.  To work around in ld.so, _dl_tlsdesc_dynamic
> needs
> to save and restore ALL registers, which can be expensive.

Or it could be compiled with options to make sure it doesn't use vector
registers etc., and only save/restore if it needs to call into some code where
libc can't afford that (say allocate memory).

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
(In reply to H.J. Lu from comment #3)
> Created attachment 57385 [details]
> A patch
> 
> Try this.

This doesn't work properly.  To work around in ld.so, _dl_tlsdesc_dynamic needs
to save and restore ALL registers, which can be expensive.

[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow

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

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

--- Comment #3 from Jakub Jelinek  ---
The sanitizers don't turn on -fwrapv.
There is just TYPE_OVERFLOW_SANITIZED which inhibits various optimizations, in
the constant folder and match.pd etc. so that stuff can be instrumented
properly, doesn't get folded away before the instrumentation is added.
And given the amount of open bugs we have for cases where sanitizers should
catch some UB and don't, I don't think there is energy for enhancements like
this.

[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #2 from uecker at gcc dot gnu.org ---

How does -fwrapv make sense if it is supposed to catch the overflow?

[Bug modula2/113836] gm2 does not dump gimple or quadruples to a file

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

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

Gaius Mulley  changed:

   What|Removed |Added

  Attachment #57367|0   |1
is obsolete||

--- Comment #5 from Gaius Mulley  ---
Created attachment 57388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57388=edit
Proposed fix v8

This fixes an option bug and allows init/fini module ctor procedures to be
dumped.
Currently testing --enable-languages=all and comparing results before posting
to patches.

[Bug tree-optimization/106103] ICE in binds_to_current_def_p when source object files are compiled with -flto -Os

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

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

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

[Bug lto/113875] g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

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

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

[Bug sanitizer/113878] missed optimization with sanitizer and signed integer overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |sanitizer
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
The undefined sanitizer turns on -fwrapv to prevent optimizations from
optimizing based on undefined behavior and the overflow checks are added after
a few optimizations even.

[Bug c/113878] New: missed optimization with sanitizer and signed integer overflow

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 113878
   Summary: missed optimization with sanitizer and signed integer
overflow
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
  Target Milestone: ---

It would be nice if the following example could be optimized better with the
sanitizer. Without sanitizer the function is optimized to return 1. With
sanitizer I would expect it to only add the test for the underflow condition,
but it then fails to optimize well.

int test(int x)
{
if (x > 100)
return 1;
x -= 10;
if (x > 100)
return 2;
return 1;
}

https://godbolt.org/z/j4K96v7jn

[Bug lto/113875] g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

[ivanka2012 at gmail dot com via Gcc-bugs]

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

Ivan  changed:

   What|Removed |Added

 CC||ivanka2012 at gmail dot com

--- Comment #4 from Ivan  ---
Also a dupe of 106103

[Bug tree-optimization/106103] ICE in binds_to_current_def_p when source object files are compiled with -flto -Os

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #4 from Julian Waters  ---
The Java HotSpot VM also cannot currently be compiled for Windows with
optimization level SIZE and Link Time Optimization active due to this bug

[Bug lto/113875] g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Julian Waters  ---
Compiler configure options as requested by the gcc bug site:
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\ucrt64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/ucrt64/lib/gcc/x86_64-w64-mingw32/13.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-13.2.0/configure --prefix=/ucrt64
--with-local-prefix=/ucrt64/local --with-build-config=bootstrap-lto
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --with-native-system-header-dir=/ucrt64/include
--libexecdir=/ucrt64/lib --enable-bootstrap --enable-checking=release
--with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++
--enable-shared --enable-static --enable-libatomic --enable-threads=win32
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-threads
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp
--disable-multilib --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64
--with-pkgversion='Rev3, Built by MSYS2 project'
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++
--with-stage1-ldflags=-static-libstdc++
Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Rev3, Built by MSYS2 project)

I don't know if obtaining a preprocessed .i file is possible, since this crash
happens with the linker command line and also due to the sheer volume of source
files that are involved

[Bug lto/113875] g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Maybe a dup of bug 108383 due to -Os enabling -fdeclone-ctor-dtor .

[Bug lto/113875] g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

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

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

--- Comment #1 from Andrew Pinski  ---
Can you read https://gcc.gnu.org/bugs/ can get back to us on what is requested?

Also
https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction?highlight=%28reduction%29#Reducing_LTO_bugs
might be useful too.

[Bug lto/113875] g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-02-11
   Keywords||ice-on-valid-code, lto
Version|unknown |13.2.0

[Bug ada/113877] New: gnatchop -c puts gnat.adc in the current working directory

[simon at pushface dot org via Gcc-bugs]

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

Bug ID: 113877
   Summary: gnatchop -c puts gnat.adc in the current working
directory
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57387=edit
Demonstrator

In the attached demo, where demo-00.a contains only a configuration pragma,
you’d have expected "gnatchop -c *.a tmp" to put the configuration file 
"gnat.adc" into the same directory "tmp/" as the chopped code. Instead, it’s
output into the current directory.

$ gnatchop -c *.a tmp
writing configuration pragmas from demo-00.a to gnat.adc
splitting demo-00.a into:
splitting demo-01.a into:
   tmp/demo.ads

$ ls -R
demo-00.a   demo-01.a   gnat.adctmp

./tmp:
demo.ads

[Bug tree-optimization/113714] [11/12/13/14 Regression] Missed optimization for redundancy computation elimination: -(w+d-x)-x => -(w+d)

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

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

Filip Kastl  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com,
   ||pheeck at gcc dot gnu.org

--- Comment #3 from Filip Kastl  ---
For x86_64, I've bisected the regression to r11-1146-g1396fa5b91cfa0

[Bug target/113876] New: ICE: in ix86_expand_epilogue, at config/i386/i386.cc:10101 with -O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf -mcmodel=large and _BitInt()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 113876
   Summary: ICE: in ix86_expand_epilogue, at
config/i386/i386.cc:10101 with -O
-mpreferred-stack-boundary=3 -finstrument-functions
-mapxf -mcmodel=large and _BitInt()
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mpreferred-stack-boundary=3
-finstrument-functions -mapxf -mcmodel=large testcase.c 
during RTL pass: pro_and_epilogue
testcase.c: In function 'bar':
testcase.c:1:21: internal compiler error: in ix86_expand_epilogue, at
config/i386/i386.cc:10101
1 | _BitInt(129) bar() {}
  | ^
0x8b8e63 ix86_expand_epilogue(int)
/repo/gcc-trunk/gcc/config/i386/i386.cc:10101
0x1fca31f gen_epilogue()
/repo/gcc-trunk/gcc/config/i386/i386.md:19238
0x18eb205 target_gen_epilogue
/repo/gcc-trunk/gcc/config/i386/i386.md:18734
0x113ac26 make_epilogue_seq
/repo/gcc-trunk/gcc/function.cc:5970
0x113acfb thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.cc:6052
0x113b6a2 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.cc:6565
0x113b6a2 execute
/repo/gcc-trunk/gcc/function.cc:6651
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8910-20240210112800-g39920447f87-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8910-20240210112800-g39920447f87-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240210 (experimental) (GCC)

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 57385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57385=edit
A patch

Try this.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Alex, what was the original intention here?
It wouldn't surprise me if the intention was to clobber as few registers as
possible because in the common case the call doesn't really call much, just a
TLS load or so, and one can have hundreds of those in a single function.

[Bug lto/113712] [11/12/13/14 Regression] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9)

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

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

Filip Kastl  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||mjambor at suse dot cz,
   ||pheeck at gcc dot gnu.org

--- Comment #17 from Filip Kastl  ---
I've bisected this (using the test from Andrew Pinski) to
r10-3311-gff6686d2e5f797

[Bug lto/113875] New: g++ crash with Internal Compiler Error when compiling HotSpot for Windows with -Os and -flto

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Bug ID: 113875
   Summary: g++ crash with Internal Compiler Error when compiling
HotSpot for Windows with -Os and -flto
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tanksherman27 at gmail dot com
  Target Milestone: ---

When compiling the Java HotSpot VM for Windows, g++ crashes with an Internal
Compiler Error if the optimization level is set to SIZE (Aka -Os):

during GIMPLE pass: dse
src/hotspot/share/runtime/continuationFreezeThaw.cpp: In function
'freeze_epilog.isra':
src/hotspot/share/runtime/continuationFreezeThaw.cpp:1544:12: internal compiler
error: in binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:383:
C:\msys64\tmp\cc602ZS3.ltrans127.ltrans.o] Error 1
make[4]: *** Waiting for unfinished jobs
during GIMPLE pass: dse
ad_x86_gen.cpp: In member function 'MachNodeGenerator':
ad_x86_gen.cpp:508:11: internal compiler error: in binds_to_current_def_p, at
symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:41:
C:\msys64\tmp\cc602ZS3.ltrans13.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp: In function 'details.isra':
src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:312:6: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:377:
C:\msys64\tmp\cc602ZS3.ltrans125.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/share/classfile/verifier.cpp: In member function
'get_newarray_type.isra':
src/hotspot/share/classfile/verifier.cpp:3003: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:371:
C:\msys64\tmp\cc602ZS3.ltrans123.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp: In function
'fill_continuation_entry.constprop':
src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp:1326: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:368:
C:\msys64\tmp\cc602ZS3.ltrans122.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/share/prims/jni.cpp: In function 'jni_MonitorEnter':
src/hotspot/share/prims/jni.cpp:2712: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:191:
C:\msys64\tmp\cc602ZS3.ltrans63.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/cpu/x86/c1_Runtime1_x86.cpp: In member function
'restore_live_registers_except_rax.constprop':
src/hotspot/cpu/x86/c1_Runtime1_x86.cpp:568:6: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
during GIMPLE pass: dse
src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp: In member function
'addm.constprop':
src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp:670: internal compiler error: in
binds_to_current_def_p, at symtab.cc:2497
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:365:
C:\msys64\tmp\cc602ZS3.ltrans121.ltrans.o] Error 1
make[4]: *** [C:\msys64\tmp\ccxx3n9d.mk:362:
C:\msys64\tmp\cc602ZS3.ltrans120.ltrans.o] Error 1
during GIMPLE pass: dse
src/hotspot/share/gc/g1/g1ParScanThreadState.cpp: In member function
'steal_and_trim_queue':

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

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

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

Bug 98417 Summary: ICE when using C++ modules and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98417

   What|Removed |Added

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

[Bug c++/98417] ICE when using C++ modules and -g

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #4 from Nathaniel Shead  ---
Then fixed.

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

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

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

Bug 98885 Summary: [modules] forward declaration of classes prevent them from 
being exported at the point of actual declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98885

   What|Removed |Added

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

[Bug c++/98885] [modules] forward declaration of classes prevent them from being exported at the point of actual declaration

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #13 from Nathaniel Shead  ---
.

[Bug c++/98885] [modules] forward declaration of classes prevent them from being exported at the point of actual declaration

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||nshead at gcc dot gnu.org

--- Comment #12 from Nathaniel Shead  ---
Fixed for GCC 14.

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

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

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

Bug 100617 Summary: [modules] Exported namespace not visible from outside when 
the module imports another module that declares the same namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100617

   What|Removed |Added

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

[Bug c++/100617] [modules] Exported namespace not visible from outside when the module imports another module that declares the same namespace

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100707
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 Resolution|--- |FIXED
 CC||nshead at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Nathaniel Shead  ---
Fixed with r14-8407-gb433a6f5a0617d.

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

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

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

Bug 100689 Summary: [modules] internal compiler error: Segmentation fault when 
using modules and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100689

   What|Removed |Added

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

[Bug c++/100689] [modules] internal compiler error: Segmentation fault when using modules and -g

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #1 from Nathaniel Shead  ---
Fixed for GCC 14 with r14-8350-gaffef534b03355.

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

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

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

Bug 100707 Summary: [modules] ICE on nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100707

   What|Removed |Added

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

[Bug c++/100707] [modules] ICE on nested namespace

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #3 from Nathaniel Shead  ---
Fixed for GCC 14.

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

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

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

Bug 102545 Summary: [modules] inlining constexpr is required yet it should not 
be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102545

   What|Removed |Added

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

[Bug c++/102545] [modules] inlining constexpr is required yet it should not be.

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #3 from Nathaniel Shead  ---
Fixed for GCC 14 with r14-5826-g726723c4768002.

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

[Bug c++/99232] Exported variable in module gives error: 'lambda' was not declared in this scope

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||e9leyland at outlook dot com

--- Comment #4 from Nathaniel Shead  ---
*** Bug 102545 has been marked as a duplicate of this bug. ***

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

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

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

--- Comment #1 from Florian Weimer  ---
Brought to the x86-64 ABI list:

GCC and the GNU2 TLS descriptor call ABI

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

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

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

Bug 102598 Summary: [modules] ICE in pp_string, at pretty-print.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102598

   What|Removed |Added

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

[Bug c++/102598] [modules] ICE in pp_string, at pretty-print.c

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |nshead at gcc dot 
gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113580
 CC||nshead at gcc dot gnu.org
   Target Milestone|--- |14.0

--- Comment #3 from Nathaniel Shead  ---
Fixed with r14-8462-gec57d183d35412.