[Bug libstdc++/100621] New: ranges::reverse_view fails to meet its complexity requirements

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 100621
   Summary: ranges::reverse_view fails to meet its complexity
requirements
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Hi, in ranges#L3230, the _S_needs_cached_begin of reverse_view is defined as:


  static constexpr bool _S_needs_cached_begin
= !common_range<_Vp> && !random_access_range<_Vp>;


This definition seems incorrect, consider (https://godbolt.org/z/xfT5E4zK4):


  auto r = std::views::iota(0) | std::views::take(42) | std::views::drop(3);
  using V = decltype(r);
  static_assert(std::ranges::random_access_range);
  static_assert(!std::ranges::common_range);


This r is not a common_range but a random_access_range, so the value of
_S_needs_cached_begin is false, and because the following two asserts fail, the
complexity of ranges::next is O(n):


  using I = decltype(r.begin());
  using S = decltype(r.end());
  static_assert(!std::assignable_from);
  static_assert(!std::sized_sentinel_for);

  auto rr = r | std::views::reverse;


This makes rr.begin() fails to meet its complexity requirements in
[range.reverse.view#3]: "Remarks: In order to provide the amortized constant
time complexity required by the range concept, this function caches the result
within the reverse_­view for use on subsequent calls.".

[Bug c/82134] warn_unused_result triggers on empty structs even when they are used

[dblaikie at gmail dot com via Gcc-bugs]

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

David Blaikie  changed:

   What|Removed |Added

 CC||dblaikie at gmail dot com

--- Comment #6 from David Blaikie  ---
For what it's worth, this is being actively worked around in gmock here:
https://github.com/google/googletest/blob/662fe38e44900c007eccb65a5d2ea19df7bd520e/googlemock/include/gmock/gmock-more-actions.h#L295

[Bug other/100598] [12 Regression] MinGW Canadian cross toolchain fails to build due to missing BASEVER in genversion.c

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
I've seen the same issues.

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match

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

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

--- Comment #16 from Andrew Pinski  ---
I Have a new patch though I need to remove some code still.

[Bug web/100614] Missing mpfr 4 tarballs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-05-15

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

[Bug web/100614] Missing mpfr 4 tarballs

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |web

--- Comment #1 from Andrew Pinski  ---
Confirmed, I noticed this too.
https://gcc.gnu.org/pipermail/gcc/2021-May/236060.html

Possibly Wrong Permissions in "liboffloadmic"

[Firas Khalil Khana via Gcc-bugs]

Hey there,

I noticed that `liboffloadmic/configure' and
`liboffloadmic/plugin/configure' lack execute permissions (`644' instead of
`755'), and I was wondering if that was intended.

Thanks for your time and effort.

[Bug c/100620] New: ICE: in gimplify_var_or_parm_decl, at gimplify.c:2840

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 100620
   Summary: ICE: in gimplify_var_or_parm_decl, at gimplify.c:2840
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.eZIsobWkq2-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210514 (experimental) [master revision
:e5c3c8afa:f3b1516d9dfd969d7cc1ca6f26dec13478a1c458] (GCC)

$ cat mutant.c
__GIMPLE
foo() {
  int t1;
  t1_1 = __builtin_abs(t1);
}

$ gcc-trunk -fgimple mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | foo() {
  | ^~~
during GIMPLE pass: lower
In function ‘foo’:
cc1: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2840
0x6d9dc5 gimplify_var_or_parm_decl
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:2840
0xc26554 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:14544
0xc28b39 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify.c:14829
0xc4a301 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimplify-me.c:78
0xbf29f0 gimplify_and_update_call_from_tree(gimple_stmt_iterator*, tree_node*)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-fold.c:792
0xc007b9 gimple_fold_builtin
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-fold.c:5167
0xc03117 gimple_fold_call
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-fold.c:5561
0xc03117 fold_stmt_1
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-fold.c:6263
0x191f533 lower_stmt
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-low.c:388
0x191f533 lower_sequence
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-low.c:217
0x191f3dd lower_gimple_bind
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-low.c:473
0x192029d lower_function_body
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-low.c:110
0x192029d execute
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/gimple-low.c:195
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/100619] New: ICE: in build_attr_access_from_parms, at c-family/c-attribs.c:5038

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 100619
   Summary: ICE: in build_attr_access_from_parms, at
c-family/c-attribs.c:5038
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.eZIsobWkq2-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210514 (experimental) [master revision
:e5c3c8afa:f3b1516d9dfd969d7cc1ca6f26dec13478a1c458] (GCC)

$ cat mutant.c
n1;
a2pampan
  (int
  
(([][n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1]);

$ gcc-trunk  mutant.c
mutant.c:1:1: warning: data definition has no type or storage class
1 | n1;
  | ^~
mutant.c:1:1: warning: type defaults to ‘int’ in declaration of ‘n1’
[-Wimplicit-int]
mutant.c:2:1: warning: data definition has no type or storage class
2 | a2pampan
  | ^~~~
mutant.c:2:1: warning: type defaults to ‘int’ in declaration of ‘a2pampan’
[-Wimplicit-int]
mutant.c:4:4: internal compiler error: in build_attr_access_from_parms, at
c-family/c-attribs.c:5038
4 |   
(([][n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1])[n1]);
  |^
0x674eda build_attr_access_from_parms(tree_node*, bool)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/c-family/c-attribs.c:5038
0x8e1e78 finish_decl(tree_node*, unsigned int, tree_node*, tree_node*,
tree_node*)
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/c/c-decl.c:5540
0x94466b c_parser_declaration_or_fndef
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/c/c-parser.c:2370
0x94ce93 c_parser_external_declaration
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/c/c-parser.c:1777
0x94d8f9 c_parser_translation_unit
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/c/c-parser.c:1650
0x94d8f9 c_parse_file()
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/c/c-parser.c:21984
0x9adc35 c_common_parse_file()
/tmp/tmp.eZIsobWkq2-gcc-builder/gcc/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor

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

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

--- Comment #2 from Jonathan Wakely  ---
Somehow I missed this when the report was originally filed. I'll take a look.

[Bug libstdc++/100612] std::jthread can't be initialized with a pointer to a member function taking a std::stop_token

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED
   Severity|normal  |enhancement

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan O'Connor from comment #5)
> I was afraid you were going to say it's not a bug :-) That's why I reached
> out to Nico, who was on the committee, and was one of the people who
> proposed jthread.

Yes, I know, I was there when we reviewed it and voted it into the standard :-)

> My view, as a user, is that jthread should be a drop in replacement for
> thread, with auto-joining and stop_token support.

And it is. But "stop_token support" doesn't mean "can drop a stop_token at any
arbitrary position in the arguments list and expect it to work". For it to work
with a pointer-to-member we need to change the specification.


> I've just reread the descripton of jthread's constructor here:
> https://en.cppreference.com/w/cpp/thread/jthread/jthread
> and it does seem to explicitly exclude the behaviour I would like.

Right.

> So, I have no problem with you closing this as not a bug.
> Sorry for wasting your time. I guess, I'll have to write a committee
> proposal.

Please do.

> BTW, thanks for your all your work on g++ and the stdlib++. Much appreciated.

It's libstdc++ ;-)

FWIW this patch makes your code work, and I think this would make a reasonable
non-standard extension:

diff --git a/libstdc++-v3/include/std/thread b/libstdc++-v3/include/std/thread
index 886994c1320..ee4fec4a50c 100644
--- a/libstdc++-v3/include/std/thread
+++ b/libstdc++-v3/include/std/thread
@@ -99,6 +99,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

 #ifdef __cpp_lib_jthread

+#ifndef __STRICT_ANSI__
+template
+  constexpr bool __pmf_callable_with_stop_token = false;
+
+template
+  constexpr bool __pmf_callable_with_stop_token<_Callable, _Obj, _Args...>
+   = __and_>,
+is_invocable<_Callable, _Obj, stop_token, _Args...>>::value;
+#endif
+
   /// A thread that can be requested to stop and automatically joined.
   class jthread
   {
@@ -211,6 +221,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static thread
   _S_create(stop_source& __ssrc, _Callable&& __f, _Args&&... __args)
   {
+#ifndef __STRICT_ANSI__
+   if constexpr (__pmf_callable_with_stop_token<_Callable, _Args...>)
+ return _S_create2(__ssrc, std::forward<_Callable>(__f),
+   std::forward<_Args>(__args)...);
+   else
+#endif
if constexpr(is_invocable_v, stop_token,
decay_t<_Args>...>)
  return thread{std::forward<_Callable>(__f), __ssrc.get_token(),
@@ -226,6 +242,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  }
   }

+#ifndef __STRICT_ANSI__
+template
+  static thread
+  _S_create2(stop_source& __ssrc, _Callable&& __f, _Obj&& __obj,
+_Args&&... __args)
+  {
+   return thread{std::forward<_Callable>(__f), std::forward<_Obj>(__obj),
+ __ssrc.get_token(), std::forward<_Args>(__args)...};
+  }
+#endif
+
 stop_source _M_stop_source;
 thread _M_thread;
   };

I think I'll make this change in my own GCC fork, but not the gcc.gnu.org
version.

[Bug c/100618] Add a -fno-semantic-interposition variant which allows variable interposition

[i at maskray dot me via Gcc-bugs]

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

--- Comment #1 from Fangrui Song  ---
Perhaps

-fsemantic-interposition=function,variable (default -fpic/-fPIC)
-fsemantic-interposition=variable   (compatible with copy relocations but
enable function optimizations)
-fsemantic-interposition=  (alias: -fno-semantic-interposition)

?

[Bug c/100618] New: Add a -fno-semantic-interposition variant which allows variable interposition

[i at maskray dot me via Gcc-bugs]

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

Bug ID: 100618
   Summary: Add a -fno-semantic-interposition variant which allows
variable interposition
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

Extracted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483

The documentation says -fno-semantic-interposition applies to variables.

Having an option which only apply to external linkage function definitions will
be useful. Assuming no-variable-interposition is unfortunately incompatible
with the plethora of copy relocations: -fno-pic emits direct access relocations
referencing a global variable. If the global variable turns out to be defined
in a shared object, there will be a copy relocation in the executable. The
object the shared object sees and the executable sees will be different.

See
https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic#the-last-alliance-of-elf-and-men
for more context.

[Bug c++/100616] [modules] ICE when a variable of class taking a non-type template argument is defined both inside and outside the module

[amorvincitomnia.iw at gmail dot com via Gcc-bugs]

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

--- Comment #1 from wang ivor  ---
Seems like the same bug happens whenever you use a class template with a
non-type template argument in two modules with dependency. This seems to be a
pretty serious bug that renders non-type template argument basically unusable
inside modules.

[Bug bootstrap/100597] [12 Regression] Ada bootstrap fails

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
Presumably fixed.

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

[amorvincitomnia.iw at gmail dot com via Gcc-bugs]

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

Bug ID: 100617
   Summary: [modules] Exported namespace not visible from outside
when the module imports another module that declares
the same namespace
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amorvincitomnia.iw at gmail dot com
  Target Milestone: ---

See it live: https://wandbox.org/permlink/1Tgk83eCk7VYm3a3


Minimum code to reproduce the error:

//test2.cc
export module test2;
export namespace A{}

//test1.cc
export module test1;
import test2;
export namespace A{
int a = 3;
}

//prog.cc
import test1;

void g(){
A::a;
}



Compile it with:

$ g++ "-std=c++20" "-fmodules-ts" "test2.cc" "test1.cc" "prog.cc"



Results in error:

prog.cc: In function 'void g()':
prog.cc:5:5: error: 'A' has not been declared
5 | A::a;
  | ^



Reproduces in both g++ 11.1.0 and g++ 12.0.0 20210510.

[Bug c++/100616] New: [modules] ICE when a class template taking a non-type template argument is used both inside and outside the defining module

[amorvincitomnia.iw at gmail dot com via Gcc-bugs]

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

Bug ID: 100616
   Summary: [modules] ICE when a class template taking a non-type
template argument is used both inside and outside the
defining module
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amorvincitomnia.iw at gmail dot com
  Target Milestone: ---

See it live: https://wandbox.org/permlink/QUKvRN5GI1feSldA


Minimal code to reproduce ICE:

// test.cc
export module test;

export
{
struct A{};
template 
struct C {
};

C c1;
}

// prog.cc
import test;
C<1> c2;



Compile this with:

$ g++ "-std=c++20" "-fmodules-ts" "test.cc" "prog.cc"



Generates:

In module test, imported at prog.cc:2:
test.cc: In instantiation of 'struct C@test<1>':
prog.cc:3:6:   required from here
test.cc:8:12: internal compiler error: Segmentation fault
8 | struct C {
  |^
0xcac40f crash_signal
../../source/gcc/toplev.c:327
0x7e6673 comptypes(tree_node*, tree_node*, int)
../../source/gcc/cp/typeck.c:1544
0x7e6673 comptypes(tree_node*, tree_node*, int)
../../source/gcc/cp/typeck.c:1527
0x6a894f complete_vars(tree_node*)
../../source/gcc/cp/decl.c:17761
0x65f97b finish_struct_1(tree_node*)
../../source/gcc/cp/class.c:7505
0x7b1014 instantiate_class_template_1
../../source/gcc/cp/pt.c:12248
0x7b1e42 instantiate_class_template(tree_node*)
../../source/gcc/cp/pt.c:12288
0x7e380b complete_type(tree_node*)
../../source/gcc/cp/typeck.c:143
0x7e380b complete_type(tree_node*)
../../source/gcc/cp/typeck.c:111
0x6a1aeb start_decl_1(tree_node*, bool)
../../source/gcc/cp/decl.c:5677
0x6b283f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../source/gcc/cp/decl.c:5643
0x771343 cp_parser_init_declarator
../../source/gcc/cp/parser.c:21759
0x74fac4 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:14464
0x779cb5 cp_parser_declaration
../../source/gcc/cp/parser.c:14161
0x77a98e cp_parser_toplevel_declaration
../../source/gcc/cp/parser.c:14190
0x77a98e cp_parser_translation_unit
../../source/gcc/cp/parser.c:4942
0x77a98e c_parse_file()
../../source/gcc/cp/parser.c:45372
0x84b46d c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Reproduces in both g++ 11.1.0 and 12.0.0 20210510.

[Bug analyzer/100615] New: analyzer failed to report leak in rxtxcpu's parse_cpu_list

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

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

Bug ID: 100615
   Summary: analyzer failed to report leak in rxtxcpu's
parse_cpu_list
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

clang's static analyzer found this leak on an error-handling path:
  https://github.com/stackpath/rxtxcpu/pull/42
which gcc's -fanalyzer failed to report.

Looking at the code, I see that the string is passed to strsep and to strtol,
which IIRC the analyzer doesn't have special knowledge of (perhaps the analyzer
is conservatively assuming that these could free the string?)

[Bug libstdc++/100612] std::jthread can't be initialized with a pointer to a member function taking a std::stop_token

[jonathan.oconnor at protonmail dot com via Gcc-bugs]

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

--- Comment #5 from Jonathan O'Connor  
---
I was afraid you were going to say it's not a bug :-) That's why I reached out
to Nico, who was on the committee, and was one of the people who proposed
jthread.

My view, as a user, is that jthread should be a drop in replacement for thread,
with auto-joining and stop_token support.

I've just reread the descripton of jthread's constructor here:
https://en.cppreference.com/w/cpp/thread/jthread/jthread
and it does seem to explicitly exclude the behaviour I would like.

So, I have no problem with you closing this as not a bug.
Sorry for wasting your time. I guess, I'll have to write a committee proposal.

BTW, thanks for your all your work on g++ and the stdlib++. Much appreciated.

[Bug jit/100380] Segfault when using inline asm

[bouanto at zoho dot com via Gcc-bugs]

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

--- Comment #4 from Antoni  ---
I just had a similar issue when developing a new feature for libgccjit and it
might be the same problem. If it is (I haven't checked in this case), here's
what's happening:

 * The asm is replayed.
 * The asm tries to access the replayed variable (which wasn't replayed yet
because it was created after the asm).
 * Segfault (the rest is not executed, but is shown to explain what's
happening)
 * The variable is replayed (too late because it was NULL when accessed by the
asm).

Again it's to be verified, and I'm not sure what should be the solution to this
problem because the mementos are replayed in the order they were created.

[Bug libstdc++/100612] std::jthread can't be initialized with a pointer to a member function taking a std::stop_token

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> Are is the first argument in the pack,


Sorry, that was meant to say Arg0 not Are

[Bug libstdc++/100612] std::jthread can't be initialized with a pointer to a member function taking a std::stop_token

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

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

--- Comment #3 from Jonathan Wakely  ---
The standard could support this by saying that if the function object is a
pointer to member function then the requirement is
is_­invocable_­v, Arg0, stop_­token, decay_­t...> where Are
is the first argument in the pack, and ArgsN is the rest of the pack. But
that's not what the standard says.

[Bug other/100614] New: Missing mpfr 4 tarballs

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

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

Bug ID: 100614
   Summary: Missing mpfr 4 tarballs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Commit fe108dad32f521c4f924a397f11c63f86519e183 updated mpfr to version 4.1.0.
but did not upload the tarball.

as a consequence https://gcc.gnu.org/pub/gcc/infrastructure/mpfr-4.1.0.tar.bz2
returns 404 when running contrib/download_prerequisites is broken.

[Bug libstdc++/100612] std::jthread can't be initialized with a pointer to a member function taking a std::stop_token

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

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

--- Comment #2 from Jonathan Wakely  ---
I don't think this is valid.

The requirement for the constructor is is_­invocable_­v,
stop_­token, decay_­t...> which means the stop_token is passed to INVOKE
before the object, so it calls INVOKE(f, token, ) which isn't valid.

[Bug jit/100613] New: libgccjit should produce dylib on macOS

[wyuenho at gmail dot com via Gcc-bugs]

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

Bug ID: 100613
   Summary: libgccjit should produce dylib on macOS
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: wyuenho at gmail dot com
  Target Milestone: ---

Created attachment 50818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50818=edit
Make-lang.in patch to fix library ext on macOS

Compiling GCC with the language jit currently does not produce the correct
share library extension on macOS due to omission in Make-lang.in. The patch to
correct this is provided. You can also find the patch in Macports at
https://raw.githubusercontent.com/macports/macports-ports/master/lang/gcc11/files/patch-Make-lang.in.diff

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

[nilsgladitz at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Nils Gladitz  ---
(In reply to Nils Gladitz from comment #0)
> Indicating that "Foo" is constructed more often than it gets destructed.

Sorry that of course was supposed to read:
 Indicating that "Foo" is destructed more often than it gets constructed.

[Bug libstdc++/100612] std::jthread can't be initialized with a pointer to a member function taking a std::stop_token

[jonathan.oconnor at protonmail dot com via Gcc-bugs]

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

--- Comment #1 from Jonathan O'Connor  
---
The std::jthread constructor does not support taking a pointer to a member
function that has, as a first argument, a std::stop_token.

In C++20, the new jthread class can accept a std::stop_token to aid in stopping
a thread cooperatively. Unfortunately, the library code in gcc 10.2.0 and all
later versions (according to godbolt.org) do not allow a member function taking
a stop_token to be used to initialize a jthread.

The problem is due to the std::jthread::_S_create() method which can't handle
my desired case.

In a private email discussion with Nico Josuttis, his opinion was this should
be allowed by the standard:
  "well, my rough understanding is that as INVOKE is called
  (see 20.9.2 Requirements [func.require] in the Standard),
  you can always pass a member function with the object to call the member
  function for as next argument.
  That should work for both thread and jthread."

The fix should be relatively simple, involving a further if constexpr check for
the Callable being a member function. I'll try and make a patch, and append it
here.

#include 

struct ThreadObj {
void withoutStopToken() {}
void withStopToken(std::stop_token st) {}
};

int main() {
ThreadObj obj;
// The following line causes an error. The other example compile fine.
std::jthread t1{::withStopToken, };
std::jthread t2{::withoutStopToken, };
return 0;
}

[Bug libstdc++/100612] New: std::jthread can't be initialized with a pointer to a member function taking a std::stop_token

[jonathan.oconnor at protonmail dot com via Gcc-bugs]

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

Bug ID: 100612
   Summary: std::jthread can't be initialized with a pointer to a
member function taking a std::stop_token
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonathan.oconnor at protonmail dot com
  Target Milestone: ---

Created attachment 50817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50817=edit
Sample source code showing error

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

[nilsgladitz at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Nils Gladitz  ---
I opened bug 100611 for what I described above; assuming this is related but
distinct.

[Bug c++/100611] New: coroutines: destructor called too many times for coroutine lambda stored object

[nilsgladitz at gmail dot com via Gcc-bugs]

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

Bug ID: 100611
   Summary: coroutines: destructor called too many times for
coroutine lambda stored object
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nilsgladitz at gmail dot com
  Target Milestone: ---

Created attachment 50816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50816=edit
test case

Given the attached test case compiled and run with e.g.
 g++ test.cpp -std=c++20 -fcoroutines && ./a.out

produces the output:
 Foo(23) 0x55c938eb5ed4
 Foo(const& 23) 0x55c938eb5ee4
 ~Foo(23) 0x55c938eb5ee0
 ~Foo(23) 0x55c938eb5ee4
 ~Foo(23) 0x55c938eb5ed4

Indicating that "Foo" is constructed more often than it gets destructed.

This may be a variation of or related to bug 99576 which my test case is based
on.

Bug 99576 seems to be observable in 10.2 while this new issue seems to be
observable in 10.3 and 11.1.

Bisecting the gcc-10 release branch the dividing commit seems to be:
 commit f43a1b1d1718969423337190ddbbbc9037c67783
 Author: Iain Sandoe 
 Date:   Sun Jul 19 18:39:21 2020 +0100

 coroutines: Correct frame capture of compiler temps [PR95591+4].

[Bug tree-optimization/56457] Bogus warning: loop-invariant.c:786:20: error: unused variable ‘regno’ when building vax-*-*

[jbglaw--- via Gcc-bugs]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

 CC||jbg...@lug-owl.de

--- Comment #4 from Jan-Benedict Glaw  ---
This can IMHO be closed. Using a 11.0.1 based compiler (Debian "unstable"'s
"gcc-snapshot package) to build current GCC versions (ie. tested with
5e0236d3b0e0d7ad98bcee36128433fa755b5558 as of May 9th, 2021), the warning
doesn't appear. Indeed, the VAX backend recently got quite a major overhault by
Maciej.

[Bug debug/100610] New: DWARF5, wrong include_directories[0] when building in /

[simon.marchi at polymtl dot ca via Gcc-bugs]

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

Bug ID: 100610
   Summary: DWARF5, wrong include_directories[0] when building in
/
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

If I build a trivial test file while in the /tmp directory:

$ pwd
/tmp
$ cat test.c
#include 

#define FOO 2

int main() {
return FOO;
}
$ /opt/gcc/git/bin/gcc -gdwarf-5 -g3 -O0 -o test test.c

The include_directories table of .debug_line looks fine:

$ readelf --debug-dump=rawline test

 The Directory Table (offset 0x22, lines 7, columns 1):
  Entry Name
  0 (line_strp) (offset: 0x0): /tmp
  1 (line_strp) (offset: 0xc): /usr/include
  2 (line_strp) (offset: 0x19): /usr/include/bits
  3 (line_strp) (offset: 0x2b): /usr/include/sys
  4 (line_strp) (offset: 0x3c): /usr/include/gnu
  5 (line_strp) (offset: 0x4d):
/opt/gcc/git/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include
  6 (line_strp) (offset: 0x85): /usr/include/bits/types

 The File Name Table (offset 0x44, lines 26, columns 2):
  Entry Dir Name
  0 (udata) 0   (line_strp) (offset: 0x5): test.c
  1 (udata) 0   (line_strp) (offset: 0x5): test.c

Files #0 and #1 point to directory 0, which gives /tmp/test.c.

However, if I move test.c in the root directory, at /test.c and move there:

$ pwd
/
$ /opt/gcc/git/bin/gcc -gdwarf-5 -g3 -O0 -o /tmp/test test.c

 The Directory Table (offset 0x22, lines 7, columns 1):
  Entry Name
  0 (line_strp) (offset: 0x9): /usr/include
  1 (line_strp) (offset: 0x9): /usr/include
  2 (line_strp) (offset: 0x16): /usr/include/bits
  3 (line_strp) (offset: 0x28): /usr/include/sys
  4 (line_strp) (offset: 0x39): /usr/include/gnu
  5 (line_strp) (offset: 0x4a):
/opt/gcc/git/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include
  6 (line_strp) (offset: 0x82): /usr/include/bits/types

 The File Name Table (offset 0x44, lines 26, columns 2):
  Entry Dir Name
  0 (udata) 0   (line_strp) (offset: 0x0): test.c
  1 (udata) 0   (line_strp) (offset: 0x0): test.c

See the files #0 and #1.  They point to directory #0, which is /usr/include. 
That makes it believe that the source file was at /usr/include/test.c.  That
looks wrong to me.

[Bug bootstrap/100597] [12 Regression] Ada bootstrap fails

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org
 Target|x86_64-*-*, ia64-*-*,   |x86_64-*-*, ia64-*-*,
   |riscv64-*-* |riscv64-*-*, sparcv9-*-*

--- Comment #8 from Rainer Orth  ---
I'm seeing the same failure in a 64-bit-default Solaris/SPARC bootstrap, while
32-bit-default SPARC is ok.

[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor

[TonyELewis at hotmail dot com via Gcc-bugs]

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

Tony E Lewis  changed:

   What|Removed |Added

 CC||TonyELewis at hotmail dot com

--- Comment #1 from Tony E Lewis  ---
I agree with the OP's report: I think this static_assert() is rejecting valid
calls and accepting invalid calls.

AFAIU from https://eel.is/c++draft/reduce, we don't require that *the range's
value type* is convertible to the type we're reducing to; we require that *the
binary operation always returns something* that's convertible to the type being
reduced to.

So I think these two lines in the numeric header:

static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, _Tp&, _Tp&>);
static_assert(is_convertible_v);

...should instead be something like:

static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, _Tp&, _Tp&>);
static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, _Tp&, value_type&>);
static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, value_type&, _Tp&>);
static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, value_type&,
value_type&>);

(location :
https://github.com/gcc-mirror/gcc/blob/af42043e6618e69187b47f37dac870763c01e20f/libstdc%2B%2B-v3/include/std/numeric#L282
)

Thanks very much for all work on libstdc++.

[Bug bootstrap/100597] [12 Regression] Ada bootstrap fails

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

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #7 from Martin Jambor  ---
(In reply to Andreas Schwab from comment #6)
> Reverting ca9bb74a5f8 fixes bootstrap for me.

I have reverted the commit, so hopefully this is fixed (but I cannot verify
that at the moment).

[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Jambor  ---
Only now I realized I do not test Ada on aarch64 (which I used to test the
const_decl_pool stuff).  I have reverted the patch to fix bootstrap and will
have another look at this next week. Sorry for the breakage.

[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r12-809-gaf42043e6618e69187b47f37dac870763c01e20f
Author: Martin Jambor 
Date:   Sat May 15 10:11:12 2021 +0200

Revert "tree-sra: Avoid refreshing into const base decls (PR 100453)"

This reverts commit ca9bb74a5f856ccdceb4797f18b0a4ac8f49d069.
...because of Ada issues I did not catch with original testing.

gcc/ChangeLog:

2021-05-12  Martin Jambor  

Revert:
PR tree-optimization/100453
* tree-sra.c (sra_modify_assign): All const base accesses do not
need refreshing, not just those from decl_pool.
(sra_modify_assign): Do not refresh into a const base decl.

gcc/testsuite/ChangeLog:

2021-05-12  Martin Jambor  

Revert:
PR tree-optimization/100453
* gcc.dg/tree-ssa/pr100453.c: New test.

[Bug rtl-optimization/100342] [10/11 Regression] wrong code with -O2 -fno-dse -fno-forward-propagate -mno-sse2

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

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

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

https://gcc.gnu.org/g:425ad87dcfacbb326d8f448a0f2b4d6b53dcd98f

commit r12-808-g425ad87dcfacbb326d8f448a0f2b4d6b53dcd98f
Author: Jakub Jelinek 
Date:   Sat May 15 10:12:11 2021 +0200

regcprop: Fix another cprop_hardreg bug [PR100342]

On Tue, Jan 19, 2021 at 04:10:33PM +, Richard Sandiford via Gcc-patches
wrote:
> Ah, ok, thanks for the extra context.
>
> So AIUI the problem when recording xmm2<-di isn't just:
>
>  [A] partial_subreg_p (vd->e[sr].mode, GET_MODE (src))
>
> but also that:
>
>  [B] partial_subreg_p (vd->e[sr].mode,
vd->e[vd->e[sr].oldest_regno].mode)
>
> For example, all registers in this sequence can be part of the same
chain:
>
> (set (reg:HI R1) (reg:HI R0))
> (set (reg:SI R2) (reg:SI R1)) // [A]
> (set (reg:DI R3) (reg:DI R2)) // [A]
> (set (reg:SI R4) (reg:SI R[0-3]))
> (set (reg:HI R5) (reg:HI R[0-4]))
>
> But:
>
> (set (reg:SI R1) (reg:SI R0))
> (set (reg:HI R2) (reg:HI R1))
> (set (reg:SI R3) (reg:SI R2)) // [A] && [B]
>
> is problematic because it dips below the precision of the oldest regno
> and then increases again.
>
> When this happens, I guess we have two choices:
>
> (1) what the patch does: treat R3 as the start of a new chain.
> (2) pretend that the copy occured in vd->e[sr].mode instead
> (i.e. copy vd->e[sr].mode to vd->e[dr].mode)
>
> I guess (2) would need to be subject to REG_CAN_CHANGE_MODE_P.
> Maybe the optimisation provided by (2) compared to (1) isn't common
> enough to be worth the complication.
>
> I think we should test [B] as well as [A] though.  The pass is set
> up to do some quite elaborate mode changes and I think rejecting
> [A] on its own would make some of the other code redundant.
> It also feels like it should be a seperate âifâ or âelse ifâ,
> with its own comment.

Unfortunately, we now have a testcase that shows that testing also [B]
is a problem (unfortunately now latent on the trunk, only reproduces
on 10 and 11 branches).

The comment in the patch tries to list just the interesting instructions,
we have a 64-bit value, copy low 8 bit of those to another register,
copy full 64 bits to another register and then clobber the original
register.
Before that (set (reg:DI r14) (const_int ...)) we have a chain
DI r14, QI si, DI bp , that instruction drops the DI r14 from that chain,
so
we have QI si, DI bp , si being the oldest_regno.
Next DI si is copied into DI dx.  Only the low 8 bits of that are defined,
the rest is unspecified, but we would add DI dx into that same chain at the
end, so QI si, DI bp, DI dx [*].  Next si is overwritten, so the chain is
DI bp, DI dx.  And then we see (set (reg:DI dx) (reg:DI bp)) and remove it
as redundant, because we think bp and dx are already equivalent, when in
reality that is true only for the lowpart 8 bits.
I believe the [*] marked step above is where the bug is.

The committed regcprop.c (copy_value) change (but only committed to
trunk/11, not to 10) added
  else if (partial_subreg_p (vd->e[sr].mode, GET_MODE (src))
   && partial_subreg_p (vd->e[sr].mode,
vd->e[vd->e[sr].oldest_regno].mode))
return;
and while the first partial_subreg_p call returns true, the second one
doesn't; before the (set (reg:DI r14) (const_int ...)) insn it would be
true and we'd return, but as that reg got clobbered, si became the oldest
regno in the chain and so vd->e[vd->e[sr].oldest_regno].mode is QImode
and vd->e[sr].mode is QImode too, so the second partial_subreg_p is false.
But as the testcase shows, what is the oldest_regno in the chain is
something that changes over time, so relying on it for anything is
problematic, something could have a different oldest_regno and later
on get a different oldest_regno (perhaps with different mode) because
the oldest_regno got overwritten and it can change both ways.

The following patch effectively implements your (2) above.

2021-05-15  Jakub Jelinek  

PR rtl-optimization/100342
* regcprop.c (copy_value): When copying a source reg in a wider
mode than it has recorded for the value, adjust recorded
destination
mode too or punt if !REG_CAN_CHANGE_MODE_P.

* gcc.target/i386/pr100342.c: New test.